From skpobox at gawab.com Thu Sep 2 07:58:45 2004 From: skpobox at gawab.com (Sanjay Arora) Date: 02 Sep 2004 13:28:45 +0530 Subject: Let's get moving In-Reply-To: <20040831155156.GC31395@domino.ccmr.cornell.edu> References: <20040831155156.GC31395@domino.ccmr.cornell.edu> Message-ID: <1094037230.2462.12.camel@Sewak.Asr.Lan> On Tue, 2004-08-31 at 21:21, David Botsch wrote: > Not much activity as of late (is the project dead? Seems that way). I think that lack of participation is about to kill the fedora legacy project. People like myself who are not coders and were just using Linux on RH update strength were not daring enough to migrate to FC1/2 and most of those who were cometent in this field seem to have migrated to FC and other options. Its time to move on...I think...I am currently downloading whiteboax linux, a RH ES compatible compilation...for testing...FC six month upgrade is too fast for me. Ciao. Sanjay. From hjp+fedora-legacy at wsr.ac.at Thu Sep 2 10:12:50 2004 From: hjp+fedora-legacy at wsr.ac.at (Peter J. Holzer) Date: Thu, 2 Sep 2004 12:12:50 +0200 Subject: Let's get moving In-Reply-To: <20040902084711.GB3948@wsr.ac.at> References: <20040831155156.GC31395@domino.ccmr.cornell.edu> <1094037230.2462.12.camel@Sewak.Asr.Lan> <20040902084711.GB3948@wsr.ac.at> Message-ID: <20040902101250.GA6843@wsr.ac.at> On 2004-09-02 13:28:45 +0530, Sanjay Arora wrote: > On Tue, 2004-08-31 at 21:21, David Botsch wrote: > > Not much activity as of late (is the project dead? Seems that way). > > I think that lack of participation is about to kill the fedora legacy > project. I don't know if I'm alone, but my problem is that I don't really know how I can participate. To take a specific example, there is a tcpdump package in updates-testing since June. What does it take to move that to updates? There doesn't seem to be a bugzilla entry corresponding to it where I could enter a "I tested it and it seems to work" comment. Should such comments be directed to this list? hp -- _ | Peter J. Holzer | Shooting the users in the foot is bad. |_|_) | Sysadmin WSR / LUGA | Giving them a gun isn't. | | | hjp at wsr.ac.at | -- Gordon Schumacher, __/ | http://www.hjp.at/ | mozilla bug #84128 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 388 bytes Desc: not available URL: From mic at npgx.com.au Thu Sep 2 10:46:02 2004 From: mic at npgx.com.au (Michael Mansour) Date: Thu, 2 Sep 2004 20:46:02 +1000 Subject: Let's get moving In-Reply-To: <1094037230.2462.12.camel@Sewak.Asr.Lan> References: <20040831155156.GC31395@domino.ccmr.cornell.edu> <1094037230.2462.12.camel@Sewak.Asr.Lan> Message-ID: <20040902103830.M92660@npgx.com.au> Hi, > On Tue, 2004-08-31 at 21:21, David Botsch wrote: > > Not much activity as of late (is the project dead? Seems that way). > > I think that lack of participation is about to kill the fedora legacy > project. People like myself who are not coders and were just using Linux > on RH update strength were not daring enough to migrate to FC1/2 and > most of those who were cometent in this field seem to have migrated > to FC and other options. > > Its time to move on...I think...I am currently downloading whiteboax > linux, a RH ES compatible compilation...for testing...FC six month > upgrade is too fast for me. > > Ciao. > Sanjay. I definately like the spirit of FL and its purpose, but must say that after running several older versions of RH, I upgraded them all and don't use anything older than FC1 now. The upgrade wasn't that much of a drama, actually with the additional benefits of the software updates, it was worth the time and effort to make the leap to the newer OSes. FC is a very quick release cycle even for my tastes, but the way I'm doing it now is FC1 to FC3 to FC5 etc, which slows down the cycle for me. I currently run two FC2 machines but still find FC1 more stable for many of my apps and servers. As with anything in the tech field, it's hard to know where we're going to be at over the next couple of years and where this will all take us, but as with any community projects, the people must be there to contribute for it to stay alive and prosper. Michael. From lludwig-maillist at empoweringmedia.com Thu Sep 2 11:48:04 2004 From: lludwig-maillist at empoweringmedia.com (lludwig-maillist at empoweringmedia.com) Date: Thu, 2 Sep 2004 07:48:04 -0400 Subject: Let's get moving In-Reply-To: <20040902101250.GA6843@wsr.ac.at> References: <20040831155156.GC31395@domino.ccmr.cornell.edu> <1094037230.2462.12.camel@Sewak.Asr.Lan> <20040902084711.GB3948@wsr.ac.at> <20040902101250.GA6843@wsr.ac.at> Message-ID: <1094125684.413708743255c@www.emwebmail.com> Quoting "Peter J. Holzer" : > On 2004-09-02 13:28:45 +0530, Sanjay Arora wrote: > > On Tue, 2004-08-31 at 21:21, David Botsch wrote: > > > Not much activity as of late (is the project dead? Seems that way). > > > > I think that lack of participation is about to kill the fedora legacy > > project. > > I don't know if I'm alone, but my problem is that I don't really know > how I can participate. To take a specific example, there is a tcpdump > package in updates-testing since June. What does it take to move that to > updates? There doesn't seem to be a bugzilla entry corresponding to it > where I could enter a "I tested it and it seems to work" comment. Should > such comments be directed to this list? I agree, I more than happy to help but it seems like no one is really steering the ship. > > hp > > -- > _ | Peter J. Holzer | Shooting the users in the foot is bad. > |_|_) | Sysadmin WSR / LUGA | Giving them a gun isn't. > | | | hjp at wsr.ac.at | -- Gordon Schumacher, > __/ | http://www.hjp.at/ | mozilla bug #84128 > -- Larry Ludwig Empowering Media lludwig at empoweringmedia.com http://www.empoweringmedia.com hostasite.com - Web Hosting made simple 631-321-0262 -------------------------------------------------- http://www.hostasite.com - Web hosting made simple From jonny.strom at netikka.fi Thu Sep 2 13:16:58 2004 From: jonny.strom at netikka.fi (Johnny Strom) Date: Thu, 02 Sep 2004 16:16:58 +0300 Subject: Let's get moving In-Reply-To: <1094125684.413708743255c@www.emwebmail.com> References: <20040831155156.GC31395@domino.ccmr.cornell.edu> <1094037230.2462.12.camel@Sewak.Asr.Lan> <20040902084711.GB3948@wsr.ac.at> <20040902101250.GA6843@wsr.ac.at> <1094125684.413708743255c@www.emwebmail.com> Message-ID: <41371D4A.2060306@netikka.fi> lludwig-maillist at empoweringmedia.com wrote: > Quoting "Peter J. Holzer" : > > >>On 2004-09-02 13:28:45 +0530, Sanjay Arora wrote: >> >>>On Tue, 2004-08-31 at 21:21, David Botsch wrote: >>> >>>>Not much activity as of late (is the project dead? Seems that way). >>> >>>I think that lack of participation is about to kill the fedora legacy >>>project. >> >>I don't know if I'm alone, but my problem is that I don't really know >>how I can participate. To take a specific example, there is a tcpdump >>package in updates-testing since June. What does it take to move that to >>updates? There doesn't seem to be a bugzilla entry corresponding to it >>where I could enter a "I tested it and it seems to work" comment. Should >>such comments be directed to this list? > > > I agree, I more than happy to help but it seems like no one is really steering > the ship. Hi Well all open sorce projects needs one or more leader's, what we could perhaps do is to delegte areas of responsibilities to persons. Like one person is responsible for rh 9 uppdates and one for rh 7.3 etc.. > > >> hp >> >>-- >> _ | Peter J. Holzer | Shooting the users in the foot is bad. >>|_|_) | Sysadmin WSR / LUGA | Giving them a gun isn't. >>| | | hjp at wsr.ac.at | -- Gordon Schumacher, >>__/ | http://www.hjp.at/ | mozilla bug #84128 >> > > > From guallar at easternrad.com Thu Sep 2 13:54:43 2004 From: guallar at easternrad.com (Josep L. Guallar-Esteve) Date: Thu, 2 Sep 2004 09:54:43 -0400 Subject: Let's get moving In-Reply-To: <1094037230.2462.12.camel@Sewak.Asr.Lan> References: <20040831155156.GC31395@domino.ccmr.cornell.edu> <1094037230.2462.12.camel@Sewak.Asr.Lan> Message-ID: <200409020954.47323.guallar@easternrad.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday 02 September 2004 03:58 am, Sanjay Arora wrote: > Its time to move on...I think...I am currently downloading whiteboax > linux, a RH ES compatible compilation...for testing...FC six month > upgrade is too fast for me. I would recomend you to try CentOS-3. It's another RHEL rebuild, like WhiteBoxLinux. But, IMHO, it has a broader support and a more active community. Bug fixes and security patches show up fast. Get info about CentOS-3 here: http://www.caosity.org There is also a way I use both RHEL and CentOS-3. Nice distros. Regards, Josep - -- Josep L. Guallar-Esteve Eastern Radiologists, Inc. Systems and PACS Administration http://www.easternrad.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBNyYmSGQa4/zQ9e8RAnfLAJ9No9aT4RdUBRMv1ECsqNkA1vS5AwCePs3X lSYTNrKTh0nqvRcwEDi/AfA= =GfiV -----END PGP SIGNATURE----- From lists at alpha345.com Thu Sep 2 13:59:39 2004 From: lists at alpha345.com (Matt Dickinson) Date: Thu, 2 Sep 2004 08:59:39 -0500 Subject: Let's get moving In-Reply-To: <1094125684.413708743255c@www.emwebmail.com> Message-ID: <20040902135940.29B581A851A@tornado.pdcompsys.com> lludwig-maillist at empoweringmedia.com wrote: > I agree, I more than happy to help but it seems like no one is really > steering the ship. I've got time to spend, and I'm sure I'd be able to do some of the jobs required, I just don't know _exactly_ where to get started in the most efficient manner. Matt From strange at nsk.no-ip.org Thu Sep 2 14:16:23 2004 From: strange at nsk.no-ip.org (Luciano Miguel Ferreira Rocha) Date: Thu, 2 Sep 2004 15:16:23 +0100 Subject: RH-Dist-FAQ: WAS: OpenSSL In-Reply-To: <1093373736.2379.76.camel@patriux.localdomain> References: <03d701c48a01$0f9bb6c0$1701a8c0@alec> <1093373736.2379.76.camel@patriux.localdomain> Message-ID: <20040902141623.GA9269@nsk.no-ip.org> On Tue, Aug 24, 2004 at 02:55:37PM -0400, Bryan J. Smith wrote: > (21264) used it as well. > > B. How XP 64-bit Edition is still 32-bit, using Win64 on Win32 (WoW) > for most libraries, because Microsoft couldn't tackle the massive > compatibility and effort that GCC/GLibC/Linux did back in the mid-'90s. > Right now, if you want to run 64-bit programs on Windows, you are (or > your vendor is ;-) stuck with making sure you have 64-bit libraries. > Other than a kernel that runs in "long mode," XP 64-bit still quite > 32-bit at the core. > > So benchmarks on PC enthusiast sites showing _reduced_ performance with > 64-bit versions of applications on XP 64-bit Ed is not only not > surprising -- but a "replay" of the old NT 3.x days when Win32 on Win16 > (WoW) ran Win16 apps slower. History repeats itself. ;-ppp "ran Win16 apps slower" or win32 apps? If history is to repeat itself, it should be the other way around. :) Regards, Luciano Rocha From dwb7 at ccmr.cornell.edu Thu Sep 2 14:20:08 2004 From: dwb7 at ccmr.cornell.edu (David Botsch) Date: Thu, 2 Sep 2004 10:20:08 -0400 Subject: Let's get moving In-Reply-To: <20040902135940.29B581A851A@tornado.pdcompsys.com> References: <1094125684.413708743255c@www.emwebmail.com> <20040902135940.29B581A851A@tornado.pdcompsys.com> Message-ID: <20040902142008.GA14912@ccmr.cornell.edu> I would advise the following: first start by QAing stuff that's in bugzilla that needs either one or two PUBLISHes (which OS are you willing to do)? then, make packages for those things that don't have packages made, yet Remember that in QA we need a pgp signed message with the sha1sum of the srpm and a clear PUBLISH or DONT PUBLISH stated. On Thu, Sep 02, 2004 at 08:59:39AM -0500, Matt Dickinson wrote: > lludwig-maillist at empoweringmedia.com wrote: > > I agree, I more than happy to help but it seems like no one is really > > steering the ship. > > I've got time to spend, and I'm sure I'd be able to do some of the jobs > required, I just don't know _exactly_ where to get started in the most > efficient manner. > > Matt > > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-legacy-list -- ******************************** David William Botsch Consultant/Advisor II CCMR Computing Facility dwb7 at ccmr.cornell.edu ******************************** From matt.followers at gmail.com Thu Sep 2 14:48:21 2004 From: matt.followers at gmail.com (Matt Nuzum) Date: Thu, 2 Sep 2004 10:48:21 -0400 Subject: Let's get moving In-Reply-To: <20040902135940.29B581A851A@tornado.pdcompsys.com> References: <20040902135940.29B581A851A@tornado.pdcompsys.com> Message-ID: <27c475ec04090207483360c3d@mail.gmail.com> On Thu, 2 Sep 2004 08:59:39 -0500, Matt Dickinson wrote: > lludwig-maillist at empoweringmedia.com wrote: > > I agree, I more than happy to help but it seems like no one is really > > steering the ship. > > I've got time to spend, and I'm sure I'd be able to do some of the jobs > required, I just don't know _exactly_ where to get started in the most > efficient manner. > > Matt > > Sorry if this sounds a bit like a rant, it's really not. It strikes me that FLP is a short-term project to help people transition into one of the more long-term linux solutions. RedHat has split their product into two, one for those who like to live on the edge, and another who like to maintain stability for long periods of time. So likewise, the RH/FC community is made up of 2 or 3 groups of people. For those people who really can't afford to make big changes every year and are still running RH 7, 8, and 9 (like me), we need to transition to a commercially supported distribution. For those who like to be on the edge and use FC, FLP is of no use and they probably don't subscribe to this list. There is one other group of people; those who want a free OS but didn't realize the extent of what RH said when FC was released as an unsupported, rapidly changing distribution. I was shocked to see FC1 retired so soon. People in this group need to come to the realization that they need to choose a new distribution, either RHEL for stability, FC for new features and RH familiarity, or another distribution entirely. I suggest that FLP create time-lines for which people can expect support. RH 7.x (x>=1) came out in 2001, right? How long does the community want to support it? I've found that people often hesitate to volunteer for a project when there is no end in sight. They feel like they will be chained to it for the rest of their life. I think if we said, (for example) RH 7.x support extended through FLP until Dec. 31 2005 and (again for example) RH 8,9 support extended through Dec 31 2006 it would help people feel more confident about volunteering (cause there's an end date) and it would help people like me to finally kick it in gear and make a decission about what to do. We could put a "project ownership" schedule up so people could commit to doing an aspect of the maintenance work for a set amount of time. This is how we would determine the time frame of support for a product. I personally do not advocate that FLP support FC > 1. I think a lot of people bought into FC thinking it was the next generation of RHL. By now they need to realize it's a whole new beast and they need to make a decission if that's what they really want. BTW, I would like to see TAO, WhiteBox and CentOS merge into one and pool their resources. Unless I see a stronger community arise I will consider these to be less supported even than FC. Just some food for thought, -- Matthew Nuzum | Makers of "Elite Content Management System" www.followers.net | View samples of Elite CMS in action matt at followers.net | http://www.followers.net/portfolio/ From ckelley at ibnads.com Thu Sep 2 15:42:06 2004 From: ckelley at ibnads.com (Craig Kelley) Date: Thu, 02 Sep 2004 09:42:06 -0600 Subject: Let's get moving In-Reply-To: <27c475ec04090207483360c3d@mail.gmail.com> References: <20040902135940.29B581A851A@tornado.pdcompsys.com> <27c475ec04090207483360c3d@mail.gmail.com> Message-ID: <41373F4E.8070902@ibnads.com> Matt Nuzum wrote: >BTW, I would like to see TAO, WhiteBox and CentOS merge into one and >pool their resources. Unless I see a stronger community arise I will >consider these to be less supported even than FC. > >Just some food for thought, > > Don't forget Scientific/Fermi Linux; another RHEL3 clone... it's fairly well supported. I like RedHat 7.3; and will continue to use it for at least another year. -- Craig Kelley In-Store Broadcasting Network -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 256 bytes Desc: OpenPGP digital signature URL: From drees at greenhydrant.com Thu Sep 2 15:57:57 2004 From: drees at greenhydrant.com (David Rees) Date: Thu, 02 Sep 2004 08:57:57 -0700 Subject: Let's get moving In-Reply-To: <27c475ec04090207483360c3d@mail.gmail.com> References: <20040902135940.29B581A851A@tornado.pdcompsys.com> <27c475ec04090207483360c3d@mail.gmail.com> Message-ID: <41374305.2030400@greenhydrant.com> Matt Nuzum wrote, On 9/2/2004 7:48 AM: > > I suggest that FLP create time-lines for which people can expect > support. RH 7.x (x>=1) came out in 2001, right? How long does the > community want to support it? It is quite clear how long RH 7.3 and 9 will be supported for, see the FAQ: http://www.fedoralegacy.org/about/faq.php While it is not a specific date, I do not see that as a problem. It will be supported as long as there is community support. In the end that is what the FL project requires to succeed, community support. However, it just isn't a very exciting job to do backporting and testing of legacy software. For those of you wanting to see packages make it out of -testing, please see the QA Testing document. It does quite a good job of describing the QA process. http://www.fedoralegacy.org/wiki/index.php/QaTesting -Dave From cradle at umd.edu Thu Sep 2 16:14:08 2004 From: cradle at umd.edu (David Eisner) Date: Thu, 02 Sep 2004 12:14:08 -0400 Subject: Let's get moving In-Reply-To: <41374305.2030400@greenhydrant.com> References: <20040902135940.29B581A851A@tornado.pdcompsys.com> <27c475ec04090207483360c3d@mail.gmail.com> <41374305.2030400@greenhydrant.com> Message-ID: <413746D0.3010706@umd.edu> David Rees wrote: >For those of you wanting to see packages make it out of -testing, please >see the QA Testing document. It does quite a good job of describing the >QA process. > >http://www.fedoralegacy.org/wiki/index.php/QaTesting > > >From http://www.fedoralegacy.org/participate/ QA tester You are a person who has a machine on which they can download and test package updates. Your task is to download test packages and check that they build, install, and function correctly on a given platform. You then report your findings in Bugzilla. I think this page should be updated to include a link to the QaTesting Wiki document. Consider these an addition to the changes I recommended earlier: http://www.redhat.com/archives/fedora-legacy-list/2004-August/msg00118.html -David From dom at earth.li Thu Sep 2 16:15:31 2004 From: dom at earth.li (Dominic Hargreaves) Date: Thu, 2 Sep 2004 17:15:31 +0100 Subject: Let's get moving In-Reply-To: <41374305.2030400@greenhydrant.com> References: <20040902135940.29B581A851A@tornado.pdcompsys.com> <27c475ec04090207483360c3d@mail.gmail.com> <41374305.2030400@greenhydrant.com> Message-ID: <20040902161531.GA26041@tirian.magd.ox.ac.uk> On Thu, Sep 02, 2004 at 08:57:57AM -0700, David Rees wrote: > In the end that is what the FL project requires to succeed, community > support. However, it just isn't a very exciting job to do backporting > and testing of legacy software. > > For those of you wanting to see packages make it out of -testing, please > see the QA Testing document. It does quite a good job of describing the > QA process. It also needs a working infrastructure. Since we've not seen any packages actually be released for months I have pretty much run out of enthusiasm for contributing to the project. Dominic. From dwb7 at ccmr.cornell.edu Thu Sep 2 16:57:43 2004 From: dwb7 at ccmr.cornell.edu (David Botsch) Date: Thu, 2 Sep 2004 12:57:43 -0400 Subject: Let's get moving In-Reply-To: <41374305.2030400@greenhydrant.com> References: <20040902135940.29B581A851A@tornado.pdcompsys.com> <27c475ec04090207483360c3d@mail.gmail.com> <41374305.2030400@greenhydrant.com> Message-ID: <20040902165743.GE14912@ccmr.cornell.edu> If I read the QA doc correctly, what it actually refers to is getting stuff put into updates-testing, not moved out of updates-testing to updates. After talking w. some folk in the channel, my understanding is that after 2 weeks, if no one objects, packages should be moved from updates-testing to updates and released as final. Unless I misunderstood, it also seems that only one person currently has the ability to actually do this. And, 2 weeks is also way, way, way tooo long. A couple days is more like it. On Thu, Sep 02, 2004 at 08:57:57AM -0700, David Rees wrote: > Matt Nuzum wrote, On 9/2/2004 7:48 AM: > > > >I suggest that FLP create time-lines for which people can expect > >support. RH 7.x (x>=1) came out in 2001, right? How long does the > >community want to support it? > > It is quite clear how long RH 7.3 and 9 will be supported for, see the > FAQ: http://www.fedoralegacy.org/about/faq.php While it is not a > specific date, I do not see that as a problem. It will be supported as > long as there is community support. > > In the end that is what the FL project requires to succeed, community > support. However, it just isn't a very exciting job to do backporting > and testing of legacy software. > > For those of you wanting to see packages make it out of -testing, please > see the QA Testing document. It does quite a good job of describing the > QA process. > > http://www.fedoralegacy.org/wiki/index.php/QaTesting > > -Dave > > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-legacy-list -- ******************************** David William Botsch Consultant/Advisor II CCMR Computing Facility dwb7 at ccmr.cornell.edu ******************************** From jonny.strom at netikka.fi Thu Sep 2 17:24:10 2004 From: jonny.strom at netikka.fi (Johnny Strom) Date: Thu, 02 Sep 2004 20:24:10 +0300 Subject: Let's get moving In-Reply-To: <20040902165743.GE14912@ccmr.cornell.edu> References: <20040902135940.29B581A851A@tornado.pdcompsys.com> <27c475ec04090207483360c3d@mail.gmail.com> <41374305.2030400@greenhydrant.com> <20040902165743.GE14912@ccmr.cornell.edu> Message-ID: <4137573A.1040207@netikka.fi> David Botsch wrote: > If I read the QA doc correctly, what it actually refers to is getting stuff put > into updates-testing, not moved out of updates-testing to updates. > > After talking w. some folk in the channel, my understanding is that after 2 > weeks, if no one objects, packages should be moved from updates-testing to > updates and released as final. > > Unless I misunderstood, it also seems that only one person currently has the > ability to actually do this. And, 2 weeks is also way, way, way tooo long. A > couple days is more like it. Yes that's right the problem is that it have taken to long to get them to a relase so how can we speed this up? I think we need 2 or 3 ppl that have the rights to make relases. > > On Thu, Sep 02, 2004 at 08:57:57AM -0700, David Rees wrote: > >>Matt Nuzum wrote, On 9/2/2004 7:48 AM: >> >>>I suggest that FLP create time-lines for which people can expect >>>support. RH 7.x (x>=1) came out in 2001, right? How long does the >>>community want to support it? >> >>It is quite clear how long RH 7.3 and 9 will be supported for, see the >>FAQ: http://www.fedoralegacy.org/about/faq.php While it is not a >>specific date, I do not see that as a problem. It will be supported as >>long as there is community support. >> >>In the end that is what the FL project requires to succeed, community >>support. However, it just isn't a very exciting job to do backporting >>and testing of legacy software. >> >>For those of you wanting to see packages make it out of -testing, please >>see the QA Testing document. It does quite a good job of describing the >>QA process. >> >>http://www.fedoralegacy.org/wiki/index.php/QaTesting >> >>-Dave >> >> >>-- >>fedora-legacy-list mailing list >>fedora-legacy-list at redhat.com >>http://www.redhat.com/mailman/listinfo/fedora-legacy-list > > From skpobox at gawab.com Thu Sep 2 17:25:08 2004 From: skpobox at gawab.com (Sanjay Arora) Date: 02 Sep 2004 22:55:08 +0530 Subject: Let's get moving In-Reply-To: <200409020954.47323.guallar@easternrad.com> References: <20040831155156.GC31395@domino.ccmr.cornell.edu> <1094037230.2462.12.camel@Sewak.Asr.Lan> <200409020954.47323.guallar@easternrad.com> Message-ID: <1094145907.4360.16.camel@Sewak.Asr.Lan> On Thu, 2004-09-02 at 19:24, Josep L. Guallar-Esteve wrote: > > I would recomend you to try CentOS-3. It's another RHEL rebuild, like > WhiteBoxLinux. But, IMHO, it has a broader support and a more active > community. Bug fixes and security patches show up fast. > > Get info about CentOS-3 here: http://www.caosity.org Its already next on the testing list ;-) Downloading entire iso(s) on dial-up is plain hell ;-( Thanks. Sanjay. From lludwig-maillist at empoweringmedia.com Thu Sep 2 18:14:45 2004 From: lludwig-maillist at empoweringmedia.com (lludwig-maillist at empoweringmedia.com) Date: Thu, 2 Sep 2004 14:14:45 -0400 Subject: Let's get moving In-Reply-To: <20040902142008.GA14912@ccmr.cornell.edu> References: <1094125684.413708743255c@www.emwebmail.com> <20040902135940.29B581A851A@tornado.pdcompsys.com> <20040902142008.GA14912@ccmr.cornell.edu> Message-ID: <1094148885.41376315ca6cc@www.emwebmail.com> Quoting David Botsch : > I would advise the following: > > first start by QAing stuff that's in bugzilla that needs either one or two > PUBLISHes (which OS are you willing to do)? 7.3 for me. I'll have to add an account in bugzilla. > > then, make packages for those things that don't have packages made, yet > > Remember that in QA we need a pgp signed message with the sha1sum of the > srpm > and a clear PUBLISH or DONT PUBLISH stated. > > On Thu, Sep 02, 2004 at 08:59:39AM -0500, Matt Dickinson wrote: > > lludwig-maillist at empoweringmedia.com wrote: > > > I agree, I more than happy to help but it seems like no one is really > > > steering the ship. > > > > I've got time to spend, and I'm sure I'd be able to do some of the jobs > > required, I just don't know _exactly_ where to get started in the most > > efficient manner. > > > > Matt > > > > > > -- > > fedora-legacy-list mailing list > > fedora-legacy-list at redhat.com > > http://www.redhat.com/mailman/listinfo/fedora-legacy-list > > -- > ******************************** > David William Botsch > Consultant/Advisor II > CCMR Computing Facility > dwb7 at ccmr.cornell.edu > ******************************** > > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-legacy-list > -- Larry Ludwig Empowering Media lludwig at empoweringmedia.com http://www.empoweringmedia.com hostasite.com - Web Hosting made simple 631-321-0262 -------------------------------------------------- http://www.hostasite.com - Web hosting made simple From dwb7 at ccmr.cornell.edu Thu Sep 2 19:25:01 2004 From: dwb7 at ccmr.cornell.edu (David Botsch) Date: Thu, 2 Sep 2004 15:25:01 -0400 Subject: Let's get moving In-Reply-To: <4137573A.1040207@netikka.fi> References: <20040902135940.29B581A851A@tornado.pdcompsys.com> <27c475ec04090207483360c3d@mail.gmail.com> <41374305.2030400@greenhydrant.com> <20040902165743.GE14912@ccmr.cornell.edu> <4137573A.1040207@netikka.fi> Message-ID: <20040902192501.GA13812@ccmr.cornell.edu> well... I am willing to help for the time being... when I have time and until we get migrated to RHEL, as far as RH7.3 goes. On Thu, Sep 02, 2004 at 08:24:10PM +0300, Johnny Strom wrote: > David Botsch wrote: > >If I read the QA doc correctly, what it actually refers to is getting > >stuff put > >into updates-testing, not moved out of updates-testing to updates. > > > >After talking w. some folk in the channel, my understanding is that after 2 > >weeks, if no one objects, packages should be moved from updates-testing to > >updates and released as final. > > > >Unless I misunderstood, it also seems that only one person currently has > >the > >ability to actually do this. And, 2 weeks is also way, way, way tooo long. > >A > >couple days is more like it. > > > Yes that's right the problem is that it have taken to long to get them > to a relase so how can we speed this up? > I think we need 2 or 3 ppl that have the rights to make relases. > > > > > >On Thu, Sep 02, 2004 at 08:57:57AM -0700, David Rees wrote: > > > >>Matt Nuzum wrote, On 9/2/2004 7:48 AM: > >> > >>>I suggest that FLP create time-lines for which people can expect > >>>support. RH 7.x (x>=1) came out in 2001, right? How long does the > >>>community want to support it? > >> > >>It is quite clear how long RH 7.3 and 9 will be supported for, see the > >>FAQ: http://www.fedoralegacy.org/about/faq.php While it is not a > >>specific date, I do not see that as a problem. It will be supported as > >>long as there is community support. > >> > >>In the end that is what the FL project requires to succeed, community > >>support. However, it just isn't a very exciting job to do backporting > >>and testing of legacy software. > >> > >>For those of you wanting to see packages make it out of -testing, please > >>see the QA Testing document. It does quite a good job of describing the > >>QA process. > >> > >>http://www.fedoralegacy.org/wiki/index.php/QaTesting > >> > >>-Dave > >> > >> > >>-- > >>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 -- ******************************** David William Botsch Consultant/Advisor II CCMR Computing Facility dwb7 at ccmr.cornell.edu ******************************** From mattdm at mattdm.org Thu Sep 2 19:57:01 2004 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 2 Sep 2004 15:57:01 -0400 Subject: component=package in bugzilla Message-ID: <20040902195701.GA21772@jadzia.bu.edu> I mentioned this before, but nothing came of it, so I thought I would again. I think it'd really help the project if the bugzilla were better organized. At the very least, there needs to be individual bugzilla components for each source package (like Red Hat's bugzilla, or the _rest_ of the fedora bugzilla). I know this is incredibly tedious to do by hand, but it can be scripted pretty easily if you have access to the server/database directly. In fact, I have a quick-hack perl script to do just this -- takes a file with the output of 'rpm -qip *' (basically) and feeds it in to bugzilla. I'd be very willing to help get this set up. Maybe this seems like a triviality, but good infrastructure is important for a project like this to succeed. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From marcdeslauriers at videotron.ca Thu Sep 2 22:02:04 2004 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Thu, 02 Sep 2004 18:02:04 -0400 Subject: Let's get moving In-Reply-To: <27c475ec04090207483360c3d@mail.gmail.com> References: <20040902135940.29B581A851A@tornado.pdcompsys.com> <27c475ec04090207483360c3d@mail.gmail.com> Message-ID: <1094162524.17209.9.camel@mdlinux> On Thu, 2004-09-02 at 10:48, Matt Nuzum wrote: > Sorry if this sounds a bit like a rant, it's really not. It strikes > me that FLP is a short-term project to help people transition into one > of the more long-term linux solutions. AFAIK, FLP is a long term project to transform Fedora products into long-term linux solutions. > For those people who really can't afford to make big changes every > year and are still running RH 7, 8, and 9 (like me), we need to > transition to a commercially supported distribution. Or, a community supported distribution, like debian, or Fedora Legacy. > There is one other group of people; those who want a free OS but > didn't realize the extent of what RH said when FC was released as an > unsupported, rapidly changing distribution. I was shocked to see FC1 > retired so soon. People in this group need to come to the realization > that they need to choose a new distribution, either RHEL for > stability, FC for new features and RH familiarity, or another > distribution entirely. Once the Fedora Legacy Project starts rolling, FC will become a viable option for long-term use, as much as Red Hat Linux used to be, although unsupported by Red Hat. > I've found that people often hesitate to volunteer for a project when > there is no end in sight. They feel like they will be chained to it > for the rest of their life. I think if we said, (for example) RH 7.x > support extended through FLP until Dec. 31 2005 and (again for > example) RH 8,9 support extended through Dec 31 2006 it would help Timelines don't really work in a community supported project. Although rh 7.2 and rh 8.0 support was supposed to be longer, lack of community interest put them on hold. Nevertheless, there are timelines published on the FLP web page somewhere. > I personally do not advocate that FLP support FC > 1. Why not? There is no reason FLP can't extend the useful life of FC releases. > I think a lot > of people bought into FC thinking it was the next generation of RHL. It's the next generation of free RHL. Marc. From sstrong at crwash.org Thu Sep 2 22:20:11 2004 From: sstrong at crwash.org (Steve Strong) Date: Thu, 02 Sep 2004 17:20:11 -0500 Subject: samba won't authenticate Message-ID: <1094163611.2562.6.camel@localhost.localdomain> This is really hot. I'm a CS teacher in a high school. We use dual-boot linux/win2k in the lab I support. The students using window suddenly can't change their samba password. Here's a dialog from the command line: [aford at stretch aford]$ smbpasswd Old SMB password: New SMB password: Retype new SMB password: machine 127.0.0.1 rejected the session setup. Error was : NT_STATUS_LOGON_FAILURE. Failed to change password for aford [aford at stretch aford]$ the same dialog occurs at the server, on a client in the lab (and the same subnet as the server) or from a remote location using puTTy. logged in as root locally or remotely, i can successfully use smbpasswd to change the passwords. The server is running RH 9.0 without the benefit of updates since RH 9.0 went EOL. The clients are running win2k with all current updates. Any ideas? and thanks in advance! steve -- Steve Strong Math/Computer Science Teacher Washington High School 2205 Forest Dr. SE Cedar Rapids, IA 52403 email: sstrong at crwash.org web: http://crwash.org telephone: 319-558-4685 From dwb7 at ccmr.cornell.edu Fri Sep 3 02:27:09 2004 From: dwb7 at ccmr.cornell.edu (David Botsch) Date: Thu, 2 Sep 2004 22:27:09 -0400 Subject: samba won't authenticate In-Reply-To: <1094163611.2562.6.camel@localhost.localdomain> References: <1094163611.2562.6.camel@localhost.localdomain> Message-ID: <20040903022709.GA15684@ccmr.cornell.edu> SInce I'm not doing this, I can't really troubleshoot, but a couple of things: 1. are you up to date w. the FL released updates for RH9? 2. did upgrading the samba rpm replace your samba pam or other samba config files? On Thu, Sep 02, 2004 at 05:20:11PM -0500, Steve Strong wrote: > This is really hot. > > I'm a CS teacher in a high school. We use dual-boot linux/win2k in the > lab I support. The students using window suddenly can't change their > samba password. Here's a dialog from the command line: > > [aford at stretch aford]$ smbpasswd > Old SMB password: > New SMB password: > Retype new SMB password: > machine 127.0.0.1 rejected the session setup. Error was : > NT_STATUS_LOGON_FAILURE. > Failed to change password for aford > [aford at stretch aford]$ > > the same dialog occurs at the server, on a client in the lab (and the > same subnet as the server) or from a remote location using puTTy. > > logged in as root locally or remotely, i can successfully use smbpasswd > to change the passwords. > > The server is running RH 9.0 without the benefit of updates since RH 9.0 > went EOL. The clients are running win2k with all current updates. > > Any ideas? > > and thanks in advance! > steve > -- > Steve Strong > Math/Computer Science Teacher > Washington High School > 2205 Forest Dr. SE > Cedar Rapids, IA 52403 > email: sstrong at crwash.org > web: http://crwash.org > telephone: 319-558-4685 > > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-legacy-list -- ******************************** David William Botsch Consultant/Advisor II CCMR Computing Facility dwb7 at ccmr.cornell.edu ******************************** From dwb7 at ccmr.cornell.edu Fri Sep 3 19:51:28 2004 From: dwb7 at ccmr.cornell.edu (David Botsch) Date: Fri, 3 Sep 2004 15:51:28 -0400 Subject: Let's get moving In-Reply-To: <4137573A.1040207@netikka.fi>; from jonny.strom@netikka.fi on Thu, Sep 02, 2004 at 13:24:10 -0400 References: <20040902135940.29B581A851A@tornado.pdcompsys.com> <27c475ec04090207483360c3d@mail.gmail.com> <41374305.2030400@greenhydrant.com> <20040902165743.GE14912@ccmr.cornell.edu> <4137573A.1040207@netikka.fi> Message-ID: <20040903195128.GM22667@domino.ccmr.cornell.edu> Who is currently responsible for doing this? And who has permissions to delegate this off to a few other people? On 2004.09.02 13:24 Johnny Strom wrote: > David Botsch wrote: >> If I read the QA doc correctly, what it actually refers to is >> getting stuff put >> into updates-testing, not moved out of updates-testing to updates. >> >> After talking w. some folk in the channel, my understanding is that >> after 2 >> weeks, if no one objects, packages should be moved from >> updates-testing to >> updates and released as final. >> >> Unless I misunderstood, it also seems that only one person currently >> has the >> ability to actually do this. And, 2 weeks is also way, way, way tooo >> long. A >> couple days is more like it. > > > Yes that's right the problem is that it have taken to long to get > them to a relase so how can we speed this up? > I think we need 2 or 3 ppl that have the rights to make relases. > > >> >> On Thu, Sep 02, 2004 at 08:57:57AM -0700, David Rees wrote: >> >>> Matt Nuzum wrote, On 9/2/2004 7:48 AM: >>> >>>> I suggest that FLP create time-lines for which people can expect >>>> support. RH 7.x (x>=1) came out in 2001, right? How long does the >>>> community want to support it? >>> >>> It is quite clear how long RH 7.3 and 9 will be supported for, see >>> the FAQ: http://www.fedoralegacy.org/about/faq.php While it is not >>> a specific date, I do not see that as a problem. It will be >>> supported as long as there is community support. >>> >>> In the end that is what the FL project requires to succeed, >>> community support. However, it just isn't a very exciting job to >>> do backporting and testing of legacy software. >>> >>> For those of you wanting to see packages make it out of -testing, >>> please see the QA Testing document. It does quite a good job of >>> describing the QA process. >>> >>> http://www.fedoralegacy.org/wiki/index.php/QaTesting >>> >>> -Dave >>> >>> >>> -- >>> 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 -- ******************************** David William Botsch Consultant/Advisor II CCMR Computing Facility dwb7 at ccmr.cornell.edu ******************************** From marcdeslauriers at videotron.ca Fri Sep 3 22:49:59 2004 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Fri, 03 Sep 2004 18:49:59 -0400 Subject: Let's get moving In-Reply-To: <20040903195128.GM22667@domino.ccmr.cornell.edu> References: <20040902135940.29B581A851A@tornado.pdcompsys.com> <27c475ec04090207483360c3d@mail.gmail.com> <41374305.2030400@greenhydrant.com> <20040902165743.GE14912@ccmr.cornell.edu> <4137573A.1040207@netikka.fi> <20040903195128.GM22667@domino.ccmr.cornell.edu> Message-ID: <1094251799.20632.0.camel@mdlinux> On Fri, 2004-09-03 at 15:51, David Botsch wrote: > Who is currently responsible for doing this? And who has permissions to > delegate this off to a few other people? That would be Jesse Keating. Marc. From madlists at teaparty.net Sat Sep 4 07:11:55 2004 From: madlists at teaparty.net (Tom Yates) Date: Sat, 4 Sep 2004 08:11:55 +0100 (BST) Subject: Let's get moving In-Reply-To: <1094251799.20632.0.camel@mdlinux> References: <20040902135940.29B581A851A@tornado.pdcompsys.com> <27c475ec04090207483360c3d@mail.gmail.com> <41374305.2030400@greenhydrant.com> <20040902165743.GE14912@ccmr.cornell.edu> <4137573A.1040207@netikka.fi> <20040903195128.GM22667@domino.ccmr.cornell.edu> <1094251799.20632.0.camel@mdlinux> Message-ID: On Fri, 3 Sep 2004, Marc Deslauriers wrote: > On Fri, 2004-09-03 at 15:51, David Botsch wrote: >> Who is currently responsible for doing this? And who has permissions to >> delegate this off to a few other people? > > That would be Jesse Keating. perhaps we should ask jesse how we might best help share the load? maybe having one person with final authority on the release process is no bad thing - i know that none of the stuff i've installed so far has been anything but fine - but maybe that person shouldn't have to be doing loads of other stuff as well. i feel we're a little to quick to re-engineer this process. it's not like it's broken, it's just painfully slow. can anyone inside it identify major rate-limiting steps that people can help with, and point to documentation on how to do it? if there's no doco, *please* say so, i'll jump through the hoops and write some up (if it's about something i can do, which doesn't include making new packages). -- Tom Yates Cambridge, UK. From jimpop at yahoo.com Sat Sep 4 11:52:54 2004 From: jimpop at yahoo.com (Jim Popovitch) Date: Sat, 04 Sep 2004 07:52:54 -0400 Subject: Let's get moving In-Reply-To: References: <20040902135940.29B581A851A@tornado.pdcompsys.com> <27c475ec04090207483360c3d@mail.gmail.com> <41374305.2030400@greenhydrant.com> <20040902165743.GE14912@ccmr.cornell.edu> <4137573A.1040207@netikka.fi> <20040903195128.GM22667@domino.ccmr.cornell.edu> <1094251799.20632.0.camel@mdlinux> Message-ID: <1094298774.7153.3.camel@blue> On Sat, 2004-09-04 at 03:11, Tom Yates wrote: > On Fri, 3 Sep 2004, Marc Deslauriers wrote: > > > > > > That would be Jesse Keating. > > perhaps we should ask jesse Where is Jesse? Perhaps he unsubcribed himself accidentally. ;) -Jim P. From jkeating at j2solutions.net Sat Sep 4 18:11:46 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Sat, 4 Sep 2004 11:11:46 -0700 Subject: Let's get moving In-Reply-To: <1094298774.7153.3.camel@blue> References: <20040902135940.29B581A851A@tornado.pdcompsys.com> <1094298774.7153.3.camel@blue> Message-ID: <200409041111.52712.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Saturday 04 September 2004 04:52, Jim Popovitch wrote: > Where is Jesse? ?Perhaps he unsubcribed himself accidentally. ;) Actually I've been incredibly busy at work trying to get something ready for a very large cluster opportunity. I have been working 12~14 hour days and doing nothing but eating/sleeping at home. I think I'm finally through it, and I can do what I have been planning for a while. I'm building a 'public' build server that I will have colocated somewhere near me. A few people will be given access to this server and they can build/sign/release Legacy updates from it. I plan on taking something of a backseat in the Fedora Legacy development process given that I just can't make time for it. My work promised that I would be given time but it just isn't happening. - -- Jesse Keating RHCE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedoralegacy.org) GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBOgVn4v2HLvE71NURAn78AJ9FTgpGIbLzLzK9QEoPSb5ZuYfz/QCgspKD dkkY/7oknm2Au9D4PWGMwiY= =Wt9C -----END PGP SIGNATURE----- From boris at folgmann.de Mon Sep 6 10:11:25 2004 From: boris at folgmann.de (Boris Folgmann) Date: Mon, 06 Sep 2004 12:11:25 +0200 Subject: Unoffical, minor RedHat 8.0 support Message-ID: <413C37CD.1030605@folgmann.de> Hi! I know that RH8 support was dropped due to the small number of RH8 systems. However people keep asking for it. Since RH9 is supported I assume that most updated SRPMS could be compiled and used successfully on RH8. If anybody is interested I think we could form a small group for sharing knowledge if this or that works or works not. If necessary I could provide some Webspace or a mailing list for this. For me it would be also ok to discuss it here, because that's where everybody looks first. If anybody already has experiences with RH9 updates on RH8 for important services like SSL, Apache, Firewall and so on, please share it. cu, boris From neils at ariel.met.tamu.edu Mon Sep 6 17:08:05 2004 From: neils at ariel.met.tamu.edu (Neil Smith) Date: Mon, 6 Sep 2004 12:08:05 -0500 Subject: wrong GPG key for FedoraLegacy? Message-ID: <51858864-0027-11D9-AD4B-000A9599F046@ariel.met.tamu.edu> RedHat 9 Attempting to use yum for updating a new install of RH 9 according to directions from http://www.fedoralegacy.org/docs/yum-rh9.php. So now have yum-2.0.3-0.fdr.1.rh90 gnupg-1.2.1-9 And also did rpm --import http://www.fedoralegacy.org/FEDORA-LEGACY-GPG-KEY with confirmation: rpm -qa gpg-pubkey* gpg-pubkey-731002fa-400b9109 And also have verbatum yum.conf from that site: [main] cachedir=/var/cache/yum debuglevel=2 logfile=/var/log/yum.log pkgpolicy=newest distroverpkg=redhat-release tolerant=1 exactarch=1 #exclude=kernel* [base] name=Red Hat Linux $releasever - $basearch - Base baseurl=http://download.fedora.us/fedora/redhat/$releasever/$basearch/ yum/os/ gpgcheck=1 [updates] name=Red Hat Linux $releasever - $basearch - updates baseurl=http://download.fedora.us/fedora/redhat/$releasever/$basearch/ yum/updates/ gpgcheck=1 yum check-update shows bunches of available updates. But when running, say, [root at achem2 log]# yum update grep Gathering header information file(s) from server(s) Server: Red Hat Linux 9 - i386 - Base Server: Red Hat Linux 9 - i386 - updates Finding updated packages Downloading needed headers Resolving dependencies Dependencies resolved I will do the following: [update: grep 2.5.1-7.8.i386] Is this ok [y/N]: y Getting grep-2.5.1-7.8.i386.rpm warning: rpmts_HdrFromFdno: V3 DSA signature: NOKEY, key ID db42a60e Error: Could not find the GPG Key necessary to validate pkg /var/cache/yum/updates/packages/grep-2.5.1-7.8.i386.rpm Error: You may want to run yum clean or remove the file: /var/cache/yum/updates/packages/grep-2.5.1-7.8.i386.rpm Error: You may also check that you have the correct GPG keys installed I get this regardless of the package requested. Does anyone know what is happening here? Thanks. -Neil ------------------ Neil R. Smith neils at tamu.edu Comp.Sys.Mngr. (979)845-6272 Dept. Atmospheric Sciences/Texas A&M University From ametzler at logic.univie.ac.at Mon Sep 6 17:19:51 2004 From: ametzler at logic.univie.ac.at (Andreas Metzler) Date: Mon, 6 Sep 2004 19:19:51 +0200 Subject: wrong GPG key for FedoraLegacy? In-Reply-To: <51858864-0027-11D9-AD4B-000A9599F046@ariel.met.tamu.edu> References: <51858864-0027-11D9-AD4B-000A9599F046@ariel.met.tamu.edu> Message-ID: <20040906171949.GG899@balrog.logic.univie.ac.at> On Mon, Sep 06, 2004 at 12:08:05PM -0500, Neil Smith wrote: [...] > rpm --import http://www.fedoralegacy.org/FEDORA-LEGACY-GPG-KEY > with confirmation: > rpm -qa gpg-pubkey* > gpg-pubkey-731002fa-400b9109 [...] > Getting grep-2.5.1-7.8.i386.rpm > warning: rpmts_HdrFromFdno: V3 DSA signature: NOKEY, key ID db42a60e > Error: Could not find the GPG Key necessary to validate pkg [...] This is a update from redhat.com, generated while they were still providing support for RH9, and therefore signed RedHat, not by fedoara-legacy. http://www.redhat.com/security/db42a60e.txt cu andreas From rostetter at mail.utexas.edu Tue Sep 7 18:22:07 2004 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Tue, 7 Sep 2004 13:22:07 -0500 Subject: Let's get moving In-Reply-To: <20040902101250.GA6843@wsr.ac.at> References: <20040831155156.GC31395@domino.ccmr.cornell.edu> <1094037230.2462.12.camel@Sewak.Asr.Lan> <20040902084711.GB3948@wsr.ac.at> <20040902101250.GA6843@wsr.ac.at> Message-ID: <1094581327.130bad31eaaa3@mail.ph.utexas.edu> Quoting "Peter J. Holzer" : > I don't know if I'm alone, but my problem is that I don't really know > how I can participate. Post to the list asking how you can help, and be patient in getting the help. Suggest topics that need to be addressed on the web site, or even create your own questions/answers in the wicki pages. > To take a specific example, there is a tcpdump > package in updates-testing since June. What does it take to move that to > updates? People to test it and vote for it to be published (for each OS version to which it applies). > There doesn't seem to be a bugzilla entry corresponding to it > where I could enter a "I tested it and it seems to work" comment. Should > such comments be directed to this list? Yes, they should be directed to this list, and the bugzilla entry is likely https://bugzilla.fedora.us/show_bug.cgi?id=1468 > hp > > -- > _ | Peter J. Holzer | Shooting the users in the foot is bad. > |_|_) | Sysadmin WSR / LUGA | Giving them a gun isn't. > | | | hjp at wsr.ac.at | -- Gordon Schumacher, > __/ | http://www.hjp.at/ | mozilla bug #84128 > -- Eric Rostetter From rostetter at mail.utexas.edu Tue Sep 7 18:26:07 2004 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Tue, 7 Sep 2004 13:26:07 -0500 Subject: Let's get moving In-Reply-To: <1094125684.413708743255c@www.emwebmail.com> References: <20040831155156.GC31395@domino.ccmr.cornell.edu> <1094037230.2462.12.camel@Sewak.Asr.Lan> <20040902084711.GB3948@wsr.ac.at> <20040902101250.GA6843@wsr.ac.at> <1094125684.413708743255c@www.emwebmail.com> Message-ID: <1094581567.30e9cc30398b2@mail.ph.utexas.edu> Quoting lludwig-maillist at empoweringmedia.com: > I agree, I more than happy to help but it seems like no one is really > steering > the ship. It is a very large ship to steer, and so far we don't have enough volunteers to help steer. Ask on the list, and you should get answers. But if you want specific answers, you will need to ask specific questions. I can't tell you how to help per se, because I don't know what you are capable of doing, or willing to do. But the single most important thing would be to get people to QA packages. And I can tell you what needs to be done to do that, if you express a desire to do so. > Larry Ludwig > Empowering Media > lludwig at empoweringmedia.com > http://www.empoweringmedia.com > hostasite.com - Web Hosting made simple > 631-321-0262 -- Eric Rostetter From rostetter at mail.utexas.edu Tue Sep 7 18:41:04 2004 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Tue, 7 Sep 2004 13:41:04 -0500 Subject: Let's get moving In-Reply-To: <27c475ec04090207483360c3d@mail.gmail.com> References: <20040902135940.29B581A851A@tornado.pdcompsys.com> <27c475ec04090207483360c3d@mail.gmail.com> Message-ID: <1094582464.8649983989036@mail.ph.utexas.edu> Quoting Matt Nuzum : > Sorry if this sounds a bit like a rant, it's really not. It strikes > me that FLP is a short-term project to help people transition into one > of the more long-term linux solutions. No, it is a long term project, to last as long at least as long as Fedora Core lasts plus some after that. > For those who like to be on the edge and use FC, FLP is of no use and > they probably don't subscribe to this list. Yes, it is of use to them. For example, we can only upgrade between school semesters. FC releases don't usually happen on that schedule. So we need to FL to hold us over on the old release until we can upgrade to the new one, at a minimum. > I suggest that FLP create time-lines for which people can expect > support. RH 7.x (x>=1) came out in 2001, right? How long does the > community want to support it? For as long as there is community support. This is all in the web site and FAQ, which apparently you have not read. > BTW, I would like to see TAO, WhiteBox and CentOS merge into one and > pool their resources. Unless I see a stronger community arise I will > consider these to be less supported even than FC. I think CentOS is well supported by the community. TAO and WhiteBox are of course a whole different story. > Just some food for thought, But none of it agrees with the purpose or intent of FL, so it really doesn't help in any way. > -- > Matthew Nuzum | Makers of "Elite Content Management System" > www.followers.net | View samples of Elite CMS in action > matt at followers.net | http://www.followers.net/portfolio/ -- Eric Rostetter From rostetter at mail.utexas.edu Tue Sep 7 19:16:30 2004 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Tue, 7 Sep 2004 14:16:30 -0500 Subject: Let's get moving In-Reply-To: <413746D0.3010706@umd.edu> References: <20040902135940.29B581A851A@tornado.pdcompsys.com> <27c475ec04090207483360c3d@mail.gmail.com> <41374305.2030400@greenhydrant.com> <413746D0.3010706@umd.edu> Message-ID: <1094584590.9f4996067ae9e@mail.ph.utexas.edu> Quoting David Eisner : > I think this page should be updated to include a link to the > QaTesting Wiki document. Done. > Consider these an addition to the changes I > recommended earlier: > > http://www.redhat.com/archives/fedora-legacy-list/2004-August/msg00118.html Done, but I'm sure there is room for improvement. Submitted suggested changes to me, or to the mailing list. > -David -- Eric Rostetter From rostetter at mail.utexas.edu Tue Sep 7 19:23:57 2004 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Tue, 7 Sep 2004 14:23:57 -0500 Subject: Let's get moving In-Reply-To: <20040902165743.GE14912@ccmr.cornell.edu> References: <20040902135940.29B581A851A@tornado.pdcompsys.com> <27c475ec04090207483360c3d@mail.gmail.com> <41374305.2030400@greenhydrant.com> <20040902165743.GE14912@ccmr.cornell.edu> Message-ID: <1094585037.1aa0b0d478bbb@mail.ph.utexas.edu> Quoting David Botsch : > If I read the QA doc correctly, what it actually refers to is getting stuff > put > into updates-testing, not moved out of updates-testing to updates. The bottom section about publishing is about moving it from updates-testing to updates. It should be made more clear. > After talking w. some folk in the channel, my understanding is that after 2 > weeks, if no one objects, packages should be moved from updates-testing to > updates and released as final. No, IRRC. If the package has passed QA for one OS version, but not for other OS versions, then after 2 weeks all versions can be passed. This is there so that if one SRPM is built for multiple OS versions, they won't all hang up because only one OS version wasn't tested. It really only applies when the same SRPM, or at least the same patch code, was used for all of the versions. If a different patch was used for the different versions, then this probably shouldn't be applied to that case. At least that is my memory of the situation. > Unless I misunderstood, it also seems that only one person currently has the > ability to actually do this. And, 2 weeks is also way, way, way tooo long. A > couple days is more like it. Yes, currently it is one person. But that doesn't usually matter as the RPMs never even get the QA publish votes for them to be moved. So one person or 10 people, it doesn't matter if there is nothing to be moved. And 2 weeks is a timeout if no one votes on it. To speed that up, vote on it. Participation is the key. -- Eric Rostetter From rostetter at mail.utexas.edu Tue Sep 7 19:26:09 2004 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Tue, 7 Sep 2004 14:26:09 -0500 Subject: Let's get moving In-Reply-To: <20040902161531.GA26041@tirian.magd.ox.ac.uk> References: <20040902135940.29B581A851A@tornado.pdcompsys.com> <27c475ec04090207483360c3d@mail.gmail.com> <41374305.2030400@greenhydrant.com> <20040902161531.GA26041@tirian.magd.ox.ac.uk> Message-ID: <1094585169.823d4dc0c41f5@mail.ph.utexas.edu> Quoting Dominic Hargreaves : > It also needs a working infrastructure. Since we've not seen any > packages actually be released for months I have pretty much run out of > enthusiasm for contributing to the project. > > Dominic. You and many others stop contributing because no packages are being released. Packages are not being released because of a lack of people contributing. Catch-22, chicken and egg, self-fulfilling profacy, or what ever your other favorite cliche is... -- Eric Rostetter From dwb7 at ccmr.cornell.edu Tue Sep 7 19:47:22 2004 From: dwb7 at ccmr.cornell.edu (David Botsch) Date: Tue, 7 Sep 2004 15:47:22 -0400 Subject: Let's get moving In-Reply-To: <1094585037.1aa0b0d478bbb@mail.ph.utexas.edu> References: <20040902135940.29B581A851A@tornado.pdcompsys.com> <27c475ec04090207483360c3d@mail.gmail.com> <41374305.2030400@greenhydrant.com> <20040902165743.GE14912@ccmr.cornell.edu> <1094585037.1aa0b0d478bbb@mail.ph.utexas.edu> Message-ID: <20040907194722.GA361@ccmr.cornell.edu> See Johnny Strom's email.... you and he are having different interpretations of what means what... my interpretation this point of PUBLISH is when an SRPM is built and is on someone's public server someplace. People download it, QA it, and say PUBLISH or DONTPUBLISH. When it gets two gpg signed PUBLISHes, it gets stuck in updates-testing Two weeks after that, w/o objection, it should go to updates. So, if that is not what is supposed to be happening, then, we've got a problem. One can have too much QA, and if I'm reading your interpretation of what is going on, then I would say we have too much QA, perhaps. On Tue, Sep 07, 2004 at 02:23:57PM -0500, Eric Rostetter wrote: > Quoting David Botsch : > > > If I read the QA doc correctly, what it actually refers to is getting stuff > > put > > into updates-testing, not moved out of updates-testing to updates. > > The bottom section about publishing is about moving it from updates-testing > to updates. It should be made more clear. > > > After talking w. some folk in the channel, my understanding is that after 2 > > weeks, if no one objects, packages should be moved from updates-testing to > > updates and released as final. > > No, IRRC. If the package has passed QA for one OS version, but not for > other OS versions, then after 2 weeks all versions can be passed. This > is there so that if one SRPM is built for multiple OS versions, they won't > all hang up because only one OS version wasn't tested. It really only > applies when the same SRPM, or at least the same patch code, was used for > all of the versions. If a different patch was used for the different versions, > then this probably shouldn't be applied to that case. > > At least that is my memory of the situation. > > > Unless I misunderstood, it also seems that only one person currently has the > > ability to actually do this. And, 2 weeks is also way, way, way tooo long. A > > couple days is more like it. > > Yes, currently it is one person. But that doesn't usually matter as the > RPMs never even get the QA publish votes for them to be moved. So one > person or 10 people, it doesn't matter if there is nothing to be moved. > > And 2 weeks is a timeout if no one votes on it. To speed that up, vote on > it. Participation is the key. > > -- > Eric Rostetter > > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-legacy-list -- ******************************** David William Botsch Consultant/Advisor II CCMR Computing Facility dwb7 at ccmr.cornell.edu ******************************** From jonny.strom at netikka.fi Tue Sep 7 19:22:34 2004 From: jonny.strom at netikka.fi (Johnny Strom) Date: Tue, 07 Sep 2004 22:22:34 +0300 Subject: Let's get moving In-Reply-To: <1094584590.9f4996067ae9e@mail.ph.utexas.edu> References: <20040902135940.29B581A851A@tornado.pdcompsys.com> <27c475ec04090207483360c3d@mail.gmail.com> <41374305.2030400@greenhydrant.com> <413746D0.3010706@umd.edu> <1094584590.9f4996067ae9e@mail.ph.utexas.edu> Message-ID: <413E0A7A.8010807@netikka.fi> Eric Rostetter wrote: > Quoting David Eisner : > > >>I think this page should be updated to include a link to the >>QaTesting Wiki document. > > > Done. > > >>Consider these an addition to the changes I >>recommended earlier: >> >>http://www.redhat.com/archives/fedora-legacy-list/2004-August/msg00118.html > > > Done, but I'm sure there is room for improvement. Submitted suggested changes > to me, or to the mailing list. > > >>-David > > Hi When is the new build server/s ready? Johnny From dom at earth.li Tue Sep 7 21:55:52 2004 From: dom at earth.li (Dominic Hargreaves) Date: Tue, 7 Sep 2004 22:55:52 +0100 Subject: Let's get moving In-Reply-To: <1094585169.823d4dc0c41f5@mail.ph.utexas.edu> References: <20040902135940.29B581A851A@tornado.pdcompsys.com> <27c475ec04090207483360c3d@mail.gmail.com> <41374305.2030400@greenhydrant.com> <20040902161531.GA26041@tirian.magd.ox.ac.uk> <1094585169.823d4dc0c41f5@mail.ph.utexas.edu> Message-ID: <20040907215552.GV26041@tirian.magd.ox.ac.uk> On Tue, Sep 07, 2004 at 02:26:09PM -0500, Eric Rostetter wrote: > Quoting Dominic Hargreaves : > > > It also needs a working infrastructure. Since we've not seen any > > packages actually be released for months I have pretty much run out of > > enthusiasm for contributing to the project. > You and many others stop contributing because no packages are being released. > Packages are not being released because of a lack of people contributing. > Catch-22, chicken and egg, self-fulfilling profacy, or what ever your other > favorite cliche is... I was referring to packages not being moved from updates-testing to updates, in particular. That's something that only Jesse can handle currently. Seeing the work I've put in sit in a limbo discourages me from continuing. It's not a direct result of lack of development, but an infrastructure problem. That's why I phrased it the way I did. Dominic. From rostetter at mail.utexas.edu Tue Sep 7 22:02:38 2004 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Tue, 7 Sep 2004 17:02:38 -0500 Subject: Let's get moving In-Reply-To: <20040907215552.GV26041@tirian.magd.ox.ac.uk> References: <20040902135940.29B581A851A@tornado.pdcompsys.com> <27c475ec04090207483360c3d@mail.gmail.com> <41374305.2030400@greenhydrant.com> <20040902161531.GA26041@tirian.magd.ox.ac.uk> <1094585169.823d4dc0c41f5@mail.ph.utexas.edu> <20040907215552.GV26041@tirian.magd.ox.ac.uk> Message-ID: <1094594558.db992eb141a49@mail.ph.utexas.edu> Quoting Dominic Hargreaves : > I was referring to packages not being moved from updates-testing to > updates, in particular. That's something that only Jesse can handle > currently. Seeing the work I've put in sit in a limbo discourages me > from continuing. It's not a direct result of lack of development, but an > infrastructure problem. That's why I phrased it the way I did. > > Dominic. My understanding, which may be wrong, is they sit in updates-testing until they get publish votes, at which time they are moved out. If that is wrong, then ignore me. If that is right, then most of the things in update-testing don't have publish votes, so it is a mute point. I do acknowledge that Jesse needs more help doing this. But if the packages never get the QA, it doesn't matter. I also acknowledge that we can't just wait for Jesse to seek out people to delegate to. People have to actively solicit the position, and prove themself worthy of the trust involved. Until that happens, Jesse has no one to delegate to. -- Eric Rostetter From dom at earth.li Tue Sep 7 22:18:03 2004 From: dom at earth.li (Dominic Hargreaves) Date: Tue, 7 Sep 2004 23:18:03 +0100 Subject: Let's get moving In-Reply-To: <1094594558.db992eb141a49@mail.ph.utexas.edu> References: <20040902135940.29B581A851A@tornado.pdcompsys.com> <27c475ec04090207483360c3d@mail.gmail.com> <41374305.2030400@greenhydrant.com> <20040902161531.GA26041@tirian.magd.ox.ac.uk> <1094585169.823d4dc0c41f5@mail.ph.utexas.edu> <20040907215552.GV26041@tirian.magd.ox.ac.uk> <1094594558.db992eb141a49@mail.ph.utexas.edu> Message-ID: <20040907221803.GW26041@tirian.magd.ox.ac.uk> On Tue, Sep 07, 2004 at 05:02:38PM -0500, Eric Rostetter wrote: > My understanding, which may be wrong, is they sit in updates-testing > until they get publish votes, at which time they are moved out. If > that is wrong, then ignore me. If that is right, then most of the > things in update-testing don't have publish votes, so it is a mute > point. There certainly seems to be confusion about the terminology used in the bug reporting system and process. I and others have been under the impression that the packages were released after two weeks if no further problems were found, as did you in <1094585037.1aa0b0d478bbb at mail.ph.utexas.edu>: "And 2 weeks is a timeout if no one votes on it." Clearly a 2 week timeout is not in place. > I also acknowledge that we can't just wait for Jesse to seek out people > to delegate to. People have to actively solicit the position, and prove > themself worthy of the trust involved. Until that happens, Jesse has > no one to delegate to. I volunteered to help with the build server when Jesse mentioned it, and I can currently only assume we should wait until it is available. Dominic. From dom at earth.li Wed Sep 8 00:34:26 2004 From: dom at earth.li (Dominic Hargreaves) Date: Wed, 8 Sep 2004 01:34:26 +0100 Subject: Roundup of work needed Message-ID: <20040908003426.GX26041@tirian.magd.ox.ac.uk> Recent discussion has thrown up some confusion on the state of the package release system (including on my part :), so here is a reminder of what needs to be done on currently pending packages. See bottom for some notes on these lists. Packages in state RESOLVED (ie exist in updates-testing) that need active work. ------------------------------------------------------------------ mailman - https://bugzilla.fedora.us/show_bug.cgi?id=1269 There were some unconfirmed reports of breakage with the candidate. This needs more QA before release. mod_python - https://bugzilla.fedora.us/show_bug.cgi?id=1325 Needs 2 VERIFY before release. ethereal - https://bugzilla.fedora.us/show_bug.cgi?id=1419 Needs 2 VERIFY before release. - but dup with 1840? tcpdump - https://bugzilla.fedora.us/show_bug.cgi?id=1468 Needs 1 VERIFY before release. kernel - https://bugzilla.fedora.us/show_bug.cgi?id=1484 Needs missing file rebuilt for verification - but preferentially put work into later kernel ticket mozilla - https://bugzilla.fedora.us/show_bug.cgi?id=1532 Needs 2 VERIFY but has been superceded lha - https://bugzilla.fedora.us/show_bug.cgi?id=1547 Needs 2 VERIFY but has been superceded cadaver - https://bugzilla.fedora.us/show_bug.cgi?id=1552 Needs 2 VERIFY before release. rsync - https://bugzilla.fedora.us/show_bug.cgi?id=1569 Needs 2 VERIFY but has been superceded. flim - https://bugzilla.fedora.us/show_bug.cgi?id=1581 Needs 2 VERIFY before release. squid - https://bugzilla.fedora.us/show_bug.cgi?id=1732 Needs 2 VERIFY before release. squirrelmail - https://bugzilla.fedora.us/show_bug.cgi?id=1733 Needs 2 VERIFY before release (also double check no new issues have cropped up) xchat - https://bugzilla.fedora.us/show_bug.cgi?id=1549 Needs 2 VERIFY before release. Packages in state UNCONFIRMED, NEW, ASSIGNED or REOPENED: -------------------------------------------------------- * yum - https://bugzilla.fedora.us/show_bug.cgi?id=1583 IMO this shouldn't be in the Package Request component close WONTFIX re rh8? vsftp - https://bugzilla.fedora.us/show_bug.cgi?id=1778 Resolution of whether we are vulnerable needed. * kernel - https://bugzilla.fedora.us/show_bug.cgi?id=1797 VM (non-security) bug in rh9 that was never fixed before EOL. Looks to me like this should be closed WONTFIX. * rpm - https://bugzilla.fedora.us/show_bug.cgi?id=1864 No rationale given for bug request - the rh bug it refers to dates from before rh7.3 EOL. WONTFIX? * readline - https://bugzilla.fedora.us/show_bug.cgi?id=2017 Another not fixed before EOL (rh9). WONTFIX? XFree86 - https://bugzilla.fedora.us/show_bug.cgi?id=1289 This has had 2 PUBLISHes for 7.3 and the only problem holding it back was likely a gdk-pixbuf red herring. Packages should be built for this and pushed to updates-testing I think. gaim - https://bugzilla.fedora.us/show_bug.cgi?id=1237 Needs new vulnerability to be investigated and fixes built. netpbm - https://bugzilla.fedora.us/show_bug.cgi?id=1257 Needs 2 PUBLISH kdelibs - https://bugzilla.fedora.us/show_bug.cgi?id=1373 Needs 2 PUBLISH (superceded?) * cal - https://bugzilla.fedora.us/show_bug.cgi?id=1439 Should be closed WONTFIX IMO yum - https://bugzilla.fedora.us/show_bug.cgi?id=1604 Needs 2 PUBLISH mod_ssl - https://bugzilla.fedora.us/show_bug.cgi?id=1708 Needs 2 PUBLISH for rh9 - superceded? mod_ssl - https://bugzilla.fedora.us/show_bug.cgi?id=1888 Needs 1 PUBLISH for rh7.3 - superceded? krb5 - https://bugzilla.fedora.us/show_bug.cgi?id=1726 Obsoleted mod_proxy - https://bugzilla.fedora.us/show_bug.cgi?id=1737 Has 2 PUBLISH, build packages for updates-testing or fix further minor non-security issues libxml - https://bugzilla.fedora.us/show_bug.cgi?id=1324 Sort out confusion over status over version in updates-testing and add RESOLVED flag. gdk-pixbuf - https://bugzilla.fedora.us/show_bug.cgi?id=1371 Packages built for updates-testing and/or a couple of formal PUBLISH needed. sysstat - https://bugzilla.fedora.us/show_bug.cgi?id=1372 Need 2 PUBLISH - 7.3 only I think mc - https://bugzilla.fedora.us/show_bug.cgi?id=1548 Need 2 PUBLISH (but superceded?) libpng - https://bugzilla.fedora.us/show_bug.cgi?id=1550 Superceded libpng - https://bugzilla.fedora.us/show_bug.cgi?id=1943 Need 2 PUBLISH tripwire - https://bugzilla.fedora.us/show_bug.cgi?id=1719 Resolve problems with how to version and build fix kernel - https://bugzilla.fedora.us/show_bug.cgi?id=1804 Need 2 PUBLISH apache - https://bugzilla.fedora.us/show_bug.cgi?id=1805 Is this redundant? XFree86 - https://bugzilla.fedora.us/show_bug.cgi?id=1831 Check how this stands with the other open XFree86 bug mysql - https://bugzilla.fedora.us/show_bug.cgi?id=1832 Needs 1 PUBLISH but superceded? lha - https://bugzilla.fedora.us/show_bug.cgi?id=1833 Verify all patches are there, and make updated SRPMs available. mozilla - https://bugzilla.fedora.us/show_bug.cgi?id=1834 Needs 2 PUBLISH ethereal - https://bugzilla.fedora.us/show_bug.cgi?id=1834 Needs PUBLISH for rh9 php - https://bugzilla.fedora.us/show_bug.cgi?id=1868 Needs PUBLISH, especially for rh7.3 abiword - https://bugzilla.fedora.us/show_bug.cgi?id=1906 Needs PUBLISH, especially for rh9 subversion - https://bugzilla.fedora.us/show_bug.cgi?id=1907 Analysis and build fixed packages samba - https://bugzilla.fedora.us/show_bug.cgi?id=1924 Needs PUBLISH, especially for rh9 gnome vfs - https://bugzilla.fedora.us/show_bug.cgi?id=1944 Needs 2 PUBLISH sox - https://bugzilla.fedora.us/show_bug.cgi?id=1945 Needs PUBLISH - rh9 status? glibc - https://bugzilla.fedora.us/show_bug.cgi?id=1947 Needs PUBLISH qt - https://bugzilla.fedora.us/show_bug.cgi?id=2002 RPM needs work rsync - https://bugzilla.fedora.us/show_bug.cgi?id=2003 Needs PUBLISH gdk-pixbuf - https://bugzilla.fedora.us/show_bug.cgi?id=2005 Analyse and see whether relevant mysql - https://bugzilla.fedora.us/show_bug.cgi?id=2006 needs work ruby - https://bugzilla.fedora.us/show_bug.cgi?id=2007 needs work kdelibs - https://bugzilla.fedora.us/show_bug.cgi?id=2008 Needs analysis mc - https://bugzilla.fedora.us/show_bug.cgi?id=2009 Needs work pam_wheel - https://bugzilla.fedora.us/show_bug.cgi?id=2010 Needs PUBLISH krb5 - https://bugzilla.fedora.us/show_bug.cgi?id=2040 Fix broken 7.3 packages, then QA mod_ssl - https://bugzilla.fedora.us/show_bug.cgi?id=2041 Needs work zlib - https://bugzilla.fedora.us/show_bug.cgi?id=2043 Needs work * kernel - https://bugzilla.fedora.us/show_bug.cgi?id=1614 close WONTFIX? Reporter gone AWOL. General (non-package bugs) -------------------------- * https://bugzilla.fedora.us/show_bug.cgi?id=1599 applies to rh8 only - WONTFIX? * https://bugzilla.fedora.us/show_bug.cgi?id=1437 applies to rh8 only - WONTFIX? * https://bugzilla.fedora.us/show_bug.cgi?id=1586 applies to rh8 only - WONTFIX? https://bugzilla.fedora.us/show_bug.cgi?id=1963 Website needs fixing https://bugzilla.fedora.us/show_bug.cgi?id=1652 Website fix? Notes ----- I marked a few duplicate bugs as CLOSED to make the RESOLVED query more useful (and less overwhelming!) but then stopped as I realised this may be not what people expect. Any opinions on this? I don't particularly see any reason to keep dups in any other state, as they by definition to not describe anything that isn't recorded elsewhere. Needs PUBLISH means that there are packages available for QA that need to be QAd at the source level. Needs VERIFY means that there are updates-testing packages that need testing. This is the easy bit, let's get this old ones out of the way ASAP. I'll endeavour to do this more often... Hopefully we can get lots of things ready for the new build server to crunch on :) * means that there is a judgement call that can be made on the bug system immediately. Please follow up onlist with opinions. Cheers, Dominic. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 232 bytes Desc: not available URL: From rostetter at mail.utexas.edu Wed Sep 8 01:51:33 2004 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Tue, 7 Sep 2004 20:51:33 -0500 Subject: Let's get moving In-Reply-To: <20040907221803.GW26041@tirian.magd.ox.ac.uk> References: <20040902135940.29B581A851A@tornado.pdcompsys.com> <27c475ec04090207483360c3d@mail.gmail.com> <41374305.2030400@greenhydrant.com> <20040902161531.GA26041@tirian.magd.ox.ac.uk> <1094585169.823d4dc0c41f5@mail.ph.utexas.edu> <20040907215552.GV26041@tirian.magd.ox.ac.uk> <1094594558.db992eb141a49@mail.ph.utexas.edu> <20040907221803.GW26041@tirian.magd.ox.ac.uk> Message-ID: <1094608293.518b629109e69@mail.ph.utexas.edu> Quoting Dominic Hargreaves : > There certainly seems to be confusion about the terminology used in the > bug reporting system and process. I and others have been under the > impression that the packages were released after two weeks if no further > problems were found I'm not under that impression. > as did you in > <1094585037.1aa0b0d478bbb at mail.ph.utexas.edu>: > > "And 2 weeks is a timeout if no one votes on it." No, that wasn't what I meant. Above that I wrote: No, IRRC. If the package has passed QA for one OS version, but not for other OS versions, then after 2 weeks all versions can be passed. This is there so that if one SRPM is built for multiple OS versions, they won't all hang up because only one OS version wasn't tested. It really only applies when the same SRPM, or at least the same patch code, was used for all of the versions. If a different patch was used for the different versions, then this probably shouldn't be applied to that case. If you look at the QA wiki page, it reads: If a similar update is available for multiple similar OS versions (e.g. for both RHL 7.2 and RHL 7.3), and has passed the publish criteria for one OS version but not for the other, the second OS version may be released after a timeout period if no one has tested it. This prevents updates from being published for one OS version due to lack of testers when it has passed on other similar OS versions and is believed to therefore be safe. Such releases are at the descretion of the Fedora Legacy package publishers. > Clearly a 2 week timeout is not in place. I don't know if that is clear. Clearly there is confusion about it, and there may be delays. But the wording above even states that "it may be released" after the 2 weeks, not that it must be released or that it must happen exactly 2 weeks later. > I volunteered to help with the build server when Jesse mentioned it, and > I can currently only assume we should wait until it is available. In my dealings with Jesse, I find it helpful to pester him repeatedly about things every few days until he gives in. :) Your milage may vary... That's how I ended up getting the web site up, CVS for the web site, etc. I think an indication of how little participation we get can be seen in the wiki. I don't think there have been any changes to the docs in there except for by myself and Jesse. > Dominic. -- Eric Rostetter From hjp+fedora-legacy at wsr.ac.at Wed Sep 8 10:06:26 2004 From: hjp+fedora-legacy at wsr.ac.at (Peter J. Holzer) Date: Wed, 8 Sep 2004 12:06:26 +0200 Subject: Let's get moving In-Reply-To: <1094581327.130bad31eaaa3@mail.ph.utexas.edu> References: <20040831155156.GC31395@domino.ccmr.cornell.edu> <1094037230.2462.12.camel@Sewak.Asr.Lan> <20040902084711.GB3948@wsr.ac.at> <20040902101250.GA6843@wsr.ac.at> <1094581327.130bad31eaaa3@mail.ph.utexas.edu> Message-ID: <20040908100626.GT15990@wsr.ac.at> On 2004-09-07 13:22:07 -0500, Eric Rostetter wrote: > Quoting "Peter J. Holzer" : > > There doesn't seem to be a bugzilla entry corresponding to it > > where I could enter a "I tested it and it seems to work" comment. Should > > such comments be directed to this list? > > Yes, they should be directed to this list, and the bugzilla entry is likely > https://bugzilla.fedora.us/show_bug.cgi?id=1468 Ah, I guess I didn't expect a bug for a package in QA to be in status RESOLVED. hp -- _ | Peter J. Holzer | Shooting the users in the foot is bad. |_|_) | Sysadmin WSR / LUGA | Giving them a gun isn't. | | | hjp at wsr.ac.at | -- Gordon Schumacher, __/ | http://www.hjp.at/ | mozilla bug #84128 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 388 bytes Desc: not available URL: From dom at earth.li Wed Sep 8 11:43:34 2004 From: dom at earth.li (Dominic Hargreaves) Date: Wed, 8 Sep 2004 12:43:34 +0100 Subject: Bugzilla owners Message-ID: <20040908114334.GY26041@tirian.magd.ox.ac.uk> Hi, Is there any reason we shouldn't set ourselves as owners of bugs if we intend to lead work on them? It would probably help drive development along and prevent bugs from being held in limbo for so long, and would let us move those bugs out of state NEW (it would be presumptious to ASSIGN them to Jesse :) Cheers, Dominic. From dom at earth.li Wed Sep 8 11:48:02 2004 From: dom at earth.li (Dominic Hargreaves) Date: Wed, 8 Sep 2004 12:48:02 +0100 Subject: Let's get moving In-Reply-To: <1094608293.518b629109e69@mail.ph.utexas.edu> References: <20040902135940.29B581A851A@tornado.pdcompsys.com> <27c475ec04090207483360c3d@mail.gmail.com> <41374305.2030400@greenhydrant.com> <20040902161531.GA26041@tirian.magd.ox.ac.uk> <1094585169.823d4dc0c41f5@mail.ph.utexas.edu> <20040907215552.GV26041@tirian.magd.ox.ac.uk> <1094594558.db992eb141a49@mail.ph.utexas.edu> <20040907221803.GW26041@tirian.magd.ox.ac.uk> <1094608293.518b629109e69@mail.ph.utexas.edu> Message-ID: <20040908114802.GZ26041@tirian.magd.ox.ac.uk> On Tue, Sep 07, 2004 at 08:51:33PM -0500, Eric Rostetter wrote: > No, that wasn't what I meant. Above that I wrote: > > No, IRRC. If the package has passed QA for one OS version, but not for > other OS versions, then after 2 weeks all versions can be passed. This > is there so that if one SRPM is built for multiple OS versions, they won't > all hang up because only one OS version wasn't tested. It really only > applies when the same SRPM, or at least the same patch code, was used for > all of the versions. If a different patch was used for the different versions, > then this probably shouldn't be applied to that case. Ah, okay, yes. That makes sense. Cheers, Dominic. From simon at nzservers.com Wed Sep 8 12:28:46 2004 From: simon at nzservers.com (Simon Weller) Date: Wed, 8 Sep 2004 07:28:46 -0500 Subject: Roundup of work needed In-Reply-To: <20040908003426.GX26041@tirian.magd.ox.ac.uk> References: <20040908003426.GX26041@tirian.magd.ox.ac.uk> Message-ID: <200409080728.46937.simon@nzservers.com> Thanks for this list Dominic, it makes it easier seeing what still needs to be done. I've posted a verify for tcpdump. - Si On Tuesday 07 September 2004 07:34 pm, Dominic Hargreaves wrote: > Recent discussion has thrown up some confusion on the state of the > package release system (including on my part :), so here is a reminder > of what needs to be done on currently pending packages. > > See bottom for some notes on these lists. > > Packages in state RESOLVED (ie exist in updates-testing) that need > active work. > ------------------------------------------------------------------ > > mailman - https://bugzilla.fedora.us/show_bug.cgi?id=1269 > There were some unconfirmed reports of breakage with the candidate. This > needs more QA before release. > > mod_python - https://bugzilla.fedora.us/show_bug.cgi?id=1325 > Needs 2 VERIFY before release. > > ethereal - https://bugzilla.fedora.us/show_bug.cgi?id=1419 > Needs 2 VERIFY before release. - but dup with 1840? > > tcpdump - https://bugzilla.fedora.us/show_bug.cgi?id=1468 > Needs 1 VERIFY before release. > > kernel - https://bugzilla.fedora.us/show_bug.cgi?id=1484 > Needs missing file rebuilt for verification - but preferentially put > work into later kernel ticket > > mozilla - https://bugzilla.fedora.us/show_bug.cgi?id=1532 > Needs 2 VERIFY but has been superceded > > lha - https://bugzilla.fedora.us/show_bug.cgi?id=1547 > Needs 2 VERIFY but has been superceded > > cadaver - https://bugzilla.fedora.us/show_bug.cgi?id=1552 > Needs 2 VERIFY before release. > > rsync - https://bugzilla.fedora.us/show_bug.cgi?id=1569 > Needs 2 VERIFY but has been superceded. > > flim - https://bugzilla.fedora.us/show_bug.cgi?id=1581 > Needs 2 VERIFY before release. > > squid - https://bugzilla.fedora.us/show_bug.cgi?id=1732 > Needs 2 VERIFY before release. > > squirrelmail - https://bugzilla.fedora.us/show_bug.cgi?id=1733 > Needs 2 VERIFY before release (also double check no new issues have > cropped up) > > xchat - https://bugzilla.fedora.us/show_bug.cgi?id=1549 > Needs 2 VERIFY before release. > > Packages in state UNCONFIRMED, NEW, ASSIGNED or REOPENED: > -------------------------------------------------------- > > * yum - https://bugzilla.fedora.us/show_bug.cgi?id=1583 > IMO this shouldn't be in the Package Request component > close WONTFIX re rh8? > > vsftp - https://bugzilla.fedora.us/show_bug.cgi?id=1778 > Resolution of whether we are vulnerable needed. > > * kernel - https://bugzilla.fedora.us/show_bug.cgi?id=1797 > VM (non-security) bug in rh9 that was never fixed before EOL. Looks to > me like this should be closed WONTFIX. > > * rpm - https://bugzilla.fedora.us/show_bug.cgi?id=1864 > No rationale given for bug request - the rh bug it refers to dates from > before rh7.3 EOL. WONTFIX? > > * readline - https://bugzilla.fedora.us/show_bug.cgi?id=2017 > Another not fixed before EOL (rh9). WONTFIX? > > XFree86 - https://bugzilla.fedora.us/show_bug.cgi?id=1289 > This has had 2 PUBLISHes for 7.3 and the only problem holding it back > was likely a gdk-pixbuf red herring. Packages should be built for this > and pushed to updates-testing I think. > > gaim - https://bugzilla.fedora.us/show_bug.cgi?id=1237 > Needs new vulnerability to be investigated and fixes built. > > netpbm - https://bugzilla.fedora.us/show_bug.cgi?id=1257 > Needs 2 PUBLISH > > kdelibs - https://bugzilla.fedora.us/show_bug.cgi?id=1373 > Needs 2 PUBLISH (superceded?) > > * cal - https://bugzilla.fedora.us/show_bug.cgi?id=1439 > Should be closed WONTFIX IMO > > yum - https://bugzilla.fedora.us/show_bug.cgi?id=1604 > Needs 2 PUBLISH > > mod_ssl - https://bugzilla.fedora.us/show_bug.cgi?id=1708 > Needs 2 PUBLISH for rh9 - superceded? > > mod_ssl - https://bugzilla.fedora.us/show_bug.cgi?id=1888 > Needs 1 PUBLISH for rh7.3 - superceded? > > krb5 - https://bugzilla.fedora.us/show_bug.cgi?id=1726 > Obsoleted > > mod_proxy - https://bugzilla.fedora.us/show_bug.cgi?id=1737 > Has 2 PUBLISH, build packages for updates-testing or fix further > minor non-security issues > > libxml - https://bugzilla.fedora.us/show_bug.cgi?id=1324 > Sort out confusion over status over version in updates-testing and add > RESOLVED flag. > > gdk-pixbuf - https://bugzilla.fedora.us/show_bug.cgi?id=1371 > Packages built for updates-testing and/or a couple of formal PUBLISH > needed. > > sysstat - https://bugzilla.fedora.us/show_bug.cgi?id=1372 > Need 2 PUBLISH - 7.3 only I think > > mc - https://bugzilla.fedora.us/show_bug.cgi?id=1548 > Need 2 PUBLISH (but superceded?) > > libpng - https://bugzilla.fedora.us/show_bug.cgi?id=1550 > Superceded > > libpng - https://bugzilla.fedora.us/show_bug.cgi?id=1943 > Need 2 PUBLISH > > tripwire - https://bugzilla.fedora.us/show_bug.cgi?id=1719 > Resolve problems with how to version and build fix > > kernel - https://bugzilla.fedora.us/show_bug.cgi?id=1804 > Need 2 PUBLISH > > apache - https://bugzilla.fedora.us/show_bug.cgi?id=1805 > Is this redundant? > > XFree86 - https://bugzilla.fedora.us/show_bug.cgi?id=1831 > Check how this stands with the other open XFree86 bug > > mysql - https://bugzilla.fedora.us/show_bug.cgi?id=1832 > Needs 1 PUBLISH but superceded? > > lha - https://bugzilla.fedora.us/show_bug.cgi?id=1833 > Verify all patches are there, and make updated SRPMs available. > > mozilla - https://bugzilla.fedora.us/show_bug.cgi?id=1834 > Needs 2 PUBLISH > > ethereal - https://bugzilla.fedora.us/show_bug.cgi?id=1834 > Needs PUBLISH for rh9 > > php - https://bugzilla.fedora.us/show_bug.cgi?id=1868 > Needs PUBLISH, especially for rh7.3 > > abiword - https://bugzilla.fedora.us/show_bug.cgi?id=1906 > Needs PUBLISH, especially for rh9 > > subversion - https://bugzilla.fedora.us/show_bug.cgi?id=1907 > Analysis and build fixed packages > > samba - https://bugzilla.fedora.us/show_bug.cgi?id=1924 > Needs PUBLISH, especially for rh9 > > gnome vfs - https://bugzilla.fedora.us/show_bug.cgi?id=1944 > Needs 2 PUBLISH > > sox - https://bugzilla.fedora.us/show_bug.cgi?id=1945 > Needs PUBLISH - rh9 status? > > glibc - https://bugzilla.fedora.us/show_bug.cgi?id=1947 > Needs PUBLISH > > qt - https://bugzilla.fedora.us/show_bug.cgi?id=2002 > RPM needs work > > rsync - https://bugzilla.fedora.us/show_bug.cgi?id=2003 > Needs PUBLISH > > gdk-pixbuf - https://bugzilla.fedora.us/show_bug.cgi?id=2005 > Analyse and see whether relevant > > mysql - https://bugzilla.fedora.us/show_bug.cgi?id=2006 > needs work > > ruby - https://bugzilla.fedora.us/show_bug.cgi?id=2007 > needs work > > kdelibs - https://bugzilla.fedora.us/show_bug.cgi?id=2008 > Needs analysis > > mc - https://bugzilla.fedora.us/show_bug.cgi?id=2009 > Needs work > > pam_wheel - https://bugzilla.fedora.us/show_bug.cgi?id=2010 > Needs PUBLISH > > krb5 - https://bugzilla.fedora.us/show_bug.cgi?id=2040 > Fix broken 7.3 packages, then QA > > mod_ssl - https://bugzilla.fedora.us/show_bug.cgi?id=2041 > Needs work > > zlib - https://bugzilla.fedora.us/show_bug.cgi?id=2043 > Needs work > > * kernel - https://bugzilla.fedora.us/show_bug.cgi?id=1614 > close WONTFIX? Reporter gone AWOL. > > General (non-package bugs) > -------------------------- > > * https://bugzilla.fedora.us/show_bug.cgi?id=1599 > applies to rh8 only - WONTFIX? > > * https://bugzilla.fedora.us/show_bug.cgi?id=1437 > applies to rh8 only - WONTFIX? > > * https://bugzilla.fedora.us/show_bug.cgi?id=1586 > applies to rh8 only - WONTFIX? > > https://bugzilla.fedora.us/show_bug.cgi?id=1963 > Website needs fixing > > https://bugzilla.fedora.us/show_bug.cgi?id=1652 > Website fix? > > > Notes > ----- > > I marked a few duplicate bugs as CLOSED to make the RESOLVED > query more useful (and less overwhelming!) but then stopped as I > realised this may be not what people expect. Any opinions on this? I > don't particularly see any reason to keep dups in any other state, as > they by definition to not describe anything that isn't recorded > elsewhere. > > Needs PUBLISH means that there are packages available for QA that need > to be QAd at the source level. > > Needs VERIFY means that there are updates-testing packages that need > testing. This is the easy bit, let's get this old ones out of the way > ASAP. > > I'll endeavour to do this more often... Hopefully we can get lots of things > ready for the new build server to crunch on :) > > * means that there is a judgement call that can be made on the bug > system immediately. Please follow up onlist with opinions. > > Cheers, > > Dominic. -- Simon Weller LPIC-2, BCIP Systems Engineer NZServers LTD http://www.nzservers.com/ U.S. Branch <- To mess up a Linux box, you need to work at it; to mess up your Windows box, you just need to work on it. - Scott Granneman, Security Focus -> From mattdm at mattdm.org Wed Sep 8 12:58:36 2004 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 8 Sep 2004 08:58:36 -0400 Subject: Let's get moving In-Reply-To: <20040908100626.GT15990@wsr.ac.at> References: <20040831155156.GC31395@domino.ccmr.cornell.edu> <1094037230.2462.12.camel@Sewak.Asr.Lan> <20040902084711.GB3948@wsr.ac.at> <20040902101250.GA6843@wsr.ac.at> <1094581327.130bad31eaaa3@mail.ph.utexas.edu> <20040908100626.GT15990@wsr.ac.at> Message-ID: <20040908125836.GA15834@jadzia.bu.edu> On Wed, Sep 08, 2004 at 12:06:26PM +0200, Peter J. Holzer wrote: > > Yes, they should be directed to this list, and the bugzilla entry is likely > > https://bugzilla.fedora.us/show_bug.cgi?id=1468 > Ah, I guess I didn't expect a bug for a package in QA to be in status > RESOLVED. Sure -- issue itself has been resolved, but that resolution needs testing. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From dwb7 at ccmr.cornell.edu Wed Sep 8 16:58:08 2004 From: dwb7 at ccmr.cornell.edu (David Botsch) Date: Wed, 8 Sep 2004 12:58:08 -0400 Subject: Let's get moving In-Reply-To: <20040908125836.GA15834@jadzia.bu.edu> References: <20040831155156.GC31395@domino.ccmr.cornell.edu> <1094037230.2462.12.camel@Sewak.Asr.Lan> <20040902084711.GB3948@wsr.ac.at> <20040902101250.GA6843@wsr.ac.at> <1094581327.130bad31eaaa3@mail.ph.utexas.edu> <20040908100626.GT15990@wsr.ac.at> <20040908125836.GA15834@jadzia.bu.edu> Message-ID: <20040908165808.GB31883@ccmr.cornell.edu> I think we may need a different status for something in update-testing, then. If a bug is marked resolved, it doesn't normally show up when on searches for LEGACY bugs (by say, clicking the link on the main FL page). To me, resolved says, everything is done. On Wed, Sep 08, 2004 at 08:58:36AM -0400, Matthew Miller wrote: > On Wed, Sep 08, 2004 at 12:06:26PM +0200, Peter J. Holzer wrote: > > > Yes, they should be directed to this list, and the bugzilla entry is likely > > > https://bugzilla.fedora.us/show_bug.cgi?id=1468 > > Ah, I guess I didn't expect a bug for a package in QA to be in status > > RESOLVED. > > Sure -- issue itself has been resolved, but that resolution needs testing. > > -- > Matthew Miller mattdm at mattdm.org > Boston University Linux ------> > > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-legacy-list -- ******************************** David William Botsch Consultant/Advisor II CCMR Computing Facility dwb7 at ccmr.cornell.edu ******************************** From simon at nzservers.com Wed Sep 8 17:05:07 2004 From: simon at nzservers.com (Simon Weller) Date: Wed, 8 Sep 2004 12:05:07 -0500 Subject: Let's get moving In-Reply-To: <20040908165808.GB31883@ccmr.cornell.edu> References: <20040831155156.GC31395@domino.ccmr.cornell.edu> <20040908125836.GA15834@jadzia.bu.edu> <20040908165808.GB31883@ccmr.cornell.edu> Message-ID: <200409081205.07351.simon@nzservers.com> On Wednesday 08 September 2004 11:58 am, David Botsch wrote: > I think we may need a different status for something in update-testing, > then. If a bug is marked resolved, it doesn't normally show up when on > searches for LEGACY bugs (by say, clicking the link on the main FL page). > > To me, resolved says, everything is done. > I agree, it would make life a lot easier. - Si -- Simon Weller LPIC-2, BCIP Systems Engineer NZServers LTD http://www.nzservers.com/ U.S. Branch <- To mess up a Linux box, you need to work at it; to mess up your Windows box, you just need to work on it. - Scott Granneman, Security Focus -> From dom at earth.li Wed Sep 8 17:07:06 2004 From: dom at earth.li (Dominic Hargreaves) Date: Wed, 8 Sep 2004 18:07:06 +0100 Subject: Let's get moving In-Reply-To: <200409081205.07351.simon@nzservers.com> References: <20040831155156.GC31395@domino.ccmr.cornell.edu> <20040908125836.GA15834@jadzia.bu.edu> <20040908165808.GB31883@ccmr.cornell.edu> <200409081205.07351.simon@nzservers.com> Message-ID: <20040908170706.GA26041@tirian.magd.ox.ac.uk> On Wed, Sep 08, 2004 at 12:05:07PM -0500, Simon Weller wrote: > On Wednesday 08 September 2004 11:58 am, David Botsch wrote: > > I think we may need a different status for something in update-testing, > > then. If a bug is marked resolved, it doesn't normally show up when on > > searches for LEGACY bugs (by say, clicking the link on the main FL page). > > > > To me, resolved says, everything is done. > > > I agree, it would make life a lot easier. Hi, RESOLVED PENDING means precisely that. It's not obvious but once you know it perfectly satisfactory. I don't see the benefit of introducing another status. Cheers, Dominic. From simon at nzservers.com Wed Sep 8 17:26:24 2004 From: simon at nzservers.com (Simon Weller) Date: Wed, 8 Sep 2004 12:26:24 -0500 Subject: Let's get moving In-Reply-To: <20040908170706.GA26041@tirian.magd.ox.ac.uk> References: <20040831155156.GC31395@domino.ccmr.cornell.edu> <200409081205.07351.simon@nzservers.com> <20040908170706.GA26041@tirian.magd.ox.ac.uk> Message-ID: <200409081226.24631.simon@nzservers.com> On Wednesday 08 September 2004 12:07 pm, Dominic Hargreaves wrote: > On Wed, Sep 08, 2004 at 12:05:07PM -0500, Simon Weller wrote: > > On Wednesday 08 September 2004 11:58 am, David Botsch wrote: > > > I think we may need a different status for something in update-testing, > > > then. If a bug is marked resolved, it doesn't normally show up when on > > > searches for LEGACY bugs (by say, clicking the link on the main FL > > > page). > > > > > > To me, resolved says, everything is done. > > > > I agree, it would make life a lot easier. > > Hi, > > RESOLVED PENDING means precisely that. It's not obvious but once you > know it perfectly satisfactory. I don't see the benefit of introducing > another status. > > Cheers, > > Dominic. > well now we know ;-) - Sk > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-legacy-list -- Simon Weller LPIC-2, BCIP Systems Engineer NZServers LTD http://www.nzservers.com/ U.S. Branch <- To mess up a Linux box, you need to work at it; to mess up your Windows box, you just need to work on it. - Scott Granneman, Security Focus -> From rostetter at mail.utexas.edu Wed Sep 8 18:20:38 2004 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Wed, 8 Sep 2004 13:20:38 -0500 Subject: Let's get moving In-Reply-To: <20040908165808.GB31883@ccmr.cornell.edu> References: <20040831155156.GC31395@domino.ccmr.cornell.edu> <1094037230.2462.12.camel@Sewak.Asr.Lan> <20040902084711.GB3948@wsr.ac.at> <20040902101250.GA6843@wsr.ac.at> <1094581327.130bad31eaaa3@mail.ph.utexas.edu> <20040908100626.GT15990@wsr.ac.at> <20040908125836.GA15834@jadzia.bu.edu> <20040908165808.GB31883@ccmr.cornell.edu> Message-ID: <1094667638.b7d4cd84a4669@mail.ph.utexas.edu> Quoting David Botsch : > I think we may need a different status for something in update-testing, then. Not a bad idea. > If a bug is marked resolved, it doesn't normally show up when on searches for > LEGACY bugs (by say, clicking the link on the main FL page). What? Yes, resolved issues still show up when you click on that link. > To me, resolved says, everything is done. That would be "closed" instead of resolved, no? -- Eric Rostetter From ckelley at ibnads.com Wed Sep 8 19:28:30 2004 From: ckelley at ibnads.com (Craig Kelley) Date: Wed, 08 Sep 2004 13:28:30 -0600 Subject: Roundup of work needed In-Reply-To: <20040908003426.GX26041@tirian.magd.ox.ac.uk> References: <20040908003426.GX26041@tirian.magd.ox.ac.uk> Message-ID: <413F5D5E.5000209@ibnads.com> Dominic Hargreaves wrote: >I marked a few duplicate bugs as CLOSED to make the RESOLVED >query more useful (and less overwhelming!) but then stopped as I >realised this may be not what people expect. Any opinions on this? > Sounds like a good idea to me. >I'll endeavour to do this more often... Hopefully we can get lots of things >ready for the new build server to crunch on :) > > This is excellent, thanks a ton! -- Craig Kelley In-Store Broadcasting Network -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 256 bytes Desc: OpenPGP digital signature URL: From david at daku.org Wed Sep 8 19:41:49 2004 From: david at daku.org (david) Date: Wed, 08 Sep 2004 12:41:49 -0700 Subject: Roundup of work needed In-Reply-To: <413F5D5E.5000209@ibnads.com> References: <20040908003426.GX26041@tirian.magd.ox.ac.uk> <413F5D5E.5000209@ibnads.com> Message-ID: <6.1.2.0.2.20040908123922.03d476e0@telford.daku.org> At 12:28 PM 9/8/2004, you wrote: >Dominic Hargreaves wrote: >> >>I marked a few duplicate bugs as CLOSED to make the RESOLVED >>query more useful (and less overwhelming!) but then stopped as I >>realised this may be not what people expect. Any opinions on this? >Sounds like a good idea to me. > >> >>I'll endeavour to do this more often... Hopefully we can get lots of things >>ready for the new build server to crunch on :) >> >This is excellent, thanks a ton! > >-- Back in the company I used to work for, there was a special status for duplicates, with a link to the master copy. The status would say: DUPLICATE see xxxxxxx and one would therefore know to look at the master copy for current status. Furthermore, duplicate bugs didn't show up as "outstanding" or "pending" or "closed". If the bug recording software doesn't provide for such, perhaps it could be added? David From mattdm at mattdm.org Wed Sep 8 17:42:01 2004 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 8 Sep 2004 13:42:01 -0400 Subject: Let's get moving In-Reply-To: <20040908165808.GB31883@ccmr.cornell.edu> References: <20040831155156.GC31395@domino.ccmr.cornell.edu> <1094037230.2462.12.camel@Sewak.Asr.Lan> <20040902084711.GB3948@wsr.ac.at> <20040902101250.GA6843@wsr.ac.at> <1094581327.130bad31eaaa3@mail.ph.utexas.edu> <20040908100626.GT15990@wsr.ac.at> <20040908125836.GA15834@jadzia.bu.edu> <20040908165808.GB31883@ccmr.cornell.edu> Message-ID: <20040908174201.GA25950@jadzia.bu.edu> On Wed, Sep 08, 2004 at 12:58:08PM -0400, David Botsch wrote: > I think we may need a different status for something in update-testing, then. > If a bug is marked resolved, it doesn't normally show up when on searches for > LEGACY bugs (by say, clicking the link on the main FL page). > To me, resolved says, everything is done. Yeah, it's a little strange, but it's standard bugzilla terminology. Changing it just makes things *more* confusing. A better approach would be simply to change what's included in the default searches. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From dom at earth.li Wed Sep 8 20:24:38 2004 From: dom at earth.li (Dominic Hargreaves) Date: Wed, 8 Sep 2004 21:24:38 +0100 Subject: Roundup of work needed In-Reply-To: <6.1.2.0.2.20040908123922.03d476e0@telford.daku.org> References: <20040908003426.GX26041@tirian.magd.ox.ac.uk> <413F5D5E.5000209@ibnads.com> <6.1.2.0.2.20040908123922.03d476e0@telford.daku.org> Message-ID: <20040908202438.GB26041@tirian.magd.ox.ac.uk> On Wed, Sep 08, 2004 at 12:41:49PM -0700, david wrote: > Back in the company I used to work for, there was a special status for > duplicates, with a link to the master copy. The status would say: > DUPLICATE see xxxxxxx > and one would therefore know to look at the master copy for current > status. Furthermore, duplicate bugs didn't show up as "outstanding" or > "pending" or "closed". > > If the bug recording software doesn't provide for such, perhaps it could be > added? We've discussed changing bugzilla before, and I think the consensus was that it was too involved (Jesse tried to get some categories added a while back and didn't get anywhere, IIRC). Dominic. From simon at nzservers.com Wed Sep 8 20:32:51 2004 From: simon at nzservers.com (Simon Weller) Date: Wed, 8 Sep 2004 15:32:51 -0500 Subject: Roundup of work needed In-Reply-To: <20040908202438.GB26041@tirian.magd.ox.ac.uk> References: <20040908003426.GX26041@tirian.magd.ox.ac.uk> <6.1.2.0.2.20040908123922.03d476e0@telford.daku.org> <20040908202438.GB26041@tirian.magd.ox.ac.uk> Message-ID: <200409081532.51271.simon@nzservers.com> We could of course just run our own bugzilla or a mantis install...is there any reason we need to utilize the fedora one? - Si On Wednesday 08 September 2004 03:24 pm, Dominic Hargreaves wrote: > On Wed, Sep 08, 2004 at 12:41:49PM -0700, david wrote: > > Back in the company I used to work for, there was a special status for > > duplicates, with a link to the master copy. The status would say: > > DUPLICATE see xxxxxxx > > and one would therefore know to look at the master copy for current > > status. Furthermore, duplicate bugs didn't show up as "outstanding" or > > "pending" or "closed". > > > > If the bug recording software doesn't provide for such, perhaps it could > > be added? > > We've discussed changing bugzilla before, and I think the consensus was > that it was too involved (Jesse tried to get some categories added a > while back and didn't get anywhere, IIRC). > > Dominic. > > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-legacy-list -- Simon Weller LPIC-2, BCIP Systems Engineer NZServers LTD http://www.nzservers.com/ U.S. Branch <- To mess up a Linux box, you need to work at it; to mess up your Windows box, you just need to work on it. - Scott Granneman, Security Focus -> From marcdeslauriers at videotron.ca Wed Sep 8 21:01:08 2004 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Wed, 08 Sep 2004 17:01:08 -0400 Subject: Roundup of work needed In-Reply-To: <20040908003426.GX26041@tirian.magd.ox.ac.uk> References: <20040908003426.GX26041@tirian.magd.ox.ac.uk> Message-ID: <1094677268.14083.2.camel@mdlinux> On Tue, 2004-09-07 at 20:34, Dominic Hargreaves wrote: > gaim - https://bugzilla.fedora.us/show_bug.cgi?id=1237 > Needs new vulnerability to be investigated and fixes built. > > lha - https://bugzilla.fedora.us/show_bug.cgi?id=1833 > Verify all patches are there, and make updated SRPMs available. > New packages are now available to QA for 7.3 and 9 for both of these issues. Marc. From dom at earth.li Thu Sep 9 01:17:46 2004 From: dom at earth.li (Dominic Hargreaves) Date: Thu, 9 Sep 2004 02:17:46 +0100 Subject: Round-up, 2004-09-09 Message-ID: <20040909011746.GC26041@tirian.magd.ox.ac.uk> (Posting this again to let people know of the URL - I'll try and post regularly, but not this regularly, hereafter) $Id: issues.txt,v 1.8 2004/09/08 23:38:03 dom Exp $ See bottom for changes This list is also available at http://www-astro.physics.ox.ac.uk/~dom/legacy/issues.txt Packages that have been verified and should be fully released ------------------------------------------------------------- tcpdump - https://bugzilla.fedora.us/show_bug.cgi?id=1468 Packages in state RESOLVED (ie exist in updates-testing) that need active work. ------------------------------------------------------------------ mailman - https://bugzilla.fedora.us/show_bug.cgi?id=1269 There were some unconfirmed reports of breakage with the candidate. This needs more QA before release. mod_python - https://bugzilla.fedora.us/show_bug.cgi?id=1325 Needs 2 VERIFY before release. ethereal - https://bugzilla.fedora.us/show_bug.cgi?id=1419 Needs 2 VERIFY before release. - but dup with 1840? kernel - https://bugzilla.fedora.us/show_bug.cgi?id=1484 Needs missing file rebuilt for verification - but preferentially put work into later kernel ticket mozilla - https://bugzilla.fedora.us/show_bug.cgi?id=1532 Needs 2 VERIFY but has been superceded lha - https://bugzilla.fedora.us/show_bug.cgi?id=1547 Needs 2 VERIFY but has been superceded cadaver - https://bugzilla.fedora.us/show_bug.cgi?id=1552 Needs 1 VERIFY before release. rsync - https://bugzilla.fedora.us/show_bug.cgi?id=1569 Needs 2 VERIFY but has been superceded. flim - https://bugzilla.fedora.us/show_bug.cgi?id=1581 Needs 1 VERIFY before release. squid - https://bugzilla.fedora.us/show_bug.cgi?id=1732 Needs 1 VERIFY before release (but about to be superceded?) squirrelmail - https://bugzilla.fedora.us/show_bug.cgi?id=1733 Needs 2 VERIFY before release (also double check no new issues have cropped up) xchat - https://bugzilla.fedora.us/show_bug.cgi?id=1549 Needs 2 VERIFY before release. Packages in state UNCONFIRMED, NEW, ASSIGNED or REOPENED: -------------------------------------------------------- * yum - https://bugzilla.fedora.us/show_bug.cgi?id=1583 IMO this shouldn't be in the Package Request component close WONTFIX re rh8? vsftp - https://bugzilla.fedora.us/show_bug.cgi?id=1778 Resolution of whether we are vulnerable needed. * kernel - https://bugzilla.fedora.us/show_bug.cgi?id=1797 VM (non-security) bug in rh9 that was never fixed before EOL. Looks to me like this should be closed WONTFIX. * rpm - https://bugzilla.fedora.us/show_bug.cgi?id=1864 No rationale given for bug request - the rh bug it refers to dates from before rh7.3 EOL. WONTFIX? * readline - https://bugzilla.fedora.us/show_bug.cgi?id=2017 Another not fixed before EOL (rh9). WONTFIX? XFree86 - https://bugzilla.fedora.us/show_bug.cgi?id=1289 This has had 2 PUBLISHes for 7.3 and the only problem holding it back was likely a gdk-pixbuf red herring. Packages should be built for this and pushed to updates-testing I think. gaim - https://bugzilla.fedora.us/show_bug.cgi?id=1237 Needs 2 PUBLISH netpbm - https://bugzilla.fedora.us/show_bug.cgi?id=1257 Needs 2 PUBLISH kdelibs - https://bugzilla.fedora.us/show_bug.cgi?id=1373 Needs 2 PUBLISH (superceded?) * cal - https://bugzilla.fedora.us/show_bug.cgi?id=1439 Should be closed WONTFIX IMO yum - https://bugzilla.fedora.us/show_bug.cgi?id=1604 Needs 2 PUBLISH mod_ssl - https://bugzilla.fedora.us/show_bug.cgi?id=1708 Needs 2 PUBLISH for rh9 - superceded? mod_ssl - https://bugzilla.fedora.us/show_bug.cgi?id=1888 Needs 1 PUBLISH for rh7.3 - superceded? krb5 - https://bugzilla.fedora.us/show_bug.cgi?id=1726 Obsoleted mod_proxy - https://bugzilla.fedora.us/show_bug.cgi?id=1737 Has 2 PUBLISH, build packages for updates-testing or fix further minor non-security issues libxml - https://bugzilla.fedora.us/show_bug.cgi?id=1324 Sort out confusion over status over version in updates-testing and add RESOLVED flag. gdk-pixbuf - https://bugzilla.fedora.us/show_bug.cgi?id=1371 Packages built for updates-testing and/or a couple of formal PUBLISH needed. sysstat - https://bugzilla.fedora.us/show_bug.cgi?id=1372 Need 2 PUBLISH - 7.3 only I think mc - https://bugzilla.fedora.us/show_bug.cgi?id=1548 Need 2 PUBLISH (but superceded?) libpng - https://bugzilla.fedora.us/show_bug.cgi?id=1550 Superceded libpng - https://bugzilla.fedora.us/show_bug.cgi?id=1943 Need 2 PUBLISH tripwire - https://bugzilla.fedora.us/show_bug.cgi?id=1719 Resolve problems with how to version and build fix kernel - https://bugzilla.fedora.us/show_bug.cgi?id=1804 Need 2 PUBLISH apache - https://bugzilla.fedora.us/show_bug.cgi?id=1805 Is this redundant? XFree86 - https://bugzilla.fedora.us/show_bug.cgi?id=1831 Check how this stands with the other open XFree86 bug mysql - https://bugzilla.fedora.us/show_bug.cgi?id=1832 Needs 1 PUBLISH but superceded? lha - https://bugzilla.fedora.us/show_bug.cgi?id=1833 Needs 2 PUBLISH mozilla - https://bugzilla.fedora.us/show_bug.cgi?id=1834 Needs 2 PUBLISH ethereal - https://bugzilla.fedora.us/show_bug.cgi?id=1840 Needs PUBLISH for rh9 php - https://bugzilla.fedora.us/show_bug.cgi?id=1868 Needs PUBLISH, especially for rh7.3 abiword - https://bugzilla.fedora.us/show_bug.cgi?id=1906 Needs PUBLISH, especially for rh9 subversion - https://bugzilla.fedora.us/show_bug.cgi?id=1907 Analysis and build fixed packages samba - https://bugzilla.fedora.us/show_bug.cgi?id=1924 Needs PUBLISH, especially for rh9 gnome vfs - https://bugzilla.fedora.us/show_bug.cgi?id=1944 Needs 2 PUBLISH sox - https://bugzilla.fedora.us/show_bug.cgi?id=1945 Needs PUBLISH - rh9 status? glibc - https://bugzilla.fedora.us/show_bug.cgi?id=1947 Needs PUBLISH qt - https://bugzilla.fedora.us/show_bug.cgi?id=2002 RPM needs work rsync - https://bugzilla.fedora.us/show_bug.cgi?id=2003 Needs PUBLISH gdk-pixbuf - https://bugzilla.fedora.us/show_bug.cgi?id=2005 Analyse and see whether relevant mysql - https://bugzilla.fedora.us/show_bug.cgi?id=2006 needs work ruby - https://bugzilla.fedora.us/show_bug.cgi?id=2007 needs work kdelibs - https://bugzilla.fedora.us/show_bug.cgi?id=2008 Needs analysis mc - https://bugzilla.fedora.us/show_bug.cgi?id=2009 Needs work pam_wheel - https://bugzilla.fedora.us/show_bug.cgi?id=2010 Needs PUBLISH krb5 - https://bugzilla.fedora.us/show_bug.cgi?id=2040 Fix broken 7.3 packages, then QA mod_ssl - https://bugzilla.fedora.us/show_bug.cgi?id=2041 Needs work zlib - https://bugzilla.fedora.us/show_bug.cgi?id=2043 Needs work * kernel - https://bugzilla.fedora.us/show_bug.cgi?id=1614 close WONTFIX? Reporter gone AWOL. imlib - https://bugzilla.fedora.us/show_bug.cgi?id=2051 Prepare packages. ImageMagick - https://bugzilla.fedora.us/show_bug.cgi?id=2052 Prepare packages. squid - https://bugzilla.fedora.us/show_bug.cgi?id=2053 Prepare packages. General (non-package bugs) -------------------------- * https://bugzilla.fedora.us/show_bug.cgi?id=1599 applies to rh8 only - WONTFIX? * https://bugzilla.fedora.us/show_bug.cgi?id=1437 applies to rh8 only - WONTFIX? * https://bugzilla.fedora.us/show_bug.cgi?id=1586 applies to rh8 only - WONTFIX? https://bugzilla.fedora.us/show_bug.cgi?id=1963 Website needs fixing https://bugzilla.fedora.us/show_bug.cgi?id=1652 Website fix? Notes ----- Needs PUBLISH means that there are packages available for QA that need to be QAd at the source level. Needs VERIFY means that there are updates-testing packages that need testing. This is the easy bit, let's get this old ones out of the way ASAP. * means that there is a judgement call that can be made on the bug system immediately. Please follow up onlist with opinions. Changes ------- $Log: issues.txt,v $ Revision 1.8 2004/09/08 23:38:03 dom move tcpdump to release pile update cadaver, flim, squid add imlib, imagemagick, squid Revision 1.7 2004/09/08 22:58:17 dom new lha packages Revision 1.6 2004/09/08 16:46:13 dom gaim -> need publish, fix broken ethereal URL Revision 1.5 2004/09/08 12:42:32 dom tcpdump needs rh9 verify Revision 1.4 2004/09/08 11:50:55 dom no changes Revision 1.2 2004/09/08 01:23:41 dom add tags From jimpop at yahoo.com Thu Sep 9 02:13:44 2004 From: jimpop at yahoo.com (Jim Popovitch) Date: Wed, 08 Sep 2004 22:13:44 -0400 Subject: Round-up, 2004-09-09 In-Reply-To: <20040909011746.GC26041@tirian.magd.ox.ac.uk> References: <20040909011746.GC26041@tirian.magd.ox.ac.uk> Message-ID: <1094696024.14225.3.camel@blue> OK, so I've started looking at some of these packages, what is the procedure to close them? For instance, the rsync package (bug 1569) looks to be resolved and confirmed. I see that it has made it's way to updates-testing... how does it get from there to updates? -Jim P. On Wed, 2004-09-08 at 21:17, Dominic Hargreaves wrote: > (Posting this again to let people know of the URL - I'll try and post > regularly, but not this regularly, hereafter) > > $Id: issues.txt,v 1.8 2004/09/08 23:38:03 dom Exp $ > > See bottom for changes > > This list is also available at > http://www-astro.physics.ox.ac.uk/~dom/legacy/issues.txt > > Packages that have been verified and should be fully released > ------------------------------------------------------------- > > tcpdump - https://bugzilla.fedora.us/show_bug.cgi?id=1468 > > > Packages in state RESOLVED (ie exist in updates-testing) that need > active work. > ------------------------------------------------------------------ > > mailman - https://bugzilla.fedora.us/show_bug.cgi?id=1269 > There were some unconfirmed reports of breakage with the candidate. This > needs more QA before release. > > mod_python - https://bugzilla.fedora.us/show_bug.cgi?id=1325 > Needs 2 VERIFY before release. > > ethereal - https://bugzilla.fedora.us/show_bug.cgi?id=1419 > Needs 2 VERIFY before release. - but dup with 1840? > > kernel - https://bugzilla.fedora.us/show_bug.cgi?id=1484 > Needs missing file rebuilt for verification - but preferentially put > work into later kernel ticket > > mozilla - https://bugzilla.fedora.us/show_bug.cgi?id=1532 > Needs 2 VERIFY but has been superceded > > lha - https://bugzilla.fedora.us/show_bug.cgi?id=1547 > Needs 2 VERIFY but has been superceded > > cadaver - https://bugzilla.fedora.us/show_bug.cgi?id=1552 > Needs 1 VERIFY before release. > > rsync - https://bugzilla.fedora.us/show_bug.cgi?id=1569 > Needs 2 VERIFY but has been superceded. > > flim - https://bugzilla.fedora.us/show_bug.cgi?id=1581 > Needs 1 VERIFY before release. > > squid - https://bugzilla.fedora.us/show_bug.cgi?id=1732 > Needs 1 VERIFY before release (but about to be superceded?) > > squirrelmail - https://bugzilla.fedora.us/show_bug.cgi?id=1733 > Needs 2 VERIFY before release (also double check no new issues have > cropped up) > > xchat - https://bugzilla.fedora.us/show_bug.cgi?id=1549 > Needs 2 VERIFY before release. > > Packages in state UNCONFIRMED, NEW, ASSIGNED or REOPENED: > -------------------------------------------------------- > > * yum - https://bugzilla.fedora.us/show_bug.cgi?id=1583 > IMO this shouldn't be in the Package Request component > close WONTFIX re rh8? > > vsftp - https://bugzilla.fedora.us/show_bug.cgi?id=1778 > Resolution of whether we are vulnerable needed. > > * kernel - https://bugzilla.fedora.us/show_bug.cgi?id=1797 > VM (non-security) bug in rh9 that was never fixed before EOL. Looks to > me like this should be closed WONTFIX. > > * rpm - https://bugzilla.fedora.us/show_bug.cgi?id=1864 > No rationale given for bug request - the rh bug it refers to dates from > before rh7.3 EOL. WONTFIX? > > * readline - https://bugzilla.fedora.us/show_bug.cgi?id=2017 > Another not fixed before EOL (rh9). WONTFIX? > > XFree86 - https://bugzilla.fedora.us/show_bug.cgi?id=1289 > This has had 2 PUBLISHes for 7.3 and the only problem holding it back > was likely a gdk-pixbuf red herring. Packages should be built for this > and pushed to updates-testing I think. > > gaim - https://bugzilla.fedora.us/show_bug.cgi?id=1237 > Needs 2 PUBLISH > > netpbm - https://bugzilla.fedora.us/show_bug.cgi?id=1257 > Needs 2 PUBLISH > > kdelibs - https://bugzilla.fedora.us/show_bug.cgi?id=1373 > Needs 2 PUBLISH (superceded?) > > * cal - https://bugzilla.fedora.us/show_bug.cgi?id=1439 > Should be closed WONTFIX IMO > > yum - https://bugzilla.fedora.us/show_bug.cgi?id=1604 > Needs 2 PUBLISH > > mod_ssl - https://bugzilla.fedora.us/show_bug.cgi?id=1708 > Needs 2 PUBLISH for rh9 - superceded? > > mod_ssl - https://bugzilla.fedora.us/show_bug.cgi?id=1888 > Needs 1 PUBLISH for rh7.3 - superceded? > > krb5 - https://bugzilla.fedora.us/show_bug.cgi?id=1726 > Obsoleted > > mod_proxy - https://bugzilla.fedora.us/show_bug.cgi?id=1737 > Has 2 PUBLISH, build packages for updates-testing or fix further > minor non-security issues > > libxml - https://bugzilla.fedora.us/show_bug.cgi?id=1324 > Sort out confusion over status over version in updates-testing and add > RESOLVED flag. > > gdk-pixbuf - https://bugzilla.fedora.us/show_bug.cgi?id=1371 > Packages built for updates-testing and/or a couple of formal PUBLISH > needed. > > sysstat - https://bugzilla.fedora.us/show_bug.cgi?id=1372 > Need 2 PUBLISH - 7.3 only I think > > mc - https://bugzilla.fedora.us/show_bug.cgi?id=1548 > Need 2 PUBLISH (but superceded?) > > libpng - https://bugzilla.fedora.us/show_bug.cgi?id=1550 > Superceded > > libpng - https://bugzilla.fedora.us/show_bug.cgi?id=1943 > Need 2 PUBLISH > > tripwire - https://bugzilla.fedora.us/show_bug.cgi?id=1719 > Resolve problems with how to version and build fix > > kernel - https://bugzilla.fedora.us/show_bug.cgi?id=1804 > Need 2 PUBLISH > > apache - https://bugzilla.fedora.us/show_bug.cgi?id=1805 > Is this redundant? > > XFree86 - https://bugzilla.fedora.us/show_bug.cgi?id=1831 > Check how this stands with the other open XFree86 bug > > mysql - https://bugzilla.fedora.us/show_bug.cgi?id=1832 > Needs 1 PUBLISH but superceded? > > lha - https://bugzilla.fedora.us/show_bug.cgi?id=1833 > Needs 2 PUBLISH > > mozilla - https://bugzilla.fedora.us/show_bug.cgi?id=1834 > Needs 2 PUBLISH > > ethereal - https://bugzilla.fedora.us/show_bug.cgi?id=1840 > Needs PUBLISH for rh9 > > php - https://bugzilla.fedora.us/show_bug.cgi?id=1868 > Needs PUBLISH, especially for rh7.3 > > abiword - https://bugzilla.fedora.us/show_bug.cgi?id=1906 > Needs PUBLISH, especially for rh9 > > subversion - https://bugzilla.fedora.us/show_bug.cgi?id=1907 > Analysis and build fixed packages > > samba - https://bugzilla.fedora.us/show_bug.cgi?id=1924 > Needs PUBLISH, especially for rh9 > > gnome vfs - https://bugzilla.fedora.us/show_bug.cgi?id=1944 > Needs 2 PUBLISH > > sox - https://bugzilla.fedora.us/show_bug.cgi?id=1945 > Needs PUBLISH - rh9 status? > > glibc - https://bugzilla.fedora.us/show_bug.cgi?id=1947 > Needs PUBLISH > > qt - https://bugzilla.fedora.us/show_bug.cgi?id=2002 > RPM needs work > > rsync - https://bugzilla.fedora.us/show_bug.cgi?id=2003 > Needs PUBLISH > > gdk-pixbuf - https://bugzilla.fedora.us/show_bug.cgi?id=2005 > Analyse and see whether relevant > > mysql - https://bugzilla.fedora.us/show_bug.cgi?id=2006 > needs work > > ruby - https://bugzilla.fedora.us/show_bug.cgi?id=2007 > needs work > > kdelibs - https://bugzilla.fedora.us/show_bug.cgi?id=2008 > Needs analysis > > mc - https://bugzilla.fedora.us/show_bug.cgi?id=2009 > Needs work > > pam_wheel - https://bugzilla.fedora.us/show_bug.cgi?id=2010 > Needs PUBLISH > > krb5 - https://bugzilla.fedora.us/show_bug.cgi?id=2040 > Fix broken 7.3 packages, then QA > > mod_ssl - https://bugzilla.fedora.us/show_bug.cgi?id=2041 > Needs work > > zlib - https://bugzilla.fedora.us/show_bug.cgi?id=2043 > Needs work > > * kernel - https://bugzilla.fedora.us/show_bug.cgi?id=1614 > close WONTFIX? Reporter gone AWOL. > > imlib - https://bugzilla.fedora.us/show_bug.cgi?id=2051 > Prepare packages. > > ImageMagick - https://bugzilla.fedora.us/show_bug.cgi?id=2052 > Prepare packages. > > squid - https://bugzilla.fedora.us/show_bug.cgi?id=2053 > Prepare packages. > > General (non-package bugs) > -------------------------- > > * https://bugzilla.fedora.us/show_bug.cgi?id=1599 > applies to rh8 only - WONTFIX? > > * https://bugzilla.fedora.us/show_bug.cgi?id=1437 > applies to rh8 only - WONTFIX? > > * https://bugzilla.fedora.us/show_bug.cgi?id=1586 > applies to rh8 only - WONTFIX? > > https://bugzilla.fedora.us/show_bug.cgi?id=1963 > Website needs fixing > > https://bugzilla.fedora.us/show_bug.cgi?id=1652 > Website fix? > > > Notes > ----- > > Needs PUBLISH means that there are packages available for QA that need > to be QAd at the source level. > > Needs VERIFY means that there are updates-testing packages that need > testing. This is the easy bit, let's get this old ones out of the way > ASAP. > > * means that there is a judgement call that can be made on the bug > system immediately. Please follow up onlist with opinions. > > Changes > ------- > > $Log: issues.txt,v $ > Revision 1.8 2004/09/08 23:38:03 dom > move tcpdump to release pile > update cadaver, flim, squid > add imlib, imagemagick, squid > > Revision 1.7 2004/09/08 22:58:17 dom > new lha packages > > Revision 1.6 2004/09/08 16:46:13 dom > gaim -> need publish, fix broken ethereal URL > > Revision 1.5 2004/09/08 12:42:32 dom > tcpdump needs rh9 verify > > Revision 1.4 2004/09/08 11:50:55 dom > no changes > > Revision 1.2 2004/09/08 01:23:41 dom > add tags > > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-legacy-list From jonny.strom at netikka.fi Thu Sep 9 05:41:38 2004 From: jonny.strom at netikka.fi (Johnny Strom) Date: Thu, 09 Sep 2004 08:41:38 +0300 Subject: Round-up, 2004-09-09 In-Reply-To: <1094696024.14225.3.camel@blue> References: <20040909011746.GC26041@tirian.magd.ox.ac.uk> <1094696024.14225.3.camel@blue> Message-ID: <413FED12.9000002@netikka.fi> Jim Popovitch wrote: > OK, so I've started looking at some of these packages, what is the > procedure to close them? Good we need more ppl that can do that so all want's to help now is the time to go trough the list and QA packages. The prcedure is to have 2 ppl that have tested a package and voted for publish, then a relase manager can put that package in update testing. List is here: http://www-astro.physics.ox.ac.uk/~dom/legacy/issues.txt For instance, the rsync package (bug 1569) > looks to be resolved and confirmed. I see that it has made it's way to > updates-testing... how does it get from there to updates? If a package is in testing then a person who has rights to make a relase will close the bug after 2 weeks in testing if no one have complained about problems during that time. So the more ppl who can do QA and put feedback into bugzilla the faster we can get the packages out. Jesse when is the 'public' build server ready? Cheers Johnny > > -Jim P. > > On Wed, 2004-09-08 at 21:17, Dominic Hargreaves wrote: > >>(Posting this again to let people know of the URL - I'll try and post >>regularly, but not this regularly, hereafter) >> >>$Id: issues.txt,v 1.8 2004/09/08 23:38:03 dom Exp $ >> >>See bottom for changes >> >>This list is also available at >>http://www-astro.physics.ox.ac.uk/~dom/legacy/issues.txt >> >>Packages that have been verified and should be fully released >>------------------------------------------------------------- >> >>tcpdump - https://bugzilla.fedora.us/show_bug.cgi?id=1468 >> >> >>Packages in state RESOLVED (ie exist in updates-testing) that need >>active work. >>------------------------------------------------------------------ >> >>mailman - https://bugzilla.fedora.us/show_bug.cgi?id=1269 >>There were some unconfirmed reports of breakage with the candidate. This >>needs more QA before release. >> >>mod_python - https://bugzilla.fedora.us/show_bug.cgi?id=1325 >>Needs 2 VERIFY before release. >> >>ethereal - https://bugzilla.fedora.us/show_bug.cgi?id=1419 >>Needs 2 VERIFY before release. - but dup with 1840? >> >>kernel - https://bugzilla.fedora.us/show_bug.cgi?id=1484 >>Needs missing file rebuilt for verification - but preferentially put >>work into later kernel ticket >> >>mozilla - https://bugzilla.fedora.us/show_bug.cgi?id=1532 >>Needs 2 VERIFY but has been superceded >> >>lha - https://bugzilla.fedora.us/show_bug.cgi?id=1547 >>Needs 2 VERIFY but has been superceded >> >>cadaver - https://bugzilla.fedora.us/show_bug.cgi?id=1552 >>Needs 1 VERIFY before release. >> >>rsync - https://bugzilla.fedora.us/show_bug.cgi?id=1569 >>Needs 2 VERIFY but has been superceded. >> >>flim - https://bugzilla.fedora.us/show_bug.cgi?id=1581 >>Needs 1 VERIFY before release. >> >>squid - https://bugzilla.fedora.us/show_bug.cgi?id=1732 >>Needs 1 VERIFY before release (but about to be superceded?) >> >>squirrelmail - https://bugzilla.fedora.us/show_bug.cgi?id=1733 >>Needs 2 VERIFY before release (also double check no new issues have >>cropped up) >> >>xchat - https://bugzilla.fedora.us/show_bug.cgi?id=1549 >>Needs 2 VERIFY before release. >> >>Packages in state UNCONFIRMED, NEW, ASSIGNED or REOPENED: >>-------------------------------------------------------- >> >>* yum - https://bugzilla.fedora.us/show_bug.cgi?id=1583 >>IMO this shouldn't be in the Package Request component >>close WONTFIX re rh8? >> >>vsftp - https://bugzilla.fedora.us/show_bug.cgi?id=1778 >>Resolution of whether we are vulnerable needed. >> >>* kernel - https://bugzilla.fedora.us/show_bug.cgi?id=1797 >>VM (non-security) bug in rh9 that was never fixed before EOL. Looks to >>me like this should be closed WONTFIX. >> >>* rpm - https://bugzilla.fedora.us/show_bug.cgi?id=1864 >>No rationale given for bug request - the rh bug it refers to dates from >>before rh7.3 EOL. WONTFIX? >> >>* readline - https://bugzilla.fedora.us/show_bug.cgi?id=2017 >>Another not fixed before EOL (rh9). WONTFIX? >> >>XFree86 - https://bugzilla.fedora.us/show_bug.cgi?id=1289 >>This has had 2 PUBLISHes for 7.3 and the only problem holding it back >>was likely a gdk-pixbuf red herring. Packages should be built for this >>and pushed to updates-testing I think. >> >>gaim - https://bugzilla.fedora.us/show_bug.cgi?id=1237 >>Needs 2 PUBLISH >> >>netpbm - https://bugzilla.fedora.us/show_bug.cgi?id=1257 >>Needs 2 PUBLISH >> >>kdelibs - https://bugzilla.fedora.us/show_bug.cgi?id=1373 >>Needs 2 PUBLISH (superceded?) >> >>* cal - https://bugzilla.fedora.us/show_bug.cgi?id=1439 >>Should be closed WONTFIX IMO >> >>yum - https://bugzilla.fedora.us/show_bug.cgi?id=1604 >>Needs 2 PUBLISH >> >>mod_ssl - https://bugzilla.fedora.us/show_bug.cgi?id=1708 >>Needs 2 PUBLISH for rh9 - superceded? >> >>mod_ssl - https://bugzilla.fedora.us/show_bug.cgi?id=1888 >>Needs 1 PUBLISH for rh7.3 - superceded? >> >>krb5 - https://bugzilla.fedora.us/show_bug.cgi?id=1726 >>Obsoleted >> >>mod_proxy - https://bugzilla.fedora.us/show_bug.cgi?id=1737 >>Has 2 PUBLISH, build packages for updates-testing or fix further >>minor non-security issues >> >>libxml - https://bugzilla.fedora.us/show_bug.cgi?id=1324 >>Sort out confusion over status over version in updates-testing and add >>RESOLVED flag. >> >>gdk-pixbuf - https://bugzilla.fedora.us/show_bug.cgi?id=1371 >>Packages built for updates-testing and/or a couple of formal PUBLISH >>needed. >> >>sysstat - https://bugzilla.fedora.us/show_bug.cgi?id=1372 >>Need 2 PUBLISH - 7.3 only I think >> >>mc - https://bugzilla.fedora.us/show_bug.cgi?id=1548 >>Need 2 PUBLISH (but superceded?) >> >>libpng - https://bugzilla.fedora.us/show_bug.cgi?id=1550 >>Superceded >> >>libpng - https://bugzilla.fedora.us/show_bug.cgi?id=1943 >>Need 2 PUBLISH >> >>tripwire - https://bugzilla.fedora.us/show_bug.cgi?id=1719 >>Resolve problems with how to version and build fix >> >>kernel - https://bugzilla.fedora.us/show_bug.cgi?id=1804 >>Need 2 PUBLISH >> >>apache - https://bugzilla.fedora.us/show_bug.cgi?id=1805 >>Is this redundant? >> >>XFree86 - https://bugzilla.fedora.us/show_bug.cgi?id=1831 >>Check how this stands with the other open XFree86 bug >> >>mysql - https://bugzilla.fedora.us/show_bug.cgi?id=1832 >>Needs 1 PUBLISH but superceded? >> >>lha - https://bugzilla.fedora.us/show_bug.cgi?id=1833 >>Needs 2 PUBLISH >> >>mozilla - https://bugzilla.fedora.us/show_bug.cgi?id=1834 >>Needs 2 PUBLISH >> >>ethereal - https://bugzilla.fedora.us/show_bug.cgi?id=1840 >>Needs PUBLISH for rh9 >> >>php - https://bugzilla.fedora.us/show_bug.cgi?id=1868 >>Needs PUBLISH, especially for rh7.3 >> >>abiword - https://bugzilla.fedora.us/show_bug.cgi?id=1906 >>Needs PUBLISH, especially for rh9 >> >>subversion - https://bugzilla.fedora.us/show_bug.cgi?id=1907 >>Analysis and build fixed packages >> >>samba - https://bugzilla.fedora.us/show_bug.cgi?id=1924 >>Needs PUBLISH, especially for rh9 >> >>gnome vfs - https://bugzilla.fedora.us/show_bug.cgi?id=1944 >>Needs 2 PUBLISH >> >>sox - https://bugzilla.fedora.us/show_bug.cgi?id=1945 >>Needs PUBLISH - rh9 status? >> >>glibc - https://bugzilla.fedora.us/show_bug.cgi?id=1947 >>Needs PUBLISH >> >>qt - https://bugzilla.fedora.us/show_bug.cgi?id=2002 >>RPM needs work >> >>rsync - https://bugzilla.fedora.us/show_bug.cgi?id=2003 >>Needs PUBLISH >> >>gdk-pixbuf - https://bugzilla.fedora.us/show_bug.cgi?id=2005 >>Analyse and see whether relevant >> >>mysql - https://bugzilla.fedora.us/show_bug.cgi?id=2006 >>needs work >> >>ruby - https://bugzilla.fedora.us/show_bug.cgi?id=2007 >>needs work >> >>kdelibs - https://bugzilla.fedora.us/show_bug.cgi?id=2008 >>Needs analysis >> >>mc - https://bugzilla.fedora.us/show_bug.cgi?id=2009 >>Needs work >> >>pam_wheel - https://bugzilla.fedora.us/show_bug.cgi?id=2010 >>Needs PUBLISH >> >>krb5 - https://bugzilla.fedora.us/show_bug.cgi?id=2040 >>Fix broken 7.3 packages, then QA >> >>mod_ssl - https://bugzilla.fedora.us/show_bug.cgi?id=2041 >>Needs work >> >>zlib - https://bugzilla.fedora.us/show_bug.cgi?id=2043 >>Needs work >> >>* kernel - https://bugzilla.fedora.us/show_bug.cgi?id=1614 >>close WONTFIX? Reporter gone AWOL. >> >>imlib - https://bugzilla.fedora.us/show_bug.cgi?id=2051 >>Prepare packages. >> >>ImageMagick - https://bugzilla.fedora.us/show_bug.cgi?id=2052 >>Prepare packages. >> >>squid - https://bugzilla.fedora.us/show_bug.cgi?id=2053 >>Prepare packages. >> >>General (non-package bugs) >>-------------------------- >> >>* https://bugzilla.fedora.us/show_bug.cgi?id=1599 >>applies to rh8 only - WONTFIX? >> >>* https://bugzilla.fedora.us/show_bug.cgi?id=1437 >>applies to rh8 only - WONTFIX? >> >>* https://bugzilla.fedora.us/show_bug.cgi?id=1586 >>applies to rh8 only - WONTFIX? >> >>https://bugzilla.fedora.us/show_bug.cgi?id=1963 >>Website needs fixing >> >>https://bugzilla.fedora.us/show_bug.cgi?id=1652 >>Website fix? >> >> >>Notes >>----- >> >>Needs PUBLISH means that there are packages available for QA that need >>to be QAd at the source level. >> >>Needs VERIFY means that there are updates-testing packages that need >>testing. This is the easy bit, let's get this old ones out of the way >>ASAP. >> >>* means that there is a judgement call that can be made on the bug >>system immediately. Please follow up onlist with opinions. >> >>Changes >>------- >> >>$Log: issues.txt,v $ >>Revision 1.8 2004/09/08 23:38:03 dom >>move tcpdump to release pile >>update cadaver, flim, squid >>add imlib, imagemagick, squid >> >>Revision 1.7 2004/09/08 22:58:17 dom >>new lha packages >> >>Revision 1.6 2004/09/08 16:46:13 dom >>gaim -> need publish, fix broken ethereal URL >> >>Revision 1.5 2004/09/08 12:42:32 dom >>tcpdump needs rh9 verify >> >>Revision 1.4 2004/09/08 11:50:55 dom >>no changes >> >>Revision 1.2 2004/09/08 01:23:41 dom >>add tags >> >> >>-- >>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 dwb7 at ccmr.cornell.edu Thu Sep 9 16:05:11 2004 From: dwb7 at ccmr.cornell.edu (David Botsch) Date: Thu, 9 Sep 2004 12:05:11 -0400 Subject: Round-up, 2004-09-09 In-Reply-To: <20040909011746.GC26041@tirian.magd.ox.ac.uk> References: <20040909011746.GC26041@tirian.magd.ox.ac.uk> Message-ID: <20040909160511.GA5940@ccmr.cornell.edu> Bug 2040... new krb5 packages are available for QA On Thu, Sep 09, 2004 at 02:17:46AM +0100, Dominic Hargreaves wrote: > (Posting this again to let people know of the URL - I'll try and post > regularly, but not this regularly, hereafter) > > $Id: issues.txt,v 1.8 2004/09/08 23:38:03 dom Exp $ > > See bottom for changes > > This list is also available at > http://www-astro.physics.ox.ac.uk/~dom/legacy/issues.txt > > Packages that have been verified and should be fully released > ------------------------------------------------------------- > > tcpdump - https://bugzilla.fedora.us/show_bug.cgi?id=1468 > > > Packages in state RESOLVED (ie exist in updates-testing) that need > active work. > ------------------------------------------------------------------ > > mailman - https://bugzilla.fedora.us/show_bug.cgi?id=1269 > There were some unconfirmed reports of breakage with the candidate. This > needs more QA before release. > > mod_python - https://bugzilla.fedora.us/show_bug.cgi?id=1325 > Needs 2 VERIFY before release. > > ethereal - https://bugzilla.fedora.us/show_bug.cgi?id=1419 > Needs 2 VERIFY before release. - but dup with 1840? > > kernel - https://bugzilla.fedora.us/show_bug.cgi?id=1484 > Needs missing file rebuilt for verification - but preferentially put > work into later kernel ticket > > mozilla - https://bugzilla.fedora.us/show_bug.cgi?id=1532 > Needs 2 VERIFY but has been superceded > > lha - https://bugzilla.fedora.us/show_bug.cgi?id=1547 > Needs 2 VERIFY but has been superceded > > cadaver - https://bugzilla.fedora.us/show_bug.cgi?id=1552 > Needs 1 VERIFY before release. > > rsync - https://bugzilla.fedora.us/show_bug.cgi?id=1569 > Needs 2 VERIFY but has been superceded. > > flim - https://bugzilla.fedora.us/show_bug.cgi?id=1581 > Needs 1 VERIFY before release. > > squid - https://bugzilla.fedora.us/show_bug.cgi?id=1732 > Needs 1 VERIFY before release (but about to be superceded?) > > squirrelmail - https://bugzilla.fedora.us/show_bug.cgi?id=1733 > Needs 2 VERIFY before release (also double check no new issues have > cropped up) > > xchat - https://bugzilla.fedora.us/show_bug.cgi?id=1549 > Needs 2 VERIFY before release. > > Packages in state UNCONFIRMED, NEW, ASSIGNED or REOPENED: > -------------------------------------------------------- > > * yum - https://bugzilla.fedora.us/show_bug.cgi?id=1583 > IMO this shouldn't be in the Package Request component > close WONTFIX re rh8? > > vsftp - https://bugzilla.fedora.us/show_bug.cgi?id=1778 > Resolution of whether we are vulnerable needed. > > * kernel - https://bugzilla.fedora.us/show_bug.cgi?id=1797 > VM (non-security) bug in rh9 that was never fixed before EOL. Looks to > me like this should be closed WONTFIX. > > * rpm - https://bugzilla.fedora.us/show_bug.cgi?id=1864 > No rationale given for bug request - the rh bug it refers to dates from > before rh7.3 EOL. WONTFIX? > > * readline - https://bugzilla.fedora.us/show_bug.cgi?id=2017 > Another not fixed before EOL (rh9). WONTFIX? > > XFree86 - https://bugzilla.fedora.us/show_bug.cgi?id=1289 > This has had 2 PUBLISHes for 7.3 and the only problem holding it back > was likely a gdk-pixbuf red herring. Packages should be built for this > and pushed to updates-testing I think. > > gaim - https://bugzilla.fedora.us/show_bug.cgi?id=1237 > Needs 2 PUBLISH > > netpbm - https://bugzilla.fedora.us/show_bug.cgi?id=1257 > Needs 2 PUBLISH > > kdelibs - https://bugzilla.fedora.us/show_bug.cgi?id=1373 > Needs 2 PUBLISH (superceded?) > > * cal - https://bugzilla.fedora.us/show_bug.cgi?id=1439 > Should be closed WONTFIX IMO > > yum - https://bugzilla.fedora.us/show_bug.cgi?id=1604 > Needs 2 PUBLISH > > mod_ssl - https://bugzilla.fedora.us/show_bug.cgi?id=1708 > Needs 2 PUBLISH for rh9 - superceded? > > mod_ssl - https://bugzilla.fedora.us/show_bug.cgi?id=1888 > Needs 1 PUBLISH for rh7.3 - superceded? > > krb5 - https://bugzilla.fedora.us/show_bug.cgi?id=1726 > Obsoleted > > mod_proxy - https://bugzilla.fedora.us/show_bug.cgi?id=1737 > Has 2 PUBLISH, build packages for updates-testing or fix further > minor non-security issues > > libxml - https://bugzilla.fedora.us/show_bug.cgi?id=1324 > Sort out confusion over status over version in updates-testing and add > RESOLVED flag. > > gdk-pixbuf - https://bugzilla.fedora.us/show_bug.cgi?id=1371 > Packages built for updates-testing and/or a couple of formal PUBLISH > needed. > > sysstat - https://bugzilla.fedora.us/show_bug.cgi?id=1372 > Need 2 PUBLISH - 7.3 only I think > > mc - https://bugzilla.fedora.us/show_bug.cgi?id=1548 > Need 2 PUBLISH (but superceded?) > > libpng - https://bugzilla.fedora.us/show_bug.cgi?id=1550 > Superceded > > libpng - https://bugzilla.fedora.us/show_bug.cgi?id=1943 > Need 2 PUBLISH > > tripwire - https://bugzilla.fedora.us/show_bug.cgi?id=1719 > Resolve problems with how to version and build fix > > kernel - https://bugzilla.fedora.us/show_bug.cgi?id=1804 > Need 2 PUBLISH > > apache - https://bugzilla.fedora.us/show_bug.cgi?id=1805 > Is this redundant? > > XFree86 - https://bugzilla.fedora.us/show_bug.cgi?id=1831 > Check how this stands with the other open XFree86 bug > > mysql - https://bugzilla.fedora.us/show_bug.cgi?id=1832 > Needs 1 PUBLISH but superceded? > > lha - https://bugzilla.fedora.us/show_bug.cgi?id=1833 > Needs 2 PUBLISH > > mozilla - https://bugzilla.fedora.us/show_bug.cgi?id=1834 > Needs 2 PUBLISH > > ethereal - https://bugzilla.fedora.us/show_bug.cgi?id=1840 > Needs PUBLISH for rh9 > > php - https://bugzilla.fedora.us/show_bug.cgi?id=1868 > Needs PUBLISH, especially for rh7.3 > > abiword - https://bugzilla.fedora.us/show_bug.cgi?id=1906 > Needs PUBLISH, especially for rh9 > > subversion - https://bugzilla.fedora.us/show_bug.cgi?id=1907 > Analysis and build fixed packages > > samba - https://bugzilla.fedora.us/show_bug.cgi?id=1924 > Needs PUBLISH, especially for rh9 > > gnome vfs - https://bugzilla.fedora.us/show_bug.cgi?id=1944 > Needs 2 PUBLISH > > sox - https://bugzilla.fedora.us/show_bug.cgi?id=1945 > Needs PUBLISH - rh9 status? > > glibc - https://bugzilla.fedora.us/show_bug.cgi?id=1947 > Needs PUBLISH > > qt - https://bugzilla.fedora.us/show_bug.cgi?id=2002 > RPM needs work > > rsync - https://bugzilla.fedora.us/show_bug.cgi?id=2003 > Needs PUBLISH > > gdk-pixbuf - https://bugzilla.fedora.us/show_bug.cgi?id=2005 > Analyse and see whether relevant > > mysql - https://bugzilla.fedora.us/show_bug.cgi?id=2006 > needs work > > ruby - https://bugzilla.fedora.us/show_bug.cgi?id=2007 > needs work > > kdelibs - https://bugzilla.fedora.us/show_bug.cgi?id=2008 > Needs analysis > > mc - https://bugzilla.fedora.us/show_bug.cgi?id=2009 > Needs work > > pam_wheel - https://bugzilla.fedora.us/show_bug.cgi?id=2010 > Needs PUBLISH > > krb5 - https://bugzilla.fedora.us/show_bug.cgi?id=2040 > Fix broken 7.3 packages, then QA > > mod_ssl - https://bugzilla.fedora.us/show_bug.cgi?id=2041 > Needs work > > zlib - https://bugzilla.fedora.us/show_bug.cgi?id=2043 > Needs work > > * kernel - https://bugzilla.fedora.us/show_bug.cgi?id=1614 > close WONTFIX? Reporter gone AWOL. > > imlib - https://bugzilla.fedora.us/show_bug.cgi?id=2051 > Prepare packages. > > ImageMagick - https://bugzilla.fedora.us/show_bug.cgi?id=2052 > Prepare packages. > > squid - https://bugzilla.fedora.us/show_bug.cgi?id=2053 > Prepare packages. > > General (non-package bugs) > -------------------------- > > * https://bugzilla.fedora.us/show_bug.cgi?id=1599 > applies to rh8 only - WONTFIX? > > * https://bugzilla.fedora.us/show_bug.cgi?id=1437 > applies to rh8 only - WONTFIX? > > * https://bugzilla.fedora.us/show_bug.cgi?id=1586 > applies to rh8 only - WONTFIX? > > https://bugzilla.fedora.us/show_bug.cgi?id=1963 > Website needs fixing > > https://bugzilla.fedora.us/show_bug.cgi?id=1652 > Website fix? > > > Notes > ----- > > Needs PUBLISH means that there are packages available for QA that need > to be QAd at the source level. > > Needs VERIFY means that there are updates-testing packages that need > testing. This is the easy bit, let's get this old ones out of the way > ASAP. > > * means that there is a judgement call that can be made on the bug > system immediately. Please follow up onlist with opinions. > > Changes > ------- > > $Log: issues.txt,v $ > Revision 1.8 2004/09/08 23:38:03 dom > move tcpdump to release pile > update cadaver, flim, squid > add imlib, imagemagick, squid > > Revision 1.7 2004/09/08 22:58:17 dom > new lha packages > > Revision 1.6 2004/09/08 16:46:13 dom > gaim -> need publish, fix broken ethereal URL > > Revision 1.5 2004/09/08 12:42:32 dom > tcpdump needs rh9 verify > > Revision 1.4 2004/09/08 11:50:55 dom > no changes > > Revision 1.2 2004/09/08 01:23:41 dom > add tags > > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-legacy-list -- ******************************** David William Botsch Consultant/Advisor II CCMR Computing Facility dwb7 at ccmr.cornell.edu ******************************** From listas at andreso.net Thu Sep 9 16:18:31 2004 From: listas at andreso.net (Andres Adrover Kvamsdal) Date: Thu, 09 Sep 2004 18:18:31 +0200 Subject: Round-up, 2004-09-09 In-Reply-To: <20040909160511.GA5940@ccmr.cornell.edu> References: <20040909011746.GC26041@tirian.magd.ox.ac.uk> <20040909160511.GA5940@ccmr.cornell.edu> Message-ID: <41408257.5050506@andreso.net> >>squirrelmail - https://bugzilla.fedora.us/show_bug.cgi?id=1733 >>Needs 2 VERIFY before release (also double check no new issues have >>cropped up) This is the main problem I see with Fedora Legacy. "double check no new issues have cropped up" As I see it Fedora Legacy should release ASAP. Remember that redhat has released several broken packages. They fixed that releasing improved packages some few days later. I do not understand why Fedora Legacy has to be better than RedHat. Andres From dom at earth.li Thu Sep 9 16:22:15 2004 From: dom at earth.li (Dominic Hargreaves) Date: Thu, 9 Sep 2004 17:22:15 +0100 Subject: Round-up, 2004-09-09 In-Reply-To: <41408257.5050506@andreso.net> References: <20040909011746.GC26041@tirian.magd.ox.ac.uk> <20040909160511.GA5940@ccmr.cornell.edu> <41408257.5050506@andreso.net> Message-ID: <20040909162215.GG26041@tirian.magd.ox.ac.uk> On Thu, Sep 09, 2004 at 06:18:31PM +0200, Andres Adrover Kvamsdal wrote: > >>squirrelmail - https://bugzilla.fedora.us/show_bug.cgi?id=1733 > >>Needs 2 VERIFY before release (also double check no new issues have > >>cropped up) > > This is the main problem I see with Fedora Legacy. "double check no new > issues have cropped up" As I see it Fedora Legacy should release ASAP. > Remember that redhat has released several broken packages. They fixed > that releasing improved packages some few days later. > > I do not understand why Fedora Legacy has to be better than RedHat. Clearly it is better not to release broken packages. In general we don't need to strive for perfect quality, perhaps, but I am aware that that particular package does have a large number of security issues (based on skimming bugtraq) so I thought it was worth mentioning. But to be honest that has nothing to do with the reason why FL is slow. That is down to lack of manpower. Dominic. From dwb7 at ccmr.cornell.edu Thu Sep 9 16:23:12 2004 From: dwb7 at ccmr.cornell.edu (David Botsch) Date: Thu, 9 Sep 2004 12:23:12 -0400 Subject: Round-up, 2004-09-09 In-Reply-To: <41408257.5050506@andreso.net> References: <20040909011746.GC26041@tirian.magd.ox.ac.uk> <20040909160511.GA5940@ccmr.cornell.edu> <41408257.5050506@andreso.net> Message-ID: <20040909162312.GB5940@ccmr.cornell.edu> I do tend to think we should try and not release broken packages. That is something that annoys lots (myself included) when RedHat releases a package that breaks something critical (such as process accounting). I would propose the following: after two PUBLISHes, the package goes to updates-testing as current If this is a critical hole (say, a remote exploit), we immediately release the package to updates If the hole is not as critical, then we go through the normal QA process. Two VERIFYs are after some period of time (say one week) with no objections, the package goes to updates On Thu, Sep 09, 2004 at 06:18:31PM +0200, Andres Adrover Kvamsdal wrote: > >>squirrelmail - https://bugzilla.fedora.us/show_bug.cgi?id=1733 > >>Needs 2 VERIFY before release (also double check no new issues have > >>cropped up) > > This is the main problem I see with Fedora Legacy. "double check no new > issues have cropped up" As I see it Fedora Legacy should release ASAP. > Remember that redhat has released several broken packages. They fixed > that releasing improved packages some few days later. > > I do not understand why Fedora Legacy has to be better than RedHat. > > Andres > > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-legacy-list -- ******************************** David William Botsch Consultant/Advisor II CCMR Computing Facility dwb7 at ccmr.cornell.edu ******************************** From simon at nzservers.com Thu Sep 9 16:27:23 2004 From: simon at nzservers.com (Simon Weller) Date: Thu, 9 Sep 2004 11:27:23 -0500 Subject: Round-up, 2004-09-09 In-Reply-To: <20040909162312.GB5940@ccmr.cornell.edu> References: <20040909011746.GC26041@tirian.magd.ox.ac.uk> <41408257.5050506@andreso.net> <20040909162312.GB5940@ccmr.cornell.edu> Message-ID: <200409091127.23417.simon@nzservers.com> On Thursday 09 September 2004 11:23 am, David Botsch wrote: > I do tend to think we should try and not release broken packages. That is > something that annoys lots (myself included) when RedHat releases a package > that breaks something critical (such as process accounting). > > I would propose the following: > > after two PUBLISHes, the package goes to updates-testing as current > > If this is a critical hole (say, a remote exploit), we immediately release > the package to updates > > If the hole is not as critical, then we go through the normal QA process. > Two VERIFYs are after some period of time (say one week) with no > objections, the package goes to updates > I think that's a good idea. If people are concerned that a package isn't going to get enough QA, then request 5 VERIFYs and then immediate release to updates. There will be more than enough people willing to VERIFY a package if it's a remote exploit. - Si > > -- > > fedora-legacy-list mailing list > > fedora-legacy-list at redhat.com > > http://www.redhat.com/mailman/listinfo/fedora-legacy-list -- Simon Weller LPIC-2, BCIP Systems Engineer NZServers LTD http://www.nzservers.com/ U.S. Branch <- To mess up a Linux box, you need to work at it; to mess up your Windows box, you just need to work on it. - Scott Granneman, Security Focus -> From euckew at sierraelectronics.com Thu Sep 9 17:06:00 2004 From: euckew at sierraelectronics.com (Eucke Warren) Date: Thu, 9 Sep 2004 10:06:00 -0700 Subject: I want to help but.... Message-ID: <002301c4968f$488e6dc0$3f01a8c0@Eucke> Guys, I very much want to help but I need to better understand the issues involved with stress testing a package for review. I have a number of RH9 systems and some that can be used for package testing. Is there a structured process tree for stress testing that is published somewhere that I might review to help me understand what I would need to do? I am kind of a Jack of all Trades and I have learned by doing. Is there a place where I can help further this project? I can certainly test if I have something that will help me to know what I am testing for...willingness and resources I can supply...expertise is, admittedly, lacking.... Eucke -------------- next part -------------- An HTML attachment was scrubbed... URL: From mule at umich.edu Thu Sep 9 17:05:14 2004 From: mule at umich.edu (Stephen E. Dudek) Date: Thu, 09 Sep 2004 13:05:14 -0400 Subject: Self Introduction: Stephen Dudek Message-ID: <1094749514.1701.29.camel@pestilence.themule.net> [mule at pestilence mule]$ whoami Stephen Dudek Ann Arbor, Michigan, United States Workstation and Network Administrator University of Michigan Department of Public Safety I'm interested in doing QA for Red Hat 9, possibly more. I'm currently maintaining four production Red Hat 9 servers for both work and personal use. Thank you. [mule at pestilence mule]$ gpg --fingerprint DA69E152 pub 1024D/DA69E152 2004-09-09 Stephen E. Dudek (Mule) Key fingerprint = 84D8 F68B 2C52 E0E2 6CD9 5C35 4EC6 946B DA69 E152 sub 1024g/2BF14B54 2004-09-09 [expires: 2006-09-09] [mule at pestilence mule]$ From dom at earth.li Thu Sep 9 17:05:26 2004 From: dom at earth.li (Dominic Hargreaves) Date: Thu, 9 Sep 2004 18:05:26 +0100 Subject: I want to help but.... In-Reply-To: <002301c4968f$488e6dc0$3f01a8c0@Eucke> References: <002301c4968f$488e6dc0$3f01a8c0@Eucke> Message-ID: <20040909170526.GH26041@tirian.magd.ox.ac.uk> On Thu, Sep 09, 2004 at 10:06:00AM -0700, Eucke Warren wrote: > Guys, I very much want to help but I need to better understand the issues involved with stress testing a package for review. I have a number of RH9 systems and some that can be used for package testing. Is there a structured process tree for stress testing that is published somewhere that I might review to help me understand what I would need to do? Hi, The best place to start is ; this describes how to QA a package. Cheers, Dominic. From rostetter at mail.utexas.edu Thu Sep 9 18:01:32 2004 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Thu, 9 Sep 2004 13:01:32 -0500 Subject: Round-up, 2004-09-09 In-Reply-To: <41408257.5050506@andreso.net> References: <20040909011746.GC26041@tirian.magd.ox.ac.uk> <20040909160511.GA5940@ccmr.cornell.edu> <41408257.5050506@andreso.net> Message-ID: <1094752892.6cb08bbfe7ae6@mail.ph.utexas.edu> Quoting Andres Adrover Kvamsdal : > >>squirrelmail - https://bugzilla.fedora.us/show_bug.cgi?id=1733 > >>Needs 2 VERIFY before release (also double check no new issues have > >>cropped up) > > This is the main problem I see with Fedora Legacy. "double check no new > issues have cropped up" I agree (I think). > As I see it Fedora Legacy should release ASAP. ASAP after receiving two publish votes. Come on people, test and vote!!! > Remember that redhat has released several broken packages. We want to avoid releasing broken packages at all costs. But we shouldn't stop a functioning, tested patch that fixes a security problem be delayed just because a second problem is found in the same package. If the first problem is fixed and tested, it should be released even if another (existing) problem is identified with that package. Waiting until all known problems are fixed just delays releases for ever, discourages people from testing them (since they test is no invalidated), and causes complaints and bad PR for the FLP. > They fixed > that releasing improved packages some few days later. Hopefully we won't have broken packages, so we won't have to fix them. But I see no problem with releasing a package to fix BUG #1 on Tuesday, then releasing the same package to fix BUG #2 on Friday (for example). > I do not understand why Fedora Legacy has to be better than RedHat. We don't. But even Red Hat tries not to release broken packages, and even Red Hat won't release something without QA testing. We need to follow that lead. But we shouldn't delay tested patches for new, not-yet-existing patches, which we have done in the past, and looks like we may be doing again now... > Andres -- Eric Rostetter From rostetter at mail.utexas.edu Thu Sep 9 18:11:36 2004 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Thu, 9 Sep 2004 13:11:36 -0500 Subject: I want to help but.... In-Reply-To: <20040909170526.GH26041@tirian.magd.ox.ac.uk> References: <002301c4968f$488e6dc0$3f01a8c0@Eucke> <20040909170526.GH26041@tirian.magd.ox.ac.uk> Message-ID: <1094753496.6d8ae099a0b95@mail.ph.utexas.edu> Quoting Dominic Hargreaves : > On Thu, Sep 09, 2004 at 10:06:00AM -0700, Eucke Warren wrote: > > Guys, I very much want to help but I need to better understand the issues > involved with stress testing a package for review. I have a number of RH9 > systems and some that can be used for package testing. Is there a structured > process tree for stress testing that is published somewhere that I might > review to help me understand what I would need to do? > > Hi, > > The best place to start is > ; this describes > how to QA a package. > > Cheers, > > Dominic. That page is really aimed at QA testing before it hits updates-testing, and is over the head of most people who want to help. I'll create a new wiki page today that says the minimum steps needed to QA the stuff in updates-testing for those who want to help. I'll report to the list with the url when it is ready. > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-legacy-list > -- Eric Rostetter From euckew at sierraelectronics.com Thu Sep 9 18:25:05 2004 From: euckew at sierraelectronics.com (Eucke Warren) Date: Thu, 9 Sep 2004 11:25:05 -0700 Subject: I want to help but.... References: <002301c4968f$488e6dc0$3f01a8c0@Eucke><20040909170526.GH26041@tirian.magd.ox.ac.uk> <1094753496.6d8ae099a0b95@mail.ph.utexas.edu> Message-ID: <005601c4969a$5411f710$3f01a8c0@Eucke> ----- Original Message ----- From: "Eric Rostetter" To: Sent: Thursday, September 09, 2004 11:11 AM Subject: Re: I want to help but.... > Quoting Dominic Hargreaves : > > > On Thu, Sep 09, 2004 at 10:06:00AM -0700, Eucke Warren wrote: > > > Guys, I very much want to help but I need to better understand the issues > > involved with stress testing a package for review. I have a number of RH9 > > systems and some that can be used for package testing. Is there a structured > > process tree for stress testing that is published somewhere that I might > > review to help me understand what I would need to do? > > > > Hi, > > > > The best place to start is > > ; this describes > > how to QA a package. > > > > Cheers, > > > > Dominic. > > That page is really aimed at QA testing before it hits updates-testing, > and is over the head of most people who want to help. I'll create > a new wiki page today that says the minimum steps needed to QA the stuff > in updates-testing for those who want to help. I'll report to the list > with the url when it is ready. That's what I am after Eric. I'll admit that I am ignorant of much of what needs to be done...but I can follow instructions and report my observations if someone might be inclined to mentor me in what to look for and where.....of course...if you guys rat me out for being ignorant...I'll deny everything! :-P Thanks very much! -Eucke From pmatilai at welho.com Thu Sep 9 19:42:21 2004 From: pmatilai at welho.com (Panu Matilainen) Date: Thu, 09 Sep 2004 22:42:21 +0300 Subject: Round-up, 2004-09-09 In-Reply-To: <1094752892.6cb08bbfe7ae6@mail.ph.utexas.edu> References: <20040909011746.GC26041@tirian.magd.ox.ac.uk> <20040909160511.GA5940@ccmr.cornell.edu> <41408257.5050506@andreso.net> <1094752892.6cb08bbfe7ae6@mail.ph.utexas.edu> Message-ID: <1094758940.12099.21.camel@chip.laiskiainen.org> On Thu, 2004-09-09 at 21:01, Eric Rostetter wrote: > We want to avoid releasing broken packages at all costs. Doesn't everybody... but not really at ALL costs. > > But we shouldn't stop a functioning, tested patch that fixes a security > problem be delayed just because a second problem is found in the same > package. > > If the first problem is fixed and tested, it should be released even > if another (existing) problem is identified with that package. Waiting > until all known problems are fixed just delays releases for ever, discourages > people from testing them (since they test is no invalidated), and causes > complaints and bad PR for the FLP. It's very very easy to go down the road of "but how about this tiny little thing that just found, can we include it in this update as well pretty pretty please". There will always be another "tiny little thing" wanting fixing... It's to better set an initial goal of "this package fixes CAN-xxxxx and NOTHING else", verify "it still boots and seems to function" and publish that than to wait for two weeks if something happens to happen during that time which just causes the already slow verification process to restart from the beginning. Of course if nobody votes anything then the packager is free to fix additional things since no work is lost, but asking people to qa->test->vote->try-new-release->qa->vote all over again wont go anywhere, as I think we've seen here. Oh and yes, talk is cheap. I would like to give more time to fedora-legacy but I can't under current circumstances so feel free to ignore me'n my ramblings... - Panu - From rostetter at mail.utexas.edu Thu Sep 9 19:51:45 2004 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Thu, 9 Sep 2004 14:51:45 -0500 Subject: I want to help but.... In-Reply-To: <005601c4969a$5411f710$3f01a8c0@Eucke> References: <002301c4968f$488e6dc0$3f01a8c0@Eucke><20040909170526.GH26041@tirian.magd.ox.ac.uk> <1094753496.6d8ae099a0b95@mail.ph.utexas.edu> <005601c4969a$5411f710$3f01a8c0@Eucke> Message-ID: <1094759505.16d2b1497aabd@mail.ph.utexas.edu> Quoting Eucke Warren : > > > The best place to start is > > > ; this describes > > > how to QA a package. > > > > > > Cheers, > > > > > > Dominic. This is once again the best place to start. I've modified it to take into account people who just want to help test the updates-testing packages. Still a work in progress, but it is much better now. > That's what I am after Eric. I'll admit that I am ignorant of much of what > needs to be done...but I can follow instructions and report my observations > if someone might be inclined to mentor me in what to look for and > where.....of course...if you guys rat me out for being ignorant...I'll deny > everything! :-P Basic steps are: * Install pgp on your machine if needed (yum install gnupg) * Generate a pgp key for yourself (ask for help on the mailing list) * Publish the pgp key to a public key server (see docs on the wiki) * Introduce yourself to the list, with your pgp key (see docs on the wiki) * Download the RPMS you want to test. Verify them (see docs on the wiki) * Install them. Test the functionality to make sure it works. * Report your results as a pgp clearsigned message to the Bugzilla system. If you are voting for a publish state, then make this clear in the message (such as putting in it "I VOTE TO PUBLISH" or "PUBLISH++"). If you need help on any of the above, ask on the mailing list. Things which get asked will be archived and will probably be added to the wiki pages, so your questions will end up helping others. > Thanks very much! > > -Eucke Not long ago, when Fedora Legacy just started, I was in the same boat. I had to ask the mailing list for help, and now I'm in a position to help others. GPG signing and Bugzilla posting and all was new to me. But it was easy to lern with the help of others. So please don't feel afraid to ask me (or the others) for help. -- Eric Rostetter From mule at umich.edu Thu Sep 9 20:41:11 2004 From: mule at umich.edu (Stephen E. Dudek) Date: Thu, 09 Sep 2004 16:41:11 -0400 Subject: I want to help but.... In-Reply-To: <1094759505.16d2b1497aabd@mail.ph.utexas.edu> References: <002301c4968f$488e6dc0$3f01a8c0@Eucke> <20040909170526.GH26041@tirian.magd.ox.ac.uk> <1094753496.6d8ae099a0b95@mail.ph.utexas.edu> <005601c4969a$5411f710$3f01a8c0@Eucke> <1094759505.16d2b1497aabd@mail.ph.utexas.edu> Message-ID: <1094762471.10581.21.camel@pestilence.themule.net> Slight typo in the updated page: http://wwww.fedoralegacy.org/about/security.php should be http://www.fedoralegacy.org/about/security.php On Thu, 2004-09-09 at 15:51, Eric Rostetter wrote: > Quoting Eucke Warren : > > > > > The best place to start is > > > > ; this describes > > > > how to QA a package. > > > > > > > > Cheers, > > > > > > > > Dominic. > > This is once again the best place to start. I've modified it to take > into account people who just want to help test the updates-testing packages. > Still a work in progress, but it is much better now. > > > That's what I am after Eric. I'll admit that I am ignorant of much of what > > needs to be done...but I can follow instructions and report my observations > > if someone might be inclined to mentor me in what to look for and > > where.....of course...if you guys rat me out for being ignorant...I'll deny > > everything! :-P > > Basic steps are: > > * Install pgp on your machine if needed (yum install gnupg) > * Generate a pgp key for yourself (ask for help on the mailing list) > * Publish the pgp key to a public key server (see docs on the wiki) > * Introduce yourself to the list, with your pgp key (see docs on the wiki) > * Download the RPMS you want to test. Verify them (see docs on the wiki) > * Install them. Test the functionality to make sure it works. > * Report your results as a pgp clearsigned message to the Bugzilla system From rostetter at mail.utexas.edu Thu Sep 9 20:55:48 2004 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Thu, 9 Sep 2004 15:55:48 -0500 Subject: I want to help but.... In-Reply-To: <002301c4968f$488e6dc0$3f01a8c0@Eucke> References: <002301c4968f$488e6dc0$3f01a8c0@Eucke> Message-ID: <1094763348.ba5854a0e69da@mail.ph.utexas.edu> Quoting Eucke Warren : > Guys, I very much want to help but I need to better understand the issues > involved with stress testing a package for review. I have a number of RH9 > systems and some that can be used for package testing. Is there a structured > process tree for stress testing that is published somewhere that I might > review to help me understand what I would need to do? Basically you want to start by seeing the web page at: http://www.fedoralegacy.org/wiki/index.php/QaTesting In particular, the info about creating/registering a gpg key, the self introduction to the mailing list, the section on testing a package in the updates-testing channel, and the section on reporting your results to bugzilla. If you have any questions on that, then ask on the mailing list. After all that, you want to download and install the packages from updates-testing on as many machines as you can. You then want to use, or have users of the machine use, the functionality of the package to make sure it works. For example, if the package was "zip" you would want to try zipping some files, unzipping them, compare the original and unzipped files to make sure they are the same, try to unzip some old zip files created with another version, etc. How to test it is dependend on your skills, resources, and the package in question. But you want to test it as well as possible; in many cases (e.g. a kernel or XFree86 or such) this means testing it for several days. Once you test it as well as possible, you want to report your results. Installation problems/issues, whether it worked or not, any problems or quirks you noticed, etc. You can also, if you want, vote for it to be published or not. This report is via Bugzilla and must be gpg clear signed. > I am kind of a Jack of all Trades and I have learned by doing. Is there a > place where I can help further this project? The web page, the wiki, or the mailing list archives. Or ask on the list. > I can certainly test if I have > something that will help me to know what I am testing for...willingness and > resources I can supply...expertise is, admittedly, lacking.... Just ask if you need help! > Eucke -- Eric Rostetter From rostetter at mail.utexas.edu Thu Sep 9 21:29:00 2004 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Thu, 9 Sep 2004 16:29:00 -0500 Subject: I want to help but.... In-Reply-To: <1094762471.10581.21.camel@pestilence.themule.net> References: <002301c4968f$488e6dc0$3f01a8c0@Eucke> <20040909170526.GH26041@tirian.magd.ox.ac.uk> <1094753496.6d8ae099a0b95@mail.ph.utexas.edu> <005601c4969a$5411f710$3f01a8c0@Eucke> <1094759505.16d2b1497aabd@mail.ph.utexas.edu> <1094762471.10581.21.camel@pestilence.themule.net> Message-ID: <1094765340.6c8cc233508b3@mail.ph.utexas.edu> Quoting "Stephen E. Dudek" : > Slight typo in the updated page: > > http://wwww.fedoralegacy.org/about/security.php > > should be > > http://www.fedoralegacy.org/about/security.php Fixed, thanks! -- Eric Rostetter From dom at earth.li Fri Sep 10 12:42:06 2004 From: dom at earth.li (Dominic Hargreaves) Date: Fri, 10 Sep 2004 13:42:06 +0100 Subject: Problem with bugzilla CCs Message-ID: <20040910124206.GJ26041@tirian.magd.ox.ac.uk> Hi, Is there a known problem with the bugzilla's mail system? It's failed to send me quite a few CCs over the last week or so (and yes, my preferences do indicate that I should be receiving them). Thanks, Dominic. From listas at andreso.net Fri Sep 10 14:24:10 2004 From: listas at andreso.net (Andres Adrover Kvamsdal) Date: Fri, 10 Sep 2004 16:24:10 +0200 Subject: Round-up, 2004-09-09 In-Reply-To: <1094752892.6cb08bbfe7ae6@mail.ph.utexas.edu> References: <20040909011746.GC26041@tirian.magd.ox.ac.uk> <20040909160511.GA5940@ccmr.cornell.edu> <41408257.5050506@andreso.net> <1094752892.6cb08bbfe7ae6@mail.ph.utexas.edu> Message-ID: <4141B90A.3000601@andreso.net> Eric Rostetter wrote: > Hopefully we won't have broken packages, so we won't have to fix them. As far as I see it there would be only two sources of concern to me, two situations I would not be able to deal with: 1. A broken rpm package. As long as rpm works everything is fine and dandy with me. I am too much of a linux newbie to have a clue of how to deal with a broken rpm 2. I currently have a RedHat 7.2 development server. The new iptables package was incompatible with the old kernel so I had to upgrade the kernel instead of installing a new one. A broken kernel that requires update instead of install would also stress my abilitiess. I personally can live with a couple of days of downtime due to broken packages. I have spent five years reading bugtraq. I have seen terminator 3 (which coincidentaly was released at about the same time as blaster). It gives me a false sense of security (which I appreciate) to see a lot of activity in my yum logs. Andres From marcdeslauriers at videotron.ca Fri Sep 10 14:23:41 2004 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Fri, 10 Sep 2004 10:23:41 -0400 Subject: Problem with bugzilla CCs In-Reply-To: <20040910124206.GJ26041@tirian.magd.ox.ac.uk> References: <20040910124206.GJ26041@tirian.magd.ox.ac.uk> Message-ID: <1094826206.4639.0.camel@mdlinux> On Fri, 2004-09-10 at 08:42, Dominic Hargreaves wrote: > Is there a known problem with the bugzilla's mail system? It's failed to > send me quite a few CCs over the last week or so (and yes, my > preferences do indicate that I should be receiving them). I got a bunch of your CCs...Do you have any one in particular you know you didn't get so I can check if I got it? Marc. From ckelley at ibnads.com Fri Sep 10 16:22:16 2004 From: ckelley at ibnads.com (Craig Kelley) Date: Fri, 10 Sep 2004 10:22:16 -0600 Subject: Problem with bugzilla CCs In-Reply-To: <1094826206.4639.0.camel@mdlinux> References: <20040910124206.GJ26041@tirian.magd.ox.ac.uk> <1094826206.4639.0.camel@mdlinux> Message-ID: <4141D4B8.7080104@ibnads.com> Marc Deslauriers wrote: >On Fri, 2004-09-10 at 08:42, Dominic Hargreaves wrote: > > >>Is there a known problem with the bugzilla's mail system? It's failed to >>send me quite a few CCs over the last week or so (and yes, my >>preferences do indicate that I should be receiving them). >> >> > >I got a bunch of your CCs...Do you have any one in particular you know >you didn't get so I can check if I got it? > > I'm getting them fine; but I'm always on the explicit CC list (I don't own any bugs). -- Craig Kelley In-Store Broadcasting Network -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 256 bytes Desc: OpenPGP digital signature URL: From marcdeslauriers at videotron.ca Fri Sep 10 18:18:04 2004 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Fri, 10 Sep 2004 14:18:04 -0400 Subject: Round-up, 2004-09-09 In-Reply-To: <20040909011746.GC26041@tirian.magd.ox.ac.uk> References: <20040909011746.GC26041@tirian.magd.ox.ac.uk> Message-ID: <1094840284.6436.10.camel@mdlinux> On Wed, 2004-09-08 at 21:17, Dominic Hargreaves wrote: > (Posting this again to let people know of the URL - I'll try and post > regularly, but not this regularly, hereafter) Here are a few changes for the list: Ethereal - Bug 1419 has been superseded by bug 1840 kdelibs - Bug 1373 has been superseded by bug 2008 XFree86 - Bug 1831 contains correct updated packages for rh9. The 7.3 packages included in this bug report can be ignored. Marc. From lludwig-maillist at empoweringmedia.com Fri Sep 10 18:36:34 2004 From: lludwig-maillist at empoweringmedia.com (lludwig-maillist at empoweringmedia.com) Date: Fri, 10 Sep 2004 14:36:34 -0400 Subject: How to vote? In-Reply-To: <413FED12.9000002@netikka.fi> References: <20040909011746.GC26041@tirian.magd.ox.ac.uk> <1094696024.14225.3.camel@blue> <413FED12.9000002@netikka.fi> Message-ID: <1094841394.4141f4326d315@www.emwebmail.com> Quoting Johnny Strom : > Good we need more ppl that can do that so all want's to help now is the > time to go trough the list and QA packages. The prcedure is to have > 2 ppl that have tested a package and voted for publish, then a relase > manager can put that package in update testing. This may have been asked before but how do you vote in bugzilla? I have an account BUT cannot vote on any items. It appears I do not have permission. my Email account is ludes at yahoo.com -------------------------------------------------- http://www.hostasite.com - Web hosting made simple From jonny.strom at netikka.fi Fri Sep 10 20:36:40 2004 From: jonny.strom at netikka.fi (Johnny Strom) Date: Fri, 10 Sep 2004 23:36:40 +0300 Subject: How to vote? In-Reply-To: <1094841394.4141f4326d315@www.emwebmail.com> References: <20040909011746.GC26041@tirian.magd.ox.ac.uk> <1094696024.14225.3.camel@blue> <413FED12.9000002@netikka.fi> <1094841394.4141f4326d315@www.emwebmail.com> Message-ID: <41421058.3050304@netikka.fi> lludwig-maillist at empoweringmedia.com wrote: > Quoting Johnny Strom : > > >>Good we need more ppl that can do that so all want's to help now is the >>time to go trough the list and QA packages. The prcedure is to have >>2 ppl that have tested a package and voted for publish, then a relase >>manager can put that package in update testing. > > > This may have been asked before but how do you vote in bugzilla? I have an > account BUT cannot vote on any items. It appears I do not have permission. my > Email account is ludes at yahoo.com What you do is an QA of the package like others have done, this is good example: http://bugzilla.fedora.us/show_bug.cgi?id=1943 check the example at comment 6. Cheers Johnny > > -------------------------------------------------- > http://www.hostasite.com - Web hosting made simple > > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-legacy-list From madlists at teaparty.net Sat Sep 11 08:55:43 2004 From: madlists at teaparty.net (Tom Yates) Date: Sat, 11 Sep 2004 09:55:43 +0100 (BST) Subject: Self-Introduction: Tom Yates In-Reply-To: <1094759505.16d2b1497aabd@mail.ph.utexas.edu> References: <002301c4968f$488e6dc0$3f01a8c0@Eucke><20040909170526.GH26041@tirian.magd.ox.ac.uk> <1094753496.6d8ae099a0b95@mail.ph.utexas.edu> <005601c4969a$5411f710$3f01a8c0@Eucke> <1094759505.16d2b1497aabd@mail.ph.utexas.edu> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thu, 9 Sep 2004, Eric Rostetter wrote: > Basic steps are: > [stuff i've done already] > * Introduce yourself to the list, with your pgp key (see docs on the wiki) greetings! i am Tom Yates, i live in Cambridge, UK, whence i've spent the past six years running a small free software consultancy business (http://www.gatekeeper.ltd.uk). most other biographical information can be found at http://www.teaparty.net/cv/tom/ . briefly, my historical qualifications are fifteen years of unix sysadminning, and co-authorship of "Building Linux and OpenBSD Firewalls" (Wiley, 2000). i have no idea why you should trust me; that's your call. my specific RH legacy interest is RH9, as teaparty.net is a colocated server running RH9. all my home boxes are at various versions of FC, but as teaparty.net is near the other Cambridge (Massachusetts), upgrading it isn't likely to happen any time soon. i am very grateful to the FL project for enabling me to keep it in patch without having to fly over and upgrade. teaparty.net isn't just a vanity box. it provides a smorgasbord of shell, webmail, mailing lists, IMAPS/POPS, spam filtering, DNS hosting, web hosting and/or redirection, secure socks proxying, and like services, from which a community of about 25 non-paying, personally-known users select the services they wish to use. i also maintain a second server, hosted by a kind donor company in cambridge, which provides a deployment platform for linux-oriented tibetans who operate out of dharamsala, in north india. there's a long story behind that one. i'm currently applying anything relevant to either box as soon as it appears in updates-testing, so my aim for the project is to provide feedback on these packages in a live environment. i'm looking at using FL to support a number of production RH73 boxes for a client of mine, so later, i may be able to provide feedback on 73 builds as well. my key is appended. i do apologise, but for hysterical raisins my list- subscription address (madlists@) is *not* my main email address, and isn't on the key. for the avoidance of doubt: i do everything *except* post to mailing lists as madhatter@, which *is* on the key, so please don't let the slight mismatch between the usernames confuse you. the 1024 bit key's fingerprint is 8AAC D1B1 FCA8 1019 99B1 9D65 78FB 6F29 5DF5 CF0E. > * Report your results as a pgp clearsigned message to the Bugzilla system. > If you are voting for a publish state, then make this clear in the message > (such as putting in it "I VOTE TO PUBLISH" or "PUBLISH++"). a question of nomenclature is "publish" the decision to move stuff into updates-testing, or from updates-testing to updates? - -- Tom Yates Cambridge, UK. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Peace, Long Life and Free Software! iD8DBQFBQr2aePtvKV31zw4RAh0ZAJ9GpPUrAdJ2MR21JgA97UBGqEL+7wCfZOJR PveZwQ+GJMHsd5Pbra3gREs= =4CtB -----END PGP SIGNATURE----- -------------- next part -------------- -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v1.2.4 (GNU/Linux) mQGiBD9BDkgRBADSISSFThSDsOWJDPgQBuNx7lxxBjsJFy7EEDeCSxMyBoSnPDyt tD0bqho/G7uH1OUvnB7HtSHIIxc2JBdDTbPswzemXQJIUUqLagSZT0M/IgPoBUcK 5VDeN8Hy8TcN535EGEhWOkJwJWSWCK+0Z8Y9uKQvru1WrJEZR3253E2mxwCg40jZ aSk5mpMCkyDfucvof4zwoHUD/jZwTlhIJ7ws3M+Vpj1KzhWB7SJlQ8YYn46nODiX cymdh0wZECTKnXirdyHHnpAeOw8F4CYxvglpDKOYz8xhhHNGovIEzRpZHPC0TdO3 MJfZwm/wpE1MTQazwYY8BZCoGGpkEj+a89/+PYLVhwLW/a0CZ5DzKEPXF6Ht3z3Z ZTE/A/48ENIF4HJXqV+RzQemk1Gvd6u90SMOq2Ge0m2bHewzvdwBCMEvUymiKbuF 721gj8J7fTDwP7/X3tZZCWGP+rxQjyWmAbmMTD42lRoCdBCT0W2HuISWkrBQcX+W uXgNYXfgFQqDAIvX5NyenZaGZSKIpAV/8lIG5zWU9CpwuqUu5rQkVG9tIFlhdGVz IDx0eWF0ZXNAZ2F0ZWtlZXBlci5sdGQudWs+iGUEExECACUFAj9BIFECGwMFCQlm AYAHCwkIBwMCAQMVAgMDFgIBAh4BAheAAAoJEHj7byld9c8Ow4wAoMcZOAV6l6fx frGMvLFpcdHWsUrKAJ4uj5C+2LPOgOa3fO9XshxOmLkgrYiiBBMBAgAMBQI/QSlP BYMJZeZ5AAoJELPFuX/P39459jQD/0ZvQwU9RmRv9Mxp0eilQrzP6w5QW/MYuGeN hBAefwmEN6Nq3xN3gc8HiGalkqbr7QmUdNBiv7Bp0lB2dUMXl+dQlH1DlIqcK+N6 iZWGNZq/FAZFWckVT7KT5ihqfjY5FQ9b4OrN8fYPVTRhRyGSXN+ZdBgXWqELEkee 5RKEIoD5tCJUb20gWWF0ZXMgPG1hZGhhdHRlckB0ZWFwYXJ0eS5uZXQ+iGEEExEC ACEFAj9BDkgFCQlmAYAGCwkIBwMCAxUCAwMWAgECHgECF4AACgkQePtvKV31zw6z +QCdFI/9suqyfM5VqHxXt8DuHlrt54MAnjc4yJNeDyO6Jzl8BEXhu/g2E/3iiKIE EwECAAwFAj9BKU8Fgwll5nkACgkQs8W5f8/f3jnsyAP/UuM3UO8bQ55YoC+4ba3h xM+XwiEw0MDXGn/nkY3mxRy4RI9oLJ6XveK5/LUML/UJKfBeMYr/Mg74R6jfwapW ygNw05WESgKxZQEFthIGom9O6f7tbPbt4raWbRoqU7+828f52t0xiWGTqQzE1okO rdHTRKf3+LQFiFpqY9Ohnyq5Ag0EP0EOxxAIAJHwuelJcQOWTG6jh2xsuaf0hdbR l96zLLOAW3UgQw8V8jpocUqB039iimeMt1Dk8AgM84zttDavysrx7/yRi0oywaAU nf8/vnwMrlvh5CoKW5Dqyub4dqQoF4HvWx5jwWzRXAh3Qtqixu01n7brUudBAel7 F0aC2XsK+u/8zCTssP6X3NcS2EpKIsoTWpPkepdiyl5LO6pYX0uO5Hz38EYb7JX7 BFKlEUylUv95eJ/Kwu37C6zzxMPkjOIcRPYO5a39x8ijEZyNZg5h0xXQoNmcb24Z KineY5Er/Ztz5RCRTCuhkCU5r/GG/JmNSDGIHeVT3SXhOSokKsjq9liJbmMAAwUI AI+wKHFfgmenU3VeHRinGs0+GDyaIAk30ONQ+VuUEBB/e84wMuK0zSz1VqLhvzS4 apKYwRGMnNuWO7TdZHg09r+p3ZZZuRor5n5innxIf0gkt1DaNK0JE4kCdoJNYAHc 5gCyQSp6GEZsxDdFEwVqZD/xgCfxWAbizJmalPP+JYIZzfd/eEqJcJ6CN2hUB5qa x1wfA4G1/5eruC9j7/771MPd9+DFdNvvAzyJ2UXEtCPHf2UAlBs+HiqugVy+jqK/ BwHZDo3HFm3M3oaG4u5FvnSXexPNZWaoZyVPD+fdTv8xuIR1ipki6w+/8nmmo+UC knNuKnDOWlsmKXf1OAtMSWiITAQYEQIADAUCP0EOxwUJCWYBgAAKCRB4+28pXfXP DjJnAKC7FGmBHgYkrjk8UqbJs9lZF1wh6QCg27qp3LoJvc9LTVBJ7lUo+z1LoX4= =hd4r -----END PGP PUBLIC KEY BLOCK----- From jonny.strom at netikka.fi Sat Sep 11 09:41:35 2004 From: jonny.strom at netikka.fi (Johnny Strom) Date: Sat, 11 Sep 2004 12:41:35 +0300 Subject: Self-Introduction: Tom Yates In-Reply-To: References: <002301c4968f$488e6dc0$3f01a8c0@Eucke><20040909170526.GH26041@tirian.magd.ox.ac.uk> <1094753496.6d8ae099a0b95@mail.ph.utexas.edu> <005601c4969a$5411f710$3f01a8c0@Eucke> <1094759505.16d2b1497aabd@mail.ph.utexas.edu> Message-ID: <4142C84F.4010805@netikka.fi> Tom Yates wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Thu, 9 Sep 2004, Eric Rostetter wrote: > >> Basic steps are: >> > [stuff i've done already] > >> * Introduce yourself to the list, with your pgp key (see docs on the >> wiki) > > > greetings! i am Tom Yates, i live in Cambridge, UK, whence i've spent > the past six years running a small free software consultancy business > (http://www.gatekeeper.ltd.uk). most other biographical information can > be found at http://www.teaparty.net/cv/tom/ . briefly, my historical > qualifications are fifteen years of unix sysadminning, and co-authorship > of "Building Linux and OpenBSD Firewalls" (Wiley, 2000). i have no idea > why you should trust me; that's your call. > > my specific RH legacy interest is RH9, as teaparty.net is a colocated > server running RH9. all my home boxes are at various versions of FC, > but as teaparty.net is near the other Cambridge (Massachusetts), > upgrading it isn't likely to happen any time soon. i am very grateful > to the FL project for enabling me to keep it in patch without having to > fly over and upgrade. > > teaparty.net isn't just a vanity box. it provides a smorgasbord of > shell, webmail, mailing lists, IMAPS/POPS, spam filtering, DNS hosting, > web hosting and/or redirection, secure socks proxying, and like > services, from which a community of about 25 non-paying, > personally-known users select the services they wish to use. > > i also maintain a second server, hosted by a kind donor company in > cambridge, which provides a deployment platform for linux-oriented > tibetans who operate out of dharamsala, in north india. there's a long > story behind that one. > > i'm currently applying anything relevant to either box as soon as it > appears in updates-testing, so my aim for the project is to provide > feedback on these packages in a live environment. i'm looking at using > FL to support a number of production RH73 boxes for a client of mine, so > later, i may be able to provide feedback on 73 builds as well. > > my key is appended. i do apologise, but for hysterical raisins my list- > subscription address (madlists@) is *not* my main email address, and > isn't on the key. for the avoidance of doubt: i do everything *except* > post to mailing lists as madhatter@, which *is* on the key, so please > don't let the slight mismatch between the usernames confuse you. the > 1024 bit key's fingerprint is 8AAC D1B1 FCA8 1019 99B1 9D65 78FB 6F29 > 5DF5 CF0E. > >> * Report your results as a pgp clearsigned message to the Bugzilla >> system. >> If you are voting for a publish state, then make this clear in the >> message >> (such as putting in it "I VOTE TO PUBLISH" or "PUBLISH++"). > > > a question of nomenclature is "publish" the decision to move stuff into > updates-testing, or from updates-testing to updates? > You add publish when you have tested a package and then when two ppl have done that we can move it to updates-testing. This is one area where we need ppl so please QA packages. > > - -- > Tom Yates > Cambridge, UK. > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.4 (GNU/Linux) > Comment: Peace, Long Life and Free Software! > > iD8DBQFBQr2aePtvKV31zw4RAh0ZAJ9GpPUrAdJ2MR21JgA97UBGqEL+7wCfZOJR > PveZwQ+GJMHsd5Pbra3gREs= > =4CtB > -----END PGP SIGNATURE----- > > > ------------------------------------------------------------------------ > > -----BEGIN PGP PUBLIC KEY BLOCK----- > Version: GnuPG v1.2.4 (GNU/Linux) > > mQGiBD9BDkgRBADSISSFThSDsOWJDPgQBuNx7lxxBjsJFy7EEDeCSxMyBoSnPDyt > tD0bqho/G7uH1OUvnB7HtSHIIxc2JBdDTbPswzemXQJIUUqLagSZT0M/IgPoBUcK > 5VDeN8Hy8TcN535EGEhWOkJwJWSWCK+0Z8Y9uKQvru1WrJEZR3253E2mxwCg40jZ > aSk5mpMCkyDfucvof4zwoHUD/jZwTlhIJ7ws3M+Vpj1KzhWB7SJlQ8YYn46nODiX > cymdh0wZECTKnXirdyHHnpAeOw8F4CYxvglpDKOYz8xhhHNGovIEzRpZHPC0TdO3 > MJfZwm/wpE1MTQazwYY8BZCoGGpkEj+a89/+PYLVhwLW/a0CZ5DzKEPXF6Ht3z3Z > ZTE/A/48ENIF4HJXqV+RzQemk1Gvd6u90SMOq2Ge0m2bHewzvdwBCMEvUymiKbuF > 721gj8J7fTDwP7/X3tZZCWGP+rxQjyWmAbmMTD42lRoCdBCT0W2HuISWkrBQcX+W > uXgNYXfgFQqDAIvX5NyenZaGZSKIpAV/8lIG5zWU9CpwuqUu5rQkVG9tIFlhdGVz > IDx0eWF0ZXNAZ2F0ZWtlZXBlci5sdGQudWs+iGUEExECACUFAj9BIFECGwMFCQlm > AYAHCwkIBwMCAQMVAgMDFgIBAh4BAheAAAoJEHj7byld9c8Ow4wAoMcZOAV6l6fx > frGMvLFpcdHWsUrKAJ4uj5C+2LPOgOa3fO9XshxOmLkgrYiiBBMBAgAMBQI/QSlP > BYMJZeZ5AAoJELPFuX/P39459jQD/0ZvQwU9RmRv9Mxp0eilQrzP6w5QW/MYuGeN > hBAefwmEN6Nq3xN3gc8HiGalkqbr7QmUdNBiv7Bp0lB2dUMXl+dQlH1DlIqcK+N6 > iZWGNZq/FAZFWckVT7KT5ihqfjY5FQ9b4OrN8fYPVTRhRyGSXN+ZdBgXWqELEkee > 5RKEIoD5tCJUb20gWWF0ZXMgPG1hZGhhdHRlckB0ZWFwYXJ0eS5uZXQ+iGEEExEC > ACEFAj9BDkgFCQlmAYAGCwkIBwMCAxUCAwMWAgECHgECF4AACgkQePtvKV31zw6z > +QCdFI/9suqyfM5VqHxXt8DuHlrt54MAnjc4yJNeDyO6Jzl8BEXhu/g2E/3iiKIE > EwECAAwFAj9BKU8Fgwll5nkACgkQs8W5f8/f3jnsyAP/UuM3UO8bQ55YoC+4ba3h > xM+XwiEw0MDXGn/nkY3mxRy4RI9oLJ6XveK5/LUML/UJKfBeMYr/Mg74R6jfwapW > ygNw05WESgKxZQEFthIGom9O6f7tbPbt4raWbRoqU7+828f52t0xiWGTqQzE1okO > rdHTRKf3+LQFiFpqY9Ohnyq5Ag0EP0EOxxAIAJHwuelJcQOWTG6jh2xsuaf0hdbR > l96zLLOAW3UgQw8V8jpocUqB039iimeMt1Dk8AgM84zttDavysrx7/yRi0oywaAU > nf8/vnwMrlvh5CoKW5Dqyub4dqQoF4HvWx5jwWzRXAh3Qtqixu01n7brUudBAel7 > F0aC2XsK+u/8zCTssP6X3NcS2EpKIsoTWpPkepdiyl5LO6pYX0uO5Hz38EYb7JX7 > BFKlEUylUv95eJ/Kwu37C6zzxMPkjOIcRPYO5a39x8ijEZyNZg5h0xXQoNmcb24Z > KineY5Er/Ztz5RCRTCuhkCU5r/GG/JmNSDGIHeVT3SXhOSokKsjq9liJbmMAAwUI > AI+wKHFfgmenU3VeHRinGs0+GDyaIAk30ONQ+VuUEBB/e84wMuK0zSz1VqLhvzS4 > apKYwRGMnNuWO7TdZHg09r+p3ZZZuRor5n5innxIf0gkt1DaNK0JE4kCdoJNYAHc > 5gCyQSp6GEZsxDdFEwVqZD/xgCfxWAbizJmalPP+JYIZzfd/eEqJcJ6CN2hUB5qa > x1wfA4G1/5eruC9j7/771MPd9+DFdNvvAzyJ2UXEtCPHf2UAlBs+HiqugVy+jqK/ > BwHZDo3HFm3M3oaG4u5FvnSXexPNZWaoZyVPD+fdTv8xuIR1ipki6w+/8nmmo+UC > knNuKnDOWlsmKXf1OAtMSWiITAQYEQIADAUCP0EOxwUJCWYBgAAKCRB4+28pXfXP > DjJnAKC7FGmBHgYkrjk8UqbJs9lZF1wh6QCg27qp3LoJvc9LTVBJ7lUo+z1LoX4= > =hd4r > -----END PGP PUBLIC KEY BLOCK----- > > > ------------------------------------------------------------------------ > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-legacy-list From dom at earth.li Sat Sep 11 14:27:14 2004 From: dom at earth.li (Dominic Hargreaves) Date: Sat, 11 Sep 2004 15:27:14 +0100 Subject: Problem with bugzilla CCs In-Reply-To: <1094826206.4639.0.camel@mdlinux> References: <20040910124206.GJ26041@tirian.magd.ox.ac.uk> <1094826206.4639.0.camel@mdlinux> Message-ID: <20040911142714.GM26041@tirian.magd.ox.ac.uk> On Fri, Sep 10, 2004 at 10:23:41AM -0400, Marc Deslauriers wrote: > On Fri, 2004-09-10 at 08:42, Dominic Hargreaves wrote: > > Is there a known problem with the bugzilla's mail system? It's failed to > > send me quite a few CCs over the last week or so (and yes, my > > preferences do indicate that I should be receiving them). > > I got a bunch of your CCs...Do you have any one in particular you know > you didn't get so I can check if I got it? It turns out that the earth.li mail server was failing to callback to bugzilla.fedora.us and hence rejecting the mails. The check's been exempted and I'm getting things now. Dominic. From dom at earth.li Sat Sep 11 23:40:04 2004 From: dom at earth.li (Dominic Hargreaves) Date: Sun, 12 Sep 2004 00:40:04 +0100 Subject: Round-up, 2004-09-12 Message-ID: <20040911234004.GO26041@tirian.magd.ox.ac.uk> We're making good progress now - let's get some more packages ready so we can really hammer the build server when it's ready :) $Id: issues.txt,v 1.16 2004/09/11 14:35:12 dom Exp $ See bottom for changes This list is also available at http://www-astro.physics.ox.ac.uk/~dom/legacy/issues.txt Packages that have been verified and should be fully released ------------------------------------------------------------- tcpdump - https://bugzilla.fedora.us/show_bug.cgi?id=1468 cadaver - https://bugzilla.fedora.us/show_bug.cgi?id=1552 flim - https://bugzilla.fedora.us/show_bug.cgi?id=1581 Packages waiting to be built for updates-testing ------------------------------------------------ gaim - https://bugzilla.fedora.us/show_bug.cgi?id=1237 lha - https://bugzilla.fedora.us/show_bug.cgi?id=1833 Packages in state RESOLVED (ie exist in updates-testing) that need active work. ------------------------------------------------------------------ mailman - https://bugzilla.fedora.us/show_bug.cgi?id=1269 There were some unconfirmed reports of breakage with the candidate. This needs more QA before release. mod_python - https://bugzilla.fedora.us/show_bug.cgi?id=1325 Needs 2 VERIFY before release. ethereal - https://bugzilla.fedora.us/show_bug.cgi?id=1419 Needs 2 VERIFY before release. - but dup with 1840? kernel - https://bugzilla.fedora.us/show_bug.cgi?id=1484 Needs missing file rebuilt for verification - but preferentially put work into later kernel ticket mozilla - https://bugzilla.fedora.us/show_bug.cgi?id=1532 Needs 2 VERIFY but has been superceded lha - https://bugzilla.fedora.us/show_bug.cgi?id=1547 Needs 2 VERIFY but has been superceded rsync - https://bugzilla.fedora.us/show_bug.cgi?id=1569 Needs 1 VERIFY but has been superceded. squid - https://bugzilla.fedora.us/show_bug.cgi?id=1732 Needs 1 VERIFY before release (but about to be superceded?) squirrelmail - https://bugzilla.fedora.us/show_bug.cgi?id=1733 Needs 1 VERIFY before release (also double check no new issues have cropped up) xchat - https://bugzilla.fedora.us/show_bug.cgi?id=1549 Needs 1 VERIFY for rh9 before release. Packages in state UNCONFIRMED, NEW, ASSIGNED or REOPENED: -------------------------------------------------------- * yum - https://bugzilla.fedora.us/show_bug.cgi?id=1583 IMO this shouldn't be in the Package Request component close WONTFIX re rh8? vsftp - https://bugzilla.fedora.us/show_bug.cgi?id=1778 Resolution of whether we are vulnerable needed. * kernel - https://bugzilla.fedora.us/show_bug.cgi?id=1797 VM (non-security) bug in rh9 that was never fixed before EOL. Looks to me like this should be closed WONTFIX. * rpm - https://bugzilla.fedora.us/show_bug.cgi?id=1864 No rationale given for bug request - the rh bug it refers to dates from before rh7.3 EOL. WONTFIX? * readline - https://bugzilla.fedora.us/show_bug.cgi?id=2017 Another not fixed before EOL (rh9). WONTFIX? XFree86 - https://bugzilla.fedora.us/show_bug.cgi?id=1289 This has had 2 PUBLISHes for 7.3 and the only problem holding it back was likely a gdk-pixbuf red herring. Packages should be built for this and pushed to updates-testing I think. netpbm - https://bugzilla.fedora.us/show_bug.cgi?id=1257 Needs 2 PUBLISH kdelibs - https://bugzilla.fedora.us/show_bug.cgi?id=1373 Needs 2 PUBLISH (superceded) * cal - https://bugzilla.fedora.us/show_bug.cgi?id=1439 Should be closed WONTFIX IMO yum - https://bugzilla.fedora.us/show_bug.cgi?id=1604 Needs 2 PUBLISH mod_ssl - https://bugzilla.fedora.us/show_bug.cgi?id=1708 Needs 2 PUBLISH for rh9 mod_ssl - https://bugzilla.fedora.us/show_bug.cgi?id=1888 Needs 1 PUBLISH for rh7.3 krb5 - https://bugzilla.fedora.us/show_bug.cgi?id=1726 Obsoleted mod_proxy - https://bugzilla.fedora.us/show_bug.cgi?id=1737 Has 2 PUBLISH, build packages for updates-testing or fix further minor non-security issues libxml - https://bugzilla.fedora.us/show_bug.cgi?id=1324 Sort out confusion over status over version in updates-testing and add RESOLVED flag. gdk-pixbuf - https://bugzilla.fedora.us/show_bug.cgi?id=1371 Packages built for updates-testing and/or a couple of formal PUBLISH needed. sysstat - https://bugzilla.fedora.us/show_bug.cgi?id=1372 Need 2 PUBLISH - 7.3 only I think mc - https://bugzilla.fedora.us/show_bug.cgi?id=1548 Need 2 PUBLISH (but superceded?) libpng - https://bugzilla.fedora.us/show_bug.cgi?id=1550 Superceded libpng - https://bugzilla.fedora.us/show_bug.cgi?id=1943 Need 1 PUBLISH for rh9 tripwire - https://bugzilla.fedora.us/show_bug.cgi?id=1719 Resolve problems with how to version and build fix kernel - https://bugzilla.fedora.us/show_bug.cgi?id=1804 Need 2 PUBLISH apache - https://bugzilla.fedora.us/show_bug.cgi?id=1805 Is this redundant? XFree86 - https://bugzilla.fedora.us/show_bug.cgi?id=1831 Needs 2 PUBLISH mysql - https://bugzilla.fedora.us/show_bug.cgi?id=1832 Needs 1 PUBLISH but superceded? mozilla - https://bugzilla.fedora.us/show_bug.cgi?id=1834 Needs 1 PUBLISH for rh9 + rebuilt galeon SRPM with fixed build-deps ethereal - https://bugzilla.fedora.us/show_bug.cgi?id=1840 Needs PUBLISH for rh9 php - https://bugzilla.fedora.us/show_bug.cgi?id=1868 Needs PUBLISH, especially for rh7.3 abiword - https://bugzilla.fedora.us/show_bug.cgi?id=1906 Needs PUBLISH, especially for rh9 subversion - https://bugzilla.fedora.us/show_bug.cgi?id=1907 Analysis and build fixed packages samba - https://bugzilla.fedora.us/show_bug.cgi?id=1924 Needs PUBLISH, especially for rh9 gnome vfs - https://bugzilla.fedora.us/show_bug.cgi?id=1944 Needs 2 PUBLISH sox - https://bugzilla.fedora.us/show_bug.cgi?id=1945 Needs PUBLISH - rh9 status? glibc - https://bugzilla.fedora.us/show_bug.cgi?id=1947 Needs PUBLISH qt - https://bugzilla.fedora.us/show_bug.cgi?id=2002 Needs 2 PUBLISH rsync - https://bugzilla.fedora.us/show_bug.cgi?id=2003 Needs PUBLISH gdk-pixbuf - https://bugzilla.fedora.us/show_bug.cgi?id=2005 Analyse and see whether relevant mysql - https://bugzilla.fedora.us/show_bug.cgi?id=2006 Needs 2 PUBLISH ruby - https://bugzilla.fedora.us/show_bug.cgi?id=2007 needs work kdelibs - https://bugzilla.fedora.us/show_bug.cgi?id=2008 Needs 2 PUBLISH mc - https://bugzilla.fedora.us/show_bug.cgi?id=2009 Needs work pam_wheel - https://bugzilla.fedora.us/show_bug.cgi?id=2010 Needs PUBLISH and full auditing? krb5 - https://bugzilla.fedora.us/show_bug.cgi?id=2040 Needs 1 PUBLISH for rh9 * kernel - https://bugzilla.fedora.us/show_bug.cgi?id=1614 close WONTFIX? Reporter gone AWOL. imlib - https://bugzilla.fedora.us/show_bug.cgi?id=2051 Needs 2 PUBLISH + new packages with proper versioning (pending from me) ImageMagick - https://bugzilla.fedora.us/show_bug.cgi?id=2052 Needs PUBLISH for rh7.3 and packages for rh9 squid - https://bugzilla.fedora.us/show_bug.cgi?id=2053 Needs 2 PUBLISH samba - https://bugzilla.fedora.us/show_bug.cgi?id=2057 Investigate/prepare packages - not vulnerable - release previous cdrecord - https://bugzilla.fedora.us/show_bug.cgi?id=2058 Investigate/prepare packages General (non-package bugs) -------------------------- * https://bugzilla.fedora.us/show_bug.cgi?id=1599 applies to rh8 only - WONTFIX? * https://bugzilla.fedora.us/show_bug.cgi?id=1437 applies to rh8 only - WONTFIX? * https://bugzilla.fedora.us/show_bug.cgi?id=1586 applies to rh8 only - WONTFIX? https://bugzilla.fedora.us/show_bug.cgi?id=1963 Website needs fixing https://bugzilla.fedora.us/show_bug.cgi?id=1652 Website fix? Notes ----- Needs PUBLISH means that there are packages available for QA that need to be QAd at the source level. Needs VERIFY means that there are updates-testing packages that need testing. This is the easy bit, let's get this old ones out of the way ASAP. * means that there is a judgement call that can be made on the bug system immediately. Please follow up onlist with opinions. Changes ------- $Log: issues.txt,v $ Revision 1.16 2004/09/11 14:35:12 dom XFree86 (1831) needs QA mysql has packages kdelibs has packages mod_ssl (2041) removed squid has packages Revision 1.15 2004/09/10 17:33:09 dom move flim to to-be-released add to be-built-for-updates-testing section, move gaim, lha there one less verify for squirrelmail xhat needs rh9 verify mod_ssl not superceded libpng needs publish for rh9 mozilla needs rh9 publish plus fixed galeon package qt needs publis pam_wheel needs publish and full auditing krb5 needs publish for rh9 mod_ssl redundant? imlib needs publish, and package pending from me imagemagick needs publish and rh9 package squid superceded? cdrtools was dup, removed samba not vulnerable Revision 1.14 2004/09/10 10:27:40 dom add cdrtools, samba, cdreocrd Revision 1.13 2004/09/09 23:14:21 dom xchat has a verify Revision 1.12 2004/09/09 23:06:48 dom cadaver is now releasable Revision 1.11 2004/09/09 22:53:09 dom imlib packages Revision 1.10 2004/09/09 16:11:25 dom remove zlib Revision 1.9 2004/09/09 16:06:42 dom new krb5 packages Revision 1.8 2004/09/08 23:38:03 dom move tcpdump to release pile update cadaver, flim, squid add imlib, imagemagick, squid Revision 1.7 2004/09/08 22:58:17 dom new lha packages Revision 1.6 2004/09/08 16:46:13 dom gaim -> need publish, fix broken ethereal URL Revision 1.5 2004/09/08 12:42:32 dom tcpdump needs rh9 verify Revision 1.4 2004/09/08 11:50:55 dom no changes Revision 1.2 2004/09/08 01:23:41 dom add tags -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 232 bytes Desc: not available URL: From madlists at teaparty.net Sun Sep 12 16:22:48 2004 From: madlists at teaparty.net (Tom Yates) Date: Sun, 12 Sep 2004 17:22:48 +0100 (BST) Subject: how to get sha1sum of an installed package In-Reply-To: <20040911234004.GO26041@tirian.magd.ox.ac.uk> References: <20040911234004.GO26041@tirian.magd.ox.ac.uk> Message-ID: in the case of the mailman package, i installed it directly from updates-testing using yum, but the package has been deleted from my yum cache (by me doing a yum clean). does anyone know how i can either get the sha1sum of the installed package (ie, reconstruct the .rpm file from my installed version), or how i can verify that the package i have installed matches the .rpm currently in updates-testing? otherwise, i can't put a sha1sum of the .rpm in my VERIFY report. any bright ideas gratefully received. -- Tom Yates Cambridge, UK. From dom at earth.li Sun Sep 12 22:17:24 2004 From: dom at earth.li (Dominic Hargreaves) Date: Sun, 12 Sep 2004 23:17:24 +0100 Subject: FC1 support is ours... Message-ID: <20040912221724.GT26041@tirian.magd.ox.ac.uk> According to http://fedora.redhat.com/ we are supporting FC1 from tomorrow :) We should get some docs up on the web site regarding our FC1 support, and prepare the build/download system etc. Since I'm not involved in liasing with the Fedora Steering Committee this isn't an official word but with FL the key is frequent gentle nudges :) If anyone would care to give me CVS access I'd be happy to help in preparing web site updates. Cheers, Dominic. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 232 bytes Desc: not available URL: From dom at earth.li Sun Sep 12 22:20:41 2004 From: dom at earth.li (Dominic Hargreaves) Date: Sun, 12 Sep 2004 23:20:41 +0100 Subject: FC1 support is ours... In-Reply-To: <20040912221724.GT26041@tirian.magd.ox.ac.uk> References: <20040912221724.GT26041@tirian.magd.ox.ac.uk> Message-ID: <20040912222041.GU26041@tirian.magd.ox.ac.uk> On Sun, Sep 12, 2004 at 11:17:24PM +0100, Dominic Hargreaves wrote: > According to http://fedora.redhat.com/ we are supporting FC1 from > tomorrow :) We should get some docs up on the web site regarding our FC1 > support, and prepare the build/download system etc. Since I'm not > involved in liasing with the Fedora Steering Committee this isn't an > official word but with FL the key is frequent gentle nudges :) Correction: http://fedora.redhat.com/participate/schedule/ says that FC3 test2 is currently aiming for 20th Sept (which corresponds to us taking over FC1 at that time). All the rest of what I said stands, of course. Dominic. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 232 bytes Desc: not available URL: From dom at earth.li Mon Sep 13 01:01:07 2004 From: dom at earth.li (Dominic Hargreaves) Date: Mon, 13 Sep 2004 02:01:07 +0100 Subject: how to get sha1sum of an installed package In-Reply-To: References: <20040911234004.GO26041@tirian.magd.ox.ac.uk> Message-ID: <20040913010107.GX26041@tirian.magd.ox.ac.uk> On Sun, Sep 12, 2004 at 05:22:48PM +0100, Tom Yates wrote: > in the case of the mailman package, i installed it directly from > updates-testing using yum, but the package has been deleted from my yum > cache (by me doing a yum clean). does anyone know how i can either get > the sha1sum of the installed package (ie, reconstruct the .rpm file from > my installed version), or how i can verify that the package i have > installed matches the .rpm currently in updates-testing? Hi, I don't know of a way to do this. I suggest you download the RPM manually and forcibly reinstall it or remove/install it. Cheers, Dominic. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 232 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Mon Sep 13 10:13:45 2004 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 13 Sep 2004 12:13:45 +0200 Subject: FC1 support is ours... In-Reply-To: <20040912221724.GT26041@tirian.magd.ox.ac.uk> References: <20040912221724.GT26041@tirian.magd.ox.ac.uk> Message-ID: <20040913101345.GE3968@neu.physik.fu-berlin.de> Hi, On Sun, Sep 12, 2004 at 11:17:24PM +0100, Dominic Hargreaves wrote: > According to http://fedora.redhat.com/ we are supporting FC1 from > tomorrow :) We should get some docs up on the web site regarding our FC1 > support, and prepare the build/download system etc. Since I'm not > involved in liasing with the Fedora Steering Committee this isn't an > official word but with FL the key is frequent gentle nudges :) > > If anyone would care to give me CVS access I'd be happy to help in > preparing web site updates. Even though the schedule has been changed for another week, perhaps already preparing a (legacy-empty) FC1 repo which can be pointed at would be very useful. I could start adding this repo to ATrpms and medley default configs and start deploying it. BTW there were some thoughts on having a fake FC3 legacy repo with matching yum.conf etc. entries in the vendor packages (perhaps commented out) from the very beginning (in order to avoid having to deploy them when FC3 EOLs. Did anything come out of this? -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rostetter at mail.utexas.edu Mon Sep 13 21:42:42 2004 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Mon, 13 Sep 2004 16:42:42 -0500 Subject: FC1 support is ours... In-Reply-To: <20040912221724.GT26041@tirian.magd.ox.ac.uk> References: <20040912221724.GT26041@tirian.magd.ox.ac.uk> Message-ID: <1095111762.f6a5e39c2bcff@mail.ph.utexas.edu> Quoting Dominic Hargreaves : > According to http://fedora.redhat.com/ we are supporting FC1 from > tomorrow :) I think the exact date is a moving target. We probably won't know for sure until it happens. > We should get some docs up on the web site regarding our FC1 > support What I would appreciate is if anyone can provide me with docs on using apt and/or yum with FC1. Basically just modify what is on the web site now for RHL versions to work for FC1... I think FC1 has native yum support (in up2date even?) but I just don't know for sure since I've never run FC1. So I'd ask for help here from FC1 users. > If anyone would care to give me CVS access I'd be happy to help in > preparing web site updates. I'm on top of most of this for the web site, as best as we can be without a firm date. But if you want to help, you can. Best way would be to make apt/yum docs and submit them. Most other changes are minor. You can access the web cvs read-only right now. There are instructions linked off the main web page, or see http://www.fedoralegacy.org/about/webcvs.php You could then submit patches to us, etc. As for write access, that is out of my scope (Jesse is probably the only one who can help there). But certainly you are welcome to do a cvs checkout, install/test it (see the README directory), create patches (cvs diff -u is cool), submit those patches, etc. I'd encourage such patch submissions (to me directory or to the mailing list). > Cheers, > > Dominic. -- Eric Rostetter From paul at frields.com Mon Sep 13 21:49:13 2004 From: paul at frields.com (Paul W. Frields) Date: Mon, 13 Sep 2004 17:49:13 -0400 Subject: FC1 support is ours... In-Reply-To: <1095111762.f6a5e39c2bcff@mail.ph.utexas.edu> References: <20040912221724.GT26041@tirian.magd.ox.ac.uk> <1095111762.f6a5e39c2bcff@mail.ph.utexas.edu> Message-ID: <1095112153.21495.2.camel@bettie.internal.frields.org> On Mon, 2004-09-13 at 17:42, Eric Rostetter wrote: > What I would appreciate is if anyone can provide me with docs on using > apt and/or yum with FC1. Basically just modify what is on the web site > now for RHL versions to work for FC1... > > I think FC1 has native yum support (in up2date even?) but I just don't > know for sure since I've never run FC1. So I'd ask for help here from > FC1 users. Correct on both counts, IIRC. I'm running FC2 now, but when I created a set of yum-aware up2date RPM's for use with FL, they were based on the FC1 releases. -- Paul W. Frields, RHCE From dom at earth.li Mon Sep 13 23:04:44 2004 From: dom at earth.li (Dominic Hargreaves) Date: Tue, 14 Sep 2004 00:04:44 +0100 Subject: FC1 support is ours... In-Reply-To: <1095111762.f6a5e39c2bcff@mail.ph.utexas.edu> References: <20040912221724.GT26041@tirian.magd.ox.ac.uk> <1095111762.f6a5e39c2bcff@mail.ph.utexas.edu> Message-ID: <20040913230444.GZ26041@tirian.magd.ox.ac.uk> On Mon, Sep 13, 2004 at 04:42:42PM -0500, Eric Rostetter wrote: > What I would appreciate is if anyone can provide me with docs on using > apt and/or yum with FC1. Basically just modify what is on the web site > now for RHL versions to work for FC1... > > I think FC1 has native yum support (in up2date even?) but I just don't > know for sure since I've never run FC1. So I'd ask for help here from > FC1 users. Not me then :) > I'm on top of most of this for the web site, as best as we can be without > a firm date. But if you want to help, you can. Best way would be to > make apt/yum docs and submit them. Most other changes are minor. Okay, fair enough. > You can access the web cvs read-only right now. There are instructions > linked off the main web page, or see > > http://www.fedoralegacy.org/about/webcvs.php Those instructions don't cover say what the password for the "legacy at fedoralegacy.org" account is, or describe any anonymous access method unless I'm missing something. Cheers, Dominic. From rostetter at mail.utexas.edu Mon Sep 13 23:07:28 2004 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Mon, 13 Sep 2004 18:07:28 -0500 Subject: Self-Introduction: Tom Yates In-Reply-To: References: <002301c4968f$488e6dc0$3f01a8c0@Eucke><20040909170526.GH26041@tirian.magd.ox.ac.uk> <1094753496.6d8ae099a0b95@mail.ph.utexas.edu> <005601c4969a$5411f710$3f01a8c0@Eucke> <1094759505.16d2b1497aabd@mail.ph.utexas.edu> Message-ID: <1095116848.63a85011c7a02@mail.ph.utexas.edu> Quoting Tom Yates : > > * Report your results as a pgp clearsigned message to the Bugzilla system. > > If you are voting for a publish state, then make this clear in the message > > (such as putting in it "I VOTE TO PUBLISH" or "PUBLISH++"). > > a question of nomenclature is "publish" the decision to move stuff into > updates-testing, or from updates-testing to updates? I think we would understand it in either case. Technically it seems "publish" is to move a package into updates-testing, and "verify" to move it from "updates-testing" to "updates". I'll try to update the wiki for this when I get the time (or someone else can of course do it also). -- Eric Rostetter From rostetter at mail.utexas.edu Mon Sep 13 23:16:17 2004 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Mon, 13 Sep 2004 18:16:17 -0500 Subject: FC1 support is ours... In-Reply-To: <20040913230444.GZ26041@tirian.magd.ox.ac.uk> References: <20040912221724.GT26041@tirian.magd.ox.ac.uk> <1095111762.f6a5e39c2bcff@mail.ph.utexas.edu> <20040913230444.GZ26041@tirian.magd.ox.ac.uk> Message-ID: <1095117377.108aebef81f12@mail.ph.utexas.edu> Quoting Dominic Hargreaves : > > You can access the web cvs read-only right now. There are instructions > > linked off the main web page, or see > > > > http://www.fedoralegacy.org/about/webcvs.php > > Those instructions don't cover say what the password for the > "legacy at fedoralegacy.org" account is, or describe any anonymous access > method unless I'm missing something. Yes and no. IIRC legacy at fedoralegacy.org was the anonymous access, but is no longer working (probably went fubar in the server move). Jesse: can you comment on, or fix, this? > Cheers, > > Dominic. -- Eric Rostetter From dom at earth.li Tue Sep 14 00:38:34 2004 From: dom at earth.li (Dominic Hargreaves) Date: Tue, 14 Sep 2004 01:38:34 +0100 Subject: Round-up, 2004-09-14 Message-ID: <20040914003834.GA26041@tirian.magd.ox.ac.uk> $Id: issues.txt,v 1.23 2004/09/13 23:07:42 dom Exp $ See bottom for changes This list is also available at http://www-astro.physics.ox.ac.uk/~dom/legacy/issues.txt Packages that have been verified and should be fully released ------------------------------------------------------------- tcpdump - https://bugzilla.fedora.us/show_bug.cgi?id=1468 cadaver - https://bugzilla.fedora.us/show_bug.cgi?id=1552 flim - https://bugzilla.fedora.us/show_bug.cgi?id=1581 rsync - https://bugzilla.fedora.us/show_bug.cgi?id=1569 (but superceded) Packages waiting to be built for updates-testing ------------------------------------------------ gaim - https://bugzilla.fedora.us/show_bug.cgi?id=1237 lha - https://bugzilla.fedora.us/show_bug.cgi?id=1833 ethereal - https://bugzilla.fedora.us/show_bug.cgi?id=1840 XFree86 - https://bugzilla.fedora.us/show_bug.cgi?id=1289 mod_proxy - https://bugzilla.fedora.us/show_bug.cgi?id=1737 rsync - https://bugzilla.fedora.us/show_bug.cgi?id=2003 imlib - https://bugzilla.fedora.us/show_bug.cgi?id=2051 Packages in state RESOLVED (ie exist in updates-testing) that need active work. ------------------------------------------------------------------ mailman - https://bugzilla.fedora.us/show_bug.cgi?id=1269 There were some unconfirmed reports of breakage with the candidate. This needs more QA before release. mod_python - https://bugzilla.fedora.us/show_bug.cgi?id=1325 Needs 2 VERIFY before release. ethereal - https://bugzilla.fedora.us/show_bug.cgi?id=1419 Needs 2 VERIFY before release. - but dup with 1840? kernel - https://bugzilla.fedora.us/show_bug.cgi?id=1484 Needs missing file rebuilt for verification - but preferentially put work into later kernel ticket mozilla - https://bugzilla.fedora.us/show_bug.cgi?id=1532 Needs 2 VERIFY but has been superceded lha - https://bugzilla.fedora.us/show_bug.cgi?id=1547 Needs 2 VERIFY but has been superceded squid - https://bugzilla.fedora.us/show_bug.cgi?id=1732 Needs 1 VERIFY before release (but about to be superceded?) squirrelmail - https://bugzilla.fedora.us/show_bug.cgi?id=1733 Needs 1 VERIFY before release (also double check no new issues have cropped up) xchat - https://bugzilla.fedora.us/show_bug.cgi?id=1549 Needs 1 VERIFY for rh9 before release. Packages in state UNCONFIRMED, NEW, ASSIGNED or REOPENED: -------------------------------------------------------- * yum - https://bugzilla.fedora.us/show_bug.cgi?id=1583 IMO this shouldn't be in the Package Request component close WONTFIX re rh8? vsftp - https://bugzilla.fedora.us/show_bug.cgi?id=1778 Resolution of whether we are vulnerable needed. * kernel - https://bugzilla.fedora.us/show_bug.cgi?id=1797 VM (non-security) bug in rh9 that was never fixed before EOL. Looks to me like this should be closed WONTFIX. * rpm - https://bugzilla.fedora.us/show_bug.cgi?id=1864 No rationale given for bug request - the rh bug it refers to dates from before rh7.3 EOL. WONTFIX? * readline - https://bugzilla.fedora.us/show_bug.cgi?id=2017 Another not fixed before EOL (rh9). WONTFIX? netpbm - https://bugzilla.fedora.us/show_bug.cgi?id=1257 Needs 2 PUBLISH kdelibs - https://bugzilla.fedora.us/show_bug.cgi?id=1373 Needs 2 PUBLISH (superceded) * cal - https://bugzilla.fedora.us/show_bug.cgi?id=1439 Should be closed WONTFIX IMO yum - https://bugzilla.fedora.us/show_bug.cgi?id=1604 Needs 2 PUBLISH mod_ssl - https://bugzilla.fedora.us/show_bug.cgi?id=1708 Needs 2 PUBLISH for rh9 mod_ssl - https://bugzilla.fedora.us/show_bug.cgi?id=1888 Needs 1 PUBLISH for rh7.3 krb5 - https://bugzilla.fedora.us/show_bug.cgi?id=1726 Obsoleted libxml - https://bugzilla.fedora.us/show_bug.cgi?id=1324 Sort out confusion over status over version in updates-testing and add RESOLVED flag. gdk-pixbuf - https://bugzilla.fedora.us/show_bug.cgi?id=1371 Packages built for updates-testing and/or a couple of formal PUBLISH needed. sysstat - https://bugzilla.fedora.us/show_bug.cgi?id=1372 Need 2 PUBLISH - 7.3 only I think mc - https://bugzilla.fedora.us/show_bug.cgi?id=1548 Need 2 PUBLISH (but superceded?) libpng - https://bugzilla.fedora.us/show_bug.cgi?id=1550 Superceded libpng - https://bugzilla.fedora.us/show_bug.cgi?id=1943 Need 1 PUBLISH for rh9 tripwire - https://bugzilla.fedora.us/show_bug.cgi?id=1719 Resolve problems with how to version and build fix kernel - https://bugzilla.fedora.us/show_bug.cgi?id=1804 Need 2 PUBLISH apache - https://bugzilla.fedora.us/show_bug.cgi?id=1805 Is this redundant? XFree86 - https://bugzilla.fedora.us/show_bug.cgi?id=1831 Needs 2 PUBLISH mysql - https://bugzilla.fedora.us/show_bug.cgi?id=1832 Needs 1 PUBLISH but superceded? mozilla - https://bugzilla.fedora.us/show_bug.cgi?id=1834 Needs 1 PUBLISH for rh9 + rebuilt galeon SRPM with fixed build-deps php - https://bugzilla.fedora.us/show_bug.cgi?id=1868 Needs PUBLISH, especially for rh7.3 abiword - https://bugzilla.fedora.us/show_bug.cgi?id=1906 Needs PUBLISH, especially for rh9 subversion - https://bugzilla.fedora.us/show_bug.cgi?id=1907 Analysis and build fixed packages samba - https://bugzilla.fedora.us/show_bug.cgi?id=1924 Needs PUBLISH, especially for rh9 gnome vfs - https://bugzilla.fedora.us/show_bug.cgi?id=1944 Needs 2 PUBLISH sox - https://bugzilla.fedora.us/show_bug.cgi?id=1945 Needs PUBLISH for rh9 and possible renaming of rh7.3 package glibc - https://bugzilla.fedora.us/show_bug.cgi?id=1947 Needs PUBLISH qt - https://bugzilla.fedora.us/show_bug.cgi?id=2002 Needs 2 PUBLISH gdk-pixbuf - https://bugzilla.fedora.us/show_bug.cgi?id=2005 Analyse and see whether relevant mysql - https://bugzilla.fedora.us/show_bug.cgi?id=2006 Needs 2 PUBLISH ruby - https://bugzilla.fedora.us/show_bug.cgi?id=2007 needs work kdelibs - https://bugzilla.fedora.us/show_bug.cgi?id=2008 Needs 2 PUBLISH mc - https://bugzilla.fedora.us/show_bug.cgi?id=2009 Needs work pam_wheel - https://bugzilla.fedora.us/show_bug.cgi?id=2010 Needs PUBLISH and full auditing? krb5 - https://bugzilla.fedora.us/show_bug.cgi?id=2040 Needs 1 PUBLISH for rh9 * kernel - https://bugzilla.fedora.us/show_bug.cgi?id=1614 close WONTFIX? Reporter gone AWOL. ImageMagick - https://bugzilla.fedora.us/show_bug.cgi?id=2052 Needs 2 PUBLISH squid - https://bugzilla.fedora.us/show_bug.cgi?id=2053 Needs 2 PUBLISH samba - https://bugzilla.fedora.us/show_bug.cgi?id=2057 Investigate/prepare packages - not vulnerable - release previous cdrecord - https://bugzilla.fedora.us/show_bug.cgi?id=2058 Investigate/prepare packages General (non-package bugs) -------------------------- * https://bugzilla.fedora.us/show_bug.cgi?id=1599 applies to rh8 only - WONTFIX? * https://bugzilla.fedora.us/show_bug.cgi?id=1437 applies to rh8 only - WONTFIX? * https://bugzilla.fedora.us/show_bug.cgi?id=1586 applies to rh8 only - WONTFIX? https://bugzilla.fedora.us/show_bug.cgi?id=1963 Website needs fixing https://bugzilla.fedora.us/show_bug.cgi?id=1652 Website fix? Notes ----- Needs PUBLISH means that there are packages available for QA that need to be QAd at the source level. Needs VERIFY means that there are updates-testing packages that need testing. This is the easy bit, let's get this old ones out of the way ASAP. * means that there is a judgement call that can be made on the bug system immediately. Please follow up onlist with opinions. Changes ------- $Log: issues.txt,v $ Revision 1.23 2004/09/13 23:07:42 dom update sox Revision 1.22 2004/09/13 01:08:36 dom move imlib to updates-testing pile Revision 1.21 2004/09/12 21:32:38 dom move XFree86, mod_proxy, rsync to to-be-built list ImageMagick has packages for rh9 Revision 1.20 2004/09/12 16:42:50 dom old rsync is releasable. Revision 1.19 2004/09/12 15:44:23 dom ethereal needs to be built Revision 1.18 2004/09/12 13:20:37 dom update rsync Revision 1.17 2004/09/12 13:15:07 dom update imlib Revision 1.16 2004/09/11 14:35:12 dom XFree86 (1831) needs QA mysql has packages kdelibs has packages mod_ssl (2041) removed squid has packages Revision 1.15 2004/09/10 17:33:09 dom move flim to to-be-released add to be-built-for-updates-testing section, move gaim, lha there one less verify for squirrelmail xhat needs rh9 verify mod_ssl not superceded libpng needs publish for rh9 mozilla needs rh9 publish plus fixed galeon package qt needs publis pam_wheel needs publish and full auditing krb5 needs publish for rh9 mod_ssl redundant? imlib needs publish, and package pending from me imagemagick needs publish and rh9 package squid superceded? cdrtools was dup, removed samba not vulnerable Revision 1.14 2004/09/10 10:27:40 dom add cdrtools, samba, cdreocrd Revision 1.13 2004/09/09 23:14:21 dom xchat has a verify Revision 1.12 2004/09/09 23:06:48 dom cadaver is now releasable Revision 1.11 2004/09/09 22:53:09 dom imlib packages Revision 1.10 2004/09/09 16:11:25 dom remove zlib Revision 1.9 2004/09/09 16:06:42 dom new krb5 packages Revision 1.8 2004/09/08 23:38:03 dom move tcpdump to release pile update cadaver, flim, squid add imlib, imagemagick, squid Revision 1.7 2004/09/08 22:58:17 dom new lha packages Revision 1.6 2004/09/08 16:46:13 dom gaim -> need publish, fix broken ethereal URL Revision 1.5 2004/09/08 12:42:32 dom tcpdump needs rh9 verify Revision 1.4 2004/09/08 11:50:55 dom no changes Revision 1.2 2004/09/08 01:23:41 dom add tags -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 232 bytes Desc: not available URL: From lists-fedora-legacy-list at sprachgewalt.de Tue Sep 14 00:59:27 2004 From: lists-fedora-legacy-list at sprachgewalt.de (Mike Gerber) Date: Tue, 14 Sep 2004 02:59:27 +0200 Subject: Self-Introduction: Mike Gerber Message-ID: <20040914005927.GA17445@nin.lan.rwsr-xr-x.de> Hi, I'm Mike Gerber and work for LEITWERK GmbH in Germany. We have around a hundred RH7.3 servers for which we still maintain software, so I'm interested in doing QA work and packaging updates. Bye, Mike -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From alexander.dalloz at uni-bielefeld.de Tue Sep 14 01:27:12 2004 From: alexander.dalloz at uni-bielefeld.de (Alexander Dalloz) Date: Tue, 14 Sep 2004 03:27:12 +0200 Subject: FC1 support is ours... Message-ID: <1095125232.10393.347.camel@serendipity.dogma.lan> On Mon, 13 Sep 2004 16:42:42 -0500 Eric Rostetter wrote: > What I would appreciate is if anyone can provide me with docs on using > apt and/or yum with FC1. Basically just modify what is on the web site > now for RHL versions to work for FC1... > > I think FC1 has native yum support (in up2date even?) but I just don't > know for sure since I've never run FC1. So I'd ask for help here from > FC1 users. > Eric Rostetter Hi Eric - hello all! I just subscribed to this list awaiting the point when responsibility for FC1 security updates is handed over to the Fedora Legacy Project. From current schedule it will be in a week. I am still running FC1 hosts and have no interest to upgrade them to FC2 and this way have the need for security fixes in an acceptable time frame. Looking forward ... Eric, reading your requirement for information about yum and apt and update on FC1 I can say, that yum works the same as the yum from Fedora Legacy for RH9. Did you expect something different? RH9: yum --version --> 2.0.3 FC1: yum --version --> 2.0.5 I never used apt on FC1 for anything but short testings. So I cannot say much valuable. up2date on FC1 has the capability to handle yum repositories as well as apt repositories. up2date is independent from yum. It too did not need a subscription to any RHN channel, a subscription attempts even made it useless because it caused a misconfiguration. The RHN applet automatically checks the configured repository for new packages every 4 hours (hard coded). If all is up to date it signalises that with a white check on a blue circle. If updates are available it becomes a white exclamation mark on a red circle. yum and up2date are shipped with FC1. apt is not but available through different repositories like ATrpms.net as well as fedora.us. I think many FC1 users are apt users. A couple of month ago I wrote a small article about the need to configure up2date and yum to point to different servers than the default Redhat main server. The article is still available through http://www.fedoranews.org/contributors/alexander_dalloz/mirror and may be helpful for you Eric. If you knock on your head for all I wrote in this mail and saying "man, this is common ground, no news", then please forgive me. I just jumped into this list and have so far no true impression who plays which role in the project. From Eric's posting I concluded some acknowledgment about the state of the update tools on Fedora Core 1 is needed. Regards Alexander -- Alexander Dalloz | Enger, Germany | GPG key 1024D/ED695653 1999-07-13 Fedora GNU/Linux Core 2 (Tettnang) kernel 2.6.8-1.521smp Serendipity 03:00:56 up 15 days, 17 users, load average: 0.94, 0.68, 0.59 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From philip at wyett.net Tue Sep 14 04:04:33 2004 From: philip at wyett.net (Philip Wyett) Date: Tue, 14 Sep 2004 05:04:33 +0100 Subject: Self-Introduction: Philip Wyett Message-ID: <1095134673.3076.12.camel@wyett> Full leagal name: Philip Wyett. Location: England, Bradford. Profession: Quality Assurance Engineer. Company: A-Novo UK (Salts Mill, Shipley). Goals: - Interested in legacy support of Fedora Core 1. - Interested in the development and QA of patched packages for not only the vanilla FC1 packages that are broken, but updates of packages which would allow the addition of new libraries and applications from rawhide or other sources. Historical qualifications: - GNU linux user and developer since Red Hat 7.3. - Programmer in C, C++, assembler etc. - A prominant part of the Crystal Space 3D SDK development team since 2000. - Contributor (patch, support, testing etc.) to various OSS projects over the years. - My past, present and future contributions to the OSS software community is the basis people should I believe trust me and my work. GPG key ID/fingerprint: pub 1024D/AA1D215E 2003-11-11 Philip Wyett Key fingerprint = B410 A660 0C3A 7597 0EDF 51F1 01C8 0BED AA1D 215E sub 2048g/B62B5583 2003-11-11 Regards -- Philip Wyett Personal Email: philip at wyett.net Website: http://www.wyett.net Work email: pwyett at a-novo.co.uk -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From rostetter at mail.utexas.edu Tue Sep 14 14:40:16 2004 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Tue, 14 Sep 2004 09:40:16 -0500 Subject: FC1 support is ours... In-Reply-To: <1095125232.10393.347.camel@serendipity.dogma.lan> References: <1095125232.10393.347.camel@serendipity.dogma.lan> Message-ID: <1095172816.56072c0034077@mail.ph.utexas.edu> Quoting Alexander Dalloz : > Eric, reading your requirement for information about yum and apt and > update on FC1 I can say, that yum works the same as the yum from Fedora > Legacy for RH9. Did you expect something different? Well, for one, we don't need to have them install a 3rd party yum, since it is in FC1, right? So the installation instructions will be different. Is it installed by default as a standalone program, or not? How about apt? Is it in the standard paths? Does it run as a service by default? Does it include scripts in /etc/rc.d/init.d/ for auto updates? Or a cron job? > I never used apt on FC1 for anything but short testings. So I cannot say > much valuable. Sure you can. Is it part of FC1? What's the package name? As I've said: I've never run FC1, so I know nothing about it. I need low level info like whether yum and apt are even in FC1 or not as standalone applications, etc. > up2date on FC1 has the capability to handle yum repositories as well as > apt repositories. up2date is independent from yum. It too did not need a > subscription to any RHN channel, a subscription attempts even made it > useless because it caused a misconfiguration. The RHN applet > automatically checks the configured repository for new packages every 4 > hours (hard coded). If all is up to date it signalises that with a white > check on a blue circle. If updates are available it becomes a white > exclamation mark on a red circle. So we need a new document about up2date for those who want to use it. And how to configure it (still up in there air actually). And maybe why people might want to use yum/apt instead of up2date, etc. > yum and up2date are shipped with FC1. apt is not but available through > different repositories like ATrpms.net as well as fedora.us. I think > many FC1 users are apt users. Okay, this is the kind of info I need. That means FL should start creating its own apt utility also... > A couple of month ago I wrote a small article about the need to > configure up2date and yum to point to different servers than the default > Redhat main server. The article is still available through > > http://www.fedoranews.org/contributors/alexander_dalloz/mirror > > and may be helpful for you Eric. Thanks for the pointer. Should I take this as permission to copy/paste from your article to the web site? Please confirm/deny. > If you knock on your head for all I wrote in this mail and saying "man, > this is common ground, no news", then please forgive me. I just jumped No, there is useful info in there. But there could be more. :) > into this list and have so far no true impression who plays which role > in the project. From Eric's posting I concluded some acknowledgment > about the state of the update tools on Fedora Core 1 is needed. Exactly. > Regards > > Alexander -- Eric Rostetter From alexander.dalloz at uni-bielefeld.de Tue Sep 14 16:12:07 2004 From: alexander.dalloz at uni-bielefeld.de (Alexander Dalloz) Date: Tue, 14 Sep 2004 18:12:07 +0200 Subject: FC1 support is ours... In-Reply-To: <1095172816.56072c0034077@mail.ph.utexas.edu> References: <1095125232.10393.347.camel@serendipity.dogma.lan> <1095172816.56072c0034077@mail.ph.utexas.edu> Message-ID: <1095178327.10393.438.camel@serendipity.dogma.lan> Am Di, den 14.09.2004 schrieb Eric Rostetter um 16:40: > > Eric, reading your requirement for information about yum and apt and > > update on FC1 I can say, that yum works the same as the yum from Fedora > > Legacy for RH9. Did you expect something different? > > Well, for one, we don't need to have them install a 3rd party yum, since > it is in FC1, right? So the installation instructions will be different. > Is it installed by default as a standalone program, or not? How about apt? > Is it in the standard paths? Does it run as a service by default? Does it > include scripts in /etc/rc.d/init.d/ for auto updates? Or a cron job? yum and up2date are installed by default on FC1 systems. They come with a baisc configuration pointing to the Redhat main server (which was the reason for a lot of problems and why I wrote the article earlier this year). So both tools work with yum repositories and you just have to configure them with /etc/yum.conf and /etc/sysconfig/rhn/sources to let them point to the new Fedora Legacy mirror servers. up2date is capable to handle apt repositories as well. The RHN applet has the limitation to not properly handle FTP servers (you get an error saying so). An instructions paper should too contain instructions and hints for users behind a proxy server. bugzilla.redhat.com has some entries about this. yum comes with an init script to let it run as a nightly cron job. update is a standalone tool. But as said, running the RHN applet it will automatically contact the configured repository each 240 minutes and check for new packages. Once found one it optically inform you with a read flashing circle. > > I never used apt on FC1 for anything but short testings. So I cannot say > > much valuable. > > Sure you can. Is it part of FC1? What's the package name? No, apt is not part of Fedora _Core_ 1. http://atrpms.net/dist/fc1/apt/ http://download.fedora.us/fedora/fedora/1/i386/RPMS.stable/apt-0.5.15cnc6-0.fdr.11.1.i386.rpm http://yarrow.freshrpms.net/rpm.html?id=1048 These are the 3 packaged apt RPMs certainly used by those feeling uncomfortable with yum or up2date on FC1. Each RPM comes with a different default setup. If I may do a suggestion, then contact the packagers and let them adjust their apt RPMs to handle the future Fedora Legacy locations for FC1. I could imagine they would do with favour. > As I've said: I've never run FC1, so I know nothing about it. I need low > level info like whether yum and apt are even in FC1 or not as standalone > applications, etc. I think everyone running an FC1 install does know at least one of the 3 tools and uses at least one of them. > So we need a new document about up2date for those who want to use it. > And how to configure it (still up in there air actually). And maybe > why people might want to use yum/apt instead of up2date, etc. I doubt there are impartitial reasons about preferences for any tool. I feel comfortable with up2date and very rarely used yum on some systems. I have 2 RH9 systems, one using yum with FL and on the other apt. The Fedora Core user's mailing list is full of postings where people have problems with one of the tools or stating they prefer one over an other. Best is, to show how to configure each tool and let people decide their own. Some know apt for instance from Debian and swear on it. Some do because it does not fetch all the header files and is from their point of view much faster than yum and up2date. > Okay, this is the kind of info I need. That means FL should start creating > its own apt utility also... If you prefer. As said above, I would contact the 3 packagers and ask them to adjust their configuration files for the upcoming changes with FC1 (end of "support" by Redhat / Fedora Project and further responsibility by Fedora Legacy). Maybe there is even the will to become an official mirror for FL at any of them. > > A couple of month ago I wrote a small article about the need to > > configure up2date and yum to point to different servers than the default > > Redhat main server. The article is still available through > > > > http://www.fedoranews.org/contributors/alexander_dalloz/mirror > > > > and may be helpful for you Eric. > > Thanks for the pointer. Should I take this as permission to copy/paste > from your article to the web site? Please confirm/deny. Sure, you have my permission to use the article as you like. If you visit the page you see at the bottom "Copyright ? 2003-2004 FedoraNEWS.ORG". I am no lawyer and do not know whether that covers my writings or just the fedoranews.org site in general. > > If you knock on your head for all I wrote in this mail and saying "man, > > this is common ground, no news", then please forgive me. I just jumped > > No, there is useful info in there. But there could be more. :) Let me know what information is lacking. I am willing to help as much as I can. Alexander -- Alexander Dalloz | Enger, Germany | GPG key 1024D/ED695653 1999-07-13 Fedora GNU/Linux Core 2 (Tettnang) kernel 2.6.8-1.521smp Serendipity 17:38:53 up 15 days, 14:55, load average: 0.69, 0.69, 0.71 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From pmatilai at welho.com Tue Sep 14 17:47:12 2004 From: pmatilai at welho.com (Panu Matilainen) Date: Tue, 14 Sep 2004 20:47:12 +0300 Subject: FC1 support is ours... In-Reply-To: <1095178327.10393.438.camel@serendipity.dogma.lan> References: <1095125232.10393.347.camel@serendipity.dogma.lan> <1095172816.56072c0034077@mail.ph.utexas.edu> <1095178327.10393.438.camel@serendipity.dogma.lan> Message-ID: <1095184031.11856.9.camel@chip.laiskiainen.org> On Tue, 2004-09-14 at 19:12, Alexander Dalloz wrote: > Am Di, den 14.09.2004 schrieb Eric Rostetter um 16:40: > > > > Eric, reading your requirement for information about yum and apt and > > > update on FC1 I can say, that yum works the same as the yum from Fedora > > > Legacy for RH9. Did you expect something different? > > > > Well, for one, we don't need to have them install a 3rd party yum, since > > it is in FC1, right? So the installation instructions will be different. > > Is it installed by default as a standalone program, or not? How about apt? > > Is it in the standard paths? Does it run as a service by default? Does it > > include scripts in /etc/rc.d/init.d/ for auto updates? Or a cron job? > > yum and up2date are installed by default on FC1 systems. They come with > a baisc configuration pointing to the Redhat main server (which was the > reason for a lot of problems and why I wrote the article earlier this > year). So both tools work with yum repositories and you just have to > configure them with /etc/yum.conf and /etc/sysconfig/rhn/sources to let > them point to the new Fedora Legacy mirror servers. up2date is capable > to handle apt repositories as well. I'd recommend not relying on up2date with apt repositories as up2date's apt repository support is far from perfect, many installations fail with bogus directory conflict errors: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=106123 > > > > Sure you can. Is it part of FC1? What's the package name? > > No, apt is not part of Fedora _Core_ 1. > > http://atrpms.net/dist/fc1/apt/ > http://download.fedora.us/fedora/fedora/1/i386/RPMS.stable/apt-0.5.15cnc6-0.fdr.11.1.i386.rpm > http://yarrow.freshrpms.net/rpm.html?id=1048 > > These are the 3 packaged apt RPMs certainly used by those feeling > uncomfortable with yum or up2date on FC1. Each RPM comes with a > different default setup. > > If I may do a suggestion, then contact the packagers and let them adjust > their apt RPMs to handle the future Fedora Legacy locations for FC1. I > could imagine they would do with favour. For fedora.us apt package this is a simple matter of just adding the relevant fedora-legacy mirrors to the default repository/mirror list files hosted on fedora.us server and telling people to rerun 'apt-get mirror-select' to enable updates from FL. For others either the users need to add the repositories themselves or the packages need to be modified. - Panu - From mule at umich.edu Tue Sep 14 17:53:17 2004 From: mule at umich.edu (Stephen E. Dudek) Date: Tue, 14 Sep 2004 13:53:17 -0400 Subject: Round-up, 2004-09-14 In-Reply-To: <20040914003834.GA26041@tirian.magd.ox.ac.uk> References: <20040914003834.GA26041@tirian.magd.ox.ac.uk> Message-ID: <1095184397.13561.7.camel@pestilence.themule.net> On Mon, 2004-09-13 at 20:38, Dominic Hargreaves wrote: > $Id: issues.txt,v 1.23 2004/09/13 23:07:42 dom Exp $ > xchat - https://bugzilla.fedora.us/show_bug.cgi?id=1549 > Needs 1 VERIFY for rh9 before release. If I'm not mistaken, this VERIFY should be for rh73, correct? I believe that xchat for Red Hat 9 was fixed by Red Hat on April 29, 2004, as part of their big push to fix a couple of issues before the End-of-Life on April 30, 2004. Thanks, Steve -------------- 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 b.pennacchi at istc.cnr.it Tue Sep 14 19:21:43 2004 From: b.pennacchi at istc.cnr.it (Barbara Pennacchi) Date: Tue, 14 Sep 2004 21:21:43 +0200 Subject: yum broken :p Message-ID: <20040914192143.GA3177@sibannac> Hello, I wrote almost one month ago to seek help with yum broken by updating python. I tried some of the fixes suggested in the replies, but to no avail. Then I went into vacation. Now I'm back. I've read all the back issues of this ml (I receive it in the digest format), to see if somebody else had replied on this subject. But no one did. Obviously I was in such a hurry to close down the store that I forgot to tell those folks that "thankyouverymuch, but it was still broken" :) Alas, I still need to have yum working (so at least I could try upgrading from RH9 to FC2 to have a newer python version :-) To sum it up, both yums, when called upon, keep spitting this: (from the RH9, with yum 2.0.4-1 and python 2.2.2-26: the one where I tried forcing back the former versions then the rpm --rebuilddb -vv) Traceback (most recent call last): File "/usr/bin/yum", line 22, in ? import yummain File "yummain.py", line 21, in ? File "clientStuff.py", line 25, in ? File "pkgaction.py", line 25, in ? File "rpmUtils.py", line 9, in ? File "urlgrabber.py", line 21, in ? File "/usr/lib/python2.2/urllib2.py", line 101, in ? import ftplib File "/usr/lib/python2.2/ftplib.py", line 68, in ? all_errors = (Error, socket.error, IOError, EOFError) AttributeError: 'module' object has no attribute 'error' (from the RH8 upgraded to RH9, with yum 2.0.7-1 and python 2.2.3-26, where I simply removed yum, installed new yum and tried the rpm --rebuilddb -vv) Traceback (most recent call last): File "/usr/bin/yum", line 22, in ? import yummain File "/usr/share/yum/yummain.py", line 22, in ? import clientStuff File "/usr/share/yum/clientStuff.py", line 25, in ? import pkgaction File "/usr/share/yum/pkgaction.py", line 25, in ? import rpmUtils File "/usr/share/yum/rpmUtils.py", line 10, in ? from urlgrabber import URLGrabError File "/usr/share/yum/urlgrabber.py", line 21, in ? import urllib2 File "/usr/lib/python2.2/urllib2.py", line 101, in ? import ftplib File "/usr/lib/python2.2/ftplib.py", line 68, in ? all_errors = (Error, socket.error, IOError, EOFError) AttributeError: 'module' object has no attribute 'error' I tried removing yum with rpm -e and reinstalling, I tried forcing installation of the prior python version, I tried synching yum version with python version. I tried also the rpm --rebuilddb -vv. Nope. Yum is still spitting error messages. Anyone has ideas or pointers ? :( I feel that somewhere, hidden or simply-not-mentioned-explicitly, there is a config file or something similar (environment variables?) that had been overlooked by me and by rpm. -- +--------------------------------------------------------------------+ | WARNING WARNING WARNING *** EMAIL ADDRESS CHANGED! | | USE EMAIL ADDRESS PROVIDED BELOW | | IF YOU KEEP WRITING TO THE OLD ADDRESS IT IS NOT MY FAULT! | +--------------------------------------------------------------------+ | Barbara Pennacchi b.pennacchi at istc.cnr.it | | Consiglio Nazionale delle Ricerche | | Istituto di Scienze e Tecnologie della Cognizione | | V.le Marx 15, 00137 Roma, Italia | | http://www.istc.cnr.it/ | +--------------------------------------------------------------------+ From joseph at ndimedia.com Tue Sep 14 19:45:10 2004 From: joseph at ndimedia.com (S.Joseph) Date: Tue, 14 Sep 2004 15:45:10 -0400 Subject: yum broken :p References: <20040914192143.GA3177@sibannac> Message-ID: <020d01c49a93$587e03a0$336bcac7@BUSAC> I use Apt on my RH9 , I'll try out Yum and let you know how my experience with is goes. ----- Original Message ----- From: "Barbara Pennacchi" To: "Fedora Legacy Project" Sent: Tuesday, September 14, 2004 3:21 PM Subject: yum broken :p > > Hello, I wrote almost one month ago to seek help with yum broken by > updating python. I tried some of the fixes suggested in the replies, but > to no avail. Then I went into vacation. > > Now I'm back. I've read all the back issues of this ml (I receive it in > the digest format), to see if somebody else had replied on this subject. > But no one did. Obviously I was in such a hurry to close down the store > that I forgot to tell those folks that "thankyouverymuch, but it was still > broken" :) > > Alas, I still need to have yum working (so at least I could try upgrading > from RH9 to FC2 to have a newer python version :-) > > To sum it up, both yums, when called upon, keep spitting this: > > (from the RH9, with yum 2.0.4-1 and python 2.2.2-26: the one where I tried > forcing back the former versions then the rpm --rebuilddb -vv) > > Traceback (most recent call last): > File "/usr/bin/yum", line 22, in ? > import yummain > File "yummain.py", line 21, in ? > File "clientStuff.py", line 25, in ? > File "pkgaction.py", line 25, in ? > File "rpmUtils.py", line 9, in ? > File "urlgrabber.py", line 21, in ? > File "/usr/lib/python2.2/urllib2.py", line 101, in ? > import ftplib > File "/usr/lib/python2.2/ftplib.py", line 68, in ? > all_errors = (Error, socket.error, IOError, EOFError) > AttributeError: 'module' object has no attribute 'error' > > > (from the RH8 upgraded to RH9, with yum 2.0.7-1 and python 2.2.3-26, where > I simply removed yum, installed new yum and tried the rpm --rebuilddb -vv) > Traceback (most recent call last): > File "/usr/bin/yum", line 22, in ? > import yummain > File "/usr/share/yum/yummain.py", line 22, in ? > import clientStuff > File "/usr/share/yum/clientStuff.py", line 25, in ? > import pkgaction > File "/usr/share/yum/pkgaction.py", line 25, in ? > import rpmUtils > File "/usr/share/yum/rpmUtils.py", line 10, in ? > from urlgrabber import URLGrabError > File "/usr/share/yum/urlgrabber.py", line 21, in ? > import urllib2 > File "/usr/lib/python2.2/urllib2.py", line 101, in ? > import ftplib > File "/usr/lib/python2.2/ftplib.py", line 68, in ? > all_errors = (Error, socket.error, IOError, EOFError) > AttributeError: 'module' object has no attribute 'error' > > I tried removing yum with rpm -e and reinstalling, I tried forcing > installation of the prior python version, I tried synching yum version > with python version. I tried also the rpm --rebuilddb -vv. Nope. Yum is > still spitting error messages. > > Anyone has ideas or pointers ? :( > > I feel that somewhere, hidden or simply-not-mentioned-explicitly, there is > a config file or something similar (environment variables?) that had been > overlooked by me and by rpm. > > -- > +--------------------------------------------------------------------+ > | WARNING WARNING WARNING *** EMAIL ADDRESS CHANGED! | > | USE EMAIL ADDRESS PROVIDED BELOW | > | IF YOU KEEP WRITING TO THE OLD ADDRESS IT IS NOT MY FAULT! | > +--------------------------------------------------------------------+ > | Barbara Pennacchi b.pennacchi at istc.cnr.it | > | Consiglio Nazionale delle Ricerche | > | Istituto di Scienze e Tecnologie della Cognizione | > | V.le Marx 15, 00137 Roma, Italia | > | http://www.istc.cnr.it/ | > +--------------------------------------------------------------------+ > > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-legacy-list > From sheltren at cs.ucsb.edu Tue Sep 14 20:20:30 2004 From: sheltren at cs.ucsb.edu (Jeff Sheltren) Date: Tue, 14 Sep 2004 13:20:30 -0700 Subject: yum broken :p In-Reply-To: <020d01c49a93$587e03a0$336bcac7@BUSAC> Message-ID: Err, it's not yum that is broken on RH9; I have used yum on RH9 for quite some time now. I believe the problem she is having is due to using a different python version... Is that correct, Barbara? If so, you may want to direct this to the yum mailing list as it isn't really related to Fedora Legacy. https://lists.linux.duke.edu/mailman/listinfo/yum -Jeff On 9/14/04 12:45 PM, "S.Joseph" wrote: > I use Apt on my RH9 , I'll try out Yum and let you know how my experience > with is goes. > > ----- Original Message ----- > From: "Barbara Pennacchi" > To: "Fedora Legacy Project" > Sent: Tuesday, September 14, 2004 3:21 PM > Subject: yum broken :p > > >> >> Hello, I wrote almost one month ago to seek help with yum broken by >> updating python. I tried some of the fixes suggested in the replies, but >> to no avail. Then I went into vacation. >> >> Now I'm back. I've read all the back issues of this ml (I receive it in >> the digest format), to see if somebody else had replied on this subject. >> But no one did. Obviously I was in such a hurry to close down the store >> that I forgot to tell those folks that "thankyouverymuch, but it was still >> broken" :) >> >> Alas, I still need to have yum working (so at least I could try upgrading >> from RH9 to FC2 to have a newer python version :-) >> >> To sum it up, both yums, when called upon, keep spitting this: >> >> (from the RH9, with yum 2.0.4-1 and python 2.2.2-26: the one where I tried >> forcing back the former versions then the rpm --rebuilddb -vv) >> >> Traceback (most recent call last): >> File "/usr/bin/yum", line 22, in ? >> import yummain >> File "yummain.py", line 21, in ? >> File "clientStuff.py", line 25, in ? >> File "pkgaction.py", line 25, in ? >> File "rpmUtils.py", line 9, in ? >> File "urlgrabber.py", line 21, in ? >> File "/usr/lib/python2.2/urllib2.py", line 101, in ? >> import ftplib >> File "/usr/lib/python2.2/ftplib.py", line 68, in ? >> all_errors = (Error, socket.error, IOError, EOFError) >> AttributeError: 'module' object has no attribute 'error' >> >> >> (from the RH8 upgraded to RH9, with yum 2.0.7-1 and python 2.2.3-26, where >> I simply removed yum, installed new yum and tried the rpm --rebuilddb -vv) >> Traceback (most recent call last): >> File "/usr/bin/yum", line 22, in ? >> import yummain >> File "/usr/share/yum/yummain.py", line 22, in ? >> import clientStuff >> File "/usr/share/yum/clientStuff.py", line 25, in ? >> import pkgaction >> File "/usr/share/yum/pkgaction.py", line 25, in ? >> import rpmUtils >> File "/usr/share/yum/rpmUtils.py", line 10, in ? >> from urlgrabber import URLGrabError >> File "/usr/share/yum/urlgrabber.py", line 21, in ? >> import urllib2 >> File "/usr/lib/python2.2/urllib2.py", line 101, in ? >> import ftplib >> File "/usr/lib/python2.2/ftplib.py", line 68, in ? >> all_errors = (Error, socket.error, IOError, EOFError) >> AttributeError: 'module' object has no attribute 'error' >> >> I tried removing yum with rpm -e and reinstalling, I tried forcing >> installation of the prior python version, I tried synching yum version >> with python version. I tried also the rpm --rebuilddb -vv. Nope. Yum is >> still spitting error messages. >> >> Anyone has ideas or pointers ? :( >> >> I feel that somewhere, hidden or simply-not-mentioned-explicitly, there is >> a config file or something similar (environment variables?) that had been >> overlooked by me and by rpm. >> >> -- >> +--------------------------------------------------------------------+ >> | WARNING WARNING WARNING *** EMAIL ADDRESS CHANGED! | >> | USE EMAIL ADDRESS PROVIDED BELOW | >> | IF YOU KEEP WRITING TO THE OLD ADDRESS IT IS NOT MY FAULT! | >> +--------------------------------------------------------------------+ >> | Barbara Pennacchi b.pennacchi at istc.cnr.it | >> | Consiglio Nazionale delle Ricerche | >> | Istituto di Scienze e Tecnologie della Cognizione | >> | V.le Marx 15, 00137 Roma, Italia | >> | http://www.istc.cnr.it/ | >> +--------------------------------------------------------------------+ >> >> >> -- >> 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 dom at earth.li Tue Sep 14 20:55:54 2004 From: dom at earth.li (Dominic Hargreaves) Date: Tue, 14 Sep 2004 21:55:54 +0100 Subject: Round-up, 2004-09-14 In-Reply-To: <1095184397.13561.7.camel@pestilence.themule.net> References: <20040914003834.GA26041@tirian.magd.ox.ac.uk> <1095184397.13561.7.camel@pestilence.themule.net> Message-ID: <20040914205554.GC26041@tirian.magd.ox.ac.uk> On Tue, Sep 14, 2004 at 01:53:17PM -0400, Stephen E. Dudek wrote: > On Mon, 2004-09-13 at 20:38, Dominic Hargreaves wrote: > > $Id: issues.txt,v 1.23 2004/09/13 23:07:42 dom Exp $ > > > xchat - https://bugzilla.fedora.us/show_bug.cgi?id=1549 > > Needs 1 VERIFY for rh9 before release. > > If I'm not mistaken, this VERIFY should be for rh73, correct? I believe > that xchat for Red Hat 9 was fixed by Red Hat on April 29, 2004, as part > of their big push to fix a couple of issues before the End-of-Life on > April 30, 2004. Well spotted. My mistake. Dominic. From b.pennacchi at istc.cnr.it Tue Sep 14 20:59:40 2004 From: b.pennacchi at istc.cnr.it (Barbara Pennacchi) Date: Tue, 14 Sep 2004 22:59:40 +0200 Subject: yum broken :p In-Reply-To: References: Message-ID: <20040914205940.GA3294@sibannac> On 14.09.04 22:20, Jeff Sheltren wrote: > Err, it's not yum that is broken on RH9; I have used yum on RH9 for > quite some time now. I believe the problem she is having is due to > using a different python version... Is that correct, Barbara? Correct. When I installed yum on both boxes it worked fine. It worked even through updating a RH8 box to RH9. Then the need to update python for installing mailman came up. And it is this python upgrade that broke yum. > > If so, you may want to direct this to the yum mailing list as it isn't > really related to Fedora Legacy. > https://lists.linux.duke.edu/mailman/listinfo/yum Thank you for the pointer. I'll let you know what comes out of it. In the meanwhile, it wouldn't be a bad idea to add a warning about this on the pages related to using/installing yum. :-) Thanks again :) b. -- +--------------------------------------------------------------------+ | WARNING WARNING WARNING *** EMAIL ADDRESS CHANGED! | | USE EMAIL ADDRESS PROVIDED BELOW | | IF YOU KEEP WRITING TO THE OLD ADDRESS IT IS NOT MY FAULT! | +--------------------------------------------------------------------+ | Barbara Pennacchi b.pennacchi at istc.cnr.it | | Consiglio Nazionale delle Ricerche | | Istituto di Scienze e Tecnologie della Cognizione | | V.le Marx 15, 00137 Roma, Italia | | http://www.istc.cnr.it/ | +--------------------------------------------------------------------+ From rostetter at mail.utexas.edu Tue Sep 14 21:56:49 2004 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Tue, 14 Sep 2004 16:56:49 -0500 Subject: yum broken :p In-Reply-To: <20040914192143.GA3177@sibannac> References: <20040914192143.GA3177@sibannac> Message-ID: <1095199009.eeb03c93c08ad@mail.ph.utexas.edu> Quoting Barbara Pennacchi : > To sum it up, both yums, when called upon, keep spitting this: I had a similar problem once when I updated via yum/apt across versions. The problem was, at least in my case, I ended up with multiple pythons on my system. For example: % ls /usr/bin/python* /usr/bin/python /usr/bin/python2 /usr/bin/python2.2 (That's just an example). Now, the first line of /usr/bin/yum is something like: #!/usr/bin/python Which may be pointing at the "wrong" python version. So, to get it to work for me, I changed that line to something like (this is from memory, so you may have to experiment) #!/usr/bin/python2 > Anyone has ideas or pointers ? :( Try the above; it can't hurt, and if you are lucky it may help. > I feel that somewhere, hidden or simply-not-mentioned-explicitly, there is > a config file or something similar (environment variables?) that had been > overlooked by me and by rpm. If my memory is correct, it was just as simple as changing the version of python yum was using, as above... But then, my memory may be off some, so your milage may vary... -- Eric Rostetter From skvidal at phy.duke.edu Tue Sep 14 22:09:12 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 14 Sep 2004 18:09:12 -0400 Subject: yum broken :p In-Reply-To: <20040914205940.GA3294@sibannac> References: <20040914205940.GA3294@sibannac> Message-ID: <1095199752.32569.92.camel@opus.phy.duke.edu> On Tue, 2004-09-14 at 16:59, Barbara Pennacchi wrote: > On 14.09.04 22:20, Jeff Sheltren wrote: > > Err, it's not yum that is broken on RH9; I have used yum on RH9 for > > quite some time now. I believe the problem she is having is due to > > using a different python version... Is that correct, Barbara? > > Correct. When I installed yum on both boxes it worked fine. It worked even > through updating a RH8 box to RH9. Then the need to update python for > installing mailman came up. And it is this python upgrade that broke yum. > what need to update python for mailman? If you updated python outside of the packages in the tree - did you, perchance, use rpm --force --nodeps to update python? If you did then you broke your python install on your own. > > > > If so, you may want to direct this to the yum mailing list as it isn't > > really related to Fedora Legacy. > > https://lists.linux.duke.edu/mailman/listinfo/yum > > Thank you for the pointer. I'll let you know what comes out of it. > > In the meanwhile, it wouldn't be a bad idea to add a warning about this on > the pages related to using/installing yum. :-) > Would the warning read something like this?: If you decide to break your install by forcing an incompatible package on top of it then things will break. B/c that is essentially the warning that you'd have to give out. If you upgrade glibc beyond what your system can use you can expect everything to break. Ditto the case for python. -sv From joseph at ndimedia.com Tue Sep 14 22:09:59 2004 From: joseph at ndimedia.com (S.Joseph) Date: Tue, 14 Sep 2004 18:09:59 -0400 Subject: yum broken :p References: <20040914192143.GA3177@sibannac> <1095199009.eeb03c93c08ad@mail.ph.utexas.edu> Message-ID: <026901c49aa7$934fc130$336bcac7@BUSAC> Eric is right I installed 2.3 which installed as /usr/bin/python2.3, I pointed the /usr/bin/python link to 2.3 and yum failed , I modified yum to use 2.2 and it worked again. /usr/bin/yum line 1 #!/usr/bin/python2.2 for my test I used http://www.python.org/ftp/python/2.3.2/rpms/redhat-9/python2.3-2.3.2-1pydotorg.i386.rpm PS: I didn't get the same error as you Barbara but maybe the fix is the same. good luck ----- Original Message ----- From: "Eric Rostetter" To: Sent: Tuesday, September 14, 2004 5:56 PM Subject: Re: yum broken :p > Quoting Barbara Pennacchi : > >> To sum it up, both yums, when called upon, keep spitting this: > > I had a similar problem once when I updated via yum/apt across versions. > The problem was, at least in my case, I ended up with multiple pythons > on my system. For example: > > % ls /usr/bin/python* > /usr/bin/python /usr/bin/python2 /usr/bin/python2.2 > > (That's just an example). > > Now, the first line of /usr/bin/yum is something like: > > #!/usr/bin/python > > Which may be pointing at the "wrong" python version. So, to get it to > work > for me, I changed that line to something like (this is from memory, so you > may have to experiment) > > #!/usr/bin/python2 > >> Anyone has ideas or pointers ? :( > > Try the above; it can't hurt, and if you are lucky it may help. > >> I feel that somewhere, hidden or simply-not-mentioned-explicitly, there >> is >> a config file or something similar (environment variables?) that had been >> overlooked by me and by rpm. > > If my memory is correct, it was just as simple as changing the version > of python yum was using, as above... But then, my memory may be off some, > so your milage may vary... > > -- > Eric Rostetter > > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-legacy-list > From Axel.Thimm at ATrpms.net Tue Sep 14 23:52:34 2004 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 15 Sep 2004 01:52:34 +0200 Subject: FC1 support is ours... In-Reply-To: <1095184031.11856.9.camel@chip.laiskiainen.org> References: <1095125232.10393.347.camel@serendipity.dogma.lan> <1095172816.56072c0034077@mail.ph.utexas.edu> <1095178327.10393.438.camel@serendipity.dogma.lan> <1095184031.11856.9.camel@chip.laiskiainen.org> Message-ID: <20040914235234.GC8683@neu.physik.fu-berlin.de> On Tue, Sep 14, 2004 at 08:47:12PM +0300, Panu Matilainen wrote: > On Tue, 2004-09-14 at 19:12, Alexander Dalloz wrote: > > Am Di, den 14.09.2004 schrieb Eric Rostetter um 16:40: > > > Sure you can. Is it part of FC1? What's the package name? > > > > No, apt is not part of Fedora _Core_ 1. > > > > http://atrpms.net/dist/fc1/apt/ > > http://download.fedora.us/fedora/fedora/1/i386/RPMS.stable/apt-0.5.15cnc6-0.fdr.11.1.i386.rpm > > http://yarrow.freshrpms.net/rpm.html?id=1048 > > > > These are the 3 packaged apt RPMs certainly used by those feeling > > uncomfortable with yum or up2date on FC1. Each RPM comes with a > > different default setup. > > > > If I may do a suggestion, then contact the packagers and let them adjust > > their apt RPMs to handle the future Fedora Legacy locations for FC1. I > > could imagine they would do with favour. ATrpms' configs already include FL for all current FL repos, and FC1 will be no different :) > For fedora.us apt package this is a simple matter of just adding the > relevant fedora-legacy mirrors to the default repository/mirror list > files hosted on fedora.us server and telling people to rerun 'apt-get > mirror-select' to enable updates from FL. For others either the users > need to add the repositories themselves or the packages need to be > modified. ATrpms has a very flexible packaging scheme that does not require repackaging of yum/apt for adding/modifying repo entries (which is not on conflict to what Panu describes, the concepts are orthogonal AFAICT), which I would recommend to Fedora Legacy to adopt: Yum's and apt's config files are split out the main packages into a separate packages (also done by the kde-redhat project). This allows crafting vendor/repo neutral apt/yum packages and several *-package-config packages. The latter could also carry semantics like Panu's mirror scripts or other apt magic. For instance ATrpms has atrpms-package-config that activates only base/updates/atrpms and alternatively a medley-package-config that activates a larger set of compatible repos. Every repo could simply create its own *-package-config rpm and reuse the same sets of rpms like ATrpms. In this scheme FL could deploy fedoralegacy-package-config with only base/updates. This would allow more repos to share the same tool bits, but with different base configurations. Better for QA and inter-repo compatibility carma :) It is also easier to modify default yum.conf/sources.list entries for adding more (commented?) mirrors etc. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From pmatilai at welho.com Wed Sep 15 16:13:04 2004 From: pmatilai at welho.com (Panu Matilainen) Date: Wed, 15 Sep 2004 19:13:04 +0300 Subject: FC1 support is ours... In-Reply-To: <20040914235234.GC8683@neu.physik.fu-berlin.de> References: <1095125232.10393.347.camel@serendipity.dogma.lan> <1095172816.56072c0034077@mail.ph.utexas.edu> <1095178327.10393.438.camel@serendipity.dogma.lan> <1095184031.11856.9.camel@chip.laiskiainen.org> <20040914235234.GC8683@neu.physik.fu-berlin.de> Message-ID: <1095264784.2779.21.camel@chip.laiskiainen.org> On Wed, 2004-09-15 at 02:52, Axel Thimm wrote: > On Tue, Sep 14, 2004 at 08:47:12PM +0300, Panu Matilainen wrote: > > On Tue, 2004-09-14 at 19:12, Alexander Dalloz wrote: > > > Am Di, den 14.09.2004 schrieb Eric Rostetter um 16:40: > > > > Sure you can. Is it part of FC1? What's the package name? > > > > > > No, apt is not part of Fedora _Core_ 1. > > > > > > http://atrpms.net/dist/fc1/apt/ > > > http://download.fedora.us/fedora/fedora/1/i386/RPMS.stable/apt-0.5.15cnc6-0.fdr.11.1.i386.rpm > > > http://yarrow.freshrpms.net/rpm.html?id=1048 > > > > > > These are the 3 packaged apt RPMs certainly used by those feeling > > > uncomfortable with yum or up2date on FC1. Each RPM comes with a > > > different default setup. > > > > > > If I may do a suggestion, then contact the packagers and let them adjust > > > their apt RPMs to handle the future Fedora Legacy locations for FC1. I > > > could imagine they would do with favour. > > ATrpms' configs already include FL for all current FL repos, and FC1 > will be no different :) > > > For fedora.us apt package this is a simple matter of just adding the > > relevant fedora-legacy mirrors to the default repository/mirror list > > files hosted on fedora.us server and telling people to rerun 'apt-get > > mirror-select' to enable updates from FL. For others either the users > > need to add the repositories themselves or the packages need to be > > modified. > > ATrpms has a very flexible packaging scheme that does not require > repackaging of yum/apt for adding/modifying repo entries (which is not > on conflict to what Panu describes, the concepts are orthogonal > AFAICT), which I would recommend to Fedora Legacy to adopt: > > Yum's and apt's config files are split out the main packages into a > separate packages (also done by the kde-redhat project). This allows > crafting vendor/repo neutral apt/yum packages and several > *-package-config packages. Sure, it'd be possible to just add apt-fedora-legacy-conf.rpm or such which drops in /etc/apt/sources.list.d/fedora-legacy.list and nothing else (well perhaps the GPG key) and have it "just work". For yum 2.0.x it's not quite as easy since there's no yum.conf.d, 2.1.x does have that though. > The latter could also carry semantics like Panu's mirror scripts or other apt magic. Note that the mirror-select thing is totally distro/repository agnostic, it's just preconfigured in fedora.us apt package for, well, fedora.us :) You can just drop in config bits describing where to fetch the mirror list for this repository - eg for fedora-legacy it might be something like this in /etc/apt/apt.conf.d/fedora-legacy.conf: Apt::State::mirrors-URL:: "http://www.fedoralegacy.org/mirrorlists/fc1-legacy.list"; ..and the next time the user runs 'apt-get mirror-select' you'll see the FL repository as a new option in the list of repositories + it's mirrors. For an example of drop-in config rpm for mirror-select including GPG key see http://fedora.laiskiainen.org/SRPMS.lvn/apt-config-livna-2.0-0.lvn.1.src.rpm (IIRC that's somewhat outdated but you'll get the idea) - Panu - From b.pennacchi at istc.cnr.it Wed Sep 15 18:32:39 2004 From: b.pennacchi at istc.cnr.it (Barbara Pennacchi) Date: Wed, 15 Sep 2004 20:32:39 +0200 Subject: yum broken :p (quick replies) In-Reply-To: <20040914235259.0EF01736C0@hormel.redhat.com> References: <20040914235259.0EF01736C0@hormel.redhat.com> Message-ID: <20040915183239.GA4049@sibannac> Hi, a quick round of replies: ---- "S.Joseph" wrote: > I use Apt on my RH9 , I'll try out Yum and let you know how my > experience Aside from the fact that leaving the whole full quoted text below your reply doesn't look so nice in the eyes of some people, maybe I haven't made myself clear: until I updated python manually and only by a small notch, yum worked fine. I don't use apt so I cannot provide you with a comparison list. ---- Jeff Sheltren wrote: > https://lists.linux.duke.edu/mailman/listinfo/yum I dunno why, but this url makes firefox hang till I do a kill -9. :-) with elinks works, though. Been perusing in their bugzilla, though. ---- Eric Rostetter wrote: > % ls /usr/bin/python* > /usr/bin/python /usr/bin/python2 /usr/bin/python2.2 actually /usr/bin/python2 is a symlink to /usr/bin/python > for me, I changed that line to something like > #!/usr/bin/python2 Tried that. Nope. Not even changing it to point to /usr/bin/python2.2 works. I even went as far as poking my nose into /usr/share/yum/ and look at the header of the *.py files contained in it. didn't work ---- seth vidal wrote: > what need to update python for mailman? If you updated python outside of > the packages in the tree - did you, perchance, use rpm --force --nodeps > to update python? needed to install the new version of mailman, followed their indications. And, nope, didn't do a rpm --force --nodeps (looked too radical for my tastes :-) I did a rpm -Uvh, instead. > > In the meanwhile, it wouldn't be a bad idea to add a warning about > > this on the pages related to using/installing yum. :-) > Would the warning read something like this?: > > If you decide to break your install by forcing an incompatible package > on top of it then things will break. Nope, was thinking of somethink like "please take care when updating python by hand after installing yum" (duh!) I don't know much of python, it is not my favorite scripting language. Whatever. Mine was just a suggestion geared toward people not python- proficient (hope that a friend of mine doesn't read this ML :-) ---- "S.Joseph" wrote: > Eric is right I installed 2.3 which installed as /usr/bin/python2.3, I > pointed the /usr/bin/python link to 2.3 and yum failed , I modified yum > to use 2.2 and it worked again. well, this is understandable, since it is a bit of a major upgrade. But I upgraded only from 2.2.2 to 2.2.3! (I thought it was a TINY upgrade :-) End of the round of quick replies. I did also a rpmquery -vv --requires on the two .rpms of yum (the older and the newest) to see if there was some tiny dependency that I missed (but, hey, the rpm -ivh didn't complain about dependencies and conflicts with python 2.2.3! and also the rpm -Uvh of python 2.2.3 went fine.) Since my patience wears off easily, I decided to remove yum (rpm -e yum) and hunt down all the clutter left behind (like /usr/share/yum and /var/ cache/yum). Even moved my original yum.conf away from /etc/. BTW, since I think someone asked me where the heck I got those packages, the yum packages were from dulug.duke.edu (built by seth), while the python packages was from www.python.org (built by some tummy.com ^-^) I admit that all this has gotten way off-topic. Hope it all has been useful in some way to someone else. I'll go bother the people in yum's mailing list now :-) -- +--------------------------------------------------------------------+ | WARNING WARNING WARNING *** EMAIL ADDRESS CHANGED! | | USE EMAIL ADDRESS PROVIDED BELOW | | IF YOU KEEP WRITING TO THE OLD ADDRESS IT IS NOT MY FAULT! | +--------------------------------------------------------------------+ | Barbara Pennacchi b.pennacchi at istc.cnr.it | | Consiglio Nazionale delle Ricerche | | Istituto di Scienze e Tecnologie della Cognizione | | V.le Marx 15, 00137 Roma, Italia | | http://www.istc.cnr.it/ | +--------------------------------------------------------------------+ From joseph at ndimedia.com Wed Sep 15 18:50:49 2004 From: joseph at ndimedia.com (S.Joseph) Date: Wed, 15 Sep 2004 14:50:49 -0400 Subject: yum broken :p (quick replies) References: <20040914235259.0EF01736C0@hormel.redhat.com> <20040915183239.GA4049@sibannac> Message-ID: <020801c49b54$eb6b1c40$c002a8c0@BUSAC> Yes Barbara , I used your original mail as reference (2.3.2) http://www.redhat.com/archives/fedora-legacy-list/2004-August/msg00097.html good luck. take care. From strange at nsk.no-ip.org Wed Sep 15 19:12:51 2004 From: strange at nsk.no-ip.org (Luciano Miguel Ferreira Rocha) Date: Wed, 15 Sep 2004 20:12:51 +0100 Subject: yum broken :p (quick replies) In-Reply-To: <20040915183239.GA4049@sibannac> References: <20040914235259.0EF01736C0@hormel.redhat.com> <20040915183239.GA4049@sibannac> Message-ID: <20040915191251.GA1447@nsk.no-ip.org> (coming late to the discussion...) Could you do a rpm -qa python\* yum ; rpm -V yum python python2? Regards, Luciano Rocha From michal at harddata.com Thu Sep 16 00:04:18 2004 From: michal at harddata.com (Michal Jaegermann) Date: Wed, 15 Sep 2004 18:04:18 -0600 Subject: current gdk-pixbuf alerts Message-ID: <20040915180418.A1497@mail.harddata.com> There is definitely more general activity about that that one would with for. :-) To reflect recent alerts I added some patches and comments to https://bugzilla.fedora.us/show_bug.cgi?id=2005 All interested parties are invited to peek there. My personal preference is to follow the suit of RHEL and switch to a patched gdk-pixbuf-0.22.0. Yes, I am using that right now. Michal From simon at nzservers.com Thu Sep 16 02:47:25 2004 From: simon at nzservers.com (Simon Weller) Date: Wed, 15 Sep 2004 21:47:25 -0500 Subject: current gdk-pixbuf alerts In-Reply-To: <20040915180418.A1497@mail.harddata.com> References: <20040915180418.A1497@mail.harddata.com> Message-ID: <200409152147.25587.simon@nzservers.com> On Wednesday 15 September 2004 07:04 pm, Michal Jaegermann wrote: > There is definitely more general activity about that that one would > with for. :-) To reflect recent alerts I added some patches > and comments to > https://bugzilla.fedora.us/show_bug.cgi?id=2005 > All interested parties are invited to peek there. > > My personal preference is to follow the suit of RHEL and switch > to a patched gdk-pixbuf-0.22.0. Yes, I am using that right now. I agree with you on this one. I think this can be classed as a non-standard (for FL) approach, but it sounds like the most logical one. If everyone else is happy, we're probably just going to have to really give it some intense QA. With packages that have moved progressed so much, it gets harder and harder to easily backport anyway...we have enough issues to be looking at without spending half a day trying to get patches to apply to a single source tree. regards, Simon > > Michal > > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-legacy-list -- Simon Weller LPIC-2 Systems Engineer NZServers LTD http://www.nzservers.com/ U.S. Branch <- To mess up a Linux box, you need to work at it; to mess up your Windows box, you just need to work on it. - Scott Granneman, Security Focus -> From peak at argo.troja.mff.cuni.cz Thu Sep 16 09:39:33 2004 From: peak at argo.troja.mff.cuni.cz (Pavel Kankovsky) Date: Thu, 16 Sep 2004 11:39:33 +0200 (MET DST) Subject: Self Introduction: Pavel Kankovsky Message-ID: <20040916101626.31C9.0@argo.troja.mff.cuni.cz> 1. Full legal name Pavel Kankovsky 2. Location (Country, City, etc) Czech Republic 3. Profession or Student status network/unix/linux administrator computer security consultant (pentests, audits) used to work as a software developer in the past 4. Company or School Charles University, Faculty of Mathematics and Physics (http://www.mff.cuni.cz/) DCIT, s.r.o. (http://www.dcit.cz) 5. Your goals in the Fedora Legacy Project * Which OS versions are you interested in? 7.3. To keep it alive. Forever. :) * Do you want to do QA for packages? I am already reviewing any 3rd package to be installed on any of my computers (yes, I am paranoid), ergo I think I can do it. * Anything else special? I am suffering from an obsessive bugfixing syndrome, and might attempt to sneak nonessential patches into new package releases. :) 6. Historical qualifications * What other projects have you worked on in the past? FreeType (http://www.freetype.org/) numerous bugfixes and bug reports to numerous projects (OpenSSH, Nessus, Mozilla...) * What computer languages and other skills do you know? C, C++, Perl, sh, Pascal, x86 assembler other skills: debugging, source code auditing, network/unix/linux administration * Why should we trust you? Do not trust me. Double-check everything I submit. 7. GPG KEYID and fingerprint $ gpg --fingerprint peak-sw gpg: Warning: using insecure memory! gpg: please see http://www.gnupg.org/faq.html for more information pub 1024D/DF8A3AB1 2004-09-16 Pavel Kankovsky (sw) Key fingerprint = A837 6174 F7CE 6B0F 3FFB C424 A5A5 18FD DF8A 3AB1 sub 2048g/A5903F57 2004-09-16 [expires: 2006-09-16] --Pavel Kankovsky aka Peak [ Boycott Microsoft--http://www.vcnet.com/bms ] "Resistance is futile. Open your source code and prepare for assimilation." From b.pennacchi at istc.cnr.it Thu Sep 16 13:48:15 2004 From: b.pennacchi at istc.cnr.it (Barbara Pennacchi) Date: Thu, 16 Sep 2004 15:48:15 +0200 Subject: yum broken :p (quick replies) In-Reply-To: <20040915191251.GA1447@nsk.no-ip.org> References: <20040914235259.0EF01736C0@hormel.redhat.com> <20040915183239.GA4049@sibannac> <20040915191251.GA1447@nsk.no-ip.org> Message-ID: <20040916134815.GA3654@sibannac> On 15.09.04 21:12, Luciano Miguel Ferreira Rocha wrote: > Could you do a rpm -qa python\* yum ; rpm -V yum python python2? Already done. rpm -qa \*python\* gives: rpm-python-4.2-0.69 python-2.2.3-26 <---that's the python that broke yum, previously it was python-2.2.2-26) python-optik-1.4-2 libxml2-python-2.5.4-3.rh9 mod_python-3.0.1-4 I did a rpm -V yum python and even a rpm -V -vv yum python but all files seem to be OK. except that yum keeps NOT working. The only thing I didn't try (yet) was to move the symlink of /usr/bin/ python2 from /usr/bin/python to /usr/bin/python2.2 -- +--------------------------------------------------------------------+ | WARNING WARNING WARNING *** EMAIL ADDRESS CHANGED! | | USE EMAIL ADDRESS PROVIDED BELOW | | IF YOU KEEP WRITING TO THE OLD ADDRESS IT IS NOT MY FAULT! | +--------------------------------------------------------------------+ | Barbara Pennacchi b.pennacchi at istc.cnr.it | | Consiglio Nazionale delle Ricerche | | Istituto di Scienze e Tecnologie della Cognizione | | V.le Marx 15, 00137 Roma, Italia | | http://www.istc.cnr.it/ | +--------------------------------------------------------------------+ From dom at earth.li Fri Sep 17 00:25:42 2004 From: dom at earth.li (Dominic Hargreaves) Date: Fri, 17 Sep 2004 01:25:42 +0100 Subject: Round-up, 2004-09-17 Message-ID: <20040917002542.GB17144@home.thedom.org> $Id: issues.txt,v 1.37 2004/09/16 22:01:02 dom Exp $ See bottom for changes This list is also available at http://www-astro.physics.ox.ac.uk/~dom/legacy/issues.txt Packages that have been verified and should be fully released ------------------------------------------------------------- tcpdump - https://bugzilla.fedora.us/show_bug.cgi?id=1468 cadaver - https://bugzilla.fedora.us/show_bug.cgi?id=1552 flim - https://bugzilla.fedora.us/show_bug.cgi?id=1581 rsync - https://bugzilla.fedora.us/show_bug.cgi?id=1569 (but superceded) Packages waiting to be built for updates-testing ------------------------------------------------ gaim - https://bugzilla.fedora.us/show_bug.cgi?id=1237 lha - https://bugzilla.fedora.us/show_bug.cgi?id=1833 ethereal - https://bugzilla.fedora.us/show_bug.cgi?id=1840 XFree86 - https://bugzilla.fedora.us/show_bug.cgi?id=1289 mod_proxy - https://bugzilla.fedora.us/show_bug.cgi?id=1737 rsync - https://bugzilla.fedora.us/show_bug.cgi?id=2003 mod_ssl - https://bugzilla.fedora.us/show_bug.cgi?id=1888 XFree86 - https://bugzilla.fedora.us/show_bug.cgi?id=1831 gdk-pixbuf - https://bugzilla.fedora.us/show_bug.cgi?id=1371 (rh73) glibc - https://bugzilla.fedora.us/show_bug.cgi?id=1947 Packages in state RESOLVED (ie exist in updates-testing) that need active work. ------------------------------------------------------------------ mailman - https://bugzilla.fedora.us/show_bug.cgi?id=1269 There were some unconfirmed reports of breakage with the candidate. This needs more QA before release. mod_python - https://bugzilla.fedora.us/show_bug.cgi?id=1325 Needs 1 VERIFY before release. ethereal - https://bugzilla.fedora.us/show_bug.cgi?id=1419 Needs 2 VERIFY before release. - but dup with 1840? kernel - https://bugzilla.fedora.us/show_bug.cgi?id=1484 Needs missing file rebuilt for verification - but preferentially put work into later kernel ticket mozilla - https://bugzilla.fedora.us/show_bug.cgi?id=1532 Needs 2 VERIFY but has been superceded lha - https://bugzilla.fedora.us/show_bug.cgi?id=1547 Needs 2 VERIFY but has been superceded squid - https://bugzilla.fedora.us/show_bug.cgi?id=1732 Needs 1 VERIFY before release (but about to be superceded?) squirrelmail - https://bugzilla.fedora.us/show_bug.cgi?id=1733 Needs 1 VERIFY before release (also double check no new issues have cropped up) xchat - https://bugzilla.fedora.us/show_bug.cgi?id=1549 Needs 1 VERIFY for rh73 before release. Packages in state UNCONFIRMED, NEW, ASSIGNED or REOPENED: -------------------------------------------------------- * yum - https://bugzilla.fedora.us/show_bug.cgi?id=1583 IMO this shouldn't be in the Package Request component close WONTFIX re rh8? vsftp - https://bugzilla.fedora.us/show_bug.cgi?id=1778 Resolution of whether we are vulnerable needed. * kernel - https://bugzilla.fedora.us/show_bug.cgi?id=1797 VM (non-security) bug in rh9 that was never fixed before EOL. Looks to me like this should be closed WONTFIX. * rpm - https://bugzilla.fedora.us/show_bug.cgi?id=1864 No rationale given for bug request - the rh bug it refers to dates from before rh7.3 EOL. WONTFIX? * readline - https://bugzilla.fedora.us/show_bug.cgi?id=2017 Another not fixed before EOL (rh9). WONTFIX? netpbm - https://bugzilla.fedora.us/show_bug.cgi?id=1257 Needs PUBLISH, especially for rh9 kdelibs - https://bugzilla.fedora.us/show_bug.cgi?id=1373 Needs 2 PUBLISH (superceded) * cal - https://bugzilla.fedora.us/show_bug.cgi?id=1439 Should be closed WONTFIX IMO yum - https://bugzilla.fedora.us/show_bug.cgi?id=1604 Needs 2 PUBLISH mod_ssl - https://bugzilla.fedora.us/show_bug.cgi?id=1708 Needs PUBLISH for rh9 (but superceded) krb5 - https://bugzilla.fedora.us/show_bug.cgi?id=1726 Obsoleted libxml - https://bugzilla.fedora.us/show_bug.cgi?id=1324 Sort out confusion over status over version in updates-testing and add RESOLVED flag. sysstat - https://bugzilla.fedora.us/show_bug.cgi?id=1372 Need 2 PUBLISH - 7.3 only I think mc - https://bugzilla.fedora.us/show_bug.cgi?id=1548 Need 1 PUBLISH (but superceded?) libpng - https://bugzilla.fedora.us/show_bug.cgi?id=1550 Superceded libpng - https://bugzilla.fedora.us/show_bug.cgi?id=1943 Need 1 PUBLISH for rh9 tripwire - https://bugzilla.fedora.us/show_bug.cgi?id=1719 Resolve problems with how to version and build fix kernel - https://bugzilla.fedora.us/show_bug.cgi?id=1804 Need 2 PUBLISH apache - https://bugzilla.fedora.us/show_bug.cgi?id=1805 Is this redundant? mysql - https://bugzilla.fedora.us/show_bug.cgi?id=1832 Needs 1 PUBLISH but superceded? mozilla - https://bugzilla.fedora.us/show_bug.cgi?id=1834 Needs 1 PUBLISH for rh9 + rebuilt galeon SRPM with fixed build-deps php - https://bugzilla.fedora.us/show_bug.cgi?id=1868 Needs PUBLISH, especially for rh7.3 abiword - https://bugzilla.fedora.us/show_bug.cgi?id=1906 Needs PUBLISH, especially for rh9 subversion - https://bugzilla.fedora.us/show_bug.cgi?id=1907 Analysis and build fixed packages samba - https://bugzilla.fedora.us/show_bug.cgi?id=1924 Needs PUBLISH, especially for rh9 gnome vfs - https://bugzilla.fedora.us/show_bug.cgi?id=1944 Needs 2 PUBLISH sox - https://bugzilla.fedora.us/show_bug.cgi?id=1945 Needs PUBLISH for rh9 and possible renaming of rh7.3 package qt - https://bugzilla.fedora.us/show_bug.cgi?id=2002 Needs 2 PUBLISH gdk-pixbuf - https://bugzilla.fedora.us/show_bug.cgi?id=2005 Analyse/prepare packages mysql - https://bugzilla.fedora.us/show_bug.cgi?id=2006 Needs 2 PUBLISH ruby - https://bugzilla.fedora.us/show_bug.cgi?id=2007 needs work kdelibs - https://bugzilla.fedora.us/show_bug.cgi?id=2008 Needs 2 PUBLISH mc - https://bugzilla.fedora.us/show_bug.cgi?id=2009 Needs work pam_wheel - https://bugzilla.fedora.us/show_bug.cgi?id=2010 Needs PUBLISH and full auditing? krb5 - https://bugzilla.fedora.us/show_bug.cgi?id=2040 Needs 1 PUBLISH for rh9 * kernel - https://bugzilla.fedora.us/show_bug.cgi?id=1614 close WONTFIX? Reporter gone AWOL. imlib - https://bugzilla.fedora.us/show_bug.cgi?id=2051 Needs more work for further bugs ImageMagick - https://bugzilla.fedora.us/show_bug.cgi?id=2052 Needs 2 PUBLISH squid - https://bugzilla.fedora.us/show_bug.cgi?id=2053 Needs 2 PUBLISH for rh9 samba - https://bugzilla.fedora.us/show_bug.cgi?id=2057 Need maybe another publish for each release otherwise building cdrecord - https://bugzilla.fedora.us/show_bug.cgi?id=2058 Needs 2 PUBLISH for rh9 apache - https://bugzilla.fedora.us/show_bug.cgi?id=2068 Needs packages/confirmation cups - https://bugzilla.fedora.us/show_bug.cgi?id=2072 Needs packages/confirmation gtk2 - https://bugzilla.fedora.us/show_bug.cgi?id=2073 Needs packages/confirmation openoffice - https://bugzilla.fedora.us/show_bug.cgi?id=2074 Needs packages/confirmation libxpm - https://bugzilla.fedora.us/show_bug.cgi?id=2075 Needs packages/confirmation cupsomatic - https://bugzilla.fedora.us/show_bug.cgi?id=2076 Needs packages/confirmation General (non-package bugs) -------------------------- * https://bugzilla.fedora.us/show_bug.cgi?id=1437 applies to rh8 only - WONTFIX? Notes ----- Needs PUBLISH means that there are packages available for QA that need to be QAd at the source level. Needs VERIFY means that there are updates-testing packages that need testing. This is the easy bit, let's get this old ones out of the way ASAP. * means that there is a judgement call that can be made on the bug system immediately. Please follow up onlist with opinions. Changes ------- $Log: issues.txt,v $ Revision 1.37 2004/09/16 22:01:02 dom update imlib, gdk-pixbuf, glibc, mod_ssl Revision 1.36 2004/09/16 09:32:48 dom add new bugs ., Revision 1.35 2004/09/15 23:50:49 dom add new apache bug Revision 1.34 2004/09/15 23:38:56 dom update samba Revision 1.33 2004/09/15 23:33:21 dom mod_ssl update Revision 1.32 2004/09/15 00:06:11 dom update samba Revision 1.31 2004/09/14 21:24:43 dom update mc Revision 1.30 2004/09/14 21:19:18 dom update python Revision 1.29 2004/09/14 21:03:08 dom update netpbm Revision 1.28 2004/09/14 20:59:57 dom gdk-pixbuf buildable. Revision 1.27 2004/09/14 20:56:47 dom correct xchat comment Revision 1.26 2004/09/14 01:08:32 dom update squid, cdrtools, XFree86 Revision 1.25 2004/09/14 00:56:43 dom remove closed non-package bugs Revision 1.24 2004/09/14 00:47:33 dom move mod_ssl rh7.3 to to-be-built [...] -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From PEDROCJ at terra.es Sat Sep 18 09:50:28 2004 From: PEDROCJ at terra.es (Pedro Canadilla) Date: Sat, 18 Sep 2004 11:50:28 +0200 Subject: Bye, bye Fedora Legacy In-Reply-To: <20040917002542.GB17144@home.thedom.org> References: <20040917002542.GB17144@home.thedom.org> Message-ID: <1095501025.1471.16.camel@localhost.localdomain> Hello all, I've just finished to migrate the rhl 8 to WhiteBox Linux. I'm trying to close the bugzilla fedora legacy account but I'm not able to find the required information. Is it possible to do that? Anyone has information to do this action? (I'm a maniathic about cleaning garbage). Many thanks in advance for your help. Best Regards, P.C. From mattdm at mattdm.org Sat Sep 18 17:14:46 2004 From: mattdm at mattdm.org (Matthew Miller) Date: Sat, 18 Sep 2004 13:14:46 -0400 Subject: Bye, bye Fedora Legacy In-Reply-To: <1095501025.1471.16.camel@localhost.localdomain> References: <20040917002542.GB17144@home.thedom.org> <1095501025.1471.16.camel@localhost.localdomain> Message-ID: <20040918171446.GA26725@jadzia.bu.edu> On Sat, Sep 18, 2004 at 11:50:28AM +0200, Pedro Canadilla wrote: > I'm trying to close the bugzilla fedora legacy account but I'm not able > to find the required information. > Is it possible to do that? Anyone has information to do this action? > (I'm a maniathic about cleaning garbage). Deleting bugzilla accounts doesn't work very easily. Just don't worry about it. (Plus, it's not just fedora legacy's bugzilla -- it's fedora.us's, and it may be useful at some point.) -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From dom at earth.li Mon Sep 20 00:09:59 2004 From: dom at earth.li (Dominic Hargreaves) Date: Mon, 20 Sep 2004 01:09:59 +0100 Subject: Round-up, 2004-09-20 Message-ID: <20040920000958.GA12809@home.thedom.org> $Id: issues.txt,v 1.47 2004/09/20 00:01:49 dom Exp $ See bottom for changes This list is also available at http://www-astro.physics.ox.ac.uk/~dom/legacy/issues.txt Packages that have been verified and should be fully released ------------------------------------------------------------- tcpdump - https://bugzilla.fedora.us/show_bug.cgi?id=1468 cadaver - https://bugzilla.fedora.us/show_bug.cgi?id=1552 flim - https://bugzilla.fedora.us/show_bug.cgi?id=1581 rsync - https://bugzilla.fedora.us/show_bug.cgi?id=1569 (but superceded) xchat - https://bugzilla.fedora.us/show_bug.cgi?id=1549 squirrelmail - https://bugzilla.fedora.us/show_bug.cgi?id=1733 Packages waiting to be built for updates-testing ------------------------------------------------ gaim - https://bugzilla.fedora.us/show_bug.cgi?id=1237 lha - https://bugzilla.fedora.us/show_bug.cgi?id=1833 ethereal - https://bugzilla.fedora.us/show_bug.cgi?id=1840 XFree86 - https://bugzilla.fedora.us/show_bug.cgi?id=1289 mod_proxy - https://bugzilla.fedora.us/show_bug.cgi?id=1737 rsync - https://bugzilla.fedora.us/show_bug.cgi?id=2003 mod_ssl - https://bugzilla.fedora.us/show_bug.cgi?id=1888 XFree86 - https://bugzilla.fedora.us/show_bug.cgi?id=1831 gdk-pixbuf - https://bugzilla.fedora.us/show_bug.cgi?id=1371 (rh73,superceded) glibc - https://bugzilla.fedora.us/show_bug.cgi?id=1947 kernel - https://bugzilla.fedora.us/show_bug.cgi?id=1804 abiword - https://bugzilla.fedora.us/show_bug.cgi?id=1906 Packages in state RESOLVED (ie exist in updates-testing) that need active work. ------------------------------------------------------------------ mailman - https://bugzilla.fedora.us/show_bug.cgi?id=1269 There were some unconfirmed reports of breakage with the candidate. This needs more QA before release. mod_python - https://bugzilla.fedora.us/show_bug.cgi?id=1325 Needs 1 VERIFY before release. ethereal - https://bugzilla.fedora.us/show_bug.cgi?id=1419 Needs 2 VERIFY before release. - but dup with 1840? kernel - https://bugzilla.fedora.us/show_bug.cgi?id=1484 Needs missing file rebuilt for verification - but preferentially put work into later kernel ticket mozilla - https://bugzilla.fedora.us/show_bug.cgi?id=1532 Needs 2 VERIFY but has been superceded lha - https://bugzilla.fedora.us/show_bug.cgi?id=1547 Needs 2 VERIFY but has been superceded squid - https://bugzilla.fedora.us/show_bug.cgi?id=1732 Needs 1 VERIFY before release (but about to be superceded?) Packages in state UNCONFIRMED, NEW, ASSIGNED or REOPENED: -------------------------------------------------------- * readline - https://bugzilla.fedora.us/show_bug.cgi?id=2017 Another not fixed before EOL (rh9). WONTFIX? netpbm - https://bugzilla.fedora.us/show_bug.cgi?id=1257 Needs PUBLISH, especially for rh9 kdelibs - https://bugzilla.fedora.us/show_bug.cgi?id=1373 Needs 2 PUBLISH (superceded) yum - https://bugzilla.fedora.us/show_bug.cgi?id=1604 Needs 2 PUBLISH mod_ssl - https://bugzilla.fedora.us/show_bug.cgi?id=1708 Needs PUBLISH for rh9 (but superceded) krb5 - https://bugzilla.fedora.us/show_bug.cgi?id=1726 Obsoleted libxml - https://bugzilla.fedora.us/show_bug.cgi?id=1324 Sort out confusion over status over version in updates-testing and add RESOLVED flag. sysstat - https://bugzilla.fedora.us/show_bug.cgi?id=1372 Need 2 PUBLISH - 7.3 only I think mc - https://bugzilla.fedora.us/show_bug.cgi?id=1548 Need 1 PUBLISH (but superceded?) libpng - https://bugzilla.fedora.us/show_bug.cgi?id=1550 Superceded libpng - https://bugzilla.fedora.us/show_bug.cgi?id=1943 Need 1 PUBLISH for rh9 tripwire - https://bugzilla.fedora.us/show_bug.cgi?id=1719 Resolve problems with how to version and build fix apache - https://bugzilla.fedora.us/show_bug.cgi?id=1805 Is this redundant? mysql - https://bugzilla.fedora.us/show_bug.cgi?id=1832 Needs 1 PUBLISH but superceded? mozilla - https://bugzilla.fedora.us/show_bug.cgi?id=1834 Needs 1 PUBLISH for rh9 + rebuilt galeon SRPM with fixed build-deps php - https://bugzilla.fedora.us/show_bug.cgi?id=1868 Needs PUBLISH, especially for rh7.3 samba - https://bugzilla.fedora.us/show_bug.cgi?id=1924 Needs PUBLISH, especially for rh9 gnome vfs - https://bugzilla.fedora.us/show_bug.cgi?id=1944 Needs 2 PUBLISH sox - https://bugzilla.fedora.us/show_bug.cgi?id=1945 Needs PUBLISH for rh9 and possible renaming of rh7.3 package qt - https://bugzilla.fedora.us/show_bug.cgi?id=2002 Needs 2 PUBLISH gdk-pixbuf - https://bugzilla.fedora.us/show_bug.cgi?id=2005 Needs 2 PUBLISH mysql - https://bugzilla.fedora.us/show_bug.cgi?id=2006 Needs 2 PUBLISH ruby - https://bugzilla.fedora.us/show_bug.cgi?id=2007 needs work kdelibs - https://bugzilla.fedora.us/show_bug.cgi?id=2008 Needs 2 PUBLISH mc - https://bugzilla.fedora.us/show_bug.cgi?id=2009 Needs work pam_wheel - https://bugzilla.fedora.us/show_bug.cgi?id=2010 Needs PUBLISH and full auditing? krb5 - https://bugzilla.fedora.us/show_bug.cgi?id=2040 Needs 1 PUBLISH for rh9 imlib - https://bugzilla.fedora.us/show_bug.cgi?id=2051 Needs more work for further bugs ImageMagick - https://bugzilla.fedora.us/show_bug.cgi?id=2052 Needs 2 PUBLISH squid - https://bugzilla.fedora.us/show_bug.cgi?id=2053 Needs 2 PUBLISH for rh9 samba - https://bugzilla.fedora.us/show_bug.cgi?id=2057 Need maybe another PUBLISH for each release otherwise building cdrecord - https://bugzilla.fedora.us/show_bug.cgi?id=2058 Needs 2 PUBLISH for rh9 apache - https://bugzilla.fedora.us/show_bug.cgi?id=2068 Needs 2 PUBLISH cups - https://bugzilla.fedora.us/show_bug.cgi?id=2072 Needs 2 PUBLISH gtk2 - https://bugzilla.fedora.us/show_bug.cgi?id=2073 Needs 2 PUBLISH openoffice - https://bugzilla.fedora.us/show_bug.cgi?id=2074 Needs 2 PUBLISH libxpm - https://bugzilla.fedora.us/show_bug.cgi?id=2075 Needs packages/confirmation General (non-package bugs) -------------------------- Notes ----- Needs PUBLISH means that there are packages available for QA that need to be QAd at the source level. Needs VERIFY means that there are updates-testing packages that need testing. This is the easy bit, let's get this old ones out of the way ASAP. * means that there is a judgement call that can be made on the bug system immediately. Please follow up onlist with opinions. Changes ------- $Log: issues.txt,v $ Revision 1.47 2004/09/20 00:01:49 dom update gtk Revision 1.46 2004/09/19 18:16:32 dom update squirrelmail Revision 1.45 2004/09/19 17:53:23 dom move xchat to fully-release pile Revision 1.44 2004/09/19 17:24:04 dom update abiword Revision 1.43 2004/09/19 16:54:24 dom remove more old bugs Revision 1.42 2004/09/19 16:53:19 dom remove more old bugs Revision 1.41 2004/09/19 11:35:49 dom update gdk-pixbuf, openoffice remove dead kernel bug Revision 1.40 2004/09/18 00:31:26 dom update kernel Revision 1.39 2004/09/17 23:47:10 dom update gdk-pixbuf, cups, remove cupsomatic Revision 1.38 2004/09/17 01:17:47 dom update httpd [...] -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From ckelley at ibnads.com Mon Sep 20 02:45:40 2004 From: ckelley at ibnads.com (Craig Kelley) Date: Sun, 19 Sep 2004 20:45:40 -0600 Subject: Round-up, 2004-09-20 In-Reply-To: <20040920000958.GA12809@home.thedom.org> References: <20040920000958.GA12809@home.thedom.org> Message-ID: <414E4454.1090704@ibnads.com> Dominic Hargreaves wrote: >Packages that have been verified and should be fully released >------------------------------------------------------------- > >tcpdump - https://bugzilla.fedora.us/show_bug.cgi?id=1468 >cadaver - https://bugzilla.fedora.us/show_bug.cgi?id=1552 >flim - https://bugzilla.fedora.us/show_bug.cgi?id=1581 >rsync - https://bugzilla.fedora.us/show_bug.cgi?id=1569 (but superceded) >xchat - https://bugzilla.fedora.us/show_bug.cgi?id=1549 >squirrelmail - https://bugzilla.fedora.us/show_bug.cgi?id=1733 > > > Thanks again for doing this compilation Dominic. Do we have any news on releasing these packages?? They've been ready for quite some time now... From jonny.strom at netikka.fi Mon Sep 20 16:04:38 2004 From: jonny.strom at netikka.fi (Johnny Strom) Date: Mon, 20 Sep 2004 19:04:38 +0300 Subject: fedoralegacy.org down? Message-ID: <414EFF96.4030203@netikka.fi> Hi What have happend to fedoralegacy.org some problems with DNS or? Cheers Johnny From jkeating at j2solutions.net Mon Sep 20 16:44:03 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 20 Sep 2004 09:44:03 -0700 Subject: fedoralegacy.org down? In-Reply-To: <414EFF96.4030203@netikka.fi> References: <414EFF96.4030203@netikka.fi> Message-ID: <200409200944.07159.jkeating@j2solutions.net> On Monday 20 September 2004 09:04, Johnny Strom wrote: > Hi > > What have happend to fedoralegacy.org some problems with DNS or? Just a small problem at the colo. Things are back up now. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From mule at umich.edu Mon Sep 20 18:11:46 2004 From: mule at umich.edu (Stephen E. Dudek) Date: Mon, 20 Sep 2004 14:11:46 -0400 Subject: Round-up, 2004-09-20 In-Reply-To: <20040920000958.GA12809@home.thedom.org> References: <20040920000958.GA12809@home.thedom.org> Message-ID: <1095703905.2209.90.camel@pestilence.themule.net> Dominic, In reviewing this list, I believe the following should also be added to your round-up list: cvs - http://bugzilla.fedora.us/show_bug.cgi?id=1735 It is currently listed as RESOLVED but seems to be in limbo under updates-testing. On Sun, 2004-09-19 at 20:09, Dominic Hargreaves wrote: > $Id: issues.txt,v 1.47 2004/09/20 00:01:49 dom Exp $ > > See bottom for changes > > This list is also available at > http://www-astro.physics.ox.ac.uk/~dom/legacy/issues.txt > > Packages that have been verified and should be fully released > ------------------------------------------------------------- > > tcpdump - https://bugzilla.fedora.us/show_bug.cgi?id=1468 > cadaver - https://bugzilla.fedora.us/show_bug.cgi?id=1552 > flim - https://bugzilla.fedora.us/show_bug.cgi?id=1581 > rsync - https://bugzilla.fedora.us/show_bug.cgi?id=1569 (but superceded) > xchat - https://bugzilla.fedora.us/show_bug.cgi?id=1549 > squirrelmail - https://bugzilla.fedora.us/show_bug.cgi?id=1733 > > Packages waiting to be built for updates-testing > ------------------------------------------------ > > gaim - https://bugzilla.fedora.us/show_bug.cgi?id=1237 > lha - https://bugzilla.fedora.us/show_bug.cgi?id=1833 > ethereal - https://bugzilla.fedora.us/show_bug.cgi?id=1840 > XFree86 - https://bugzilla.fedora.us/show_bug.cgi?id=1289 > mod_proxy - https://bugzilla.fedora.us/show_bug.cgi?id=1737 > rsync - https://bugzilla.fedora.us/show_bug.cgi?id=2003 > mod_ssl - https://bugzilla.fedora.us/show_bug.cgi?id=1888 > XFree86 - https://bugzilla.fedora.us/show_bug.cgi?id=1831 > gdk-pixbuf - https://bugzilla.fedora.us/show_bug.cgi?id=1371 (rh73,superceded) > glibc - https://bugzilla.fedora.us/show_bug.cgi?id=1947 > kernel - https://bugzilla.fedora.us/show_bug.cgi?id=1804 > abiword - https://bugzilla.fedora.us/show_bug.cgi?id=1906 > > Packages in state RESOLVED (ie exist in updates-testing) that need > active work. > ------------------------------------------------------------------ > > mailman - https://bugzilla.fedora.us/show_bug.cgi?id=1269 > There were some unconfirmed reports of breakage with the candidate. This > needs more QA before release. > > mod_python - https://bugzilla.fedora.us/show_bug.cgi?id=1325 > Needs 1 VERIFY before release. > > ethereal - https://bugzilla.fedora.us/show_bug.cgi?id=1419 > Needs 2 VERIFY before release. - but dup with 1840? > > kernel - https://bugzilla.fedora.us/show_bug.cgi?id=1484 > Needs missing file rebuilt for verification - but preferentially put > work into later kernel ticket > > mozilla - https://bugzilla.fedora.us/show_bug.cgi?id=1532 > Needs 2 VERIFY but has been superceded > > lha - https://bugzilla.fedora.us/show_bug.cgi?id=1547 > Needs 2 VERIFY but has been superceded > > squid - https://bugzilla.fedora.us/show_bug.cgi?id=1732 > Needs 1 VERIFY before release (but about to be superceded?) > > Packages in state UNCONFIRMED, NEW, ASSIGNED or REOPENED: > -------------------------------------------------------- > > * readline - https://bugzilla.fedora.us/show_bug.cgi?id=2017 > Another not fixed before EOL (rh9). WONTFIX? > > netpbm - https://bugzilla.fedora.us/show_bug.cgi?id=1257 > Needs PUBLISH, especially for rh9 > > kdelibs - https://bugzilla.fedora.us/show_bug.cgi?id=1373 > Needs 2 PUBLISH (superceded) > > yum - https://bugzilla.fedora.us/show_bug.cgi?id=1604 > Needs 2 PUBLISH > > mod_ssl - https://bugzilla.fedora.us/show_bug.cgi?id=1708 > Needs PUBLISH for rh9 (but superceded) > > krb5 - https://bugzilla.fedora.us/show_bug.cgi?id=1726 > Obsoleted > > libxml - https://bugzilla.fedora.us/show_bug.cgi?id=1324 > Sort out confusion over status over version in updates-testing and add > RESOLVED flag. > > sysstat - https://bugzilla.fedora.us/show_bug.cgi?id=1372 > Need 2 PUBLISH - 7.3 only I think > > mc - https://bugzilla.fedora.us/show_bug.cgi?id=1548 > Need 1 PUBLISH (but superceded?) > > libpng - https://bugzilla.fedora.us/show_bug.cgi?id=1550 > Superceded > > libpng - https://bugzilla.fedora.us/show_bug.cgi?id=1943 > Need 1 PUBLISH for rh9 > > tripwire - https://bugzilla.fedora.us/show_bug.cgi?id=1719 > Resolve problems with how to version and build fix > > apache - https://bugzilla.fedora.us/show_bug.cgi?id=1805 > Is this redundant? > > mysql - https://bugzilla.fedora.us/show_bug.cgi?id=1832 > Needs 1 PUBLISH but superceded? > > mozilla - https://bugzilla.fedora.us/show_bug.cgi?id=1834 > Needs 1 PUBLISH for rh9 + rebuilt galeon SRPM with fixed build-deps > > php - https://bugzilla.fedora.us/show_bug.cgi?id=1868 > Needs PUBLISH, especially for rh7.3 > > samba - https://bugzilla.fedora.us/show_bug.cgi?id=1924 > Needs PUBLISH, especially for rh9 > > gnome vfs - https://bugzilla.fedora.us/show_bug.cgi?id=1944 > Needs 2 PUBLISH > > sox - https://bugzilla.fedora.us/show_bug.cgi?id=1945 > Needs PUBLISH for rh9 and possible renaming of rh7.3 package > > qt - https://bugzilla.fedora.us/show_bug.cgi?id=2002 > Needs 2 PUBLISH > > gdk-pixbuf - https://bugzilla.fedora.us/show_bug.cgi?id=2005 > Needs 2 PUBLISH > > mysql - https://bugzilla.fedora.us/show_bug.cgi?id=2006 > Needs 2 PUBLISH > > ruby - https://bugzilla.fedora.us/show_bug.cgi?id=2007 > needs work > > kdelibs - https://bugzilla.fedora.us/show_bug.cgi?id=2008 > Needs 2 PUBLISH > > mc - https://bugzilla.fedora.us/show_bug.cgi?id=2009 > Needs work > > pam_wheel - https://bugzilla.fedora.us/show_bug.cgi?id=2010 > Needs PUBLISH and full auditing? > > krb5 - https://bugzilla.fedora.us/show_bug.cgi?id=2040 > Needs 1 PUBLISH for rh9 > > imlib - https://bugzilla.fedora.us/show_bug.cgi?id=2051 > Needs more work for further bugs > > ImageMagick - https://bugzilla.fedora.us/show_bug.cgi?id=2052 > Needs 2 PUBLISH > > squid - https://bugzilla.fedora.us/show_bug.cgi?id=2053 > Needs 2 PUBLISH for rh9 > > samba - https://bugzilla.fedora.us/show_bug.cgi?id=2057 > Need maybe another PUBLISH for each release otherwise building > > cdrecord - https://bugzilla.fedora.us/show_bug.cgi?id=2058 > Needs 2 PUBLISH for rh9 > > apache - https://bugzilla.fedora.us/show_bug.cgi?id=2068 > Needs 2 PUBLISH > > cups - https://bugzilla.fedora.us/show_bug.cgi?id=2072 > Needs 2 PUBLISH > > gtk2 - https://bugzilla.fedora.us/show_bug.cgi?id=2073 > Needs 2 PUBLISH > > openoffice - https://bugzilla.fedora.us/show_bug.cgi?id=2074 > Needs 2 PUBLISH > > libxpm - https://bugzilla.fedora.us/show_bug.cgi?id=2075 > Needs packages/confirmation > > General (non-package bugs) > -------------------------- > > Notes > ----- > > Needs PUBLISH means that there are packages available for QA that need > to be QAd at the source level. > > Needs VERIFY means that there are updates-testing packages that need > testing. This is the easy bit, let's get this old ones out of the way > ASAP. > > * means that there is a judgement call that can be made on the bug > system immediately. Please follow up onlist with opinions. > > Changes > ------- > > $Log: issues.txt,v $ > Revision 1.47 2004/09/20 00:01:49 dom > update gtk > > Revision 1.46 2004/09/19 18:16:32 dom > update squirrelmail > > Revision 1.45 2004/09/19 17:53:23 dom > move xchat to fully-release pile > > Revision 1.44 2004/09/19 17:24:04 dom > update abiword > > Revision 1.43 2004/09/19 16:54:24 dom > remove more old bugs > > Revision 1.42 2004/09/19 16:53:19 dom > remove more old bugs > > Revision 1.41 2004/09/19 11:35:49 dom > update gdk-pixbuf, openoffice > remove dead kernel bug > > Revision 1.40 2004/09/18 00:31:26 dom > update kernel > > Revision 1.39 2004/09/17 23:47:10 dom > update gdk-pixbuf, cups, remove cupsomatic > > Revision 1.38 2004/09/17 01:17:47 dom > update httpd > > [...] > > > !DSPAM:414e1fed162251483713606! > > ______________________________________________________________________ > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-legacy-list > > !DSPAM:414e1fed162251483713606! -------------- 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 clint at penguinsolutions.org Mon Sep 20 20:09:26 2004 From: clint at penguinsolutions.org (Clint Harshaw) Date: Mon, 20 Sep 2004 16:09:26 -0400 Subject: yum.conf for FC1 move Message-ID: <414F38F6.6070909@penguinsolutions.org> Hi all, I'm new to the list and want to modify my existing yum.conf so that it will be compatible with the Fedora Legacy addresses. I imagine the move will be complete later on today or the next couple of days, and would like to be sure I understand where the packages will be located. Based on what I read at the legacy site, it looks like my yum.conf will be in the form I'm pasted below. I've also listed mirrors that are geographically close to me, if the fedoralegacy.org site isn't available. Do have I have things set up properly here? Thanks in advance for the help, Clint ################## ## Basic Fedora ## ################## [base] name=Fedora Core $releasever base baseurl=http://download.fedoralegacy.org/fedora/$releasever/os/$basearch http://www.gtlib.cc.gatech.edu/pub/fedoralegacy/fedora/$releasever/os/$basearch ftp://mirror.physics.ncsu.edu/mirror/download.fedoralegacy.org/fedora/$releasever/os/$basearch # ftp://linux21.fnal.gov/linux/legacy/fedora/$releasever/os/$basearch # http://mirror.datapipe.net/fedoralegacy/fedora/$releasever/os/$basearch # ftp://mirrors.umbc.edu/pub/linux/fedora-legacy/fedora/$releasever/os/$basearch # http://mirror3.cs.wisc.edu/pub/mirrors/linux/download.fedoralegacy.org/fedora/$releasever/os/$basearch [updates] name=Fedora Core $releasever updates baseurl=http://download.fedoralegacy.org/fedora/$releasever/updates/$basearch http://www.gtlib.cc.gatech.edu/pub/fedoralegacy/fedora/$releasever/updates/$basearch ftp://mirror.physics.ncsu.edu/mirror/download.fedoralegacy.org/fedora/$releasever/updates/$basearch # ftp://linux21.fnal.gov/linux/legacy/fedora/$releasever/updates/$basearch # http://mirror.datapipe.net/fedoralegacy/fedora/$releasever/updates/$basearch # ftp://mirrors.umbc.edu/pub/linux/fedora-legacy/fedora/$releasever/updates/$basearch # http://mirror3.cs.wisc.edu/pub/mirrors/linux/download.fedoralegacy.org/fedora/$releasever/updates/$basearch [legacy-utils] name=Fedora Legacy utilities for Fedora Core $releasever baseurl=http://download.fedoralegacy.org/fedora/$releasever/legacy-utils/$basearch http://www.gtlib.cc.gatech.edu/pub/fedoralegacy/fedora/$releasever/legacy-utils/$basearch ftp://mirror.physics.ncsu.edu/mirror/download.fedoralegacy.org/fedora/$releasever/legacy-utils/$basearch # ftp://linux21.fnal.gov/linux/legacy/fedora/$releasever/legacy-utils/$basearch # http://mirror.datapipe.net/fedoralegacy/fedora/$releasever/legacy-utils/$basearch # ftp://mirrors.umbc.edu/pub/linux/fedora-legacy/fedora/$releasever/legacy-utils/$basearch # http://mirror3.cs.wisc.edu/pub/mirrors/linux/download.fedoralegacy.org/fedora/$releasever/legacy-utils/$basearch From rostetter at mail.utexas.edu Mon Sep 20 22:11:54 2004 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Mon, 20 Sep 2004 17:11:54 -0500 Subject: FC1 updates on web site. Message-ID: <1095718314.171a8875360e6@mail.ph.utexas.edu> I've updated the web site to reflect that we now have FC1 support. As soon as I hear the yum/apt trees are setup and read to go, I'll add those updates also. Please let me know of any omissions, corrections, problems, etc. on the web site's FC1 info. -- Eric Rostetter From byte at aeon.com.my Tue Sep 21 03:30:01 2004 From: byte at aeon.com.my (Colin Charles) Date: Tue, 21 Sep 2004 13:30:01 +1000 Subject: FC1 updates on web site. In-Reply-To: <1095718314.171a8875360e6@mail.ph.utexas.edu> References: <1095718314.171a8875360e6@mail.ph.utexas.edu> Message-ID: <1095737401.4472.150.camel@albus.aeon.com.my> On Tue, 2004-09-21 at 08:11, Eric Rostetter wrote: > I've updated the web site to reflect that we now have FC1 support. As soon > as I hear the yum/apt trees are setup and read to go, I'll add those updates > also. > > Please let me know of any omissions, corrections, problems, etc. on the web > site's FC1 info. I suggest we start moving "quickly", and if people want a workspace/scratch space, just sign up at the Wiki: http://fedoraproject.org/wiki/ This way things like a yum.conf and other bits can be built mighty quikcly. If you're wondering why you can't edit things, just ask someone within the EditGroup to add you Regards -- Colin Charles, byte at aeon.com.my http://www.bytebot.net/ "First they ignore you, then they laugh at you, then they fight you, then you win." -- Mohandas Gandhi From ggw at wolves.durham.nc.us Wed Sep 22 03:18:14 2004 From: ggw at wolves.durham.nc.us (Gregory Woodbury) Date: Tue, 21 Sep 2004 23:18:14 -0400 Subject: Self-Introduction: Gregory "Wolfe" Woodbury Message-ID: <20040922031814.GA29433@wolves.durham.nc.us> I've been lurking on the list for a few month now and it seems to be time to step out into the light. 1. Gregory G. "Wolfe" Woodbury 2. Durham, North Carolina, USA 3. Disabled (former System Administrator) 4. RedWolfe Computer Homestead - my household 5. My goals are to support the FC1 aspects of the project. I will do testing of updates-testing packages 6. Historically I've been using UNIX and Linux since 1978 when Duke got its Edition 6 tape from Bell Labs. I participated in the development of Usenet in a minor way and was an admin of one of the early machines (duke34). I've been an SA as a contractor at Bell Labs, and for 15 years was the SA at cds.duke.edu. Now I'm disabled and doing everything on a heterogenous network here at the homestead - 6 machines (3 FCx,1 mac, 1 Win 98SE, 1 Win 2K Server) and wired and wireless networks, xDSL to the internet, etc. I program in FORTRAN, C/C++, Objective C, BASH and Perl. I'm learning Python. As for trust, I've been around the block a few times, and will gain it slowly. 7. Freshly minted key: pub 1024D/3573369E 2004-09-22 Gregory Woodbury (aka Wolfe or RedWolfe) Key fingerprint = 3EE2 4730 C53F 8CE9 5277 35DD A0EF 838E 3573 369E sub 1024g/48388E81 2004-09-22 [expires: 2007-09-22] -- G.Wolfe Woodbury `- -' RHCT U The Line Eater is a boojum! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rob.myers at gtri.gatech.edu Wed Sep 22 14:57:44 2004 From: rob.myers at gtri.gatech.edu (Rob Myers) Date: Wed, 22 Sep 2004 10:57:44 -0400 Subject: Self-Introduction: Rob Myers Message-ID: <1095865064.11163.57.camel@rXm-581b.stl.gtri.gatech.edu> Name: Rob Myers Location: Atlanta, Georgia, USA Current Profession: SysAdmin Company/School: Georgia Tech Research Institute Goals: To do whatever it takes to extend the life of FC1. Qualifications: None to speak of. GPG KEYID and fingerprint: pub 1024D/DD4E5A7B 2004-09-22 Rob Myers (rob) Key fingerprint = 7061 158C 5C6B CD74 A35C AF1A B54D 9702 DD4E 5A7B sub 2048g/F6E6F65E 2004-09-22 [expires: 2009-09-21] From clint at penguinsolutions.org Wed Sep 22 15:22:06 2004 From: clint at penguinsolutions.org (Clint Harshaw) Date: Wed, 22 Sep 2004 11:22:06 -0400 Subject: Need help with yum.conf for FC1 Message-ID: <4151989E.5080607@penguinsolutions.org> I have tried modifying my yum.conf to work with the fedoralegacy.org servers, by mimicing what I found at the site for RH versions. So the relevant section of my yum.conf looks like: [base] name=Fedora Core $releasever base baseurl=http://download.fedoralegacy.org/fedora/$releasever/os/$basearch [updates] name=Fedora Core $releasever updates baseurl=http://download.fedoralegacy.org/fedora/$releasever/updates/$basearch [legacy-utils] name=Fedora Legacy utilities for Fedora Core $releasever baseurl=http://download.fedoralegacy.org/fedora/$releasever/legacy-utils/$basearch (I've removed the mirrors that I have on my real yum.conf, but once I figure this part out, I'll configure mirrors.) When I run yum update, however, I get the following output: # yum update Gathering header information file(s) from server(s) Server: Fedora Core 1 base retrygrab() failed for: http://download.fedoralegacy.org/fedora/1/os/i386/headers/header.info Executing failover method failover: out of servers to try Error getting file http://download.fedoralegacy.org/fedora/1/os/i386/headers/header.info [Errno 4] IOError: HTTP Error 404: Not Found How should I correct this in my yum.conf? Thanks, Clint From ggw at wolves.durham.nc.us Wed Sep 22 15:33:27 2004 From: ggw at wolves.durham.nc.us (Gregory Woodbury) Date: Wed, 22 Sep 2004 11:33:27 -0400 Subject: Need help with yum.conf for FC1 In-Reply-To: <4151989E.5080607@penguinsolutions.org> References: <4151989E.5080607@penguinsolutions.org> Message-ID: <20040922153327.GA3261@wolves.durham.nc.us> On Wed, Sep 22, 2004 at 11:22:06AM -0400, Clint Harshaw wrote: > When I run yum update, however, I get the following output: > # yum update > Gathering header information file(s) from server(s) > Server: Fedora Core 1 base > retrygrab() failed for: > http://download.fedoralegacy.org/fedora/1/os/i386/headers/header.info > Executing failover method > failover: out of servers to try > Error getting file > http://download.fedoralegacy.org/fedora/1/os/i386/headers/header.info > [Errno 4] IOError: HTTP Error 404: Not Found > > How should I correct this in my yum.conf? As Far As I Can Tell (AFAICT) the FC1 stuff isn't on the site yet. They are working on getting it in place, but don't have it there as of this morning. -- G.Wolfe Woodbury `- -' RHCT U The Line Eater is a boojum! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From alexander.dalloz at uni-bielefeld.de Wed Sep 22 15:40:15 2004 From: alexander.dalloz at uni-bielefeld.de (Alexander Dalloz) Date: Wed, 22 Sep 2004 17:40:15 +0200 Subject: Need help with yum.conf for FC1 In-Reply-To: <20040922153327.GA3261@wolves.durham.nc.us> References: <4151989E.5080607@penguinsolutions.org> <20040922153327.GA3261@wolves.durham.nc.us> Message-ID: <1095867615.26478.49.camel@serendipity.dogma.lan> Am Mi, den 22.09.2004 schrieb Gregory Woodbury um 17:33: > > When I run yum update, however, I get the following output: > > # yum update > > Gathering header information file(s) from server(s) > > Server: Fedora Core 1 base > > retrygrab() failed for: > > http://download.fedoralegacy.org/fedora/1/os/i386/headers/header.info > > Executing failover method > > failover: out of servers to try > > Error getting file > > http://download.fedoralegacy.org/fedora/1/os/i386/headers/header.info > > [Errno 4] IOError: HTTP Error 404: Not Found > > > > How should I correct this in my yum.conf? > > As Far As I Can Tell (AFAICT) the FC1 stuff isn't on the site yet. They > are working on getting it in place, but don't have it there as of this > morning. At least the headers folder is missing so far. Alexander -- Alexander Dalloz | Enger, Germany | GPG key 1024D/ED695653 1999-07-13 Fedora GNU/Linux Core 2 (Tettnang) kernel 2.6.8-1.521smp Serendipity 17:39:10 up 1 day, 19:43, load average: 2.43, 1.95, 1.77 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From b.pennacchi at istc.cnr.it Wed Sep 22 19:16:13 2004 From: b.pennacchi at istc.cnr.it (Barbara Pennacchi) Date: Wed, 22 Sep 2004 21:16:13 +0200 Subject: Yum works again ! :-) Message-ID: <20040922191613.GA12217@sibannac> About time. It was openssl that caused the whole mess. Apparently, I updated some time ago openssl from a openssl-related site that provided rpm packages for rh8/9 to the version 0.9.7a-30, while on fedora legacy mirrors there was openssl 0.9.7a-20.2 So I downloaded from fedora legacy the right package, gave it a "rpm -Uvh --force" then checked in the command line of python with "import ftplib" to see if there were still errors. Python didn't complain so I re- installed yum. oh well. ^__^ (no, don't ask me why I updated openssl to 0.9.7a-30, I don't have this much cache in my biological RAM!) Thanks to everybody for all their help. :-) -- +--------------------------------------------------------------------+ | WARNING WARNING WARNING *** EMAIL ADDRESS CHANGED! | | USE EMAIL ADDRESS PROVIDED BELOW | | IF YOU KEEP WRITING TO THE OLD ADDRESS IT IS NOT MY FAULT! | +--------------------------------------------------------------------+ | Barbara Pennacchi b.pennacchi at istc.cnr.it | | Consiglio Nazionale delle Ricerche | | Istituto di Scienze e Tecnologie della Cognizione | | V.le Marx 15, 00137 Roma, Italia | | http://www.istc.cnr.it/ | +--------------------------------------------------------------------+ From b.pennacchi at istc.cnr.it Fri Sep 24 16:05:18 2004 From: b.pennacchi at istc.cnr.it (Barbara Pennacchi) Date: Fri, 24 Sep 2004 18:05:18 +0200 Subject: Self-Introduction: B. Pennacchi Message-ID: <20040924160518.GE4252@sibannac> After aligning to the same version of RH9 the 2 boxes and fixing yum, I think I could leave well alone the rh9 prod box and use the other (the one I'm writing from) for QA testing. So here is my self-introduction (better late than never ;) 1. Barbara Pennacchi 2. Rome, Italy (EU) 3. dunno how to translate it in english. Officially, I'm a 'technician'. Practically, I'm responsible for a webserver (maintenance and PHP/html development, mostly) 4. it's in my big&cumbersome signature below. 5. I'm mostly interested in RH9, since FC evolves a bit too fast for my tastes. I'd like to help in testing packages for release (as a vanilla luser). Obviously I'm interested mostly in packages related to the webserver (ie kernels, httpd, mysql, iptables and so on) 6. Actually, this is my first dabble at participating in a community/open source project. I work mostly with html and PHP now, but I still remember a bit of C and perl, from my former job, 5 years ago. Python and I still can't see each other, though. Gdb scares me a bit. ...why shoud you trust me? hmm. nice question. Ain't got no sure-fire answer to that. Can only tell you that I'm stubborn, I like things to work, I like to fix things that don't work as best as I can and then leave 'em alone. I like to learn. I'm paranoid. I hate spam, scriptkiddies and PHBs. I wish also to learn how to work with source rpms. 7. GPG keyID & fingerprint: pub 1024D/172B7B1B 2004-09-24 Barbara Pennacchi Key fingerprint = 9E7F 3D74 CF96 CE1A F276 3509 9180 0182 172B 7B1B sub 1024g/A50F163C 2004-09-24 Please note that I'd use GPG only for Bugzilla reports. -- +--------------------------------------------------------------------+ | WARNING WARNING WARNING *** EMAIL ADDRESS CHANGED! | | USE EMAIL ADDRESS PROVIDED BELOW | | IF YOU KEEP WRITING TO THE OLD ADDRESS IT IS NOT MY FAULT! | +--------------------------------------------------------------------+ | Barbara Pennacchi b.pennacchi at istc.cnr.it | | Consiglio Nazionale delle Ricerche | | Istituto di Scienze e Tecnologie della Cognizione | | V.le Marx 15, 00137 Roma, Italia | | http://www.istc.cnr.it/ | +--------------------------------------------------------------------+ From buso at fbinfo.com.br Fri Sep 24 22:57:09 2004 From: buso at fbinfo.com.br (BYTE SAVE INF. LTDA ME) Date: Fri, 24 Sep 2004 19:57:09 -0300 Subject: Brazil Message-ID: <00ec01c4a289$d2af0040$19a9fea9@intel> Sou do Brasil, e uso o fedora core 1, gostaria de informa??es de como ir? ficar o projeto no legacy, ter? continua??o? -------------- next part -------------- An HTML attachment was scrubbed... URL: From dom at earth.li Sat Sep 25 16:53:28 2004 From: dom at earth.li (Dominic Hargreaves) Date: Sat, 25 Sep 2004 17:53:28 +0100 Subject: Round-up, 2004-09-25 Message-ID: <20040925165326.GA26283@home.thedom.org> $Id: issues.txt,v 1.57 2004/09/25 15:01:44 dom Exp $ See bottom for changes This list is also available at http://www-astro.physics.ox.ac.uk/~dom/legacy/issues.txt Packages that have been verified and should be fully released ------------------------------------------------------------- tcpdump - https://bugzilla.fedora.us/show_bug.cgi?id=1468 cadaver - https://bugzilla.fedora.us/show_bug.cgi?id=1552 flim - https://bugzilla.fedora.us/show_bug.cgi?id=1581 rsync - https://bugzilla.fedora.us/show_bug.cgi?id=1569 (but superceded) xchat - https://bugzilla.fedora.us/show_bug.cgi?id=1549 squirrelmail - https://bugzilla.fedora.us/show_bug.cgi?id=1733 Packages waiting to be built for updates-testing ------------------------------------------------ gaim - https://bugzilla.fedora.us/show_bug.cgi?id=1237 lha - https://bugzilla.fedora.us/show_bug.cgi?id=1833 ethereal - https://bugzilla.fedora.us/show_bug.cgi?id=1840 XFree86 - https://bugzilla.fedora.us/show_bug.cgi?id=1289 mod_proxy - https://bugzilla.fedora.us/show_bug.cgi?id=1737 rsync - https://bugzilla.fedora.us/show_bug.cgi?id=2003 mod_ssl - https://bugzilla.fedora.us/show_bug.cgi?id=1888 XFree86 - https://bugzilla.fedora.us/show_bug.cgi?id=1831 gdk-pixbuf - https://bugzilla.fedora.us/show_bug.cgi?id=1371 (rh73,superceded) glibc - https://bugzilla.fedora.us/show_bug.cgi?id=1947 kernel - https://bugzilla.fedora.us/show_bug.cgi?id=1804 abiword - https://bugzilla.fedora.us/show_bug.cgi?id=1906 sysstat - https://bugzilla.fedora.us/show_bug.cgi?id=1372 Packages in state RESOLVED (ie exist in updates-testing) that need active work. ------------------------------------------------------------------ mailman - https://bugzilla.fedora.us/show_bug.cgi?id=1269 There were some unconfirmed reports of breakage with the candidate. This needs more QA before release. mod_python - https://bugzilla.fedora.us/show_bug.cgi?id=1325 Needs 1 VERIFY before release. ethereal - https://bugzilla.fedora.us/show_bug.cgi?id=1419 Needs 2 VERIFY before release. - but dup with 1840? kernel - https://bugzilla.fedora.us/show_bug.cgi?id=1484 Needs missing file rebuilt for verification - but preferentially put work into later kernel ticket mozilla - https://bugzilla.fedora.us/show_bug.cgi?id=1532 Needs 2 VERIFY but has been superceded lha - https://bugzilla.fedora.us/show_bug.cgi?id=1547 Needs 2 VERIFY but has been superceded squid - https://bugzilla.fedora.us/show_bug.cgi?id=1732 Needs 1 VERIFY before release (but about to be superceded?) cvs - https://bugzilla.fedora.us/show_bug.cgi?id=1735 Needs VERIFY before release especially for rh73 Packages in state UNCONFIRMED, NEW, ASSIGNED or REOPENED: -------------------------------------------------------- * readline - https://bugzilla.fedora.us/show_bug.cgi?id=2017 Another not fixed before EOL (rh9). WONTFIX? netpbm - https://bugzilla.fedora.us/show_bug.cgi?id=1257 Needs PUBLISH, especially for rh9 kdelibs - https://bugzilla.fedora.us/show_bug.cgi?id=1373 Needs 2 PUBLISH (superceded) yum - https://bugzilla.fedora.us/show_bug.cgi?id=1604 Needs 2 PUBLISH mod_ssl - https://bugzilla.fedora.us/show_bug.cgi?id=1708 Needs PUBLISH for rh9 (but superceded) krb5 - https://bugzilla.fedora.us/show_bug.cgi?id=1726 Obsoleted libxml - https://bugzilla.fedora.us/show_bug.cgi?id=1324 Sort out confusion over status over version in updates-testing and add RESOLVED flag. mc - https://bugzilla.fedora.us/show_bug.cgi?id=1548 Need 1 PUBLISH (but superceded?) libpng - https://bugzilla.fedora.us/show_bug.cgi?id=1550 Superceded libpng - https://bugzilla.fedora.us/show_bug.cgi?id=1943 Need 1 PUBLISH for rh9 tripwire - https://bugzilla.fedora.us/show_bug.cgi?id=1719 Resolve problems with how to version and build fix apache - https://bugzilla.fedora.us/show_bug.cgi?id=1805 Is this redundant? mysql - https://bugzilla.fedora.us/show_bug.cgi?id=1832 Needs 1 PUBLISH but superceded? mozilla - https://bugzilla.fedora.us/show_bug.cgi?id=1834 Needs PUBLISH especially for rh73 and FC1 php - https://bugzilla.fedora.us/show_bug.cgi?id=1868 Needs PUBLISH, especially for rh7.3 samba - https://bugzilla.fedora.us/show_bug.cgi?id=1924 Needs PUBLISH, especially for rh9 gnome vfs - https://bugzilla.fedora.us/show_bug.cgi?id=1944 Needs PUBLISH, especially for rh9 sox - https://bugzilla.fedora.us/show_bug.cgi?id=1945 Needs PUBLISH for rh9 and possible renaming of rh7.3 package qt - https://bugzilla.fedora.us/show_bug.cgi?id=2002 Needs 2 PUBLISH gdk-pixbuf - https://bugzilla.fedora.us/show_bug.cgi?id=2005 Needs 2 PUBLISH mysql - https://bugzilla.fedora.us/show_bug.cgi?id=2006 Needs 2 PUBLISH ruby - https://bugzilla.fedora.us/show_bug.cgi?id=2007 needs work kdelibs - https://bugzilla.fedora.us/show_bug.cgi?id=2008 Needs 2 PUBLISH mc - https://bugzilla.fedora.us/show_bug.cgi?id=2009 Needs 2 PUBLISH pam_wheel - https://bugzilla.fedora.us/show_bug.cgi?id=2010 Needs PUBLISH and full auditing? krb5 - https://bugzilla.fedora.us/show_bug.cgi?id=2040 Needs 1 PUBLISH for rh9 / investigate possible bug introduced imlib - https://bugzilla.fedora.us/show_bug.cgi?id=2051 Needs more work for further bugs ImageMagick - https://bugzilla.fedora.us/show_bug.cgi?id=2052 Needs 2 PUBLISH squid - https://bugzilla.fedora.us/show_bug.cgi?id=2053 Needs 2 PUBLISH for rh9 samba - https://bugzilla.fedora.us/show_bug.cgi?id=2057 Need maybe another PUBLISH for each release otherwise building cdrecord - https://bugzilla.fedora.us/show_bug.cgi?id=2058 Needs 2 PUBLISH for rh9 apache - https://bugzilla.fedora.us/show_bug.cgi?id=2068 Needs PUBLISH especially for rh9 cups - https://bugzilla.fedora.us/show_bug.cgi?id=2072 Needs 2 PUBLISH gtk2 - https://bugzilla.fedora.us/show_bug.cgi?id=2073 Needs 2 PUBLISH openoffice - https://bugzilla.fedora.us/show_bug.cgi?id=2074 Needs 2 PUBLISH for rh9 and fc1 libxpm - https://bugzilla.fedora.us/show_bug.cgi?id=2075 Needs packages/confirmation cupsomatic - https://bugzilla.fedora.us/show_bug.cgi?id=2076 Needs 1 PUBLISH redhat-config-nfs - https://bugzilla.fedora.us/show_bug.cgi?id=2086 Need 1 or 2 PUBLISH mozilla - https://bugzilla.fedora.us/show_bug.cgi?id=2089 Needs packages (waiting for RHEL?) General (non-package bugs) -------------------------- fc1 repo - https://bugzilla.fedora.us/show_bug.cgi?id=2087 Notes ----- Needs PUBLISH means that there are packages available for QA that need to be QAd at the source level. Needs VERIFY means that there are updates-testing packages that need testing. This is the easy bit, let's get this old ones out of the way ASAP. * means that there is a judgement call that can be made on the bug system immediately. Please follow up onlist with opinions. Changes ------- $Log: issues.txt,v $ Revision 1.57 2004/09/25 15:01:44 dom update httpd Revision 1.56 2004/09/24 20:38:48 dom update openoffice Revision 1.55 2004/09/24 20:37:35 dom update sysstat, gnome-vfs Revision 1.54 2004/09/24 13:46:28 dom update mozilla Revision 1.53 2004/09/24 09:34:05 dom update mozilla, redhat-config-nfs, fc1 repo, apache Revision 1.52 2004/09/23 00:39:55 dom update cvs, krb6, cupsomatic, redhat-config-nfs Revision 1.51 2004/09/22 14:15:21 dom update mozilla, openoffice with fc1 reference Revision 1.50 2004/09/21 23:12:38 dom update mozilla, cupsomatic. Revision 1.49 2004/09/21 00:15:09 dom update mc Revision 1.48 2004/09/20 23:41:58 dom add cvs -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From timtak at nihonbunka.com Sun Sep 26 14:12:22 2004 From: timtak at nihonbunka.com (Takemoto) Date: Sun, 26 Sep 2004 23:12:22 +0900 Subject: Self Introduction: Pavel Kankovsky References: <20040916101626.31C9.0@argo.troja.mff.cuni.cz> Message-ID: <053d01c4a3d3$a527ea60$0b01a8c0@exusasus> 1. Full legal name Timoty Takemoto ne Williams, was Leuers 2. Location (Country, City, etc) Japan (but I am from the UK originally) 3. Profession or Student status University teacher. 4. Company or School Yamaguchi University 5. Your goals in the Fedora Legacy Project * Which OS versions are you interested in? RHL9 * Do you want to do QA for packages? I am not sure what this means. * Anything else special? No 6. Historical qualifications * What other projects have you worked on in the past? I am an active member of moodle.org in a user support sort of way. * What computer languages and other skills do you know? I can hack php. I used to program in pascal many years ago. * Why should we trust you? Sounds like a bad idea to me. 7. GPG KEYID and fingerprint Who? I am just a guy that bought a book with an RHL9 CD. It installed just like Windows - a piece of cake. It looks like Windows. It cost next to nothing. But it acts as a server! Wow! I use it for my classes. The server still seems to run fine. At first I could press a button and download things, such as php, from the RH site, sort of like Windows Update (I use win2k). There have been some essential patches from Windows Update, to stop really nasty viri. I am here in the hope that I will be able read messages saying things like "RH9 has been breached. Download this patch now!" But since the "End of life" I have downloaded nothing. And I am still not sure what "yum" or "apt" is but I think that they are needed for downloading patches. It all looks too complicated. I am thinking of moving to mandrake or whitebox or something, but my RH9 box still seems to work fine. Tim From marcdeslauriers at videotron.ca Tue Sep 28 11:45:09 2004 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Tue, 28 Sep 2004 07:45:09 -0400 Subject: Fedora Legacy Test Update Notification: sysstat Message-ID: <1096371908.29310.1.camel@mdlinux> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - --------------------------------------------------------------------- Fedora Legacy Test Update Notification FEDORALEGACY-2004-1372 Bugzilla https://bugzilla.fedora.us/show_bug.cgi?id=1372 2004-09-28 - --------------------------------------------------------------------- Name : sysstat Versions : 7.3: 4.0.3-4 Summary : The sar and iostat system monitoring commands. Description : This package provides the sar and iostat commands for Linux. Sar and iostat enable system monitoring of disk, network, and other IO activity. - --------------------------------------------------------------------- Update Information: CAN-2004-0107: A bug was found in the Red Hat sysstat package post and trigger scripts, which used insecure temporary file names. A local attacker could overwrite system files using carefully-crafted symbolic links in the /tmp directory. - --------------------------------------------------------------------- 7.3 changelog: * Tue Jun 08 2004 Jesse Keating - - Added gettext as a BuildReq. * Thu Mar 11 2004 Michal Jaegermann - - repackaged changes from rhl9 for earlier distributions * Tue Feb 24 2004 Nils Philippsen 4.0.7-3.rhl9.1 - - fix insecure tmp files in scripts (#78212) - - handle interface names longer than 5 characters (#92052) - - increase maximum number of partitions (#110822) - --------------------------------------------------------------------- This update can be downloaded from: http://download.fedoralegacy.org/redhat/ (sha1sums) b2d1ced29b39cd024169b173d01db6fa99327bfb 7.3/updates-testing/i386/sysstat-4.0.3-4.legacy.i386.rpm 5bd937c2c0d643ba5a4dcab9c1f5ded2d67c9fb5 7.3/updates-testing/SRPMS/sysstat-4.0.3-4.legacy.src.rpm - --------------------------------------------------------------------- Please test and comment in bugzilla. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBWU5xLMAs/0C4zNoRAreUAJ42t6VLM5NvCVhqrp4N+DPfJWuLvACgg39u ZV6BH2XPsNnVW7h2IvKFSqE= =/eDp -----END PGP SIGNATURE----- From marcdeslauriers at videotron.ca Tue Sep 28 11:45:52 2004 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Tue, 28 Sep 2004 07:45:52 -0400 Subject: Fedora Legacy Test Update Notification: gaim Message-ID: <1096371952.29310.3.camel@mdlinux> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - --------------------------------------------------------------------- Fedora Legacy Test Update Notification FEDORALEGACY-2004-1237 Bugzilla https://bugzilla.fedora.us/show_bug.cgi?id=1237 2004-09-28 - --------------------------------------------------------------------- Name : gaim Versions : 7.3: 0.82.1-0.73.2, 9: 0.82.1-0.90.2 Summary : A GTK+ clone of the AOL Instant Messenger client. Description : Gaim is a clone of America Online's Instant Messenger client. It features nearly all of the functionality of the official AIM client while also being smaller, faster, and commercial-free. - --------------------------------------------------------------------- Update Information: Issues fixed with this gaim release include: Multiple buffer overflows that affect versions of Gaim 0.75 and earlier. 1) When parsing cookies in a Yahoo web connection, 2) YMSG protocol overflows parsing the Yahoo login webpage, 3) a YMSG packet overflow, 4) flaws in the URL parser, and 5) flaws in HTTP Proxy connect. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-0006 to these issues. A buffer overflow in Gaim 0.74 and earlier in the Extract Info Field Function used for MSN and YMSG protocol handlers. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-0007 to this issue. An integer overflow in Gaim 0.74 and earlier, when allocating memory for a directIM packet results in heap overflow. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-0008 to this issue. Buffer overflow bugs were found in the Gaim MSN protocol handler. In order to exploit these bugs, an attacker would have to perform a man in the middle attack between the MSN server and the vulnerable Gaim client. Such an attack could allow arbitrary code execution. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-0500 to this issue. An integer overflow bug has been found in the Gaim Groupware message receiver. It is possible that if a user connects to a malicious server, an attacker could send carefully crafted data which could lead to arbitrary code execution on the victims machine. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-0754 to this issue. A shell escape bug has been found in the Gaim smiley theme file installation. When a user installs a smiley theme, which is contained within a tar file, the unarchiving of the data is done in an unsafe manner. An attacker could create a malicious smiley theme that would execute arbitrary commands if the theme was installed by the victim. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-0784 to this issue. Buffer overflow bugs have been found in the Gaim URL decoder, local hostname resolver, and the RTF message parser. It is possible that a remote attacker could send carefully crafted data to a vulnerable client and lead to a crash or arbitrary code execution. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-0785 to this issue. - --------------------------------------------------------------------- 7.3 changelog: * Mon Sep 27 2004 Marc Deslauriers 0.82.1-0.73.2.legacy - - Added mozilla-nspr-devel and mozilla-nss BuildRequires - - Specify mozilla version * Sun Sep 05 2004 Marc Deslauriers 0.82.1-0.73.1.legacy - - Updated to 0.82.1 * Sat Jun 12 2004 Marc Deslauriers 0.78-0.73.1.legacy - - Rebuilt as Fedora Legacy update for rh73 (FL#1237) - - Disabled some requirements not available on rh73 - - Removed Fedora specific config file and patches - - Created a desktop file for rh73 - - Removed docklet.so plugin as it doesn't work in rh73 9 changelog: * Mon Sep 27 2004 Marc Deslauriers 0.82.1-0.90.2.legacy - - Added mozilla-nspr-devel and mozilla-nss BuildRequires * Sun Sep 05 2004 Marc Deslauriers 0.82.1-0.90.1.legacy - - Updated to 0.82.1 * Sat Jun 12 2004 Marc Deslauriers 0.78-0.90.1.legacy - - Rebuilt as Fedora Legacy update for rh9 (FL#1237) - - Disabled some requirements not available on rh9 - --------------------------------------------------------------------- This update can be downloaded from: http://download.fedoralegacy.org/redhat/ (sha1sums) cda084b78e263bb725ad92fdef0fc4b329b705d5 7.3/updates-testing/i386/gaim-0.82.1-0.73.2.legacy.i386.rpm e28d0c278324c7a508af7a30565cc5741b7ec4f0 7.3/updates-testing/SRPMS/gaim-0.82.1-0.73.2.legacy.src.rpm a35de8c26f1c748cd773957bddebb95114b711e2 9/updates-testing/i386/gaim-0.82.1-0.90.2.legacy.i386.rpm 2a6144f3fac77e921de382548f1ac11ad3da9d83 9/updates-testing/SRPMS/gaim-0.82.1-0.90.2.legacy.src.rpm - --------------------------------------------------------------------- Please test and comment in bugzilla. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBWU5nLMAs/0C4zNoRAi5wAKCBu36xXdWyf1L4pAit712l79NajgCcDzs4 ADzM/az0JZVtWD88ftwB4Tk= =Utkq -----END PGP SIGNATURE----- From marcdeslauriers at videotron.ca Wed Sep 29 10:19:26 2004 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Wed, 29 Sep 2004 06:19:26 -0400 Subject: Fedora Legacy Test Update Notification: php Message-ID: <1096453166.3958.0.camel@mdlinux> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - --------------------------------------------------------------------- Fedora Legacy Test Update Notification FEDORALEGACY-2004-1868 Bugzilla https://bugzilla.fedora.us/show_bug.cgi?id=1868 2004-09-29 - --------------------------------------------------------------------- Name : php Versions : 7.3: 4.1.2-7.3.9.legacy, 9: 4.2.2-17.5.legacy Summary : The PHP HTML-embedded scripting language. Description : PHP is an HTML-embedded scripting language. PHP attempts to make it easy for developers to write dynamically generated webpages. PHP also offers built-in database integration for several commercial and non-commercial database management systems, so writing a database-enabled webpage with PHP is fairly simple. The most common use of PHP coding is probably as a replacement for CGI scripts. The mod_php module enables the Apache Web server to understand and process the embedded PHP language in Web pages. - --------------------------------------------------------------------- Update Information: Stefan Esser discovered a flaw when memory_limit is enabled in versions of PHP 4 before 4.3.8. If a remote attacker could force the PHP interpreter to allocate more memory than the memory_limit setting before script execution begins, then the attacker may be able to supply the contents of a PHP hash table remotely. This hash table could then be used to execute arbitrary code as the 'apache' user. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-0594 to this issue. This issue has a higher risk when PHP is running on an instance of Apache which is vulnerable to CAN-2004-0493. It may also be possible to exploit this issue if using a non-default PHP configuration with the "register_defaults" setting is changed to "On". Stefan Esser discovered a flaw in the strip_tags function in versions of PHP before 4.3.8. The strip_tags function is commonly used by PHP scripts to prevent Cross-Site-Scripting attacks by removing HTML tags from user-supplied form data. By embedding NUL bytes into form data, HTML tags can in some cases be passed intact through the strip_tags function, which may allow a Cross-Site-Scripting attack. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-0595 to this issue. - --------------------------------------------------------------------- 7.3 changelog: * Sun Aug 01 2004 John Dalbec 4.1.2-7.3.9.legacy - - Added missing BuildRequires: flex mm-devel libtool * Mon Jul 26 2004 Marc Deslauriers 4.1.2-7.3.8.legacy - - Added better security fix for CAN-2004-0594 - - Added fixes for various compiler warnings * Thu Jul 15 2004 Marc Deslauriers 4.1.2-7.3.7.legacy - - Added security fix for CAN-2004-0594 - - Added security fix for CAN-2004-0595 - - Added a few more fixes - - Added imap-devel BuildRequires 9 changelog: * Tue Sep 28 2004 Marc Deslauriers 4.2.2-17.5.legacy - - Added flex and libtool to BuildRequires * Mon Jul 26 2004 Marc Deslauriers 4.2.2-17.4.legacy - - Added better security fix for CAN-2004-0594 * Thu Jul 15 2004 Marc Deslauriers 4.2.2-17.3.legacy - - Added security fix for CAN-2004-0594 - - Added security fix for CAN-2004-0595 - - Added a few more fixes - --------------------------------------------------------------------- This update can be downloaded from: http://download.fedoralegacy.org/redhat/ (sha1sums) 384ee0d9afcac322cc2fd0597af0a8a9b8fa700c 7.3/updates-testing/i386/php-4.1.2-7.3.9.legacy.i386.rpm d47cd648c2b969b425af28654c5b6e1acc9161ed 7.3/updates-testing/i386/php-devel-4.1.2-7.3.9.legacy.i386.rpm 637b17298eafb570399bd3128db0c1e222f93f18 7.3/updates-testing/i386/php-imap-4.1.2-7.3.9.legacy.i386.rpm 26bff2604c3899cfcc3d34e119e5f293878ba50f 7.3/updates-testing/i386/php-ldap-4.1.2-7.3.9.legacy.i386.rpm ea9c70f1970de5ca0b379b21ce28c0dbc4f048c0 7.3/updates-testing/i386/php-manual-4.1.2-7.3.9.legacy.i386.rpm 1179a9c43339097cd0c3f7dbfee4995e2853a105 7.3/updates-testing/i386/php-mysql-4.1.2-7.3.9.legacy.i386.rpm efd4323aff5c81817be4fc0a0a32a1e9c05c50c7 7.3/updates-testing/i386/php-odbc-4.1.2-7.3.9.legacy.i386.rpm f0cc7d94a1ea5422d3950975f8b75476ddb3ed70 7.3/updates-testing/i386/php-pgsql-4.1.2-7.3.9.legacy.i386.rpm 666175913adda7b584821fe9fef7bfd20bf36e3d 7.3/updates-testing/i386/php-snmp-4.1.2-7.3.9.legacy.i386.rpm 73eb5523a60a920cca612021eb7cc73bd487e319 7.3/updates-testing/SRPMS/php-4.1.2-7.3.9.legacy.src.rpm 36beb0117341d9dae1d195195620a02f1802ab52 9/updates-testing/i386/php-4.2.2-17.5.legacy.i386.rpm d251cb7331596c4d634f1594a39feb688278847a 9/updates-testing/i386/php-devel-4.2.2-17.5.legacy.i386.rpm 34bcc424439e2e8d260bb50c27d2dea26e664ef6 9/updates-testing/i386/php-imap-4.2.2-17.5.legacy.i386.rpm c1f15969980ac1911bb84d6744c2cfcdad296746 9/updates-testing/i386/php-ldap-4.2.2-17.5.legacy.i386.rpm ca252f411e06436c9578a3357cb8b6630a9cc85e 9/updates-testing/i386/php-manual-4.2.2-17.5.legacy.i386.rpm af4fea6f8e5321dc176061e7dbf32280f83a02d5 9/updates-testing/i386/php-mysql-4.2.2-17.5.legacy.i386.rpm 81e8b1e2b55906710eb64413a17b5b9a5d3e9be7 9/updates-testing/i386/php-odbc-4.2.2-17.5.legacy.i386.rpm 83546545b3af70aee72ba0da9196ad37cb872ead 9/updates-testing/i386/php-pgsql-4.2.2-17.5.legacy.i386.rpm d39845815418f09ff9b842dcb7e193a7cdd1736c 9/updates-testing/i386/php-snmp-4.2.2-17.5.legacy.i386.rpm fb8475b2292b5b84785b322773c723b5dc9a9eed 9/updates-testing/SRPMS/php-4.2.2-17.5.legacy.src.rpm - --------------------------------------------------------------------- Please test and comment in bugzilla. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBWovvLMAs/0C4zNoRAvRLAJ929em8OuLde4sIAGH9oG24QfqAcwCfQJ7J e+vAJSWmo4Q5z2/SELxnVTI= =hR+G -----END PGP SIGNATURE----- From marcdeslauriers at videotron.ca Wed Sep 29 10:21:16 2004 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Wed, 29 Sep 2004 06:21:16 -0400 Subject: Fedora Legacy Test Update Notification: rsync Message-ID: <1096453276.3958.4.camel@mdlinux> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - --------------------------------------------------------------------- Fedora Legacy Test Update Notification FEDORALEGACY-2004-2003 Bugzilla https://bugzilla.fedora.us/show_bug.cgi?id=2003 2004-09-29 - --------------------------------------------------------------------- Name : rsync Versions : 7.3: 2.5.7-2.legacy.7x, 9: 2.5.7-2.legacy.9 Summary : A program for synchronizing files over a network. Description : Rsync uses a reliable algorithm to bring remote and host files into sync very quickly. Rsync is fast because it just sends the differences in the files over the network instead of sending the complete files. Rsync is often used as a very powerful mirroring process or just as a more capable replacement for the rcp command. A technical report which describes the rsync algorithm is included in this package. - --------------------------------------------------------------------- Update Information: Rsync before 2.6.1 does not properly sanitize paths when running a read/write daemon without using chroot. This could allow a remote attacker to write files outside of the module's "path", depending on the privileges assigned to the rsync daemon. Users not running an rsync daemon, running a read-only daemon, or running a chrooted daemon are not affected by this issue. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-0426 to this issue. Versions of rsync up to and including version 2.6.2 contain a path sanitization issue. This issue could allow an attacker to read or write files outside of the rsync directory. This vulnerability is only exploitable when an rsync server is enabled and is not running within a chroot. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-0792 to this issue. - --------------------------------------------------------------------- 7.3 changelog: * Mon Aug 30 2004 Dave Botsch 2.5.7-2.legacy.7x - - apply sanitize patch for CAN-2004-0792 - - rsync path sanitizing bug * Wed May 05 2004 Seth Vidal 2.5.7-1.legacy.7x - - apply sanitize path's patch for: - - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0426 - - Fix for segfault when RSYNC_PROXY port part is too long 9 changelog: * Wed Sep 01 2004 Marc Deslauriers 2.5.7-2.legacy.9 - - apply sanitize patch for CAN-2004-0792 - - rsync path sanitizing bug * Tue May 04 2004 Rok Papez 2.5.7-1.legacy.9 - - Fix for segfault when RSYNC_PROXY port part is too long - - Fix for CAN-2004-0426: not properly sanitizing paths - --------------------------------------------------------------------- This update can be downloaded from: http://download.fedoralegacy.org/redhat/ (sha1sums) 1101ad1c735a11c9be6f4d45971374a6195431d9 7.3/updates-testing/i386/rsync-2.5.7-2.legacy.7x.i386.rpm 4bb344d823f423cf5c1cc64d949dd1d9408960e7 7.3/updates-testing/SRPMS/rsync-2.5.7-2.legacy.7x.src.rpm 49a3fa2fe967ed5c62994d5785463357aaf49de5 9/updates-testing/i386/rsync-2.5.7-2.legacy.9.i386.rpm 84ec22198c189660f3cf2b967b710de9a04d6b22 9/updates-testing/SRPMS/rsync-2.5.7-2.legacy.9.src.rpm - --------------------------------------------------------------------- Please test and comment in bugzilla. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBWoyBLMAs/0C4zNoRAv19AKCH/vj9j5lGDLW4Abyhz4IAMI68HQCgwyuZ n3lwL6V0irPwag+g2uGDRmY= =SBxz -----END PGP SIGNATURE----- From marcdeslauriers at videotron.ca Wed Sep 29 10:20:25 2004 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Wed, 29 Sep 2004 06:20:25 -0400 Subject: Fedora Legacy Test Update Notification: ethereal Message-ID: <1096453225.3958.2.camel@mdlinux> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - --------------------------------------------------------------------- Fedora Legacy Test Update Notification FEDORALEGACY-2004-1840 Bugzilla https://bugzilla.fedora.us/show_bug.cgi?id=1840 2004-09-29 - --------------------------------------------------------------------- Name : ethereal Versions : 7.3: 0.10.3-0.73.3.legacy, 9: 0.10.3-0.90.4.legacy Summary : Ethereal is a network traffic analyzer for Unix-ish operating systems. Description : Ethereal is a network traffic analyzer for Unix-ish operating systems. This package uses libpcap, a packet capture and filtering library, and contains command-line utilities, plugins and documentation for ethereal. A GTK+ based graphical user interface is available in a separate package. - --------------------------------------------------------------------- Update Information: Issues fixed with this Ethereal release include: Stefan Esser reported that Ethereal versions 0.10.1 and earlier contain stack overflows in the IGRP, PGM, Metflow, ISUP, TCAP, or IGAP dissectors. On a system where Ethereal is being run a remote attacker could send malicious packets that could cause Ethereal to crash or execute arbitrary code. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-0176 to this issue. Jonathan Heussser discovered that a carefully-crafted RADIUS packet could cause a crash. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-0365 to this issue. Ethereal 0.8.13 to 0.10.2 allows remote attackers to cause a denial of service (crash) via a zero-length Presentation protocol selector. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-0367 to this issue. The MMSE dissector in Ethereal releases 0.10.1 through 0.10.3 contained a buffer overflow flaw. On a system where Ethereal is running, a remote attacker could send malicious packets that could cause Ethereal to crash or execute arbitrary code. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-0507 to this issue. In addition, other flaws in Ethereal prior to 0.10.4 were found that could cause it to crash in response to carefully crafted SIP (CAN-2004-0504), AIM (CAN-2004-0505), or SPNEGO (CAN-2004-0506) packets. The SNMP dissector in Ethereal releases 0.8.15 through 0.10.4 contained a memory read flaw. On a system where Ethereal is running, a remote attacker could send malicious packets that could cause Ethereal to crash or possibly execute arbitrary code. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-0635 to this issue. The SMB dissector in Ethereal releases 0.9.15 through 0.10.4 contained a null pointer flaw. On a system where Ethereal is running, a remote attacker could send malicious packets that could cause Ethereal to crash. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-0634 to this issue. The iSNS dissector in Ethereal releases 0.10.3 through 0.10.4 contained an integer overflow flaw. On a system where Ethereal is running, a remote attacker could send malicious packets that could cause Ethereal to crash or possibly execute arbitrary code. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-0633 to this issue. - --------------------------------------------------------------------- 7.3 changelog: * Thu Jul 08 2004 Marc Deslauriers 0.10.3-0.73.3.legacy - - Included backported security fixes from ethereal-0.10.5 (CAN-2004-0633, CAN-2004-0634, CAN-2004-0635) * Thu Jun 10 2004 Jesse Keating 0.10.3-0.73.2.legacy - - Missing build-req of python * Fri Jun 04 2004 Marc Deslauriers 0.10.3-0.73.1.legacy - - Updated to version 0.10.3 - - Included backported security fixes from ethereal-0.10.4 9 changelog: * Thu Jul 08 2004 Marc Deslauriers 0.10.3-0.90.4.legacy - - Included backported security fixes from ethereal-0.10.5 (CAN-2004-0633, CAN-2004-0634, CAN-2004-0635) * Thu Jun 10 2004 Jesse Keating 0.10.3-0.90.3.legacy - - Added elfutils-devel and python as build-reqs. * Fri Jun 04 2004 Marc Deslauriers 0.10.3-0.90.2.legacy - - Included backported security fixes from ethereal-0.10.4 - --------------------------------------------------------------------- This update can be downloaded from: http://download.fedoralegacy.org/redhat/ (sha1sums) 9dea4bd2d8a8efce8722e7891a8b211ece731645 7.3/updates-testing/i386/ethereal-0.10.3-0.73.3.legacy.i386.rpm f3defe29af6aceec7df646a0a49d8654823796e1 7.3/updates-testing/i386/ethereal-gnome-0.10.3-0.73.3.legacy.i386.rpm 33c5ea5e2cabcd186aace74b9679a07c950d0d89 7.3/updates-testing/SRPMS/ethereal-0.10.3-0.73.3.legacy.src.rpm 5c8e340c29644e861ebe064158b04420ca447066 9/updates-testing/i386/ethereal-0.10.3-0.90.4.legacy.i386.rpm beb7b34e7a09b29c32976f7af123c7712f469bc6 9/updates-testing/i386/ethereal-gnome-0.10.3-0.90.4.legacy.i386.rpm a32b6b54c36c2fe6a29e47080cadbb6ae87c8d6a 9/updates-testing/SRPMS/ethereal-0.10.3-0.90.4.legacy.src.rpm - --------------------------------------------------------------------- Please test and comment in bugzilla. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBWoxILMAs/0C4zNoRAnCTAJ41ZdvoxgqFehlZTk4Qm44MBshwQgCeKUsV sZjXZlAgMnqktd6WjeCmHxE= =rjH4 -----END PGP SIGNATURE----- From dom at earth.li Wed Sep 29 10:54:09 2004 From: dom at earth.li (Dominic Hargreaves) Date: Wed, 29 Sep 2004 11:54:09 +0100 Subject: Fedora Legacy Test Update Notification: Kernel Message-ID: <20040929105406.GA10467@home.thedom.org> --------------------------------------------------------------------- Fedora Test Update Notification FEDORALEGACY-2004-1804 Bugzilla https://bugzilla.fedora.us/show_bug.cgi?id=1804 2004-09-29 --------------------------------------------------------------------- Name : kernel Version 7.3 : 2.4.20-37.7.legacy Version 9 : 2.4.20-37.9.legacy Summary : The Linux kernel (the core of the Linux operating system) Description : The kernel package contains the Linux kernel (vmlinuz), the core of your Red Hat Linux operating system. The kernel handles the basic functions of the operating system: memory allocation, process allocation, device input and output, etc. --------------------------------------------------------------------- Update Information: iDefense reported a buffer overflow flaw in the ISO9660 filesystem code. An attacker could create a malicious filesystem in such a way that they could gain root privileges if that filesystem is mounted. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-0109 to this issue. This issue is addressed in the Red Hat 7.3 packages referenced in this advisory, having been previously fixed for Red Hat 9. These packages also contain an updated fix with additional checks for issues in the R128 Direct Render Infrastructure. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-0003 to this issue. This issue was addressed in the Red Hat 7.3 packages referenced in this advisory, having been previously fixed for Red Hat 9. A bug in the SoundBlaster 16 code which did not properly handle certain sample sizes has been fixed. This flaw could be used by local users to crash a system. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-0178 to this issue. Paul Starzetz discovered flaws in the Linux kernel when handling file offset pointers. These consist of invalid conversions of 64 to 32-bit file offset pointers and possible race conditions. A local unprivileged user could make use of these flaws to access large portions of kernel memory. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-0415 to this issue. During an audit of the Linux kernel, SUSE discovered a flaw that allowed a user to make unauthorized changes to the group ID of files in certain circumstances. In the 2.4 kernel, as shipped with Red Hat Enterprise Linux, the only way this could happen is through the kernel nfs server. A user on a system that mounted a remote file system from a vulnerable machine may be able to make unauthorized changes to the group ID of exported files. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-0497 to this issue. A flaw was found in Linux kernel versions 2.4 and 2.6 for x86 and x86_64 that allowed local users to cause a denial of service (system crash) by triggering a signal handler with a certain sequence of fsave and frstor instructions. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-0554 to this issue. Enhancements were committed to the 2.6 kernel by Al Viro which enabled the Sparse source code checking tool to check for a certain class of kernel bugs. A subset of these fixes also applies to various drivers in the 2.4 kernel. These flaws could lead to privilege escalation or access to kernel memory. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-0495 to these issues. Integer overflow in the Linux Broadcom 5820 cryptonet driver allows local users to cause a denial of service (crash) and possibly execute arbitrary code. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-0619 to this issue. This driver has been removed from this release. Integer overflow in the IEEE 1394 (Firewire) driver allows local users to cause a denial of service (crash) and possibly execute arbitrary code. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-0658 to this issue. The do_fork function in Linux 2.4.x before 2.4.26 had a bug which could trigger a memory leak leading to a denial of service. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-0427 to this issue. An integer signedness error in the cpufreq proc handle allowed local users to gain privileges. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-0228 to this issue. The JFS file system code in Linux 2.4.x had an information leak in which in-memory data is written to the device for the JFS file system, which allowed local users to obtain sensitive information by reading the raw device. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-0181 to this issue. The XFS file system code in Linux 2.4.x had an information leak in which in-memory data is written to the device for the XFS file system, which allowed local users to obtain sensitive information by reading the raw device. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-0133 to this issue. In addition, these packages correct further minor issues: An bug in the e1000 network driver. This bug could be used by local users to leak small amounts of kernel memory (CAN-2004-0535). Inappropriate permissions on /proc/scsi/qla2300/HbaApiNode (CAN-2004-0587). Potential buffer overflow in the panic() function (CAN-2004-0394). --------------------------------------------------------------------- Changelog: * Fri Aug 06 2004 Jon Peatfield - fix linux-2.4.21-file-offset-fixes.patch to work with older gcc - versions e.g. on RH73 (Michal Jaegermann ) - - include various patches from RHEL which we didn't have yet: - argument size checks in proc_tty.c, binfmt_elf.c, socket.c, - char/vt.c, cdrom/cdu31a.c, arch/i386/kernel/mtrr.c ; type - check/ATIME fix in af_unix.c ; return checking in - char/consolemap.c ; sanity check in isdn/pcbit/capi.c ; extra - checks and type fixes in isdn/isdn_ppp.c, isdn/isdn_common.c ; - eflasg fix in arch/i386/kernel/traps.c. (Michal Jaegermann - ) - - add usb sparse patch (CAN-2004-0685) (mjc at redhat.com) - see http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=127921 - - nfs patch from Trond to allow us to serve clients which use - cookies != 8 bytes, OSX 10.3 uses 30 FreeBSD uses 20... - See http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=125996 - http://www.fys.uio.no/~trondmy/src/Linux-2.4.x/2.4.23-rc1/linux-2.4.23-03-fix_osx.dif * Thu Aug 05 2004 Jon Peatfield - add in updated fix for e1000, qla /proc permissions fix - fix possible races/overflows in file offset handling (Alexander Viro) * Fri Jul 02 2004 Jon Peatfield - loosely based on fc1 changes by Dave Jones - add patch to fix missing checks in fchown() (CAN-2004-0497) - Drop Broadcom 5820 driver due to code quality concerns. * Fri Jun 18 2004 Dominic Hargreaves - Fix memory leak in kernel/fork.c. (CAN-2004-0427) - Numerous userspace pointer reference bugs found with the sparse tool by Al Viro. (CAN-2004-0495) - Fix e1000 driver information leak. (CAN-2004-0535) * Tue Jun 15 2004 Dominic Hargreaves - Fix local DoS in "clear_cpu()" macro. (CAN-2004-0554) * Thu May 13 2004 Dominic Hargreaves - Fix information leak in cpufreq userspace ioctl. (CAN-2004-0228) - Fix for C1 Halt Disconnect problem on nForce2 systems. * Wed May 05 2004 Dominic Hargreaves - Fix potential local denial of service in sb16 driver (CAN-2004-0178) - Fix information leak in JFS (CAN-2004-0181) - Add range checking to i810_dma() in DRM driver. - Make ioctl(FBIOGETCMAP) use copy_to_user() rather than memcpy() - Fix possible buffer overflow in panic() (CAN-2004-0394) * Tue Apr 13 2004 Dave Jones - Yet another additional r128 DRM check. (CAN-2004-0003) - Bounds checking in ISO9660 filesystem. (CAN-2004-0109) - Fix Information leak in EXT3 (CAN-2004-0133) - Fix local DoS in mremap() --------------------------------------------------------------------- This update can be downloaded from: http://download.fedoralegacy.org/redhat/ 8a1c65a280190c3fc5102bb5a37db4a6d38dc38c 7.3/updates-testing/i386/kernel-2.4.20-37.7.legacy.athlon.rpm b7a9696838f7c981fa9dc7f016c626f068d77f32 7.3/updates-testing/i386/kernel-2.4.20-37.7.legacy.i386.rpm b01d2fc73b95e89a67b9490b7f7c4261be0b2d92 7.3/updates-testing/i386/kernel-2.4.20-37.7.legacy.i586.rpm 2c64ea0f6f088eeb2a47eed62f20fce086695f1f 7.3/updates-testing/i386/kernel-2.4.20-37.7.legacy.i686.rpm e76f2bbdb94c0baa2d8c81df33f1f001b4eb6515 7.3/updates-testing/i386/kernel-bigmem-2.4.20-37.7.legacy.i686.rpm 302b9f0ae8e4b8dc975b0243ada68287508d85e9 7.3/updates-testing/i386/kernel-BOOT-2.4.20-37.7.legacy.i386.rpm c63c54ec6da4d10a21cd768d9596edb463dab3f3 7.3/updates-testing/i386/kernel-doc-2.4.20-37.7.legacy.i386.rpm ca0abce4704e89972b4d55edc615d1ac77c9038a 7.3/updates-testing/i386/kernel-smp-2.4.20-37.7.legacy.athlon.rpm e151c2fe55bfb2ecc802ccbc82b176b6e6e32e27 7.3/updates-testing/i386/kernel-smp-2.4.20-37.7.legacy.i586.rpm 8cddf2b85c8e0aa6442d111a4190c2b2ebc65d45 7.3/updates-testing/i386/kernel-smp-2.4.20-37.7.legacy.i686.rpm 40595f8d08b8b631742cfb891168a96de36364f0 7.3/updates-testing/i386/kernel-source-2.4.20-37.7.legacy.i386.rpm d5122c56d20371d25921a789f20b4a429f0ed0ee 7.3/updates-testing/SRPMS/kernel-2.4.20-37.7.legacy.src.rpm f93b63bc5a40f24351a2d7855aaa66aacf6b1349 9/updates-testing/i386/kernel-2.4.20-37.9.legacy.athlon.rpm 15c94e731201db0ad89b41d9b2c35e7f85d6f517 9/updates-testing/i386/kernel-2.4.20-37.9.legacy.i386.rpm 5ee67818d1902c1e7ef919e1986c4c6f5cb58b6c 9/updates-testing/i386/kernel-2.4.20-37.9.legacy.i586.rpm 4a61fc7fd41a7d35cfcc25178ec5cb659ed3f6fe 9/updates-testing/i386/kernel-2.4.20-37.9.legacy.i686.rpm 790eef91cb194f60ab6c9ec5b0c4f08365b02022 9/updates-testing/i386/kernel-bigmem-2.4.20-37.9.legacy.i686.rpm dd464f337d30580cd60b279d3b28f1ff972b718c 9/updates-testing/i386/kernel-BOOT-2.4.20-37.9.legacy.i386.rpm 6283845b3af07cf065902f3e75312a3ef7b5c90a 9/updates-testing/i386/kernel-doc-2.4.20-37.9.legacy.i386.rpm 25f86ab0bb3cfb9e1cf03e71af16c3d58e3db12b 9/updates-testing/i386/kernel-smp-2.4.20-37.9.legacy.athlon.rpm c3f2461bd36aba58139e3cb29e34ecf9e97f6daf 9/updates-testing/i386/kernel-smp-2.4.20-37.9.legacy.i586.rpm d03acba749f539607b3068670d8d2b12e7a98c02 9/updates-testing/i386/kernel-smp-2.4.20-37.9.legacy.i686.rpm 65079b01af9d60ca90b6650690634aa5d0c79cfa 9/updates-testing/i386/kernel-source-2.4.20-37.9.legacy.i386.rpm 4fdcc24dba64ef30ce49b170f6bbd3be98a129d8 9/updates-testing/SRPMS/kernel-2.4.20-37.9.legacy.src.rpm Please note that this update is also available via yum and apt through the updates-testing channel. Many people find this an easier way to apply updates. --------------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From dom at earth.li Wed Sep 29 10:54:32 2004 From: dom at earth.li (Dominic Hargreaves) Date: Wed, 29 Sep 2004 11:54:32 +0100 Subject: Fedora Legacy Test Update Notification: XFree86 Message-ID: <20040929105431.GB10467@home.thedom.org> --------------------------------------------------------------------- Fedora Test Update Notification FEDORALEGACY-2004-1831 Bugzilla https://bugzilla.fedora.us/show_bug.cgi?id=1831 2004-09-29 --------------------------------------------------------------------- Name : XFree86 Version : 4.3.0-2.90.57.legacy Summary : The basic fonts, programs and docs for an X workstation. Description : XFree86 is an open source implementation of the X Window System. It provides the basic low level functionality which full fledged graphical user interfaces (GUIs) such as GNOME and KDE are designed upon. --------------------------------------------------------------------- Update Information: Steve Rumble discovered that xdm in XFree86 opens a chooserFd TCP socket even when DisplayManager.requestPort is 0, which could allow remote attackers to connect to the port, in violation of the intended restrictions. --------------------------------------------------------------------- Changelog: * Tue Sep 28 2004 Dominic Hargreaves 4.3.0-2.x.57.legacy - Add BuildRequires on gcc-c++ * Tue Jul 06 2004 J.S.Peatfield 4.3.0-2.x.56.leg ac - fix CAN-2004-0419 - XDM in XFree86 socket open vulnerability with patch based on one from http://bugs.xfree86.org/show_bug.cgi?id=1376 --------------------------------------------------------------------- This update can be downloaded from: http://download.fedoralegacy.org/redhat/ 7373b7bffdce87d9692f76f1a3f8038a4dd06cfb 9/updates-testing/i386/XFree86-100dpi-fonts-4.3.0-2.90.57.legacy.i386.rpm 305807aabe1775410489be712b391be6db3ec5e0 9/updates-testing/i386/XFree86-4.3.0-2.90.57.legacy.i386.rpm 830b762d2ecf3fa41c762640c9cdd930bf272ed2 9/updates-testing/i386/XFree86-75dpi-fonts-4.3.0-2.90.57.legacy.i386.rpm 2a0a32dbd0e1d329896ff85ace84417054cc651d 9/updates-testing/i386/XFree86-base-fonts-4.3.0-2.90.57.legacy.i386.rpm 3740a0e48b10ce45a97d3e60a958a723961b9bf2 9/updates-testing/i386/XFree86-cyrillic-fonts-4.3.0-2.90.57.legacy.i386.rpm 18ad671755daeb990882630de217426010a2040d 9/updates-testing/i386/XFree86-devel-4.3.0-2.90.57.legacy.i386.rpm a43d31e70c84e77a4a4a986fdaef0b0a625daa51 9/updates-testing/i386/XFree86-doc-4.3.0-2.90.57.legacy.i386.rpm e6c1795cd1915f559d1cf3a583e07a9068092e5a 9/updates-testing/i386/XFree86-font-utils-4.3.0-2.90.57.legacy.i386.rpm 89aa4c43ed29222042e0d0d9cf84bd180a591438 9/updates-testing/i386/XFree86-ISO8859-14-100dpi-fonts-4.3.0-2.90.57.legacy.i386.rpm 4e715cf42babaa041acaad6ce8f4cfa2255b9af9 9/updates-testing/i386/XFree86-ISO8859-14-75dpi-fonts-4.3.0-2.90.57.legacy.i386.rpm b7c8916aed637c832d9d07fa3d16765e4cd8b263 9/updates-testing/i386/XFree86-ISO8859-15-100dpi-fonts-4.3.0-2.90.57.legacy.i386.rpm 58da214f4cc310e41d2aecdd9c38a618a2fd2397 9/updates-testing/i386/XFree86-ISO8859-15-75dpi-fonts-4.3.0-2.90.57.legacy.i386.rpm 6a815dba95f9250475de7be29e41faa19a881344 9/updates-testing/i386/XFree86-ISO8859-2-100dpi-fonts-4.3.0-2.90.57.legacy.i386.rpm da8a8c248c56bb2e7e55233e2668e1a6bf184199 9/updates-testing/i386/XFree86-ISO8859-2-75dpi-fonts-4.3.0-2.90.57.legacy.i386.rpm 38a71809da1e8e930511f0cc3ce1296ec5d9ba7e 9/updates-testing/i386/XFree86-ISO8859-9-100dpi-fonts-4.3.0-2.90.57.legacy.i386.rpm 7320da3031d5e52aff7e5a852d768b281bcb5e78 9/updates-testing/i386/XFree86-ISO8859-9-75dpi-fonts-4.3.0-2.90.57.legacy.i386.rpm d9c817e6cf113b97de218d71057dde823bffecee 9/updates-testing/i386/XFree86-libs-4.3.0-2.90.57.legacy.i386.rpm a1992724b585356c8645e4fa8a77fffa3371e6ae 9/updates-testing/i386/XFree86-libs-data-4.3.0-2.90.57.legacy.i386.rpm 658e243b612fa09e4db9f49e2461a9f8df9de6f9 9/updates-testing/i386/XFree86-Mesa-libGL-4.3.0-2.90.57.legacy.i386.rpm 8b545b3837ba1dd0c6326aecef464dc42c5b1733 9/updates-testing/i386/XFree86-Mesa-libGLU-4.3.0-2.90.57.legacy.i386.rpm 806053982f7777bb0868c3c75d6b21e6c23587e3 9/updates-testing/i386/XFree86-sdk-4.3.0-2.90.57.legacy.i386.rpm 6b6432e825829a60127cbe61cb281e81eb972221 9/updates-testing/i386/XFree86-syriac-fonts-4.3.0-2.90.57.legacy.i386.rpm 3a7b8ae74c215228a6ae1c423ae891a4211fd027 9/updates-testing/i386/XFree86-tools-4.3.0-2.90.57.legacy.i386.rpm 579b3456b8ad40f21afb99a5dff7ebe6f1e241ee 9/updates-testing/i386/XFree86-truetype-fonts-4.3.0-2.90.57.legacy.i386.rpm d4efc73d58bbaf3be6868eae6701a9b1654cfafc 9/updates-testing/i386/XFree86-twm-4.3.0-2.90.57.legacy.i386.rpm 6c49b54fbacd2c1f4f5eed2d3b6a77f79cf8f6a8 9/updates-testing/i386/XFree86-xauth-4.3.0-2.90.57.legacy.i386.rpm 8a1553bee519e073d769afadee8848f274000392 9/updates-testing/i386/XFree86-xdm-4.3.0-2.90.57.legacy.i386.rpm 3b04bd562750b72267403115be089cad469a82d8 9/updates-testing/i386/XFree86-xfs-4.3.0-2.90.57.legacy.i386.rpm 16db0d71ca67d7fd9c1500b979efcaefcfec65c8 9/updates-testing/i386/XFree86-Xnest-4.3.0-2.90.57.legacy.i386.rpm 0237c68cc9d8e2fbafd80c7af519c2587001e672 9/updates-testing/i386/XFree86-Xvfb-4.3.0-2.90.57.legacy.i386.rpm 7e8484046cbecc96263abf2d86282e59846cce74 9/updates-testing/SRPMS/XFree86-4.3.0-2.90.57.legacy.src.rpm Please note that this update is also available via yum and apt through the updates-testing channel. Many people find this an easier way to apply updates. --------------------------------------------------------------------- [-- Error: could not find beginning of PGP message! --] -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From b.pennacchi at istc.cnr.it Wed Sep 29 15:41:40 2004 From: b.pennacchi at istc.cnr.it (Barbara Pennacchi) Date: Wed, 29 Sep 2004 17:41:40 +0200 Subject: questions about yum.conf (long) Message-ID: <20040929154140.GC10614@sibannac> Hi, I have 3 questions about yum.conf (my version of yum is 2.0.7-3) 1) I've put 3 different servers in it, the nearest mirror first, then fedoralegacy.org and fedora.us for last, but it looks like yum ignores the order I put them in and tries to go to fedora.us first! (yum.conf available upon request) 2) If I do a yum check-update, I see there are updates to, say, tcpdump libpcap and arpwatch. But yum update alone ignores them. I have to specify the name of the rpm I want to upgrade. Sometimes I have to try twice before it gets the hint. (transcript available upon request as to not hog the ML) 3) has anyone checked the coherency between what's found in fedoralegacy's website regarding entries in yum.conf? Take, for example, http://www.fedoralegacy.org/download/ and http://www.fedoralegacy.org/docs/yum-rh9.php (i use a RH9 box). If you look carefully at the exapmles, there are slight differences in the structure of the baseurls. I know, I know: maybe both work just fine, but for someone newbish enough and not so much the average luser, this might leave them a bit stymied. P.S: I've set the debug level in yum.conf to 2. To what level should I put it as to see in the log something more about yum's almost-idiotic behaviour for questions 1 and 2? -- +--------------------------------------------------------------------+ | WARNING WARNING WARNING *** EMAIL ADDRESS CHANGED! | | USE EMAIL ADDRESS PROVIDED BELOW | | IF YOU KEEP WRITING TO THE OLD ADDRESS IT IS NOT MY FAULT! | +--------------------------------------------------------------------+ | Barbara Pennacchi b.pennacchi at istc.cnr.it | | Consiglio Nazionale delle Ricerche | | Istituto di Scienze e Tecnologie della Cognizione | | V.le Marx 15, 00137 Roma, Italia | | http://www.istc.cnr.it/ | +--------------------------------------------------------------------+ From dom at earth.li Wed Sep 29 16:12:29 2004 From: dom at earth.li (Dominic Hargreaves) Date: Wed, 29 Sep 2004 17:12:29 +0100 Subject: [FLSA-2004:1468] Updated tcpdump packages that fix multiple security vulnerabilities Message-ID: <20040929161226.GA11725@home.thedom.org> ----------------------------------------------------------------------- Fedora Legacy Update Advisory Synopsis: Updated tcpdump resolves security vulnerabilities Advisory ID: FLSA:1468 Issue date: 2004-09-29 Product: Red Hat Linux Keywords: Security Cross references: https://bugzilla.fedora.us/show_bug.cgi?id=1468 CVE Names: CAN-2004-0183, CAN-2004-0184 ----------------------------------------------------------------------- ----------------------------------------------------------------------- 1. Topic: Updated tcpdump packages that fix multiple security vulnerabilities are now available. 2. Relevant releases/architectures: Red Hat Linux 7.3 - i386 Red Hat Linux 9 - i386 3. Problem description: Tcpdump is a command-line tool for monitoring network traffic. Tcpdump v3.8.1 and earlier versions contained multiple flaws in the packet display functions for the ISAKMP protocol. Upon receiving specially crafted ISAKMP packets, tcpdump would try to read beyond the end of the packet capture buffer and subsequently crash. All users are advised to upgrade to these updated packages, which contain a backported fix and are not vulnerable to this issue. 4. Solution: Before applying this update, make sure all previously released errata relevant to your system have been applied. To update all RPMs for your particular architecture, run: rpm -Fvh [filenames] where [filenames] is a list of the RPMs you wish to upgrade. Only those RPMs which are currently installed will be updated. Those RPMs which are not installed but included in the list will not be updated. Note that you can also use wildcards (*.rpm) if your current directory *only* contains the desired RPMs. Please note that this update is also available via yum and apt. Many people find this an easier way to apply updates. To use yum issue: yum update or to use apt: apt-get update; apt-get upgrade This will start an interactive process that will result in the appropriate RPMs being upgraded on your system. This assumes that you have yum or apt-get configured for obtaining Fedora Legacy content. Please visit http://www.fedoralegacy.org/docs/ for directions on how to configure yum and apt-get. 5. Bug IDs fixed: http://bugzilla.fedora.us - 1468 - tcpdump ISAKMP Packet Decoding Vulnerability 6. RPMs required: Red Hat Linux 7.3: SRPM: http://download.fedoralegacy.org/redhat/7.3/updates/SRPMS/tcpdump-3.6.3-17.7.3.6.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/7.3/updates/i386/arpwatch-2.1a11-17.7.3.6.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/libpcap-0.6.2-17.7.3.6.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/tcpdump-3.6.3-17.7.3.6.legacy.i386.rpm Red Hat Linux 9: SRPM: http://download.fedoralegacy.org/redhat/9/updates/SRPMS/tcpdump-3.7.2-7.9.3.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/9/updates/i386/arpwatch-2.1a11-7.9.3.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/libpcap-0.7.2-7.9.3.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/tcpdump-3.7.2-7.9.3.legacy.i386.rpm 7. Verification: SHA1 sum Package Name --------------------------------------------------------------------------- 3c236622c2f0815b257eb6df89470875844ab051 7.3/updates/SRPMS/tcpdump-3.6.3-17.7.3.6.legacy.src.rpm 1d7866f944b95a9350098803c1be9a9439ef9de1 7.3/updates/i386/arpwatch-2.1a11-17.7.3.6.legacy.i386.rpm 827884c667461dcd1624b666d29d83e50e4611cc 7.3/updates/i386/libpcap-0.6.2-17.7.3.6.legacy.i386.rpm 2e77a8344ce68a80fe484fae4e9e371b92dc25c2 7.3/updates/i386/tcpdump-3.6.3-17.7.3.6.legacy.i386.rpm 2a63dfe8422c135d41ec0655d1957b2ac6e348a2 9/updates/SRPMS/tcpdump-3.7.2-7.9.3.legacy.src.rpm e2e2cd142b0a4a50ab3b66a665d52e35fbe103aa 9/updates/i386/arpwatch-2.1a11-7.9.3.legacy.i386.rpm 3e7aad82c73a3250828b05e1308eb63a43c0d35e 9/updates/i386/libpcap-0.7.2-7.9.3.legacy.i386.rpm 39b28a5fc7bda074426736cfdbc6a2186979daa2 9/updates/i386/tcpdump-3.7.2-7.9.3.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://marc.theaimsgroup.com/?l=bugtraq&m=108067265931525&w=2 9. Contact: The Fedora Legacy security contact is . More project details at http://www.fedoralegacy.org --------------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From dom at earth.li Wed Sep 29 16:13:58 2004 From: dom at earth.li (Dominic Hargreaves) Date: Wed, 29 Sep 2004 17:13:58 +0100 Subject: [FLSA-2004:1552] Updated cadaver packages that fix security vulnerabilities Message-ID: <20040929161357.GB11725@home.thedom.org> ----------------------------------------------------------------------- Fedora Legacy Update Advisory Synopsis: Updated cadaver resolves security vulnerabilities Advisory ID: FLSA:1552 Issue date: 2004-09-29 Product: Red Hat Linux Keywords: Security Cross references: https://bugzilla.fedora.us/show_bug.cgi?id=1552 CVE Names: CAN-2004-0179, CAN-2004-0398 ----------------------------------------------------------------------- ----------------------------------------------------------------------- 1. Topic: Updated cadaver packages that fix multiple security vulnerability are now available. 2. Relevant releases/architectures: Red Hat Linux 7.3 - i386 Red Hat Linux 9 - i386 3. Problem description: An updated cadaver package that fixes a vulnerability in neon exploitable by a malicious DAV server is now available. cadaver is a command-line WebDAV client that uses inbuilt code from neon, an HTTP and WebDAV client library. Versions of the neon client library up to and including 0.24.4 have been found to contain a number of format string bugs. An attacker could create a malicious WebDAV server in such a way as to allow arbitrary code execution on the client should a user connect to it using cadaver. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-0179 to this issue. This issue was addressed in a previous update for Red Hat Linux 9. Stefan Esser discovered a flaw in the neon library which allows a heap buffer overflow in a date parsing routine. An attacker could create a malicious WebDAV server in such a way as to allow arbitrary code execution on the client should a user connect to it using cadaver. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-0398 to this issue. Users of cadaver are advised to upgrade to this updated package, which contains patches correcting these issues. 4. Solution: Before applying this update, make sure all previously released errata relevant to your system have been applied. To update all RPMs for your particular architecture, run: rpm -Fvh [filenames] where [filenames] is a list of the RPMs you wish to upgrade. Only those RPMs which are currently installed will be updated. Those RPMs which are not installed but included in the list will not be updated. Note that you can also use wildcards (*.rpm) if your current directory *only* contains the desired RPMs. Please note that this update is also available via yum and apt. Many people find this an easier way to apply updates. To use yum issue: yum update or to use apt: apt-get update; apt-get upgrade This will start an interactive process that will result in the appropriate RPMs being upgraded on your system. This assumes that you have yum or apt-get configured for obtaining Fedora Legacy content. Please visit http://www.fedoralegacy.org/docs/ for directions on how to configure yum and apt-get. 5. Bug IDs fixed: http://bugzilla.fedora.us - 1552 - cadaver neon vulnerability (CAN-2004-0179) 6. RPMs required: Red Hat Linux 7.3: SRPM: http://download.fedoralegacy.org/redhat/7.3/updates/SRPMS/cadaver-0.22.1-1.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/7.3/updates/i386/cadaver-0.22.1-1.legacy.i386.rpm Red Hat Linux 9: SRPM: http://download.fedoralegacy.org/redhat/9/updates/SRPMS/cadaver-0.22.1-3.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/9/updates/i386/cadaver-0.22.1-3.legacy.i386.rpm 7. Verification: SHA1 sum Package Name --------------------------------------------------------------------------- 46931edc0f4e8ad25c994891938c103a45f28982 7.3/updates/SRPMS/cadaver-0.22.1-1.legacy.src.rpm 0c3742f3151d4dedc5e5320a3a4792f17e8bd2e4 7.3/updates/i386/cadaver-0.22.1-1.legacy.i386.rpm 6cc852676c85e9cc3dc8e472676185cdffabf09f 9/updates/SRPMS/cadaver-0.22.1-3.legacy.src.rpm 1a9d4e010885e902b2a6a994cfee5744b7f4afba 9/updates/i386/cadaver-0.22.1-3.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://security.e-matters.de/advisories/062004.html 9. Contact: The Fedora Legacy security contact is . More project details at http://www.fedoralegacy.org --------------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From b.pennacchi at istc.cnr.it Wed Sep 29 16:13:54 2004 From: b.pennacchi at istc.cnr.it (Barbara Pennacchi) Date: Wed, 29 Sep 2004 18:13:54 +0200 Subject: Fedora Legacy Test Update Notification: Kernel In-Reply-To: <20040929160018.1589073E1A@hormel.redhat.com> References: <20040929160018.1589073E1A@hormel.redhat.com> Message-ID: <20040929161354.GG10614@sibannac> On 29.09.04 18:00, fedora-legacy-list-request at redhat.com wrote: > --------------------------------------------------------------------- > Fedora Test Update Notification > FEDORALEGACY-2004-1804 > Bugzilla https://bugzilla.fedora.us/show_bug.cgi?id=1804 > 2004-09-29 > --------------------------------------------------------------------- > > Name : kernel > Version 7.3 : 2.4.20-37.7.legacy > Version 9 : 2.4.20-37.9.legacy Uh, Dominic? Does this version supersedes the 2.4.20-35? Or are BOTH to be tested before release? (was about to download the kernel to test it) -- +--------------------------------------------------------------------+ | WARNING WARNING WARNING *** EMAIL ADDRESS CHANGED! | | USE EMAIL ADDRESS PROVIDED BELOW | | IF YOU KEEP WRITING TO THE OLD ADDRESS IT IS NOT MY FAULT! | +--------------------------------------------------------------------+ | Barbara Pennacchi b.pennacchi at istc.cnr.it | | Consiglio Nazionale delle Ricerche | | Istituto di Scienze e Tecnologie della Cognizione | | V.le Marx 15, 00137 Roma, Italia | | http://www.istc.cnr.it/ | +--------------------------------------------------------------------+ From dom at earth.li Wed Sep 29 16:22:54 2004 From: dom at earth.li (Dominic Hargreaves) Date: Wed, 29 Sep 2004 17:22:54 +0100 Subject: Fedora Legacy Test Update Notification: Kernel In-Reply-To: <20040929161354.GG10614@sibannac> References: <20040929160018.1589073E1A@hormel.redhat.com> <20040929161354.GG10614@sibannac> Message-ID: <20040929162254.GC15895@tirian.magd.ox.ac.uk> On Wed, Sep 29, 2004 at 06:13:54PM +0200, Barbara Pennacchi wrote: > Uh, Dominic? Does this version supersedes the 2.4.20-35? Or are BOTH to be > tested before release? (was about to download the kernel to test it) It supercedes 2.4.20-35. I'll remove that from the download server for the next update. Dominic. From b.pennacchi at istc.cnr.it Wed Sep 29 16:27:00 2004 From: b.pennacchi at istc.cnr.it (Barbara Pennacchi) Date: Wed, 29 Sep 2004 18:27:00 +0200 Subject: Fedora Legacy Test Update Notification: Kernel In-Reply-To: <20040929162254.GC15895@tirian.magd.ox.ac.uk> References: <20040929160018.1589073E1A@hormel.redhat.com> <20040929161354.GG10614@sibannac> <20040929162254.GC15895@tirian.magd.ox.ac.uk> Message-ID: <20040929162700.GI10614@sibannac> On 29.09.04 18:22, Dominic Hargreaves wrote: > > Uh, Dominic? Does this version supersedes the 2.4.20-35? Or are BOTH > > to be tested before release? (was about to download the kernel to test > > it) > > It supercedes 2.4.20-35. I'll remove that from the download server for > the next update. Thanks, maybe I happened to hit the repo just when both were in updates- testing :-) Will try to make yum download the right kernel to test, now. -- +--------------------------------------------------------------------+ | WARNING WARNING WARNING *** EMAIL ADDRESS CHANGED! | | USE EMAIL ADDRESS PROVIDED BELOW | | IF YOU KEEP WRITING TO THE OLD ADDRESS IT IS NOT MY FAULT! | +--------------------------------------------------------------------+ | Barbara Pennacchi b.pennacchi at istc.cnr.it | | Consiglio Nazionale delle Ricerche | | Istituto di Scienze e Tecnologie della Cognizione | | V.le Marx 15, 00137 Roma, Italia | | http://www.istc.cnr.it/ | +--------------------------------------------------------------------+ From skvidal at phy.duke.edu Wed Sep 29 17:14:13 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 29 Sep 2004 13:14:13 -0400 Subject: questions about yum.conf (long) In-Reply-To: <20040929154140.GC10614@sibannac> References: <20040929154140.GC10614@sibannac> Message-ID: <1096478053.30263.44.camel@opus.phy.duke.edu> On Wed, 2004-09-29 at 11:41, Barbara Pennacchi wrote: > Hi, I have 3 questions about yum.conf (my version of yum is 2.0.7-3) > > 1) I've put 3 different servers in it, the nearest mirror first, then > fedoralegacy.org and fedora.us for last, but it looks like yum ignores the > order I put them in and tries to go to fedora.us first! (yum.conf > available upon request) You can set the failover order - read the manpage - look for roundrobin and priority. > 2) If I do a yum check-update, I see there are updates to, say, tcpdump > libpcap and arpwatch. But yum update alone ignores them. I have to specify > the name of the rpm I want to upgrade. Sometimes I have to try twice > before it gets the hint. (transcript available upon request as to not hog > the ML) If you can replicate this - file a bug at yum bugzilla about it. I've not heard of this problem on yum 2.0.X, so far. > P.S: I've set the debug level in yum.conf to 2. To what level should I put > it as to see in the log something more about yum's almost-idiotic > behaviour for questions 1 and 2? debug level 2 is fine for normal runs. if you want to send more information you can run: yum -d number_greater_than_2 yourcommand -sv From josh.kayse at gtri.gatech.edu Wed Sep 29 20:59:14 2004 From: josh.kayse at gtri.gatech.edu (Josh Kayse) Date: Wed, 29 Sep 2004 16:59:14 -0400 Subject: Self-Introduction: Joshua Kayse Message-ID: <1096491554.17418.134.camel@jak-579.stl.gtri.gatech.edu> 1. Joshua Allen Kayse 2. Atlanta, GA USA 3. 3rd year CompE major 4. GTRI / STL 5. Fedora Core 1 QA for packages 6. Realbot for CS C, Java, scheme, learning linux My job integrates fedora core 1 heavily and therefore we need to keep it supported. 7. pub 1024D/20E6B7B1 2004-09-29 Joshua Kayse (Josh) Key fingerprint = 949E EC62 2F35 6017 9931 606E C275 0509 20E6 B7B1 sub 1024g/E7354419 2004-09-29 -- Josh Kayse Signature Technology Lab From dom at earth.li Wed Sep 29 23:53:22 2004 From: dom at earth.li (Dominic Hargreaves) Date: Thu, 30 Sep 2004 00:53:22 +0100 Subject: Fedora Legacy Test Update Notification: XFree86 Message-ID: <20040929235322.GF15895@tirian.magd.ox.ac.uk> Please test these packages and report to bugzilla. Note these packages are for Redhat 7.3; the previous test update was for Redhat 9. --------------------------------------------------------------------- Fedora Test Update Notification FEDORALEGACY-2004-1289 Bugzilla https://bugzilla.fedora.us/show_bug.cgi?id=1289 2004-09-30 --------------------------------------------------------------------- Name : XFree86 Version : 4.2.1-16.73.27 Summary : The basic fonts, programs and docs for an X workstation. Description : XFree86 is an open source implementation of the X Window System. It provides the basic low level functionality which full fledged graphical user interfaces (GUIs) such as GNOME and KDE are designed upon. --------------------------------------------------------------------- Update Information: iDefense discovered two buffer overflows in the parsing of the 'font.alias' file. A local attacker could exploit this vulnerability by creating a carefully-crafted file and gaining root privileges. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the names CAN-2004-0083 and CAN-2004-0084 to these issues. Additionally David Dawes discovered additional flaws in reading font files. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-0106 to these issues. --------------------------------------------------------------------- Changelog: * Tue Sep 28 2004 Dominic Hargrewaves 4.2.1-27 - Fixed permissions of a few source files - Added gcc-c++ BuildRequires * Fri May 14 2004 John P. Dalbec 4.2.1-26 - Disabled parallel building (not fixable?). * Wed May 12 2004 John P. Dalbec 4.2.1-25 - Fixed parallel building (reversed order of two lines in Makefile patches). - Added conditional BuildRequires for Glide3-devel. - Commented out rpm -q test for Glide3-devel. * Tue Feb 24 2004 John P. Dalbec 4.2.1-24 - [SECURITY] XFree86-4.2.1-libXfont-security-CAN-2004-0083-CAN-2004-0084-CAN-2004-0106-v2-430-backport.patch added containing fixes for libXfont buffer overflow issues CAN-2004-0083, CAN-2004-0084, and CAN-2004-0106 (copied from RH 9 SRPM). - Added missing BuildRequires for libtool - Converted all BuildPrereq to BuildRequires --------------------------------------------------------------------- This update can be downloaded from: http://download.fedoralegacy.org/redhat/ b311b22fe4d6d4e08f99ea7e59d4be7a6158d66d 7.3/updates-testing/SRPMS/XFree86-4.2. 1-16.73.27.src.rpm 8a5738fc0d2aeff3b98e3cfdf28135eeee4385f0 7.3/updates-testing/i386/XFree86-100dp i-fonts-4.2.1-16.73.27.i386.rpm 77ae3b1c10ce7a001f5822c66f6b91f58c94a475 7.3/updates-testing/i386/XFree86-4.2.1 -16.73.27.i386.rpm 9c899aab10f09516a9003199620d0fc2e04dd014 7.3/updates-testing/i386/XFree86-75dpi -fonts-4.2.1-16.73.27.i386.rpm 7e365574c9d4c4e56ed042f7119423bc6114dbb5 7.3/updates-testing/i386/XFree86-base- fonts-4.2.1-16.73.27.i386.rpm 477b6fa1d9bec3a1bb9f285c8c57622d4d131656 7.3/updates-testing/i386/XFree86-cyril lic-fonts-4.2.1-16.73.27.i386.rpm 704f039490bb3a0e56400f7ec71a9cfb43de129b 7.3/updates-testing/i386/XFree86-devel -4.2.1-16.73.27.i386.rpm 56f083d57e4fd5048d5a0548193c03ecb39332f9 7.3/updates-testing/i386/XFree86-doc-4 .2.1-16.73.27.i386.rpm cef766b8f14f497279905516cc0743ca0b484a6a 7.3/updates-testing/i386/XFree86-font-utils-4.2.1-16.73.27.i386.rpm 9dbf4535e9499d5e3ca21ce44b14859d88a45ac7 7.3/updates-testing/i386/XFree86-ISO8859-15-100dpi-fonts-4.2.1-16.73.27.i386.rpm 50782370c7d3a524649085b039cb704e1361754b 7.3/updates-testing/i386/XFree86-ISO8859-15-75dpi-fonts-4.2.1-16.73.27.i386.rpm 28f087c281057110a3dd1ca84c564033b5510c67 7.3/updates-testing/i386/XFree86-ISO8859-2-100dpi-fonts-4.2.1-16.73.27.i386.rpm 074a8115455791cbfc09c02c4796533c2d00fa57 7.3/updates-testing/i386/XFree86-ISO8859-2-75dpi-fonts-4.2.1-16.73.27.i386.rpm 1f23b76f196979b8ae5d91cda87f1eb7905be0e7 7.3/updates-testing/i386/XFree86-ISO8859-9-100dpi-fonts-4.2.1-16.73.27.i386.rpm 65d0f074cade8ac011ec881e91862541f2b7de63 7.3/updates-testing/i386/XFree86-ISO8859-9-75dpi-fonts-4.2.1-16.73.27.i386.rpm fa8d73c984479350425bda006a168d19a4f724a5 7.3/updates-testing/i386/XFree86-libs-4.2.1-16.73.27.i386.rpm f4e2d367b3ac930e68d4c2dae3d4fa78e45eb7e9 7.3/updates-testing/i386/XFree86-tools-4.2.1-16.73.27.i386.rpm 8dd9a32c44beb8110897adeaeac66e10a02e5ec2 7.3/updates-testing/i386/XFree86-truetype-fonts-4.2.1-16.73.27.i386.rpm 0083535709b3e46c646551e48d3c6793a0797c6c 7.3/updates-testing/i386/XFree86-twm-4.2.1-16.73.27.i386.rpm 889acef55be6e8cc1fa67d1133b03e68d6e4a2b3 7.3/updates-testing/i386/XFree86-xdm-4.2.1-16.73.27.i386.rpm e0f95f9a79dcb83b73bfc284714f1ea9b8f8eeba 7.3/updates-testing/i386/XFree86-xf86cfg-4.2.1-16.73.27.i386.rpm d963b8d19b4cef53c70e60597a57ff2b215af244 7.3/updates-testing/i386/XFree86-xfs-4.2.1-16.73.27.i386.rpm 708d06c728c2df4eb526403eb132630b027da0f2 7.3/updates-testing/i386/XFree86-Xnest-4.2.1-16.73.27.i386.rpm 74ba7b4eaae9ca8d44c053afbc18fba9e163f59d 7.3/updates-testing/i386/XFree86-Xvfb-4.2.1-16.73.27.i386.rpm Please note that this update is also available via yum and apt through the updates-testing channel. Many people find this an easier way to apply updates. --------------------------------------------------------------------- From dom at earth.li Wed Sep 29 23:54:34 2004 From: dom at earth.li (Dominic Hargreaves) Date: Thu, 30 Sep 2004 00:54:34 +0100 Subject: Fedora Legacy Test Update Notification: XFree86 Message-ID: <20040929235432.GA13576@home.thedom.org> Signed this time... Please test these packages and report to bugzilla. Note these packages are for Redhat 7.3; the previous test update was for Redhat 9. --------------------------------------------------------------------- Fedora Test Update Notification FEDORALEGACY-2004-1289 Bugzilla https://bugzilla.fedora.us/show_bug.cgi?id=1289 2004-09-30 --------------------------------------------------------------------- Name : XFree86 Version : 4.2.1-16.73.27 Summary : The basic fonts, programs and docs for an X workstation. Description : XFree86 is an open source implementation of the X Window System. It provides the basic low level functionality which full fledged graphical user interfaces (GUIs) such as GNOME and KDE are designed upon. --------------------------------------------------------------------- Update Information: iDefense discovered two buffer overflows in the parsing of the 'font.alias' file. A local attacker could exploit this vulnerability by creating a carefully-crafted file and gaining root privileges. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the names CAN-2004-0083 and CAN-2004-0084 to these issues. Additionally David Dawes discovered additional flaws in reading font files. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-0106 to these issues. --------------------------------------------------------------------- Changelog: * Tue Sep 28 2004 Dominic Hargrewaves 4.2.1-27 - Fixed permissions of a few source files - Added gcc-c++ BuildRequires * Fri May 14 2004 John P. Dalbec 4.2.1-26 - Disabled parallel building (not fixable?). * Wed May 12 2004 John P. Dalbec 4.2.1-25 - Fixed parallel building (reversed order of two lines in Makefile patches). - Added conditional BuildRequires for Glide3-devel. - Commented out rpm -q test for Glide3-devel. * Tue Feb 24 2004 John P. Dalbec 4.2.1-24 - [SECURITY] XFree86-4.2.1-libXfont-security-CAN-2004-0083-CAN-2004-0084-CAN-2004-0106-v2-430-backport.patch added containing fixes for libXfont buffer overflow issues CAN-2004-0083, CAN-2004-0084, and CAN-2004-0106 (copied from RH 9 SRPM). - Added missing BuildRequires for libtool - Converted all BuildPrereq to BuildRequires --------------------------------------------------------------------- This update can be downloaded from: http://download.fedoralegacy.org/redhat/ b311b22fe4d6d4e08f99ea7e59d4be7a6158d66d 7.3/updates-testing/SRPMS/XFree86-4.2. 1-16.73.27.src.rpm 8a5738fc0d2aeff3b98e3cfdf28135eeee4385f0 7.3/updates-testing/i386/XFree86-100dp i-fonts-4.2.1-16.73.27.i386.rpm 77ae3b1c10ce7a001f5822c66f6b91f58c94a475 7.3/updates-testing/i386/XFree86-4.2.1 -16.73.27.i386.rpm 9c899aab10f09516a9003199620d0fc2e04dd014 7.3/updates-testing/i386/XFree86-75dpi -fonts-4.2.1-16.73.27.i386.rpm 7e365574c9d4c4e56ed042f7119423bc6114dbb5 7.3/updates-testing/i386/XFree86-base- fonts-4.2.1-16.73.27.i386.rpm 477b6fa1d9bec3a1bb9f285c8c57622d4d131656 7.3/updates-testing/i386/XFree86-cyril lic-fonts-4.2.1-16.73.27.i386.rpm 704f039490bb3a0e56400f7ec71a9cfb43de129b 7.3/updates-testing/i386/XFree86-devel -4.2.1-16.73.27.i386.rpm 56f083d57e4fd5048d5a0548193c03ecb39332f9 7.3/updates-testing/i386/XFree86-doc-4 .2.1-16.73.27.i386.rpm cef766b8f14f497279905516cc0743ca0b484a6a 7.3/updates-testing/i386/XFree86-font-utils-4.2.1-16.73.27.i386.rpm 9dbf4535e9499d5e3ca21ce44b14859d88a45ac7 7.3/updates-testing/i386/XFree86-ISO8859-15-100dpi-fonts-4.2.1-16.73.27.i386.rpm 50782370c7d3a524649085b039cb704e1361754b 7.3/updates-testing/i386/XFree86-ISO8859-15-75dpi-fonts-4.2.1-16.73.27.i386.rpm 28f087c281057110a3dd1ca84c564033b5510c67 7.3/updates-testing/i386/XFree86-ISO8859-2-100dpi-fonts-4.2.1-16.73.27.i386.rpm 074a8115455791cbfc09c02c4796533c2d00fa57 7.3/updates-testing/i386/XFree86-ISO8859-2-75dpi-fonts-4.2.1-16.73.27.i386.rpm 1f23b76f196979b8ae5d91cda87f1eb7905be0e7 7.3/updates-testing/i386/XFree86-ISO8859-9-100dpi-fonts-4.2.1-16.73.27.i386.rpm 65d0f074cade8ac011ec881e91862541f2b7de63 7.3/updates-testing/i386/XFree86-ISO8859-9-75dpi-fonts-4.2.1-16.73.27.i386.rpm fa8d73c984479350425bda006a168d19a4f724a5 7.3/updates-testing/i386/XFree86-libs-4.2.1-16.73.27.i386.rpm f4e2d367b3ac930e68d4c2dae3d4fa78e45eb7e9 7.3/updates-testing/i386/XFree86-tools-4.2.1-16.73.27.i386.rpm 8dd9a32c44beb8110897adeaeac66e10a02e5ec2 7.3/updates-testing/i386/XFree86-truetype-fonts-4.2.1-16.73.27.i386.rpm 0083535709b3e46c646551e48d3c6793a0797c6c 7.3/updates-testing/i386/XFree86-twm-4.2.1-16.73.27.i386.rpm 889acef55be6e8cc1fa67d1133b03e68d6e4a2b3 7.3/updates-testing/i386/XFree86-xdm-4.2.1-16.73.27.i386.rpm e0f95f9a79dcb83b73bfc284714f1ea9b8f8eeba 7.3/updates-testing/i386/XFree86-xf86cfg-4.2.1-16.73.27.i386.rpm d963b8d19b4cef53c70e60597a57ff2b215af244 7.3/updates-testing/i386/XFree86-xfs-4.2.1-16.73.27.i386.rpm 708d06c728c2df4eb526403eb132630b027da0f2 7.3/updates-testing/i386/XFree86-Xnest-4.2.1-16.73.27.i386.rpm 74ba7b4eaae9ca8d44c053afbc18fba9e163f59d 7.3/updates-testing/i386/XFree86-Xvfb-4.2.1-16.73.27.i386.rpm Please note that this update is also available via yum and apt through the updates-testing channel. Many people find this an easier way to apply updates. --------------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From dom at earth.li Wed Sep 29 23:58:38 2004 From: dom at earth.li (Dominic Hargreaves) Date: Thu, 30 Sep 2004 00:58:38 +0100 Subject: Round-up, 2004-09-30 Message-ID: <20040929235838.GA13603@home.thedom.org> $Id: issues.txt,v 1.67 2004/09/29 23:56:34 dom Exp $ See bottom for changes This list is also available at http://www-astro.physics.ox.ac.uk/~dom/legacy/issues.txt Packages that have been verified and should be fully released ------------------------------------------------------------- flim - https://bugzilla.fedora.us/show_bug.cgi?id=1581 rsync - https://bugzilla.fedora.us/show_bug.cgi?id=1569 (but superceded) xchat - https://bugzilla.fedora.us/show_bug.cgi?id=1549 squirrelmail - https://bugzilla.fedora.us/show_bug.cgi?id=1733 ethereal - https://bugzilla.fedora.us/show_bug.cgi?id=1840 rsync - https://bugzilla.fedora.us/show_bug.cgi?id=2003 Packages waiting to be built for updates-testing ------------------------------------------------ lha - https://bugzilla.fedora.us/show_bug.cgi?id=1833 mod_proxy - https://bugzilla.fedora.us/show_bug.cgi?id=1737 mod_ssl - https://bugzilla.fedora.us/show_bug.cgi?id=1888 gdk-pixbuf - https://bugzilla.fedora.us/show_bug.cgi?id=1371 (rh73,superceded) glibc - https://bugzilla.fedora.us/show_bug.cgi?id=1947 abiword - https://bugzilla.fedora.us/show_bug.cgi?id=1906 Packages in state RESOLVED (ie exist in updates-testing) that need active work. ------------------------------------------------------------------ gaim - https://bugzilla.fedora.us/show_bug.cgi?id=1237 Needs 1 VERIFY before release. XFree86 - https://bugzilla.fedora.us/show_bug.cgi?id=1289 Needs 2 VERIFY before release. mailman - https://bugzilla.fedora.us/show_bug.cgi?id=1269 There were some unconfirmed reports of breakage with the candidate. This needs more QA before release. mod_python - https://bugzilla.fedora.us/show_bug.cgi?id=1325 Needs 1 VERIFY before release. sysstat - https://bugzilla.fedora.us/show_bug.cgi?id=1372 Needs 1 VERIFY before release. kernel - https://bugzilla.fedora.us/show_bug.cgi?id=1484 Needs missing file rebuilt for verification - but preferentially put work into later kernel ticket mozilla - https://bugzilla.fedora.us/show_bug.cgi?id=1532 Needs 2 VERIFY but has been superceded lha - https://bugzilla.fedora.us/show_bug.cgi?id=1547 Needs 2 VERIFY but has been superceded squid - https://bugzilla.fedora.us/show_bug.cgi?id=1732 Needs 1 VERIFY before release (but about to be superceded?) cvs - https://bugzilla.fedora.us/show_bug.cgi?id=1735 Needs VERIFY before release especially for rh73 kernel - https://bugzilla.fedora.us/show_bug.cgi?id=1804 Needs 2 VERIFY XFree86 - https://bugzilla.fedora.us/show_bug.cgi?id=1831 Needs VERIFY for rh9 php - https://bugzilla.fedora.us/show_bug.cgi?id=1868 Needs 2 VERIFY Packages in state UNCONFIRMED, NEW, ASSIGNED or REOPENED: -------------------------------------------------------- * readline - https://bugzilla.fedora.us/show_bug.cgi?id=2017 Another not fixed before EOL (rh9). WONTFIX? netpbm - https://bugzilla.fedora.us/show_bug.cgi?id=1257 Needs PUBLISH, especially for rh9 kdelibs - https://bugzilla.fedora.us/show_bug.cgi?id=1373 Needs 2 PUBLISH (superceded) yum - https://bugzilla.fedora.us/show_bug.cgi?id=1604 Needs 2 PUBLISH mod_ssl - https://bugzilla.fedora.us/show_bug.cgi?id=1708 Needs PUBLISH for rh9 (but superceded) krb5 - https://bugzilla.fedora.us/show_bug.cgi?id=1726 Obsoleted libxml - https://bugzilla.fedora.us/show_bug.cgi?id=1324 Sort out confusion over status over version in updates-testing and add RESOLVED flag. mc - https://bugzilla.fedora.us/show_bug.cgi?id=1548 Need 1 PUBLISH (but superceded?) libpng - https://bugzilla.fedora.us/show_bug.cgi?id=1550 Superceded libpng - https://bugzilla.fedora.us/show_bug.cgi?id=1943 Need 1 PUBLISH for rh9 tripwire - https://bugzilla.fedora.us/show_bug.cgi?id=1719 Resolve problems with how to version and build fix apache - https://bugzilla.fedora.us/show_bug.cgi?id=1805 Is this redundant? mysql - https://bugzilla.fedora.us/show_bug.cgi?id=1832 Needs 1 PUBLISH but superceded? mozilla - https://bugzilla.fedora.us/show_bug.cgi?id=1834 Needs PUBLISH especially for rh73 and FC1 samba - https://bugzilla.fedora.us/show_bug.cgi?id=1924 Needs PUBLISH, especially for rh9 gnome vfs - https://bugzilla.fedora.us/show_bug.cgi?id=1944 Needs PUBLISH, especially for rh9 sox - https://bugzilla.fedora.us/show_bug.cgi?id=1945 Needs possible renaming of rh7.3 package qt - https://bugzilla.fedora.us/show_bug.cgi?id=2002 Needs 2 PUBLISH gdk-pixbuf - https://bugzilla.fedora.us/show_bug.cgi?id=2005 Needs 2 PUBLISH mysql - https://bugzilla.fedora.us/show_bug.cgi?id=2006 Needs 2 PUBLISH ruby - https://bugzilla.fedora.us/show_bug.cgi?id=2007 needs work kdelibs - https://bugzilla.fedora.us/show_bug.cgi?id=2008 Needs 2 PUBLISH mc - https://bugzilla.fedora.us/show_bug.cgi?id=2009 Needs 2 PUBLISH pam_wheel - https://bugzilla.fedora.us/show_bug.cgi?id=2010 Needs PUBLISH and full auditing? krb5 - https://bugzilla.fedora.us/show_bug.cgi?id=2040 Needs 1 PUBLISH for rh9 / investigate possible bug introduced imlib - https://bugzilla.fedora.us/show_bug.cgi?id=2051 Needs PUBLISH [rh73,rh9] ImageMagick - https://bugzilla.fedora.us/show_bug.cgi?id=2052 Needs 2 PUBLISH squid - https://bugzilla.fedora.us/show_bug.cgi?id=2053 Needs 2 PUBLISH for rh9 samba - https://bugzilla.fedora.us/show_bug.cgi?id=2057 Need maybe another PUBLISH for 7.3 otherwise building cdrecord - https://bugzilla.fedora.us/show_bug.cgi?id=2058 Needs 2 PUBLISH for rh9 apache - https://bugzilla.fedora.us/show_bug.cgi?id=2068 Needs PUBLISH cups - https://bugzilla.fedora.us/show_bug.cgi?id=2072 Needs 1 PUBLISH gtk2 - https://bugzilla.fedora.us/show_bug.cgi?id=2073 Needs 2 PUBLISH openoffice - https://bugzilla.fedora.us/show_bug.cgi?id=2074 Needs 2 PUBLISH for rh9 and fc1 libxpm - https://bugzilla.fedora.us/show_bug.cgi?id=2075 Needs packages/confirmation cupsomatic - https://bugzilla.fedora.us/show_bug.cgi?id=2076 Needs 1 PUBLISH redhat-config-nfs - https://bugzilla.fedora.us/show_bug.cgi?id=2086 Need 1 or 2 PUBLISH mozilla - https://bugzilla.fedora.us/show_bug.cgi?id=2089 Needs packages (waiting for RHEL?) General (non-package bugs) -------------------------- fc1 repo - https://bugzilla.fedora.us/show_bug.cgi?id=2087 Notes ----- Needs PUBLISH means that there are packages available for QA that need to be QAd at the source level. Needs VERIFY means that there are updates-testing packages that need testing. This is the easy bit, let's get this old ones out of the way ASAP. * means that there is a judgement call that can be made on the bug system immediately. Please follow up onlist with opinions. Changes ------- $Log: issues.txt,v $ Revision 1.67 2004/09/29 23:56:34 dom update XFree86 Revision 1.66 2004/09/29 22:55:31 dom update php. Revision 1.65 2004/09/29 22:16:23 dom more updates Revision 1.64 2004/09/29 22:09:23 dom stuff Revision 1.63 2004/09/29 16:27:13 dom remove cadaver, tcpdump (releases! finally!) Revision 1.62 2004/09/29 11:07:11 dom update kernel, XFree86 Revision 1.61 2004/09/29 00:02:20 dom update php, so x Revision 1.60 2004/09/28 21:51:56 dom update sysstat, apache, samba, cups Revision 1.59 2004/09/28 15:08:30 dom update gaim Revision 1.58 2004/09/26 23:21:08 dom update imlib -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From dom at earth.li Wed Sep 29 16:13:58 2004 From: dom at earth.li (Dominic Hargreaves) Date: Wed, 29 Sep 2004 17:13:58 +0100 Subject: [FLSA-2004:1552] Updated cadaver packages that fix security vulnerabilities Message-ID: <20040929161357.GB11725@home.thedom.org> ----------------------------------------------------------------------- Fedora Legacy Update Advisory Synopsis: Updated cadaver resolves security vulnerabilities Advisory ID: FLSA:1552 Issue date: 2004-09-29 Product: Red Hat Linux Keywords: Security Cross references: https://bugzilla.fedora.us/show_bug.cgi?id=1552 CVE Names: CAN-2004-0179, CAN-2004-0398 ----------------------------------------------------------------------- ----------------------------------------------------------------------- 1. Topic: Updated cadaver packages that fix multiple security vulnerability are now available. 2. Relevant releases/architectures: Red Hat Linux 7.3 - i386 Red Hat Linux 9 - i386 3. Problem description: An updated cadaver package that fixes a vulnerability in neon exploitable by a malicious DAV server is now available. cadaver is a command-line WebDAV client that uses inbuilt code from neon, an HTTP and WebDAV client library. Versions of the neon client library up to and including 0.24.4 have been found to contain a number of format string bugs. An attacker could create a malicious WebDAV server in such a way as to allow arbitrary code execution on the client should a user connect to it using cadaver. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-0179 to this issue. This issue was addressed in a previous update for Red Hat Linux 9. Stefan Esser discovered a flaw in the neon library which allows a heap buffer overflow in a date parsing routine. An attacker could create a malicious WebDAV server in such a way as to allow arbitrary code execution on the client should a user connect to it using cadaver. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-0398 to this issue. Users of cadaver are advised to upgrade to this updated package, which contains patches correcting these issues. 4. Solution: Before applying this update, make sure all previously released errata relevant to your system have been applied. To update all RPMs for your particular architecture, run: rpm -Fvh [filenames] where [filenames] is a list of the RPMs you wish to upgrade. Only those RPMs which are currently installed will be updated. Those RPMs which are not installed but included in the list will not be updated. Note that you can also use wildcards (*.rpm) if your current directory *only* contains the desired RPMs. Please note that this update is also available via yum and apt. Many people find this an easier way to apply updates. To use yum issue: yum update or to use apt: apt-get update; apt-get upgrade This will start an interactive process that will result in the appropriate RPMs being upgraded on your system. This assumes that you have yum or apt-get configured for obtaining Fedora Legacy content. Please visit http://www.fedoralegacy.org/docs/ for directions on how to configure yum and apt-get. 5. Bug IDs fixed: http://bugzilla.fedora.us - 1552 - cadaver neon vulnerability (CAN-2004-0179) 6. RPMs required: Red Hat Linux 7.3: SRPM: http://download.fedoralegacy.org/redhat/7.3/updates/SRPMS/cadaver-0.22.1-1.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/7.3/updates/i386/cadaver-0.22.1-1.legacy.i386.rpm Red Hat Linux 9: SRPM: http://download.fedoralegacy.org/redhat/9/updates/SRPMS/cadaver-0.22.1-3.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/9/updates/i386/cadaver-0.22.1-3.legacy.i386.rpm 7. Verification: SHA1 sum Package Name --------------------------------------------------------------------------- 46931edc0f4e8ad25c994891938c103a45f28982 7.3/updates/SRPMS/cadaver-0.22.1-1.legacy.src.rpm 0c3742f3151d4dedc5e5320a3a4792f17e8bd2e4 7.3/updates/i386/cadaver-0.22.1-1legacy.i386.rpm 6cc852676c85e9cc3dc8e472676185cdffabf09f 9/updates/SRPMS/cadaver-0.22.1-3.legacy.src.rpm 1a9d4e010885e902b2a6a994cfee5744b7f4afba 9/updates/i386/cadaver-0.22.1-3.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://security.e-matters.de/advisories/062004.html 9. Contact: The Fedora Legacy security contact is . More project details at http://www.fedoralegacy.org --------------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From marcdeslauriers at videotron.ca Thu Sep 30 10:22:28 2004 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Thu, 30 Sep 2004 06:22:28 -0400 Subject: [FLSA-2004:2003] Updated rsync package fixes security issues Message-ID: <1096539748.6762.3.camel@mdlinux> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - - ----------------------------------------------------------------------- Fedora Legacy Update Advisory Synopsis: Updated rsync package fixes security issues Advisory ID: FLSA:2003 Issue date: 2004-09-30 Product: Red Hat Linux Keywords: Bugfix Cross references: https://bugzilla.fedora.us/show_bug.cgi?id=2003 CVE Names: CAN-2004-0426 CAN-2004-0792 - - ----------------------------------------------------------------------- - - ----------------------------------------------------------------------- 1. Topic: An updated rsync package that fixes several security issues is now available. The rsync program synchronizes files over a network. 2. Relevent releases/architectures: Red Hat Linux 7.3 - i386 Red Hat Linux 9 - i386 3. Problem description: Rsync before 2.6.1 does not properly sanitize paths when running a read/write daemon without using chroot. This could allow a remote attacker to write files outside of the module's "path", depending on the privileges assigned to the rsync daemon. Users not running an rsync daemon, running a read-only daemon, or running a chrooted daemon are not affected by this issue. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-0426 to this issue. Versions of rsync up to and including version 2.6.2 contain a path sanitization issue. This issue could allow an attacker to read or write files outside of the rsync directory. This vulnerability is only exploitable when an rsync server is enabled and is not running within a chroot. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-0792 to this issue. Users of rsync are advised to upgrade to this updated package, which contains backported patches and is not affected by these issues. 4. Solution: Before applying this update, make sure all previously released errata relevant to your system have been applied. To update all RPMs for your particular architecture, run: rpm -Fvh [filenames] where [filenames] is a list of the RPMs you wish to upgrade. Only those RPMs which are currently installed will be updated. Those RPMs which are not installed but included in the list will not be updated. Note that you can also use wildcards (*.rpm) if your current directory *only* contains the desired RPMs. Please note that this update is also available via yum and apt. Many people find this an easier way to apply updates. To use yum issue: yum update or to use apt: apt-get update; apt-get upgrade This will start an interactive process that will result in the appropriate RPMs being upgraded on your system. This assumes that you have yum or apt-get configured for obtaining Fedora Legacy content. Please visit http://www fedoralegacy.org/docs for directions on how to configure yum and apt-get. 5. Bug IDs fixed: http://bugzilla.fedora.us - bug #1569 http://bugzilla.fedora.us - bug #2003 6. RPMs required: Red Hat Linux 7.3: SRPM: http://download.fedoralegacy.org/redhat/7.3/updates/SRPMS/rsync-2.5.7-2.legacy.7x.src.rpm i386: http://download.fedoralegacy.org/redhat/7.3/updates/i386/rsync-2.5.7-2.legacy.7x.i386.rpm Red Hat Linux 9: SRPM: http://download.fedoralegacy.org/redhat/9/updates/SRPMS/rsync-2.5.7-2.legacy.9.src.rpm i386: http://download.fedoralegacy.org/redhat/9/updates/i386/rsync-2.5.7-2.legacy.9.i386.rpm 7. Verification: SHA1 sum Package Name - - --------------------------------------------------------------------------- 1101ad1c735a11c9be6f4d45971374a6195431d9 7.3/updates/i386/rsync-2.5.7-2.legacy.7x.i386.rpm 4bb344d823f423cf5c1cc64d949dd1d9408960e7 7.3/updates/SRPMS/rsync-2.5.7-2.legacy.7x.src.rpm 49a3fa2fe967ed5c62994d5785463357aaf49de5 9/updates/i386/rsync-2.5.7-2.legacy.9.i386.rpm 84ec22198c189660f3cf2b967b710de9a04d6b22 9/updates/SRPMS/rsync-2.5.7-2.legacy.9.src.rpm These packages are GPG signed by Fedora Legacy for security. Our key is available from http://www.fedoralegacy org/about/security.php You can verify each package with the following command: rpm --checksig -v If you only wish to verify that each package has not been corrupted or tampered with, examine only the sha1sum with the following command: sha1sum 8. References: http://rsync.samba.org/#security_apr04 http://rsync.samba.org/#security_aug04 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0426 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0792 9. Contact: The Fedora Legacy security contact is . More project details at http://www.fedoralegacy.org - - --------------------------------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBW90yLMAs/0C4zNoRAigPAKCyd2qrr/E5euEo4cZ509eGSQ3U3ACfYvP1 1NWrfCntZHfnvKlJ4Uvm98U= =gYDA -----END PGP SIGNATURE----- From marcdeslauriers at videotron.ca Thu Sep 30 10:24:34 2004 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Thu, 30 Sep 2004 06:24:34 -0400 Subject: [FLSA-2004:1840] Updated Ethereal packages fix security issues Message-ID: <1096539874.6762.6.camel@mdlinux> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - - ----------------------------------------------------------------------- Fedora Legacy Update Advisory Synopsis: Updated Ethereal packages fix security issues Advisory ID: FLSA:1840 Issue date: 2004-09-30 Product: Red Hat Linux Keywords: Bugfix Cross references: https://bugzilla.fedora.us/show_bug.cgi?id=1840 CVE Names: CAN-2004-0176 CAN-2004-0365 CAN-2004-0367 CAN-2004-0504 CAN-2004-0505 CAN-2004-0506 CAN-2004-0507 CAN-2004-0633 CAN-2004-0634 CAN-2004-0635 - - ----------------------------------------------------------------------- - - ----------------------------------------------------------------------- 1. Topic: Updated Ethereal packages that fix various security vulnerabilities are now available. Ethereal is a program for monitoring network traffic. 2. Relevent releases/architectures: Red Hat Linux 7.3 - i386 Red Hat Linux 9 - i386 3. Problem description: Issues fixed with this Ethereal release include: Stefan Esser reported that Ethereal versions 0.10.1 and earlier contain stack overflows in the IGRP, PGM, Metflow, ISUP, TCAP, or IGAP dissectors. On a system where Ethereal is being run a remote attacker could send malicious packets that could cause Ethereal to crash or execute arbitrary code. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-0176 to this issue. Jonathan Heussser discovered that a carefully-crafted RADIUS packet could cause a crash. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-0365 to this issue. Ethereal 0.8.13 to 0.10.2 allows remote attackers to cause a denial of service (crash) via a zero-length Presentation protocol selector. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-0367 to this issue. The MMSE dissector in Ethereal releases 0.10.1 through 0.10.3 contained a buffer overflow flaw. On a system where Ethereal is running, a remote attacker could send malicious packets that could cause Ethereal to crash or execute arbitrary code. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-0507 to this issue. In addition, other flaws in Ethereal prior to 0.10.4 were found that could cause it to crash in response to carefully crafted SIP (CAN-2004-0504), AIM (CAN-2004-0505), or SPNEGO (CAN-2004-0506) packets. The SNMP dissector in Ethereal releases 0.8.15 through 0.10.4 contained a memory read flaw. On a system where Ethereal is running, a remote attacker could send malicious packets that could cause Ethereal to crash or possibly execute arbitrary code. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-0635 to this issue. The SMB dissector in Ethereal releases 0.9.15 through 0.10.4 contained a null pointer flaw. On a system where Ethereal is running, a remote attacker could send malicious packets that could cause Ethereal to crash. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-0634 to this issue. The iSNS dissector in Ethereal releases 0.10.3 through 0.10.4 contained an integer overflow flaw. On a system where Ethereal is running, a remote attacker could send malicious packets that could cause Ethereal to crash or possibly execute arbitrary code. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-0633 to this issue. Users of Ethereal should upgrade to these updated packages, which contain backported security patches that correct these issues. 4. Solution: Before applying this update, make sure all previously released errata relevant to your system have been applied. To update all RPMs for your particular architecture, run: rpm -Fvh [filenames] where [filenames] is a list of the RPMs you wish to upgrade. Only those RPMs which are currently installed will be updated. Those RPMs which are not installed but included in the list will not be updated. Note that you can also use wildcards (*.rpm) if your current directory *only* contains the desired RPMs. Please note that this update is also available via yum and apt. Many people find this an easier way to apply updates. To use yum issue: yum update or to use apt: apt-get update; apt-get upgrade This will start an interactive process that will result in the appropriate RPMs being upgraded on your system. This assumes that you have yum or apt-get configured for obtaining Fedora Legacy content. Please visit http://www fedoralegacy.org/docs for directions on how to configure yum and apt-get. 5. Bug IDs fixed: http://bugzilla.fedora.us - bug #1419 http://bugzilla.fedora.us - bug #1840 6. RPMs required: Red Hat Linux 7.3: SRPM: http://download.fedoralegacy.org/redhat/7.3/updates/SRPMS/ethereal-0.10.3-0.73.3.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/7.3/updates/i386/ethereal-0.10.3-0.73.3.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/ethereal-gnome-0.10.3-0.73.3.legacy.i386.rpm Red Hat Linux 9: SRPM: http://download.fedoralegacy.org/redhat/9/updates/SRPMS/ethereal-0.10.3-0.90.4.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/9/updates/i386/ethereal-0.10.3-0.90.4.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/ethereal-gnome-0.10.3-0.90.4.legacy.i386.rpm 7. Verification: SHA1 sum Package Name - - --------------------------------------------------------------------------- 9dea4bd2d8a8efce8722e7891a8b211ece731645 7.3/updates/i386/ethereal-0.10.3-0.73.3.legacy.i386.rpm f3defe29af6aceec7df646a0a49d8654823796e1 7.3/updates/i386/ethereal-gnome-0.10.3-0.73.3.legacy.i386.rpm 33c5ea5e2cabcd186aace74b9679a07c950d0d89 7.3/updates/SRPMS/ethereal-0.10.3-0.73.3.legacy.src.rpm 5c8e340c29644e861ebe064158b04420ca447066 9/updates/i386/ethereal-0.10.3-0.90.4.legacy.i386.rpm beb7b34e7a09b29c32976f7af123c7712f469bc6 9/updates/i386/ethereal-gnome-0.10.3-0.90.4.legacy.i386.rpm a32b6b54c36c2fe6a29e47080cadbb6ae87c8d6a 9/updates/SRPMS/ethereal-0.10.3-0.90.4.legacy.src.rpm These packages are GPG signed by Fedora Legacy for security. Our key is available from http://www.fedoralegacy org/about/security.php You can verify each package with the following command: rpm --checksig -v If you only wish to verify that each package has not been corrupted or tampered with, examine only the sha1sum with the following command: sha1sum 8. References: http://www.ethereal.com/appnotes/enpa-sa-00013.html http://www.ethereal.com/appnotes/enpa-sa-00014.html http://www.ethereal.com/appnotes/enpa-sa-00015.html http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0176 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0365 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0367 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0504 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0505 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0506 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0507 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0633 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0634 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0635 9. Contact: The Fedora Legacy security contact is . More project details at http://www.fedoralegacy.org - - --------------------------------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBW96ILMAs/0C4zNoRAt2IAJ92d61uwD3kP8uxzOMeL4LhhNoFWACcD5zx XVIAJKRFtSw27sw4giVzPc0= =SUxl -----END PGP SIGNATURE----- From marcdeslauriers at videotron.ca Thu Sep 30 10:26:01 2004 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Thu, 30 Sep 2004 06:26:01 -0400 Subject: Fedora Legacy Test Update Notification: lha Message-ID: <1096539961.6762.9.camel@mdlinux> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - --------------------------------------------------------------------- Fedora Legacy Test Update Notification FEDORALEGACY-2004-1833 Bugzilla https://bugzilla.fedora.us/show_bug.cgi?id=1833 2004-09-30 - --------------------------------------------------------------------- Name : lha Versions : 7.3: 1.14i-4.7.3.3.legacy, 9: 1.14i-9.3.legacy Summary : An archiving and compression utility for LHarc format archives. Description : LHA is an archiving and compression utility for LHarc format archives. LHA is mostly used in the DOS world, but can be used under Linux to extract DOS files from LHA archives. Install the lha package if you need to extract DOS files from LHA archives. - --------------------------------------------------------------------- Update Information: Ulf Harnhammar discovered two stack buffer overflows and two directory traversal flaws in LHA. An attacker could exploit the buffer overflows by creating a carefully crafted LHA archive in such a way that arbitrary code would be executed when the archive is tested or extracted by a victim. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-0234 to this issue. An attacker could exploit the directory traversal issues to create files as the victim outside of the expected directory. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-0235 to this issue. Lukasz Wojtow discovered a stack-based buffer overflow in all versions of lha up to and including version 1.14. A carefully created archive could allow an attacker to execute arbitrary code when a victim extracts or tests the archive. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-0769 to this issue. Buffer overflows were discovered in the command line processing of all versions of lha up to and including version 1.14. If a malicious user could trick a victim into passing a specially crafted command line to the lha command, it is possible that arbitrary code could be executed. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the names CAN-2004-0771 and CAN-2004-0694 to these issues. Thomas Biege discovered a shell meta character command execution vulnerability in all versions of lha up to and including 1.14. An attacker could create a directory with shell meta characters in its name which could lead to arbitrary command execution. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-0745 to this issue. - --------------------------------------------------------------------- 7.3 changelog: * Wed Sep 08 2004 Marc Deslauriers 1.14i-4.7.3.3.legacy - - Rebuilt as Fedora Legacy security update * Tue Aug 03 2004 Than Ngo 1.14i-10.4 - - another LHA buffer overflow * Fri Jun 25 2004 Than Ngo 1.14i-10.3 - - fix LHA buffer overflow 9 changelog: * Wed Sep 08 2004 Marc Deslauriers 1.14i-9.3.legacy - - Rebuilt as Fedora Legacy security update * Tue Aug 03 2004 Than Ngo 1.14i-10.4 - - another LHA buffer overflow * Fri Jun 25 2004 Than Ngo 1.14i-10.3 - - fix LHA buffer overflow - --------------------------------------------------------------------- This update can be downloaded from: http://download.fedoralegacy.org/redhat/ (sha1sums) 421a0998d84a2b75ebaa0bb334273ce1dad2be88 7.3/updates-testing/i386/lha-1.14i-4.7.3.3.legacy.i386.rpm aa6033fd436ea908b38b2035f096223f92ed780d 7.3/updates-testing/SRPMS/lha-1.14i-4.7.3.3.legacy.src.rpm 344f153d52712fbcba78e79b28fe46012d826a74 9/updates-testing/i386/lha-1.14i-9.3.legacy.i386.rpm ba93abb5201ef503bb866403dae811eb5caa3a86 9/updates-testing/SRPMS/lha-1.14i-9.3.legacy.src.rpm - --------------------------------------------------------------------- Please test and comment in bugzilla. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBW98ZLMAs/0C4zNoRApynAKCUz+Rw0vg3eBsNzXNMoVaH509TXgCfdrNN W/zhlFT7dbclDUwdfgsBKic= =Lgps -----END PGP SIGNATURE----- From marcdeslauriers at videotron.ca Thu Sep 30 10:27:05 2004 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Thu, 30 Sep 2004 06:27:05 -0400 Subject: Fedora Legacy Test Update Notification: mod_ssl Message-ID: <1096540025.6762.11.camel@mdlinux> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - --------------------------------------------------------------------- Fedora Legacy Test Update Notification FEDORALEGACY-2004-1888 Bugzilla https://bugzilla.fedora.us/show_bug.cgi?id=1888 2004-09-30 - --------------------------------------------------------------------- Name : mod_ssl Versions : 7.3: 2.8.12-6.legacy Summary : Cryptography support for the Apache Web server. Description : The mod_ssl module provides strong cryptography for the Apache Web server via the Secure Sockets Layer (SSL) and Transport Layer Security (TLS) protocols. - --------------------------------------------------------------------- Update Information: A stack buffer overflow was discovered in mod_ssl which can be triggered if using the FakeBasicAuth option. If mod_ssl is sent a client certificate with a subject DN field longer than 6000 characters, a stack overflow can occur if FakeBasicAuth has been enabled. In order to exploit this issue the carefully crafted malicious certificate would have to be signed by a Certificate Authority which mod_ssl is configured to trust. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-0488 to this issue. A format string issue was discovered in mod_ssl for Apache 1.3 which can be triggered if mod_ssl is configured to allow a client to proxy to remote SSL sites. In order to exploit this issue, a user who is authorized to use Apache as a proxy would have to attempt to connect to a carefully crafted hostname via SSL. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-0700 to this issue. - --------------------------------------------------------------------- 7.3 changelog: * Wed Sep 29 2004 Marc Deslauriers 2.8.12-6.legacy - - Added apache and openssl-devel BuildPrereq * Thu Jul 22 2004 Dominic Hargreaves 2.8.12-5.legacy - - Fix format string vulnerability in the ssl_log function in ssl_engine_log.c [CAN-2004-0700] - - Fix shmcb corruption for small cache sizes * Wed Jun 02 2004 Michal Jaegermann 2.8.12-4.legacy - - security fix for CAN-2004-0488; rediffed from a patch for 2.8.12-8.1.91mdk by Vincent Danen - --------------------------------------------------------------------- This update can be downloaded from: http://download.fedoralegacy.org/redhat/ (sha1sums) 211714e3a8faab1152e76471f1085f3d8ef30400 7.3/updates-testing/i386/mod_ssl-2.8.12-6.legacy.i386.rpm 027bf3500924d4bb58bd8bb0ed452420a0e134bc 7.3/updates-testing/SRPMS/mod_ssl-2.8.12-6.legacy.src.rpm - --------------------------------------------------------------------- Please test and comment in bugzilla. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBW99pLMAs/0C4zNoRAksfAJ4zMWeRLPTHmELaIwiAfrHMTHKt5gCfZZ2W uMv5AAvE1fGKGs0TM3u8kBY= =0lKU -----END PGP SIGNATURE----- From marcdeslauriers at videotron.ca Thu Sep 30 10:27:58 2004 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Thu, 30 Sep 2004 06:27:58 -0400 Subject: Fedora Legacy Test Update Notification: apache Message-ID: <1096540078.6762.13.camel@mdlinux> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - --------------------------------------------------------------------- Fedora Legacy Test Update Notification FEDORALEGACY-2004-1737 Bugzilla https://bugzilla.fedora.us/show_bug.cgi?id=1737 2004-09-30 - --------------------------------------------------------------------- Name : apache Versions : 7.3: 1.3.27-5.legacy Summary : The most widely used Web server on the Internet. Description : Apache is a powerful, full-featured, efficient, and freely-available Web server. Apache is also the most popular Web server on the Internet. - --------------------------------------------------------------------- Update Information: A buffer overflow was found in the Apache proxy module, mod_proxy, which can be triggered by receiving an invalid Content-Length header. In order to exploit this issue, an attacker would need an Apache installation that was configured as a proxy to connect to a malicious site. This would cause the Apache child processing the request to crash. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-0492 to this issue. - --------------------------------------------------------------------- 7.3 changelog: * Fri Jun 11 2004 Dominic Hargreaves 1.3.27-5.legacy - - add security fix for CVE CAN-2004-0492 - --------------------------------------------------------------------- This update can be downloaded from: http://download.fedoralegacy.org/redhat/ (sha1sums) 2e1f8e6bafbbbe02ac26ccc98b73631e62c889ce 7.3/updates-testing/i386/apache-1.3.27-5.legacy.i386.rpm 27a716974163c739784e09992f1d84a1996041d9 7.3/updates-testing/i386/apache-devel-1.3.27-5.legacy.i386.rpm ab688996e12f0364a50b58c2b120d933b403ce6b 7.3/updates-testing/i386/apache-manual-1.3.27-5.legacy.i386.rpm e2fadeb9a430a5dbda28076cd850180fbb95c2b8 7.3/updates-testing/SRPMS/apache-1.3.27-5.legacy.src.rpm - --------------------------------------------------------------------- Please test and comment in bugzilla. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBW9+RLMAs/0C4zNoRApSxAKCBwqQrLv3Kv5ni2Q2skeZl406LLQCeNN+d BMxHh+A/TbDH8mw4nD25CuA= =NdQK -----END PGP SIGNATURE----- From S.J.Thompson at cs.bham.ac.uk Thu Sep 30 10:53:43 2004 From: S.J.Thompson at cs.bham.ac.uk (Simon Thompson) Date: Thu, 30 Sep 2004 11:53:43 +0100 Subject: Self Introduction: Simon Thompson Message-ID: <415BE5B7.5070805@cs.bham.ac.uk> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 1 Full legal name ~ Simon James Thompson 2 Location (Country, City, etc) ~ Birmingham, UK 3 Profession or Student status ~ Computer Systems Officer 4 Company or School ~ School of Computer Science, The University of Birmingham 5 Your goals in the Fedora Legacy Project ~ QA for packages for RedHat 9 (used in our teaching labs). 6 Historical qualifications ~ C, Perl ~ Spent lots of time repacking software for use on our machines ~ Solaris & Linux systems administrator ~ Have worked as part of a CSIRT (incident response team) 7 PGP key gpg --fingerprint 32D9D128 pub 1024D/32D9D128 2004-09-17 Simon Thompson (work) ~ Key fingerprint = BA42 713A D883 8328 32E7 E273 E8FA 717C 32D9 D128 sub 1024g/B7082587 2004-09-17 [expires: 2009-09-16] - -- Simon Thompson Computer Officer School of Computer Science, The University of Birmingham -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBW+W36PpxfDLZ0SgRAkxwAJ9e/UyAZXL24gDNoPnG9Ra1Man+QwCfZY/V CAvSLt7jc8+E+z1/5czTs/w= =Z3fS -----END PGP SIGNATURE----- From dom at earth.li Wed Sep 29 16:12:29 2004 From: dom at earth.li (Dominic Hargreaves) Date: Wed, 29 Sep 2004 17:12:29 +0100 Subject: [FLSA-2004:1468] Updated tcpdump packages that fix multiple security vulnerabilities Message-ID: <20040929161226.GA11725@home.thedom.org> ----------------------------------------------------------------------- Fedora Legacy Update Advisory Synopsis: Updated tcpdump resolves security vulnerabilities Advisory ID: FLSA:1468 Issue date: 2004-09-29 Product: Red Hat Linux Keywords: Security Cross references: https://bugzilla.fedora.us/show_bug.cgi?id=1468 CVE Names: CAN-2004-0183, CAN-2004-0184 ----------------------------------------------------------------------- ----------------------------------------------------------------------- 1. Topic: Updated tcpdump packages that fix multiple security vulnerabilities are now available. 2. Relevant releases/architectures: Red Hat Linux 7.3 - i386 Red Hat Linux 9 - i386 3. Problem description: Tcpdump is a command-line tool for monitoring network traffic. Tcpdump v3.8.1 and earlier versions contained multiple flaws in the packet display functions for the ISAKMP protocol. Upon receiving specially crafted ISAKMP packets, tcpdump would try to read beyond the end of the packet capture buffer and subsequently crash. All users are advised to upgrade to these updated packages, which contain a backported fix and are not vulnerable to this issue. 4. Solution: Before applying this update, make sure all previously released errata relevant to your system have been applied. To update all RPMs for your particular architecture, run: rpm -Fvh [filenames] where [filenames] is a list of the RPMs you wish to upgrade. Only those RPMs which are currently installed will be updated. Those RPMs which are not installed but included in the list will not be updated. Note that you can also use wildcards (*.rpm) if your current directory *only* contains the desired RPMs. Please note that this update is also available via yum and apt. Many people find this an easier way to apply updates. To use yum issue: yum update or to use apt: apt-get update; apt-get upgrade This will start an interactive process that will result in the appropriate RPMs being upgraded on your system. This assumes that you have yum or apt-get configured for obtaining Fedora Legacy content. Please visit http://www.fedoralegacy.org/docs/ for directions on how to configure yum and apt-get. 5. Bug IDs fixed: http://bugzilla.fedora.us - 1468 - tcpdump ISAKMP Packet Decoding Vulnerability 6. RPMs required: Red Hat Linux 7.3: SRPM: http://download.fedoralegacy.org/redhat/7.3/updates/SRPMS/tcpdump-3.6.3-17.7.3.6.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/7.3/updates/i386/arpwatch-2.1a11-177.3.6.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/libpcap-0.6.2-17.73.6.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/tcpdump-3.6.3-17.73.6.legacy.i386.rpm Red Hat Linux 9: SRPM: http://download.fedoralegacy.org/redhat/9/updates/SRPMS/tcpdump-3.7.2-7.9.3legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/9/updates/i386/arpwatch-2.1a11-7.9.3.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/libpcap-0.7.2-7.9.3.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/tcpdump-3.7.2-7.9.3.legacy.i386.rpm 7. Verification: SHA1 sum Package Name --------------------------------------------------------------------------- 3c236622c2f0815b257eb6df89470875844ab051 7.3/updates/SRPMS/tcpdump-3.6.3-17.7.3.6.legacy.src.rpm 1d7866f944b95a9350098803c1be9a9439ef9de1 7.3/updates/i386/arpwatch-2.1a11-17.7.3.6.legacy.i386.rpm 827884c667461dcd1624b666d29d83e50e4611cc 7.3/updates/i386/libpcap-0.6.2-17.7.3.6.legacy.i386.rpm 2e77a8344ce68a80fe484fae4e9e371b92dc25c2 7.3/updates/i386/tcpdump-3.6.3-17.7.3.6.legacy.i386.rpm 2a63dfe8422c135d41ec0655d1957b2ac6e348a2 9/updates/SRPMS/tcpdump-3.7.2-7.9.3.legacy.src.rpm e2e2cd142b0a4a50ab3b66a665d52e35fbe103aa 9/updates/i386/arpwatch-2.1a11-7.9.3.legacy.i386.rpm 3e7aad82c73a3250828b05e1308eb63a43c0d35e 9/updates/i386/libpcap-0.7.2-7.9.3.legacy.i386.rpm 39b28a5fc7bda074426736cfdbc6a2186979daa2 9/updates/i386/tcpdump-3.7.2-7.9.3.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://marc.theaimsgroup.com/?l=bugtraq&m=108067265931525&w=2 9. Contact: The Fedora Legacy security contact is . More project details at http://www.fedoralegacy.org --------------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From moixa at gmx.ch Thu Sep 30 11:06:52 2004 From: moixa at gmx.ch (Tobias Sager) Date: Thu, 30 Sep 2004 13:06:52 +0200 Subject: Fedora Legacy Test Update Notification: apache In-Reply-To: <1096540078.6762.13.camel@mdlinux> References: <1096540078.6762.13.camel@mdlinux> Message-ID: <415BE8CC.1030707@gmx.ch> Hi Marc, On 30.09.2004 12:27 Marc Deslauriers wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 [..] I always get a "BAD signature" from you (I am using Thunderbird). Can anyone confirm this as well? Cheers, Tobias -- GPG-Key: 0xEF37FF28 (1024/4096 - DSA/ELG-E) Fingerprint: 3C4B 155F 2621 CEAF D3A6 0CCB 937C 9597 EF37 FF28 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 187 bytes Desc: OpenPGP digital signature URL: From simon at nzservers.com Thu Sep 30 11:49:31 2004 From: simon at nzservers.com (Simon Weller) Date: Thu, 30 Sep 2004 06:49:31 -0500 Subject: Fedora Legacy Test Update Notification: apache In-Reply-To: <415BE8CC.1030707@gmx.ch> References: <1096540078.6762.13.camel@mdlinux> <415BE8CC.1030707@gmx.ch> Message-ID: <200409300649.31155.simon@nzservers.com> I'm also getting a bad sig from Marc in Kmail (kde 3.3). - Si On Thursday 30 September 2004 06:06 am, Tobias Sager wrote: > Hi Marc, > > On 30.09.2004 12:27 Marc Deslauriers wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > [..] > > I always get a "BAD signature" from you (I am using Thunderbird). > Can anyone confirm this as well? > > Cheers, > Tobias -- Simon Weller LPIC-2 Systems Engineer NZServers LTD http://www.nzservers.com/ U.S. Branch <- To mess up a Linux box, you need to work at it; to mess up your Windows box, you just need to work on it. - Scott Granneman, Security Focus -> From jpdalbec at ysu.edu Thu Sep 30 12:24:46 2004 From: jpdalbec at ysu.edu (John Dalbec) Date: Thu, 30 Sep 2004 08:24:46 -0400 Subject: Fedora Legacy Test Update Notification: XFree86 In-Reply-To: <20040930003523.F185C73196@hormel.redhat.com> References: <20040930003523.F185C73196@hormel.redhat.com> Message-ID: <415BFB0E.6050204@ysu.edu> Dominic Hargreaves wrote: > Changelog: > > * Tue Sep 28 2004 Dominic Hargrewaves 4.2.1-27 > > - Fixed permissions of a few source files > - Added gcc-c++ BuildRequires The fedora.us Wiki says: > Exceptions > > There is no need to include the following packages or their dependencies as BuildRequires because they would occur too often. These packages are considered the minimum build environment and are installed as requirements of the rpm-build package or fedora-rpmdevtools package. > > rpm-build > redhat-rpm-config > gcc > gcc-c++ > make > sed > tar > cpio > patch > diffutils > gzip > bzip2 > unzip > perl Are we not following this policy? If not, a page should be added to our Wiki to describe the policy we are following. John From jpdalbec at ysu.edu Thu Sep 30 12:26:45 2004 From: jpdalbec at ysu.edu (John Dalbec) Date: Thu, 30 Sep 2004 08:26:45 -0400 Subject: http://www.fedoralegacy.org/wiki/index.php/QaTesting Message-ID: <415BFB85.60101@ysu.edu> > 3. Check for missing BuildRequires. For more information, see this posting. Should "this posting" be a link? John From cra at WPI.EDU Thu Sep 30 14:07:34 2004 From: cra at WPI.EDU (Charles R. Anderson) Date: Thu, 30 Sep 2004 10:07:34 -0400 Subject: Fedora Legacy Test Update Notification: apache In-Reply-To: <200409300649.31155.simon@nzservers.com> References: <1096540078.6762.13.camel@mdlinux> <415BE8CC.1030707@gmx.ch> <200409300649.31155.simon@nzservers.com> Message-ID: <20040930140734.GB17571@angus.ind.WPI.EDU> On Thu, Sep 30, 2004 at 06:49:31AM -0500, Simon Weller wrote: > On Thursday 30 September 2004 06:06 am, Tobias Sager wrote: > > I always get a "BAD signature" from you (I am using Thunderbird). > > Can anyone confirm this as well? > I'm also getting a bad sig from Marc in Kmail (kde 3.3). Me too. Mutt/gnupg. Is it caused by the bad line-wrapping in the message? From cra at WPI.EDU Thu Sep 30 14:11:01 2004 From: cra at WPI.EDU (Charles R. Anderson) Date: Thu, 30 Sep 2004 10:11:01 -0400 Subject: Fedora Legacy Test Update Notification: apache In-Reply-To: <20040930140734.GB17571@angus.ind.WPI.EDU> References: <1096540078.6762.13.camel@mdlinux> <415BE8CC.1030707@gmx.ch> <200409300649.31155.simon@nzservers.com> <20040930140734.GB17571@angus.ind.WPI.EDU> Message-ID: <20040930141101.GC17571@angus.ind.WPI.EDU> On Thu, Sep 30, 2004 at 10:07:34AM -0400, Charles R. Anderson wrote: > On Thu, Sep 30, 2004 at 06:49:31AM -0500, Simon Weller wrote: > > On Thursday 30 September 2004 06:06 am, Tobias Sager wrote: > > > I always get a "BAD signature" from you (I am using Thunderbird). > > > Can anyone confirm this as well? > > I'm also getting a bad sig from Marc in Kmail (kde 3.3). > > Me too. Mutt/gnupg. > > Is it caused by the bad line-wrapping in the message? Verified. These two lines, when unwrapped, allows the signature to be correctly verified: --- msg.orig Thu Sep 30 10:09:33 2004 +++ msg.fixed Thu Sep 30 10:08:24 2004 @@ -22,11 +22,9 @@ A buffer overflow was found in the Apache proxy module, mod_proxy, which can be triggered by receiving an invalid Content-Length header. In order to exploit this issue, an attacker would need an Apache installation -that was configured as a proxy to connect to a malicious site. This -would +that was configured as a proxy to connect to a malicious site. This would cause the Apache child processing the request to crash. The Common -Vulnerabilities and Exposures project (cve.mitre.org) has assigned the -name +Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-0492 to this issue. From bdm at fenrir.org.uk Thu Sep 30 14:17:37 2004 From: bdm at fenrir.org.uk (Brian Morrison) Date: Thu, 30 Sep 2004 15:17:37 +0100 Subject: Fedora Legacy Test Update Notification: apache In-Reply-To: <415BE8CC.1030707@gmx.ch> References: <1096540078.6762.13.camel@mdlinux> <415BE8CC.1030707@gmx.ch> Message-ID: <20040930151737.35f9858c@ickx.fenrir.org.uk> On Thu, 30 Sep 2004 13:06:52 +0200 in 415BE8CC.1030707 at gmx.ch Tobias Sager wrote: > Hi Marc, > > On 30.09.2004 12:27 Marc Deslauriers wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > [..] > > I always get a "BAD signature" from you (I am using Thunderbird). > Can anyone confirm this as well? Yes, it looks like something is changing the lines that start with dashes in a way different from the way that PGP inline signatures are meant to be changed. I've seen this happen before with a mail client that claims to use "format flowed". -- Brian Morrison bdm at fenrir dot org dot uk GnuPG key ID DE32E5C5 - http://wwwkeys.uk.pgp.net/pgpnet/wwwkeys.html From Axel.Thimm at ATrpms.net Thu Sep 30 14:38:21 2004 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 30 Sep 2004 16:38:21 +0200 Subject: {atrpms,medley}-package-config updated for FedoraLegacy Message-ID: <20040930143821.GA8017@neu.nirvana> The two package sets configurations, the minimal ATrpms and the multi-repo medley, have been updated to include o FedoraLegacy repos for FC1, and o (commented) FedoraLegacy repos for FC2 Thanks! -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dom at earth.li Wed Sep 29 16:13:58 2004 From: dom at earth.li (Dominic Hargreaves) Date: Wed, 29 Sep 2004 17:13:58 +0100 Subject: [Full-Disclosure] [FLSA-2004:1552] Updated cadaver packages that fix security vulnerabilities Message-ID: <20040929161357.GB11725@home.thedom.org> ----------------------------------------------------------------------- Fedora Legacy Update Advisory Synopsis: Updated cadaver resolves security vulnerabilities Advisory ID: FLSA:1552 Issue date: 2004-09-29 Product: Red Hat Linux Keywords: Security Cross references: https://bugzilla.fedora.us/show_bug.cgi?id=1552 CVE Names: CAN-2004-0179, CAN-2004-0398 ----------------------------------------------------------------------- ----------------------------------------------------------------------- 1. Topic: Updated cadaver packages that fix multiple security vulnerability are now available. 2. Relevant releases/architectures: Red Hat Linux 7.3 - i386 Red Hat Linux 9 - i386 3. Problem description: An updated cadaver package that fixes a vulnerability in neon exploitable by a malicious DAV server is now available. cadaver is a command-line WebDAV client that uses inbuilt code from neon, an HTTP and WebDAV client library. Versions of the neon client library up to and including 0.24.4 have been found to contain a number of format string bugs. An attacker could create a malicious WebDAV server in such a way as to allow arbitrary code execution on the client should a user connect to it using cadaver. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-0179 to this issue. This issue was addressed in a previous update for Red Hat Linux 9. Stefan Esser discovered a flaw in the neon library which allows a heap buffer overflow in a date parsing routine. An attacker could create a malicious WebDAV server in such a way as to allow arbitrary code execution on the client should a user connect to it using cadaver. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-0398 to this issue. Users of cadaver are advised to upgrade to this updated package, which contains patches correcting these issues. 4. Solution: Before applying this update, make sure all previously released errata relevant to your system have been applied. To update all RPMs for your particular architecture, run: rpm -Fvh [filenames] where [filenames] is a list of the RPMs you wish to upgrade. Only those RPMs which are currently installed will be updated. Those RPMs which are not installed but included in the list will not be updated. Note that you can also use wildcards (*.rpm) if your current directory *only* contains the desired RPMs. Please note that this update is also available via yum and apt. Many people find this an easier way to apply updates. To use yum issue: yum update or to use apt: apt-get update; apt-get upgrade This will start an interactive process that will result in the appropriate RPMs being upgraded on your system. This assumes that you have yum or apt-get configured for obtaining Fedora Legacy content. Please visit http://www.fedoralegacy.org/docs/ for directions on how to configure yum and apt-get. 5. Bug IDs fixed: http://bugzilla.fedora.us - 1552 - cadaver neon vulnerability (CAN-2004-0179) 6. RPMs required: Red Hat Linux 7.3: SRPM: http://download.fedoralegacy.org/redhat/7.3/updates/SRPMS/cadaver-0.22.1-1.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/7.3/updates/i386/cadaver-0.22.1-1.legacy.i386.rpm Red Hat Linux 9: SRPM: http://download.fedoralegacy.org/redhat/9/updates/SRPMS/cadaver-0.22.1-3.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/9/updates/i386/cadaver-0.22.1-3.legacy.i386.rpm 7. Verification: SHA1 sum Package Name --------------------------------------------------------------------------- 46931edc0f4e8ad25c994891938c103a45f28982 7.3/updates/SRPMS/cadaver-0.22.1-1.legacy.src.rpm 0c3742f3151d4dedc5e5320a3a4792f17e8bd2e4 7.3/updates/i386/cadaver-0.22.1-1.legacy.i386.rpm 6cc852676c85e9cc3dc8e472676185cdffabf09f 9/updates/SRPMS/cadaver-0.22.1-3.legacy.src.rpm 1a9d4e010885e902b2a6a994cfee5744b7f4afba 9/updates/i386/cadaver-0.22.1-3.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://security.e-matters.de/advisories/062004.html 9. Contact: The Fedora Legacy security contact is . More project details at http://www.fedoralegacy.org --------------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From dom at earth.li Wed Sep 29 16:12:29 2004 From: dom at earth.li (Dominic Hargreaves) Date: Wed, 29 Sep 2004 17:12:29 +0100 Subject: [Full-Disclosure] [FLSA-2004:1468] Updated tcpdump packages that fix multiple security vulnerabilities Message-ID: <20040929161226.GA11725@home.thedom.org> ----------------------------------------------------------------------- Fedora Legacy Update Advisory Synopsis: Updated tcpdump resolves security vulnerabilities Advisory ID: FLSA:1468 Issue date: 2004-09-29 Product: Red Hat Linux Keywords: Security Cross references: https://bugzilla.fedora.us/show_bug.cgi?id=1468 CVE Names: CAN-2004-0183, CAN-2004-0184 ----------------------------------------------------------------------- ----------------------------------------------------------------------- 1. Topic: Updated tcpdump packages that fix multiple security vulnerabilities are now available. 2. Relevant releases/architectures: Red Hat Linux 7.3 - i386 Red Hat Linux 9 - i386 3. Problem description: Tcpdump is a command-line tool for monitoring network traffic. Tcpdump v3.8.1 and earlier versions contained multiple flaws in the packet display functions for the ISAKMP protocol. Upon receiving specially crafted ISAKMP packets, tcpdump would try to read beyond the end of the packet capture buffer and subsequently crash. All users are advised to upgrade to these updated packages, which contain a backported fix and are not vulnerable to this issue. 4. Solution: Before applying this update, make sure all previously released errata relevant to your system have been applied. To update all RPMs for your particular architecture, run: rpm -Fvh [filenames] where [filenames] is a list of the RPMs you wish to upgrade. Only those RPMs which are currently installed will be updated. Those RPMs which are not installed but included in the list will not be updated. Note that you can also use wildcards (*.rpm) if your current directory *only* contains the desired RPMs. Please note that this update is also available via yum and apt. Many people find this an easier way to apply updates. To use yum issue: yum update or to use apt: apt-get update; apt-get upgrade This will start an interactive process that will result in the appropriate RPMs being upgraded on your system. This assumes that you have yum or apt-get configured for obtaining Fedora Legacy content. Please visit http://www.fedoralegacy.org/docs/ for directions on how to configure yum and apt-get. 5. Bug IDs fixed: http://bugzilla.fedora.us - 1468 - tcpdump ISAKMP Packet Decoding Vulnerability 6. RPMs required: Red Hat Linux 7.3: SRPM: http://download.fedoralegacy.org/redhat/7.3/updates/SRPMS/tcpdump-3.6.3-17.7.3.6.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/7.3/updates/i386/arpwatch-2.1a11-17.7.3.6.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/libpcap-0.6.2-17.7.3.6.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/tcpdump-3.6.3-17.7.3.6.legacy.i386.rpm Red Hat Linux 9: SRPM: http://download.fedoralegacy.org/redhat/9/updates/SRPMS/tcpdump-3.7.2-7.9.3.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/9/updates/i386/arpwatch-2.1a11-7.9.3.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/libpcap-0.7.2-7.9.3.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/tcpdump-3.7.2-7.9.3.legacy.i386.rpm 7. Verification: SHA1 sum Package Name --------------------------------------------------------------------------- 3c236622c2f0815b257eb6df89470875844ab051 7.3/updates/SRPMS/tcpdump-3.6.3-17.7.3.6.legacy.src.rpm 1d7866f944b95a9350098803c1be9a9439ef9de1 7.3/updates/i386/arpwatch-2.1a11-17.7.3.6.legacy.i386.rpm 827884c667461dcd1624b666d29d83e50e4611cc 7.3/updates/i386/libpcap-0.6.2-17.7.3.6.legacy.i386.rpm 2e77a8344ce68a80fe484fae4e9e371b92dc25c2 7.3/updates/i386/tcpdump-3.6.3-17.7.3.6.legacy.i386.rpm 2a63dfe8422c135d41ec0655d1957b2ac6e348a2 9/updates/SRPMS/tcpdump-3.7.2-7.9.3.legacy.src.rpm e2e2cd142b0a4a50ab3b66a665d52e35fbe103aa 9/updates/i386/arpwatch-2.1a11-7.9.3.legacy.i386.rpm 3e7aad82c73a3250828b05e1308eb63a43c0d35e 9/updates/i386/libpcap-0.7.2-7.9.3.legacy.i386.rpm 39b28a5fc7bda074426736cfdbc6a2186979daa2 9/updates/i386/tcpdump-3.7.2-7.9.3.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://marc.theaimsgroup.com/?l=bugtraq&m=108067265931525&w=2 9. Contact: The Fedora Legacy security contact is . More project details at http://www.fedoralegacy.org --------------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From dom at earth.li Thu Sep 30 12:25:06 2004 From: dom at earth.li (Dominic Hargreaves) Date: Thu, 30 Sep 2004 13:25:06 +0100 Subject: [FLSA-2004:1549] Updated xchat packages fix security vulnerability Message-ID: <20040930122504.GA16974@home.thedom.org> ----------------------------------------------------------------------- Fedora Legacy Update Advisory Synopsis: Updated xchat resolves security vulnerabilities Advisory ID: FLSA:1549 Issue date: 2004-09-30 Product: Red Hat Linux Keywords: Security Cross references: https://bugzilla.fedora.us/show_bug.cgi?id=1549 CVE Names: CAN-2004-0409 ----------------------------------------------------------------------- ----------------------------------------------------------------------- 1. Topic: Updated xchat packages that fix a security vulnerability are now available. 2. Relevant releases/architectures: Red Hat Linux 7.3 - i386 3. Problem description: X-Chat is a graphical IRC chat client for the X Window System. A stack buffer overflow flaw was found in the X-Chat's Socks-5 proxy code. An attacker could create a malicious Socks-5 proxy server in such a way that X-Chat would execute arbitrary code if a victim configured X-Chat to use the proxy. Users of X-Chat should upgrade to this updated package which contains a backported security patch and is not vulnerable to this issue. 4. Solution: Before applying this update, make sure all previously released errata relevant to your system have been applied. To update all RPMs for your particular architecture, run: rpm -Fvh [filenames] where [filenames] is a list of the RPMs you wish to upgrade. Only those RPMs which are currently installed will be updated. Those RPMs which are not installed but included in the list will not be updated. Note that you can also use wildcards (*.rpm) if your current directory *only* contains the desired RPMs. Please note that this update is also available via yum and apt. Many people find this an easier way to apply updates. To use yum issue: yum update or to use apt: apt-get update; apt-get upgrade This will start an interactive process that will result in the appropriate RPMs being upgraded on your system. This assumes that you have yum or apt-get configured for obtaining Fedora Legacy content. Please visit http://www.fedoralegacy.org/docs/ for directions on how to configure yum and apt-get. 5. Bug IDs fixed: http://bugzilla.fedora.us - 1549 - xchat CAN-2004-0409 6. RPMs required: Red Hat Linux 7.3: SRPM: http://download.fedoralegacy.org/redhat/7.3/updates/SRPMS/xchat-1.8.9-1.73.2.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/7.3/updates/i386/xchat-1.8.9-1.73.2.legacy.i386.rpm 7. Verification: SHA1 sum Package Name --------------------------------------------------------------------------- cf1a4d68df4b21c9f19cc8ac8f87bd6802413e43 7.3/updates/SRPMS/xchat-1.8.9-1.73.2.legacy.src.rpm ec7357872af344cb5e09556ba21865aa78e99e3d 7.3/updates/i386/xchat-1.8.9-1.73.2.legacy.i386.rpm These packages are GPG signed by Fedora Legacy for security. Our key is available from http://www.fedoralegacy org/about/security.php You can verify each package with the following command: rpm --checksig -v If you only wish to verify that each package has not been corrupted or tampered with, examine only the sha1sum with the following command: sha1sum 8. References: http://mail.nl.linux.org/xchat-announce/2004-04/msg00000.html 9. Contact: The Fedora Legacy security contact is . More project details at http://www.fedoralegacy.org --------------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From dom at earth.li Thu Sep 30 12:33:10 2004 From: dom at earth.li (Dominic Hargreaves) Date: Thu, 30 Sep 2004 13:33:10 +0100 Subject: [FLSA-2004:1581] Updated flim packages fix security vulnerability Message-ID: <20040930123309.GA17004@home.thedom.org> ----------------------------------------------------------------------- Fedora Legacy Update Advisory Synopsis: Updated flim resolves security vulnerabilities Advisory ID: FLSA:1581 Issue date: 2004-09-30 Product: Red Hat Linux Keywords: Security Cross references: https://bugzilla.fedora.us/show_bug.cgi?id=1581 CVE Names: CAN-2004-0422 ----------------------------------------------------------------------- ----------------------------------------------------------------------- 1. Topic: Updated flim packages that fix a security vulnerability are now available. 2. Relevant releases/architectures: Red Hat Linux 7.3 - i386 Red Hat Linux 9 - i386 3. Problem description: The flim package includes a MIME library for GNU Emacs and XEmacs used by the wl mail package. Tatsuya Kinoshita discovered a vulnerability in flim, an emacs library for working with Internet messages. Temporary files were being created without taking adequate precautions, and therefore a local user could potentially overwrite files with the privileges of the user running emacs. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-0422 to this issue. Users of flim are advised to upgrade to this updated package, which contains patches correcting these issues. 4. Solution: Before applying this update, make sure all previously released errata relevant to your system have been applied. To update all RPMs for your particular architecture, run: rpm -Fvh [filenames] where [filenames] is a list of the RPMs you wish to upgrade. Only those RPMs which are currently installed will be updated. Those RPMs which are not installed but included in the list will not be updated. Note that you can also use wildcards (*.rpm) if your current directory *only* contains the desired RPMs. Please note that this update is also available via yum and apt. Many people find this an easier way to apply updates. To use yum issue: yum update or to use apt: apt-get update; apt-get upgrade This will start an interactive process that will result in the appropriate RPMs being upgraded on your system. This assumes that you have yum or apt-get configured for obtaining Fedora Legacy content. Please visit http://www.fedoralegacy.org/docs/ for directions on how to configure yum and apt-get. 5. Bug IDs fixed: http://bugzilla.fedora.us - 1581 - flim insecure temporary file CAN-2004-0422 6. RPMs required: Red Hat Linux 7.3: SRPM: http://download.fedoralegacy.org/redhat/7.3/updates/SRPMS/flim-1.14.4-4.7x.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/7.3/updates/i386/flim-1.14.4-4.7x.legacy.noarch.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/flim-xemacs-1.14.4-4.7x.legacy.noarch.rpm Red Hat Linux 9: SRPM: http://download.fedoralegacy.org/redhat/9/updates/SRPMS/flim-1.14.4-4.9.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/9/updates/i386/flim-1.14.4-4.9.legacy.noarch.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/flim-xemacs-1.14.4-4.9.legacy.noarch.rpm 7. Verification: SHA1 sum Package Name --------------------------------------------------------------------------- f7236bf2d2a3ed5b024e391918ff286b8f0b10db 7.3/updates/SRPMS/flim-1.14.4-4.7x.legacy.src.rpm c3683fae4e02fa01490a0e7376b0cc680921c3cc 7.3/updates/i386/flim-1.14.4-4.7x.legacy.noarch.rpm b895a2ea9a6c7c52f22cabd273306dfea9d318e4 7.3/updates/i386/flim-xemacs-1.14.4-4.7x.legacy.noarch.rpm 20ab29707a40a754bb7259b8940be283eb82f7d0 9/updates/SRPMS/flim-1.14.4-4.9.legacy.src.rpm 136a864b72fe9600caeec27b0804a55013c27dbc 9/updates/i386/flim-1.14.4-4.9.legacy.noarch.rpm 5ce5f434dd078bfb863f595379897ad1e9b37a59 9/updates/i386/flim-xemacs-1.14.4-4.9.legacy.noarch.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://rhn.redhat.com/errata/RHSA-2004-344.html 9. Contact: The Fedora Legacy security contact is . More project details at http://www.fedoralegacy.org --------------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From marcdeslauriers at videotron.ca Thu Sep 30 10:22:28 2004 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Thu, 30 Sep 2004 06:22:28 -0400 Subject: [Full-Disclosure] [FLSA-2004:2003] Updated rsync package fixes security issues Message-ID: <1096539748.6762.3.camel@mdlinux> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - - ----------------------------------------------------------------------- Fedora Legacy Update Advisory Synopsis: Updated rsync package fixes security issues Advisory ID: FLSA:2003 Issue date: 2004-09-30 Product: Red Hat Linux Keywords: Bugfix Cross references: https://bugzilla.fedora.us/show_bug.cgi?id=2003 CVE Names: CAN-2004-0426 CAN-2004-0792 - - ----------------------------------------------------------------------- - - ----------------------------------------------------------------------- 1. Topic: An updated rsync package that fixes several security issues is now available. The rsync program synchronizes files over a network. 2. Relevent releases/architectures: Red Hat Linux 7.3 - i386 Red Hat Linux 9 - i386 3. Problem description: Rsync before 2.6.1 does not properly sanitize paths when running a read/write daemon without using chroot. This could allow a remote attacker to write files outside of the module's "path", depending on the privileges assigned to the rsync daemon. Users not running an rsync daemon, running a read-only daemon, or running a chrooted daemon are not affected by this issue. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-0426 to this issue. Versions of rsync up to and including version 2.6.2 contain a path sanitization issue. This issue could allow an attacker to read or write files outside of the rsync directory. This vulnerability is only exploitable when an rsync server is enabled and is not running within a chroot. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-0792 to this issue. Users of rsync are advised to upgrade to this updated package, which contains backported patches and is not affected by these issues. 4. Solution: Before applying this update, make sure all previously released errata relevant to your system have been applied. To update all RPMs for your particular architecture, run: rpm -Fvh [filenames] where [filenames] is a list of the RPMs you wish to upgrade. Only those RPMs which are currently installed will be updated. Those RPMs which are not installed but included in the list will not be updated. Note that you can also use wildcards (*.rpm) if your current directory *only* contains the desired RPMs. Please note that this update is also available via yum and apt. Many people find this an easier way to apply updates. To use yum issue: yum update or to use apt: apt-get update; apt-get upgrade This will start an interactive process that will result in the appropriate RPMs being upgraded on your system. This assumes that you have yum or apt-get configured for obtaining Fedora Legacy content. Please visit http://www fedoralegacy.org/docs for directions on how to configure yum and apt-get. 5. Bug IDs fixed: http://bugzilla.fedora.us - bug #1569 http://bugzilla.fedora.us - bug #2003 6. RPMs required: Red Hat Linux 7.3: SRPM: http://download.fedoralegacy.org/redhat/7.3/updates/SRPMS/rsync-2.5.7-2.legacy.7x.src.rpm i386: http://download.fedoralegacy.org/redhat/7.3/updates/i386/rsync-2.5.7-2.legacy.7x.i386.rpm Red Hat Linux 9: SRPM: http://download.fedoralegacy.org/redhat/9/updates/SRPMS/rsync-2.5.7-2.legacy.9.src.rpm i386: http://download.fedoralegacy.org/redhat/9/updates/i386/rsync-2.5.7-2.legacy.9.i386.rpm 7. Verification: SHA1 sum Package Name - - --------------------------------------------------------------------------- 1101ad1c735a11c9be6f4d45971374a6195431d9 7.3/updates/i386/rsync-2.5.7-2.legacy.7x.i386.rpm 4bb344d823f423cf5c1cc64d949dd1d9408960e7 7.3/updates/SRPMS/rsync-2.5.7-2.legacy.7x.src.rpm 49a3fa2fe967ed5c62994d5785463357aaf49de5 9/updates/i386/rsync-2.5.7-2.legacy.9.i386.rpm 84ec22198c189660f3cf2b967b710de9a04d6b22 9/updates/SRPMS/rsync-2.5.7-2.legacy.9.src.rpm These packages are GPG signed by Fedora Legacy for security. Our key is available from http://www.fedoralegacy org/about/security.php You can verify each package with the following command: rpm --checksig -v If you only wish to verify that each package has not been corrupted or tampered with, examine only the sha1sum with the following command: sha1sum 8. References: http://rsync.samba.org/#security_apr04 http://rsync.samba.org/#security_aug04 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0426 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0792 9. Contact: The Fedora Legacy security contact is . More project details at http://www.fedoralegacy.org - - --------------------------------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBW90yLMAs/0C4zNoRAigPAKCyd2qrr/E5euEo4cZ509eGSQ3U3ACfYvP1 1NWrfCntZHfnvKlJ4Uvm98U= =gYDA -----END PGP SIGNATURE----- _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html From marcdeslauriers at videotron.ca Thu Sep 30 10:24:34 2004 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Thu, 30 Sep 2004 06:24:34 -0400 Subject: [Full-Disclosure] [FLSA-2004:1840] Updated Ethereal packages fix security issues Message-ID: <1096539874.6762.6.camel@mdlinux> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - - ----------------------------------------------------------------------- Fedora Legacy Update Advisory Synopsis: Updated Ethereal packages fix security issues Advisory ID: FLSA:1840 Issue date: 2004-09-30 Product: Red Hat Linux Keywords: Bugfix Cross references: https://bugzilla.fedora.us/show_bug.cgi?id=1840 CVE Names: CAN-2004-0176 CAN-2004-0365 CAN-2004-0367 CAN-2004-0504 CAN-2004-0505 CAN-2004-0506 CAN-2004-0507 CAN-2004-0633 CAN-2004-0634 CAN-2004-0635 - - ----------------------------------------------------------------------- - - ----------------------------------------------------------------------- 1. Topic: Updated Ethereal packages that fix various security vulnerabilities are now available. Ethereal is a program for monitoring network traffic. 2. Relevent releases/architectures: Red Hat Linux 7.3 - i386 Red Hat Linux 9 - i386 3. Problem description: Issues fixed with this Ethereal release include: Stefan Esser reported that Ethereal versions 0.10.1 and earlier contain stack overflows in the IGRP, PGM, Metflow, ISUP, TCAP, or IGAP dissectors. On a system where Ethereal is being run a remote attacker could send malicious packets that could cause Ethereal to crash or execute arbitrary code. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-0176 to this issue. Jonathan Heussser discovered that a carefully-crafted RADIUS packet could cause a crash. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-0365 to this issue. Ethereal 0.8.13 to 0.10.2 allows remote attackers to cause a denial of service (crash) via a zero-length Presentation protocol selector. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-0367 to this issue. The MMSE dissector in Ethereal releases 0.10.1 through 0.10.3 contained a buffer overflow flaw. On a system where Ethereal is running, a remote attacker could send malicious packets that could cause Ethereal to crash or execute arbitrary code. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-0507 to this issue. In addition, other flaws in Ethereal prior to 0.10.4 were found that could cause it to crash in response to carefully crafted SIP (CAN-2004-0504), AIM (CAN-2004-0505), or SPNEGO (CAN-2004-0506) packets. The SNMP dissector in Ethereal releases 0.8.15 through 0.10.4 contained a memory read flaw. On a system where Ethereal is running, a remote attacker could send malicious packets that could cause Ethereal to crash or possibly execute arbitrary code. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-0635 to this issue. The SMB dissector in Ethereal releases 0.9.15 through 0.10.4 contained a null pointer flaw. On a system where Ethereal is running, a remote attacker could send malicious packets that could cause Ethereal to crash. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-0634 to this issue. The iSNS dissector in Ethereal releases 0.10.3 through 0.10.4 contained an integer overflow flaw. On a system where Ethereal is running, a remote attacker could send malicious packets that could cause Ethereal to crash or possibly execute arbitrary code. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-0633 to this issue. Users of Ethereal should upgrade to these updated packages, which contain backported security patches that correct these issues. 4. Solution: Before applying this update, make sure all previously released errata relevant to your system have been applied. To update all RPMs for your particular architecture, run: rpm -Fvh [filenames] where [filenames] is a list of the RPMs you wish to upgrade. Only those RPMs which are currently installed will be updated. Those RPMs which are not installed but included in the list will not be updated. Note that you can also use wildcards (*.rpm) if your current directory *only* contains the desired RPMs. Please note that this update is also available via yum and apt. Many people find this an easier way to apply updates. To use yum issue: yum update or to use apt: apt-get update; apt-get upgrade This will start an interactive process that will result in the appropriate RPMs being upgraded on your system. This assumes that you have yum or apt-get configured for obtaining Fedora Legacy content. Please visit http://www fedoralegacy.org/docs for directions on how to configure yum and apt-get. 5. Bug IDs fixed: http://bugzilla.fedora.us - bug #1419 http://bugzilla.fedora.us - bug #1840 6. RPMs required: Red Hat Linux 7.3: SRPM: http://download.fedoralegacy.org/redhat/7.3/updates/SRPMS/ethereal-0.10.3-0.73.3.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/7.3/updates/i386/ethereal-0.10.3-0.73.3.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/ethereal-gnome-0.10.3-0.73.3.legacy.i386.rpm Red Hat Linux 9: SRPM: http://download.fedoralegacy.org/redhat/9/updates/SRPMS/ethereal-0.10.3-0.90.4.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/9/updates/i386/ethereal-0.10.3-0.90.4.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/ethereal-gnome-0.10.3-0.90.4.legacy.i386.rpm 7. Verification: SHA1 sum Package Name - - --------------------------------------------------------------------------- 9dea4bd2d8a8efce8722e7891a8b211ece731645 7.3/updates/i386/ethereal-0.10.3-0.73.3.legacy.i386.rpm f3defe29af6aceec7df646a0a49d8654823796e1 7.3/updates/i386/ethereal-gnome-0.10.3-0.73.3.legacy.i386.rpm 33c5ea5e2cabcd186aace74b9679a07c950d0d89 7.3/updates/SRPMS/ethereal-0.10.3-0.73.3.legacy.src.rpm 5c8e340c29644e861ebe064158b04420ca447066 9/updates/i386/ethereal-0.10.3-0.90.4.legacy.i386.rpm beb7b34e7a09b29c32976f7af123c7712f469bc6 9/updates/i386/ethereal-gnome-0.10.3-0.90.4.legacy.i386.rpm a32b6b54c36c2fe6a29e47080cadbb6ae87c8d6a 9/updates/SRPMS/ethereal-0.10.3-0.90.4.legacy.src.rpm These packages are GPG signed by Fedora Legacy for security. Our key is available from http://www.fedoralegacy org/about/security.php You can verify each package with the following command: rpm --checksig -v If you only wish to verify that each package has not been corrupted or tampered with, examine only the sha1sum with the following command: sha1sum 8. References: http://www.ethereal.com/appnotes/enpa-sa-00013.html http://www.ethereal.com/appnotes/enpa-sa-00014.html http://www.ethereal.com/appnotes/enpa-sa-00015.html http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0176 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0365 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0367 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0504 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0505 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0506 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0507 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0633 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0634 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0635 9. Contact: The Fedora Legacy security contact is . More project details at http://www.fedoralegacy.org - - --------------------------------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBW96ILMAs/0C4zNoRAt2IAJ92d61uwD3kP8uxzOMeL4LhhNoFWACcD5zx XVIAJKRFtSw27sw4giVzPc0= =SUxl -----END PGP SIGNATURE----- _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html From info at coolzero.info Thu Sep 30 15:18:15 2004 From: info at coolzero.info (Jim van Wel) Date: Thu, 30 Sep 2004 17:18:15 +0200 Subject: Problem with new legacy package in RedHat 9.0 with php... Message-ID: <200409301518.i8UFIEnc007949@vmx40.multikabel.net> I have a major problem with the package php-4.2.2-17.5.legacy.i386. It doesn't support the mail() function anymore? Am I doing something wrong, and if so, what can I do to fix it? I get an error like this: Warning: mail() is not supported in this PHP build Hope to hear soon about this matter. From simon at nzservers.com Thu Sep 30 15:31:20 2004 From: simon at nzservers.com (Simon Weller) Date: Thu, 30 Sep 2004 10:31:20 -0500 Subject: Problem with new legacy package in RedHat 9.0 with php... In-Reply-To: <200409301518.i8UFIEnc007949@vmx40.multikabel.net> References: <200409301518.i8UFIEnc007949@vmx40.multikabel.net> Message-ID: <200409301031.20967.simon@nzservers.com> Does the build machine have /sbin/sendmail? If not, it needs to be symlinked to the mta or php will leave mail() support out completely. - Si On Thursday 30 September 2004 10:18 am, Jim van Wel wrote: > I have a major problem with the package php-4.2.2-17.5.legacy.i386. It > doesn't support the mail() function anymore? Am I doing something wrong, > and if so, what can I do to fix it? > > I get an error like this: > > Warning: mail() is not supported in this PHP build > > Hope to hear soon about this matter. > > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-legacy-list -- Simon Weller LPIC-2 Systems Engineer NZServers LTD http://www.nzservers.com/ U.S. Branch <- To mess up a Linux box, you need to work at it; to mess up your Windows box, you just need to work on it. - Scott Granneman, Security Focus -> From jkeating at j2solutions.net Thu Sep 30 15:39:12 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Thu, 30 Sep 2004 08:39:12 -0700 Subject: Problem with new legacy package in RedHat 9.0 with php... In-Reply-To: <200409301031.20967.simon@nzservers.com> References: <200409301518.i8UFIEnc007949@vmx40.multikabel.net> <200409301031.20967.simon@nzservers.com> Message-ID: <200409300839.12286.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday 30 September 2004 08:31, Simon Weller wrote: > Does the build machine have /sbin/sendmail? > > If not, it needs to be symlinked to the mta or php will leave mail() > support out completely. Build system has whatever the rpm says is a buildreq. If sendmail isn't listed as a buildreq, then sendmail isn't installed on the build system. This kind of thing should have been caught in updates-testing, was it not tested then? We'll have to rebuild and re-issue immediately. - -- Jesse Keating RHCE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedoralegacy.org) GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBXCig4v2HLvE71NURAt7iAJ9j31UJocXxzgJ3+lOGD+pSGAxIeACffqgi 8o8vTABS5SlAf6uKPlH+07I= =DACc -----END PGP SIGNATURE----- From simon at nzservers.com Thu Sep 30 15:50:10 2004 From: simon at nzservers.com (Simon Weller) Date: Thu, 30 Sep 2004 10:50:10 -0500 Subject: Problem with new legacy package in RedHat 9.0 with php... In-Reply-To: <200409300839.12286.jkeating@j2solutions.net> References: <200409301518.i8UFIEnc007949@vmx40.multikabel.net> <200409301031.20967.simon@nzservers.com> <200409300839.12286.jkeating@j2solutions.net> Message-ID: <200409301050.10472.simon@nzservers.com> On Thursday 30 September 2004 10:39 am, Jesse Keating wrote: > On Thursday 30 September 2004 08:31, Simon Weller wrote: > > Does the build machine have /sbin/sendmail? > > > > If not, it needs to be symlinked to the mta or php will leave mail() > > support out completely. > > Build system has whatever the rpm says is a buildreq. If sendmail isn't > listed as a buildreq, then sendmail isn't installed on the build system. > This kind of thing should have been caught in updates-testing, was it not > tested then? We'll have to rebuild and re-issue immediately. agreed, this is a nasty one. - Si > > -- > Jesse Keating RHCE (http://geek.j2solutions.net) > Fedora Legacy Team (http://www.fedoralegacy.org) > GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub) > > Was I helpful? Let others know: > http://svcs.affero.net/rm.php?r=jkeating -- Simon Weller LPIC-2 Systems Engineer NZServers LTD http://www.nzservers.com/ U.S. Branch <- To mess up a Linux box, you need to work at it; to mess up your Windows box, you just need to work on it. - Scott Granneman, Security Focus -> From whb001 at shsu.edu Thu Sep 30 16:04:43 2004 From: whb001 at shsu.edu (Will Bending) Date: Thu, 30 Sep 2004 11:04:43 -0500 Subject: GPG key signature discrepancy Message-ID: <1096560283.21138.64.camel@turnip.shsu.edu> I have noticed that the following packages for rh 9 are using a non Fedora-Legacy GPG key signature: Name Arch Version Repo -------------------------------------------------------------------------------- ethereal i386 0.10.3-0.90.4.legacy updates-fedoralegacy rsync i386 2.5.7-2.legacy.9 updates-fedoralegacy Here is a sample: [root at someboxonmynetwork /]# rpm -qip /var/cache/yum/updates-fedoralegacy/packages/rsync-2.5.7-2.legacy.9.i386.rpm warning: /var/cache/yum/updates-fedoralegacy/packages/rsync-2.5.7-2.legacy.9.i386.rpm: V3 DSA signature: NOKEY, key ID 731002fa Name : rsync Relocations: /usr Version : 2.5.7 Vendor: Fedora Legacy Release : 2.legacy.9 Build Date: Tue 28 Sep 2004 06:37:59 PM CDT Install Date: (not installed) Build Host: jane.fedoralegacy.org Group : Applications/Internet Source RPM: rsync-2.5.7-2.legacy.9.src.rpm Size : 277714 License: GPL Signature : DSA/SHA1, Tue 28 Sep 2004 06:48:02 PM CDT, Key ID 108c4512731002fa Packager : Marc Deslauriers Summary : A program for synchronizing files over a network. Here's the one I imported a while back from the FC Legacy project: [root at someboxonmynetwork /]# rpm -qa gpg-pubkey* gpg-pubkey-db42a60e-37ea5438 I'm holding off on installing them at this time because of this. Just thought you'd want to be informed of it. Thanks, --will -------------- 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 dom at earth.li Thu Sep 30 16:11:50 2004 From: dom at earth.li (Dominic Hargreaves) Date: Thu, 30 Sep 2004 17:11:50 +0100 Subject: GPG key signature discrepancy In-Reply-To: <1096560283.21138.64.camel@turnip.shsu.edu> References: <1096560283.21138.64.camel@turnip.shsu.edu> Message-ID: <20040930161150.GK15895@tirian.magd.ox.ac.uk> On Thu, Sep 30, 2004 at 11:04:43AM -0500, Will Bending wrote: > [root at someboxonmynetwork /]# rpm -qip > /var/cache/yum/updates-fedoralegacy/packages/rsync-2.5.7-2.legacy.9.i386.rpm > warning: > /var/cache/yum/updates-fedoralegacy/packages/rsync-2.5.7-2.legacy.9.i386.rpm: V3 DSA signature: NOKEY, key ID 731002fa dom at tirian:~$ gpg --list-keys 731002fa pub 1024D/731002FA 2004-01-19 Fedora Legacy (http://www.fedoralegacy.org) sub 2048g/D12E351D 2004-01-19 > Here's the one I imported a while back from the FC Legacy project: > > [root at someboxonmynetwork /]# rpm -qa gpg-pubkey* > gpg-pubkey-db42a60e-37ea5438 dom at tirian:~$ gpg --list-keys db42a60e pub 1024D/DB42A60E 1999-09-23 Red Hat, Inc sub 2048g/961630A2 1999-09-23 It seems that you are mistaken. The key you have installed is a Red Hat key, not a Fedora Legacy one. Our key is described on: http://www.fedoralegacy.org/about/security.php Cheers, Dominic. From info at coolzero.info Thu Sep 30 16:47:57 2004 From: info at coolzero.info (Jim van Wel) Date: Thu, 30 Sep 2004 18:47:57 +0200 Subject: Problem with new legacy package in RedHat 9.0 with php... In-Reply-To: <200409301031.20967.simon@nzservers.com> Message-ID: <200409301648.i8UGlviu003724@vmx20.multikabel.net> I have done some other processes because of the fact the mail() was not working properly. [root at someserver php]# ls -all total 1864 drwxr-xr-x 2 root root 4096 Sep 30 16:53 . drwxr-x--- 14 root root 4096 Sep 30 16:58 .. -rw-r--r-- 1 root root 1359821 Jul 1 2003 php-4.2.2-17.2.i386.rpm -rw-r--r-- 1 root root 421018 Jul 1 2003 php-imap-4.2.2-17.2.i386.rpm -rw-r--r-- 1 root root 38300 Jul 1 2003 php-ldap-4.2.2-17.2.i386.rpm -rw-r--r-- 1 root root 37701 Jul 1 2003 php-mysql-4.2.2-17.2.i386.rpm [root at someserver php]# rpm -Uvh --oldpackage php-* After I have done this, the php is working properly again. I have located the sendmail in /usr/sbin/sendmail and looks like this with ls. /usr/sbin/sendmail -> /var/courier/bin/sendmail As you can see it's linked to courier. With the package above it's working fine. Am I still doing something wrong or is package not right? -----Oorspronkelijk bericht----- Van: fedora-legacy-list-bounces at redhat.com [mailto:fedora-legacy-list-bounces at redhat.com] Namens Simon Weller Verzonden: donderdag 30 september 2004 17:31 Aan: Discussion of the Fedora Legacy Project Onderwerp: Re: Problem with new legacy package in RedHat 9.0 with php... Does the build machine have /sbin/sendmail? If not, it needs to be symlinked to the mta or php will leave mail() support out completely. - Si On Thursday 30 September 2004 10:18 am, Jim van Wel wrote: > I have a major problem with the package php-4.2.2-17.5.legacy.i386. It > doesn't support the mail() function anymore? Am I doing something wrong, > and if so, what can I do to fix it? > > I get an error like this: > > Warning: mail() is not supported in this PHP build > > Hope to hear soon about this matter. > > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-legacy-list -- Simon Weller LPIC-2 Systems Engineer NZServers LTD http://www.nzservers.com/ U.S. Branch <- To mess up a Linux box, you need to work at it; to mess up your Windows box, you just need to work on it. - Scott Granneman, Security Focus -> -- fedora-legacy-list mailing list fedora-legacy-list at redhat.com http://www.redhat.com/mailman/listinfo/fedora-legacy-list From jkeating at j2solutions.net Thu Sep 30 17:08:32 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Thu, 30 Sep 2004 10:08:32 -0700 Subject: Problem with new legacy package in RedHat 9.0 with php... In-Reply-To: <200409301648.i8UGlviu003724@vmx20.multikabel.net> References: <200409301648.i8UGlviu003724@vmx20.multikabel.net> Message-ID: <200409301008.35195.jkeating@j2solutions.net> On Thursday 30 September 2004 09:47, Jim van Wel wrote: > [root at someserver php]# rpm -Uvh --oldpackage php-* > > After I have done this, the php is working properly again. I have > located the sendmail in /usr/sbin/sendmail and looks like this with > ls. > > /usr/sbin/sendmail -> /var/courier/bin/sendmail > > As you can see it's linked to courier. With the package above it's > working fine. > Am I still doing something wrong or is package not right? You have courier-mta installed, did you remove the sendmail package? Does /usr/lib/sendmail exist, or does 'rpm -q sendmail' show the right stuff? This php is from updates-testing correct? -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From sujiannming at gmail.com Thu Sep 30 17:50:58 2004 From: sujiannming at gmail.com (Jiann-Ming Su) Date: Thu, 30 Sep 2004 13:50:58 -0400 Subject: md5sum for entire filesystem? Message-ID: <561dc326040930105053ef289b@mail.gmail.com> Is there a md5sum for all the files in the FC1 distribution? I know there's md5sums for the iso and rpm packages. But, I'm looking for md5sum for each of the files. Is using md5sum even a good way to verify that system files haven't been compromised? I've tested md5sums from a two FC1 installs, and they don't match. And, I'm certain both of these boxes haven't been compromised. Thanks for any help. -- Jiann-Ming Su "I have to decide between two equally frightening options. If I wanted to do that, I'd vote." --Duckman From jonny.strom at netikka.fi Thu Sep 30 17:54:51 2004 From: jonny.strom at netikka.fi (Johnny Strom) Date: Thu, 30 Sep 2004 20:54:51 +0300 Subject: Problem with new legacy package in RedHat 9.0 with php... In-Reply-To: <200409301518.i8UFIEnc007949@vmx40.multikabel.net> References: <200409301518.i8UFIEnc007949@vmx40.multikabel.net> Message-ID: <415C486B.9050202@netikka.fi> Jim van Wel wrote: > I have a major problem with the package php-4.2.2-17.5.legacy.i386. It > doesn't support the mail() function anymore? Am I doing something wrong, and > if so, what can I do to fix it? > > I get an error like this: > > Warning: mail() is not supported in this PHP build > > Hope to hear soon about this matter. > > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-legacy-list This is a bug in php that it dose not find sendmail during configure, I had the same problem now I can't find the instructions how I fixed it. Try to search on the net it is fixed in later versions of php, I think from 4.3.5 or someting.. From jkeating at j2solutions.net Thu Sep 30 17:59:03 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Thu, 30 Sep 2004 10:59:03 -0700 Subject: md5sum for entire filesystem? In-Reply-To: <561dc326040930105053ef289b@mail.gmail.com> References: <561dc326040930105053ef289b@mail.gmail.com> Message-ID: <200409301059.03279.jkeating@j2solutions.net> On Thursday 30 September 2004 10:50, Jiann-Ming Su wrote: > Is there a md5sum for all the files in the FC1 distribution? I know > there's md5sums for the iso and rpm packages. But, I'm looking for > md5sum for each of the files. > > Is using md5sum even a good way to verify that system files haven't > been compromised? I've tested md5sums from a two FC1 installs, and > they don't match. And, I'm certain both of these boxes haven't been > compromised. rpm -V to verify packages. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From dom at earth.li Thu Sep 30 17:59:59 2004 From: dom at earth.li (Dominic Hargreaves) Date: Thu, 30 Sep 2004 18:59:59 +0100 Subject: md5sum for entire filesystem? In-Reply-To: <561dc326040930105053ef289b@mail.gmail.com> References: <561dc326040930105053ef289b@mail.gmail.com> Message-ID: <20040930175959.GL15895@tirian.magd.ox.ac.uk> On Thu, Sep 30, 2004 at 01:50:58PM -0400, Jiann-Ming Su wrote: > Is there a md5sum for all the files in the FC1 distribution? I know > there's md5sums for the iso and rpm packages. But, I'm looking for > md5sum for each of the files. http://www.knowngoods.org/ It won't necessarily have all or any updates applied though. > Is using md5sum even a good way to verify that system files haven't > been compromised? I've tested md5sums from a two FC1 installs, and > they don't match. And, I'm certain both of these boxes haven't been > compromised. Do they have the same level of updates applied to both? Dominic. From kwan at digitalhermit.com Thu Sep 30 18:03:45 2004 From: kwan at digitalhermit.com (Kwan Lowe) Date: Thu, 30 Sep 2004 14:03:45 -0400 (EDT) Subject: md5sum for entire filesystem? In-Reply-To: <561dc326040930105053ef289b@mail.gmail.com> References: <561dc326040930105053ef289b@mail.gmail.com> Message-ID: <32033.12.43.115.206.1096567425.squirrel@digitalhermit.com> > Is there a md5sum for all the files in the FC1 distribution? I know > there's md5sums for the iso and rpm packages. But, I'm looking for > md5sum for each of the files. > > Is using md5sum even a good way to verify that system files haven't > been compromised? I've tested md5sums from a two FC1 installs, and > they don't match. And, I'm certain both of these boxes haven't been > compromised. You can use the built-in rpm verification tools to check timestamps, signature, size, permissions, etc.. Outside of this, look at tripwire or other IDS systems. What files are you concerned about? Be aware that many config files, logs, etc.. will get overwritten in normal course. -- * The Digital Hermit http://www.digitalhermit.com * Unix and Linux Solutions kwan at digitalhermit.com From guallar at easternrad.com Thu Sep 30 18:05:45 2004 From: guallar at easternrad.com (Josep L. Guallar-Esteve) Date: Thu, 30 Sep 2004 14:05:45 -0400 Subject: md5sum for entire filesystem? In-Reply-To: <561dc326040930105053ef289b@mail.gmail.com> References: <561dc326040930105053ef289b@mail.gmail.com> Message-ID: <200409301405.49372.guallar@easternrad.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday 30 September 2004 01:50 pm, Jiann-Ming Su wrote: > Is there a md5sum for all the files in the FC1 distribution? I know > there's md5sums for the iso and rpm packages. But, I'm looking for > md5sum for each of the files. There is a built-in fle checking system in rpm-based systems. To check if files have been modified since 'foobar' was installed, use: rpm -V foobar Regards, Josep - -- Josep L. Guallar-Esteve Eastern Radiologists, Inc. Systems and PACS Administration http://www.easternrad.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBXEr8SGQa4/zQ9e8RAswyAKCEaQnCcYcldKhd3nvhzKEM3Wnq0wCfcJt5 D9T1pV0JgHEUoODv5ND88yU= =5lCs -----END PGP SIGNATURE----- From jonny.strom at netikka.fi Thu Sep 30 18:04:02 2004 From: jonny.strom at netikka.fi (Johnny Strom) Date: Thu, 30 Sep 2004 21:04:02 +0300 Subject: Problem with new legacy package in RedHat 9.0 with php... In-Reply-To: <200409301518.i8UFIEnc007949@vmx40.multikabel.net> References: <200409301518.i8UFIEnc007949@vmx40.multikabel.net> Message-ID: <415C4A92.6080703@netikka.fi> Jim van Wel wrote: > I have a major problem with the package php-4.2.2-17.5.legacy.i386. It > doesn't support the mail() function anymore? Am I doing something wrong, and > if so, what can I do to fix it? > > I get an error like this: > > Warning: mail() is not supported in this PHP build > > Hope to hear soon about this matter. > > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-legacy-list here it is mentiond in bug #22989 http://www.phpfreaks.com/articles/86/0.php From mule at umich.edu Thu Sep 30 18:12:21 2004 From: mule at umich.edu (Stephen E. Dudek) Date: Thu, 30 Sep 2004 14:12:21 -0400 Subject: Problem with new legacy package in RedHat 9.0 with php... In-Reply-To: <415C486B.9050202@netikka.fi> References: <200409301518.i8UFIEnc007949@vmx40.multikabel.net> <415C486B.9050202@netikka.fi> Message-ID: <1096567941.1644.13.camel@pestilence.themule.net> fb8475b2292b5b84785b322773c723b5dc9a9eed php-4.2.2-17.5.legacy.src.rpm I built the packages from the above source for Red Hat 9 from updates-testing, installed them on a test machine, wrote a sample PHP script with mail(). Ran the script, received mail, and verified function worked. Then, I removed all the packages from my test and downloaded the files from updates-testing and installed those. I ran my sample script and saw a difference: Warning: mail() is not supported in this PHP build Is a dependency missing? On Thu, 2004-09-30 at 13:54, Johnny Strom wrote: > Jim van Wel wrote: > > I have a major problem with the package php-4.2.2-17.5.legacy.i386. It > > doesn't support the mail() function anymore? Am I doing something wrong, and > > if so, what can I do to fix it? > > > > I get an error like this: > > > > Warning: mail() is not supported in this PHP build > > > > Hope to hear soon about this matter. > > > > > > -- > > fedora-legacy-list mailing list > > fedora-legacy-list at redhat.com > > http://www.redhat.com/mailman/listinfo/fedora-legacy-list > > > This is a bug in php that it dose not find sendmail during configure, > I had the same problem now I can't find the instructions how I fixed it. > > Try to search on the net it is fixed in later versions of php, I think > from 4.3.5 or someting.. > > > > > > > > -- > 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: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jonny.strom at netikka.fi Thu Sep 30 18:12:50 2004 From: jonny.strom at netikka.fi (Johnny Strom) Date: Thu, 30 Sep 2004 21:12:50 +0300 Subject: Problem with new legacy package in RedHat 9.0 with php... In-Reply-To: <1096567941.1644.13.camel@pestilence.themule.net> References: <200409301518.i8UFIEnc007949@vmx40.multikabel.net> <415C486B.9050202@netikka.fi> <1096567941.1644.13.camel@pestilence.themule.net> Message-ID: <415C4CA2.5070803@netikka.fi> Stephen E. Dudek wrote: > fb8475b2292b5b84785b322773c723b5dc9a9eed php-4.2.2-17.5.legacy.src.rpm > > I built the packages from the above source for Red Hat 9 from > updates-testing, installed them on a test machine, wrote a sample PHP > script with mail(). Ran the script, received mail, and verified > function worked. > > Then, I removed all the packages from my test and downloaded the files > from updates-testing and installed those. I ran my sample script and > saw a difference: > > Warning: mail() is not supported in this PHP build > > Is a dependency missing? Yes it is the bug I mailed about I will try to find out how to make it build ok... > > > On Thu, 2004-09-30 at 13:54, Johnny Strom wrote: > >>Jim van Wel wrote: >> >>>I have a major problem with the package php-4.2.2-17.5.legacy.i386. It >>>doesn't support the mail() function anymore? Am I doing something wrong, and >>>if so, what can I do to fix it? >>> >>>I get an error like this: >>> >>>Warning: mail() is not supported in this PHP build >>> >>>Hope to hear soon about this matter. >>> >>> >>>-- >>>fedora-legacy-list mailing list >>>fedora-legacy-list at redhat.com >>>http://www.redhat.com/mailman/listinfo/fedora-legacy-list >> >> >>This is a bug in php that it dose not find sendmail during configure, >>I had the same problem now I can't find the instructions how I fixed it. >> >>Try to search on the net it is fixed in later versions of php, I think >>from 4.3.5 or someting.. >> >> >> >> >> >> >> >>-- >>fedora-legacy-list mailing list >>fedora-legacy-list at redhat.com >>http://www.redhat.com/mailman/listinfo/fedora-legacy-lis > > t > > > ------------------------------------------------------------------------ > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-legacy-list From alexander.dalloz at uni-bielefeld.de Thu Sep 30 18:28:32 2004 From: alexander.dalloz at uni-bielefeld.de (Alexander Dalloz) Date: Thu, 30 Sep 2004 20:28:32 +0200 Subject: md5sum for entire filesystem? In-Reply-To: <561dc326040930105053ef289b@mail.gmail.com> References: <561dc326040930105053ef289b@mail.gmail.com> Message-ID: <1096568912.6210.157.camel@serendipity.dogma.lan> Am Do, den 30.09.2004 schrieb Jiann-Ming Su um 19:50: > Is there a md5sum for all the files in the FC1 distribution? I know > there's md5sums for the iso and rpm packages. But, I'm looking for > md5sum for each of the files. tripwire wortks with checksums: http://download.fedora.us/fedora/fedora/1/i386/RPMS.testing/tripwire-2.3.1-20.fdr.1.1.i386.rpm > Is using md5sum even a good way to verify that system files haven't > been compromised? I've tested md5sums from a two FC1 installs, and > they don't match. And, I'm certain both of these boxes haven't been > compromised. 2 systems are nearly never exactly the same. Even if you clone systems, short after they differ because of different log files. (I guess you are speaking about global checksums and not comparing md5sums of each and every single file.) Too there is prelinking on Fedora active which interferes. Alexander -- Alexander Dalloz | Enger, Germany | GPG key 1024D/ED695653 1999-07-13 Fedora GNU/Linux Core 2 (Tettnang) kernel 2.6.8-1.521smp Serendipity 20:25:08 up 22:51, 14 users, 1.82, 1.49, 0.99 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From jonny.strom at netikka.fi Thu Sep 30 18:50:10 2004 From: jonny.strom at netikka.fi (Johnny Strom) Date: Thu, 30 Sep 2004 21:50:10 +0300 Subject: Problem with new legacy package in RedHat 9.0 with php... In-Reply-To: <415C4CA2.5070803@netikka.fi> References: <200409301518.i8UFIEnc007949@vmx40.multikabel.net> <415C486B.9050202@netikka.fi> <1096567941.1644.13.camel@pestilence.themule.net> <415C4CA2.5070803@netikka.fi> Message-ID: <415C5562.6000308@netikka.fi> Hello This might be a fix: http://bugs.php.net/bug.php?id=22989&edit=3 Johnny Strom wrote: > Stephen E. Dudek wrote: > >> fb8475b2292b5b84785b322773c723b5dc9a9eed php-4.2.2-17.5.legacy.src.rpm >> >> I built the packages from the above source for Red Hat 9 from >> updates-testing, installed them on a test machine, wrote a sample PHP >> script with mail(). Ran the script, received mail, and verified >> function worked. >> >> Then, I removed all the packages from my test and downloaded the files >> from updates-testing and installed those. I ran my sample script and >> saw a difference: >> >> Warning: mail() is not supported in this PHP build >> Is a dependency missing? > > > > Yes it is the bug I mailed about I will try to find out how to > make it build ok... > > > > >> >> >> On Thu, 2004-09-30 at 13:54, Johnny Strom wrote: >> >>> Jim van Wel wrote: >>> >>>> I have a major problem with the package php-4.2.2-17.5.legacy.i386. It >>>> doesn't support the mail() function anymore? Am I doing something >>>> wrong, and >>>> if so, what can I do to fix it? >>>> >>>> I get an error like this: >>>> >>>> Warning: mail() is not supported in this PHP build >>>> >>>> Hope to hear soon about this matter. >>>> >>>> >>>> -- >>>> fedora-legacy-list mailing list >>>> fedora-legacy-list at redhat.com >>>> http://www.redhat.com/mailman/listinfo/fedora-legacy-list >>> >>> >>> >>> This is a bug in php that it dose not find sendmail during configure, >>> I had the same problem now I can't find the instructions how I fixed it. >>> >>> Try to search on the net it is fixed in later versions of php, I >>> think from 4.3.5 or someting.. >>> >>> >>> >>> >>> >>> >>> >>> -- >>> fedora-legacy-list mailing list >>> fedora-legacy-list at redhat.com >>> http://www.redhat.com/mailman/listinfo/fedora-legacy-lis >> >> >> t >> >> >> ------------------------------------------------------------------------ >> >> -- >> 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 rajones at svsmail.gsfc.nasa.gov Thu Sep 30 18:27:03 2004 From: rajones at svsmail.gsfc.nasa.gov (Randall A. Jones) Date: Thu, 30 Sep 2004 14:27:03 -0400 (EDT) Subject: md5sum for entire filesystem? In-Reply-To: <200409301405.49372.guallar@easternrad.com> Message-ID: To verify all RPMs installed on a system you can do something like: rpm -V `rpm -qa` You should get a lot of messages about files modified or different in various ways. See "man rpm" and search for "VERIFY OPTIONS" to find the meanings of the flags that show up to the left of the file path. You might want to send the output to a file ( with "> rpmV.out" ) to collect it before examining. You can ignore log files or various status files that show up here like /var/lib/nfs/rmtab, /var/log/messages, /var/log/wtmp, ... Look for executables or config files that may have changed like /etc/ssh/sshd_config, /usr/bin/ssh, /bin/ls ... ... one example output line from "rpm -V `rpm -qa`" ... S.5....T c /var/lib/nfs/rmtab ... If you see a suspicious file modification and you want to know what package contains that file you can do: rpm -qf /var/lib/nfs/rmtab Randall -- On Thu, 30 Sep 2004, Josep L. Guallar-Esteve wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Thursday 30 September 2004 01:50 pm, Jiann-Ming Su wrote: > > Is there a md5sum for all the files in the FC1 distribution? I know > > there's md5sums for the iso and rpm packages. But, I'm looking for > > md5sum for each of the files. > > There is a built-in fle checking system in rpm-based systems. To check if > files have been modified since 'foobar' was installed, use: > > rpm -V foobar > > > > Regards, > Josep > - -- > Josep L. Guallar-Esteve Eastern Radiologists, Inc. > Systems and PACS Administration http://www.easternrad.com > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.4 (GNU/Linux) > > iD8DBQFBXEr8SGQa4/zQ9e8RAswyAKCEaQnCcYcldKhd3nvhzKEM3Wnq0wCfcJt5 > D9T1pV0JgHEUoODv5ND88yU= > =5lCs > -----END PGP SIGNATURE----- > > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-legacy-list >