From rostetter at mail.utexas.edu Mon Dec 1 21:14:19 2003 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Mon, 1 Dec 2003 15:14:19 -0600 Subject: RFD: Alternative Release Support In-Reply-To: <1069949640.2726.0.camel@localhost.localdomain> References: <1069872407.2939.18.camel@localhost.localdomain> <200311261257.00182.jkeating@j2solutions.net> <1069881567.2939.38.camel@localhost.localdomain> <200311261313.53282.jkeating@j2solutions.net> <1069884123.2939.63.camel@localhost.localdomain> <1069886292.9685.12.camel@smoogen1.lanl.gov> <20031127134433.GA11310@chloe.cb.ac.at> <1069949640.2726.0.camel@localhost.localdomain> Message-ID: <20031201151419.ke40oaskkgkssskg@mail.ph.utexas.edu> Quoting "Rob J. Caskey" : > I created a page on the wiki: > > http://www.fedora.us/wiki/EveryOtherRelease?action=edit > > It would be nice if everyone just put their name down under yay or nay > so we can see how many people are going in which direction. > > -Rob Went there. Says I need to "Sign in". I don't have a wiki account, or what ever it wants. It says new users can leave the password blank, but all I get is an "Invalid password or userid." error. So, for those of us who have never used wiki, either an explaination, or instructions, or a discalimer telling us to stay away would be appropriate. -- Eric Rostetter From jeremyp at pobox.com Mon Dec 1 22:43:01 2003 From: jeremyp at pobox.com (Jeremy Portzer) Date: Mon, 01 Dec 2003 17:43:01 -0500 Subject: RFD: Alternative Release Support In-Reply-To: <20031201151419.ke40oaskkgkssskg@mail.ph.utexas.edu> References: <1069872407.2939.18.camel@localhost.localdomain> <200311261257.00182.jkeating@j2solutions.net> <1069881567.2939.38.camel@localhost.localdomain> <200311261313.53282.jkeating@j2solutions.net> <1069884123.2939.63.camel@localhost.localdomain> <1069886292.9685.12.camel@smoogen1.lanl.gov> <20031127134433.GA11310@chloe.cb.ac.at> <1069949640.2726.0.camel@localhost.localdomain> <20031201151419.ke40oaskkgkssskg@mail.ph.utexas.edu> Message-ID: <1070318581.13759.11.camel@jeremy.dtcc.cc.nc.us> On Mon, 2003-12-01 at 16:14, Eric Rostetter wrote: > Quoting "Rob J. Caskey" : > > > I created a page on the wiki: > > > > http://www.fedora.us/wiki/EveryOtherRelease?action=edit > > > > It would be nice if everyone just put their name down under yay or nay > > so we can see how many people are going in which direction. > > > > -Rob > > Went there. Says I need to "Sign in". I don't have a wiki account, or > what ever it wants. It says new users can leave the password blank, but > all I get is an "Invalid password or userid." error. Make sure you use a username in the wiki format, such as "EricRostetter" or "JeremyPortzer" --Jeremy -- /---------------------------------------------------------------------\ | Jeremy Portzer jeremyp at pobox.com trilug.org/~jeremy | | GPG Fingerprint: 712D 77C7 AB2D 2130 989F E135 6F9F F7BC CC1A 7B92 | \---------------------------------------------------------------------/ -------------- 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 rcaskey at uga.edu Wed Dec 3 01:55:16 2003 From: rcaskey at uga.edu (Rob J. Caskey) Date: Tue, 02 Dec 2003 20:55:16 -0500 Subject: RFD: Alternative Release Support In-Reply-To: <20031129034507.M49541@mm-vanecek.cc> References: <1069872407.2939.18.camel@localhost.localdomain> <3FC50683.61D8FD5F@gmx.de> <200311261257.00182.jkeating@j2solutions.net> <20031129034507.M49541@mm-vanecek.cc> Message-ID: <1070416516.3121.76.camel@localhost.localdomain> Oky, thought I would check in now that everyone has had a few days to digest things. http://www.fedora.us/wiki/EveryOtherRelease has a good summary of the issues at hand. Please weigh in if you have yet to do so! For you folks who favor select, but not exactly time-based supported releases, I will say that I am afraid this will put another potato in our hands and just gives us a lot of tough choices to make. I think that a hard-line every other release would lend an element of certainty to Legacy that would be reassuring and conforming to the project goals. Anyway, people, please continue to way in. If it seems clear that selected release support is the way to go, then we can worry about specifics. Now is the time for discussion! Sincerely, Rob J. Caskey On Fri, 2003-11-28 at 22:45, Mike Vanecek wrote: > On Wed, 26 Nov 2003 12:56:56 -0800, Jesse Keating wrote > > On Wednesday 26 November 2003 12:01, Martin Stricker wrote: > > > Agreed. I'm interested only in the really stable releases anyway > > > (like 5.2, 6.2, and 7.3). Hopefully a FC release will stand up for > > > this as well. Future will show... > > > > The current Red Hat Linux releases are special cases to Legacy. > > Those I want to support until they're pried from our cold dead > > hands. > > Thank you, thank you, thank you. > > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-legacy-list From brian.t.brunner at gai-tronics.com Wed Dec 3 14:21:37 2003 From: brian.t.brunner at gai-tronics.com (Brian T. Brunner) Date: Wed, 03 Dec 2003 09:21:37 -0500 Subject: RFD: Alternative Release Support Message-ID: If it were me carrying the load, I'd support 7.3 since getting to 7.3 from 7.x seems fairly painless, and my perception is that 7.x is fairly widely used. Getting from 7.x to 8 appears to be difficult for enough folks that I'd not push the 7.3 group to 8.0, but going 8 to 9 seems to be both a smaller set of people and less painful, so the next thing I'd support is 9. If I were to add a third supported point it would be 6.latest, not 8. The theory is to maintain hold-points where moving up to the next release is relatively more painful than was getting to the hold-point. which version(s) of Fedora to consider hold-points I can't at this time guess. Brian Brunner brian.t.brunner at gai-tronics.com (610)796-5838 >>> rcaskey at uga.edu 12/02/03 08:55PM >>> Oky, thought I would check in now that everyone has had a few days to digest things. Now is the time for discussion! ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept for the presence of computer viruses. www.hubbell.com - Hubbell Incorporated ********************************************************************** From jdaily at progeny.com Wed Dec 3 15:58:23 2003 From: jdaily at progeny.com (John Daily) Date: Wed, 03 Dec 2003 10:58:23 -0500 Subject: 7.x update service Message-ID: <20031203160441.CD8A9637C3@morimoto.progeny.com> This message may appear twice; I sent one earlier as a non-subscriber, so it's sitting in the moderation queue. Today, Progeny is announcing a subscription service for updates to Red Hat Linux 7.2 and 7.3. The goals of the Fedora Legacy Team are more ambitious than ours; we do not expect to provide updates for 8.0 or 9.0 unless there is a large demand from our customers for that service, nor do we wish to provide this service indefinitely. The objective is to provide a transition period for companies that have not yet moved away from the 7.x series. Perhaps the fact that we won't be requiring an RPM upgrade will allow the Legacy project to make that decision one way or another with the knowledge that users will have another option should they not wish to upgrade. I should point out that we don't expect to be a redistributor of your work; we are already in the distribution (and thus security backport) business. If you have any questions or concerns, feel free to drop me a note. http://transition.progeny.com/ has some marketing information. -- John R. Daily jdaily at progeny.com Director of Technology Progeny Linux Systems Master of the ephemeral epiphany From pros-n-cons at bak.rr.com Wed Dec 3 16:44:38 2003 From: pros-n-cons at bak.rr.com (Vincent) Date: Wed, 3 Dec 2003 08:44:38 -0800 Subject: Novell/progeny to take up redhat legacy services Message-ID: <20031203084438.7b48becf.pros-n-cons@bak.rr.com> http://www.linuxplanet.com/linuxplanet/newss/5137/1/ Novell/progeny will be offering pay-for support on the RHL 7.2 and 7.3 line for $5 per machine, per month or $2,500 for unlimited machines. Instead of re-inventing the wheel It's my opinion that the contributers of this list concentrate on _only_ fedora-legacy and not the RH 8.0 and 9.0 line. The users in this category are generally faster moving then the 7.2-7.3 folks who don't want to touch their servers. This would result an 'in between' user base which is apparently what the fedora-legacy project was created to accomplish. It would also benefit Redhat as to move them to the 'testing' line and not leave users in the RHL line which does the Company little good. I apologize if this has been discussed in depth, I'm new to the list and tried to read as much of the archives as I could before starting a thread. From fedoraleg_form at mm-vanecek.cc Wed Dec 3 18:32:54 2003 From: fedoraleg_form at mm-vanecek.cc (Mike Vanecek) Date: Wed, 3 Dec 2003 12:32:54 -0600 Subject: Novell/progeny to take up redhat legacy services In-Reply-To: <20031203084438.7b48becf.pros-n-cons@bak.rr.com> References: <20031203084438.7b48becf.pros-n-cons@bak.rr.com> Message-ID: <20031203182934.M17158@mm-vanecek.cc> On Wed, 3 Dec 2003 08:44:38 -0800, Vincent wrote > http://www.linuxplanet.com/linuxplanet/newss/5137/1/ > > Novell/progeny will be offering pay-for support on the RHL 7.2 and > 7.3 line for $5 per machine, per month or $2,500 for unlimited > machines. Instead of re-inventing the wheel It's my opinion that the > contributers of this list concentrate on _only_ fedora-legacy and > not the RH 8.0 and 9.0 line. I believe you may find several, including myself, that disagrees with that position. > The users in this category are > generally faster moving then the 7.2-7.3 folks who don't want to > touch their servers. Not necessarily. I'd be happy to be on RH for the next 3 or 4 years. > This would result an 'in between' user base > which is apparently what the fedora-legacy project was created to > accomplish. It would also benefit Redhat as to move them to the > 'testing' line and not leave users in the RHL line which does the > Company little good. My concern is more oriented to my needs than those of Redhat. > I apologize if this has been discussed in depth, I'm new to the list > and tried to read as much of the archives as I could before starting > a thread. Indeed, it has. From pros-n-cons at bak.rr.com Thu Dec 4 00:08:10 2003 From: pros-n-cons at bak.rr.com (Vincent) Date: Wed, 3 Dec 2003 16:08:10 -0800 Subject: Novell/progeny to take up redhat legacy services In-Reply-To: <20031203182934.M17158@mm-vanecek.cc> References: <20031203084438.7b48becf.pros-n-cons@bak.rr.com> <20031203182934.M17158@mm-vanecek.cc> Message-ID: <20031203160810.22912b8e.pros-n-cons@bak.rr.com> On Wed, 03 Dec 2003 12:32:54 -0600 Mike Vanecek wrote: > On Wed, 3 Dec 2003 08:44:38 -0800, Vincent wrote > > http://www.linuxplanet.com/linuxplanet/newss/5137/1/ > > > > Novell/progeny will be offering pay-for support on the RHL 7.2 and > > 7.3 line for $5 per machine, per month or $2,500 for unlimited > > machines. Instead of re-inventing the wheel It's my opinion that the > > contributers of this list concentrate on _only_ fedora-legacy and > > not the RH 8.0 and 9.0 line. > > I believe you may find several, including myself, that disagrees with that > position. > > > The users in this category are > > generally faster moving then the 7.2-7.3 folks who don't want to > > touch their servers. > > Not necessarily. I'd be happy to be on RH for the next 3 or 4 years. I was aware it was a blanket statement that is why I put 'generally' in there. My way of thinking is you cannot please everyone, but you could shoot for what pleases the majority, and do it better. This would not be a concern if this list had more contributers but it seems relitivly low on resources. Also, maybe you could use RH for another 4 years but you should have known when you bought/downloaded it, it surely would not be supported that long. That would be 7 yrs or so. This is moot since someone has already taken up the 7.x line. I would say the _desktop_ users out there refussing to update from 7.x are few and far between, those with an army of servers now have a pay option so why should fedora-legacy use resources on this is my point. If your company cannot afford $120 a year for updates then distribute those from scripting or an in-house up2date server, id say that business has bigger problems than updates. > > > This would result an 'in between' user base > > which is apparently what the fedora-legacy project was created to > > accomplish. It would also benefit Redhat as to move them to the > > 'testing' line and not leave users in the RHL line which does the > > Company little good. > > My concern is more oriented to my needs than those of Redhat. > > I apologize if this has been discussed in depth, I'm new to the list > > and tried to read as much of the archives as I could before starting > > a thread. > > Indeed, it has. my apoligies > > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-legacy-list From memeyou at memeyou.net Thu Dec 4 04:47:38 2003 From: memeyou at memeyou.net (Thomas Ryan Gordon Sr) Date: Wed, 03 Dec 2003 18:47:38 -1000 Subject: Novell/progeny to take up redhat legacy services In-Reply-To: <20031203160810.22912b8e.pros-n-cons@bak.rr.com> References: <20031203084438.7b48becf.pros-n-cons@bak.rr.com> <20031203182934.M17158@mm-vanecek.cc> <20031203160810.22912b8e.pros-n-cons@bak.rr.com> Message-ID: <3FCEBC6A.7090905@memeyou.net> Vincent wrote: > >so why should fedora-legacy use resources on this is my point. If your company >cannot afford $120 a year for updates then distribute those from scripting >or an in-house up2date server, id say that business has bigger problems than updates. > Let us not forget that some organizations are not built on profit and run on donations and afaik $120 will not save servers using RH8 & 9. Tom From pekkas at netcore.fi Thu Dec 4 05:42:55 2003 From: pekkas at netcore.fi (Pekka Savola) Date: Thu, 4 Dec 2003 07:42:55 +0200 (EET) Subject: Novell/progeny to take up redhat legacy services In-Reply-To: <20031203160810.22912b8e.pros-n-cons@bak.rr.com> Message-ID: On Wed, 3 Dec 2003, Vincent wrote: > If your company > cannot afford $120 a year for updates then distribute those from scripting > or an in-house up2date server, id say that business has bigger problems than updates. If you have e.g. 50 servers and 50 workstations, the bill jumps up to 12000$/yr. Not an inconsiderable amount. It'd be stupid to assume Progeny would not require some kind of agreement that disallows registering just one computer, and distributing the updates in-house. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From warren at togami.com Thu Dec 4 06:04:32 2003 From: warren at togami.com (Warren Togami) Date: Wed, 03 Dec 2003 20:04:32 -1000 Subject: Novell/progeny to take up redhat legacy services In-Reply-To: References: Message-ID: <1070517872.2521.3.camel@laptop> On Wed, 2003-12-03 at 19:42, Pekka Savola wrote: > On Wed, 3 Dec 2003, Vincent wrote: > > If your company > > cannot afford $120 a year for updates then distribute those from scripting > > or an in-house up2date server, id say that business has bigger problems than updates. > > If you have e.g. 50 servers and 50 workstations, the bill jumps up to > 12000$/yr. Not an inconsiderable amount. It'd be stupid to assume > Progeny would not require some kind of agreement that disallows > registering just one computer, and distributing the updates in-house. But then the license on the individual packages may prevent that. For example if they are GPL or LGPL, you cannot put any restrictions on re-distribution. Also they cannot legally keep the source code modifications of the security patches secret. Warren From cspencer at cait.org Thu Dec 4 06:21:04 2003 From: cspencer at cait.org (Chris Spencer) Date: Thu, 04 Dec 2003 00:21:04 -0600 Subject: Novell/progeny to take up redhat legacy services In-Reply-To: <1070517872.2521.3.camel@laptop> References: <1070517872.2521.3.camel@laptop> Message-ID: <1070518863.2035.34.camel@cnote> But do people then need to download the source rpm and have to recompile then patch. If so do they need to include the spec file? I think they don't have to. In reality this isn't a big deal at all...but it will make it just enough harder that $5/month doesn't sound so bad. Hey, maybe people really should get off the 7.X series and give fedora a shot. I really appreciate progeny offering up the update service though. Seems like a smart move. IMHO: Redhat should have continued support for RHN customers only. It would have increased their bottom line while providing an important service to their paying customers. They could have done it better...but hindsight is always 20/20. -Chris On Thu, 2003-12-04 at 00:04, Warren Togami wrote: > On Wed, 2003-12-03 at 19:42, Pekka Savola wrote: > > On Wed, 3 Dec 2003, Vincent wrote: > > > If your company > > > cannot afford $120 a year for updates then distribute those from scripting > > > or an in-house up2date server, id say that business has bigger problems than updates. > > > > If you have e.g. 50 servers and 50 workstations, the bill jumps up to > > 12000$/yr. Not an inconsiderable amount. It'd be stupid to assume > > Progeny would not require some kind of agreement that disallows > > registering just one computer, and distributing the updates in-house. > > But then the license on the individual packages may prevent that. For > example if they are GPL or LGPL, you cannot put any restrictions on > re-distribution. Also they cannot legally keep the source code > modifications of the security patches secret. > > Warren > > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-legacy-list > From warren at togami.com Thu Dec 4 06:43:01 2003 From: warren at togami.com (Warren Togami) Date: Wed, 03 Dec 2003 20:43:01 -1000 Subject: Novell/progeny to take up redhat legacy services In-Reply-To: <1070518863.2035.34.camel@cnote> References: <1070517872.2521.3.camel@laptop> <1070518863.2035.34.camel@cnote> Message-ID: <1070520180.2521.14.camel@laptop> Wait a second, it seems like people are posting thinking Legacy never planned on doing 7.x, but only 8 and 9? I was thinking that we will do everything from 7.2 and higher. Warren From mailinglist-espinoza at pulse.landshark.net Thu Dec 4 07:20:50 2003 From: mailinglist-espinoza at pulse.landshark.net (Erik Espinoza) Date: Wed, 03 Dec 2003 23:20:50 -0800 Subject: Novell/progeny to take up redhat legacy services In-Reply-To: <1070518863.2035.34.camel@cnote> References: <1070517872.2521.3.camel@laptop> <1070518863.2035.34.camel@cnote> Message-ID: <1070522450.5379.5.camel@eespinoza-lt.jpl.nasa.gov> > Hey, maybe people really should get off the 7.X series and give fedora a > shot. I'd wager that most people on the 7.x series are using it because it is a stable server platform. I'd imagine most Desktop users would either switch away from anything remotely related to RedHat, after this EOL debacle, or move to Fedora. Let's face it though, Fedora as is now will never be a server platform, nor is that the intention. From chuckw at quantumlinux.com Thu Dec 4 08:29:49 2003 From: chuckw at quantumlinux.com (Chuck Wolber) Date: Thu, 4 Dec 2003 00:29:49 -0800 (PST) Subject: Novell/progeny to take up redhat legacy services In-Reply-To: <1070520180.2521.14.camel@laptop> Message-ID: > Wait a second, it seems like people are posting thinking Legacy never > planned on doing 7.x, but only 8 and 9? I was thinking that we will do > everything from 7.2 and higher. We will do what the participants of Fedora Legacy wish to contribute. Nothing more, nothing less. Making it "official" is about as relevant as trying to yell into the wind. -Chuck -- Quantum Linux Laboratories - ACCELERATING Business with Open Technology * Education | -=^ Ad Astra Per Aspera ^=- * Integration | http://www.quantumlinux.com * Support | chuckw at quantumlinux.com "M stands for magic, mystery or matrix; according to taste." --Edward Witten From andreas at bawue.net Thu Dec 4 12:45:01 2003 From: andreas at bawue.net (Andreas Thienemann) Date: Thu, 4 Dec 2003 13:45:01 +0100 (CET) Subject: Novell/progeny to take up redhat legacy services In-Reply-To: <1070522450.5379.5.camel@eespinoza-lt.jpl.nasa.gov> Message-ID: On Wed, 3 Dec 2003, Erik Espinoza wrote: > Let's face it though, Fedora as is now will never be a server platform, > nor is that the intention. Huh? Since when? Everybody taking a casual look at fedora will see that the distribution is not different at all from the RH Linux they are used to. So why not use Fedora in the same way RHL wawqs used? Or do you meant to say that RHL was never intended to be a server platform not will it ever be one? Care to elaborate on this (false I hope) impression? bye, andreas From herrold at owlriver.com Thu Dec 4 12:54:04 2003 From: herrold at owlriver.com (R P Herrold) Date: Thu, 4 Dec 2003 07:54:04 -0500 (EST) Subject: fedora-l] Re: Novell/progeny to take up redhat legacy services In-Reply-To: References: Message-ID: On Thu, 4 Dec 2003, Andreas Thienemann wrote: > > Let's face it though, Fedora as is now will never be a server platform, > > nor is that the intention. > Huh? Since when? > Care to elaborate on this (false I hope) impression? see bottom of: http://fedora.redhat.com/about/objectives.html ----- quote --------- Non-Objectives of Fedora Core: 1. Slow rate of change. 2. Enabling commercial support, particularly Service Level Agreements. ... -------------------- I prefer my server platforms capable of being commercial supported (as I do so), particularly Service Level Agreements, and with a slow rate of change. Others thought may vary. -- Russ Herrold From whooperhsd3 at earthlink.net Thu Dec 4 13:57:05 2003 From: whooperhsd3 at earthlink.net (William Hooper) Date: Thu, 4 Dec 2003 08:57:05 -0500 (EST) Subject: Novell/progeny to take up redhat legacy services In-Reply-To: References: <20031203160810.22912b8e.pros-n-cons@bak.rr.com> Message-ID: <4158.12.29.16.103.1070546225.squirrel@12.29.16.103> Pekka Savola said: > On Wed, 3 Dec 2003, Vincent wrote: >> If your company >> cannot afford $120 a year for updates then distribute those from >> scripting >> or an in-house up2date server, id say that business has bigger problems >> than updates. > > If you have e.g. 50 servers and 50 workstations, the bill jumps up to > 12000$/yr. Not an inconsiderable amount. It'd be stupid to assume > Progeny would not require some kind of agreement that disallows > registering just one computer, and distributing the updates in-house. I'm not sure who pulled $120/year from where, but last time I checked $5/month was $60 a year. That being said Progeny (where did Novell come in?) says they are only planning this to be a "transition" service: Q: How long will Progeny offer this solution? A: Current rates are guaranteed for one year, and may continue into 2005. ^^^^^^^^ ^^^ If that is long enough for the users that would be using Fedora Legacy is another question completely. Keeping Fedora Legacy for 7.3 going would allow you to better control how long you want to keep those servers on 7.3. -- William Hooper From andreas at bawue.net Thu Dec 4 14:02:07 2003 From: andreas at bawue.net (Andreas Thienemann) Date: Thu, 4 Dec 2003 15:02:07 +0100 (CET) Subject: fedora-l] Re: Novell/progeny to take up redhat legacy services In-Reply-To: Message-ID: On Thu, 4 Dec 2003, R P Herrold wrote: > ----- quote --------- > Non-Objectives of Fedora Core: > > 1. Slow rate of change. That is exactly what you'll get by using every nth release of Fedora core and by upgrading from the fedora-legacy-project. > 2. Enabling commercial support, particularly Service Level > Agreements. > ... *cough* *cough* > I prefer my server platforms capable of being commercial > supported (as I do so), particularly Service Level Agreements, > and with a slow rate of change. Others thought may vary. Hmmm. I'm pretty sure you will be able to get service level agreements for your fedora installed sysrtems, it just depends on the price. :) But seriously: Would you consider debian as a server OS? Last time I looked the debian project did not offer SLAs or anything similar. Come to think of it, I know of exactly three companies which do have SLAs for their servers running RedHat Linux. (two of them are constantly bitching about their satellite up2date server...) So if there is no conscoius decision to make fedora a consumer OS without any security features and a a desktop centric view I do not see why this is no server OS? bye, adnreas From sschaefer at acm.org Thu Dec 4 15:56:07 2003 From: sschaefer at acm.org (Stephen P. Schaefer) Date: Thu, 04 Dec 2003 10:56:07 -0500 Subject: Novell/progeny to take up redhat legacy services Message-ID: <3FCF5917.7020806@acm.org> I can't speak for everyone, but I can describe my own circumstances: we run 3rd party, closed source chip design software on RH7.3 because it doesn't work on RH8.0 or later. For us, the only difference between a server and workstation is whether the X server is running. The Progeny service is a perfect fit for us: affordable and convenient. We've never before had to pay for Red Hat services. We want the security updates, and we were seriously contemplating compiling them ourselves, after testing the 3rd party software under ES2.1. Where that 3rd party software runs completely determines what distribution we run. We stay legal. Because we don't violate licenses or contracts, subscribing one of our boxes at $349 for ES2.1 and distributing to the remainder isn't an option. When you multiply that $349 by (60 today, who knows next week?), we could cover the salary of a parttime sysadmin to download the SRPMs and compile them. At $60 a year from Progeny, we can find something else for that sysadmin to do - and we can skip testing the 3rd party software on ES2.1. From lowen at pari.edu Thu Dec 4 19:35:19 2003 From: lowen at pari.edu (Lamar Owen) Date: Thu, 4 Dec 2003 14:35:19 -0500 Subject: Novell/progeny to take up redhat legacy services In-Reply-To: <1070517872.2521.3.camel@laptop> References: <1070517872.2521.3.camel@laptop> Message-ID: <200312041435.19353.lowen@pari.edu> On Thursday 04 December 2003 01:04 am, Warren Togami wrote: > But then the license on the individual packages may prevent that. For > example if they are GPL or LGPL, you cannot put any restrictions on > re-distribution. While the individual package license may prevent restrictions on its own redistribution, GPL for one nowhere prevents a subscription service from have a contract that allows for termination of the subscription service if the terms of service are breached. It has nothing to do with the software's distribution license. The sources may very well be publicly posted to be in compliance with the package license; but the subscription is for a QA'd package building and distribution mechanism; break the contract there, and you lose the rights to use the service, but you do not lose the rights to the packages you have (or that you wish to download in SRPM form and rebuild yourself). Just to the convenient prebuilt, secure, trusted binary package delivery service. But I am definitely not a lawyer. In programmer-speak, RHN-subscription!=the packages delivered by RHN (to use the obvious example). -- Lamar Owen Director of Information Technology Pisgah Astronomical Research Institute 1 PARI Drive Rosman, NC 28772 (828)862-5554 www.pari.edu From jkeating at j2solutions.net Thu Dec 4 19:41:20 2003 From: jkeating at j2solutions.net (Jesse Keating) Date: Thu, 4 Dec 2003 11:41:20 -0800 Subject: So much for educational discounts... Message-ID: <200312041141.25216.jkeating@j2solutions.net> http://www.redhat.com/solutions/industries/education/site With these prices, some larger institutions can get really spendy. The originally thought $2500 for a site wide WS license is for personally owned/used systems only, not institution owned. For those you have to pay. $25/WS/year for fixed, or $7/FTE/year for unlimited. See details on that page for how to calculate "FTE". If anybody on the list is involved with an educational institution (Higher education. K-12 doesn't get these "discounts"), could you please do the math and let us know what it would cost for a full AS/WS site license? It's ($2500 + ($14 x FTE)) per year. I'd be really interested in where the prices come out. -- Jesse Keating RHCE MCSE (geek.j2solutions.net) Fedora Legacy Team (www.fedora.us/wiki/FedoraLegacy) Mondo DevTeam (www.mondorescue.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From jkeating at j2solutions.net Thu Dec 4 19:45:33 2003 From: jkeating at j2solutions.net (Jesse Keating) Date: Thu, 4 Dec 2003 11:45:33 -0800 Subject: So much for educational discounts... In-Reply-To: <200312041141.25216.jkeating@j2solutions.net> References: <200312041141.25216.jkeating@j2solutions.net> Message-ID: <200312041145.33246.jkeating@j2solutions.net> On Thursday 04 December 2003 11:41, Jesse Keating wrote: > (Higher education. K-12 doesn't get these "discounts") Whoops, strike that. Students of K-12 aren't eligible, but the institution itself is. -- Jesse Keating RHCE MCSE (geek.j2solutions.net) Fedora Legacy Team (www.fedora.us/wiki/FedoraLegacy) Mondo DevTeam (www.mondorescue.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From warren at togami.com Thu Dec 4 21:11:23 2003 From: warren at togami.com (Warren Togami) Date: Thu, 04 Dec 2003 11:11:23 -1000 Subject: fedora-l] Re: Novell/progeny to take up redhat legacy services In-Reply-To: References: Message-ID: <3FCFA2FB.1080403@togami.com> Andreas Thienemann wrote: > But seriously: Would you consider debian as a server OS? Last time I > looked the debian project did not offer SLAs or anything similar. > Come to think of it, I know of exactly three companies which do have SLAs > for their servers running RedHat Linux. (two of them are constantly > bitching about their satellite up2date server...) > > So if there is no conscoius decision to make fedora a consumer OS without > any security features and a a desktop centric view I do not see why this > is no server OS? > Some would consider Debian's "slow rate of change" as enabling the potential for Service Level Agreements for any number of service providers who wish to render that service. It is admittedly more difficult to be able to service multiple versions of Fedora Core that are released every 6-ish months, but certainly doable since the server side stuff does not change *that* much. That would be a business decision of the provider to make. Warren From smoogen at lanl.gov Thu Dec 4 21:31:44 2003 From: smoogen at lanl.gov (Stephen Smoogen) Date: Thu, 04 Dec 2003 14:31:44 -0700 Subject: fedora-l] Re: Novell/progeny to take up redhat legacy services In-Reply-To: <3FCFA2FB.1080403@togami.com> References: <3FCFA2FB.1080403@togami.com> Message-ID: <1070573504.5764.48.camel@smoogen1.lanl.gov> I was wondering if we could focus on methods and action more than other peoples press releases and counting angels on the head of a pin... In 27 days, action is going to be needed, and we dont even have a press release, or MORE important some build machines, a build process, a QA process, a push process, and mirroring process. We could start testing the waters by building rsync RPMS, testing them, signing them, and getting them out the door on at least one mirror. -- Stephen John Smoogen smoogen at lanl.gov Los Alamos National Lab CCN-5 Sched 5/40 PH: 4-0645 Ta-03 SM-1498 MailStop B255 DP 10S Los Alamos, NM 87545 -- So shines a good deed in a weary world. = Willy Wonka -- From warren at togami.com Thu Dec 4 21:58:08 2003 From: warren at togami.com (Warren Togami) Date: Thu, 04 Dec 2003 11:58:08 -1000 Subject: fedora-l] Re: Novell/progeny to take up redhat legacy services In-Reply-To: <1070573504.5764.48.camel@smoogen1.lanl.gov> References: <3FCFA2FB.1080403@togami.com> <1070573504.5764.48.camel@smoogen1.lanl.gov> Message-ID: <3FCFADF0.5000108@togami.com> Stephen Smoogen wrote: > I was wondering if we could focus on methods and action more than other > peoples press releases and counting angels on the head of a pin... > > In 27 days, action is going to be needed, and we dont even have a press > release, or MORE important some build machines, a build process, a QA > process, a push process, and mirroring process. > Build server: What is the status Jesse? For expediency, may I suggest the existing fedora.us QA queue and method for package submission & approval. Only difference would be the package naming which we still have to discuss. fedora.us can do builds easily if Pogo Linux donated dedicated server is not ready by that time. > We could start testing the waters by building rsync RPMS, testing them, > signing them, and getting them out the door on at least one mirror. > Good idea. Please submit to fedora.us. Warren From skvidal at phy.duke.edu Thu Dec 4 22:23:33 2003 From: skvidal at phy.duke.edu (seth vidal) Date: 04 Dec 2003 17:23:33 -0500 Subject: fedora-l] Re: Novell/progeny to take up redhat legacy services In-Reply-To: <1070573504.5764.48.camel@smoogen1.lanl.gov> References: <3FCFA2FB.1080403@togami.com> <1070573504.5764.48.camel@smoogen1.lanl.gov> Message-ID: <1070576613.8472.25.camel@opus> > We could start testing the waters by building rsync RPMS, testing them, > signing them, and getting them out the door on at least one mirror. I built rsync for 7.X, 9 and FC1 last night but the ones from red hat just came out. If it's any use the one's I built are identical to red hat's. I should have posted them but I kinda wanted to go to bed. -sv From chuckw at quantumlinux.com Fri Dec 5 08:00:51 2003 From: chuckw at quantumlinux.com (Chuck Wolber) Date: Fri, 5 Dec 2003 00:00:51 -0800 (PST) Subject: Novell/progeny to take up redhat legacy services In-Reply-To: <3FCF5917.7020806@acm.org> Message-ID: > We stay legal. Legal shmegal!! I think you've been brainwashed by the proprietary software storm troopers. The software is GPL'd, Redhat cannot take your rights to redistribute away from you. Once you have *1* copy of the code, you can do whatever you want with it and there's not a darn thing RedHat can do to you. *REMEMBER* The GPL was created *SPECIFICALLY* to prevent anyone from taking someone's rights away. If the original developer wrote the code under the GPL, then you get the same rights RedHat got. > Because we don't violate licenses or contracts, subscribing one of our > boxes at $349 for ES2.1 and distributing to the remainder isn't an > option. Huh? How's that. Did RedHat suddenly find a way to get around the GPL? If so, please enlighten me... The fact of the matter is that you have the same rights to the code that RedHat has. That's the beauty of the GPL. You have to remember that in buying RHEL 2.1/3.0/etc you are paying for a service, *not the code*. You are paying for the update service which then supports all of the stability work that RedHat puts into the code. It is simply not legal for RedHat to hold your rights to this update service over your head. If you pay for it, you should get it. If you choose to redistribute the fruits of this service, you have every right to do so (only the GPL'd parts that is(*)). Knowing all of that, if you still choose to pay RedHat the full ticket price, I commend you! RedHat deserves every penny of it. Just make sure that you are paying for the right reasons. -Chuck (*) RedHat has publically stated more than once that *ALL* of their code has been and always will be open sourced ( specifically GPL'd). -- Quantum Linux Laboratories - ACCELERATING Business with Open Technology * Education | -=^ Ad Astra Per Aspera ^=- * Integration | http://www.quantumlinux.com * Support | chuckw at quantumlinux.com "M stands for magic, mystery or matrix; according to taste." --Edward Witten From chuckw at quantumlinux.com Fri Dec 5 08:07:51 2003 From: chuckw at quantumlinux.com (Chuck Wolber) Date: Fri, 5 Dec 2003 00:07:51 -0800 (PST) Subject: Novell/progeny to take up redhat legacy services In-Reply-To: <200312041435.19353.lowen@pari.edu> Message-ID: > The sources may very well be publicly posted to be in compliance with > the package license; but the subscription is for a QA'd package building > and distribution mechanism; break the contract there, and you lose the > rights to use the service, but you do not lose the rights to the > packages you have (or that you wish to download in SRPM form and rebuild > yourself). Just to the convenient prebuilt, secure, trusted binary > package delivery service. But I am definitely not a lawyer. Rebuilding the SRPMS them is as simple as issuing the standard rpmbuild commands. Once you do that, you'll have the exact same RPMS that you pay the service for. This is not rocket science. I hope people are starting to realize what they're paying for here. It's a service that supports the work that RedHat is doing. The fruits of that service (the packages) can be redistributed any way you wish once you have them (assuming they're GPL'd). "Pay for the service, not the software!" If you choose to pay the full ticket price, I commend you!!!! RedHat deserves every penny. Just please ensure that you are aware of what you are paying for and what RedHat can and cannot do. -Chuck -- Quantum Linux Laboratories - ACCELERATING Business with Open Technology * Education | -=^ Ad Astra Per Aspera ^=- * Integration | http://www.quantumlinux.com * Support | chuckw at quantumlinux.com "M stands for magic, mystery or matrix; according to taste." --Edward Witten From chuckw at quantumlinux.com Fri Dec 5 08:18:01 2003 From: chuckw at quantumlinux.com (Chuck Wolber) Date: Fri, 5 Dec 2003 00:18:01 -0800 (PST) Subject: fedora-l] Re: Novell/progeny to take up redhat legacy services In-Reply-To: <1070573504.5764.48.camel@smoogen1.lanl.gov> Message-ID: > In 27 days, action is going to be needed, and we dont even have a press > release, or MORE important some build machines, a build process, a QA > process, a push process, and mirroring process. Jesse, what's the status of the build server? Are we ready to go? -Chuck -- Quantum Linux Laboratories - ACCELERATING Business with Open Technology * Education | -=^ Ad Astra Per Aspera ^=- * Integration | http://www.quantumlinux.com * Support | chuckw at quantumlinux.com "M stands for magic, mystery or matrix; according to taste." --Edward Witten From ms-nospam-0306 at arcor.de Fri Dec 5 12:01:19 2003 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Fri, 5 Dec 2003 13:01:19 +0100 Subject: Novell/progeny to take up redhat legacy services In-Reply-To: References: <3FCF5917.7020806@acm.org> Message-ID: <20031205130119.7ff62548.ms-nospam-0306@arcor.de> On Fri, 5 Dec 2003 00:00:51 -0800 (PST), Chuck Wolber wrote: > > We stay legal. > > Legal shmegal!! I think you've been brainwashed by the proprietary > software storm troopers. The software is GPL'd, Redhat cannot take your > rights to redistribute away from you. Once you have *1* copy of the code, > you can do whatever you want with it and there's not a darn thing RedHat > can do to you. > > *REMEMBER* The GPL was created *SPECIFICALLY* to prevent anyone from > taking someone's rights away. If the original developer wrote the code > under the GPL, then you get the same rights RedHat got. > > > > Because we don't violate licenses or contracts, subscribing one of our > > boxes at $349 for ES2.1 and distributing to the remainder isn't an > > option. > > Huh? How's that. Did RedHat suddenly find a way to get around the GPL? If > so, please enlighten me... Because it would hurt Red Hat's business model, and it would be short sighted to do so. Why would anyone pay for the subscription and then redistribute the software or errata to others freely? Also, the GPL does not override trademark laws. You may need to modify the software appropriately before you could redistribute it. > The fact of the matter is that you have the same rights to the code that > RedHat has. That's the beauty of the GPL. The GPL does not override service licence agreements either. Meaning, that while you could copy the software freely, you are not permitted to install and run the product on more than the purchased number of licenced machines. Doing so would be in violation of your SLA. > You have to remember that in buying RHEL 2.1/3.0/etc you are paying for a > service, *not the code*. You are paying for the update service which then > supports all of the stability work that RedHat puts into the code. You also pay for R&D, QA and them assembling all the stuff and maintaining it for a long period of time. -- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at j2solutions.net Fri Dec 5 15:57:30 2003 From: jkeating at j2solutions.net (Jesse Keating) Date: Fri, 5 Dec 2003 07:57:30 -0800 Subject: fedora-l] Re: Novell/progeny to take up redhat legacy services In-Reply-To: References: Message-ID: <200312050757.31175.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday 05 December 2003 00:18, Chuck Wolber wrote: > Jesse, what's the status of the build server? Are we ready to go? Working on that... there has been some foot dragging, but I've lit the appropriate fires... - -- Jesse Keating RHCE MCSE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedora.us/wiki/FedoraLegacy) Mondo DevTeam (www.mondorescue.org) GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/0Krq4v2HLvE71NURAsBwAJwNx8X0shkj8t1C/lgHI2C7Mt9OgACeJqyR 7a1FA7m4cwrG11dFBPjhzOI= =MHbX -----END PGP SIGNATURE----- From maxfield at one.ctelcom.net Fri Dec 5 16:38:07 2003 From: maxfield at one.ctelcom.net (Wade Maxfield) Date: Fri, 5 Dec 2003 10:38:07 -0600 (CST) Subject: build In-Reply-To: <200312050757.31175.jkeating@j2solutions.net> References: <200312050757.31175.jkeating@j2solutions.net> Message-ID: I'm new to the list. I've muddled through a RedHat build on X windows to write a custom driver for a touch screen to work, modified from another driver. Rather cryptic understanding what they mean sometimes in the source code, but the examples made things clear with time and mistakes. However, I've never understood the RedHat build model. I get the kernel source and there are dozens of patch files. HUH? Do I need them? I gave up and downloaded the kernel from kernel.org and built. No problems with the build, but the RedHat Tweaks were Gone. I eventually got something I could use, but this is not my day job. Is there a HOWTO anywhere that is RedHat specific that says if you do (1), (2), (3), etc. you will get the original binary? I need this to be for a dummy. I've applied one source code patch about two years ago and it was black magic at that time and appeared to work. I was able to look at the source code files and prove the patch made it in, but I can't remember what I did to this day. Some of the things a dummy has a problem with are (1) where do the files go, (2) how do I get the files out of the source code RPM once the source code RPM has installed the files? Let me explain. I've seen source RPM's for RedHat which dump other files in a directory, and they had to be untar'd to get the source code files out. At that point, I was unsure what directory Redhat built in, and could not get a clean RedHat specific build from it. I may have, but I could not prove it at that time. At that point I gave up and depended upon RedHat to do the updates. Now, I'm fairly stuck and need help. As of December 31, 7.3 and 8.0 are history. This is very frightening, as I have several servers on the internet. Is there perhaps an ISO of the Redhat Build Machine for any of the legacy versions? If I could put a RedHat Build Machine on a computer, I could then make a patch and get something out without a lot of uncertainty on my part as to whether or not it was a RedHat compatible program. Any thoughts would be appreciated. I'll even take a flame or two at this point. thanks, wade From cra at WPI.EDU Fri Dec 5 17:09:49 2003 From: cra at WPI.EDU (Charles R. Anderson) Date: Fri, 5 Dec 2003 12:09:49 -0500 Subject: build In-Reply-To: ; from maxfield@one.ctelcom.net on Fri, Dec 05, 2003 at 10:38:07AM -0600 References: <200312050757.31175.jkeating@j2solutions.net> Message-ID: <20031205120949.B10663@angus.ind.WPI.EDU> On Fri, Dec 05, 2003 at 10:38:07AM -0600, Wade Maxfield wrote: > However, I've never understood the RedHat build model. I get the kernel > source and there are dozens of patch files. HUH? Do I need them? Only if you want the bug and security fixes, feature enhancements, backports, and additional drivers they provide. RPM source packages were designed to ship the original, unmodified source code, along with patches needed or desired for the local build. > I gave up and downloaded the kernel from kernel.org and built. No > problems with the build, but the RedHat Tweaks were Gone. I eventually > got something I could use, but this is not my day job. The kernel is one of the hardest RPM packages to learn to modify. I suggest starting out with easier fish. Red Hat provides a binary package containing the fully Red Hat-patched kernel source code that can be built in the normal way, outside of RPM packaging. It is called kernel-source-x.x.x.i386.rpm, and installs a kernel source tree in /usr/src/linux-2.4. There are steps that need to be followed, however, to be sure this tree builds correctly: http://www.redhat.com/docs/manuals/linux/RHL-9-Manual/custom-guide/ch-custom-kernel.html > Is there a HOWTO anywhere that is RedHat specific that says if you do > (1), (2), (3), etc. you will get the original binary? www.rpm.org would be a good start to look for documentation. Reproducing a build from a src.rpm to get the original binaries is usually as simple as: rpmbuild --rebuild file.src.rpm > I need this to be for a dummy. I've applied one source code patch about > two years ago and it was black magic at that time and appeared to work. I > was able to look at the source code files and prove the patch made it in, > but I can't remember what I did to this day. Patching, building, and packaging requires some knowledge of programming, unfortunately. > Some of the things a dummy has a problem with are (1) where do the files > go, (2) how do I get the files out of the source code RPM once the source > code RPM has installed the files? Let me explain. When you do "rpm -i file.src.rpm" this is where things end up by default: /usr/src/redhat/SOURCES - the source code tar files, patches, etc. /usr/src/redhat/SPECS - the spec file (control script) that gives the steps for how to unpack, patch, build, and package the built files into an rpm package. You can list the contents of a src.rpm to see what these tar, patch, and spec files are named: rpm -qpvl file.src.rpm > I've seen source RPM's for RedHat which dump other files in a > directory, and they had to be untar'd to get the source code files out. > At that point, I was unsure what directory Redhat built in, and could not > get a clean RedHat specific build from it. I may have, but I could not > prove it at that time. If you instead "rpm -i file.src.rpm", you can rebuild the binaries by doing: rpmbuild -bb file.spec or build BOTH the binary and source rpm packages by doing: rpmbuild -ba file.spec from the SPECS directory. This executes the steps in the spec file, which unpack (%prep), build (%build), install to a temporary directory called a buildroot (%install), and package the files (%files) into the final binary rpm package(s). The sections of a spec file are simply shell script fragments, optionally using RPM macros. In either case, the build happens in /usr/src/redhat/BUILD, and the resulting packaged files end up in /usr/src/redhat/RPMS. There are ways, BTW, to change these default locations so you can build as non-root in your home directory, for example. From rostetter at mail.utexas.edu Fri Dec 5 19:08:26 2003 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Fri, 5 Dec 2003 13:08:26 -0600 Subject: Novell/progeny to take up redhat legacy services In-Reply-To: References: Message-ID: <20031205130826.kdicggoc400k48c4@mail.ph.utexas.edu> Quoting Chuck Wolber : > > We stay legal. > > Legal shmegal!! I think you've been brainwashed by the proprietary > software storm troopers. No, instead you were brainwashed by the everything in life is free and legal storm troopers. > The software is GPL'd, Not all of it. > Redhat cannot take your > rights to redistribute away from you. Once you have *1* copy of the code, > you can do whatever you want with it and there's not a darn thing RedHat > can do to you. This only applies to the source code that is open source. > *REMEMBER* The GPL was created *SPECIFICALLY* to prevent anyone from > taking someone's rights away. Including Red Hat's rights. > If the original developer wrote the code > under the GPL, then you get the same rights RedHat got. To the sources at least. > Huh? How's that. Did RedHat suddenly find a way to get around the GPL? If > so, please enlighten me... No, but it seems you *think* you found a way around the law. > The fact of the matter is that you have the same rights to the code that > RedHat has. That's the beauty of the GPL. For oepn source code in source form at least. > You have to remember that in buying RHEL 2.1/3.0/etc you are paying for a > service, *not the code*. No, you are indeed paying for the code along with the service. And any reasonable media costs, etc. But you are not paying for the source code. > Knowing all of that, if you still choose to pay RedHat the full ticket > price, I commend you! RedHat deserves every penny of it. Just make sure > that you are paying for the right reasons. And please make sure you are not acting illegally out of a misconception of what GPL covers. > -Chuck > > (*) RedHat has publically stated more than once that *ALL* of their code > has been and always will be open sourced ( specifically GPL'd). No, they have not. In fact, they have stated the opposite. Not all of it is GPL'd. And some of it is subject to copyright and trademark law. What they stated was that they will always provide access to all their source code. They never said it was all open sourced or GPL'd. -- Eric Rostetter From chuckw at quantumlinux.com Fri Dec 5 20:03:58 2003 From: chuckw at quantumlinux.com (ChuckW) Date: Fri, 5 Dec 2003 12:03:58 -0800 (PST) Subject: Novell/progeny to take up redhat legacy services In-Reply-To: <20031205130826.kdicggoc400k48c4@mail.ph.utexas.edu> References: <20031205130826.kdicggoc400k48c4@mail.ph.utexas.edu> Message-ID: <37464.169.204.208.61.1070654638.squirrel@www.quantumlinux.com> >> Legal shmegal!! I think you've been brainwashed by the proprietary >> software storm troopers. > > No, instead you were brainwashed by the everything in life is free and > legal storm troopers. I never said time was free. Just the opposite. Perhaps you have been selectively reading the posts here? I've said that before... >> The software is GPL'd, > > Not all of it. Where "the" is defined as all of the GPL'd software (which I said below). >> Redhat cannot take your rights to redistribute away from you. Once you >> have *1* copy of the code, >> you can do whatever you want with it and there's not a darn thing RedHat >> can do to you. > > This only applies to the source code that is open source. I agree, which I said below. It's one short command to turn the source code into the same RPMS that RedHat delivers with the service. >> Huh? How's that. Did RedHat suddenly find a way to get around the GPL? >> If so, please enlighten me... > > No, but it seems you *think* you found a way around the law. How's that? My concern is that people are seeing RedHat software in the same light as Microsoft software. RedHat software is not what they're selling. They're selling *SERVICES*. >> You have to remember that in buying RHEL 2.1/3.0/etc you are paying for >> a service, *not the code*. > > No, you are indeed paying for the code along with the service. And any > reasonable media costs, etc. But you are not paying for the source code. Yes, a reasonable media cost. But even RedHat publically states that what you are paying for is the service (and by extension all of the incredible work it supports in the backend). >> Knowing all of that, if you still choose to pay RedHat the full ticket >> price, I commend you! RedHat deserves every penny of it. Just make sure >> that you are paying for the right reasons. > > And please make sure you are not acting illegally out of a misconception > of what GPL covers. I believe you failed to make that point. >> (*) RedHat has publically stated more than once that *ALL* of their code >> has been and always will be open sourced ( specifically GPL'd). > > No, they have not. In fact, they have stated the opposite. Not all of it > is GPL'd. And some of it is subject to copyright and trademark law. Perhaps you have been living in a hole? They have said this time and time again. What you are probably confusing is that they have also publically stated that they have no qualms about *INCLUDING* closed source software in their distribution. They themselves respect the force of the OSS community and will make all of their *OWN* code GPL'd. Please also note that this has nothing to do with their logos and trademarks. > What they stated was that they will always provide access to all their > source code. They never said it was all open sourced or GPL'd. I disagree. As a side note, I can't help but feel like you selectively read this post and made your judgement after reading the first line. Am I wrong? -Chuck From maxfield at one.ctelcom.net Fri Dec 5 20:05:19 2003 From: maxfield at one.ctelcom.net (Wade Maxfield) Date: Fri, 5 Dec 2003 14:05:19 -0600 (CST) Subject: build In-Reply-To: <20031205120949.B10663@angus.ind.WPI.EDU> References: <200312050757.31175.jkeating@j2solutions.net> <20031205120949.B10663@angus.ind.WPI.EDU> Message-ID: On Fri, 5 Dec 2003, Charles R. Anderson wrote: > > Reproducing a build from a src.rpm to get the original binaries is > usually as simple as: > > rpmbuild --rebuild file.src.rpm > Ok. I picked two packages at random: (as root) rpmbuild --rebuild lynx-2.8.5-7.1.src.rpm rpmbuild: relocation error: rpmbuild: undefined symbol: freeSpecVec rpmbuild --rebuild zlib-1.1.4-8.8x.src.rpm rpmbuild: relocation error: rpmbuild: undefined symbol: freeSpecVec So, obviously, either not all of the RPM package builders don't follow the rules, or I'm missing a package required. So far, I've batted 1000% failure in the past also, so I obviously don't understand this command line. > > I need this to be for a dummy. I've applied one source code patch about > > two years ago and it was black magic at that time and appeared to work. I > > was able to look at the source code files and prove the patch made it in, > > but I can't remember what I did to this day. > > Patching, building, and packaging requires some knowledge of > programming, unfortunately. > I have a smidgen. I just don't understand the RedHat Way. Also, since I do my own stuff under a deadline all the time, I don't do patching a lot. Just to let you know where I come from, the following. However, I'm not anything spectacular. I'm just a regular guy. I have ported the small c compiler to the 6800, written cooperative multitasking systems, written X windows drivers, written a driver for 2.0.x kernel, and done other programming in basic and fortran and C++ and perl and php and assembly in 6800, 68000, 8080, 8086, x86, COP400, and a very little PPC assembly (yuk!). I currently do real time systems and have produced 2 embedded Linux products for a company I consult at for their internal use in gathering data from sensors. However, that doesn't mean I can't be stupid as a rock sometimes. Some rocks are smarter than I am upon occasion. They at least lay there and be quiet when they should. > > Some of the things a dummy has a problem with are (1) where do the files > > go, (2) how do I get the files out of the source code RPM once the source > > code RPM has installed the files? Let me explain. > > When you do "rpm -i file.src.rpm" this is where things end up by > default: > > /usr/src/redhat/SOURCES - the source code tar files, patches, etc. > > /usr/src/redhat/SPECS - the spec file (control script) that gives the > steps for how to unpack, patch, build, and package the built files > into an rpm package. > > You can list the contents of a src.rpm to see what these tar, patch, > and spec files are named: > > rpm -qpvl file.src.rpm > Great stuff! > > I've seen source RPM's for RedHat which dump other files in a > > directory, and they had to be untar'd to get the source code files out. > > At that point, I was unsure what directory Redhat built in, and could not > > get a clean RedHat specific build from it. I may have, but I could not > > prove it at that time. > > If you instead "rpm -i file.src.rpm", you can rebuild the binaries by > doing: > > rpmbuild -bb file.spec > > or build BOTH the binary and source rpm packages by doing: > > rpmbuild -ba file.spec > > from the SPECS directory. This executes the steps in the spec file, > which unpack (%prep), build (%build), install to a temporary directory > called a buildroot (%install), and package the files (%files) into the > final binary rpm package(s). The sections of a spec file are simply > shell script fragments, optionally using RPM macros. > > In either case, the build happens in /usr/src/redhat/BUILD, and the > resulting packaged files end up in /usr/src/redhat/RPMS. > > There are ways, BTW, to change these default locations so you can > build as non-root in your home directory, for example. > > rpm -i lynx-2.8.507.1.src.rpm cd /usr/src/redhat/SPECS rpmbuild -bb lynx.spec rpmbuild: relocation error: rpmbuild: undefined symbol: freeSpecVec here is my rpm list for redhat 8.0. Note that the rpm was upgraded because of the hang problem that the standard 4.x rpm from redhat has under 8.0. With 4.1.1, the problem does not occur. [root at rh80 SPECS]# rpm -qa | grep rpm rpmdb-redhat-8.0-0.20020910 rpm-python-4.1.1-1.8x rpm2html-1.7-8 librpm404-devel-4.0.4-8x.27 redhat-rpm-config-8.0-1 rpm-4.1.1-1.8x rpm404-python-4.0.4-8x.27 rpm-build-4.1-1.06 librpm404-4.0.4-8x.27 THANKS for the help! I'm further down the road. wade From chuckw at quantumlinux.com Fri Dec 5 20:25:18 2003 From: chuckw at quantumlinux.com (ChuckW) Date: Fri, 5 Dec 2003 12:25:18 -0800 (PST) Subject: Novell/progeny to take up redhat legacy services In-Reply-To: <37464.169.204.208.61.1070654638.squirrel@www.quantumlinux.com> References: <20031205130826.kdicggoc400k48c4@mail.ph.utexas.edu> <37464.169.204.208.61.1070654638.squirrel@www.quantumlinux.com> Message-ID: <38011.169.204.208.61.1070655918.squirrel@www.quantumlinux.com> Upon re-reading, I realized my previous post contained an inaccurate statement. Please allow me to correct myself: >> No, they have not. In fact, they have stated the opposite. Not all of >> it is GPL'd. And some of it is subject to copyright and trademark law. > > Perhaps you have been living in a hole? They have said this time and time > again. What you are probably confusing is that they have also publically > stated that they have no qualms about *INCLUDING* closed source software > in their distribution. They themselves respect the force of the OSS > community and will make all of their *OWN* code GPL'd. Please also note > that this has nothing to do with their logos and trademarks. I shouldn't have said RedHat will GPL all of their code. I have no documentation to this effect. I believe Eric was correct when he originally stated that RedHat has always pledged to make the source code available, but that RedHat has never made an exclusive commitment to any given license when it comes to code developed in-house. Sorry for that. -Chuck From ms-nospam-0306 at arcor.de Fri Dec 5 20:33:53 2003 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Fri, 5 Dec 2003 21:33:53 +0100 Subject: build In-Reply-To: References: <200312050757.31175.jkeating@j2solutions.net> <20031205120949.B10663@angus.ind.WPI.EDU> Message-ID: <20031205213353.448d7e7f.ms-nospam-0306@arcor.de> On Fri, 5 Dec 2003 14:05:19 -0600 (CST), Wade Maxfield wrote: > rpmbuild: relocation error: rpmbuild: undefined symbol: freeSpecVec > > > > > here is my rpm list for redhat 8.0. Note that the rpm was upgraded > because of the hang problem that the standard 4.x rpm from redhat has > under 8.0. With 4.1.1, the problem does not occur. > > [root at rh80 SPECS]# rpm -qa | grep rpm > > rpmdb-redhat-8.0-0.20020910 > rpm-python-4.1.1-1.8x > rpm2html-1.7-8 > librpm404-devel-4.0.4-8x.27 > redhat-rpm-config-8.0-1 > rpm-4.1.1-1.8x > rpm404-python-4.0.4-8x.27 > rpm-build-4.1-1.06 This should be rpm-build-4.1.1-1.8x, so it matches your version of RPM. -- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From maxfield at one.ctelcom.net Fri Dec 5 21:00:35 2003 From: maxfield at one.ctelcom.net (Wade Maxfield) Date: Fri, 5 Dec 2003 15:00:35 -0600 (CST) Subject: build In-Reply-To: <20031205213353.448d7e7f.ms-nospam-0306@arcor.de> References: <200312050757.31175.jkeating@j2solutions.net> <20031205120949.B10663@angus.ind.WPI.EDU> <20031205213353.448d7e7f.ms-nospam-0306@arcor.de> Message-ID: On Fri, 5 Dec 2003, Michael Schwendt wrote: > Date: Fri, 5 Dec 2003 21:33:53 +0100 > From: Michael Schwendt > On Fri, 5 Dec 2003 14:05:19 -0600 (CST), Wade Maxfield wrote: > > > rpmbuild: relocation error: rpmbuild: undefined symbol: freeSpecVec > > > > > > here is my rpm list for redhat 8.0. Note that the rpm was upgraded > > because of the hang problem that the standard 4.x rpm from redhat has > > under 8.0. With 4.1.1, the problem does not occur. > > > > [root at rh80 SPECS]# rpm -qa | grep rpm > > > > rpmdb-redhat-8.0-0.20020910 > > rpm-python-4.1.1-1.8x > > rpm2html-1.7-8 > > librpm404-devel-4.0.4-8x.27 > > redhat-rpm-config-8.0-1 > > rpm-4.1.1-1.8x > > rpm404-python-4.0.4-8x.27 > > rpm-build-4.1-1.06 > > This should be rpm-build-4.1.1-1.8x, so it matches your version of RPM. Excellent! DOH! Yes, that was it. I had never heard of rpmbuild before, it appears to be a neat tool. THANKS! wade From mailinglist-espinoza at pulse.landshark.net Fri Dec 5 21:06:36 2003 From: mailinglist-espinoza at pulse.landshark.net (Erik A. Espinoza) Date: Fri, 05 Dec 2003 13:06:36 -0800 Subject: Novell/progeny to take up redhat legacy services In-Reply-To: <20031205130119.7ff62548.ms-nospam-0306@arcor.de> References: <3FCF5917.7020806@acm.org> <20031205130119.7ff62548.ms-nospam-0306@arcor.de> Message-ID: <1070658396.14633.4.camel@totoro.jpl.nasa.gov> > The GPL does not override service licence agreements either. Meaning, that > while you could copy the software freely, you are not permitted to install > and run the product on more than the purchased number of licenced > machines. Doing so would be in violation of your SLA. GPL Section 4 4. You may not copy, modify, sublicense, or distribute the Program except as expressly provided under this License. Any attempt otherwise to copy, modify, sublicense or distribute the Program is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance. Wouldn't the SLA be in violation of my rights to the code? From smoogen at lanl.gov Fri Dec 5 21:18:26 2003 From: smoogen at lanl.gov (Stephen Smoogen) Date: Fri, 05 Dec 2003 14:18:26 -0700 Subject: Novell/progeny to take up redhat legacy services In-Reply-To: <1070658396.14633.4.camel@totoro.jpl.nasa.gov> References: <3FCF5917.7020806@acm.org> <20031205130119.7ff62548.ms-nospam-0306@arcor.de> <1070658396.14633.4.camel@totoro.jpl.nasa.gov> Message-ID: <1070659106.7471.27.camel@smoogen1.lanl.gov> How about getting a lawyer versus a bunch of wags on a mailing list. You might as well talk radio as get good advice here on legal issues. On Fri, 2003-12-05 at 14:06, Erik A. Espinoza wrote: > > The GPL does not override service licence agreements either. Meaning, that > > while you could copy the software freely, you are not permitted to install > > and run the product on more than the purchased number of licenced > > machines. Doing so would be in violation of your SLA. > > > GPL Section 4 > 4. You may not copy, modify, sublicense, or distribute the Program > except as expressly provided under this License. Any attempt > otherwise to copy, modify, sublicense or distribute the Program is > void, and will automatically terminate your rights under this License. > However, parties who have received copies, or rights, from you under > this License will not have their licenses terminated so long as such > parties remain in full compliance. > > Wouldn't the SLA be in violation of my rights to the code? > > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-legacy-list -- Stephen John Smoogen smoogen at lanl.gov Los Alamos National Lab CCN-5 Sched 5/40 PH: 4-0645 Ta-03 SM-1498 MailStop B255 DP 10S Los Alamos, NM 87545 -- So shines a good deed in a weary world. = Willy Wonka -- From whooperhsd3 at earthlink.net Fri Dec 5 21:19:24 2003 From: whooperhsd3 at earthlink.net (William Hooper) Date: Fri, 5 Dec 2003 16:19:24 -0500 (EST) Subject: Novell/progeny to take up redhat legacy services In-Reply-To: <1070658396.14633.4.camel@totoro.jpl.nasa.gov> References: <3FCF5917.7020806@acm.org> <20031205130119.7ff62548.ms-nospam-0306@arcor.de> <1070658396.14633.4.camel@totoro.jpl.nasa.gov> Message-ID: <3825.12.29.16.103.1070659164.squirrel@12.29.16.103> Erik A. Espinoza said: >> The GPL does not override service licence agreements either. Meaning, >> that >> while you could copy the software freely, you are not permitted to >> install >> and run the product on more than the purchased number of licenced >> machines. Doing so would be in violation of your SLA. > > Wouldn't the SLA be in violation of my rights to the code? Sigh, must we go through this again? You can do anything you want to and with the code that complies with the GPL. Stop. Red Hat has the right to deny you service if you don't follow the service agreement. Stop. So, as a summary: You can copy the code you get from RHN to any machine you want. This, though, will invalidate your service agreement so RH can prevent you from getting NEW code *via* RHN. This will also invalidate any SLA you have with RH. -- William Hooper From jkeating at j2solutions.net Fri Dec 5 21:31:14 2003 From: jkeating at j2solutions.net (Jesse Keating) Date: Fri, 5 Dec 2003 13:31:14 -0800 Subject: Novell/progeny to take up redhat legacy services In-Reply-To: <3825.12.29.16.103.1070659164.squirrel@12.29.16.103> References: <3FCF5917.7020806@acm.org> <1070658396.14633.4.camel@totoro.jpl.nasa.gov> <3825.12.29.16.103.1070659164.squirrel@12.29.16.103> Message-ID: <200312051331.14993.jkeating@j2solutions.net> On Friday 05 December 2003 13:19, William Hooper wrote: > You can copy the code you get from RHN to any machine you want. > This, though, will invalidate your service agreement so RH can > prevent you from getting NEW code *via* RHN. This will also > invalidate any SLA you have with RH. As well as open you up to lawsuit by Red Hat for lost revenue at some pretty heafty price points. -- Jesse Keating RHCE MCSE (geek.j2solutions.net) Fedora Legacy Team (www.fedora.us/wiki/FedoraLegacy) Mondo DevTeam (www.mondorescue.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating From ms-nospam-0306 at arcor.de Fri Dec 5 22:33:46 2003 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Fri, 5 Dec 2003 23:33:46 +0100 Subject: Novell/progeny to take up redhat legacy services In-Reply-To: <1070658396.14633.4.camel@totoro.jpl.nasa.gov> References: <3FCF5917.7020806@acm.org> <20031205130119.7ff62548.ms-nospam-0306@arcor.de> <1070658396.14633.4.camel@totoro.jpl.nasa.gov> Message-ID: <20031205233346.104dcc4f.ms-nospam-0306@arcor.de> On Fri, 05 Dec 2003 13:06:36 -0800, Erik A. Espinoza wrote: > > The GPL does not override service licence agreements either. Meaning, that > > while you could copy the software freely, you are not permitted to install > > and run the product on more than the purchased number of licenced > > machines. Doing so would be in violation of your SLA. > > > GPL Section 4 > 4. You may not copy, modify, sublicense, or distribute the Program > except as expressly provided under this License. Any attempt > otherwise to copy, modify, sublicense or distribute the Program is > void, and will automatically terminate your rights under this License. > However, parties who have received copies, or rights, from you under > this License will not have their licenses terminated so long as such > parties remain in full compliance. > > Wouldn't the SLA be in violation of my rights to the code? The GPL does not cover running a piece of software, in particular not running software that is tied to a support contract. The GPL does not override the SLA, so that you could run the software on more machines than you have a licence for [*]. If you do, it can terminate your support contract, not your rights in the source code. You'd lose the support, not the GPL. Imagine someone would purchase one licence, run the software on 10 machines and then call support more often than with issues on just the single licenced machine. The GPL gives you the right to copy, modify, and distribute the source code of the software. If the software is given away in binary form (provided that it is permitted to do so), the GPL covers the recipient's rights in getting access to the source code. Illegal sublicencing attempts would be something like trying to restrict your rights in the source code, trying to combine GPL'ed code with proprietary code, not wanting to give away the source code,... [*] A common example is, consider a GPL'ed software in unmodified form which requires a serial number before it can be installed/started. You would not be allowed to give away a purchased serial number just because you're allowed to distribute the GPL'ed software. -- Or imagine you'd purchase a personalized copy of the software in binary form. The GPL does not cover whether you're allowed to redistribute that personalized binary version. -- Another example where you don't lose the rights in the source code is if the vendor's licence agreement for the GPL'ed software said "warranty void if modified". -- This has been discussed several times on some of the @redhat.com lists, but might be non-trivial to find in the list archives. From rostetter at mail.utexas.edu Fri Dec 5 23:56:04 2003 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Fri, 5 Dec 2003 17:56:04 -0600 Subject: Novell/progeny to take up redhat legacy services In-Reply-To: <37464.169.204.208.61.1070654638.squirrel@www.quantumlinux.com> References: <20031205130826.kdicggoc400k48c4@mail.ph.utexas.edu> <37464.169.204.208.61.1070654638.squirrel@www.quantumlinux.com> Message-ID: <20031205175604.ceggoc0swg8cw00c@mail.ph.utexas.edu> Quoting ChuckW : > As a side note, I can't help but feel like you selectively read this post > and made your judgement after reading the first line. Am I wrong? Yes, you are wrong. Maybe I misunderstood you. But I definately read the whole thing, and did not make my judgement until the end. > -Chuck -- Eric Rostetter From villegas at math.gatech.edu Sat Dec 6 00:31:34 2003 From: villegas at math.gatech.edu (Carlos Villegas) Date: Fri, 5 Dec 2003 19:31:34 -0500 Subject: Novell/progeny to take up redhat legacy services In-Reply-To: <20031205233346.104dcc4f.ms-nospam-0306@arcor.de> References: <3FCF5917.7020806@acm.org> <20031205130119.7ff62548.ms-nospam-0306@arcor.de> <1070658396.14633.4.camel@totoro.jpl.nasa.gov> <20031205233346.104dcc4f.ms-nospam-0306@arcor.de> Message-ID: <20031206003134.GG20043@hemi.math.gatech.edu> On Fri, Dec 05, 2003 at 11:33:46PM +0100, Michael Schwendt wrote: > you're allowed to distribute the GPL'ed software. -- Or imagine you'd > purchase a personalized copy of the software in binary form. The GPL does > not cover whether you're allowed to redistribute that personalized binary > version. -- Another example where you don't lose the rights in the source I'm not a lawyer, but that example (personalized binary) clearly would violate the GPL, if the original code is GPL, then any derivative work is GPL (personlized source that produced the binary), as such you are entitled to that source and can redistribute it and modify it as you please. And again I'm not a lawyer, but to me the binary that results from compilation is a derivative work (if not the same), and as such has no restrictions on redistribution. Carlos PS: I also don't think this is for this list, I also think that RH deserves the money they are charging. I also think that if you're applying the updates on a system you should pay for them, because is the ethical thing (I'm not sure if it is legal or not). As I said, I don't think this discussion belongs here, but I had to post this, no more postings on my part on this subject. From whooperhsd3 at earthlink.net Sat Dec 6 00:54:04 2003 From: whooperhsd3 at earthlink.net (William Hooper) Date: Fri, 5 Dec 2003 19:54:04 -0500 (EST) Subject: Novell/progeny to take up redhat legacy services In-Reply-To: <20031206003134.GG20043@hemi.math.gatech.edu> References: <3FCF5917.7020806@acm.org> <20031205130119.7ff62548.ms-nospam-0306@arcor.de> <1070658396.14633.4.camel@totoro.jpl.nasa.gov> <20031205233346.104dcc4f.ms-nospam-0306@arcor.de> <20031206003134.GG20043@hemi.math.gatech.edu> Message-ID: <64817.69.68.37.57.1070672044.squirrel@69.68.37.57> Carlos Villegas said: > On Fri, Dec 05, 2003 at 11:33:46PM +0100, Michael Schwendt wrote: >> you're allowed to distribute the GPL'ed software. -- Or imagine you'd >> purchase a personalized copy of the software in binary form. The GPL >> does >> not cover whether you're allowed to redistribute that personalized >> binary >> version. -- Another example where you don't lose the rights in the >> source > > I'm not a lawyer, but that example (personalized binary) clearly would > violate the GPL, if the original code is GPL, then any derivative work is > GPL (personlized source that produced the binary)... It depends. Is it an original work that the company you are buying it from decided to sell licenses to? IE: MySQL. If you want a non-GPL licensed copy you can buy it from them. Just because you place something you wrote under the GPL doesn't mean you can license it under other licenses also. http://www.gnu.org/licenses/gpl-faq.html#ReleaseUnderGPLAndNF -- William Hooper From rostetter at mail.utexas.edu Sat Dec 6 01:41:26 2003 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Fri, 5 Dec 2003 19:41:26 -0600 Subject: Novell/progeny to take up redhat legacy services In-Reply-To: <20031206003134.GG20043@hemi.math.gatech.edu> References: <3FCF5917.7020806@acm.org> <20031205130119.7ff62548.ms-nospam-0306@arcor.de> <1070658396.14633.4.camel@totoro.jpl.nasa.gov> <20031205233346.104dcc4f.ms-nospam-0306@arcor.de> <20031206003134.GG20043@hemi.math.gatech.edu> Message-ID: <20031205194126.apnozr40c4g40g0o@mail.ph.utexas.edu> Quoting Carlos Villegas : > I'm not a lawyer, but that example (personalized binary) clearly would > violate the GPL, if the original code is GPL, then any derivative work is > GPL (personlized source that produced the binary), as such you are entitled > to that source and can redistribute it and modify it as you please. Not always. If I personalize it with copyrighted/tradmarked material, you are entitled to the source still, but you can not sell it to others with my copyrighted/trademarked materials inside. It's a bit vague if you give it away, but generally that is also a bad thing. If I create an add on for something that is GPL, it does not have to be GPL. So just because I take all GPL code, and add-on something to it for my distribution, does not mean you can use my add-on. It could be under completely different license. No, if I take all GPL code and modify it, then it must be GPL. But if I create a separate piece, it does not have to be GPL. -- Eric Rostetter From rostetter at mail.utexas.edu Sat Dec 6 02:12:28 2003 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Fri, 5 Dec 2003 20:12:28 -0600 Subject: Novell/progeny to take up redhat legacy services In-Reply-To: <20031205194126.apnozr40c4g40g0o@mail.ph.utexas.edu> References: <3FCF5917.7020806@acm.org> <20031205130119.7ff62548.ms-nospam-0306@arcor.de> <1070658396.14633.4.camel@totoro.jpl.nasa.gov> <20031205233346.104dcc4f.ms-nospam-0306@arcor.de> <20031206003134.GG20043@hemi.math.gatech.edu> <20031205194126.apnozr40c4g40g0o@mail.ph.utexas.edu> Message-ID: <20031205201228.2n5n60wco80c4o8c@mail.ph.utexas.edu> Quoting Eric Rostetter : > Quoting Carlos Villegas : > > > I'm not a lawyer, but that example (personalized binary) clearly would > > violate the GPL, if the original code is GPL, then any derivative work is > > GPL (personlized source that produced the binary), as such you are entitled > > to that source and can redistribute it and modify it as you please. > > Not always. If I personalize it with copyrighted/tradmarked material, you > are entitled to the source still, but you can not sell it to others with my > copyrighted/trademarked materials inside. It's a bit vague if you give it > away, but generally that is also a bad thing. Actually, that probably isn't true in most cases for copyrighted material. But it does apply to trademarked material, or material licensed other other terms/conditions/licenses. Sorry about that. -- Eric Rostetter From rostetter at mail.utexas.edu Sat Dec 6 03:20:50 2003 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Fri, 5 Dec 2003 21:20:50 -0600 Subject: Novell/progeny to take up redhat legacy services In-Reply-To: <3825.12.29.16.103.1070659164.squirrel@12.29.16.103> References: <3FCF5917.7020806@acm.org> <20031205130119.7ff62548.ms-nospam-0306@arcor.de> <1070658396.14633.4.camel@totoro.jpl.nasa.gov> <3825.12.29.16.103.1070659164.squirrel@12.29.16.103> Message-ID: <20031205212050.u84g5k40w4g0wcw0@mail.ph.utexas.edu> Quoting William Hooper : > Sigh, must we go through this again? Yes, unfortunately so. But, this is my last post on the subject. > You can do anything you want to and with the code that complies with the > GPL. Stop. Not if it violates trademarks as may be the case with RHEL. > Red Hat has the right to deny you service if you don't follow the service > agreement. Stop. Correct. > So, as a summary: > > You can copy the code you get from RHN to any machine you want. This, > though, will invalidate your service agreement so RH can prevent you from > getting NEW code *via* RHN. This will also invalidate any SLA you have > with RH. You can do so within certain limits. I can, for example, copy it internal to my company/school without any problem. But to copy it to others, I need to at least make sure they know it is not from RH, does not come with support from RH, does not have any warranty from RH, and in some cases I'll need to remove any trademark references in doing so (which I don't have to do if I copy it internally). If I want to sell it or distribute it with support then I very much must do the above including removing their RH trademarks. If I modify it and distribute it again, then again I MUST make sure to do so. Otherwise I'm in trademark violation by a) using someone elses trademarks, b) misleading people as to the owner and source of the software and trademarks, and c) misleading people as to the support/contact source for the software. In addition, I can't claim ownership of it if I want to distribute it without modifications (since RH owns/copyrights it). If I want to claim onership, I need to show cause (via modifications, removals, or additions, for example). So, can you copy it? Yes, in some cases, in some forms, with some modifications. How, where, and why you copy it changes the rules for how you can copy/distribute it. Red Hat makes this all pretty clear on their web site and in their licenses. > -- > William Hooper -- Eric Rostetter From shurdeek at routehat.org Sat Dec 6 03:59:29 2003 From: shurdeek at routehat.org (Peter Surda) Date: Sat, 6 Dec 2003 04:59:29 +0100 Subject: Novell/progeny to take up redhat legacy services In-Reply-To: <20031206003134.GG20043@hemi.math.gatech.edu> References: <3FCF5917.7020806@acm.org> <20031205130119.7ff62548.ms-nospam-0306@arcor.de> <1070658396.14633.4.camel@totoro.jpl.nasa.gov> <20031205233346.104dcc4f.ms-nospam-0306@arcor.de> <20031206003134.GG20043@hemi.math.gatech.edu> Message-ID: <20031206035929.GV31087@chloe.cb.ac.at> On Fri, Dec 05, 2003 at 07:31:34PM -0500, Carlos Villegas wrote: > I'm not a lawyer, but that example (personalized binary) clearly would > violate the GPL, if the original code is GPL, then any derivative work is > GPL (personlized source that produced the binary), as such you are entitled > to that source and can redistribute it and modify it as you please. > And again I'm not a lawyer, but to me the binary that results from > compilation is a derivative work (if not the same), and as such has no > restrictions on redistribution. IANAL as well, but I think this is correct. BUT! GPL basically regulates what should happen IF YOU DECIDE to distribute GPLd software (binary/source/whatever). It doesn't say that you MUST decide to distribute, or that you must distribute to EVERYONE. This is the main point. To make this more clear, consider the following two sentences. The first one represents what many think GPL is, but isn't. The second one is what GPL really is. --------------------------------------------------------------------------- If a software is GPLd, a distributor must give everyone all the "GPL rights". If a distributor gives someone GPLd software, he must give them all the GPL rights". --------------------------------------------------------------------------- To make this even more clear in a list like this one, here is what it would look like written in a programming language :-) : --------------------------------------------------------------------------- if (soft_gpld()) if (not get_software(distributor) or not get_rights(distributor)) panic ("GPL violation!"); if (soft_gpld()) if (get_software(distributor) and not get_rights(distributor)) panic ("GPL violation!"); --------------------------------------------------------------------------- Without a doubt, those 2 don't always produce the same results, depending on get_software(distributor). So, Red Hat may not restrict what you do with the sources or binaries you get from RHN (for GPLd software at least), but may for example decide to cancel your RHN account in case you don't pay for all of it, or redistribute binaries or whatever. The first program would claim it is a GPL violation, the second one that it isn't :-). > Carlos Bye, Peter Surda (Shurdeek) , ICQ 10236103, +436505122023 -- They called their place of existence the "Universe", not the "Great Programmer/Universe". From ms-nospam-0306 at arcor.de Sat Dec 6 04:13:36 2003 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Sat, 6 Dec 2003 05:13:36 +0100 Subject: Novell/progeny to take up redhat legacy services In-Reply-To: <20031206003134.GG20043@hemi.math.gatech.edu> References: <3FCF5917.7020806@acm.org> <20031205130119.7ff62548.ms-nospam-0306@arcor.de> <1070658396.14633.4.camel@totoro.jpl.nasa.gov> <20031205233346.104dcc4f.ms-nospam-0306@arcor.de> <20031206003134.GG20043@hemi.math.gatech.edu> Message-ID: <20031206051336.0424614c.ms-nospam-0306@arcor.de> On Fri, 5 Dec 2003 19:31:34 -0500, Carlos Villegas wrote: > On Fri, Dec 05, 2003 at 11:33:46PM +0100, Michael Schwendt wrote: > > you're allowed to distribute the GPL'ed software. -- Or imagine you'd > > purchase a personalized copy of the software in binary form. The GPL does > > not cover whether you're allowed to redistribute that personalized binary > > version. -- Another example where you don't lose the rights in the source > > I'm not a lawyer, but that example (personalized binary) clearly would > violate the GPL, if the original code is GPL, then any derivative work is > GPL (personlized source that produced the binary), as such you are entitled > to that source and can redistribute it and modify it as you please. But the source code is available. The GPL has no requirements whatsoever that the program is shipped together with a complete set of tools that create the preconfigured, personalized, installable software. The GPL just requires that the complete source code for the program is made available, not that it is trivial or easy to rebuild the program. [1] Probably it didn't become clear what "personalization" means. It could be a digital key file, heavy preconfiguration or complex installation and set-up requirements. In either case, additional customization that is beyond the scope of the GPL. [...] [1] E.g. if a GPL'ed program is able to decode mp3 files, it need not include an mp3 encoder. Similarly, if a program at startup asks for a digital key file or serial number (which must be purchased), the source code need not include the tools required to create that input. -- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From pfhonore at cea.fr Sat Dec 6 12:52:37 2003 From: pfhonore at cea.fr (Pierre-Francois Honore) Date: Sat, 06 Dec 2003 13:52:37 +0100 Subject: Novell/progeny to take up redhat legacy services In-Reply-To: <20031206051336.0424614c.ms-nospam-0306@arcor.de> References: <3FCF5917.7020806@acm.org> <20031205130119.7ff62548.ms-nospam-0306@arcor.de> <1070658396.14633.4.camel@totoro.jpl.nasa.gov> <20031205233346.104dcc4f.ms-nospam-0306@arcor.de> <20031206003134.GG20043@hemi.math.gatech.edu> <20031206051336.0424614c.ms-nospam-0306@arcor.de> Message-ID: <1070715157.26410.18.camel@seipca109> On Sat, 2003-12-06 at 05:13, Michael Schwendt wrote: > On Fri, 5 Dec 2003 19:31:34 -0500, Carlos Villegas wrote: > > > On Fri, Dec 05, 2003 at 11:33:46PM +0100, Michael Schwendt wrote: > > > you're allowed to distribute the GPL'ed software. -- Or imagine you'd > > > purchase a personalized copy of the software in binary form. The GPL does > > > not cover whether you're allowed to redistribute that personalized binary > > > version. -- Another example where you don't lose the rights in the source > > > > I'm not a lawyer, but that example (personalized binary) clearly would > > violate the GPL, if the original code is GPL, then any derivative work is > > GPL (personlized source that produced the binary), as such you are entitled > > to that source and can redistribute it and modify it as you please. > > But the source code is available. The GPL has no requirements whatsoever > that the program is shipped together with a complete set of tools that > create the preconfigured, personalized, installable software. The GPL just > requires that the complete source code for the program is made available, > not that it is trivial or easy to rebuild the program. [1] > I don't tink so. The source code must be a targz or equivalent (not printed source code) and ready to build. I suppose that if you distribute a RPM, you have to provide a SRPM. chapter 3 of the GPL : The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. > Probably it didn't become clear what "personalization" means. It could be > a digital key file, heavy preconfiguration or complex installation and > set-up requirements. In either case, additional customization that is > beyond the scope of the GPL. > > [...] > > [1] E.g. if a GPL'ed program is able to decode mp3 files, it need not > include an mp3 encoder. Similarly, if a program at startup asks for a > digital key file or serial number (which must be purchased), the source > code need not include the tools required to create that input. If so you can fork and distribute a new version without the key requirement. From ms-nospam-0306 at arcor.de Sat Dec 6 17:58:41 2003 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Sat, 6 Dec 2003 18:58:41 +0100 Subject: Novell/progeny to take up redhat legacy services In-Reply-To: <1070715157.26410.18.camel@seipca109> References: <3FCF5917.7020806@acm.org> <20031205130119.7ff62548.ms-nospam-0306@arcor.de> <1070658396.14633.4.camel@totoro.jpl.nasa.gov> <20031205233346.104dcc4f.ms-nospam-0306@arcor.de> <20031206003134.GG20043@hemi.math.gatech.edu> <20031206051336.0424614c.ms-nospam-0306@arcor.de> <1070715157.26410.18.camel@seipca109> Message-ID: <20031206185841.2d516ce7.ms-nospam-0306@arcor.de> On Sat, 06 Dec 2003 13:52:37 +0100, Pierre-Francois Honore wrote: > > But the source code is available. The GPL has no requirements whatsoever > > that the program is shipped together with a complete set of tools that > > create the preconfigured, personalized, installable software. The GPL just > > requires that the complete source code for the program is made available, > > not that it is trivial or easy to rebuild the program. [1] > > > > I don't tink so. The source code must be a targz or equivalent (not > printed source code) and ready to build. I suppose that if you > distribute a RPM, you have to provide a SRPM. See [1]. Your SRPM example doesn't hold, because the vendor of the program cannot be forced to provide scripts for tasks that were manual during preparation of an installable file. E.g. creating all the directories within a binary tgz could have been a manual task. If Makefile lacks an install target, vendor isn't force to provide it or an equivalent. I'll refrain from further replies, because this has nothing to do with Fedora Legacy whatsoever. > > [1] E.g. if a GPL'ed program is able to decode mp3 files, it need not > > include an mp3 encoder. Similarly, if a program at startup asks for a > > digital key file or serial number (which must be purchased), the source > > code need not include the tools required to create that input. > > If so you can fork and distribute a new version without the key > requirement. Sure. You can also create something from Red Hat Enterprise Linux src.rpms. But that's not the point. -- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mhkohne at discordia.org Sat Dec 6 19:49:34 2003 From: mhkohne at discordia.org (Michael Kohne) Date: Sat, 6 Dec 2003 14:49:34 -0500 (EST) Subject: build In-Reply-To: References: <200312050757.31175.jkeating@j2solutions.net> Message-ID: <14367.68.162.99.230.1070740174.squirrel@www.discordia.org> Wade Maxfield said: [snip] > I've muddled through a RedHat build on X windows to write a custom > driver for a touch screen to work, modified from another driver. Rather > cryptic understanding what they mean sometimes in the source code, but > the examples made things clear with time and mistakes. > > > However, I've never understood the RedHat build model. I get the > kernel > source and there are dozens of patch files. HUH? Do I need them? > [snip] Part of what you are probably trying to understand is the underlying model that 'rpm' uses. The quick synopsis is that rpm works on 'clean sources'. When you unpack a source rpm, you get the original clean sources, plus patches. The rpm build process is to unpack the clean sources, apply the patches, build from that. I recommend Maximum RPM for a good overall look at what RPM is trying to accomplish, and a good idea of how it does so. Be VERY aware, however, that rpm has evolved quite a bit since this book was written, and therefore not everything in it precisely correct anymore. http://www.rpm.org/max-rpm/ I don't have my notes from the last time I added a patch to a redhat kernel rpm handy right now, but if you like I could find them Monday and write them up for you. -- Michael Kohne mhkohne at discordia.org "You should be smarter than the equipment you are trying to operate." -- Matt Osborne From admin at cs.montana.edu Sat Dec 6 20:20:29 2003 From: admin at cs.montana.edu (Lucas Albers) Date: Sat, 6 Dec 2003 13:20:29 -0700 (MST) Subject: test build In-Reply-To: <1070715157.26410.18.camel@seipca109> References: <3FCF5917.7020806@acm.org> <20031205130119.7ff62548.ms-nospam-0306@arcor.de> <1070658396.14633.4.camel@totoro.jpl.nasa.gov> <20031205233346.104dcc4f.ms-nospam-0306@arcor.de> <20031206003134.GG20043@hemi.math.gatech.edu> <20031206051336.0424614c.ms-nospam-0306@arcor.de> <1070715157.26410.18.camel@seipca109> Message-ID: <3941.216.166.133.165.1070742029.squirrel@lists.cs.montana.edu> How close to a working implementation of fedora legacy are we? Have you tested the build environment by rebuilding all the srpms for our supported architectures? Then we can dump those packages into our yum/apt repository. Then the mirrors can do a dry run on synchronization and various people can test everything to see if yum/apt repository appear to be working correctly. We are 24 days from our launch date, based on eol, and I want to be confident I can use this on my systems. Do we have: bugzilla database? erratta notifications? Figured out the argument about rpm versions? Setup apt or yum repository? --Luke From warren at togami.com Sat Dec 6 22:48:52 2003 From: warren at togami.com (Warren Togami) Date: Sat, 06 Dec 2003 12:48:52 -1000 Subject: test build In-Reply-To: <3941.216.166.133.165.1070742029.squirrel@lists.cs.montana.edu> References: <3FCF5917.7020806@acm.org> <20031205130119.7ff62548.ms-nospam-0306@arcor.de> <1070658396.14633.4.camel@totoro.jpl.nasa.gov> <20031205233346.104dcc4f.ms-nospam-0306@arcor.de> <20031206003134.GG20043@hemi.math.gatech.edu> <20031206051336.0424614c.ms-nospam-0306@arcor.de> <1070715157.26410.18.camel@seipca109> <3941.216.166.133.165.1070742029.squirrel@lists.cs.montana.edu> Message-ID: <1070750932.6161.6.camel@laptop> On Sat, 2003-12-06 at 10:20, Lucas Albers wrote: > How close to a working implementation of fedora legacy are we? > > Have you tested the build environment by rebuilding all the srpms for our > supported architectures? > Then we can dump those packages into our yum/apt repository. Then the > mirrors can do a dry run on synchronization and various people can test > everything to see if yum/apt repository appear to be working correctly. > Err... why rebuild the entire operating system? At the moment I am confident that we collectively fully understand all the quirks on the target operating systems. Currently we are waiting for Pogo Linux and Jesse Keatings to put together the dedicated Fedora Legacy server. When that happens we (the fedora.us team) can easily help him setup and understand every aspect of how this works. If that is not operational in time we have a viable backup plan. For the past 10 months fedora.us has basically been doing exactly this: package submission, QA analysis, improvement, building, testing, signing, publishing in apt/yum repositories. fedora.us infrastructure for doing this for Legacy is ready TODAY. Unless the Legacy members want to do the necessary discussion to design a new process now, I really believe the existing fedora.us process with minor modifications will do the job. > > We are 24 days from our launch date, based on eol, and I want to be > confident I can use this on my systems. > > Do we have: > bugzilla database? Perhaps just need to tweak our settings and update the documentation. > erratta notifications? Only need to add a mailing list to mailman. > Figured out the argument about rpm versions? RH8 and RH9 I think most of us agree to upgrade. 7.X is less certain and contingent on if we want to be able to use the latest yum-2.x, thus perhaps we should have a vote? > Setup apt or yum repository? > No problem. We've been doing this for ages. Don't worry. Warren From cspencer at cait.org Sun Dec 7 07:33:59 2003 From: cspencer at cait.org (Chris Spencer) Date: Sun, 07 Dec 2003 01:33:59 -0600 Subject: test build In-Reply-To: <1070750932.6161.6.camel@laptop> References: <3FCF5917.7020806@acm.org> <20031205130119.7ff62548.ms-nospam-0306@arcor.de> <1070658396.14633.4.camel@totoro.jpl.nasa.gov> <20031205233346.104dcc4f.ms-nospam-0306@arcor.de> <20031206003134.GG20043@hemi.math.gatech.edu> <20031206051336.0424614c.ms-nospam-0306@arcor.de> <1070715157.26410.18.camel@seipca109> <3941.216.166.133.165.1070742029.squirrel@lists.cs.montana.edu> <1070750932.6161.6.camel@laptop> Message-ID: <1070782439.3362.9.camel@cnote> Warren, I understand that we collectively have the skills needed to build (or rebuild) the RPMs. However I think we do need to make available documentation on how to access the archives once they are up. I would be happy to write something up. The users would probably appreciate it. -Chris On Sat, 2003-12-06 at 16:48, Warren Togami wrote: > On Sat, 2003-12-06 at 10:20, Lucas Albers wrote: > > How close to a working implementation of fedora legacy are we? > > > > Have you tested the build environment by rebuilding all the srpms for our > > supported architectures? > > Then we can dump those packages into our yum/apt repository. Then the > > mirrors can do a dry run on synchronization and various people can test > > everything to see if yum/apt repository appear to be working correctly. > > > > Err... why rebuild the entire operating system? > > At the moment I am confident that we collectively fully understand all > the quirks on the target operating systems. Currently we are waiting > for Pogo Linux and Jesse Keatings to put together the dedicated Fedora > Legacy server. When that happens we (the fedora.us team) can easily > help him setup and understand every aspect of how this works. > > If that is not operational in time we have a viable backup plan. For > the past 10 months fedora.us has basically been doing exactly this: > package submission, QA analysis, improvement, building, testing, > signing, publishing in apt/yum repositories. fedora.us infrastructure > for doing this for Legacy is ready TODAY. Unless the Legacy members > want to do the necessary discussion to design a new process now, I > really believe the existing fedora.us process with minor modifications > will do the job. > > > > > We are 24 days from our launch date, based on eol, and I want to be > > confident I can use this on my systems. > > > > Do we have: > > bugzilla database? > > Perhaps just need to tweak our settings and update the documentation. > > > erratta notifications? > > Only need to add a mailing list to mailman. > > > Figured out the argument about rpm versions? > > RH8 and RH9 I think most of us agree to upgrade. 7.X is less certain > and contingent on if we want to be able to use the latest yum-2.x, thus > perhaps we should have a vote? > > > Setup apt or yum repository? > > > > No problem. We've been doing this for ages. Don't worry. > > Warren > > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-legacy-list > From chuckw at quantumlinux.com Sun Dec 7 08:17:32 2003 From: chuckw at quantumlinux.com (Chuck Wolber) Date: Sun, 7 Dec 2003 00:17:32 -0800 (PST) Subject: Novell/progeny to take up redhat legacy services In-Reply-To: <200312051331.14993.jkeating@j2solutions.net> Message-ID: > > You can copy the code you get from RHN to any machine you want. > > This, though, will invalidate your service agreement so RH can > > prevent you from getting NEW code *via* RHN. This will also > > invalidate any SLA you have with RH. > > As well as open you up to lawsuit by Red Hat for lost revenue at some > pretty heafty price points. I don't believe that one bit. Legal precdedence works downward, not upward: $DIETY US Law GPL RedHat SLA If someone lower on the chain breaks a rule/law/precept higher on the chain, the group lower on the chain loses. Or as a lawyer I know put it, "Herein fail at your peril". -Chuck -- Quantum Linux Laboratories - ACCELERATING Business with Open Technology * Education | -=^ Ad Astra Per Aspera ^=- * Integration | http://www.quantumlinux.com * Support | chuckw at quantumlinux.com "M stands for magic, mystery or matrix; according to taste." --Edward Witten From chuckw at quantumlinux.com Sun Dec 7 09:03:12 2003 From: chuckw at quantumlinux.com (Chuck Wolber) Date: Sun, 7 Dec 2003 01:03:12 -0800 (PST) Subject: Novell/progeny to take up redhat legacy services In-Reply-To: <20031205212050.u84g5k40w4g0wcw0@mail.ph.utexas.edu> Message-ID: > > You can do anything you want to and with the code that complies with > > the GPL. Stop. > > Not if it violates trademarks as may be the case with RHEL. Wrong. By definition, if code complies with the GPL, it cannot violate trademarks. -Chuck -- Quantum Linux Laboratories - ACCELERATING Business with Open Technology * Education | -=^ Ad Astra Per Aspera ^=- * Integration | http://www.quantumlinux.com * Support | chuckw at quantumlinux.com "M stands for magic, mystery or matrix; according to taste." --Edward Witten From maxfield at one.ctelcom.net Mon Dec 8 00:07:04 2003 From: maxfield at one.ctelcom.net (Wade Maxfield) Date: Sun, 7 Dec 2003 18:07:04 -0600 (CST) Subject: build In-Reply-To: <14367.68.162.99.230.1070740174.squirrel@www.discordia.org> References: <200312050757.31175.jkeating@j2solutions.net> <14367.68.162.99.230.1070740174.squirrel@www.discordia.org> Message-ID: That would be very good, especially if it were posted on this list. Because, we are now going to have to patch things ourselves from the original RedHat source, which deviates from the sources from Kernel.org, for example. Posting it on this list would get it into archives and be a very good thing. :) THANKS!! I appreciate the info. wade On Sat, 6 Dec 2003, Michael Kohne wrote: > Date: Sat, 6 Dec 2003 14:49:34 -0500 (EST) > From: Michael Kohne > To: fedora-legacy-list at redhat.com > Cc: maxfield at one.ctelcom.net > Subject: Re: build > > Wade Maxfield said: > [snip] > > I've muddled through a RedHat build on X windows to write a custom > > driver for a touch screen to work, modified from another driver. Rather > > cryptic understanding what they mean sometimes in the source code, but > > the examples made things clear with time and mistakes. > > > > > > However, I've never understood the RedHat build model. I get the > > kernel > > source and there are dozens of patch files. HUH? Do I need them? > > > [snip] > > Part of what you are probably trying to understand is the underlying model > that 'rpm' uses. The quick synopsis is that rpm works on 'clean sources'. > When you unpack a source rpm, you get the original clean sources, plus > patches. The rpm build process is to unpack the clean sources, apply the > patches, build from that. > > I recommend Maximum RPM for a good overall look at what RPM is trying to > accomplish, and a good idea of how it does so. Be VERY aware, however, > that rpm has evolved quite a bit since this book was written, and > therefore not everything in it precisely correct anymore. > > http://www.rpm.org/max-rpm/ > > I don't have my notes from the last time I added a patch to a redhat > kernel rpm handy right now, but if you like I could find them Monday and > write them up for you. > > From jeremyp at pobox.com Mon Dec 8 14:17:45 2003 From: jeremyp at pobox.com (Jeremy Portzer) Date: Mon, 08 Dec 2003 09:17:45 -0500 Subject: build In-Reply-To: <14367.68.162.99.230.1070740174.squirrel@www.discordia.org> References: <200312050757.31175.jkeating@j2solutions.net> <14367.68.162.99.230.1070740174.squirrel@www.discordia.org> Message-ID: <1070893064.23038.2.camel@jeremy.dtcc.cc.nc.us> On Sat, 2003-12-06 at 14:49, Michael Kohne wrote: > I recommend Maximum RPM for a good overall look at what RPM is trying to > accomplish, and a good idea of how it does so. Be VERY aware, however, > that rpm has evolved quite a bit since this book was written, and > therefore not everything in it precisely correct anymore. > > http://www.rpm.org/max-rpm/ > I also recommend the Red Hat RPM Guide by Eric Foster-Johnson. This is a much newer book (March 2003) and should you well on your way to fully understanding RPMs. http://www.amazon.com/exec/obidos/tg/detail/-/0764549650/102-3644477-2534509?v=glance --Jeremy -- /---------------------------------------------------------------------\ | Jeremy Portzer jeremyp at pobox.com trilug.org/~jeremy | | GPG Fingerprint: 712D 77C7 AB2D 2130 989F E135 6F9F F7BC CC1A 7B92 | \---------------------------------------------------------------------/ -------------- 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 cspencer at cait.org Mon Dec 8 15:10:11 2003 From: cspencer at cait.org (Chris Spencer) Date: Mon, 08 Dec 2003 09:10:11 -0600 Subject: Novell/progeny to take up redhat legacy services In-Reply-To: References: Message-ID: <1070896210.11642.4703.camel@chriss2.cait.org> On Sun, 2003-12-07 at 02:17, Chuck Wolber wrote: > > > You can copy the code you get from RHN to any machine you want. > > > This, though, will invalidate your service agreement so RH can > > > prevent you from getting NEW code *via* RHN. This will also > > > invalidate any SLA you have with RH. > > > > As well as open you up to lawsuit by Red Hat for lost revenue at some > > pretty heafty price points. > > I don't believe that one bit. Legal precdedence works downward, not > upward: > > $DIETY > US Law > GPL > RedHat SLA > > If someone lower on the chain breaks a rule/law/precept higher on the > chain, the group lower on the chain loses. Or as a lawyer I know put it, > "Herein fail at your peril". If you steal RedHat work which is covered under the SLA then you could be fined. RedHat makes it very clear what you have to pay for and what you don't. RHEL is not a free product. You are not free to copy it from computer to computer. It is the packaged artwork and possibly some of the configuration utilities that make it non-free. Strip those out and you can do as you like. -Chris "There is a lot of speculation and I guess there is going to continue to be a log of speculation until the speculation ends." - George W. Bush on October 18, 1998 From bhughes at elevating.com Mon Dec 8 15:09:31 2003 From: bhughes at elevating.com (Bret Hughes) Date: 08 Dec 2003 09:09:31 -0600 Subject: build In-Reply-To: References: <200312050757.31175.jkeating@j2solutions.net> <20031205120949.B10663@angus.ind.WPI.EDU> <20031205213353.448d7e7f.ms-nospam-0306@arcor.de> Message-ID: <1070896172.12675.14.camel@bretsony> On Fri, 2003-12-05 at 15:00, Wade Maxfield wrote: > On Fri, 5 Dec 2003, Michael Schwendt wrote: > > > Date: Fri, 5 Dec 2003 21:33:53 +0100 > > From: Michael Schwendt > > On Fri, 5 Dec 2003 14:05:19 -0600 (CST), Wade Maxfield wrote: > > > > > rpmbuild: relocation error: rpmbuild: undefined symbol: freeSpecVec > > > > > > > > > here is my rpm list for redhat 8.0. Note that the rpm was upgraded > > > because of the hang problem that the standard 4.x rpm from redhat has > > > under 8.0. With 4.1.1, the problem does not occur. > > > > > > [root at rh80 SPECS]# rpm -qa | grep rpm > > > > > > rpmdb-redhat-8.0-0.20020910 > > > rpm-python-4.1.1-1.8x > > > rpm2html-1.7-8 > > > librpm404-devel-4.0.4-8x.27 > > > redhat-rpm-config-8.0-1 > > > rpm-4.1.1-1.8x > > > rpm404-python-4.0.4-8x.27 > > > rpm-build-4.1-1.06 > > > > This should be rpm-build-4.1.1-1.8x, so it matches your version of RPM. > > > Excellent! DOH! Yes, that was it. I had never heard of rpmbuild > before, it appears to be a neat tool. > Isn't this a symptom of a packaging error? seems like there should be a dependency built into rpmbuild to match the rpm version. Bret From brian.t.brunner at gai-tronics.com Mon Dec 8 15:57:32 2003 From: brian.t.brunner at gai-tronics.com (Brian T. Brunner) Date: Mon, 08 Dec 2003 10:57:32 -0500 Subject: Novell/progeny to take up redhat legacy services Message-ID: Check http://cart.cheapbytes.com/cgi-bin/cart/search.html?se=Pink+Tie cheapbytes takes Red Hat sources and removes all RedHat proprietary stuff, compiles, and ships it with 'pink tie' where 'red hat' used to occur. RH9 (er... Pink Tie 9) ships this way. Cheapbytes also ships Fedora Linux 1.3 http://cart.cheapbytes.com/cgi-bin/cart So: Get 1 RHEL system with one set of RHEL stuff, get that system patched, sourced, and fully configured, Keep that system patched, sourced, and up2date. Then compile your sources on that system, verify as you need, and distribute from that system to all your network. Perhaps RHEL will be cheaper than your time (including spent and lost time). Brian Brunner brian.t.brunner at gai-tronics.com (610)796-5838 >>> cspencer at cait.org 12/08/03 10:10AM >>> On Sun, 2003-12-07 at 02:17, Chuck Wolber wrote: > > > You can copy the code you get from RHN to any machine you want. > > > This, though, will invalidate your service agreement so RH can > > > prevent you from getting NEW code *via* RHN. This will also > > > invalidate any SLA you have with RH. > > > > As well as open you up to lawsuit by Red Hat for lost revenue at some > > pretty heafty price points. > > I don't believe that one bit. Legal precdedence works downward, not > upward: > > $DIETY > US Law > GPL > RedHat SLA > > If someone lower on the chain breaks a rule/law/precept higher on the > chain, the group lower on the chain loses. Or as a lawyer I know put it, > "Herein fail at your peril". If you steal RedHat work which is covered under the SLA then you could be fined. RedHat makes it very clear what you have to pay for and what you don't. RHEL is not a free product. You are not free to copy it from computer to computer. It is the packaged artwork and possibly some of the configuration utilities that make it non-free. Strip those out and you can do as you like. -Chris "There is a lot of speculation and I guess there is going to continue to be a log of speculation until the speculation ends." - George W. Bush on October 18, 1998 -- fedora-legacy-list mailing list fedora-legacy-list at redhat.com http://www.redhat.com/mailman/listinfo/fedora-legacy-list ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept for the presence of computer viruses. www.hubbell.com - Hubbell Incorporated ********************************************************************** From xose at wanadoo.es Mon Dec 8 16:54:09 2003 From: xose at wanadoo.es (Xose Vazquez Perez) Date: Mon, 08 Dec 2003 17:54:09 +0100 Subject: Novell/progeny to take up redhat legacy services References: Message-ID: <3FD4ACB1.8060005@wanadoo.es> Brian T. Brunner wrote: > So: Get 1 RHEL system with one set of RHEL stuff, > get that system patched, sourced, and fully configured, > Keep that system patched, sourced, and up2date. > Then compile your sources on that system, verify as > you need, and distribute from that system to all your > network. Already done: http://whiteboxlinux.org http://caosity.org From andy.henson.fedora at zexia.co.uk Mon Dec 8 17:17:00 2003 From: andy.henson.fedora at zexia.co.uk (Andy Henson) Date: Mon, 8 Dec 2003 17:17 +0000 (GMT Standard Time) Subject: test build In-Reply-To: <3941.216.166.133.165.1070742029.squirrel@lists.cs.montana.edu> Message-ID: Luke wrote: > We are 24 days from our launch date, based on eol, and I want to be > confident I can use this on my systems. > > Do we have: > bugzilla database? > erratta notifications? > Figured out the argument about rpm versions? > Setup apt or yum repository? Thanks, Luke, I'm keen on asking the same questions. Do we have a web page which states which versions we are maintaining, and on which architectures? I have clients who want to know fedora-devel isn't just a few people dreaming. I can help on RedHat 7.3 on i386 as needed (see my self-introduction on the -devel list). I can build and patch rpms. I'm especially keen on keeping up to date with bugfixes to openssh, cvs, and possibly apache and sendmail as well. Anything which offers open ports to the internet and therefore could compromise a working server. Andy Henson PS: IMO we don't need to rebuild all the rpms, but probably should make sure we have a copy of the SRPMs (and RPMs) before RedHat delete them! So: do we have a repository? PPS: I could host a repository if needed. From ms-nospam-0306 at arcor.de Mon Dec 8 18:00:09 2003 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Mon, 8 Dec 2003 19:00:09 +0100 Subject: build In-Reply-To: <1070896172.12675.14.camel@bretsony> References: <200312050757.31175.jkeating@j2solutions.net> <20031205120949.B10663@angus.ind.WPI.EDU> <20031205213353.448d7e7f.ms-nospam-0306@arcor.de> <1070896172.12675.14.camel@bretsony> Message-ID: <20031208190009.6daad1a3.ms-nospam-0306@arcor.de> On 08 Dec 2003 09:09:31 -0600, Bret Hughes wrote: > > > > rpmbuild: relocation error: rpmbuild: undefined symbol: freeSpecVec > > > > > > > > > > > > here is my rpm list for redhat 8.0. Note that the rpm was upgraded > > > > because of the hang problem that the standard 4.x rpm from redhat has > > > > under 8.0. With 4.1.1, the problem does not occur. > > > > > > > > [root at rh80 SPECS]# rpm -qa | grep rpm > > > > > > > > rpmdb-redhat-8.0-0.20020910 > > > > rpm-python-4.1.1-1.8x > > > > rpm2html-1.7-8 > > > > librpm404-devel-4.0.4-8x.27 > > > > redhat-rpm-config-8.0-1 > > > > rpm-4.1.1-1.8x > > > > rpm404-python-4.0.4-8x.27 > > > > rpm-build-4.1-1.06 > > > > > > This should be rpm-build-4.1.1-1.8x, so it matches your version of RPM. > > > > > > Excellent! DOH! Yes, that was it. I had never heard of rpmbuild > > before, it appears to be a neat tool. > > > > Isn't this a symptom of a packaging error? seems like there should be a > dependency built into rpmbuild to match the rpm version. The error is to assume that there's no such dependency: ;) $ rpm -qR rpm-build | grep rpm rpm = 4.1.1 rpmlib(VersionedDependencies) <= 3.0.3-1 rpmlib(CompressedFileNames) <= 3.0.4-1 librpm-4.1.so librpmbuild-4.1.so librpmdb-4.1.so librpmio-4.1.so Some users play too much with --nodeps/--force while installing or upgrading packages. -- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From maxfield at one.ctelcom.net Mon Dec 8 19:40:14 2003 From: maxfield at one.ctelcom.net (Wade Maxfield) Date: Mon, 8 Dec 2003 13:40:14 -0600 (CST) Subject: build In-Reply-To: <20031208190009.6daad1a3.ms-nospam-0306@arcor.de> References: <200312050757.31175.jkeating@j2solutions.net> <20031205120949.B10663@angus.ind.WPI.EDU> <20031205213353.448d7e7f.ms-nospam-0306@arcor.de> <1070896172.12675.14.camel@bretsony> <20031208190009.6daad1a3.ms-nospam-0306@arcor.de> Message-ID: Well, in this case, rpm did not require rpmbuild to be upgraded before I upgraded it to 4.1.1. It did require popt, and one other. :) I don't do --nodeps unless I'm installing a package that really isn't tied into what it is requiring. This is usually due installing an rpm that requires an older /lib/libblah.so.0 and only /lib/libblah.so.2 is available. I then make the softlink for .so.0, install with --nodeps and then see if it runs. If it doesn't, then the package is removed. :) On Mon, 8 Dec 2003, Michael Schwendt wrote: > Date: Mon, 8 Dec 2003 19:00:09 +0100 > From: Michael Schwendt > Reply-To: fedora-legacy-list at redhat.com > To: fedora-legacy-list at redhat.com > Subject: Re: build > > On 08 Dec 2003 09:09:31 -0600, Bret Hughes wrote: > > > > > > rpmbuild: relocation error: rpmbuild: undefined symbol: freeSpecVec > > > > > > > > > > > > > > > here is my rpm list for redhat 8.0. Note that the rpm was upgraded > > > > > because of the hang problem that the standard 4.x rpm from redhat has > > > > > under 8.0. With 4.1.1, the problem does not occur. > > > > > > > > > > [root at rh80 SPECS]# rpm -qa | grep rpm > > > > > > > > > > rpmdb-redhat-8.0-0.20020910 > > > > > rpm-python-4.1.1-1.8x > > > > > rpm2html-1.7-8 > > > > > librpm404-devel-4.0.4-8x.27 > > > > > redhat-rpm-config-8.0-1 > > > > > rpm-4.1.1-1.8x > > > > > rpm404-python-4.0.4-8x.27 > > > > > rpm-build-4.1-1.06 > > > > > > > > This should be rpm-build-4.1.1-1.8x, so it matches your version of RPM. > > > > > > > > > Excellent! DOH! Yes, that was it. I had never heard of rpmbuild > > > before, it appears to be a neat tool. > > > > > > > Isn't this a symptom of a packaging error? seems like there should be a > > dependency built into rpmbuild to match the rpm version. > > The error is to assume that there's no such dependency: ;) > > $ rpm -qR rpm-build | grep rpm > rpm = 4.1.1 > rpmlib(VersionedDependencies) <= 3.0.3-1 > rpmlib(CompressedFileNames) <= 3.0.4-1 > librpm-4.1.so > librpmbuild-4.1.so > librpmdb-4.1.so > librpmio-4.1.so > > Some users play too much with --nodeps/--force while installing or > upgrading packages. > > From ms-nospam-0306 at arcor.de Mon Dec 8 20:21:27 2003 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Mon, 8 Dec 2003 21:21:27 +0100 Subject: build In-Reply-To: References: <200312050757.31175.jkeating@j2solutions.net> <20031205120949.B10663@angus.ind.WPI.EDU> <20031205213353.448d7e7f.ms-nospam-0306@arcor.de> <1070896172.12675.14.camel@bretsony> <20031208190009.6daad1a3.ms-nospam-0306@arcor.de> Message-ID: <20031208212127.4e4f160b.ms-nospam-0306@arcor.de> On Mon, 8 Dec 2003 13:40:14 -0600 (CST), Wade Maxfield wrote: > > Well, in this case, rpm did not require rpmbuild to be upgraded before I > upgraded it to 4.1.1. It did require popt, and one other. :) Please reply below quotes to main context. You _cannot_ upgrade rpm to 4.1.1 when the installed rpm-build requires rpm = 4.1. Somehow you managed to upgrade rpm to 4.1.1 while ignoring the dependencies of the old and installed rpm-build 4.1-1.06 package. It simply smells like --nodeps. -- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From chuckw at quantumlinux.com Mon Dec 8 20:58:42 2003 From: chuckw at quantumlinux.com (Chuck Wolber) Date: Mon, 8 Dec 2003 12:58:42 -0800 (PST) Subject: Novell/progeny to take up redhat legacy services In-Reply-To: <1070896210.11642.4703.camel@chriss2.cait.org> Message-ID: > > If someone lower on the chain breaks a rule/law/precept higher on the > > chain, the group lower on the chain loses. Or as a lawyer I know put > > it, "Herein fail at your peril". > > If you steal RedHat work which is covered under the SLA then you could > be fined. RedHat makes it very clear what you have to pay for and what > you don't. Good Lord, are people really this *DENSE*? For the two zillionth time, *I AM ONLY SPEAKING OF THE GPL'D PORTIONS*! > RHEL is not a free product. You are not free to copy it from computer > to computer. So remove the artwork and the non-gpl'd software and what's left over? A fully functional system... > It is the packaged artwork and possibly some of the configuration > utilities that make it non-free. Strip those out and you can do as you > like. So, like, yeah... Thanks for making that point... -Chuck -- Quantum Linux Laboratories - ACCELERATING Business with Open Technology * Education | -=^ Ad Astra Per Aspera ^=- * Integration | http://www.quantumlinux.com * Support | chuckw at quantumlinux.com "M stands for magic, mystery or matrix; according to taste." --Edward Witten From chuckw at quantumlinux.com Mon Dec 8 21:27:19 2003 From: chuckw at quantumlinux.com (Chuck Wolber) Date: Mon, 8 Dec 2003 13:27:19 -0800 (PST) Subject: Kernel Testing Message-ID: Jesse and I were talking a while back about how "this" is all going to come together. We're pretty sure the RHEL 2.1 updates are a clean move to 7.3 systems and RHEL 3.0 updates are a clean move to 9. Of course this is all "educated" speculation, and all packages will have to be validated to be sure. The only wildcard in our minds at the time was the kernel. It was clear that we'd need some sort of test suite and some design goals. As far as a test suite goes, I ran across the below post from the LKML. I'd been aware of the kernel test suite for a while, but hadn't actually taken the time to deploy it. What I'm wondering is, has anyone on this list spent the time necessary to deploy this in any scale that would be necessary for Fedora Legacy? ------- The Linux Test Project test suite has been released. The latest version of the testsuite contains 2000+ tests for the Linux OS. Our web site also contains other information such as: test results, a Linux test tools matrix, an area for keeping up with fixes for known blocking problems in the 2.5/2.6 kernel releases, technical papers and HowTos on Linux testing, and a code coverage analysis tool. Highlights: + Updated the LTP test driver to handle all real-time signals. + Updated the command tests to ensure better portability. + Added new NFS test, nfs_fsstress, to stress NFS using the fsstress test. + Added new tests for low-level SCSI, virtual SCSI, Asynch IO, & ACL control and management + Applied more bug fixes, patches, and code cleanups. We encourage the community to post results, patches or new tests on our mailing list and use the CVS bug tracking facility to report problems that you might encounter with the test suite. ------- -- Quantum Linux Laboratories - ACCELERATING Business with Open Technology * Education | -=^ Ad Astra Per Aspera ^=- * Integration | http://www.quantumlinux.com * Support | chuckw at quantumlinux.com "M stands for magic, mystery or matrix; according to taste." --Edward Witten From cspencer at cait.org Mon Dec 8 21:49:44 2003 From: cspencer at cait.org (Chris Spencer) Date: Mon, 08 Dec 2003 15:49:44 -0600 Subject: Novell/progeny to take up redhat legacy services In-Reply-To: References: Message-ID: <1070920183.11637.5238.camel@chriss2.cait.org> > Good Lord, are people really this *DENSE*? For the two zillionth time, *I > AM ONLY SPEAKING OF THE GPL'D PORTIONS*! You need to quantify it each time you say it. The confusion on the topic carries on. Yes, people really are that dense. Hence why I repeated the stipulation. You may understand the situation very well but odds are that someone reads the archive or just googles and thinks they have found the loophole. -Chris "There is a lot of speculation and I guess there is going to continue to be a log of speculation until the speculation ends." - George W. Bush on October 18, 1998 From chuckw at quantumlinux.com Mon Dec 8 21:52:17 2003 From: chuckw at quantumlinux.com (Chuck Wolber) Date: Mon, 8 Dec 2003 13:52:17 -0800 (PST) Subject: Novell/progeny to take up redhat legacy services In-Reply-To: <1070920183.11637.5238.camel@chriss2.cait.org> Message-ID: > You may understand the situation very well but odds are that someone > reads the archive or just googles and thinks they have found the > loophole. Good point. I'll remember to sprinkle "GPL'd portions only" liberally from now on ;) -Chuck -- Quantum Linux Laboratories - ACCELERATING Business with Open Technology * Education | -=^ Ad Astra Per Aspera ^=- * Integration | http://www.quantumlinux.com * Support | chuckw at quantumlinux.com "M stands for magic, mystery or matrix; according to taste." --Edward Witten From jkeating at j2solutions.net Mon Dec 8 21:42:50 2003 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 8 Dec 2003 13:42:50 -0800 Subject: Novell/progeny to take up redhat legacy services In-Reply-To: <1070920183.11637.5238.camel@chriss2.cait.org> References: <1070920183.11637.5238.camel@chriss2.cait.org> Message-ID: <200312081342.54687.jkeating@j2solutions.net> On Monday 08 December 2003 13:49, Chris Spencer wrote: > "There is a lot of speculation and I guess there is going to continue > to be a log of speculation until the speculation ends." - George W. > Bush on October 18, 1998 Did Bush really say "log" in there, or did you typo the quote? -- Jesse Keating RHCE MCSE (geek.j2solutions.net) Fedora Legacy Team (www.fedora.us/wiki/FedoraLegacy) Mondo DevTeam (www.mondorescue.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From cspencer at cait.org Mon Dec 8 22:02:37 2003 From: cspencer at cait.org (Chris Spencer) Date: Mon, 08 Dec 2003 16:02:37 -0600 Subject: Novell/progeny to take up redhat legacy services In-Reply-To: <200312081342.54687.jkeating@j2solutions.net> References: <1070920183.11637.5238.camel@chriss2.cait.org> <200312081342.54687.jkeating@j2solutions.net> Message-ID: <1070920957.11642.5259.camel@chriss2.cait.org> You know....I am not sure. I will have to check that. I have been rotating the sig for some time and just noticed that over the weekend. Probably my typo. I am pretty sure it was lot not log. -Chris On Mon, 2003-12-08 at 15:42, Jesse Keating wrote: > On Monday 08 December 2003 13:49, Chris Spencer wrote: > > "There is a lot of speculation and I guess there is going to continue > > to be a log of speculation until the speculation ends." - George W. > > Bush on October 18, 1998 > > Did Bush really say "log" in there, or did you typo the quote? "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." - Benjamin Franklin, Historical Review of Pennsylvania, 1759 From cspencer at cait.org Mon Dec 8 22:06:46 2003 From: cspencer at cait.org (Chris Spencer) Date: Mon, 08 Dec 2003 16:06:46 -0600 Subject: Novell/progeny to take up redhat legacy services In-Reply-To: <200312081342.54687.jkeating@j2solutions.net> References: <1070920183.11637.5238.camel@chriss2.cait.org> <200312081342.54687.jkeating@j2solutions.net> Message-ID: <1070921206.11636.5267.camel@chriss2.cait.org> I can confirm that log is wrong. The correct quote is: "There is a lot of speculation and I guess there is going to continue to be a lot of speculation until the speculation ends." On whether he'll run for President, Austin-American Statesman, 18th October 1998 -Chris On Mon, 2003-12-08 at 15:42, Jesse Keating wrote: > On Monday 08 December 2003 13:49, Chris Spencer wrote: > > "There is a lot of speculation and I guess there is going to continue > > to be a log of speculation until the speculation ends." - George W. > > Bush on October 18, 1998 > > Did Bush really say "log" in there, or did you typo the quote? "Restriction of free thought and free speech is the most dangerous of all subversions. It is the one un-American act that could most easily defeat us." - Supreme Court Justice William O. Douglas From maxfield at one.ctelcom.net Mon Dec 8 22:34:20 2003 From: maxfield at one.ctelcom.net (Wade Maxfield) Date: Mon, 8 Dec 2003 16:34:20 -0600 (CST) Subject: build In-Reply-To: <20031208212127.4e4f160b.ms-nospam-0306@arcor.de> References: <200312050757.31175.jkeating@j2solutions.net> <20031205120949.B10663@angus.ind.WPI.EDU> <20031205213353.448d7e7f.ms-nospam-0306@arcor.de> <1070896172.12675.14.camel@bretsony> <20031208190009.6daad1a3.ms-nospam-0306@arcor.de> <20031208212127.4e4f160b.ms-nospam-0306@arcor.de> Message-ID: On Mon, 8 Dec 2003, Michael Schwendt wrote: > From: Michael Schwendt > On Mon, 8 Dec 2003 13:40:14 -0600 (CST), Wade Maxfield wrote: > > > > > Well, in this case, rpm did not require rpmbuild to be upgraded before I > > upgraded it to 4.1.1. It did require popt, and one other. :) > > Please reply below quotes to main context. > ok > You _cannot_ upgrade rpm to 4.1.1 when the installed rpm-build requires > rpm = 4.1. > > Somehow you managed to upgrade rpm to 4.1.1 while ignoring the > dependencies of the old and installed rpm-build 4.1-1.06 package. It > simply smells like --nodeps. > > Hmm. I am getting old. I downloaded from the rpm site (Not RedHat's site) and then installed. the install failed because of popt. and rpm-python, and maybe rpm-devel. I certaintly think I would have picked up rpmbuild (or removed it). That being said, you may be right. However, the directory I downloaded my files to that day doesn't have rpmbuild in it. I'm puzzled right now. Unless rpm.org did not have that dependency that day. Wait, I remember someone doing a -R on rpm [root at rh80 t]# rpm -qpR rpm-4.1.1-1.8x.i386.rpm fileutils shadow-utils popt = 1.7.1 rpmlib(VersionedDependencies) <= 3.0.3-1 /bin/sh /bin/sh /bin/sh rpmlib(CompressedFileNames) <= 3.0.4-1 /bin/sh libbz2.so.1 libc.so.6 libc.so.6(GLIBC_2.0) libc.so.6(GLIBC_2.1) libc.so.6(GLIBC_2.1.3) libc.so.6(GLIBC_2.2) libc.so.6(GLIBC_2.2.3) libc.so.6(GLIBC_2.3) libc.so.6(GLIBC_2.3.2) libpopt.so.0 libpthread.so.0 libpthread.so.0(GLIBC_2.0) libpthread.so.0(GLIBC_2.2) librpm-4.1.so librpmbuild-4.1.so librpmdb-4.1.so librpmio-4.1.so librt.so.1 librt.so.1(GLIBC_2.1) [root at rh80 t]# So, the rpmbuild was not required....right???? wade From jkeating at j2solutions.net Mon Dec 8 22:27:08 2003 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 8 Dec 2003 14:27:08 -0800 Subject: build In-Reply-To: References: <20031208212127.4e4f160b.ms-nospam-0306@arcor.de> Message-ID: <200312081427.08101.jkeating@j2solutions.net> On Monday 08 December 2003 14:34, Wade Maxfield wrote: > So, the rpmbuild was not required....right???? "rpm" does not require rpmbuild, but "rpm-build" requires rpm. -- Jesse Keating RHCE MCSE (geek.j2solutions.net) Fedora Legacy Team (www.fedora.us/wiki/FedoraLegacy) Mondo DevTeam (www.mondorescue.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From mhkohne at discordia.org Tue Dec 9 01:37:01 2003 From: mhkohne at discordia.org (Michael Kohne) Date: Mon, 8 Dec 2003 20:37:01 -0500 (EST) Subject: build In-Reply-To: <1070893064.23038.2.camel@jeremy.dtcc.cc.nc.us> References: <200312050757.31175.jkeating@j2solutions.net> <14367.68.162.99.230.1070740174.squirrel@www.discordia.org> <1070893064.23038.2.camel@jeremy.dtcc.cc.nc.us> Message-ID: <30824.68.162.99.230.1070933821.squirrel@www.discordia.org> Jeremy Portzer said: [snip my quote] > > I also recommend the Red Hat RPM Guide by Eric Foster-Johnson. This is > a much newer book (March 2003) and should you well on your way to fully > understanding RPMs. > http://www.amazon.com/exec/obidos/tg/detail/-/0764549650/102-3644477-2534509?v=glance > [snip sig] Hey thanks! I was unaware of that one. I'd been wondering when someone was going to update Maximum RPM (It's a little out dated in some places now). I'll try to post my kernel rebuild procedures tomorrow. Then I'll find out all the things I'm doing wrong! -- Michael Kohne mhkohne at discordia.org "You should be smarter than the equipment you are trying to operate." -- Matt Osborne From bhughes at elevating.com Tue Dec 9 06:01:46 2003 From: bhughes at elevating.com (Bret Hughes) Date: 09 Dec 2003 00:01:46 -0600 Subject: build In-Reply-To: <20031208190009.6daad1a3.ms-nospam-0306@arcor.de> References: <200312050757.31175.jkeating@j2solutions.net> <20031205120949.B10663@angus.ind.WPI.EDU> <20031205213353.448d7e7f.ms-nospam-0306@arcor.de> <1070896172.12675.14.camel@bretsony> <20031208190009.6daad1a3.ms-nospam-0306@arcor.de> Message-ID: <1070949707.25057.6.camel@bretsony> On Mon, 2003-12-08 at 12:00, Michael Schwendt wrote: > On 08 Dec 2003 09:09:31 -0600, Bret Hughes wrote: > > > > > > rpmbuild: relocation error: rpmbuild: undefined symbol: freeSpecVec > > > > > > > > > > > > > > > here is my rpm list for redhat 8.0. Note that the rpm was upgraded > > > > > because of the hang problem that the standard 4.x rpm from redhat has > > > > > under 8.0. With 4.1.1, the problem does not occur. > > > > > > > > > > [root at rh80 SPECS]# rpm -qa | grep rpm > > > > > > > > > > rpmdb-redhat-8.0-0.20020910 > > > > > rpm-python-4.1.1-1.8x > > > > > rpm2html-1.7-8 > > > > > librpm404-devel-4.0.4-8x.27 > > > > > redhat-rpm-config-8.0-1 > > > > > rpm-4.1.1-1.8x > > > > > rpm404-python-4.0.4-8x.27 > > > > > rpm-build-4.1-1.06 > > > > > > > > This should be rpm-build-4.1.1-1.8x, so it matches your version of RPM. > > > > > > > > > Excellent! DOH! Yes, that was it. I had never heard of rpmbuild > > > before, it appears to be a neat tool. > > > > > > > Isn't this a symptom of a packaging error? seems like there should be a > > dependency built into rpmbuild to match the rpm version. > > The error is to assume that there's no such dependency: ;) > > $ rpm -qR rpm-build | grep rpm > rpm = 4.1.1 > rpmlib(VersionedDependencies) <= 3.0.3-1 > rpmlib(CompressedFileNames) <= 3.0.4-1 > librpm-4.1.so > librpmbuild-4.1.so > librpmdb-4.1.so > librpmio-4.1.so > > Some users play too much with --nodeps/--force while installing or > upgrading packages. > so I guess that a dependency of rpm 4.1.1 is satisfied by both 4.1-1.06 and 4.1.1-1.8x? too minor of an upgrade to trigger a dep error? Bret From skvidal at phy.duke.edu Tue Dec 9 06:08:00 2003 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 09 Dec 2003 01:08:00 -0500 Subject: build In-Reply-To: <1070949707.25057.6.camel@bretsony> References: <200312050757.31175.jkeating@j2solutions.net> <20031205120949.B10663@angus.ind.WPI.EDU> <20031205213353.448d7e7f.ms-nospam-0306@arcor.de> <1070896172.12675.14.camel@bretsony> <20031208190009.6daad1a3.ms-nospam-0306@arcor.de> <1070949707.25057.6.camel@bretsony> Message-ID: <1070950080.18124.131.camel@binkley> > so I guess that a dependency of rpm 4.1.1 is satisfied by both 4.1-1.06 > and 4.1.1-1.8x? > > too minor of an upgrade to trigger a dep error? look closely 4.1.1 != 4.1-1 ver 4.1.1 > ver 4.1 -sv From bhughes at elevating.com Tue Dec 9 15:08:32 2003 From: bhughes at elevating.com (Bret Hughes) Date: 09 Dec 2003 09:08:32 -0600 Subject: build In-Reply-To: <1070950080.18124.131.camel@binkley> References: <200312050757.31175.jkeating@j2solutions.net> <20031205120949.B10663@angus.ind.WPI.EDU> <20031205213353.448d7e7f.ms-nospam-0306@arcor.de> <1070896172.12675.14.camel@bretsony> <20031208190009.6daad1a3.ms-nospam-0306@arcor.de> <1070949707.25057.6.camel@bretsony> <1070950080.18124.131.camel@binkley> Message-ID: <1070982515.25057.13.camel@bretsony> On Tue, 2003-12-09 at 00:08, seth vidal wrote: > > so I guess that a dependency of rpm 4.1.1 is satisfied by both 4.1-1.06 > > and 4.1.1-1.8x? > > > > too minor of an upgrade to trigger a dep error? > > look closely > 4.1.1 != 4.1-1 > > ver 4.1.1 > ver 4.1 > oops you are right. so was this a nodeps thing? Bret From skvidal at phy.duke.edu Tue Dec 9 15:13:01 2003 From: skvidal at phy.duke.edu (seth vidal) Date: 09 Dec 2003 10:13:01 -0500 Subject: build In-Reply-To: <1070982515.25057.13.camel@bretsony> References: <200312050757.31175.jkeating@j2solutions.net> <20031205120949.B10663@angus.ind.WPI.EDU> <20031205213353.448d7e7f.ms-nospam-0306@arcor.de> <1070896172.12675.14.camel@bretsony> <20031208190009.6daad1a3.ms-nospam-0306@arcor.de> <1070949707.25057.6.camel@bretsony> <1070950080.18124.131.camel@binkley> <1070982515.25057.13.camel@bretsony> Message-ID: <1070982781.29742.11.camel@opus> > > > > oops you are right. so was this a nodeps thing? > a nodeps thing? running rpm with rpm --nodeps is almost ALWAYS a bad idea. -sv From chuckw at quantumlinux.com Tue Dec 9 21:41:55 2003 From: chuckw at quantumlinux.com (Chuck Wolber) Date: Tue, 9 Dec 2003 13:41:55 -0800 (PST) Subject: build In-Reply-To: <1070982781.29742.11.camel@opus> Message-ID: > a nodeps thing? > > running rpm with rpm --nodeps is almost ALWAYS a bad idea. *ALWAYS*?? 1) A month ago I had an RPM database corruption that lost about 60% of the package information. I haven't the faintest idea how it happened. None of the usual (and some unusual stuff) would fix it. A quick check showed that it was a database problem only, all the files were still there. I was able to add the missing stuff back into the database by using --nodeps. 2) I prefer to install perl modules via the CPAN tool (even though I am hosting RPMPAN). Some packages require certain perl modules as dependencies. Installing those perl modules and then using --nodeps on the final package was one way of installing. I'm sure there are others. -Chuck -- Quantum Linux Laboratories - ACCELERATING Business with Open Technology * Education | -=^ Ad Astra Per Aspera ^=- * Integration | http://www.quantumlinux.com * Support | chuckw at quantumlinux.com "M stands for magic, mystery or matrix; according to taste." --Edward Witten From jjasen at realityfailure.org Tue Dec 9 22:07:57 2003 From: jjasen at realityfailure.org (John Jasen) Date: Tue, 9 Dec 2003 17:07:57 -0500 (EST) Subject: build (and I guess an introduction) In-Reply-To: Message-ID: On Tue, 9 Dec 2003, Chuck Wolber wrote: > > > > a nodeps thing? > > > > running rpm with rpm --nodeps is almost ALWAYS a bad idea. > > *ALWAYS*?? He said "almost ALWAYS" -- it is very different than "ALWAYS". Maybe it should be as I generally tell people "--force and --nodeps are for people who really know what they're doing. If you think you need them, most likey you do not know what you're doing. :)" I use the big no-nos --nodeps and --force on occasion, depending on the circumstances involved. (... does that mean I don't know what I'm doing?) Most of the time, I've walked away unscathed. A few times, on the boxes I used to screw around with various projects, I've broken things into many many interesting pieces that just didn't want to work right afterwards. X, KDE, mozilla, kernel are a few that come to mind. :) That said, I'm interested in helping out with continued support, just need to get an OK from work. My critical area is RH7.3. I'm also officially interested in RH9, and unofficially interested in RH6.2. I have a little 'leverage' with my local hardware vendor, who is also very interested in continued support of 7.3 and 9, so if there are any components needed by the project, I can ask. I might also get them to set a mirror up somewhere. Maybe. :) I have some experience in dealing with RPM spec files, adding in patches, and rebuilding, which pending permission, I'd be happy to trade. -- -- John E. Jasen (jjasen at realityfailure.org) -- User Error #2361: Please insert coffee and try again. From rostetter at mail.utexas.edu Tue Dec 9 22:57:35 2003 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Tue, 9 Dec 2003 16:57:35 -0600 Subject: build In-Reply-To: References: Message-ID: <20031209165735.1t3404okkg8occ0g@mail.ph.utexas.edu> Quoting Chuck Wolber : > > a nodeps thing? > > > > running rpm with rpm --nodeps is almost ALWAYS a bad idea. ^^^^^^^^^^^^^^ > *ALWAYS*?? No, "almost ALWAYS". -- Eric Rostetter From chuckw at quantumlinux.com Tue Dec 9 23:23:22 2003 From: chuckw at quantumlinux.com (Chuck Wolber) Date: Tue, 9 Dec 2003 15:23:22 -0800 (PST) Subject: build (and I guess an introduction) In-Reply-To: Message-ID: > He said "almost ALWAYS" -- it is very different than "ALWAYS". Maybe it > should be as I generally tell people "--force and --nodeps are for > people who really know what they're doing. If you think you need them, > most likey you do not know what you're doing. :)" Doh, you're right. Selective reading. Damn! Sorry Seth. -Chuck -- Quantum Linux Laboratories - ACCELERATING Business with Open Technology * Education | -=^ Ad Astra Per Aspera ^=- * Integration | http://www.quantumlinux.com * Support | chuckw at quantumlinux.com "M stands for magic, mystery or matrix; according to taste." --Edward Witten From chuckw at quantumlinux.com Tue Dec 9 23:26:53 2003 From: chuckw at quantumlinux.com (Chuck Wolber) Date: Tue, 9 Dec 2003 15:26:53 -0800 (PST) Subject: build In-Reply-To: <20031209165735.1t3404okkg8occ0g@mail.ph.utexas.edu> Message-ID: > > > a nodeps thing? > > > > > > running rpm with rpm --nodeps is almost ALWAYS a bad idea. > ^^^^^^^^^^^^^^ > > > *ALWAYS*?? > > No, "almost ALWAYS". How embarassing... Sorry for that one. -Chuck -- Quantum Linux Laboratories - ACCELERATING Business with Open Technology * Education | -=^ Ad Astra Per Aspera ^=- * Integration | http://www.quantumlinux.com * Support | chuckw at quantumlinux.com "M stands for magic, mystery or matrix; according to taste." --Edward Witten From jdaily at progeny.com Wed Dec 10 00:10:12 2003 From: jdaily at progeny.com (John R. Daily) Date: Tue, 09 Dec 2003 19:10:12 -0500 Subject: 7.x update service In-Reply-To: Your message of "Wed, 03 Dec 2003 10:58:23 EST." <20031203160441.CD8A9637C3@morimoto.progeny.com> References: <20031203160441.CD8A9637C3@morimoto.progeny.com> Message-ID: <20031210001012.E505763781@morimoto.progeny.com> At (time_t)1070467103 John Daily wrote: > we do not expect to provide updates for 8.0 or 9.0 unless there > is a large demand from our customers for that service... As you may have noticed on the news sites, we have seen quite a bit of demand for 8.0 and 9, and have decided to provide support for them. -- John R. Daily jdaily at progeny.com Director of Technology Progeny Linux Systems Master of the ephemeral epiphany From linux at bytebot.net Wed Dec 10 02:05:25 2003 From: linux at bytebot.net (Colin Charles) Date: Wed, 10 Dec 2003 10:05:25 +0800 Subject: Progeny does RH8/9 as well Message-ID: <1071021924.30612.61.camel@hermione> If you didn't already catch it: http://www.progeny.com/products/transition/ Progeny is providing the same support as they are for RH7.x, for the same $5 fee. Same deal, at least till December 31st 2004, but quite possibly later. -- Colin Charles, byte at aeon.com.my http://www.bytebot.net/ From smoogen at lanl.gov Wed Dec 10 16:06:50 2003 From: smoogen at lanl.gov (Stephen Smoogen) Date: Wed, 10 Dec 2003 09:06:50 -0700 Subject: 7.x update service In-Reply-To: <20031210001012.E505763781@morimoto.progeny.com> References: <20031203160441.CD8A9637C3@morimoto.progeny.com> <20031210001012.E505763781@morimoto.progeny.com> Message-ID: <1071072410.12539.8.camel@smoogen1.lanl.gov> How can Fedora Legacy and Progeny work together on this? The last thing we want is quips in 2 months of one group stealing SRPMS from another who is doing all the work... [IE this is not UnitedLinux.] On Tue, 2003-12-09 at 17:10, John R. Daily wrote: > At (time_t)1070467103 John Daily wrote: > > > we do not expect to provide updates for 8.0 or 9.0 unless there > > is a large demand from our customers for that service... > > As you may have noticed on the news sites, we have seen quite > a bit of demand for 8.0 and 9, and have decided to provide > support for them. > > -- > John R. Daily jdaily at progeny.com > Director of Technology Progeny Linux Systems > Master of the ephemeral epiphany > > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-legacy-list -- Stephen John Smoogen smoogen at lanl.gov Los Alamos National Lab CCN-5 Sched 5/40 PH: 4-0645 Ta-03 SM-1498 MailStop B255 DP 10S Los Alamos, NM 87545 -- So shines a good deed in a weary world. = Willy Wonka -- From smoogen at lanl.gov Wed Dec 10 18:36:16 2003 From: smoogen at lanl.gov (Stephen Smoogen) Date: Wed, 10 Dec 2003 11:36:16 -0700 Subject: SOT: For hardware vendors.. dealing with new hardware Message-ID: <1071081376.12539.77.camel@smoogen1.lanl.gov> Semi Off Topic For hardware vendors who are dealing with putting RHL-7.x onto newer hardware.. I have been working getting aic79xx into the last errata kernels. After 2 days.. I have come to remember why I am not a kernel developer :). Somewhere between the changes in 2.4.20-18 and 2.4.20-24 the driver source code from Adaptec or Justin Gibbs site will compile, but we get consistent kernel panics when running. The system dies in about 2-4 minutes with something similar to this: (scsi1:A:1:0): SCB 129 Packetized Status Overrun>>>>>>>>>>>>>>>>>> Dump Card State Begins <<<<<<<<<<<<<<<<< scsi1: Dumping Card State at program address 0x295 Mode 0x11 Card was paused HS_MAILBOX[0x0] INTCTL[0x80] SEQINTSTAT[0x0] SAVED_MODE[0x11] DFFSTAT[0x0] SCSISIGI[0x24] SCSIPHASE[0x1] SCSIBUS[0x0] LASTPHASE[0x1] SCSISEQ0[0x0] SCSISEQ1[0x12] SEQCTL0[0x10] SEQINTCTL[0x8] SEQ_FLAGS[0xc0] SEQ_FLAGS2[0x4] SSTAT0[0x0] SSTAT1[0x19] SSTAT2[0x0] SSTAT3[0x80] PERRDIAG[0xc0] SIMODE1[0xa4] LQISTAT0[0x0] LQISTAT1[0x0] LQISTAT2[0x0] LQOSTAT0[0x0] LQOSTAT1[0x0] LQOSTAT2[0x81] Not expecting anyone on the list to have a fix... more of a gotcha to look out for clients who have to have old release on new hardware. -- Stephen John Smoogen smoogen at lanl.gov Los Alamos National Lab CCN-5 Sched 5/40 PH: 4-0645 Ta-03 SM-1498 MailStop B255 DP 10S Los Alamos, NM 87545 -- So shines a good deed in a weary world. = Willy Wonka -- From jkeating at j2solutions.net Wed Dec 10 18:40:36 2003 From: jkeating at j2solutions.net (Jesse Keating) Date: Wed, 10 Dec 2003 10:40:36 -0800 Subject: SOT: For hardware vendors.. dealing with new hardware In-Reply-To: <1071081376.12539.77.camel@smoogen1.lanl.gov> References: <1071081376.12539.77.camel@smoogen1.lanl.gov> Message-ID: <200312101040.36555.jkeating@j2solutions.net> On Wednesday 10 December 2003 10:36, Stephen Smoogen wrote: > Not expecting anyone on the list to have a fix... more of a gotcha to > look out for clients who have to have old release on new hardware. Which version of the driver source are you using? -- Jesse Keating RHCE MCSE (geek.j2solutions.net) Fedora Legacy Team (www.fedora.us/wiki/FedoraLegacy) Mondo DevTeam (www.mondorescue.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From smoogen at lanl.gov Wed Dec 10 18:57:33 2003 From: smoogen at lanl.gov (Stephen Smoogen) Date: Wed, 10 Dec 2003 11:57:33 -0700 Subject: SOT: For hardware vendors.. dealing with new hardware In-Reply-To: <200312101040.36555.jkeating@j2solutions.net> References: <1071081376.12539.77.camel@smoogen1.lanl.gov> <200312101040.36555.jkeating@j2solutions.net> Message-ID: <1071082653.12539.82.camel@smoogen1.lanl.gov> I have tried both with 2.0.2 and release 20031106 [smoogen at smoogen1 temp]$ md5sum aic79* 6012bcdb7c79e50be43dfb5e0c8ff594 aic79xx-2.0.2-source.tar.gz dcb9aa0cd8179f81aaae4822eb7c2018 aic79xx-linux-2.4-20031106-tar.gz and using the kernel-source RPM as supplied by RH so that I have all the other 'fixes'. Merged the /drivers/scsi/Makefile and such to make sure I had correct items. Now is when you are supposed to say: did you do the obvious XYZ, and I will argue that I did.. and then realize that I didnt :).. On Wed, 2003-12-10 at 11:40, Jesse Keating wrote: > On Wednesday 10 December 2003 10:36, Stephen Smoogen wrote: > > Not expecting anyone on the list to have a fix... more of a gotcha to > > look out for clients who have to have old release on new hardware. > > Which version of the driver source are you using? -- Stephen John Smoogen smoogen at lanl.gov Los Alamos National Lab CCN-5 Sched 5/40 PH: 4-0645 Ta-03 SM-1498 MailStop B255 DP 10S Los Alamos, NM 87545 -- So shines a good deed in a weary world. = Willy Wonka -- From jkeating at j2solutions.net Wed Dec 10 19:17:50 2003 From: jkeating at j2solutions.net (Jesse Keating) Date: Wed, 10 Dec 2003 11:17:50 -0800 Subject: SOT: For hardware vendors.. dealing with new hardware In-Reply-To: <1071082653.12539.82.camel@smoogen1.lanl.gov> References: <1071081376.12539.77.camel@smoogen1.lanl.gov> <200312101040.36555.jkeating@j2solutions.net> <1071082653.12539.82.camel@smoogen1.lanl.gov> Message-ID: <200312101117.54909.jkeating@j2solutions.net> On Wednesday 10 December 2003 10:57, Stephen Smoogen wrote: > I have tried both with 2.0.2 and release 20031106 > > [smoogen at smoogen1 temp]$ md5sum aic79* > 6012bcdb7c79e50be43dfb5e0c8ff594 aic79xx-2.0.2-source.tar.gz > dcb9aa0cd8179f81aaae4822eb7c2018 aic79xx-linux-2.4-20031106-tar.gz > > and using the kernel-source RPM as supplied by RH so that I have all > the other 'fixes'. Merged the /drivers/scsi/Makefile and such to make > sure I had correct items. > > Now is when you are supposed to say: did you do the obvious XYZ, and > I will argue that I did.. and then realize that I didnt :).. Ah, I think the latest I've worked with is 1.3.10. It was working for 2.4.20-20 on RHL9, I have yet to rebuild it for 2.4.20-24. I really should try that and get back to you. -- Jesse Keating RHCE MCSE (geek.j2solutions.net) Fedora Legacy Team (www.fedora.us/wiki/FedoraLegacy) Mondo DevTeam (www.mondorescue.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From skvidal at phy.duke.edu Wed Dec 10 19:29:02 2003 From: skvidal at phy.duke.edu (seth vidal) Date: 10 Dec 2003 14:29:02 -0500 Subject: 7.x update service In-Reply-To: <1071072410.12539.8.camel@smoogen1.lanl.gov> References: <20031203160441.CD8A9637C3@morimoto.progeny.com> <20031210001012.E505763781@morimoto.progeny.com> <1071072410.12539.8.camel@smoogen1.lanl.gov> Message-ID: <1071084542.32740.21.camel@opus> On Wed, 2003-12-10 at 11:06, Stephen Smoogen wrote: > How can Fedora Legacy and Progeny work together on this? The last thing > we want is quips in 2 months of one group stealing SRPMS from another > who is doing all the work... [IE this is not UnitedLinux.] > My very brief take on this: - If there is anything I work on that helps keep systems secure/patched/whatever for 7.X and/or 9 then I would LOVE For anyone else to pick them up and use them, charge for them, whatever. If it means keeping systems from being cracked and causing pain elsewhere I'm for it. -sv From maxfield at one.ctelcom.net Wed Dec 10 19:31:24 2003 From: maxfield at one.ctelcom.net (Wade Maxfield) Date: Wed, 10 Dec 2003 13:31:24 -0600 (CST) Subject: from left field Message-ID: I'm learning as I go. I'm testing things out so I can learn to do source builds and patches for freedom, justice and the RedHat Way under fedora! I am trying to get a package into redhat from another direction, as I did not see the package available on rpmfind, etc. So, I pull down grace source from mandrake, pull down the t1lib-devel source and the netcdf source mandrake rpms and build and install the latter. Rather painless, except for the search. Now, I try rpmbuild -bb grace.spec. It goes well, down to the last. Now, I'm a bit puzzled, and this will probably clue me in on a huge lot of things. I download the grace tarball, and it builds just fine. the grace source rpm does not. Here is my error updating cache ./config.cache creating ./config.status creating Make.conf creating config.h + %make /var/tmp/rpm-tmp.80724: line 46: fg: no job control error: Bad exit status from /var/tmp/rpm-tmp.80724 (%build) I suspect something different between redhat and mandrake. However, the previous versions of mandrake rpms compiled just fine. Looking at the rpm-tmp.80274 file, line 46 is %make make is indeed a good command. Is the % causing the problem??? Is this a source RPM issue, or is it Stupid User Tricks? thanks, wade From jdaily at progeny.com Wed Dec 10 23:09:01 2003 From: jdaily at progeny.com (John Daily) Date: Wed, 10 Dec 2003 18:09:01 -0500 Subject: 7.x update service In-Reply-To: Your message of "Wed, 10 Dec 2003 09:06:50 MST." <1071072410.12539.8.camel@smoogen1.lanl.gov> References: <20031203160441.CD8A9637C3@morimoto.progeny.com> <20031210001012.E505763781@morimoto.progeny.com> <1071072410.12539.8.camel@smoogen1.lanl.gov> Message-ID: <20031210231038.4F9F063787@morimoto.progeny.com> Stephen Smoogen wrote: > How can Fedora Legacy and Progeny work together on this? The last=20 > thing we want is quips in 2 months of one group stealing SRPMS from=20 > another who is doing all the work... [IE this is not UnitedLinux.] I'd like to table this discussion for now. In a few months, when we've all had some experience doing the work, both groups should have a much better feel for the problems we face, and such a discussion will be more meaningful. In reference to your stated concern: as I posted in my original note, we do not plan to redistribute your work. -- John R. Daily jdaily at progeny.com Director of Technology Progeny Linux Systems Master of the ephemeral epiphany From J.S.Peatfield at damtp.cam.ac.uk Thu Dec 11 01:56:15 2003 From: J.S.Peatfield at damtp.cam.ac.uk (Jon Peatfield) Date: Thu, 11 Dec 2003 01:56:15 +0000 Subject: RH 8.0 support - a(nother) volunteer Message-ID: Just finally got round to subscribing to the list rather than lurking and just reading the archives every other weekend... On Sun, 9 Nov 2003 11:34:40 -0800 wrote: > On Sunday 09 November 2003 11:28, Miskell, Craig wrote: > > Where do I sign? > > You just did. > > Seriously though when we launch the server and website (hopefully at the > end of this month) there will be a section there for developer/member sign > up, where you'll be asked for your particulars, and then we'll have a > running list of who all is on the team. Are the server sites mentioned above up/running now? If so can someone point me at them? My department currently has ~180 RH80/x86 machines which (for various reasons) can't possibly all be upgraded to RH9 (or Fedora-Core-1) by 2003-Dec-31. I could try to explain why we didn't go to RH9 but that seems to cause flames in some parts :-) [ We havn't yet had time to elimanate our last few RH62/7x machines so we already spend far too much effort building stuff for them. I plan to get those killed off (or heavily firewalled) before the end of the year. ] So anyway I'm willing to volunteer some of my time (and cpu for building stuff etc) towards keeping RH80/x86 alive wrt security patches etc (I don't really care about anything else -- if there is a non security-related bug then we must be coping already :-). Does anyone have any estimates of the total time/effort needed to perform the relevant tests/builds/qa for a distro? That is roughly how many people will I have to drum up (scrape from other places etc), to be able to actually likely to be able to keep the RH8.0 stuff fairly close to being secure? e.g. If we have 4 volunteers for RH80/x86 would that be enough? Can I assume that someone has already worked out the logistics for GPG keysigning etc? If I'm helping build/test stuff who do I need to know to get someone to trust that a package I provide an update for is safe to be signed by the fedora-legacy keys? Would it require me to be known to the right cabal? BTW I'm also seriously considering (partly at least) switching to Debian since I also have 45+ Alphas and it seems that nothing but Debian supports those now. Others here seem keen to push us towards using SuSy, but that seems more effort than supporting RH80 until we can move to a FC1 based system. I'd be interested in helping test Fedora-Core on Alpha systems but I guess that would be a different project :-) --Jon Jon Peatfield, Computer Officer, DAMTP, University of Cambridge Mail: jp107 at damtp.cam.ac.uk Web: http://www.damtp.cam.ac.uk/ From admin at cs.montana.edu Tue Dec 16 04:46:29 2003 From: admin at cs.montana.edu (Lucas Albers) Date: Mon, 15 Dec 2003 21:46:29 -0700 (MST) Subject: 7.x update service In-Reply-To: <1071072410.12539.8.camel@smoogen1.lanl.gov> References: <20031203160441.CD8A9637C3@morimoto.progeny.com> <20031210001012.E505763781@morimoto.progeny.com> <1071072410.12539.8.camel@smoogen1.lanl.gov> Message-ID: <2953.216.166.133.165.1071549989.squirrel@www.cs.montana.edu> > How can Fedora Legacy and Progeny work together on this? The last thing > we want is quips in 2 months of one group stealing SRPMS from another > who is doing all the work... [IE this is not UnitedLinux.] > big f deal. If people want to get fedora legacy for their machines then they can do that. If they want to pay money for progeny updates, who does that hurt? No one. I am forced by my SLA agreement to have some sort of vendor contract on my critical systems, so yeah. I'll continue to work/complain/improve about things on the fedora legacy project. And you know what? I'm getting a service update contract for my 2 critical machines from progeny, as long as they don't force me to install a stupid gui. On my other 140 boxes I'll use fedora legacy...whatever is easiest....I can keep using apt-get on those machines. GPL goes both ways! It's not called stealing it's calling sharing. The (enemy?) of linux is certainly not other distributions of linux. I don't see anthing wrong with sharing...it's not called stealing...it's called the open source development model. --Luke From admin at cs.montana.edu Tue Dec 16 04:46:56 2003 From: admin at cs.montana.edu (Lucas Albers) Date: Mon, 15 Dec 2003 21:46:56 -0700 (MST) Subject: 7.x update service Message-ID: <2953.216.166.133.165.1071550016.squirrel@www.cs.montana.edu> > How can Fedora Legacy and Progeny work together on this? The last thing > we want is quips in 2 months of one group stealing SRPMS from another > who is doing all the work... [IE this is not UnitedLinux.] > big f deal. If people want to get fedora legacy for their machines then they can do that. If they want to pay money for progeny updates, who does that hurt? No one. I am forced by my SLA agreement to have some sort of vendor contract on my critical systems, so yeah. I'll continue to work/complain/improve about things on the fedora legacy project. And you know what? I'm getting a service update contract for my 2 critical machines from progeny, as long as they don't force me to install a stupid gui. On my other 140 boxes I'll use fedora legacy...whatever is easiest....I can keep using apt-get on those machines. GPL goes both ways! It's not called stealing it's calling sharing. The (enemy?) of linux is certainly not other distributions of linux. I don't see anthing wrong with sharing...it's not called stealing...it's called the open source development model. --Luke From chuckw at quantumlinux.com Tue Dec 16 05:34:01 2003 From: chuckw at quantumlinux.com (Chuck Wolber) Date: Mon, 15 Dec 2003 21:34:01 -0800 (PST) Subject: 7.x update service In-Reply-To: <2953.216.166.133.165.1071549989.squirrel@www.cs.montana.edu> Message-ID: > I don't see anthing wrong with sharing...it's not called stealing...it's > called the open source development model. There's a stigma attached to all software in the minds of the general public thanks to the efforts of certain proprietary software companies. There are documented cases of people outright refusing donations of GPL'd software because of this. This is why I made such a big stink earlier about people paying for (the GPL'd portions of) RHEL software when they didn't have to. What I found pretty funny was, even on this list, people's knee-jerk reaction was to assume I was some leech looking for a free ride. That couldn't be further from the truth... -Chuck -- Quantum Linux Laboratories - ACCELERATING Business with Open Technology * Education | -=^ Ad Astra Per Aspera ^=- * Integration | http://www.quantumlinux.com * Support | chuckw at quantumlinux.com "You know what you get after putting 30 years into a company? You're looking at it." -Downsized CIO of a major insurance carrier. From nphilipp at redhat.com Tue Dec 16 14:29:17 2003 From: nphilipp at redhat.com (Nils Philippsen) Date: Tue, 16 Dec 2003 15:29:17 +0100 Subject: from left field In-Reply-To: References: Message-ID: <1071584957.6272.7.camel@wombat.tiptoe.de> On Wed, 2003-12-10 at 20:31, Wade Maxfield wrote: > Here is my error > > updating cache ./config.cache > creating ./config.status > creating Make.conf > creating config.h > + %make > /var/tmp/rpm-tmp.80724: line 46: fg: no job control > error: Bad exit status from /var/tmp/rpm-tmp.80724 (%build) > > > > I suspect something different between redhat and mandrake. However, > the previous versions of mandrake rpms compiled just fine. > > Looking at the rpm-tmp.80274 file, line 46 is > > %make > > make is indeed a good command. Is the % causing the problem??? Yes. > Is this a source RPM issue, or is it Stupid User Tricks? Stupid RPM macro tricks ;-). Mandrake's RPM has a "%make" macro which likely will get expanded to "make" with some options. Red Hat's RPM doesn't have a "%make" macro -- replace it with "make" and you should be fine. Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -- B. Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -------------- 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 warren at togami.com Wed Dec 24 12:46:53 2003 From: warren at togami.com (Warren Togami) Date: Wed, 24 Dec 2003 02:46:53 -1000 Subject: Fedora Legacy Launch Plan (draft 2) Message-ID: <3FE98ABD.7060506@togami.com> The following is the Fedora Legacy Plan (draft 2). This plan will impact the future of older fedora.us repositories so fedora.us developers need to pay careful attention. The purpose of this draft is mainly to make the plan public and invite questions, but we are essentially pushing forward with this plan NOW. Read the following post for details about what this means for Fedora Legacy users and developers. The below guidelines and procedures go a long way to launching a viable project largely based upon already proven & existing fedora.us infrastructure and procedures, with minor modifications necessary for Legacy. ***** Fedora Legacy Launch Plan (draft 2) ***** The Fedora Legacy project will use fedoralegacy.org as the home page. This home page will contain: 1. Documentation & HOWTO Since Legacy will use the existing download.fedora.us structure and mirrors, HOWTO usage would basically be exactly how people us fedora.us today, except perhaps only "os" and "updates" channels. 2. Listings of package update details 3. link to bugzilla.fedora.us This bugzilla serves as both the problem tracker and package submission & QA. 4. Mailing lists including announce, discuss, and devel We need to request adding these lists at redhat.com. fedora.us will eventually become the Fedora Legacy project. This means that all of the existing project infrastructure will be leveraged in the community based maintenance of Legacy packages on EOL distributions. As mentioned above download.fedora.us and the many exisiting mirrors will carry the Fedora Legacy packages within the "updates" channel. Repository users have the option of using the fedora.us Extras stable/testing/unstable repositories too. GPG use requirement Like the previous fedora.us development, all Fedora Legacy developers are required to use GPG in a proper manner in all communications of substance. This allows messages and packages to be verifiable back to individuals. Most importantly this enables building the corpus of historical evidence necessary for anyone to read, verify GPG signatures, and decide based upon the contributor's good advice if they are to be trusted or not. This is part of the "web of trust" concept. Fedora Legacy project will continue to use bugzilla.fedora.us in almost exactly the same way currently used by fedora.us Extras. The only difference will be the package release tags and location within the repository will be different from the fedora.us Extras packages. The %release tag contains only a number incremented from the release number of the previous EOL distribution package, then ".legacy" appended to the end to make it clear that this is a Fedora Legacy package. evolution-1.2.2-5 This is the latest official RH update evolution-1.2.2-6.legacy This would be a theoretical package name of the Fedora Legacy update. Some cases like the kernel package has a distribution version at the end. The Fedora Legacy package naming will be treated accordingly. kernel-2.4.20-27.8 kernel-2.4.20-27.9 kernel-2.4.20-28.8.legacy kernel-2.4.20-28.9.legacy Legacy packages are to be published in the RPMS.updates channel along with the existing official updates from the EOL distribution. This means that existing users of fedora.us mirrors will continue to benefit from security updates. Users can choose between using only the base "os" and "updates" channels for the core packages, or adding the Extras channels stable/testing/unstable for more functionality and package choices. Package development priority is is focused on mainly security updates of the core distribution "os" and "updates" channels. We will keep an eye on security advisories for the Extras packages but they are lower priority than the base distribution. Network exposed services have the highest priority, while client applications have lower development priority. Fedora Legacy packages in the "updates" channel may NEVER upgrade the version. Instead these packages may be only patched, unless consensus dictates that we must do otherwise. Updates are allowed primarily for security reasons, but sometimes bugfix updates can be allowed if consensus agrees it is serious enough. Legacy packages in QA testing will be placed in the fedora.us updates-testing repository for functionality and stability testing before publication. We still need to discuss how we need to change the publication requirements and "trusted" status for Legacy packagers as the scope and people involved differ greatly from the fedora.us Extras development. Please read the existing fedora.us Package Submission & QA procedure page and suggest ways to modify that procedure for Fedora Legacy. http://www.fedora.us/wiki/PackageSubmissionQAPolicy fedora.us Package Submission & QA Policy What does this mean for the future of fedora.us and Extras? Extras will probably no longer exist at fedora.us for newer distributions after being merged into fedora.redhat.com Extras around FC2 time. fedora.redhat.com probably will not have three levels of Extras (stable/testing/unstable) but I personally am pushing for two levels (stable/unstable). Existing Extras packages for older distributions served by Legacy will sometimes be updated in version by the Extras package maintainer in the case of popular client applications like gaim. Historically fedora.us Extras packages have been of nit-picky top quality, but this will wane. Extras packages will not change much mainly due to lack of interest and time by developers, and new additions will be disallowed after a certain cut-off date. It is the responsibility of all Fedora developers and users to watch for security advisories and report when package updates are needed in the Extras repository. Warren Togami warren at togami.com From warren at togami.com Wed Dec 24 13:13:10 2003 From: warren at togami.com (Warren Togami) Date: Wed, 24 Dec 2003 03:13:10 -1000 Subject: Summary: Fedora Legacy Launch Message-ID: <3FE990E6.9030201@togami.com> This post summarizes the previous launch plan in simple terms: What does this mean for users? ============================== Use fedora.us repositories for "os" and "updates" with apt-get or yum tools today, and you are already set to automatically pull Fedora Legacy updates after distribution end-of-life. Fedora Legacy updates will be published in the "updates" tree along with existing distribution updates. Yeah... the RH7.X trees at fedora.us are not yet launched. I'm working on that and they should be online before the New Year. Watch this list for more information as it happens. I'm thinking to do only RH7.2 and RH7.3 at first unless there is strong demand for RH7.1 or RH7.0. What does this mean for testers? ================================ Soon the "updates-testing" channel will be created in each distribution tree. Candidate Fedora Legacy updates will be placed in this channel so they can be easily downloaded, installed and tested. After enough positive feedback through publication policies that we need to discuss (read below) they will move to the "updates" channel. In order to raise the bar of credibility necessary for updates-testing feedback, I would suggest that GPG clearsigned messages be required for such feedback. This helps to cut down on half-hearted "works for me" posts which are totally not useful. Thoughts? What does this mean for developers? =================================== As mentioned in the previous Plan (draft 2) post, we are in serious need of discussing the policy changes necessary from the current fedora.us procedures for Fedora Legacy development. It is your responsibility to CAREFULLY READ the fedora.us documents, read through many fedora.us Bugzilla reports, and suggest ways of changing it. Given that so few people have even suggested methods of governace of Fedora Legacy Project, I am suggesting now that this project be run in a very similar way to the way fedora.us runs. The main changes in policy will be mainly different thresholds for QA, updates-testing feedback and who is "trusted", and how one can gain "trust". Feel free to comment about & ask questions about other aspects of the procedure though. As the previous post indicated, GPG is an ABSOLUTE REQUIREMENT. If you do not already know how to use it properly, talk to the folks in fedora-devel-list. After EOL happens, it is up to YOUR PARTICIPATION and VIGILANCE to watch the security advisories and kick-start the QA process ASAP at each occurance. I personally am here mainly to give the community this framework of policy and infrastructure to work within. I personally will not be able to spend a lot of time on Legacy development, so the long term viability of this project relies entirely on you. Otherwise... I personally am fine buying Progeny's service for my own servers. $5/mo is a bargain for my time. I would much prefer to eat my own dog food though, as I am a strong believer in the collaborative development model. Warren Togami warren at togami.com From jkeating at j2solutions.net Mon Dec 29 22:32:12 2003 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 29 Dec 2003 14:32:12 -0800 Subject: Website, and review of Warren's proposal Message-ID: <200312291432.17748.jkeating@j2solutions.net> I've secured the "fedoralegacy.org" domain, and I have put up a quick text website. This has a call for webdev help, and a repost of Warren's proposal. Please read through it and prepare your comments, or OKs. We need feedback on it. I myself will post my thoughts tonight when I get home from work. Thanks! http://www.fedoralegacy.org -- Jesse Keating RHCE MCSE (geek.j2solutions.net) Fedora Legacy Team (www.fedora.us/wiki/FedoraLegacy) Mondo DevTeam (www.mondorescue.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From Bernd.Bartmann at sohanet.de Mon Dec 29 22:50:57 2003 From: Bernd.Bartmann at sohanet.de (Bernd Bartmann) Date: Mon, 29 Dec 2003 23:50:57 +0100 Subject: Fedora Legacy Launch Plan (draft 2) In-Reply-To: <3FE98ABD.7060506@togami.com> References: <3FE98ABD.7060506@togami.com> Message-ID: <3FF0AFD1.5060309@sohanet.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Warren, your proposals look good so far. Just a few questions remain for me: | fedora.us will eventually become the Fedora Legacy project. What's the status of the merge between fedora.us and fedora.redhat.com? | The %release tag contains only a number incremented from the release | number of the previous EOL distribution package, then ".legacy" appended | to the end to make it clear that this is a Fedora Legacy package. | | evolution-1.2.2-5 | This is the latest official RH update | evolution-1.2.2-6.legacy | This would be a theoretical package name of the Fedora Legacy update. | | Some cases like the kernel package has a distribution version at the | end. The Fedora Legacy package naming will be treated accordingly. | | kernel-2.4.20-27.8 | kernel-2.4.20-27.9 | kernel-2.4.20-28.8.legacy | kernel-2.4.20-28.9.legacy Is the .legacy suffix really needed? When the "old" distributions reach EOL it is clear that there will be no more offcial updates from Red Hat/Fedora. So I think .legacy is not needed. What personally worries me a lot is to publish to update/errata packages in timely manner, including announcements and a good errata overview web page. This does not even work for FC1 updates yet. Update annoucements are not GPG signed, posted to the wrong mailing list or we don't even get an announcement at all - like for the latest kernel update *2135. No errata overview page either yet. Is it now consensus that Fedora Legacy will take care about RHL 7.2/7.3/8.0 starting January 1st and RHL 9 after April? Best regards. - -- Dipl.-Ing. (FH) Bernd Bartmann I.S. Security and Network Engineer SoHaNet Technology GmbH / Kaiserin-Augusta-Allee 10-11 / 10553 Berlin Fon: +49 30 214783-44 / Fax: +49 30 214783-46 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE/8K/RkQuIaHu84cIRAmunAKCEdn8bVolrh/K9xBZlUViMivI83gCgp0D/ TNEjtGVuSsE4hf1bQPbYhoU= =eQfB -----END PGP SIGNATURE----- From dan at tucny.com Tue Dec 30 01:03:49 2003 From: dan at tucny.com (Dan Tucny) Date: Tue, 30 Dec 2003 01:03:49 +0000 Subject: Summary: Fedora Legacy Launch In-Reply-To: <3FE990E6.9030201@togami.com> References: <3FE990E6.9030201@togami.com> Message-ID: <1072746229.11359.2.camel@beech.tlns.net> On Wed, 2003-12-24 at 13:13, Warren Togami wrote: > This post summarizes the previous launch plan in simple terms: Both look good to me... Dan From warren at togami.com Tue Dec 30 09:36:45 2003 From: warren at togami.com (Warren Togami) Date: Mon, 29 Dec 2003 23:36:45 -1000 Subject: RPM upgrade discussion Message-ID: <3FF1472D.7030606@togami.com> As we discussed earlier, Fedora Legacy will require an upgrade of rpm as a requirement for all users who choose to use our repository. It is quite clear that we agree upon the rpm upgrade for RH8 and RH9 due to the major stability problems associated with those versions. Any RPM upgrade that is included will only be done so after extensive testing and verification that it does not introduce any other problems. Unanswered Questions for Discussion: 1) What changed about the rpm epoch promotion behavior between rpm-4.2 and rpm-4.2.1? Can somebody please explain this with details and concrete examples? I need to understand why we need to keep the old promotion behavior for the RH9 rpm upgrade as some have mentioned earlier. 2) Should we upgrade to rpm-4.2.x for RH7.x? While the benefit for apt-get would be minimal, the benefit for yum would be immense as that would enable the use of yum-2.x. Another key benefit would be compatibility with the newer RPM GPG signatures. 3) Which specific RPM versions should we use? In my personal experience rpm-4.2-1 from rpm.org and rpm-4.2.1 from FC1 both work very well on RH9, while rpm-4.1.1 works great on RH8, although librpm404-4.0.5 is needed to maintain compatibilty with some packaging tools of that era. Should we upgrade to rpm-4.2.x on RH7.x, RH8 and RH9, or use the above mentioned versions? Axel do you have any improvements to rpm-4.2.x series for the older distributions that we should include? I understand that you have a set of very well tested rpm upgrades. Warren From chuckw at quantumlinux.com Tue Dec 30 09:44:59 2003 From: chuckw at quantumlinux.com (Chuck Wolber) Date: Tue, 30 Dec 2003 01:44:59 -0800 (PST) Subject: RPM upgrade discussion In-Reply-To: <3FF1472D.7030606@togami.com> Message-ID: > 2) Should we upgrade to rpm-4.2.x for RH7.x? While the benefit for > apt-get would be minimal, the benefit for yum would be immense as that > would enable the use of yum-2.x. Another key benefit would be > compatibility with the newer RPM GPG signatures. RPM 4.0.4 is just so damn stable, it'd be hard to risk an upgrade. Also, I must express a bit of ignorance here when it comes to yum, as I didn't realize that *adding* yum would require an RPM upgrade. > Should we upgrade to rpm-4.2.x on RH7.x, RH8 and RH9, or use the above > mentioned versions? Stability is more important than any new feature. -Chuck -- Quantum Linux Laboratories - ACCELERATING Business with Open Technology * Education | -=^ Ad Astra Per Aspera ^=- * Integration | http://www.quantumlinux.com * Support | chuckw at quantumlinux.com "You know what you get after putting 30 years into a company? You're looking at it." -Downsized CIO of a major insurance carrier. From warren at togami.com Tue Dec 30 10:00:25 2003 From: warren at togami.com (Warren Togami) Date: Tue, 30 Dec 2003 00:00:25 -1000 Subject: RPM upgrade discussion In-Reply-To: References: Message-ID: <3FF14CB9.6030607@togami.com> Chuck Wolber wrote: > >>2) Should we upgrade to rpm-4.2.x for RH7.x? While the benefit for >>apt-get would be minimal, the benefit for yum would be immense as that >>would enable the use of yum-2.x. Another key benefit would be >>compatibility with the newer RPM GPG signatures. > > > RPM 4.0.4 is just so damn stable, it'd be hard to risk an upgrade. Also, I > must express a bit of ignorance here when it comes to yum, as I didn't > realize that *adding* yum would require an RPM upgrade. The only issue is yum-1.x is the only version that works with rpm-4.0.4. Warren From chuckw at quantumlinux.com Tue Dec 30 10:07:44 2003 From: chuckw at quantumlinux.com (Chuck Wolber) Date: Tue, 30 Dec 2003 02:07:44 -0800 (PST) Subject: RPM upgrade discussion In-Reply-To: <3FF14CB9.6030607@togami.com> Message-ID: > > RPM 4.0.4 is just so damn stable, it'd be hard to risk an upgrade. > > Also, I must express a bit of ignorance here when it comes to yum, as > > I didn't realize that *adding* yum would require an RPM upgrade. > > The only issue is yum-1.x is the only version that works with rpm-4.0.4. Is there a changelog that covers the delta between yum-1 and yum-2? Or more to the point, can we live with this? -Chuck -- Quantum Linux Laboratories - ACCELERATING Business with Open Technology * Education | -=^ Ad Astra Per Aspera ^=- * Integration | http://www.quantumlinux.com * Support | chuckw at quantumlinux.com "You know what you get after putting 30 years into a company? You're looking at it." -Downsized CIO of a major insurance carrier. From chuckw at quantumlinux.com Tue Dec 30 10:58:39 2003 From: chuckw at quantumlinux.com (Chuck Wolber) Date: Tue, 30 Dec 2003 02:58:39 -0800 (PST) Subject: Fedora Legacy Launch Plan (draft 2) In-Reply-To: <3FE98ABD.7060506@togami.com> Message-ID: > Some cases like the kernel package has a distribution version at the > end. The Fedora Legacy package naming will be treated accordingly. > > kernel-2.4.20-27.8 > kernel-2.4.20-27.9 > kernel-2.4.20-28.8.legacy > kernel-2.4.20-28.9.legacy What do you mean "some" cases? Anything that needs to be backported should have a distro tag, which means that the .legacy part is unnecessary. I think you address that to some degree when you speak of packages in the "updates" channel not being updated, only patched. There's already a long history attached with the various distro versions, it's now our job to continue that sordid trail of backporting/patching. In my mind, that's simply justification for s/legacy/rh$VERSION/ and continuing the portage trail. That all being said, I do agree that in *some* cases, we can upgrade to the latest release version without causing any trouble (fileutils, etc). > It is the responsibility of all Fedora developers and users to watch for > security advisories and report when package updates are needed in the > Extras repository. I've been on openssh-announce during the last two semi-major security updates and haven't seen a single post (I hope I just missed it, but at least one of them was due to a documented list "burp"). That makes me nervous that I'll have to join a high volume dev list just to keep abreast of the security notices. If you aren't a developer, and want to help, but are too damn lazy to write documentation, simply parking yourself on a dev list and scanning keywords would be a *HUGE* help. There's no need to worry about duplication of work since "more eyes make shallow bugs" (Alan Cox IIRC). If you need a suggestion about which list to park yourself on, please feel free to ask. I'll point you in the right direction. -Chuck -- Quantum Linux Laboratories - ACCELERATING Business with Open Technology * Education | -=^ Ad Astra Per Aspera ^=- * Integration | http://www.quantumlinux.com * Support | chuckw at quantumlinux.com "You know what you get after putting 30 years into a company? You're looking at it." -Downsized CIO of a major insurance carrier. From warren at togami.com Tue Dec 30 11:18:58 2003 From: warren at togami.com (Warren Togami) Date: Tue, 30 Dec 2003 01:18:58 -1000 Subject: Fedora Legacy Launch Plan (draft 2) In-Reply-To: References: Message-ID: <3FF15F22.5030207@togami.com> Chuck Wolber wrote: > >>Some cases like the kernel package has a distribution version at the >>end. The Fedora Legacy package naming will be treated accordingly. >> >>kernel-2.4.20-27.8 >>kernel-2.4.20-27.9 >>kernel-2.4.20-28.8.legacy >>kernel-2.4.20-28.9.legacy > > > What do you mean "some" cases? Anything that needs to be backported should > have a distro tag, which means that the .legacy part is unnecessary. I > think you address that to some degree when you speak of packages in the > "updates" channel not being updated, only patched. There's already a long > history attached with the various distro versions, it's now our job to > continue that sordid trail of backporting/patching. In my mind, that's > simply justification for s/legacy/rh$VERSION/ and continuing the portage > trail. > > That all being said, I do agree that in *some* cases, we can upgrade to > the latest release version without causing any trouble (fileutils, etc). I believe we can sanely and easily choose naming on a case-by-case basis. We only need to follow precedent. This is not a problem. We disagree about having ".legacy" at the end. I personally don't see a problem in having a longer filename since it *should* be handled automatically by tools. I believe we should have it for two reasons: 1) Clear separation between the official RH/FC updates and Legacy updates. 2) Repository tags are encouraged for all non-FC and non-FE repositories. I suppose we could have a shorter abbreviation of legacy, but I can't think of anything that looks good. I suppose we could also drop it entirely, but I would encourage not dropping it for the above reasons. Warren From Axel.Thimm at physik.fu-berlin.de Tue Dec 30 11:22:38 2003 From: Axel.Thimm at physik.fu-berlin.de (Axel Thimm) Date: Tue, 30 Dec 2003 12:22:38 +0100 Subject: RPM upgrade discussion In-Reply-To: <3FF1472D.7030606@togami.com> References: <3FF1472D.7030606@togami.com> <3FF1472D.7030606@togami.com> Message-ID: <20031230112238.GB13067@neu.nirvana> If this mail is too long: You probably don't want to upgrade rpm for doing conservative, backported (security) bugfixes. Also my recommendation would be to use Progeny's services, or go straight to RHEL2/3, as I doubt that in two days legacy will be offering security rpms. On Mon, Dec 29, 2003 at 11:36:45PM -1000, Warren Togami wrote: > As we discussed earlier, Fedora Legacy will require an upgrade of rpm as > a requirement for all users who choose to use our repository. It is > quite clear that we agree upon the rpm upgrade for RH8 and RH9 due to > the major stability problems associated with those versions. Personally I would also upgrade rpm (and in ATrpms' legacy support I am doing so), but for the target group of legacy I would question this issue for the following reasons: o Red Hat never made rpm.org's errata official for any reasons they may have. I suggest asking why. Probably they do not consider the rpm upgrades stable enough. This is a strong signal not to go that way. o rpm up to 4.2.1 still eats up your database occasionally. rpm 4.2.2 hasn't any indication in the changelog about having found the nasty bug (which is probably not in rpm, but db4). It is so badly reproducable that Jeff hasn't had a chance to nail it, I guess. But any chroot packager with automatic rpm installs/erases can sing a song about random rpm database corruptions. From ATrpms' users' aspect I must admit a big improvement in RH8.0/9 when upgrading to 4.2.x. But since Red Hat has not offered official errata for it, I would still hesitate. o legacy is supposed to continue Red Hat's way of conservative backporting fixes (which BTW should include RH's naming conventions, even if I am the first to consider them broken). For rpm this would mean identifying the salvaging patches in rpm 4.2.1 and backporting them to RH8.0/9's rpm 4.1/4.2. That's quite a hammer, considering the number of patches that went in to fix an issue, which is still not totally fixed. ATrpms' "legacy" support is not a conservative, bugfixing and security fixing approach, it is far more functional oriented. It is also much easier for administring the same package for 4 different distros, but all this is not needed in legacy. If it were, you could simply use ATrpms. legacy users will most certainly wish to follow the path of least surprise. For the above open issues I would consult Jeff Johnson, the maintainer of rpm. I know he tried to push out errata for rpm, but obviously none were issued. He should know the reasons best, and I his advise should be heavily weighted for legacy's decisions. Warren, didn't you say you wanted to ask him? RH issued 6 updates for RH7.3 in December, e.g. one every five days. I think this can be handled without touching rpm. Updates for RH7.3/RH8.0/etc. have been mostly for different versions, with different specfile etc. So you don't gain much with syncing the infrastructure accross them. It's better to invest the man power in monitoring the security lists and backporting those fixes. It is not an easy task and you should consider 6 new upcoming security holes in RH7.3 in January 2004. That's why I would suggest to simply set up a repository today, apt/yum or not enabled. People care less about the infrastructure, than about having their web server shredded to pieces, because legacy is still talking academia, while security announcements go unnoticed. Even if users would have to install security fixes manually with 'rpm -Uhv http://downloads.fedoralegacy.org/path/to/RH7.3/rpms/fixed.rpm' they would be happier than having the best rpm/apt/yum infrastructure with no contents ;) Currenty I think the only option is to go with Progeny or RHEL. fedora-legacy is still deep in the design and planning phase, debating about upgrading rpm or not (which started in October), and there is no indication that the reaction time to any security announcements will be better. Just imagine another do_brk()-like bug in the kernel on January the 1st. > Any RPM upgrade that is included will only be done so after > extensive testing and verification that it does not introduce any > other problems. Any rpm version >= 4.1 will eventually eat up your rpm database. So much has been tested and confirmed by all parties. > Unanswered Questions for Discussion: > 1) What changed about the rpm epoch promotion behavior between rpm-4.2 > and rpm-4.2.1? Can somebody please explain this with details and > concrete examples? I need to understand why we need to keep the old > promotion behavior for the RH9 rpm upgrade as some have mentioned earlier. That is not a real problem, that part of the code could be easily adjusted. I recently looked into it, because of apt's recent misbehaviour in epoch promotion. > 2) Should we upgrade to rpm-4.2.x for RH7.x? While the benefit for > apt-get would be minimal, the benefit for yum would be immense as that > would enable the use of yum-2.x. Another key benefit would be > compatibility with the newer RPM GPG signatures. On Tue, Dec 30, 2003 at 01:44:59AM -0800, Chuck Wolber wrote: > RPM 4.0.4 is just so damn stable, it'd be hard to risk an upgrade. Also, I > must express a bit of ignorance here when it comes to yum, as I didn't > realize that *adding* yum would require an RPM upgrade. This is not really true anymore. There is work underway for allowing almost all of yum 2.0 to run on a rpm 4.0.4 and python 1.5.2 system. It has not landed yet, and we should allow more time for it, but it is a non-issue anymore. apt-get is probably the best distribution mechanism available for legacy. It has proven solid for the legacy releases (if one attributes the triggered rpm database corruptions to rpm, apt/synaptic have taken quite some unneccessary blame for it). On Mon, Dec 29, 2003 at 11:36:45PM -1000, Warren Togami wrote: > 3) Which specific RPM versions should we use? In my personal experience > rpm-4.2-1 from rpm.org and rpm-4.2.1 from FC1 both work very well on > RH9, while rpm-4.1.1 works great on RH8, although librpm404-4.0.5 is > needed to maintain compatibilty with some packaging tools of that era. > > Should we upgrade to rpm-4.2.x on RH7.x, RH8 and RH9, or use the above > mentioned versions? On Tue, Dec 30, 2003 at 01:44:59AM -0800, Chuck Wolber wrote: > Stability is more important than any new feature. I agree that stability and security are the most important (or maybe even the only) aspects of what people want from legacy. On Mon, Dec 29, 2003 at 11:36:45PM -1000, Warren Togami wrote: > Axel do you have any improvements to rpm-4.2.x series for the older > distributions that we should include? I understand that you have a set > of very well tested rpm upgrades. Yes, but see above about different scopes of a legacy and a feature supporting approach. For Xmas I had wished for a common RH errata for rpm for the running RH versions. Unfortunately Santa considered me naughty :( -- Axel.Thimm at physik.fu-berlin.de -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From warren at togami.com Tue Dec 30 11:55:01 2003 From: warren at togami.com (Warren Togami) Date: Tue, 30 Dec 2003 01:55:01 -1000 Subject: RPM upgrade discussion In-Reply-To: <20031230112238.GB13067@neu.nirvana> References: <3FF1472D.7030606@togami.com> <3FF1472D.7030606@togami.com> <20031230112238.GB13067@neu.nirvana> Message-ID: <3FF16795.40001@togami.com> Axel Thimm wrote: > Personally I would also upgrade rpm (and in ATrpms' legacy support I > am doing so), but for the target group of legacy I would question this > issue for the following reasons: > > o Red Hat never made rpm.org's errata official for any reasons they > may have. I suggest asking why. Probably they do not consider the > rpm upgrades stable enough. This is a strong signal not to go that > way. I strongly disagree, as anyone that has seriously used the rpm upgrades knows that they are night and day better than the default versions. I think the only concern they had was the tiny amount of complications that could occur during the upgrade itself. We can mitigate the potential problems with a very exact HOWTO for new users of Legacy that says how to kill all other processes that could possibly contend for the lock of rpmdb to ensure that the upgrade itself goes without a deadlock. > > o rpm up to 4.2.1 still eats up your database occasionally. rpm 4.2.2 But this is true of rpm-4.1 and rpm-4.2 too. > hasn't any indication in the changelog about having found the nasty > bug (which is probably not in rpm, but db4). It is so badly > reproducable that Jeff hasn't had a chance to nail it, I guess. But > any chroot packager with automatic rpm installs/erases can sing a > song about random rpm database corruptions. From ATrpms' users' > aspect I must admit a big improvement in RH8.0/9 when upgrading to > 4.2.x. But since Red Hat has not offered official errata for it, I > would still hesitate. Does that have anything to do with --rebuilddb? I really think it is a huge mistake that people keep suggesting --rebuilddb. I seriously have NEVER used it since around RH7.3. Everything I can remember at the moment, jbj suggested that it really is useless to use --rebuilddb after the rpm deadlock of RH8 or RH9. The only thing you need to do is wipe out the /var/lib/rpm/__* files. There is also the case with --rebuilddb where it corrupts stuff in your rpmdb if you have certain types of GPG keys imported into your rpm database. > > o legacy is supposed to continue Red Hat's way of conservative > backporting fixes (which BTW should include RH's naming conventions, > even if I am the first to consider them broken). For rpm this would > mean identifying the salvaging patches in rpm 4.2.1 and backporting > them to RH8.0/9's rpm 4.1/4.2. That's quite a hammer, considering the > number of patches that went in to fix an issue, which is still not > totally fixed. > > ATrpms' "legacy" support is not a conservative, bugfixing and security > fixing approach, it is far more functional oriented. It is also much > easier for administring the same package for 4 different distros, but > all this is not needed in legacy. If it were, you could simply use > ATrpms. legacy users will most certainly wish to follow the path of > least surprise. > > For the above open issues I would consult Jeff Johnson, the maintainer > of rpm. I know he tried to push out errata for rpm, but obviously none > were issued. He should know the reasons best, and I his advise should > be heavily weighted for legacy's decisions. Warren, didn't you say you > wanted to ask him? > > RH issued 6 updates for RH7.3 in December, e.g. one every five days. I > think this can be handled without touching rpm. Updates for > RH7.3/RH8.0/etc. have been mostly for different versions, with > different specfile etc. So you don't gain much with syncing the > infrastructure accross them. It's better to invest the man power in > monitoring the security lists and backporting those fixes. It is not > an easy task and you should consider 6 new upcoming security holes in > RH7.3 in January 2004. Well reasoned, and especially given the news about yum-2.x for rpm-4.0.4 this makes a good case for not upgrading RH7.x. Somebody ping Seth about this and ask for a status report please. > > That's why I would suggest to simply set up a repository today, > apt/yum or not enabled. People care less about the infrastructure, Already done, for RH8 and RH9 as the plan said we are using fedora.us "updates" channel. "updates-testing" is coming soon along with the RH7.x channels. I am creating 7.2 and 7.3 only for now unless developers seriously want to work on others. > > Currenty I think the only option is to go with Progeny or > RHEL. fedora-legacy is still deep in the design and planning phase, > debating about upgrading rpm or not (which started in October), and > there is no indication that the reaction time to any security > announcements will be better. Just imagine another do_brk()-like bug > in the kernel on January the 1st. > Realistically you are correct, as I am currently in doubt about the seriousness of intent to do actual work from developers. I was very disheartened in the last month that no community members were seriously pushing this forward, forcing me to take the initiative or absolutely NOTHING would happen. It would be a damn shame if Legacy fails, because some companies had already put money into it (EV1's $1K computer for Jesse), and other companies like Pogo willing to throw lots of money, time and resources into making it a reality. It would also be an extreme benefit for the community to have updates available for all old distributions for a while longer than upstream's EOL. While I see the importance of Legacy, I personally am pushing this forward to launch on borrowed time since it appears that it wouldn't happen otherwise. I am giving the community only the roadmap and infrastructure to do it. This initiative is counting on YOUR support or it will fail. > >>Unanswered Questions for Discussion: >>1) What changed about the rpm epoch promotion behavior between rpm-4.2 >>and rpm-4.2.1? Can somebody please explain this with details and >>concrete examples? I need to understand why we need to keep the old >>promotion behavior for the RH9 rpm upgrade as some have mentioned earlier. > > > That is not a real problem, that part of the code could be easily > adjusted. I recently looked into it, because of apt's recent > misbehaviour in epoch promotion. Which misbehavior? Was this when fedora.us began adding Epoch: 0 to all packages and old apt compared 0 > missing? In any case we don't need to worry about this anymore because apt now does the right thing, and the python bindings (due to a fortunate bug) always did do the right thing. I'm glad to hear that it isn't a real problem though. >>2) Should we upgrade to rpm-4.2.x for RH7.x? While the benefit for >>apt-get would be minimal, the benefit for yum would be immense as that >>would enable the use of yum-2.x. Another key benefit would be >>compatibility with the newer RPM GPG signatures. > > > On Tue, Dec 30, 2003 at 01:44:59AM -0800, Chuck Wolber wrote: > >>RPM 4.0.4 is just so damn stable, it'd be hard to risk an upgrade. Also, I >>must express a bit of ignorance here when it comes to yum, as I didn't >>realize that *adding* yum would require an RPM upgrade. > > > This is not really true anymore. There is work underway for allowing > almost all of yum 2.0 to run on a rpm 4.0.4 and python 1.5.2 > system. It has not landed yet, and we should allow more time for it, > but it is a non-issue anymore. That sounds promising. If that is available that almost totally nullifies any need to upgrade RH7.x's RPM. > > apt-get is probably the best distribution mechanism available for > legacy. It has proven solid for the legacy releases (if one attributes > the triggered rpm database corruptions to rpm, apt/synaptic have taken > quite some unneccessary blame for it). +1 totally in agreement. > On Mon, Dec 29, 2003 at 11:36:45PM -1000, Warren Togami wrote: > >>Axel do you have any improvements to rpm-4.2.x series for the older >>distributions that we should include? I understand that you have a set >>of very well tested rpm upgrades. > > > Yes, but see above about different scopes of a legacy and a feature > supporting approach. > > For Xmas I had wished for a common RH errata for rpm for the running > RH versions. Unfortunately Santa considered me naughty :( Methinks continuing the broken RPM of RH8 and RH9 is incentive to upgrade to a working distribution, like FC1. Or maybe there's business motives like a certain four letter acronym that begins at $129/yr. =) Warren From Axel.Thimm at physik.fu-berlin.de Tue Dec 30 13:42:10 2003 From: Axel.Thimm at physik.fu-berlin.de (Axel Thimm) Date: Tue, 30 Dec 2003 14:42:10 +0100 Subject: RPM upgrade discussion In-Reply-To: <3FF16795.40001@togami.com> References: <3FF1472D.7030606@togami.com> <3FF1472D.7030606@togami.com> <20031230112238.GB13067@neu.nirvana> <3FF16795.40001@togami.com> Message-ID: <20031230134210.GE13067@neu.nirvana> On Tue, Dec 30, 2003 at 01:55:01AM -1000, Warren Togami wrote: > Axel Thimm wrote: > >o Red Hat never made rpm.org's errata official for any reasons they > > may have. I suggest asking why. Probably they do not consider the > > rpm upgrades stable enough. This is a strong signal not to go that > > way. > > I strongly disagree, as anyone that has seriously used the rpm upgrades > knows that they are night and day better than the default versions. I > think the only concern they had was the tiny amount of complications > that could occur during the upgrade itself. The unofficial rpm errata are an improvement, nobody denied that. If Red Hat decided not to do the upgrade nonetheless, there must be a true reason. And if that reason is that upgrading the rpm database format is occasionally eating your database, it is a severe reason, too. > We can mitigate the potential problems with a very exact HOWTO for > new users of Legacy that says how to kill all other processes that > could possibly contend for the lock of rpmdb to ensure that the > upgrade itself goes without a deadlock. I have never ever had two processes access the same rpm database in chroot builds, and I still get a corruption every few days in the >= RH8.0 chroots. > > Methinks continuing the broken RPM of RH8 and RH9 is incentive to > upgrade to a working distribution, like FC1. Or maybe there's business > motives like a certain four letter acronym that begins at $129/yr. =) > They would have a better case in shutting down customer trust with doing this with the kernel rpms. On the contrary, I suppose that they estimate they'd be breaking more than fixing. Their estimation could be wrong, and we may know better, or the other way around. Do you want to risk it? If you want to be paranoid: Probably RH is waiting for a scape goat to impose the transition. ATrpms did play scape goat, but there I'm not wearing the conservative legacy cap (or is that a fedora? ;), and I need a recent rpm for maintaining only one specfile for all four distros, which is something legacy doesn't need. > >o rpm up to 4.2.1 still eats up your database occasionally. rpm 4.2.2 > > But this is true of rpm-4.1 and rpm-4.2 too. I wrote "up to", didn't I? ;) > > hasn't any indication in the changelog about having found the nasty > > bug (which is probably not in rpm, but db4). It is so badly > > reproducable that Jeff hasn't had a chance to nail it, I guess. But > > any chroot packager with automatic rpm installs/erases can sing a > > song about random rpm database corruptions. From ATrpms' users' > > aspect I must admit a big improvement in RH8.0/9 when upgrading to > > 4.2.x. But since Red Hat has not offered official errata for it, I > > would still hesitate. > > Does that have anything to do with --rebuilddb? No, nobody uses --rebuilddb other than fixing the broken rpm databases. If --rebuilddb would be the culprit, the problem would have been solved, as it would never be issued. > I really think it is a huge mistake that people keep suggesting > --rebuilddb. I seriously have NEVER used it since around RH7.3. > Everything I can remember at the moment, jbj suggested that it > really is useless to use --rebuilddb after the rpm deadlock of RH8 > or RH9. The only thing you need to do is wipe out the > /var/lib/rpm/__* files. I think you remember wrong or vice versa, Jeff always suggests using it, in my rpm-list archive for example three weeks ago for the last time. Also on quoted mails from Jeff at rpm.org. In any case rpm database corruption is there since 4.1 upwards until today, in various degrees, but always present. > [...] I am currently in doubt about the seriousness of intent to do > actual work from developers. I was very disheartened in the last > month that no community members were seriously pushing this forward, > [...] I am giving the community only the roadmap and infrastructure > to do it. This initiative is counting on YOUR support or it will > fail. Infrastructure is only useful for managing content. I suggest to invest man power in creating the content first and then improving organization. The actual developers themselves should decide on an infrastructure, so let's see who will be doing legacy rpm work in January. I believe that there are more consumers than developers on this list, and that Progeny's $5 offer reduced the pain and need for fedora-legacy. Should Progeny not be up to the task (which I believe it will do fine), people will come back to fedora-legacy, but currently there are only ghost city planers left here. ;) > > > [... epoch promotion ...] > > That is not a real problem, that part of the code could be easily > > adjusted. I recently looked into it, because of apt's recent > > misbehaviour in epoch promotion. > > Which misbehavior? Was this when fedora.us began adding Epoch: 0 to all > packages and old apt compared 0 > missing? No, that wasn't apt's misbehaviour, but your's ;) And it wasn't recent either. I found an ugly bug yesterday when using apt-0.5.15cnc5 on RH9/rpm 4.2. -- Axel.Thimm at physik.fu-berlin.de -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From skvidal at phy.duke.edu Tue Dec 30 13:51:39 2003 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 30 Dec 2003 08:51:39 -0500 Subject: RPM upgrade discussion In-Reply-To: <3FF14CB9.6030607@togami.com> References: <3FF14CB9.6030607@togami.com> Message-ID: <1072792298.4270.2.camel@binkley> On Tue, 2003-12-30 at 05:00, Warren Togami wrote: > Chuck Wolber wrote: > > > >>2) Should we upgrade to rpm-4.2.x for RH7.x? While the benefit for > >>apt-get would be minimal, the benefit for yum would be immense as that > >>would enable the use of yum-2.x. Another key benefit would be > >>compatibility with the newer RPM GPG signatures. > > > > > > RPM 4.0.4 is just so damn stable, it'd be hard to risk an upgrade. Also, I > > must express a bit of ignorance here when it comes to yum, as I didn't > > realize that *adding* yum would require an RPM upgrade. > > The only issue is yum-1.x is the only version that works with rpm-4.0.4. What is wrong with yum-1.x? -sv From skvidal at phy.duke.edu Tue Dec 30 13:52:03 2003 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 30 Dec 2003 08:52:03 -0500 Subject: RPM upgrade discussion In-Reply-To: References: Message-ID: <1072792323.4270.4.camel@binkley> On Tue, 2003-12-30 at 05:07, Chuck Wolber wrote: > > > RPM 4.0.4 is just so damn stable, it'd be hard to risk an upgrade. > > > Also, I must express a bit of ignorance here when it comes to yum, as > > > I didn't realize that *adding* yum would require an RPM upgrade. > > > > The only issue is yum-1.x is the only version that works with rpm-4.0.4. > > Is there a changelog that covers the delta between yum-1 and yum-2? Or > more to the point, can we live with this? Sure there are changelogs - but I'm still not sure what the problems are with yum-1. -sv From skvidal at phy.duke.edu Tue Dec 30 13:55:46 2003 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 30 Dec 2003 08:55:46 -0500 Subject: RPM upgrade discussion In-Reply-To: <20031230112238.GB13067@neu.nirvana> References: <3FF1472D.7030606@togami.com> <3FF1472D.7030606@togami.com> <20031230112238.GB13067@neu.nirvana> Message-ID: <1072792545.4270.9.camel@binkley> > This is not really true anymore. There is work underway for allowing > almost all of yum 2.0 to run on a rpm 4.0.4 and python 1.5.2 > system. It has not landed yet, and we should allow more time for it, > but it is a non-issue anymore. There are still a lot of issues to work out with those patches. I wouldn't plan on them. Not to mention the fact that rhl 7.1 doesn't have a python2 that is useable, planning on backporting that, too? > apt-get is probably the best distribution mechanism available for > legacy. It has proven solid for the legacy releases (if one attributes > the triggered rpm database corruptions to rpm, apt/synaptic have taken > quite some unneccessary blame for it). I'm curious, how has yum 'failed' for legacy releases? I've been using yum on > 800, 7.x machines for more than 2.5 years. -sv From skvidal at phy.duke.edu Tue Dec 30 14:00:53 2003 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 30 Dec 2003 09:00:53 -0500 Subject: RPM upgrade discussion In-Reply-To: References: Message-ID: <1072792852.4270.12.camel@binkley> On Tue, 2003-12-30 at 04:44, Chuck Wolber wrote: > > 2) Should we upgrade to rpm-4.2.x for RH7.x? While the benefit for > > apt-get would be minimal, the benefit for yum would be immense as that > > would enable the use of yum-2.x. Another key benefit would be > > compatibility with the newer RPM GPG signatures. > > RPM 4.0.4 is just so damn stable, it'd be hard to risk an upgrade. Also, I > must express a bit of ignorance here when it comes to yum, as I didn't > realize that *adding* yum would require an RPM upgrade. > I'd like to reiterate - that's only for yum-2.x. Yum-1.x works fine with rpm 4.0.4 and I've been using 1.x for quite a while now on a whole lot of machines. -sv From jkeating at j2solutions.net Tue Dec 30 15:50:12 2003 From: jkeating at j2solutions.net (Jesse Keating) Date: Tue, 30 Dec 2003 07:50:12 -0800 Subject: RPM upgrade discussion In-Reply-To: <1072792852.4270.12.camel@binkley> References: <1072792852.4270.12.camel@binkley> Message-ID: <200312300750.12624.jkeating@j2solutions.net> On Tuesday 30 December 2003 06:00, seth vidal wrote: > I'd like to reiterate - that's only for yum-2.x. Yum-1.x works fine > with rpm 4.0.4 and I've been using 1.x for quite a while now on a > whole lot of machines. I tend to agree here. I've been using it on my 7.x box for quite a while without issues. It seems that since 7.x's yum is functional, and 7.x's RPM is mostly functional, I propose that we don't upgrade RPM as a legacy upgrade. People can still upgrade it themselves if they want, but it doesn't really seem to fall into Legacy's proposed framework, and thus it shouldn't happen. I'm strongly urging not to upgrade RPM as a legacy upgrade. -- Jesse Keating RHCE MCSE (geek.j2solutions.net) Fedora Legacy Team (www.fedora.us/wiki/FedoraLegacy) Mondo DevTeam (www.mondorescue.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating From pearcec at commnav.com Tue Dec 30 18:51:39 2003 From: pearcec at commnav.com (Christian Pearce) Date: Tue, 30 Dec 2003 18:51:39 GMT Subject: RPM upgrade discussion Message-ID: <34728.209.50.130.101.1072810299.commnav@home.commnav.com> Hello. I am new to the list and I just got up to speed. I am hoping to contribute in every way possible. I have to agreed with this as well. If Yum-1.x in functional for updating 7.x machines and rpm 4.0.4 is stable then let sleeping dogs lie. This does raise the question of Red Hat 8.0 and Red Hat 9. Are they unstable enough to warrant an upgrade? Quite frankly I don't have enough recollection to say either way. I know for a fact I sometimes run into problems with Red Hat 8.0 that requires me to kill rpm upgrades and remove database files. So this is what I assume people are talking about. Again I think there should be one way of doing this. So if we aren't going to upgrade 7.x machines because they are good enough. And the Fedora Core 1 rpm binary package is stable. Then we should make the Red Hat 8.0 and Red Hat 9 (if it is a problem i don't know) edge cases that can be handled as a decision to be made by the end user. This also would follow the spirit of the Fedora Legacy framework as Jesse stated below. Not to mention people should work to phase out their Red H! at 7.x - 9 installations. So I hope in a couple years this becomes a mute talk. This leads me to the following question. Can we provide the rpm package as a extra or crontrib package? I apologize for my lack of correct terminology I am still getting up to speed. -- Christian Pearce http://www.commnav.com Jesse Keating said: > > On Tuesday 30 December 2003 06:00, seth vidal wrote: > > I'd like to reiterate - that's only for yum-2.x. Yum-1.x works fine > > with rpm 4.0.4 and I've been using 1.x for quite a while now on a > > whole lot of machines. > > I tend to agree here. I've been using it on my 7.x box for quite a > while without issues. It seems that since 7.x's yum is functional, and > 7.x's RPM is mostly functional, I propose that we don't upgrade RPM as > a legacy upgrade. People can still upgrade it themselves if they want, > but it doesn't really seem to fall into Legacy's proposed framework, > and thus it shouldn't happen. I'm strongly urging not to upgrade RPM > as a legacy upgrade. > > -- > Jesse Keating RHCE MCSE (geek.j2solutions.net) > Fedora Legacy Team (www.fedora.us/wiki/FedoraLegacy) > Mondo DevTeam (www.mondorescue.org) > GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) > > Was I helpful? Let others know: > http://svcs.affero.net/rm.php?r=jkeating > > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-legacy-list > From digilexic at digilexic.com Tue Dec 30 18:57:34 2003 From: digilexic at digilexic.com (Digilexic) Date: Tue, 30 Dec 2003 13:57:34 -0500 Subject: RPM upgrade discussion In-Reply-To: <34728.209.50.130.101.1072810299.commnav@home.commnav.com> Message-ID: I am more of an end user lurker, but would like to contribute where and when I can. So far I have been able to follow the threads without much difficulty and am a pretty avid computer tech. I run RedHat 9 on a dedicated server (not 100's of servers like some of you) and I was wondering in what areas I could "study up" to be a help to this group. -Christian Reynolds -----Original Message----- From: fedora-legacy-list-admin at redhat.com [mailto:fedora-legacy-list-admin at redhat.com]On Behalf Of Christian Pearce Sent: Tuesday, December 30, 2003 1:52 PM To: fedora-legacy-list at redhat.com Subject: Re: RPM upgrade discussion Hello. I am new to the list and I just got up to speed. I am hoping to contribute in every way possible. I have to agreed with this as well. If Yum-1.x in functional for updating 7.x machines and rpm 4.0.4 is stable then let sleeping dogs lie. This does raise the question of Red Hat 8.0 and Red Hat 9. Are they unstable enough to warrant an upgrade? Quite frankly I don't have enough recollection to say either way. I know for a fact I sometimes run into problems with Red Hat 8.0 that requires me to kill rpm upgrades and remove database files. So this is what I assume people are talking about. Again I think there should be one way of doing this. So if we aren't going to upgrade 7.x machines because they are good enough. And the Fedora Core 1 rpm binary package is stable. Then we should make the Red Hat 8.0 and Red Hat 9 (if it is a problem i don't know) edge cases that can be handled as a decision to be made by the end user. This also would follow the spirit of the Fedora Legacy framework as Jesse stated below. Not to mention people should work to phase out their Red H! at 7.x - 9 installations. So I hope in a couple years this becomes a mute talk. This leads me to the following question. Can we provide the rpm package as a extra or crontrib package? I apologize for my lack of correct terminology I am still getting up to speed. -- Christian Pearce http://www.commnav.com Jesse Keating said: > > On Tuesday 30 December 2003 06:00, seth vidal wrote: > > I'd like to reiterate - that's only for yum-2.x. Yum-1.x works fine > > with rpm 4.0.4 and I've been using 1.x for quite a while now on a > > whole lot of machines. > > I tend to agree here. I've been using it on my 7.x box for quite a > while without issues. It seems that since 7.x's yum is functional, and > 7.x's RPM is mostly functional, I propose that we don't upgrade RPM as > a legacy upgrade. People can still upgrade it themselves if they want, > but it doesn't really seem to fall into Legacy's proposed framework, > and thus it shouldn't happen. I'm strongly urging not to upgrade RPM > as a legacy upgrade. > > -- > Jesse Keating RHCE MCSE (geek.j2solutions.net) > Fedora Legacy Team (www.fedora.us/wiki/FedoraLegacy) > Mondo DevTeam (www.mondorescue.org) > GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) > > Was I helpful? Let others know: > http://svcs.affero.net/rm.php?r=jkeating > > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-legacy-list > -- fedora-legacy-list mailing list fedora-legacy-list at redhat.com http://www.redhat.com/mailman/listinfo/fedora-legacy-list From rohwedde at codegrinder.com Tue Dec 30 19:17:11 2003 From: rohwedde at codegrinder.com (Jason) Date: Tue, 30 Dec 2003 13:17:11 -0600 Subject: Self-Introduction: Jason Rohwedder Message-ID: <20031230191711.GF17980@codegrinder.com> 1. Jason Adam Rohwedder 2. USA, Chicago 3. Development Systems Engineer 4. Orbitz.com 5. Mainly, I'd like to ensure that I have a source of security fix RPMS, for both my home machines, and any machines at work that require them. Added to that, I like RH 7.3. It's a good stable release that works well for machines that don't need all the bells and whistles that I may want on my workstation. It should be noted that while work is permitting me to contribute to this project, it is not a sponsored activity. So, I'm free to spend as much of my free time as I want. But, I may or may not, be able to spend work-time on the project, depending on what's necessary at the company. I could potentially do some QA for the project if necessary. I still need to work on setting up a reference machine for that to happen. 6. Currently, I package many of the custom packages required in the development environment at work. There are some security updates to stock packages as well, and I expect the need for that to grow as the EOL's take effect. I'm mainly responsible for making sure that the machines used for development are secure, maintainable, and that all applications used are able to work together properly. My skillset includes: C/C++, Java, Php, Perl, and a very slim bit of python. Why should I be trusted? I have a vested interest in seeing the project succeed and move forward, in that it may save me some headache at work and with my own machines. Other than that, I've been working professionally in systems administration/engineering since 1998. Honestly, I don't have any examples in the public domain to showcase, so perhaps any trust I earn will have to come from my contributions to the project. 7. [rohwedde at localhost rohwedde]$ gpg --fingerprint 9B643F0D pub 1024D/9B643F0D 2003-12-30 Jason Rohwedder Key fingerprint = 0AA1 6522 AD40 FB05 EFB3 2344 C364 0463 9B64 3F0D sub 1024g/48049725 2003-12-30 From maxfield at one.ctelcom.net Tue Dec 30 19:19:13 2003 From: maxfield at one.ctelcom.net (Wade Maxfield) Date: Tue, 30 Dec 2003 13:19:13 -0600 (CST) Subject: RPM upgrade discussion In-Reply-To: <34728.209.50.130.101.1072810299.commnav@home.commnav.com> References: <34728.209.50.130.101.1072810299.commnav@home.commnav.com> Message-ID: I've been forced to upgrade to the rpm-4.1.1-1.8x package from rpm.org to make redhat 8 play nice and survive more than 3 or 4 update cycles without freezing. I don't think we need to go to 4.2 rpm, but the 4.1 rpm update is a must, based on personal experience with several machines. On Tue, 30 Dec 2003, Christian Pearce wrote: > > Hello. I am new to the list and I just got up to speed. I am hoping to contribute in every way possible. > > I have to agreed with this as well. If Yum-1.x in functional for updating 7.x machines and rpm 4.0.4 is stable then let sleeping dogs lie. This does raise the question of Red Hat 8.0 and Red Hat 9. Are they unstable enough to warrant an upgrade? Quite frankly I don't have enough recollection to say either way. I know for a fact I sometimes run into problems with Red Hat 8.0 that requires me to kill rpm upgrades and remove database files. So this is what I assume people are talking about. Again I think there should be one way of doing this. So if we aren't going to upgrade 7.x machines because they are good enough. And the Fedora Core 1 rpm binary package is stable. Then we should make the Red Hat 8.0 and Red Hat 9 (if it is a problem i don't know) edge cases that can be handled as a decision to be made by the end user. This also would follow the spirit of the Fedora Legacy framework as Jesse stated below. Not to mention people should work to phase out their Red H! > at 7.x - 9 installations. So I hope in a couple years this becomes a mute talk. This leads me to the following question. Can we provide the rpm package as a extra or crontrib package? I apologize for my lack of correct terminology I am still getting up to speed. > > -- > Christian Pearce > http://www.commnav.com > > > > Jesse Keating said: > > > > On Tuesday 30 December 2003 06:00, seth vidal wrote: > > > I'd like to reiterate - that's only for yum-2.x. Yum-1.x works fine > > > with rpm 4.0.4 and I've been using 1.x for quite a while now on a > > > whole lot of machines. > > > > I tend to agree here. I've been using it on my 7.x box for quite a > > while without issues. It seems that since 7.x's yum is functional, and > > 7.x's RPM is mostly functional, I propose that we don't upgrade RPM as > > a legacy upgrade. People can still upgrade it themselves if they want, > > but it doesn't really seem to fall into Legacy's proposed framework, > > and thus it shouldn't happen. I'm strongly urging not to upgrade RPM > > as a legacy upgrade. > > > > -- > > Jesse Keating RHCE MCSE (geek.j2solutions.net) > > Fedora Legacy Team (www.fedora.us/wiki/FedoraLegacy) > > Mondo DevTeam (www.mondorescue.org) > > GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) > > > > Was I helpful? Let others know: > > http://svcs.affero.net/rm.php?r=jkeating > > From chuckw at quantumlinux.com Tue Dec 30 22:32:32 2003 From: chuckw at quantumlinux.com (Chuck Wolber) Date: Tue, 30 Dec 2003 14:32:32 -0800 (PST) Subject: RPM upgrade discussion In-Reply-To: <1072792323.4270.4.camel@binkley> Message-ID: > > > The only issue is yum-1.x is the only version that works with > > > rpm-4.0.4. > > > > Is there a changelog that covers the delta between yum-1 and yum-2? Or > > more to the point, can we live with this? > > Sure there are changelogs - but I'm still not sure what the problems are > with yum-1. Neither am I. Warren made the comment first, I was hoping he'd elaborate. -Chuck -- Quantum Linux Laboratories - ACCELERATING Business with Open Technology * Education | -=^ Ad Astra Per Aspera ^=- * Integration | http://www.quantumlinux.com * Support | chuckw at quantumlinux.com "You know what you get after putting 30 years into a company? You're looking at it." -Downsized CIO of a major insurance carrier. From chuckw at quantumlinux.com Tue Dec 30 22:57:33 2003 From: chuckw at quantumlinux.com (Chuck Wolber) Date: Tue, 30 Dec 2003 14:57:33 -0800 (PST) Subject: RPM upgrade discussion In-Reply-To: Message-ID: > I am more of an end user lurker, but would like to contribute where and > when I can. So far I have been able to follow the threads without much > difficulty and am a pretty avid computer tech. > > I run RedHat 9 on a dedicated server (not 100's of servers like some of > you) and I was wondering in what areas I could "study up" to be a help > to this group. Pick an RPM package that contains a service/server like httpd, OpenSSH, sendmail, BIND, etc (I can put together a semi-exhaustive list if you want). Join the development list for that application. Don't worry if it all looks like greek to you, you'll be deleting most of what you see anyway. Just scan each mesage for things like "security patch" or "insecure" or "show stopper" etc. If you see anything like that, notify this list and we'll get someone on it. That saves us from having to eat up all of our time monitoring a zillion lists. *IMPORTANT NOTE* Seeing a security thread on a dev list is not license to go running around screaming that the sky is falling. Usually those threads don't go anywhere. -Chuck -- Quantum Linux Laboratories - ACCELERATING Business with Open Technology * Education | -=^ Ad Astra Per Aspera ^=- * Integration | http://www.quantumlinux.com * Support | chuckw at quantumlinux.com "You know what you get after putting 30 years into a company? You're looking at it." -Downsized CIO of a major insurance carrier. From Bernd.Bartmann at sohanet.de Wed Dec 31 00:40:35 2003 From: Bernd.Bartmann at sohanet.de (Bernd Bartmann) Date: Wed, 31 Dec 2003 01:40:35 +0100 Subject: Please follow the KISS principle Message-ID: <3FF21B03.4020806@sohanet.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all, after reading Warrens drafts and the answers I'm getting the impressions that this projects start way to complicated. Let us just follow the KISS principle (keep it simple stupid). As Fedora-Legacy only exists to handle security updates and is not intended to introduce new features to EOLed distributions we should really focus on the essentials. For me this means NO rpm upgrades. Just use the infrastructure and tools that Red Hat gave us with their distributions. Updated packages should primarily be available via HTTP/FTP. Progeny also will focus on HTTP first. If someone can provide RSYNC, APT or YUM repositories later this would be fine but it is not needed in the first place. Personally I can offer to do package QA testing and bug reporting. I have access to RH 7.2/7.3/8.0 test servers and already do a little bit QA on some of the fedora.us packages. How shall we handle security alert notification to the developers? Can we expect that everyone monitors all major (open) security mailing lists ? At least I do so. BTW: There seems to be a security update available for CVS: http://ccvs.cvshome.org/servlets/NewsItemView?newsID=88 Best regards. - -- Dipl.-Ing. (FH) Bernd Bartmann I.S. Security and Network Engineer SoHaNet Technology GmbH / Kaiserin-Augusta-Allee 10-11 / 10553 Berlin Fon: +49 30 214783-44 / Fax: +49 30 214783-46 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE/8hsDkQuIaHu84cIRAl89AKCHlWTWuCpRGax5bhYKU06Df58HHQCfYUXS b7N495kWdGothCKwFXEG9ac= =6dIl -----END PGP SIGNATURE----- From chuckw at quantumlinux.com Wed Dec 31 00:56:53 2003 From: chuckw at quantumlinux.com (Chuck Wolber) Date: Tue, 30 Dec 2003 16:56:53 -0800 (PST) Subject: Fedora Legacy Launch Plan (draft 2) In-Reply-To: <3FF15F22.5030207@togami.com> Message-ID: > I believe we can sanely and easily choose naming on a case-by-case > basis. We only need to follow precedent. This is not a problem. Wouldn't the precedent be the existing rh7.3, rh8.0, rh9 tags? > We disagree about having ".legacy" at the end. I personally don't see a > problem in having a longer filename since it *should* be handled > automatically by tools. I believe we should have it for two reasons: > > 1) Clear separation between the official RH/FC updates and Legacy updates. Ok, I can understand that. But instead of legacy, why not flrh7.3, flrh8.0, flrh9? > 2) Repository tags are encouraged for all non-FC and non-FE repositories. Yup > I suppose we could have a shorter abbreviation of legacy, but I can't > think of anything that looks good. Shorter is good, but I'm still lobbying heavily for some semblance of which RH OS the RPM was meant for in the filename. -Chuck -- Quantum Linux Laboratories - ACCELERATING Business with Open Technology * Education | -=^ Ad Astra Per Aspera ^=- * Integration | http://www.quantumlinux.com * Support | chuckw at quantumlinux.com "You know what you get after putting 30 years into a company? You're looking at it." -Downsized CIO of a major insurance carrier. From skvidal at phy.duke.edu Wed Dec 31 00:55:01 2003 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 30 Dec 2003 19:55:01 -0500 Subject: Please follow the KISS principle In-Reply-To: <3FF21B03.4020806@sohanet.de> References: <3FF21B03.4020806@sohanet.de> Message-ID: <1072832101.10379.5.camel@binkley> > after reading Warrens drafts and the answers I'm getting the impressions > that this projects start way to complicated. Let us just follow the KISS > principle (keep it simple stupid). As Fedora-Legacy only exists to > handle security updates and is not intended to introduce new features to > EOLed distributions we should really focus on the essentials. For me > this means NO rpm upgrades. Just use the infrastructure and tools that > Red Hat gave us with their distributions. I'm thinking a good way for people to accomplish things is just to do them. If you find a security problem or notice one and produce a patched or new and working package put it up somewhere. Tell people on this list, just do the work. If you notice a problem that needs to be patched then post a link to it here, etc. just do the work, try to help out. The proposals and policies and systems be damned. I'll just be patching things and seeing about providing fixed rpms whenever I can. oh and if anyone wonders why you should trust any package I put together I think my answer is: a lot of you are using code I wrote to update your systems, so you're already trusting me :) -sv From skvidal at phy.duke.edu Wed Dec 31 01:22:17 2003 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 30 Dec 2003 20:22:17 -0500 Subject: Please follow the KISS principle In-Reply-To: <3FF21B03.4020806@sohanet.de> References: <3FF21B03.4020806@sohanet.de> Message-ID: <1072833736.10379.10.camel@binkley> > BTW: There seems to be a security update available for CVS: > http://ccvs.cvshome.org/servlets/NewsItemView?newsID=88 > I was looking at this bug and I noticed this in the cvs changelog: 2003-12-18 Derek Price * NEWS: Note that pserver can no longer run as root. That's a bit interesting. Providing a patched package that suddenly makes running pserver as root not work would be surprising, I think. -sv From rohwedde at codegrinder.com Wed Dec 31 02:31:21 2003 From: rohwedde at codegrinder.com (Jason) Date: Tue, 30 Dec 2003 20:31:21 -0600 Subject: CVS security update [ was Re: Please follow the KISS principle ] In-Reply-To: <1072833736.10379.10.camel@binkley> References: <3FF21B03.4020806@sohanet.de> <1072833736.10379.10.camel@binkley> Message-ID: <20031231023121.GK17980@codegrinder.com> The main changes concerning that seem to be in src/server.c in the switch_to_user function. I think you'd still be able to run the cvs daemon as root. In fact, I think it would still have to run as a privileged user in order to switch UID's to the proper user upon login. However, when the cvs user tries to authenticate it would refuse to switch to the root user, and then syslog it. If someone is logging into their repository as root.. they've got issues anyway. But, I don't see a problem with having this patched in. my 2cents -jason >From the linked news advisory. >"Previously, any user with the ability to write the CVSROOT/passwd file >could execute arbitrary code as the root user on systems with CVS >pserver access enabled. We recommend this upgrade for all CVS servers!" And from the NEWS file ( which you would think should match the cvs changelog >* pserver can no longer be configured to run as root via the > $CVSROOT/CVSROOT/passwd file, so if your passwd file is compromised, > it no longer leads directly to a root hack. Attempts to root will also be > logged via the syslog. from src/server.c switch_to_user (cvs_username, username) ... if (pw->pw_uid == 0) { ... printf("error 0: root not allowed\n"); error_exit (); } On Tue, Dec 30, 2003 at 08:22:17PM -0500, seth vidal wrote: > > BTW: There seems to be a security update available for CVS: > > http://ccvs.cvshome.org/servlets/NewsItemView?newsID=88 > > > > I was looking at this bug and I noticed this in the cvs changelog: > 2003-12-18 Derek Price > > * NEWS: Note that pserver can no longer run as root. > > That's a bit interesting. Providing a patched package that suddenly > makes running pserver as root not work would be surprising, I think. > > -sv > > > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-legacy-list From warren at togami.com Wed Dec 31 03:53:16 2003 From: warren at togami.com (Warren Togami) Date: Tue, 30 Dec 2003 17:53:16 -1000 Subject: Fedora Legacy Launch Plan (draft 2) In-Reply-To: References: Message-ID: <3FF2482C.4080608@togami.com> Chuck Wolber wrote: > >>I believe we can sanely and easily choose naming on a case-by-case >>basis. We only need to follow precedent. This is not a problem. > > > Wouldn't the precedent be the existing rh7.3, rh8.0, rh9 tags? No, that is not the RH precedent. That is similar to how the 3rd party repositories and fedora.us have operated. > >>We disagree about having ".legacy" at the end. I personally don't see a >>problem in having a longer filename since it *should* be handled >>automatically by tools. I believe we should have it for two reasons: >> >>1) Clear separation between the official RH/FC updates and Legacy updates. > > > Ok, I can understand that. But instead of legacy, why not flrh7.3, > flrh8.0, flrh9? This is just as ugly as rhfc-type names. Yuck. >>2) Repository tags are encouraged for all non-FC and non-FE repositories. > > > Yup > > > >>I suppose we could have a shorter abbreviation of legacy, but I can't >>think of anything that looks good. > > > Shorter is good, but I'm still lobbying heavily for some semblance of > which RH OS the RPM was meant for in the filename. > I think I'm in agreement, but I'm not exactly sure what you are saying here. Warren From skvidal at phy.duke.edu Wed Dec 31 03:58:46 2003 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 30 Dec 2003 22:58:46 -0500 Subject: CVS security update [ was Re: Please follow the KISS principle ] In-Reply-To: <20031231023121.GK17980@codegrinder.com> References: <3FF21B03.4020806@sohanet.de> <1072833736.10379.10.camel@binkley> <20031231023121.GK17980@codegrinder.com> Message-ID: <1072843125.10379.13.camel@binkley> On Tue, 2003-12-30 at 21:31, Jason wrote: > The main changes concerning that seem to be in src/server.c in the > switch_to_user function. I think you'd still be able to run the cvs > daemon as root. In fact, I think it would still have to run as a > privileged user in order to switch UID's to the proper user upon login. > However, when the cvs user tries to authenticate it would refuse to > switch to the root user, and then syslog it. > > If someone is logging into their repository as root.. they've got issues > anyway. But, I don't see a problem with having this patched in. > Yah it looks like: this is the patch that is needed http://ccvs.cvshome.org/source/browse/ccvs/src/server.c.diff?r1=1.284.2.9&r2=1.284.2.12&f=u need to take a look to see how far off that is from 1.11.1p1+patches that is in 7.x. -sv From skvidal at phy.duke.edu Wed Dec 31 05:32:14 2003 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 31 Dec 2003 00:32:14 -0500 Subject: CVS security update [ was Re: Please follow the KISS principle ] In-Reply-To: <1072843125.10379.13.camel@binkley> References: <3FF21B03.4020806@sohanet.de> <1072833736.10379.10.camel@binkley> <20031231023121.GK17980@codegrinder.com> <1072843125.10379.13.camel@binkley> Message-ID: <1072848733.10379.30.camel@binkley> On Tue, 2003-12-30 at 22:58, seth vidal wrote: > On Tue, 2003-12-30 at 21:31, Jason wrote: > > The main changes concerning that seem to be in src/server.c in the > > switch_to_user function. I think you'd still be able to run the cvs > > daemon as root. In fact, I think it would still have to run as a > > privileged user in order to switch UID's to the proper user upon login. > > However, when the cvs user tries to authenticate it would refuse to > > switch to the root user, and then syslog it. > > > > If someone is logging into their repository as root.. they've got issues > > anyway. But, I don't see a problem with having this patched in. > > > > > Yah it looks like: > this is the patch that is needed > http://ccvs.cvshome.org/source/browse/ccvs/src/server.c.diff?r1=1.284.2.9&r2=1.284.2.12&f=u > > need to take a look to see how far off that is from 1.11.1p1+patches > that is in 7.x. I got it built. The cvs people appear to have left out something though. they need this: /* Switch to run as this user. */ - switch_to_user (user); + switch_to_user ("KERBEROS", user); } #endif /* HAVE_KERBEROS */ around line 5964 in the patched source. I think that's the right patch. It compiles cleanly but I can't easily test the kerb-authenticated attempt to see if it works. I posted the srpm and rpm here: http://linux.duke.edu/~skvidal/RPMS/cvs/ Those are built on 7.3. Should work on 7.2 and 7.1, I'd bet. I put the patches I applied in that dir as well. -sv From jonny.strom at netikka.fi Wed Dec 31 08:45:32 2003 From: jonny.strom at netikka.fi (Johnny Strom) Date: Wed, 31 Dec 2003 10:45:32 +0200 Subject: Kernel security issue. Message-ID: <3FF28CAC.3030804@netikka.fi> Hi all It seems that there is a security issue in the kernel, I don't know if RH 7.x kernels are effected. Here is more info and a patch: http://www.hardrock.org/kernel/current-updates/duplicate-pid-fix-2.4.23.patch Cheers Johnny From barryn at pobox.com Wed Dec 31 09:36:35 2003 From: barryn at pobox.com (Barry K. Nathan) Date: Wed, 31 Dec 2003 01:36:35 -0800 Subject: RPM upgrade discussion In-Reply-To: <3FF1472D.7030606@togami.com> References: <3FF1472D.7030606@togami.com> Message-ID: <20031231093635.GA2545@ip68-4-255-84.oc.oc.cox.net> On Mon, Dec 29, 2003 at 11:36:45PM -1000, Warren Togami wrote: > 1) What changed about the rpm epoch promotion behavior between rpm-4.2 > and rpm-4.2.1? Can somebody please explain this with details and > concrete examples? I need to understand why we need to keep the old > promotion behavior for the RH9 rpm upgrade as some have mentioned earlier. With rpm-4.2.1-0.30 installed on Red Hat 9: [root at localhost RPMS]# rpm -q mozilla mozilla-1.2.1-26 [root at localhost RPMS]# rpm -q mozilla-chat package mozilla-chat is not installed [root at localhost RPMS]# rpm -ivh mozilla-chat-1.2.1-26.i386.rpm error: Failed dependencies: mozilla = 1.2.1-26 is needed by mozilla-chat-1.2.1-26 [root at localhost RPMS]# With RPM 4.2.1, "mozilla = 1.2.1-26" means mozilla 1.2.1-26 with epoch 0. With RPM 4.2, "mozilla = 1.2.1-26" means mozilla 1.2.1-26 with any epoch. The new (4.2.1) behavior is more predictable, but it breaks backward compatibility with old packages that have broken requirements specifications (i.e., missing specific epochs when they're needed). If we want to move Red Hat 8.0 and 9 over to the new behavior, we could make new mozilla, etc. packages that work properly with RPM 4.2.1, however. -Barry K. Nathan From warren at togami.com Wed Dec 31 10:35:13 2003 From: warren at togami.com (Warren Togami) Date: Wed, 31 Dec 2003 00:35:13 -1000 Subject: RPM upgrade discussion In-Reply-To: <20031231093635.GA2545@ip68-4-255-84.oc.oc.cox.net> References: <3FF1472D.7030606@togami.com> <20031231093635.GA2545@ip68-4-255-84.oc.oc.cox.net> Message-ID: <3FF2A661.5070408@togami.com> Barry K. Nathan wrote: > With RPM 4.2.1, "mozilla = 1.2.1-26" means mozilla 1.2.1-26 with epoch > 0. With RPM 4.2, "mozilla = 1.2.1-26" means mozilla 1.2.1-26 with any > epoch. I recall xmms had similar packaging bugs back then... > > The new (4.2.1) behavior is more predictable, but it breaks backward > compatibility with old packages that have broken requirements > specifications (i.e., missing specific epochs when they're needed). If > we want to move Red Hat 8.0 and 9 over to the new behavior, we could > make new mozilla, etc. packages that work properly with RPM 4.2.1, > however. > Updates for Mozilla will most likely be needed one day, because of the very large complexity of a behemoth like Mozilla we will surely have a security update in the future. I think. Warren From warren at togami.com Wed Dec 31 10:46:28 2003 From: warren at togami.com (Warren Togami) Date: Wed, 31 Dec 2003 00:46:28 -1000 Subject: Please follow the KISS principle In-Reply-To: <3FF21B03.4020806@sohanet.de> References: <3FF21B03.4020806@sohanet.de> Message-ID: <3FF2A904.2070400@togami.com> Bernd Bartmann wrote: > Hi all, > > after reading Warrens drafts and the answers I'm getting the impressions > that this projects start way to complicated. Let us just follow the KISS > principle (keep it simple stupid). As Fedora-Legacy only exists to > handle security updates and is not intended to introduce new features to > EOLed distributions we should really focus on the essentials. For me > this means NO rpm upgrades. Regarding RH8, this is totally infeasible. If the community demands that RH8 is not upgraded, then I personally have zero reason to work on this project. RH9 is less of a problem, but deadlocks still were common enough there that I really feel upgrading is wise. It would also have the benefit of allowing the use of 2.6 kernels without the annoying O_DIRECT problem. Ultimately it is terrible that we must continue to this day to tell people to manually kill their rpm processes and delete the lock files whenever this happens. Upgrading RH8 and RH9 rpm will simply make these problems go away, and the benefits far outweigh the risks here. > Just use the infrastructure and tools that > Red Hat gave us with their distributions. I very strongly oppose this, and below is why. > > Updated packages should primarily be available via HTTP/FTP. Progeny > also will focus on HTTP first. If someone can provide RSYNC, APT or YUM > repositories later this would be fine but it is not needed in the first > place. 1) The RH8 and RH9 repository has already been launched, and there have been mirrors and users for something like the past 9 months. apt and yum are already supported. The same will soon be launched for RH7.x. 2) Regarding "infrastructure and tools", it is infeasible to use the tools that come with those older distributions because that would require running a server like current. current just does not scale well, and far fewer mirrors would be willing to use it. up2date from FC1 could be backported, but nobody even mentioned putting forward the work to do that yet. There is also the fact that apt and yum are vastly superior to up2date in most ways, thus we should use the best tools available. > > Personally I can offer to do package QA testing and bug reporting. I > have access to RH 7.2/7.3/8.0 test servers and already do a little bit > QA on some of the fedora.us packages. Excellent. > > How shall we handle security alert notification to the developers? Can > we expect that everyone monitors all major (open) security mailing lists > ? At least I do so. Yes, and any knowledge already in the wild should be posted to the legacy list for discussion. Some of us may be on private security lists, and we will need to create policies for handling this "secret" knowledge. Please suggest such policy. Warren From warren at togami.com Wed Dec 31 10:52:28 2003 From: warren at togami.com (Warren Togami) Date: Wed, 31 Dec 2003 00:52:28 -1000 Subject: RPM upgrade discussion In-Reply-To: <20031231093635.GA2545@ip68-4-255-84.oc.oc.cox.net> References: <3FF1472D.7030606@togami.com> <20031231093635.GA2545@ip68-4-255-84.oc.oc.cox.net> Message-ID: <3FF2AA6C.4010807@togami.com> Barry K. Nathan wrote: > The new (4.2.1) behavior is more predictable, but it breaks backward > compatibility with old packages that have broken requirements > specifications (i.e., missing specific epochs when they're needed). If > we want to move Red Hat 8.0 and 9 over to the new behavior, we could > make new mozilla, etc. packages that work properly with RPM 4.2.1, > however. This btw is why I am sad that Matthias, to this day, refuses to add explicit epochs to versioned dependencies in the freshrpms packages. It is so apparent that this can lead to real problems later, so much so that even Red Hat began doing this recently for their own packages. This particular policy has been strictly enforced by fedora.us for a long time now, but unfortunately has been one of the emotional points of contention that caused certain key contributors to not join fedora.us. (Just to be clear, this is not a personal attack on Matthias. His great work at freshrpms.net is what inspired me to create Fedora in the first place.) Warren From jonny.strom at netikka.fi Wed Dec 31 11:25:20 2003 From: jonny.strom at netikka.fi (Johnny Strom) Date: Wed, 31 Dec 2003 13:25:20 +0200 Subject: Please follow the KISS principle In-Reply-To: <3FF2A904.2070400@togami.com> References: <3FF21B03.4020806@sohanet.de> <3FF2A904.2070400@togami.com> Message-ID: <3FF2B220.9010207@netikka.fi> Warren Togami wrote: > Bernd Bartmann wrote: > >> Hi all, >> >> after reading Warrens drafts and the answers I'm getting the impressions >> that this projects start way to complicated. Let us just follow the KISS >> principle (keep it simple stupid). As Fedora-Legacy only exists to >> handle security updates and is not intended to introduce new features to >> EOLed distributions we should really focus on the essentials. For me >> this means NO rpm upgrades. > > > Regarding RH8, this is totally infeasible. If the community demands > that RH8 is not upgraded, then I personally have zero reason to work on > this project. Perhaps it would be a good ide to relase bugfixed pakckages located at a separate place (directory) from the primary security fixes then users can uppdate the bugfixed packages if they so need or want to. > > RH9 is less of a problem, but deadlocks still were common enough there > that I really feel upgrading is wise. It would also have the benefit of > allowing the use of 2.6 kernels without the annoying O_DIRECT problem. > > Ultimately it is terrible that we must continue to this day to tell > people to manually kill their rpm processes and delete the lock files > whenever this happens. Upgrading RH8 and RH9 rpm will simply make these > problems go away, and the benefits far outweigh the risks here. > >> Just use the infrastructure and tools that >> Red Hat gave us with their distributions. > > > I very strongly oppose this, and below is why. > >> >> Updated packages should primarily be available via HTTP/FTP. Progeny >> also will focus on HTTP first. If someone can provide RSYNC, APT or YUM >> repositories later this would be fine but it is not needed in the first >> place. > > > 1) The RH8 and RH9 repository has already been launched, and there have > been mirrors and users for something like the past 9 months. apt and > yum are already supported. The same will soon be launched for RH7.x. > 2) Regarding "infrastructure and tools", it is infeasible to use the > tools that come with those older distributions because that would > require running a server like current. current just does not scale > well, and far fewer mirrors would be willing to use it. > up2date from FC1 could be backported, but nobody even mentioned putting > forward the work to do that yet. > There is also the fact that apt and yum are vastly superior to up2date > in most ways, thus we should use the best tools available. > >> >> Personally I can offer to do package QA testing and bug reporting. I >> have access to RH 7.2/7.3/8.0 test servers and already do a little bit >> QA on some of the fedora.us packages. > > > Excellent. > >> >> How shall we handle security alert notification to the developers? Can >> we expect that everyone monitors all major (open) security mailing lists >> ? At least I do so. > > > Yes, and any knowledge already in the wild should be posted to the > legacy list for discussion. Some of us may be on private security > lists, and we will need to create policies for handling this "secret" > knowledge. Please suggest such policy. > > Warren > > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-legacy-list > From warren at togami.com Wed Dec 31 11:42:23 2003 From: warren at togami.com (Warren Togami) Date: Wed, 31 Dec 2003 01:42:23 -1000 Subject: Please follow the KISS principle In-Reply-To: <3FF2B220.9010207@netikka.fi> References: <3FF21B03.4020806@sohanet.de> <3FF2A904.2070400@togami.com> <3FF2B220.9010207@netikka.fi> Message-ID: <3FF2B61F.5010403@togami.com> Johnny Strom wrote: >> >> Regarding RH8, this is totally infeasible. If the community demands >> that RH8 is not upgraded, then I personally have zero reason to work >> on this project. > > Perhaps it would be a good ide to relase bugfixed pakckages located > at a separate place (directory) from the primary security fixes then > users can uppdate the bugfixed packages if they so need or want to. I am trying to remember... I believe this means we would need to maintain two separate sets of package management tools, as apt compiled for rpm-4.1 and rpm-4.1.1 are different. I could be wrong though. I dislike the idea of splitting bugfix and security updates because it would further add complexity to the client configuration, as well as add more unnecessary work to the project. If the concern is that we will go wild with arbitrary bugfix packages, this is totally not the case. Bugfixes will be very rare in Legacy, and only in cases where there is no credible opposition. (Actually, non-critical bugfixes will probably go into the "stable" channel of fedora.us, which is not by default part of Legacy's default channels.) Regarding RPM specifically, it is a losing proposition to even suggest using RH8 without an RPM upgrade. And don't worry about the stability of that RPM upgrade, as it is very well understood and tested for a very great amount of time and analysis involved. We at fedora.us have been arguing about this all year now. This is nothing new, like people here seem to think it is. Warren From jonny.strom at netikka.fi Wed Dec 31 11:59:12 2003 From: jonny.strom at netikka.fi (Johnny Strom) Date: Wed, 31 Dec 2003 13:59:12 +0200 Subject: Please follow the KISS principle In-Reply-To: <3FF2B61F.5010403@togami.com> References: <3FF21B03.4020806@sohanet.de> <3FF2A904.2070400@togami.com> <3FF2B220.9010207@netikka.fi> <3FF2B61F.5010403@togami.com> Message-ID: <3FF2BA10.7010700@netikka.fi> Warren Togami wrote: > Johnny Strom wrote: > >>> >>> Regarding RH8, this is totally infeasible. If the community demands >>> that RH8 is not upgraded, then I personally have zero reason to work >>> on this project. >> >> >> Perhaps it would be a good ide to relase bugfixed pakckages located >> at a separate place (directory) from the primary security fixes then >> users can uppdate the bugfixed packages if they so need or want to. > > > I am trying to remember... I believe this means we would need to > maintain two separate sets of package management tools, as apt compiled > for rpm-4.1 and rpm-4.1.1 are different. I could be wrong though. > > I dislike the idea of splitting bugfix and security updates because it > would further add complexity to the client configuration, as well as add > more unnecessary work to the project. If the concern is that we will go > wild with arbitrary bugfix packages, this is totally not the case. > Bugfixes will be very rare in Legacy, and only in cases where there is > no credible opposition. > > (Actually, non-critical bugfixes will probably go into the "stable" > channel of fedora.us, which is not by default part of Legacy's default > channels.) > > Regarding RPM specifically, it is a losing proposition to even suggest > using RH8 without an RPM upgrade. And don't worry about the stability > of that RPM upgrade, as it is very well understood and tested for a very > great amount of time and analysis involved. We at fedora.us have been > arguing about this all year now. This is nothing new, like people here > seem to think it is. > > Warren Hi I was thinking that the bugfixes that are rear should be separated so that it would be opptional for users to go and download them manually from ftp or http. If it is done like that then the bugfixes will not make any extra trouble for the primary security fixes and no changes would be needed to any client or am I wrong about that?. In this way we would follow the KISS method and still make ppl happy that want to fix some bugs. Johnny > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-legacy-list > From pearcec at commnav.com Wed Dec 31 14:01:42 2003 From: pearcec at commnav.com (Christian Pearce) Date: 31 Dec 2003 09:01:42 -0500 Subject: Please follow the KISS principle In-Reply-To: <3FF2BA10.7010700@netikka.fi> References: <3FF21B03.4020806@sohanet.de> <3FF2A904.2070400@togami.com> <3FF2B220.9010207@netikka.fi> <3FF2B61F.5010403@togami.com> <3FF2BA10.7010700@netikka.fi> Message-ID: <1072879301.12157.17.camel@insight.pearcec.com> On Wed, 2003-12-31 at 06:59, Johnny Strom wrote: > Warren Togami wrote: > > I am trying to remember... I believe this means we would need to > > maintain two separate sets of package management tools, as apt compiled > > for rpm-4.1 and rpm-4.1.1 are different. I could be wrong though. > > > > I dislike the idea of splitting bugfix and security updates because it > > would further add complexity to the client configuration, as well as add > > more unnecessary work to the project. If the concern is that we will go > > wild with arbitrary bugfix packages, this is totally not the case. > > Bugfixes will be very rare in Legacy, and only in cases where there is > > no credible opposition. > > > > (Actually, non-critical bugfixes will probably go into the "stable" > > channel of fedora.us, which is not by default part of Legacy's default > > channels.) > > > > Regarding RPM specifically, it is a losing proposition to even suggest > > using RH8 without an RPM upgrade. And don't worry about the stability > > of that RPM upgrade, as it is very well understood and tested for a very > > great amount of time and analysis involved. We at fedora.us have been > > arguing about this all year now. This is nothing new, like people here > > seem to think it is. > > > > Warren > > Hi > > I was thinking that the bugfixes that are rear should be separated > so that it would be opptional for users to go and download them > manually from ftp or http. If it is done like that then the bugfixes > will not make any extra trouble for the primary security fixes and no > changes would be needed to any client or am I wrong about that?. > > In this way we would follow the KISS method and still make ppl > happy that want to fix some bugs. > I think what Warren is trying to say is that the RPM upgrade is a special bug fix that makes sense moving forward. It makes sense to perform this fix because it affects the system by which we upgrade our servers. Plus it is a special case and it is well understood. If it takes upgrading rpm for RedHat 8.0 and RedHat 9 to keep interest in the project I am for it. I think we are intelligent enough to manage this. I personally plan on moving all my machines over to 8.0 and 9. So I rather have the rpm stability. BTW: What is progeny doing? I think if people are interested in a pure play security fix for there servers they might want to consider them. I think Fedora Legacy intended to be a little more than that. Help blurb: While I think I will have time to do patching and packages, I am not certain I have the proper knowledge of C (in most cases) to perform the proper backported security patch. I have a great understanding of rpm packaging. So if there are not enough people to make this happen I am certainly willing to try. But I can only hope that our QA people are equally as diligent. My offer also extends to QAing packages. I work for a software shop that has a very decent build and QA process. It wouldn't be difficult for me to test new packages and give them a thorough testing. -- Christian Pearce http://www.commnav.com From barryn at pobox.com Wed Dec 31 11:15:48 2003 From: barryn at pobox.com (Barry K. Nathan) Date: Wed, 31 Dec 2003 03:15:48 -0800 Subject: RPM upgrade discussion In-Reply-To: <20031230112238.GB13067@neu.nirvana> References: <3FF1472D.7030606@togami.com> <3FF1472D.7030606@togami.com> <20031230112238.GB13067@neu.nirvana> Message-ID: <20031231111548.GB2545@ip68-4-255-84.oc.oc.cox.net> On Tue, Dec 30, 2003 at 12:22:38PM +0100, Axel Thimm wrote: > o Red Hat never made rpm.org's errata official for any reasons they > may have. I suggest asking why. Probably they do not consider the > rpm upgrades stable enough. This is a strong signal not to go that > way. It's a weak signal at best. I think it's more likely that Red Hat QA had their hands full with security updates and didn't want to spend any time/resources QA-ing bug fix packages for RPM. In fact, Red Hat didn't even bother releasing an update to fix this security problem in logwatch in Red Hat 8.0: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=83097 IME, the rpm.org errata are definitely more stable than what ships with Red Hat 8.0/9. -Barry K. Nathan From rohwedde at codegrinder.com Wed Dec 31 16:26:47 2003 From: rohwedde at codegrinder.com (Jason) Date: Wed, 31 Dec 2003 10:26:47 -0600 Subject: Please follow the KISS principle In-Reply-To: <3FF2B61F.5010403@togami.com> References: <3FF21B03.4020806@sohanet.de> <3FF2A904.2070400@togami.com> <3FF2B220.9010207@netikka.fi> <3FF2B61F.5010403@togami.com> Message-ID: <20031231162647.GM17980@codegrinder.com> On Wed, Dec 31, 2003 at 01:42:23AM -1000, Warren Togami wrote: > Johnny Strom wrote: > >> > >>Regarding RH8, this is totally infeasible. If the community demands > >>that RH8 is not upgraded, then I personally have zero reason to work > >>on this project. > > > >Perhaps it would be a good ide to relase bugfixed pakckages located > >at a separate place (directory) from the primary security fixes then > >users can uppdate the bugfixed packages if they so need or want to. > > I am trying to remember... I believe this means we would need to > maintain two separate sets of package management tools, as apt compiled > for rpm-4.1 and rpm-4.1.1 are different. I could be wrong though. > > I dislike the idea of splitting bugfix and security updates because it > would further add complexity to the client configuration, as well as add > more unnecessary work to the project. If the concern is that we will go > wild with arbitrary bugfix packages, this is totally not the case. > Bugfixes will be very rare in Legacy, and only in cases where there is > no credible opposition. > > (Actually, non-critical bugfixes will probably go into the "stable" > channel of fedora.us, which is not by default part of Legacy's default > channels.) > > Regarding RPM specifically, it is a losing proposition to even suggest > using RH8 without an RPM upgrade. And don't worry about the stability > of that RPM upgrade, as it is very well understood and tested for a very > great amount of time and analysis involved. We at fedora.us have been > arguing about this all year now. This is nothing new, like people here > seem to think it is. > > Warren > I agree with this stance, that in general we should avoid branching packages. As long as there is a consensus to implement a bugfix, I have no problem with it going in. If the end user entrusts us to backport security fixes, I imagine they'll trust us not to patch in unnecessary bugfixes. -jason From rdieter at math.unl.edu Wed Dec 31 17:36:56 2003 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 31 Dec 2003 11:36:56 -0600 Subject: RPM upgrade discussion In-Reply-To: <20031230170003.5221.78716.Mailman@listman.back-rdu.redhat.com> References: <20031230170003.5221.78716.Mailman@listman.back-rdu.redhat.com> Message-ID: <3FF30938.8070404@math.unl.edu> Warren wrote: > 3) Which specific RPM versions should we use? In my personal experience ... > Should we upgrade to rpm-4.2.x on RH7.x, RH8 and RH9, or use the above > mentioned versions? IMO, my preference is that rpm version used should be standardized across *all* supported platforms, ie, use the same version, rpm-4.2.x, for all and be done with it. I believe this will make the building and testing of packages, especially rpm-releated ones (like apt, yum, etc...), more consistent. -- Rex From jkeating at j2solutions.net Wed Dec 31 17:41:24 2003 From: jkeating at j2solutions.net (Jesse Keating) Date: Wed, 31 Dec 2003 09:41:24 -0800 Subject: RPM upgrade discussion In-Reply-To: <3FF30938.8070404@math.unl.edu> References: <20031230170003.5221.78716.Mailman@listman.back-rdu.redhat.com> <3FF30938.8070404@math.unl.edu> Message-ID: <200312310941.30133.jkeating@j2solutions.net> On Wednesday 31 December 2003 09:36, Rex Dieter wrote: > IMO, my preference is that rpm version used should be standardized > across *all* supported platforms, ie, use the same version, > rpm-4.2.x, for all and be done with it. I believe this will make the > building and testing of packages, especially rpm-releated ones (like > apt, yum, etc...), more consistent. I don't believe this will work due to python versions in 7.2/3. -- Jesse Keating RHCE MCSE (geek.j2solutions.net) Fedora Legacy Team (www.fedora.us/wiki/FedoraLegacy) Mondo DevTeam (www.mondorescue.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From skvidal at phy.duke.edu Wed Dec 31 23:21:52 2003 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 31 Dec 2003 18:21:52 -0500 Subject: Kernel security issue. In-Reply-To: <3FF28CAC.3030804@netikka.fi> References: <3FF28CAC.3030804@netikka.fi> Message-ID: <1072912911.10379.73.camel@binkley> On Wed, 2003-12-31 at 03:45, Johnny Strom wrote: > Hi all > > It seems that there is a security issue in the kernel, > I don't know if RH 7.x kernels are effected. > > Here is more info and a patch: > > http://www.hardrock.org/kernel/current-updates/duplicate-pid-fix-2.4.23.patch > > So is your contention that someone could: 1. exhaust all pids 2. run a program that would never be able to be killed >From reading the explanation that is the only way this could be seen as a security issue. Even so it seems like a pretty obscure one. -sv