From deisenst at gtw.net Mon Nov 6 09:29:30 2006 From: deisenst at gtw.net (David Eisenstein) Date: Mon, 6 Nov 2006 03:29:30 -0600 Subject: You Need Fedora Legacy!! Re: [fab] looking at our surrent state a bit References: <454B2300.8080900@leemhuis.info><454B4112.7030604@fedoraproject.org> <454B5DF0.90908@leemhuis.info> Message-ID: <009601c70186$1009c670$9962cfd0@homedns.org> ----- Original Message ----- From: "Thorsten Leemhuis" To: Sent: Friday, November 03, 2006 9:19 AM Subject: Re: [fab] looking at our surrent state a bit > >> == MISC == > >> > >> * I got the impression (and LWN readers, too ["hello corbert! "]) that > >> Fedora Legacy is not able to do it's job properly. Maybe it's time to > >> just revamp the whole project? > > How? > > Give it a fresh start, a new name (because the Term "Fedora Legacy" has > such a bad fame now), maybe try to get the load reduced (only support > releases with odd number for a longer time, drop old releases). Current Fedora Legacy status: see http://fedoraproject.org/wiki/Legacy/Status Thank you, Thorsten, for having the guts to say it -- at least about Legacy's reputation/infamy now. Of course, corbet had the guts to say it first here: http://lwn.net/Articles/204722/. Thanks, corbet. It needed to be said. The Fedora Project NEEDS Fedora Legacy! I repeat: The Fedora Project NEEDS Fedora Legacy in order to be a viable Linux distribution to be used for anything other than pushing the latest and greatest software out the door for Linux afficianados to play with and submit bugzilla tickets for. As Matthew Miller said at the beginning of Fedora Legacy's thread "lwn article on the death of Fedora Legacy," "Without a functioning lifespan of over a year, Fedora is only practically useful as an enthusiast, bleeding-edge distro. That's only supposed to be _part_ of its mission." -- http://tinyurl.com/ycl3zp Fedora Board, please take heed. Although providing a stable, long-term operating system/environment is *not* one of Fedora Project's stated goals, the practical lifetime of a Fedora release of 1 year (without Legacy to be there to security-maintain them for (at least) 1 more year) is ... ridiculous -- except for the Linux enthusiast and those who love sliding down the razor-blade of computing. The Fedora Legacy build team seems to be down now to 1 or 2 builders who can push packages to Legacy's updates-testing and updates. I am one of that team now, and am the slowest, most pedantic RPM packager/signer/pusher that you'd never wanna meet. The most sure-fire way of killing Fedora Legacy is to let me be the only one doing this essential activity with Fedora Legacy Core packages that need security updates in a timely fashion. Is this really what the Fedora Board and Red Hat wants? Although I am amid working with pushing a gzip security bug ( http://tinyurl.com/yhvh4a ) to updates-testing in the last few days, in general, Legacy Security Updates for FC3 and FC4 are simply not happening. Hopefully by Tuesday or so, this FC3/FC4 bug will at least be in updates-testing for folks to play with and judge, so it can quickly be pushed to updates (only about 2 months after Red Hat Enterprise Linux pushed similar security updates on these issues). In the history of the Fedora Legacy project, IMNSHO it has not been often that updates have been released quickly to end-users (after an security hole has been made public), unless there was a hue-and-cry over on the Fedora-legacy-list about, say, sendmail or some other server program that might allow, say, remotely-controlled anonymous root access to someone's box. I would love to see Fedora Legacy (by that name or any other name) take off and prosper, and be a real boon to users of maintenance-mode Fedora Core (and Red Hat Linux -- yes, we are continuing to roll some updates to RHL 7.3 and RHL9 until December ... um ... at least I think we are??). But as some folks have clearly said, until it does, at least to take care of the *critical* security bugs (letting the moderate or important or low-security-impact bugs slide until we have the manpower to handle them) -- THE EXISTENCE OF FEDORA LEGACY IS PROVIDING A FALSE SENSE OF SECURITY FOR OUR END-USERS ... at least at this time. If you don't believe that -- look at this article about Fedora Core 6 on eWeek Magazine's web-site, by the excellent writer, Jason Brooks: http://www.eweek.com/article2/0,1895,2048117,00.asp It's not the article, really, that proves my point. It's the article's talkback. I wish what commenter "unoengborg" was saying were true. Really, really, really wish. But it ain't -- not yet. Will it ever be? That's up to you, dear reader. I would like to propose a time folks interested in a vital and alive (even revamped) FedoraLegacy project can come on over to IRC (freenode.net) and sit and yack awhile, brainstorming and struggling with these issues. I plan to be online over on channel #fedora-legacy around 10am CST for at least two hours every day this week. Come by. Come chat. Come yell! Just come! We need your help! Thank you. Warm regards, David Eisenstein From rdieter at math.unl.edu Mon Nov 6 14:21:26 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 06 Nov 2006 08:21:26 -0600 Subject: You Need Fedora Legacy!! Re: [fab] looking at our surrent state a bit References: <454B2300.8080900@leemhuis.info><454B4112.7030604@fedoraproject.org> <454B5DF0.90908@leemhuis.info> <009601c70186$1009c670$9962cfd0@homedns.org> Message-ID: David Eisenstein wrote: > Fedora Board, please take heed. Although providing a stable, long-term > operating system/environment is *not* one of Fedora Project's stated > goals, the practical lifetime of a Fedora release of 1 year (without > Legacy to be there to security-maintain them for (at least) 1 more year) > is ... ridiculous -- except for the Linux enthusiast and those who love > sliding down the razor-blade of computing. > > The Fedora Legacy build team seems to be down now to 1 or 2 builders who > can push packages to Legacy's updates-testing and updates. OK, I'll bite. What do you want exactly from the Board? Wave our magic Fedora wand to produce more (active) community contributors? OK, lemme see, now where did I leave that darn thing... -- Rex From geek at uniserve.com Mon Nov 6 14:59:11 2006 From: geek at uniserve.com (Dave Stevens) Date: Mon, 6 Nov 2006 06:59:11 -0800 Subject: You Need Fedora Legacy!! Re: [fab] looking at our surrent state a bit In-Reply-To: References: <454B2300.8080900@leemhuis.info> <009601c70186$1009c670$9962cfd0@homedns.org> Message-ID: <200611060659.11497.geek@uniserve.com> On Monday 06 November 2006 06:21, Rex Dieter wrote: > David Eisenstein wrote: > > Fedora Board, please take heed. Although providing a stable, long-term > > operating system/environment is *not* one of Fedora Project's stated > > goals, the practical lifetime of a Fedora release of 1 year (without > > Legacy to be there to security-maintain them for (at least) 1 more year) > > is ... ridiculous -- except for the Linux enthusiast and those who love > > sliding down the razor-blade of computing. > > > > The Fedora Legacy build team seems to be down now to 1 or 2 builders who > > can push packages to Legacy's updates-testing and updates. > > OK, I'll bite. What do you want exactly from the Board? > > Wave our magic Fedora wand to produce more (active) community contributors? > OK, lemme see, now where did I leave that darn thing... > > -- Rex a confession of inadequacy is more of a preliminary than an answer Dave > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-legacy-list -- "How are nations ruled and led into war? Politicians lie to journalists and then believe those lies when they see them in print." ?Austrian journalist Karl Wiegand, explaining the causes of the First World War. From jkeating at j2solutions.net Mon Nov 6 15:16:21 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 6 Nov 2006 10:16:21 -0500 Subject: You Need Fedora Legacy!! Re: [fab] looking at our surrent state a bit In-Reply-To: <200611060659.11497.geek@uniserve.com> References: <454B2300.8080900@leemhuis.info> <200611060659.11497.geek@uniserve.com> Message-ID: <200611061016.21889.jkeating@j2solutions.net> On Monday 06 November 2006 09:59, Dave Stevens wrote: > a confession of inadequacy is more of a preliminary than an answer Confession how? How would it be any different from the Fedora Legacy project itself from making some sort of 'confession' ? The unfortunate problem is ours to solve. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkosin at beta.intcomgrp.com Mon Nov 6 15:22:04 2006 From: jkosin at beta.intcomgrp.com (James Kosin) Date: Mon, 06 Nov 2006 10:22:04 -0500 Subject: You Need Fedora Legacy!! Re: [fab] looking at our surrent state a bit In-Reply-To: <200611060659.11497.geek@uniserve.com> References: <454B2300.8080900@leemhuis.info> <009601c70186$1009c670$9962cfd0@homedns.org> <200611060659.11497.geek@uniserve.com> Message-ID: <454F531C.7040404@beta.intcomgrp.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dave Stevens wrote: > a confession of inadequacy is more of a preliminary than an answer > > Dave Sorry, to butt in.... Maybe, what we need to do is have a re-organization of the idea of FedoraLegacy instead of trying to overtax anyone. Or chase anyone away from helping. Just some proposals: (1) Every new release into fedora legacy should start with a collection of a group to manage the packages for that version. And only that version to help alleviate getting overwhelmed with multiple platforms, dependencies, etc. Yes, I know this may cause issues, but, it may be better than the current situation of lagging releases and other dependencies slowing the release of one package or another for each platform. Or having to just drop everything causing more problems for others wanting updates. (2) Each FC version can be maintained by a different group, pushing, etc the updates for that version only. Of course, we can have a supper user able to verify and validate everything pushed through by the group (RH). (3) Make it easier for people to get involved. Having a list of packages and maintainers is OK, but, having a few people managing large numbers of packages is very difficult. I'd say a limit of 5-10 packages may be reasonable.... any more than that will cut out others from helping. (4) Everyone needs to follow some rules when releasing anything for testing...! Very important. (a) Email this list!!!!!! (b) Include the bugzilla ID and or link to post checks against the package. (c) Try to include any steps to produce the problem reported by CVE. or have a link to such documentation to be sure the fix actually fixes the issue. (5) Everyone verifying packages: (a) Verify installation of the packages. (b) Be sure the applications still WORK. Installation is not the only thing that should be verified. (c) Be sure to check to be sure nothing is broken, to your ability. Lastly, we really need to work together more! - -James -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFT1MXkNLDmnu1kSkRAoLlAJ0bBTehG2QWSIHR7CL6kFBEnzH4zQCfatSn IlLIMFJzx7feFYY3rEXOLxE= =xn5n -----END PGP SIGNATURE----- -- Scanned by ClamAV - http://www.clamav.net From mattdm at mattdm.org Tue Nov 7 03:04:06 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Mon, 6 Nov 2006 22:04:06 -0500 Subject: You Need Fedora Legacy!! Re: [fab] looking at our surrent state a bit In-Reply-To: References: <454B5DF0.90908@leemhuis.info> <009601c70186$1009c670$9962cfd0@homedns.org> Message-ID: <20061107030406.GA21221@jadzia.bu.edu> On Mon, Nov 06, 2006 at 08:21:26AM -0600, Rex Dieter wrote: > Wave our magic Fedora wand to produce more (active) community contributors? > OK, lemme see, now where did I leave that darn thing... Well, to be honest, a little bit, yeah. There just hasn't been good infrastructure in place for contributors. The current/previous process had a very high learning curve, and all manner of quirks. It would have been great if more community people could have stepped in to help with this. In fact, I offered to do some specific things back when I actually had spare time, but wasn't able to get it these things coordinated to actually happen. These infrastructure things would work better with "insider" support. And only if the infrastructure is there do active community contributors have a chance. Additionally, the project simply needs at least one person who manages the project as a full-time job. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From mattdm at mattdm.org Tue Nov 7 03:21:24 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Mon, 6 Nov 2006 22:21:24 -0500 Subject: You Need Fedora Legacy!! Re: [fab] looking at our surrent state a bit In-Reply-To: <20061107030406.GA21221@jadzia.bu.edu> References: <454B5DF0.90908@leemhuis.info> <009601c70186$1009c670$9962cfd0@homedns.org> <20061107030406.GA21221@jadzia.bu.edu> Message-ID: <20061107032124.GA21978@jadzia.bu.edu> On Mon, Nov 06, 2006 at 10:04:06PM -0500, Matthew Miller wrote: > Additionally, the project simply needs at least one person who manages the > project as a full-time job. And by "needs", I mean: I'm very skeptical that it can be viable without this. While the project was in its most functional stage, Jesse Keating was basically doing this, and without, it collapsed. * If no such person can be found, I think it's most responsible to declare the experiment completely failed. [*] And, I suspect that the extent to which he had other things to do in his job at Pogo Linux correlates pretty well with the extent to which the project could have improved further at that stage. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From deisenst at gtw.net Tue Nov 7 03:50:51 2006 From: deisenst at gtw.net (David Eisenstein) Date: Mon, 06 Nov 2006 21:50:51 -0600 Subject: Fedora Legacy Test Update Notification: gzip Message-ID: <4550029B.5020503@gtw.net> with thanks to Ali Lomonaco and Michal Jaegermann for proposing packages! -------------------------------------------------------------------- Fedora Legacy Test Update Notification FEDORALEGACY-2006-211760 Bugzilla https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=211760 2006-11-06 --------------------------------------------------------------------- Name : gzip Versions : fc3: gzip-1.3.3-16.1.fc3.legacy Versions : fc4: gzip-1.3.5-6.1.0.legacy Summary : The GNU data compression program. Description : The gzip package contains the popular GNU gzip data compression program. Gzipped files have a .gz extension. Gzip should be installed on your Red Hat Linux system, because it is a very commonly used data compression program. --------------------------------------------------------------------- Update Information: Updated gzip packages that fix several security issues are now available. The gzip package contains the GNU gzip data compression program. Tavis Ormandy of the Google Security Team discovered two denial of service flaws in the way gzip expanded archive files. If a victim expanded a specially crafted archive, it could cause the gzip executable to hang or crash. (CVE-2006-4334, CVE-2006-4338) Tavis Ormandy of the Google Security Team discovered several code execution flaws in the way gzip expanded archive files. If a victim expanded a specially crafted archive, it could cause the gzip executable to crash or execute arbitrary code. (CVE-2006-4335, CVE-2006-4336, CVE-2006-4337) Users of gzip should upgrade to these updated packages, which contain a backported patch and is not vulnerable to these issues. --------------------------------------------------------------------- Changelogs fc3: * Sat Nov 4 2006 David Eisenstein 1.3.3-16.1.fc3.legacy - Add BuildRequires: texinfo, so gzip.info will be properly created. * Sat Nov 4 2006 David Eisenstein 1.3.3-16.fc3.legacy - Fedora Legacy bugzilla #211760, fixing the 5 cve's mentioned below. - Patches taken from RHEL 4. * Wed Sep 6 2006 Ivana Varekova 1.3.3-16.rhel4 - fix bug 204676 (patches by Tavis Ormandy) - cve-2006-4334 - null dereference problem - cve-2006-4335 - buffer overflow problem - cve-2006-4336 - buffer underflow problem - cve-2006-4338 - infinite loop problem - cve-2006-4337 - buffer overflow problem fc4: * Tue Oct 31 2006 David Eisenstein - 1.3.5-6.1.0.legacy - Rebuilt for FC4, reversioning so upgrade path will not be broken. * Sun Oct 22 2006 Ali Lomonaco - 1.3.5-9 - rebuilt for Legacy Bugzilla #211760. - fixes CVE-2006-{4334,4335,4336,4337,4338}. * Sun Oct 01 2006 Jesse Keating - 1.3.5-9 - rebuilt for unwind info generation, broken in gcc-4.1.1-21 * Wed Sep 20 2006 Ivana Varekova 1.3.5-8 - fix bug 204676 (patches by Tavis Ormandy) - cve-2006-4334 - null dereference problem - cve-2006-4335 - buffer overflow problem - cve-2006-4336 - buffer underflow problem - cve-2006-4338 - infinite loop problem - cve-2006-4337 - buffer overflow problem * Fri Jul 14 2006 Karsten Hopp 1.3.5-7 - buildrequire texinfo, otherwise gzip.info will be empty --------------------------------------------------------------------- This update can be downloaded from: http://download.fedoralegacy.org/ (sha1sums) fc3: 803cef0b8d4e06f79ae9ce64aee63cdd761e87b6 fedora/3/updates-testing/i386/gzip-1.3.3-16.1.fc3.legacy.i386.rpm 602ad6828a3388063db0c45f13c256d92b12cc51 fedora/3/updates-testing/x86_64/gzip-1.3.3-16.1.fc3.legacy.x86_64.rpm 7f4737f9e627480ee211022b9dffc1da5696adda fedora/3/updates-testing/SRPMS/gzip-1.3.3-16.1.fc3.legacy.src.rpm fc4: 1cf4530543c8f7da0d331f11388bb7517fa013e4 fedora/4/updates-testing/i386/gzip-1.3.5-6.1.0.legacy.i386.rpm 17fb012aacf13fcf623c5f6447d4ba127ed4a780 fedora/4/updates-testing/x86_64/gzip-1.3.5-6.1.0.legacy.x86_64.rpm b49360a81b5d4df62dbbb3b2b094515678f41a35 fedora/4/updates-testing/SRPMS/gzip-1.3.5-6.1.0.legacy.src.rpm --------------------------------------------------------------------- Please test and comment in bugzilla. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From Axel.Thimm at ATrpms.net Tue Nov 7 10:31:51 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 7 Nov 2006 11:31:51 +0100 Subject: You Need Fedora Legacy!! Re: [fab] looking at our surrent state a bit In-Reply-To: References: <454B5DF0.90908@leemhuis.info> <009601c70186$1009c670$9962cfd0@homedns.org> Message-ID: <20061107103151.GE22994@neu.nirvana> On Mon, Nov 06, 2006 at 08:21:26AM -0600, Rex Dieter wrote: > David Eisenstein wrote: > > > Fedora Board, please take heed. Although providing a stable, long-term > > operating system/environment is *not* one of Fedora Project's stated > > goals, the practical lifetime of a Fedora release of 1 year (without > > Legacy to be there to security-maintain them for (at least) 1 more year) > > is ... ridiculous -- except for the Linux enthusiast and those who love > > sliding down the razor-blade of computing. > > > > The Fedora Legacy build team seems to be down now to 1 or 2 builders who > > can push packages to Legacy's updates-testing and updates. > > OK, I'll bite. What do you want exactly from the Board? > > Wave our magic Fedora wand to produce more (active) community contributors? > OK, lemme see, now where did I leave that darn thing... :) I don't know if the board has power over suggesting to Fedora's sponsor, Red Hat, to resuffle its engineering resources, but if so, then it's a simple equation: If FL is indeed going to get more resources to prolong a Fedora release's lifespan then these resources need to be drained from somewhere. This can't be rawhide and the latest release, but maybe the previous release (like in this timeframe FC5). And it can't be Rex' magic hat either, I think it only produces rabbits and not yet FL contributors. ;) There are a couple of non-security/non-bugfixes updates happening in FC5 right now, that maybe could had been cast into FL4 support. And in the context of sparing resources FL would have to narrow the support matrix to only one FL release. E.g. better to have good support for one release than only half for two. That drops half a year of support, but gains more trust back to FL if security issues within a release can be addressed for that other half year in a timely fashion. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From pertusus at free.fr Tue Nov 7 11:07:07 2006 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 7 Nov 2006 12:07:07 +0100 Subject: You Need Fedora Legacy!! Re: [fab] looking at our surrent state a bit In-Reply-To: References: <454B5DF0.90908@leemhuis.info> <009601c70186$1009c670$9962cfd0@homedns.org> Message-ID: <20061107110707.GA29294@free.fr> On Mon, Nov 06, 2006 at 08:21:26AM -0600, Rex Dieter wrote: > > OK, I'll bite. What do you want exactly from the Board? > > Wave our magic Fedora wand to produce more (active) community contributors? > OK, lemme see, now where did I leave that darn thing... I see 2 things that could help: * use the fedora extras build system and procedures. I find legacy procedures very complicated. The legacy procedures have merit, there are more verifications, but maybe such procedures should be used in the future when there is a community. * open fedora core to the community. That way people from the community interested in a package could help maintaining it in core and it would help a lot when it transitions to legacy. Currently core is closed to the community and core maintainers often don't collaborate with the community for packaging issues. In the current situation somebody interested in a package in legacy have to learn everything about that package, knowing that he has no control on the package in current and devel release. Co-maintainership in core with community members would help a lot having somebody still taking care of the package in legacy. -- Pat From sundaram at fedoraproject.org Tue Nov 7 18:16:37 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 07 Nov 2006 23:46:37 +0530 Subject: You Need Fedora Legacy!! Re: [fab] looking at our surrent state a bit In-Reply-To: <20061107103151.GE22994@neu.nirvana> References: <454B5DF0.90908@leemhuis.info> <009601c70186$1009c670$9962cfd0@homedns.org> <20061107103151.GE22994@neu.nirvana> Message-ID: <4550CD85.4020801@fedoraproject.org> Axel Thimm wrote: > I don't know if the board has power over suggesting to Fedora's > sponsor, Red Hat, to resuffle its engineering resources, but if so, > then it's a simple equation: If FL is indeed going to get more > resources to prolong a Fedora release's lifespan then these resources > need to be drained from somewhere. This can't be rawhide and the > latest release, but maybe the previous release (like in this timeframe > FC5). And it can't be Rex' magic hat either, I think it only produces > rabbits and not yet FL contributors. ;) Board can make suggestions, yes. Dictate, no. The board doesnt have the resources in hand to allocate to sub projects. It can set policies and thats the primary work that's being done. If it comes to resources, reshuffling wont work since there is noone working on the previous release that is not working on the current release of Fedora and rawhide too. Its all part of the common pool. If we pull people out of that, we would effectively reducing the amount of movement forward. It would be possible to recommend that Red Hat hire *new people* to work solely on legacy but justifying that is harder compared to active upstream or new release development. Unifying and opening up more of the infrastructure and other ideas like that only doing critical security fixes are things to look at. Rahul From pekkas at netcore.fi Tue Nov 7 18:20:42 2006 From: pekkas at netcore.fi (Pekka Savola) Date: Tue, 7 Nov 2006 20:20:42 +0200 (EET) Subject: Fedora Legacy Test Update Notification: gzip In-Reply-To: <4550029B.5020503@gtw.net> References: <4550029B.5020503@gtw.net> Message-ID: On Mon, 6 Nov 2006, David Eisenstein wrote: > Tavis Ormandy of the Google Security Team discovered two denial of service > flaws in the way gzip expanded archive files. If a victim expanded a > specially crafted archive, it could cause the gzip executable to hang or > crash. (CVE-2006-4334, CVE-2006-4338) > > Tavis Ormandy of the Google Security Team discovered several code execution > flaws in the way gzip expanded archive files. If a victim expanded a > specially crafted archive, it could cause the gzip executable to crash or > execute arbitrary code. (CVE-2006-4335, CVE-2006-4336, CVE-2006-4337) Those interested in RHL73 may take a look at http://staff.csc.fi/psavola/fl/. It includes RPMs which fix this for RHL73, as well as a a couple of other RPMs fixing the most significant latest issues (e.g., the recently published PHP issue). -- 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 Axel.Thimm at ATrpms.net Tue Nov 7 21:47:21 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 7 Nov 2006 22:47:21 +0100 Subject: You Need Fedora Legacy!! Re: [fab] looking at our surrent state a bit In-Reply-To: <4550CD85.4020801@fedoraproject.org> References: <454B5DF0.90908@leemhuis.info> <009601c70186$1009c670$9962cfd0@homedns.org> <20061107103151.GE22994@neu.nirvana> <4550CD85.4020801@fedoraproject.org> Message-ID: <20061107214721.GA18180@neu.nirvana> On Tue, Nov 07, 2006 at 11:46:37PM +0530, Rahul Sundaram wrote: > Unifying and opening up more of the infrastructure and other ideas like > that only doing critical security fixes are things to look at. But FL's charter is already to only cater about security fixes, or do you imply to categorize them and allow some to slip? E.g. allow local priviledge escalation, but fix remote exploits? I don't think that's a good FL manifesto. Allowing non-critical security issues to exist will only harm the project's front to the public more. The issue is also not the infrstructure IMO, it's simply lack of human resources and either someone needs to assign them to it if that entity (Red Hat/board/whatever) considers that a worthy goal, or the resources need to come from more voluntary people, e.g. FL needs a marketing manager. Or the need for resources is cut by reducing the number and time span of supported releases. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at j2solutions.net Tue Nov 7 21:54:34 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Tue, 7 Nov 2006 16:54:34 -0500 Subject: You Need Fedora Legacy!! Re: [fab] looking at our surrent state a bit In-Reply-To: <20061107214721.GA18180@neu.nirvana> References: <454B5DF0.90908@leemhuis.info> <4550CD85.4020801@fedoraproject.org> <20061107214721.GA18180@neu.nirvana> Message-ID: <200611071654.34766.jkeating@j2solutions.net> On Tuesday 07 November 2006 16:47, Axel Thimm wrote: > The issue is also not the infrstructure IMO, it's simply lack of human > resources Well, if the barrier to contribute was lower, getting more people would be easier. If it were say as easy as using the Extras build system so that any current Extras contributor could easily become a Legacy contributor as well... This is what I'm working towards. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rostetter at mail.utexas.edu Tue Nov 7 21:56:32 2006 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Tue, 7 Nov 2006 15:56:32 -0600 Subject: You Need Fedora Legacy!! Re: [fab] looking at our surrent state a bit In-Reply-To: <20061107214721.GA18180@neu.nirvana> References: <454B5DF0.90908@leemhuis.info> <009601c70186$1009c670$9962cfd0@homedns.org> <20061107103151.GE22994@neu.nirvana> <4550CD85.4020801@fedoraproject.org> <20061107214721.GA18180@neu.nirvana> Message-ID: <20061107155632.hre50c2h9pss88s8@mail.ph.utexas.edu> Quoting Axel Thimm : > The issue is also not the infrstructure IMO, it's simply lack of human > resources and either someone needs to assign them to it if that entity > (Red Hat/board/whatever) considers that a worthy goal, or the > resources need to come from more voluntary people, e.g. FL needs a > marketing manager. I think it is both Infrastructure and lack of humans, plus stupid barriers that shouldn't exist. The learning curve is high, people look down at volunteers just because they don't/won't/can't use some technology (e.g. IRC), and there is little effort expended to get people to participate (though much flaming people for not participating). There is also an emphasis on getting people to only help with QA, which is rather bad. If you can get people to start helping however they feel they can, they will generally and eventually start helping in other areas. But people generally need encouragement, and not flame wars, insults, and barriers. > Or the need for resources is cut by reducing the number and time span > of supported releases. An option, but it only makes the limited resources go further, when what we really need are more resources... > -- > Axel.Thimm at ATrpms.net -- Eric Rostetter The Department of Physics The University of Texas at Austin Go Longhorns! From Axel.Thimm at ATrpms.net Tue Nov 7 21:57:28 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 7 Nov 2006 22:57:28 +0100 Subject: You Need Fedora Legacy!! Re: [fab] looking at our surrent state a bit In-Reply-To: <200611071654.34766.jkeating@j2solutions.net> References: <454B5DF0.90908@leemhuis.info> <4550CD85.4020801@fedoraproject.org> <20061107214721.GA18180@neu.nirvana> <200611071654.34766.jkeating@j2solutions.net> Message-ID: <20061107215728.GC18180@neu.nirvana> On Tue, Nov 07, 2006 at 04:54:34PM -0500, Jesse Keating wrote: > On Tuesday 07 November 2006 16:47, Axel Thimm wrote: > > The issue is also not the infrstructure IMO, it's simply lack of human > > resources > > Well, if the barrier to contribute was lower, getting more people would be > easier. If it were say as easy as using the Extras build system so that any > current Extras contributor could easily become a Legacy contributor as > well... This is what I'm working towards. It's certainly worth while attacking this way, but I think it will not be enough. Let's hope I'm wrong. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From sundaram at fedoraproject.org Tue Nov 7 23:10:50 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 08 Nov 2006 04:40:50 +0530 Subject: You Need Fedora Legacy!! Re: [fab] looking at our surrent state a bit In-Reply-To: <20061107214721.GA18180@neu.nirvana> References: <454B5DF0.90908@leemhuis.info> <009601c70186$1009c670$9962cfd0@homedns.org> <20061107103151.GE22994@neu.nirvana> <4550CD85.4020801@fedoraproject.org> <20061107214721.GA18180@neu.nirvana> Message-ID: <4551127A.9010109@fedoraproject.org> Axel Thimm wrote: > On Tue, Nov 07, 2006 at 11:46:37PM +0530, Rahul Sundaram wrote: >> Unifying and opening up more of the infrastructure and other ideas like >> that only doing critical security fixes are things to look at. > > But FL's charter is already to only cater about security fixes, or do > you imply to categorize them and allow some to slip? E.g. allow local > priviledge escalation, but fix remote exploits? > > I don't think that's a good FL manifesto. Allowing non-critical > security issues to exist will only harm the project's front to the > public more. Not really. It is better than not pushing updates at all. See https://www.redhat.com/archives/fedora-security-list/2006-October/msg00006.html > The issue is also not the infrstructure IMO, it's simply lack of human > resources and either someone needs to assign them to it if that entity > (Red Hat/board/whatever) considers that a worthy goal, or the > resources need to come from more voluntary people, e.g. FL needs a > marketing manager. Lack of human resources is also a result of higher barrier to entry. New people need to be able to contribute easily. Existing contributors in other sub projects like extras need to able to do that. Unifying infrastructure and automating more of the tasks helps in both ways. > Or the need for resources is cut by reducing the number and time span > of supported releases Just as reducing time span is a option, classification of vulnerabilities and working on critical ones after a time span is also a option that needs to be considered. Rahul From tthome at cox.net Wed Nov 8 02:57:38 2006 From: tthome at cox.net (Tim Thome) Date: Tue, 07 Nov 2006 18:57:38 -0800 Subject: You Need Fedora Legacy!! Re: [fab] looking at our surrent state a bit In-Reply-To: <20061107155632.hre50c2h9pss88s8@mail.ph.utexas.edu> References: <454B5DF0.90908@leemhuis.info> <009601c70186$1009c670$9962cfd0@homedns.org> <20061107103151.GE22994@neu.nirvana> <4550CD85.4020801@fedoraproject.org> <20061107214721.GA18180@neu.nirvana> <20061107155632.hre50c2h9pss88s8@mail.ph.utexas.edu> Message-ID: <455147A2.9050901@cox.net> Eric Rostetter wrote: > Quoting Axel Thimm : > >> The issue is also not the infrstructure IMO, it's simply lack of human >> resources and either someone needs to assign them to it if that entity >> (Red Hat/board/whatever) considers that a worthy goal, or the >> resources need to come from more voluntary people, e.g. FL needs a >> marketing manager. > > I think it is both Infrastructure and lack of humans, plus stupid > barriers > that shouldn't exist. Agreed... getting people to participate is one thing, but the effort to contribute is a bit high at the moment, considering that most folks are making this part of their spare time... It's also about organizational leadership, which to be honest, I do find lacking... there is no specific plan, no accountability/responsibility, no visible means to release into testing and production. To be honest, Legacy is pretty much borken as an organization at the people level. Folks want/need to know what to do, who does what, and how things work. This may be an implied thing at the moment, but speaking from somebody looking in from the outside, I have to ask why bother? 1) Packagers - this is important obviously 2) Testers - packagers should not be testers, but testers should be defined 3) Releaser Management - once QA is done, somebody needs to release the package to the production tree... The three roles are very different, and these need to be filled by different people, i.e. no overlap in responsibility... > The learning curve is high, people look down at volunteers just because > they don't/won't/can't use some technology (e.g. IRC), and there is > little > effort expended to get people to participate (though much flaming people > for not participating). The bar is pretty high to get in, and this is intimidating for those who lack experience with items outside of the course of their normal usage. Not to say that folks could not rise up to the challenge, it's just that the path is poorly documented, and the tools are, to be honest, a bit tough to use. Again, it comes down to who and how... > There is also an emphasis on getting people to only help with QA, which > is rather bad. If you can get people to start helping however they > feel they can, they will generally and eventually start helping in > other areas. But people generally need encouragement, and not flame > wars, insults, and barriers. Bingo... thing is that QA is the end of the line, and the one most needed and least respected by the folks that build packages. One thing that is very important, as the base of folks that would be potential QA candidates is to: 1) spell out what is needed - what is the problem and fix, how to test it? 2) how to use the systems - how to mark tested, reopen, open new bugs For the packagers... how to package for a release. I maintain my own boxen, so when a security issue pops up, I download source or make the fix locally. How to build a package and release it into testing remains somewhat of a mystery... I'd be happy to do so, if it were documented somehow. > >> Or the need for resources is cut by reducing the number and time span >> of supported releases. > > An option, but it only makes the limited resources go further, when what > we really need are more resources... More resources is not the answer - better management of the resources that are on board, and better tools to manage the process is what is needed. The process itself needs to be defined and clarified. Tim From tthome at cox.net Wed Nov 8 03:18:45 2006 From: tthome at cox.net (Tim Thome) Date: Tue, 07 Nov 2006 19:18:45 -0800 Subject: Some supporting ideas regarding fedora legacy project when FC6 is out today In-Reply-To: <20061024185209.60477.qmail@web36704.mail.mud.yahoo.com> References: <20061024185209.60477.qmail@web36704.mail.mud.yahoo.com> Message-ID: <45514C95.5070203@cox.net> Robinson Tiemuqinke wrote: > Hi, > > Glad that FC6 is out today for download/playing. > > But FC5 and FC6 are released too closely -- only > three months apart. while FC4 had released over one > year before FC5 appeared. Consequently, a lot of > people and small organizations, as far as I know, have > installed bunches of "free" FC4 boxes instead of FC5. > Thereafter, they will directly go to FC6 instead of > FC4->FC5->FC6, taking into the consideration of that > each upgrade from one release to another one is not a > tedious work. Personally... rather than the RedHat stair step approach to releases, i.e. FCx, FCy, FCz... I would rather see a gentle slope... The stair step approach, it was good when RH was selling RH Linux, but this is not the best approach for a freely available version of RH. We are not buying new packages every release of RH. Rawhide, as I see it, is always in motion, on the cutting edge of Linux, at least in the RH world. It's the development tip so to speak... I could be wrong on this. What Fedora should be is the stable edge of rawhide, with some QA... snapshots would be the core releases. In an ideal world, loading up *FCx*, and doing a yum update should take me all the way to the current_stable *FCz* release of fedora. In other words, clean *in-line* updates, no matter which ISO snapshot I download/install... then Legacy isn't really a problem. Note to RedHat and the Fedora Board - as Users, We are your Community to Develop... make the best use of the resource you have. Thx, Tim -------------- next part -------------- An HTML attachment was scrubbed... URL: From deisenst at gtw.net Wed Nov 8 10:43:24 2006 From: deisenst at gtw.net (David Eisenstein) Date: Wed, 08 Nov 2006 04:43:24 -0600 Subject: Need SeaMonkey opinions - [Fwd: [RHSA-2006:0734-01] Critical: seamonkey security update] Message-ID: <4551B4CC.1050203@gtw.net> Hello Fedora Legacy and Extras folks, This below RHEL advisory just came out, along with advisories like this for Thunderbird and for Firefox. We in Legacy need to get busy on these, because they are critical bugs, and we haven't updated any Firefox, Thunderbird, or SeaMonkey (er, Mozilla) packages in a LONG time. There are some old Bugzilla's that had been open for RHL 7.3, RHL 9, FC 1, FC 2, and FC 3 for Mozilla. There has been a running discussion (and no action -- largely my fault -- sorry!) about how and whether we upgrade Mozilla to SeaMonkey so that SeaMonkey becomes a Mozilla replacement (Core) package rather than an Extras package on a Bugzilla ticket for SeaMonkey. The Bugzilla number is 209167: . My understanding is that Michal Jaegermann (Fedora Legacy contributor) has done work on at least one or more previous versions of SeaMonkey, having created (FC4?) packages that should, once installed, act as a Mozilla replacement, not unlike what the RHEL packages mentioned in RHSA-2006-0734 do. The advantage of having SeaMonkey do this is that all other packages (such as yelp, epiphany, possibly others) will inherit the more secure code from SeaMonkey, since they tap into the shared-library (.so) files that SeaMonkey would be providing. My understanding then also would be that SeaMonkey is meant to be API compatible with Mozilla, so that other programs that depend on functions (or objects) in Mozilla's shared-library should continue to work okay, possibly without recompilation, but probably requiring recompilation and pushing to updates. Does anyone have any comments on how you wish the Legacy Project to approach this? I favor SeaMonkey as a Mozilla replacement, as it covers all vulnerabilities in packages that dynamically link to the shared libraries. But perhaps there are other ideas. Since Legacy Mozilla/Firefox/Thunderbird security bugs have been open since June (and not worked on), I also advocate that we in Legacy build SeaMonkey packages for *all* releases of Fedora Core that we have ever supported (since older releases were supported at that time) and RHL 7.3 and RHL 9. Does anyone object to that? What say ye?? Regards, David Eisenstein -------- Original Message -------- Subject: [RHSA-2006:0734-01] Critical: seamonkey security update Date: Wed, 8 Nov 2006 04:48:59 -0500 From: bugzilla at redhat.com To: enterprise-watch-list at redhat.com --------------------------------------------------------------------- Red Hat Security Advisory Synopsis: Critical: seamonkey security update Advisory ID: RHSA-2006:0734-01 Advisory URL: https://rhn.redhat.com/errata/RHSA-2006-0734.html Issue date: 2006-11-08 Updated on: 2006-11-08 Product: Red Hat Enterprise Linux CVE Names: CVE-2006-5462 CVE-2006-5463 CVE-2006-5464 CVE-2006-5747 CVE-2006-5748 --------------------------------------------------------------------- 1. Summary: Updated seamonkey packages that fix several security bugs are now available for Red Hat Enterprise Linux 2.1, 3, and 4. This update has been rated as having critical security impact by the Red Hat Security Response Team. 2. Relevant releases/architectures: ... (RHEL 2.1, RHEL 3, RHEL 4) ... 3. Problem description: SeaMonkey is an open source Web browser, advanced email and newsgroup client, IRC chat client, and HTML editor. Several flaws were found in the way SeaMonkey processes certain malformed Javascript code. A malicious web page could cause the execution of Javascript code in such a way that could cause SeaMonkey to crash or execute arbitrary code as the user running SeaMonkey. (CVE-2006-5463, CVE-2006-5747, CVE-2006-5748) Several flaws were found in the way SeaMonkey renders web pages. A malicious web page could cause the browser to crash or possibly execute arbitrary code as the user running SeaMonkey. (CVE-2006-5464) A flaw was found in the way SeaMonkey verifies RSA signatures. For RSA keys with exponent 3 it is possible for an attacker to forge a signature that would be incorrectly verified by the NSS library. SeaMonkey as shipped trusts several root Certificate Authorities that use exponent 3. An attacker could have created a carefully crafted SSL certificate which be incorrectly trusted when their site was visited by a victim. This flaw was previously thought to be fixed in SeaMonkey 1.0.5, however Ulrich Kuehn discovered the fix was incomplete (CVE-2006-5462) Users of SeaMonkey are advised to upgrade to these erratum packages, which contains SeaMonkey version 1.0.6 that corrects these issues. <> -- Enterprise-watch-list mailing list Enterprise-watch-list at redhat.com https://www.redhat.com/mailman/listinfo/enterprise-watch-list -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From deisenst at gtw.net Wed Nov 8 11:10:51 2006 From: deisenst at gtw.net (David Eisenstein) Date: Wed, 08 Nov 2006 05:10:51 -0600 Subject: You Need Fedora Legacy!! Re: [fab] looking at our surrent state a bit In-Reply-To: <20061107155632.hre50c2h9pss88s8@mail.ph.utexas.edu> References: <454B5DF0.90908@leemhuis.info> <009601c70186$1009c670$9962cfd0@homedns.org> <20061107103151.GE22994@neu.nirvana> <4550CD85.4020801@fedoraproject.org> <20061107214721.GA18180@neu.nirvana> <20061107155632.hre50c2h9pss88s8@mail.ph.utexas.edu> Message-ID: <4551BB3B.2010508@gtw.net> Eric Rostetter wrote: > Quoting Axel Thimm : > >> The issue is also not the infrstructure IMO, it's simply lack of human >> resources and either someone needs to assign them to it if that entity >> (Red Hat/board/whatever) considers that a worthy goal, or the >> resources need to come from more voluntary people, e.g. FL needs a >> marketing manager. > > > I think it is both Infrastructure and lack of humans, plus stupid barriers > that shouldn't exist. > > The learning curve is high, people look down at volunteers just because > they don't/won't/can't use some technology (e.g. IRC), and there is little > effort expended to get people to participate (though much flaming people > for not participating). I, for one, appreciate the hard work that you do, Eric. What do you suggest as an alternative for IRC for folks who are not able or interested in using it? Warm regards, David Eisenstein From martin at bugs.unl.edu.ar Wed Nov 8 11:45:40 2006 From: martin at bugs.unl.edu.ar (Martin Marques) Date: Wed, 8 Nov 2006 08:45:40 -0300 (ART) Subject: Mailman vulnerability In-Reply-To: <20061005161245.GB17040@mail.harddata.com> References: <20061005161245.GB17040@mail.harddata.com> Message-ID: On Thu, 5 Oct 2006, Michal Jaegermann wrote: > On Thu, Oct 05, 2006 at 09:19:48AM -0300, Martin Marques wrote: >> I have a FC4 web server installed and got this mailman report: >> >> http://www.securityfocus.com/bid/19831/discuss >> >> Is it to worry? > > Probably. See also http://rhn.redhat.com/errata/RHSA-2006-0600.html > > FC4 is using mailman-2.1.5-35 so fixes in sources used by > RHEL4, as specified by RHSA-2006-0600, will likely apply directly > or after minimal modifications. You can produce your own > update before something general eventually will show up. > Add patches, edit specs and rebuild rpm. Sorry for the delay. I'm working on this right now. But I found that patches for RHEL are for mailman 2.1.5 and we are on 2.1.8, making patches fail. So I'm trying to build new patches based on the RHEL ones. Would you people like to see the patches first or do I send the src.rpm? -- 21:50:04 up 2 days, 9:07, 0 users, load average: 0.92, 0.37, 0.18 --------------------------------------------------------- Lic. Mart?n Marqu?s | SELECT 'mmarques' || Centro de Telem?tica | '@' || 'unl.edu.ar'; Universidad Nacional | DBA, Programador, del Litoral | Administrador --------------------------------------------------------- From jkeating at redhat.com Wed Nov 8 12:19:02 2006 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 8 Nov 2006 07:19:02 -0500 Subject: Mailman vulnerability In-Reply-To: References: <20061005161245.GB17040@mail.harddata.com> Message-ID: <200611080719.11376.jkeating@redhat.com> On Wednesday 08 November 2006 06:45, Martin Marques wrote: > Would you people like to see the patches first or do I send the src.rpm? Either way. We now manage FC-4 in CVS so adding just a patch to generate a updates-testing rpm is easy enough. -- Jesse Keating Release Engineer: Fedora -------------- 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 redhat.com Wed Nov 8 12:21:12 2006 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 8 Nov 2006 07:21:12 -0500 Subject: Need SeaMonkey opinions - [Fwd: [RHSA-2006:0734-01] Critical: seamonkey security update] In-Reply-To: <4551B4CC.1050203@gtw.net> References: <4551B4CC.1050203@gtw.net> Message-ID: <200611080721.13164.jkeating@redhat.com> On Wednesday 08 November 2006 05:43, David Eisenstein wrote: > What say ye?? I'd say go with seamonkey. RHEL is showing us a good example. The "mozilla" codebase is dead and has been resurrected as seamonkey, so unless we want to generate our own patches (shudder) I'd highly recommend we take the RHEL route and replace mozilla with seamonkey. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mattdm at mattdm.org Wed Nov 8 12:48:52 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 8 Nov 2006 07:48:52 -0500 Subject: Need SeaMonkey opinions - [Fwd: [RHSA-2006:0734-01] Critical: seamonkey security update] In-Reply-To: <4551B4CC.1050203@gtw.net> References: <4551B4CC.1050203@gtw.net> Message-ID: <20061108124852.GA27314@jadzia.bu.edu> On Wed, Nov 08, 2006 at 04:43:24AM -0600, David Eisenstein wrote: > Does anyone have any comments on how you wish the Legacy Project to approach > this? I favor SeaMonkey as a Mozilla replacement, as it covers all > vulnerabilities in packages that dynamically link to the shared libraries. > But perhaps there are other ideas. I think this is the only reasonable choice. Backporting all of the fixes would be herculean -- for very little gain. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From martin at bugs.unl.edu.ar Wed Nov 8 13:22:06 2006 From: martin at bugs.unl.edu.ar (Martin Marques) Date: Wed, 8 Nov 2006 10:22:06 -0300 (ART) Subject: Mailman vulnerability In-Reply-To: <200611080719.11376.jkeating@redhat.com> References: <20061005161245.GB17040@mail.harddata.com> <200611080719.11376.jkeating@redhat.com> Message-ID: On Wed, 8 Nov 2006, Jesse Keating wrote: > On Wednesday 08 November 2006 06:45, Martin Marques wrote: >> Would you people like to see the patches first or do I send the src.rpm? > > Either way. We now manage FC-4 in CVS so adding just a patch to generate a > updates-testing rpm is easy enough. Excelent, because this one is giving me a hard time (attached file). I get this error when trying to build the rpm: Patch #9 (mailman-2.1-CVE-2006-3636.patch): + patch -p1 -b --suffix .CVE-2006-3636 -s 9 out of 9 hunks FAILED -- saving rejects to file Mailman/Cgi/edithtml.py.rej error: Bad exit status from /var/tmp/rpm-tmp.59741 (%prep) -- 21:50:04 up 2 days, 9:07, 0 users, load average: 0.92, 0.37, 0.18 --------------------------------------------------------- Lic. Mart?n Marqu?s | SELECT 'mmarques' || Centro de Telem?tica | '@' || 'unl.edu.ar'; Universidad Nacional | DBA, Programador, del Litoral | Administrador --------------------------------------------------------- -------------- next part -------------- --- mailman-2.1.8.orig/Mailman/Cgi/admindb.py 2005-12-30 15:50:07.000000000 -0300 +++ Mailman/Cgi/admindb.py 2006-11-08 08:42:11.000000000 -0300 @@ -313,7 +313,7 @@ ' ' + _('Permanently ban from this list') # While the address may be a unicode, it must be ascii paddr = addr.encode('us-ascii', 'replace') - table.AddRow(['%s
%s' % (paddr, fullname), + table.AddRow(['%s
%s' % (paddr, Utils.websafe(fullname)), radio, TextBox('comment-%d' % id, size=40) ]) @@ -357,8 +357,8 @@ mlist.HandleRequest(id, mm_cfg.DISCARD) continue num += 1 - table.AddRow(['%s
%s' % (addr, fullname), + table.AddRow(['%s
%s' % (addr, Utils.websafe(fullname)), RadioButtonArray(id, (_('Defer'), _('Approve'), _('Reject'), --- mailman-2.1.8.orig/Mailman/Cgi/create.py 2005-12-30 15:50:07.000000000 -0300 +++ Mailman/Cgi/create.py 2006-11-08 08:56:01.000000000 -0300 @@ -190,15 +190,24 @@ mlist.Create(listname, owner, pw, langs, emailhost) finally: os.umask(oldmask) - except Errors.EmailAddressError, s: + except Errors.EmailAddressError, e: + if e.args: + s = Utils.websafe(e.args[0]) + else: + s = Utils.websafe(owner) request_creation(doc, cgidata, _('Bad owner email address: %(s)s')) return except Errors.MMListAlreadyExistsError: + # MAS: List already exists so we don't need to websafe it. request_creation(doc, cgidata, _('List already exists: %(listname)s')) return - except Errors.BadListNameError, s: + except Errors.BadListNameError, e: + if e.args: + s = Utils.websafe(e.args[0]) + else: + s = Utils.websafe(listname) request_creation(doc, cgidata, _('Illegal list name: %(s)s')) return @@ -321,15 +330,17 @@ ftable.AddRow([Center(Italic(_('List Identity')))]) ftable.AddCellInfo(ftable.GetCurrentRowIndex(), 0, colspan=2) - safelistname = Utils.websafe(cgidata.getvalue('listname', '')) + listname = cgidata.getvalue('listname', '') + # MAS: Don't websafe twice. TextBox does it. ftable.AddRow([Label(_('Name of list:')), - TextBox('listname', safelistname)]) + TextBox('listname', listname)]) ftable.AddCellInfo(ftable.GetCurrentRowIndex(), 0, bgcolor=GREY) ftable.AddCellInfo(ftable.GetCurrentRowIndex(), 1, bgcolor=GREY) - safeowner = Utils.websafe(cgidata.getvalue('owner', '')) + owner = cgidata.getvalue('owner', '') + # MAS: Don't websafe twice. TextBox does it. ftable.AddRow([Label(_('Initial list owner address:')), - TextBox('owner', safeowner)]) + TextBox('owner', owner)]) ftable.AddCellInfo(ftable.GetCurrentRowIndex(), 0, bgcolor=GREY) ftable.AddCellInfo(ftable.GetCurrentRowIndex(), 1, bgcolor=GREY) --- mailman-2.1.8.orig/Mailman/Cgi/options.py 2005-12-02 22:07:13.000000000 -0300 +++ Mailman/Cgi/options.py 2006-11-08 08:58:00.000000000 -0300 @@ -702,8 +702,8 @@ fullname = Utils.uncanonstr(mlist.getMemberName(user), userlang) if fullname: - presentable_user += ', %s' % fullname + presentable_user += ', %s' % Utils.websafe(fullname) # Do replacements replacements = mlist.GetStandardReplacements(userlang) --- mailman-2.1.8.orig/Mailman/Cgi/edithtml.py 2006-01-09 04:06:52.000000000 -0300 +++ Mailman/Cgi/edithtml.py 2006-11-08 08:59:50.000000000 -0300 @@ -143,8 +143,9 @@ doc.AddItem('

') doc.AddItem('

') form = Form(mlist.GetScriptURL('edithtml') + '/' + template_name) - text = Utils.websafe(Utils.maketext(template_name, raw=1, mlist=mlist)) + text = Utils.maketext(template_name, raw=1, mlist=mlist) + # MAS: Don't websafe twice. TextArea does it. form.AddItem(TextArea('html_code', text, rows=40, cols=75)) form.AddItem('

' + _('When you are done making changes...')) form.AddItem(SubmitButton('submit', _('Submit Changes'))) --- mailman-2.1.8.orig/Mailman/Cgi/admin.py 2005-12-30 15:50:07.000000000 -0300 +++ Mailman/Cgi/admin.py 2006-11-08 09:04:05.000000000 -0300 @@ -1318,6 +1318,7 @@ # we display. Try uploading a file with 10k names -- it takes a while # to render the status page. for entry in entries: + safeentry = Utils.websafe(entry) fullname, address = parseaddr(entry) # Canonicalize the full name fullname = Utils.canonstr(fullname, mlist.preferred_language) @@ -1335,20 +1336,20 @@ send_admin_notif, invitation, whence='admin mass sub') except Errors.MMAlreadyAMember: - subscribe_errors.append((entry, _('Already a member'))) + subscribe_errors.append((safeentry, _('Already a member'))) except Errors.MMBadEmailError: if userdesc.address == '': subscribe_errors.append((_('<blank line>'), _('Bad/Invalid email address'))) else: - subscribe_errors.append((entry, + subscribe_errors.append((safeentry, _('Bad/Invalid email address'))) except Errors.MMHostileAddress: subscribe_errors.append( - (entry, _('Hostile address (illegal characters)'))) + (safeentry, _('Hostile address (illegal characters)'))) except Errors.MembershipIsBanned, pattern: subscribe_errors.append( - (entry, _('Banned address (matched %(pattern)s)'))) + (safeentry, _('Banned address (matched %(pattern)s)'))) else: member = Utils.uncanonstr(formataddr((fullname, address))) subscribe_success.append(Utils.websafe(member)) @@ -1388,10 +1389,10 @@ addr, whence='admin mass unsub', admin_notif=send_unsub_notifications, userack=userack) - unsubscribe_success.append(addr) + unsubscribe_success.append(Utils.websafe(addr)) except Errors.NotAMemberError: - unsubscribe_errors.append(addr) + unsubscribe_errors.append(Utils.websafe(addr)) if unsubscribe_success: doc.AddItem(Header(5, _('Successfully Unsubscribed:'))) doc.AddItem(UnorderedList(*unsubscribe_success)) --- mailman-2.1.8.orig/Mailman/Utils.py 2006-03-18 14:23:04.000000000 -0300 +++ Mailman/Utils.py 2006-11-08 09:05:10.000000000 -0300 @@ -204,8 +204,8 @@ _badchars = re.compile(r'[][()<>|;^,\000-\037\177-\377]') def ValidateEmail(s): - """Verify that the an email address isn't grossly evil.""" + """Verify that an email address isn't grossly evil.""" # Pretty minimal, cheesy check. We could do better... if not s or s.count(' ') > 0: raise Errors.MMBadEmailError --- mailman-2.1.8.orig/Mailman/htmlformat.py 2005-08-26 22:40:15.000000000 -0300 +++ Mailman/htmlformat.py 2006-11-08 09:08:00.000000000 -0300 @@ -448,7 +448,11 @@ class TextBox(InputObj): def __init__(self, name, value='', size=mm_cfg.TEXTFIELDWIDTH): - InputObj.__init__(self, name, "TEXT", value, checked=0, size=size) + if isinstance(value, str): + safevalue = Utils.websafe(value) + else: + safevalue = value + InputObj.__init__(self, name, "TEXT", safevalue, checked=0, size=size) class Hidden(InputObj): def __init__(self, name, value=''): @@ -457,9 +461,13 @@ class TextArea: def __init__(self, name, text='', rows=None, cols=None, wrap='soft', readonly=0): + if isinstance(text, str): + safetext = Utils.websafe(text) + else: + safetext = text self.name = name - self.text = text + self.text = safetext self.rows = rows self.cols = cols self.wrap = wrap --- mailman-2.1.8.orig/Mailman/Gui/General.py 2006-03-23 07:51:25.000000000 -0300 +++ Mailman/Gui/General.py 2006-11-08 09:09:37.000000000 -0300 @@ -439,14 +439,14 @@ GUIBase._setValue(self, mlist, property, val, doc) def _escape(self, property, value): - # The 'info' property allows HTML, but lets sanitize it to avoid XSS + # The 'info' property allows HTML, but let's sanitize it to avoid XSS # exploits. Everything else should be fully escaped. if property <> 'info': return GUIBase._escape(self, property, value) # Sanitize tags but nothing else. Not the best # solution, but expedient. - return re.sub(r'<([/]?script.*?)>', r'<\1>', value) + return re.sub(r'(?i)<([/]?script.*?)>', r'<\1>', value) def _postValidate(self, mlist, doc): if not mlist.reply_to_address.strip() and \ --- mailman-2.1.8.orig/Mailman/HTMLFormatter.py 2005-08-26 22:40:15.000000000 -0300 +++ Mailman/HTMLFormatter.py 2006-11-08 09:10:56.000000000 -0300 @@ -332,9 +332,13 @@ return '' def FormatBox(self, name, size=20, value=''): + if isinstance(value, str): + safevalue = Utils.websafe(value) + else: + safevalue = value return '' % ( - name, size, value) + name, size, safevalue) def FormatSecureBox(self, name): return '' % name From gene.heskett at verizon.net Wed Nov 8 14:00:36 2006 From: gene.heskett at verizon.net (Gene Heskett) Date: Wed, 08 Nov 2006 09:00:36 -0500 Subject: Need SeaMonkey opinions - [Fwd: [RHSA-2006:0734-01] Critical: seamonkey security update] In-Reply-To: <4551B4CC.1050203@gtw.net> References: <4551B4CC.1050203@gtw.net> Message-ID: <200611080900.36148.gene.heskett@verizon.net> On Wednesday 08 November 2006 05:43, David Eisenstein wrote: >Hello Fedora Legacy and Extras folks, > >This below RHEL advisory just came out, along with advisories like this > for Thunderbird and for Firefox. We in Legacy need to get busy on > these, because they are critical bugs, and we haven't updated any > Firefox, Thunderbird, or SeaMonkey (er, Mozilla) packages in a LONG > time. > >There are some old Bugzilla's that had been open for RHL 7.3, RHL 9, FC > 1, FC 2, and FC 3 for Mozilla. There has been a running discussion (and > no action -- largely my fault -- sorry!) about how and whether we > upgrade Mozilla to SeaMonkey so that SeaMonkey becomes a Mozilla > replacement (Core) package rather than an Extras package on a Bugzilla > ticket for SeaMonkey. The Bugzilla number is 209167: >. > >My understanding is that Michal Jaegermann (Fedora Legacy contributor) > has done work on at least one or more previous versions of SeaMonkey, > having created (FC4?) packages that should, once installed, act as a > Mozilla replacement, not unlike what the RHEL packages mentioned in > RHSA-2006-0734 do. > >The advantage of having SeaMonkey do this is that all other packages > (such as yelp, epiphany, possibly others) will inherit the more secure > code from SeaMonkey, since they tap into the shared-library (.so) files > that SeaMonkey would be providing. My understanding then also would be > that SeaMonkey is meant to be API compatible with Mozilla, so that other > programs that depend on functions (or objects) in Mozilla's > shared-library should continue to work okay, possibly without > recompilation, but probably requiring recompilation and pushing to > updates. > >Does anyone have any comments on how you wish the Legacy Project to > approach this? I favor SeaMonkey as a Mozilla replacement, as it covers > all vulnerabilities in packages that dynamically link to the shared > libraries. But perhaps there are other ideas. > >Since Legacy Mozilla/Firefox/Thunderbird security bugs have been open > since June (and not worked on), I also advocate that we in Legacy build > SeaMonkey packages for *all* releases of Fedora Core that we have ever > supported (since older releases were supported at that time) and RHL 7.3 > and RHL 9. Does anyone object to that? > >What say ye?? > As an interested sidewalk superintendant, I'd say go with seamonkey since a lot of that stuff comes for free with it. > Regards, > David Eisenstein > > > >-------- Original Message -------- >Subject: [RHSA-2006:0734-01] Critical: seamonkey security update >Date: Wed, 8 Nov 2006 04:48:59 -0500 >From: bugzilla at redhat.com >To: enterprise-watch-list at redhat.com > >--------------------------------------------------------------------- > Red Hat Security Advisory > >Synopsis: Critical: seamonkey security update >Advisory ID: RHSA-2006:0734-01 >Advisory URL: https://rhn.redhat.com/errata/RHSA-2006-0734.html >Issue date: 2006-11-08 >Updated on: 2006-11-08 >Product: Red Hat Enterprise Linux >CVE Names: CVE-2006-5462 CVE-2006-5463 CVE-2006-5464 > CVE-2006-5747 CVE-2006-5748 >--------------------------------------------------------------------- > >1. Summary: > >Updated seamonkey packages that fix several security bugs are now > available for Red Hat Enterprise Linux 2.1, 3, and 4. > >This update has been rated as having critical security impact by the Red >Hat Security Response Team. > >2. Relevant releases/architectures: > >... (RHEL 2.1, RHEL 3, RHEL 4) ... > >3. Problem description: > >SeaMonkey is an open source Web browser, advanced email and newsgroup >client, IRC chat client, and HTML editor. > >Several flaws were found in the way SeaMonkey processes certain malformed >Javascript code. A malicious web page could cause the execution of >Javascript code in such a way that could cause SeaMonkey to crash or >execute arbitrary code as the user running SeaMonkey. (CVE-2006-5463, >CVE-2006-5747, CVE-2006-5748) > >Several flaws were found in the way SeaMonkey renders web pages. A >malicious web page could cause the browser to crash or possibly execute >arbitrary code as the user running SeaMonkey. (CVE-2006-5464) > >A flaw was found in the way SeaMonkey verifies RSA signatures. For RSA > keys with exponent 3 it is possible for an attacker to forge a signature > that would be incorrectly verified by the NSS library. SeaMonkey as > shipped trusts several root Certificate Authorities that use exponent 3. > An attacker could have created a carefully crafted SSL certificate which > be incorrectly trusted when their site was visited by a victim. This > flaw was previously thought to be fixed in SeaMonkey 1.0.5, however > Ulrich Kuehn discovered the fix was incomplete (CVE-2006-5462) > >Users of SeaMonkey are advised to upgrade to these erratum packages, > which contains SeaMonkey version 1.0.6 that corrects these issues. > ><> -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2006 by Maurice Eugene Heskett, all rights reserved. From rostetter at mail.utexas.edu Wed Nov 8 17:12:17 2006 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Wed, 8 Nov 2006 11:12:17 -0600 Subject: Need SeaMonkey opinions - [Fwd: [RHSA-2006:0734-01] Critical: seamonkey security update] In-Reply-To: <4551B4CC.1050203@gtw.net> References: <4551B4CC.1050203@gtw.net> Message-ID: <20061108111217.81bwkneek6oo8o8s@mail.ph.utexas.edu> Quoting David Eisenstein : > There are some old Bugzilla's that had been open for RHL 7.3, RHL 9, FC 1, > FC 2, and FC 3 for Mozilla. There has been a running discussion (and no > action -- largely my fault -- sorry!) about how and whether we upgrade > Mozilla to SeaMonkey so that SeaMonkey becomes a Mozilla replacement (Core) > package rather than an Extras package on a Bugzilla ticket for SeaMonkey. > The Bugzilla number is 209167: > . I personally think this would be a good thing. I'd vote for upgrading from mozilla to seamonkey, as long as we can get people to do the work... > The advantage of having SeaMonkey do this is that all other packages (such > as yelp, epiphany, possibly others) will inherit the more secure code from > SeaMonkey, since they tap into the shared-library (.so) files that SeaMonkey > would be providing. My understanding then also would be that SeaMonkey is > meant to be API compatible with Mozilla, so that other programs that depend > on functions (or objects) in Mozilla's shared-library should continue to > work okay, possibly without recompilation, but probably requiring > recompilation and pushing to updates. We'd need some real good testing for this upgrade of course. But I'm definately in favor of trying. > Does anyone have any comments on how you wish the Legacy Project to approach > this? I favor SeaMonkey as a Mozilla replacement, as it covers all > vulnerabilities in packages that dynamically link to the shared libraries. > But perhaps there are other ideas. I think that going to seamonkey is the logical thing to do for RHL and early FC releases. Not sure how later FC releases should be handled, since I don't use them. Note this is in-line with mozilla.org and redhat.com, and basically is the "industry standard" upgrade path. So I think we are fully justified in doing so. > Since Legacy Mozilla/Firefox/Thunderbird security bugs have been open since > June (and not worked on), I also advocate that we in Legacy build SeaMonkey > packages for *all* releases of Fedora Core that we have ever supported > (since older releases were supported at that time) and RHL 7.3 and RHL 9. > Does anyone object to that? Sounds great. I can test them on RHL 7.3, RHl 9 and FC 3 64-bit. I'm willing to do any installation/functionality testing required on those versions. Those are the only versions I have access to for testing. > What say ye?? Sounds good to me. > Regards, > David Eisenstein -- Eric Rostetter The Department of Physics The University of Texas at Austin Go Longhorns! From rostetter at mail.utexas.edu Wed Nov 8 17:23:01 2006 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Wed, 8 Nov 2006 11:23:01 -0600 Subject: You Need Fedora Legacy!! Re: [fab] looking at our surrent state a bit In-Reply-To: <4551BB3B.2010508@gtw.net> References: <454B5DF0.90908@leemhuis.info> <009601c70186$1009c670$9962cfd0@homedns.org> <20061107103151.GE22994@neu.nirvana> <4550CD85.4020801@fedoraproject.org> <20061107214721.GA18180@neu.nirvana> <20061107155632.hre50c2h9pss88s8@mail.ph.utexas.edu> <4551BB3B.2010508@gtw.net> Message-ID: <20061108112301.m9xgb7urxmo08g84@mail.ph.utexas.edu> Quoting David Eisenstein : > What do you suggest as an alternative for IRC for folks who are not able or > interested in using it? I work in several opensource projects that have IRC channels, and I've never used IRC for any of them, and no one has ever complained about that fact except for here on FL. Instead, I use e-mail (the project mailing lists in all cases, except for here on FL where I sometimes use private e-mail also). Not a real big fan of the private e-mail, but it works here for some FL stuff. I've never had any lack of ability to do anything I wanted using e-mail instead of IRC on any of the projects I've worked on. I'm not knocking IRC. It has some limitations though, such as timezone issues, etc. Plus, some of us work on FL stuff at work, and IRC may be blocked at our work place or disruptive to our work. This can be a real issue for some of us. Hence, I never use IRC/IM at work, and hence since 99% of my opensource work is done at the office and not at home, that means I really can't use IRC/IM for these projects. Now, I think IRC is very useful for some things. For example, if you have a "board" or "core" group that has regular meetings, IRC is a great way to have those meetings. But for the typical FL user who isn't a core/board member, it is overkill. And I just don't see why I should be forced to install (IRC) software on my machine, learn how to use it, wonder if the University Network Folks will come knocking on my door because of it, and let it disrupt my work, just so I can ask a question that I can ask via e-mail. Now, e-mail lists have advantages also. A nice, searchable archive of the messages for reference by others, reference for myself later, and as a source for creating the documenation on the issues addressed there. Plus of course the asynchronous nature which allows people in all different time zones to participate, etc. So I'm not for getting rid of IRC, just for making it an additional option and not a required option. > Warm regards, > David Eisenstein -- Eric Rostetter The Department of Physics The University of Texas at Austin Go Longhorns! From caillon at redhat.com Wed Nov 8 19:34:30 2006 From: caillon at redhat.com (Christopher Aillon) Date: Wed, 08 Nov 2006 14:34:30 -0500 Subject: Need SeaMonkey opinions - [Fwd: [RHSA-2006:0734-01] Critical: seamonkey security update] In-Reply-To: <4551B4CC.1050203@gtw.net> References: <4551B4CC.1050203@gtw.net> Message-ID: <45523146.8070105@redhat.com> David Eisenstein wrote: > Does anyone have any comments on how you wish the Legacy Project to approach > this? I favor SeaMonkey as a Mozilla replacement, as it covers all > vulnerabilities in packages that dynamically link to the shared libraries. > But perhaps there are other ideas. I see no reason that it won't work for Fedora given that it works for RHEL. I can probably offer some guidance as there were many hurdles that I had to overcome when building these packages for RHEL, though I probably don't remember them all off the top of my head. From michal at harddata.com Wed Nov 8 20:22:45 2006 From: michal at harddata.com (Michal Jaegermann) Date: Wed, 8 Nov 2006 13:22:45 -0700 Subject: Need SeaMonkey opinions - [Fwd: [RHSA-2006:0734-01] Critical: seamonkey security update] In-Reply-To: <45523146.8070105@redhat.com> References: <4551B4CC.1050203@gtw.net> <45523146.8070105@redhat.com> Message-ID: <20061108202245.GA8233@mail.harddata.com> On Wed, Nov 08, 2006 at 02:34:30PM -0500, Christopher Aillon wrote: > David Eisenstein wrote: > >I favor SeaMonkey as a Mozilla replacement, as it covers all > >vulnerabilities in packages that dynamically link to the shared libraries. > >But perhaps there are other ideas. > > I see no reason that it won't work for Fedora given that it works for > RHEL. I can probably offer some guidance as there were many hurdles > that I had to overcome when building these packages for RHEL, though I > probably don't remember them all off the top of my head. Thanks Chris! A while ago I basically "stole" your package from RHEL sources and redid it for FC4. It really should be basically the same thing for earlier distributions. An URL for source rpm was posted on this list and a number of people is aware of it. :-) Right now it needs an update, of course, but this should be straightforward. As a matter of fact I got impatient waiting for a resolution of https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=195318 and did a similar thing for FC5 too. That one has bigger differences because it is using "external" packages for nss and nspr (and some other minor things). Michal From rostetter at mail.utexas.edu Wed Nov 8 20:51:25 2006 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Wed, 8 Nov 2006 14:51:25 -0600 Subject: You Need Fedora Legacy!! Re: [fab] looking at our surrent state a bit In-Reply-To: <455147A2.9050901@cox.net> References: <454B5DF0.90908@leemhuis.info> <009601c70186$1009c670$9962cfd0@homedns.org> <20061107103151.GE22994@neu.nirvana> <4550CD85.4020801@fedoraproject.org> <20061107214721.GA18180@neu.nirvana> <20061107155632.hre50c2h9pss88s8@mail.ph.utexas.edu> <455147A2.9050901@cox.net> Message-ID: <20061108145125.oew02bluu8m8ggkg@mail.ph.utexas.edu> Quoting Tim Thome : > For the packagers... how to package for a release. I maintain my own > boxen, so when a security issue pops up, I download source or make the > fix locally. How to build a package and release it into testing remains > somewhat of a mystery... I'd be happy to do so, if it were documented > somehow. Yeah, it is a bit of a mystery. Right now, AFAIK, for those "outside" the system, all you can do is post a link to your SRPM for those inside the system to grab and utilize... Posting such a link to the mailing list or to the relevent bugzilla entry would be the way to do that. Preferably to the bugzilla of course, but if that is too great a challange the mailing list is a backup method that is less challanging. -- Eric Rostetter The Department of Physics The University of Texas at Austin Go Longhorns! From sheltren at cs.ucsb.edu Fri Nov 10 14:05:27 2006 From: sheltren at cs.ucsb.edu (Jeff Sheltren) Date: Fri, 10 Nov 2006 10:05:27 -0400 Subject: Updates for PHP, Python, and Qt Message-ID: Hi, I've created some updated package for PHP, Python and qt that need some tender loving QA if someone is willing. PHP: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=214391 Python: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=214395 Qt: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=214393 Thanks, Jeff From kanarip at kanarip.com Sat Nov 11 23:39:45 2006 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Sun, 12 Nov 2006 00:39:45 +0100 Subject: Self Introduction: Jeroen 'kanarip' van Meeuwen Message-ID: <45565F41.2080604@kanarip.com> Hi to everyone on the list! So, here's my self introduction. My name is Jeroen van Meeuwen, age 23, and I live in a little city near Utrecht, in The Netherlands. During the day I am a System Engineer and I'm currently employed as Windows Engineer for a corporate organization in logistics. I also work as an Instructor in Linux at my consultancy agency and I'm planning to enroll the rapid RHCE course track around March 2007. I'm currently contributing to the Fedora Unity project, mainly because I think it progresses in areas that are not addressed by any other Fedora Project, such as the Installation Media Re-Spins, the Live-Spins, documentation on common issues such as the installation of NTFS read/write, nVidia drivers, and much more things that the community wants. I find it a very good example of how (part of) the community gets things done that the community wants. A friend of mine brought my attention to Fedora Legacy. Of course I had heard of it, I've read the articles about how some people suspect it to fail, but he made me realize that without Fedora Legacy, as the life-cycle of a 'supported' Fedora Core version is 'only' one year, is way too important to be as inactive as it currently is... I hope that with my future contributions, and the contributions from others, we can lift this project (close) to it's full potential and make people realize that the actual lifecycle of a Fedora Core release is at least two years. I think this often is one of the aspects that makes people decide to use a distribution other then Fedora, and I dislike that. So, I'm gonna try and do something about it. Some of you (specifically if you are on IRC), know me as kanarip. Feel free to contact me about anything! Kind regards, Jeroen van Meeuwen -kanarip gpg --fingerprint kanarip at kanarip.com pub 1024D/9342BF08 2006-05-29 Key fingerprint = C6B0 7FB4 43E6 CDDA D258 F70B 28DE 9FDA 9342 BF08 uid Jeroen van Meeuwen (kanarip) sub 2048g/769FAEDE 2006-05-29 From mattdm at mattdm.org Sun Nov 12 17:00:23 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Sun, 12 Nov 2006 12:00:23 -0500 Subject: Self Introduction: Jeroen 'kanarip' van Meeuwen In-Reply-To: <45565F41.2080604@kanarip.com> References: <45565F41.2080604@kanarip.com> Message-ID: <20061112170023.GA17878@jadzia.bu.edu> On Sun, Nov 12, 2006 at 12:39:45AM +0100, Jeroen van Meeuwen wrote: > So, here's my self introduction. My name is Jeroen van Meeuwen, age > 23, and I live in a little city near Utrecht, in The Netherlands. Hi Jeroen. We'll definitely appreciate the help. I suppose the most useful thing to do right now is to look in bugzilla or at Pekka's buglist at and start poking at things. Hopefully, we'll have some better infrastructure in place soon. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From billperrotta at yahoo.com Wed Nov 8 21:36:48 2006 From: billperrotta at yahoo.com (Bill Perrotta) Date: Wed, 8 Nov 2006 13:36:48 -0800 (PST) Subject: I get this error when trying to upgrade my 2.4.20-8 to 2.6.3 after make install Message-ID: <20061108213648.68528.qmail@web90501.mail.mud.yahoo.com> Someone please help. I need to recompile redhat nine to add disk quotas for my rhce. I get this error when trying to upgrade my 2.4.20-8 to 2.6.3 after make install see below CC kernel/power/disk.o CC kernel/power/pmdisk.o CC kernel/power/poweroff.o LD kernel/power/built-in.o CC kernel/acct.o LD kernel/built-in.o CC mm/bootmem.o CC mm/filemap.o CC mm/mempool.o CC mm/oom_kill.o CC mm/fadvise.o CC mm/page_alloc.o CC mm/page-writeback.o CC mm/pdflush.o CC mm/readahead.o CC mm/slab.o CC mm/swap.o CC mm/truncate.o CC mm/vmscan.o CC mm/fremap.o CC mm/highmem.o CC mm/madvise.o CC mm/memory.o CC mm/mincore.o CC mm/mlock.o CC mm/mmap.o CC mm/mprotect.o CC mm/mremap.o CC mm/msync.o CC mm/rmap.o CC mm/shmem.o CC mm/vmalloc.o CC mm/page_io.o CC mm/swap_state.o CC mm/swapfile.o LD mm/built-in.o CC fs/open.o CC fs/read_write.o CC fs/file_table.o CC fs/buffer.o CC fs/bio.o CC fs/super.o CC fs/block_dev.o CC fs/char_dev.o CC fs/stat.o CC fs/exec.o CC fs/pipe.o CC fs/namei.o CC fs/fcntl.o CC fs/ioctl.o CC fs/readdir.o CC fs/select.o CC fs/fifo.o CC fs/locks.o CC fs/dcache.o CC fs/inode.o CC fs/attr.o CC fs/bad_inode.o CC fs/file.o CC fs/dnotify.o CC fs/filesystems.o CC fs/namespace.o CC fs/seq_file.o CC fs/xattr.o CC fs/libfs.o CC fs/fs-writeback.o CC fs/mpage.o CC fs/direct-io.o CC fs/aio.o CC fs/eventpoll.o CC fs/nfsctl.o CC fs/binfmt_script.o CC fs/binfmt_elf.o CC fs/mbcache.o CC fs/posix_acl.o CC fs/xattr_acl.o CC fs/dquot.o CC fs/quota_v2.o CC fs/quota.o LD fs/afs/built-in.o LD fs/autofs/built-in.o LD fs/autofs4/built-in.o LD fs/befs/built-in.o LD fs/bfs/built-in.o LD fs/coda/built-in.o LD fs/cramfs/built-in.o CC fs/devpts/inode.o CC fs/devpts/xattr.o CC fs/devpts/xattr_security.o LD fs/devpts/devpts.o LD fs/devpts/built-in.o LD fs/exportfs/built-in.o CC fs/ext2/balloc.o CC fs/ext2/bitmap.o CC fs/ext2/dir.o CC fs/ext2/file.o CC fs/ext2/fsync.o CC fs/ext2/ialloc.o CC fs/ext2/inode.o CC fs/ext2/ioctl.o CC fs/ext2/namei.o CC fs/ext2/super.o CC fs/ext2/symlink.o CC fs/ext2/xattr.o CC fs/ext2/xattr_user.o CC fs/ext2/xattr_trusted.o CC fs/ext2/acl.o CC fs/ext2/xattr_security.o LD fs/ext2/ext2.o LD fs/ext2/built-in.o LD fs/ext3/built-in.o LD fs/fat/built-in.o LD fs/freevxfs/built-in.o LD fs/hfs/built-in.o CC fs/hugetlbfs/inode.o LD fs/hugetlbfs/hugetlbfs.o LD fs/hugetlbfs/built-in.o LD fs/intermezzo/built-in.o CC fs/isofs/namei.o CC fs/isofs/inode.o CC fs/isofs/dir.o CC fs/isofs/util.o CC fs/isofs/rock.o CC fs/isofs/joliet.o CC fs/isofs/compress.o LD fs/isofs/isofs.o LD fs/isofs/built-in.o LD fs/jbd/built-in.o LD fs/jfs/built-in.o LD fs/lockd/built-in.o LD fs/minix/built-in.o LD fs/msdos/built-in.o LD fs/ncpfs/built-in.o LD fs/nfs/built-in.o LD fs/nfsd/built-in.o CC fs/nls/nls_base.o LD fs/nls/built-in.o CC fs/partitions/check.o CC fs/partitions/mac.o CC fs/partitions/msdos.o CC fs/partitions/osf.o CC fs/partitions/sgi.o CC fs/partitions/sun.o CC fs/partitions/nec98.o LD fs/partitions/built-in.o CC fs/proc/task_mmu.o CC fs/proc/inode.o CC fs/proc/root.o CC fs/proc/base.o CC fs/proc/generic.o CC fs/proc/array.o CC fs/proc/kmsg.o CC fs/proc/proc_tty.o CC fs/proc/proc_misc.o CC fs/proc/kcore.o LD fs/proc/proc.o LD fs/proc/built-in.o CC fs/ramfs/inode.o LD fs/ramfs/ramfs.o LD fs/ramfs/built-in.o LD fs/reiserfs/built-in.o LD fs/romfs/built-in.o LD fs/smbfs/built-in.o CC fs/sysfs/inode.o CC fs/sysfs/file.o CC fs/sysfs/dir.o CC fs/sysfs/symlink.o CC fs/sysfs/mount.o CC fs/sysfs/bin.o CC fs/sysfs/group.o LD fs/sysfs/built-in.o LD fs/sysv/built-in.o LD fs/udf/built-in.o LD fs/ufs/built-in.o LD fs/vfat/built-in.o CC fs/xfs/xfs_dmops.o CC fs/xfs/quota/xfs_dquot.o CC fs/xfs/quota/xfs_dquot_item.o CC fs/xfs/quota/xfs_trans_dquot.o CC fs/xfs/quota/xfs_qm_syscalls.o CC fs/xfs/quota/xfs_qm_bhv.o CC fs/xfs/quota/xfs_qm.o CC fs/xfs/quota/xfs_qm_stats.o CC fs/xfs/xfs_rtalloc.o CC fs/xfs/xfs_acl.o CC fs/xfs/linux/xfs_stats.o CC fs/xfs/linux/xfs_sysctl.o CC fs/xfs/xfs_alloc.o CC fs/xfs/xfs_alloc_btree.o CC fs/xfs/xfs_attr.o CC fs/xfs/xfs_attr_leaf.o CC fs/xfs/xfs_behavior.o CC fs/xfs/xfs_bit.o CC fs/xfs/xfs_bmap.o CC fs/xfs/xfs_bmap_btree.o CC fs/xfs/xfs_btree.o CC fs/xfs/xfs_buf_item.o CC fs/xfs/xfs_da_btree.o CC fs/xfs/xfs_dir.o CC fs/xfs/xfs_dir2.o CC fs/xfs/xfs_dir2_block.o CC fs/xfs/xfs_dir2_data.o CC fs/xfs/xfs_dir2_leaf.o CC fs/xfs/xfs_dir2_node.o CC fs/xfs/xfs_dir2_sf.o CC fs/xfs/xfs_dir_leaf.o CC fs/xfs/xfs_error.o CC fs/xfs/xfs_extfree_item.o CC fs/xfs/xfs_fsops.o CC fs/xfs/xfs_ialloc.o CC fs/xfs/xfs_ialloc_btree.o CC fs/xfs/xfs_iget.o CC fs/xfs/xfs_inode.o CC fs/xfs/xfs_inode_item.o CC fs/xfs/xfs_iocore.o CC fs/xfs/xfs_iomap.o CC fs/xfs/xfs_itable.o CC fs/xfs/xfs_dfrag.o CC fs/xfs/xfs_log.o CC fs/xfs/xfs_log_recover.o CC fs/xfs/xfs_macros.o CC fs/xfs/xfs_mount.o CC fs/xfs/xfs_rename.o CC fs/xfs/xfs_trans.o CC fs/xfs/xfs_trans_ail.o CC fs/xfs/xfs_trans_buf.o CC fs/xfs/xfs_trans_extfree.o CC fs/xfs/xfs_trans_inode.o CC fs/xfs/xfs_trans_item.o CC fs/xfs/xfs_utils.o CC fs/xfs/xfs_vfsops.o CC fs/xfs/xfs_vnodeops.o CC fs/xfs/xfs_rw.o CC fs/xfs/linux/mrlock.o CC fs/xfs/linux/xfs_aops.o CC fs/xfs/linux/xfs_buf.o CC fs/xfs/linux/xfs_file.o CC fs/xfs/linux/xfs_fs_subr.o CC fs/xfs/linux/xfs_globals.o CC fs/xfs/linux/xfs_ioctl.o CC fs/xfs/linux/xfs_iops.o CC fs/xfs/linux/xfs_lrw.o CC fs/xfs/linux/xfs_super.o CC fs/xfs/linux/xfs_vfs.o CC fs/xfs/linux/xfs_vnode.o CC fs/xfs/support/debug.o CC fs/xfs/support/move.o CC fs/xfs/support/qsort.o CC fs/xfs/support/uuid.o LD fs/xfs/xfs.o LD fs/xfs/built-in.o LD fs/built-in.o CC ipc/util.o CC ipc/msg.o CC ipc/sem.o CC ipc/shm.o LD ipc/built-in.o CC security/commoncap.o CC security/capability.o LD security/built-in.o CC crypto/api.o CC crypto/cipher.o CC crypto/digest.o CC crypto/compress.o CC crypto/proc.o CC crypto/hmac.o CC crypto/crypto_null.o CC crypto/md4.o CC crypto/md5.o CC crypto/sha1.o CC crypto/sha256.o CC crypto/sha512.o CC crypto/des.o CC crypto/blowfish.o CC crypto/twofish.o CC crypto/serpent.o CC crypto/aes.o CC crypto/cast5.o CC crypto/cast6.o CC crypto/deflate.o CC crypto/tcrypt.o LD crypto/built-in.o CC drivers/atm/he.o CC drivers/atm/suni.o LD drivers/atm/built-in.o CC drivers/base/core.o CC drivers/base/sys.o CC drivers/base/interface.o CC drivers/base/bus.o CC drivers/base/driver.o CC drivers/base/class.o CC drivers/base/class_simple.o CC drivers/base/platform.o CC drivers/base/cpu.o CC drivers/base/firmware.o CC drivers/base/init.o CC drivers/base/map.o CC drivers/base/dmapool.o CC drivers/base/power/shutdown.o CC drivers/base/power/main.o CC drivers/base/power/suspend.o CC drivers/base/power/resume.o CC drivers/base/power/runtime.o CC drivers/base/power/sysfs.o LD drivers/base/power/built-in.o CC drivers/base/firmware_class.o LD drivers/base/built-in.o CC drivers/block/elevator.o CC drivers/block/ll_rw_blk.o CC drivers/block/ioctl.o CC drivers/block/genhd.o CC drivers/block/scsi_ioctl.o CC drivers/block/noop-iosched.o CC drivers/block/as-iosched.o CC drivers/block/deadline-iosched.o CC drivers/block/floppy.o CC drivers/block/rd.o LD drivers/block/built-in.o LD drivers/block/paride/built-in.o CC drivers/bluetooth/hci_ldisc.o CC drivers/bluetooth/hci_h4.o CC drivers/bluetooth/hci_bcsp.o LD drivers/bluetooth/hci_uart.o LD drivers/bluetooth/built-in.o LD drivers/cdrom/built-in.o CC drivers/char/mem.o CC drivers/char/random.o CC drivers/char/tty_io.o CC drivers/char/n_tty.o CC drivers/char/tty_ioctl.o CC drivers/char/pty.o CC drivers/char/misc.o CC drivers/char/vt_ioctl.o CC drivers/char/vc_screen.o CC drivers/char/consolemap.o CONMK drivers/char/consolemap_deftbl.c CC drivers/char/consolemap_deftbl.o CC drivers/char/selection.o CC drivers/char/keyboard.o CC drivers/char/vt.o SHIPPED drivers/char/defkeymap.c CC drivers/char/defkeymap.o CC drivers/char/sysrq.o CC drivers/char/rtc.o CC drivers/char/hw_random.o LD drivers/char/agp/built-in.o LD drivers/char/drm/built-in.o LD drivers/char/ftape/compressor/built-in.o LD drivers/char/ftape/lowlevel/built-in.o LD drivers/char/ftape/zftape/built-in.o LD drivers/char/ipmi/built-in.o LD drivers/char/mwave/built-in.o LD drivers/char/pcmcia/built-in.o CC drivers/char/watchdog/i8xx_tco.o CC drivers/char/watchdog/w83627hf_wdt.o CC drivers/char/watchdog/cpu5wdt.o CC drivers/char/watchdog/pcwd_pci.o LD drivers/char/watchdog/built-in.o CC drivers/char/hangcheck-timer.o LD drivers/char/built-in.o CC drivers/cpufreq/cpufreq.o CC drivers/cpufreq/cpufreq_performance.o CC drivers/cpufreq/cpufreq_powersave.o CC drivers/cpufreq/cpufreq_userspace.o CC drivers/cpufreq/freq_table.o CC drivers/cpufreq/proc_intf.o LD drivers/cpufreq/built-in.o GEN drivers/eisa/devlist.h CC drivers/eisa/eisa-bus.o CC drivers/eisa/pci_eisa.o CC drivers/eisa/virtual_root.o LD drivers/eisa/built-in.o CC drivers/i2c/i2c-core.o LD drivers/i2c/algos/built-in.o LD drivers/i2c/busses/built-in.o LD drivers/i2c/chips/built-in.o LD drivers/i2c/built-in.o LD drivers/ide/arm/built-in.o LD drivers/ide/legacy/built-in.o CC drivers/ide/pci/aec62xx.o CC drivers/ide/pci/alim15x3.o CC drivers/ide/pci/amd74xx.o CC drivers/ide/pci/cmd64x.o CC drivers/ide/pci/cs5530.o CC drivers/ide/pci/cy82c693.o CC drivers/ide/pci/hpt34x.o CC drivers/ide/pci/hpt366.o CC drivers/ide/pci/pdc202xx_old.o CC drivers/ide/pci/pdc202xx_new.o CC drivers/ide/pci/piix.o CC drivers/ide/pci/rz1000.o CC drivers/ide/pci/serverworks.o CC drivers/ide/pci/siimage.o CC drivers/ide/pci/sis5513.o CC drivers/ide/pci/slc90e66.o CC drivers/ide/pci/triflex.o CC drivers/ide/pci/via82cxxx.o CC drivers/ide/pci/generic.o LD drivers/ide/pci/built-in.o CC drivers/ide/ide.o CC drivers/ide/ide-default.o CC drivers/ide/ide-io.o CC drivers/ide/ide-iops.o CC drivers/ide/ide-lib.o CC drivers/ide/ide-probe.o CC drivers/ide/ide-taskfile.o CC drivers/ide/pci/cmd640.o CC drivers/ide/setup-pci.o CC drivers/ide/ide-dma.o CC drivers/ide/ide-proc.o CC drivers/ide/ide-pnp.o LD drivers/ide/ide-core.o CC drivers/ide/ide-generic.o CC drivers/ide/ide-disk.o CC drivers/ide/ide-floppy.o LD drivers/ide/built-in.o LD drivers/ieee1394/built-in.o CC drivers/input/input.o CC drivers/input/mousedev.o CC drivers/input/tsdev.o CC drivers/input/evbug.o CC drivers/input/joystick/a3d.o CC drivers/input/joystick/adi.o CC drivers/input/joystick/analog.o CC drivers/input/joystick/cobra.o CC drivers/input/joystick/gf2k.o CC drivers/input/joystick/grip.o CC drivers/input/joystick/grip_mp.o CC drivers/input/joystick/guillemot.o CC drivers/input/joystick/interact.o CC drivers/input/joystick/magellan.o CC drivers/input/joystick/sidewinder.o CC drivers/input/joystick/spaceball.o CC drivers/input/joystick/spaceorb.o CC drivers/input/joystick/stinger.o CC drivers/input/joystick/tmdc.o CC drivers/input/joystick/warrior.o CC drivers/input/joystick/iforce/iforce-ff.o CC drivers/input/joystick/iforce/iforce-main.o CC drivers/input/joystick/iforce/iforce-packets.o CC drivers/input/joystick/iforce/iforce-serio.o LD drivers/input/joystick/iforce/iforce.o LD drivers/input/joystick/iforce/built-in.o LD drivers/input/joystick/built-in.o CC drivers/input/keyboard/atkbd.o CC drivers/input/keyboard/sunkbd.o CC drivers/input/keyboard/xtkbd.o CC drivers/input/keyboard/newtonkbd.o LD drivers/input/keyboard/built-in.o CC drivers/input/misc/pcspkr.o CC drivers/input/misc/uinput.o LD drivers/input/misc/built-in.o CC drivers/input/mouse/inport.o CC drivers/input/mouse/logibm.o CC drivers/input/mouse/pc110pad.o CC drivers/input/mouse/psmouse-base.o CC drivers/input/mouse/logips2pp.o CC drivers/input/mouse/synaptics.o LD drivers/input/mouse/psmouse.o CC drivers/input/mouse/sermouse.o LD drivers/input/mouse/built-in.o CC drivers/input/touchscreen/gunze.o LD drivers/input/touchscreen/built-in.o LD drivers/input/built-in.o CC drivers/input/gameport/gameport.o CC drivers/input/gameport/emu10k1-gp.o CC drivers/input/gameport/fm801-gp.o CC drivers/input/gameport/lightning.o CC drivers/input/gameport/ns558.o drivers/input/gameport/ns558.c: In function `ns558_isa_probe': drivers/input/gameport/ns558.c:80: warning: `check_region' is deprecated (declared at include/linux/ioport.h:121) drivers/input/gameport/ns558.c:121: warning: `check_region' is deprecated (declared at include/linux/ioport.h:121) CC drivers/input/gameport/vortex.o LD drivers/input/gameport/built-in.o CC drivers/input/serio/serio.o CC drivers/input/serio/i8042.o CC drivers/input/serio/serport.o CC drivers/input/serio/ct82c710.o CC drivers/input/serio/pcips2.o LD drivers/input/serio/built-in.o CC drivers/isdn/capi/kcapi.o CC drivers/isdn/capi/capiutil.o CC drivers/isdn/capi/capilib.o CC drivers/isdn/capi/kcapi_proc.o LD drivers/isdn/capi/kernelcapi.o CC drivers/isdn/capi/capi.o CC drivers/isdn/capi/capifs.o LD drivers/isdn/capi/built-in.o CC drivers/isdn/hardware/avm/b1isa.o drivers/isdn/hardware/avm/b1isa.c: In function `b1isa_init': drivers/isdn/hardware/avm/b1isa.c:183: structure has no member named `irq_resource' make[4]: *** [drivers/isdn/hardware/avm/b1isa.o] Error 1 make[3]: *** [drivers/isdn/hardware/avm] Error 2 make[2]: *** [drivers/isdn/hardware] Error 2 make[1]: *** [drivers/isdn] Error 2 make: *** [drivers] Error 2 [root at localhost linux-2.6.3]# Thanks, Bill --------------------------------- Everyone is raving about the all-new Yahoo! Mail. -------------- next part -------------- An HTML attachment was scrubbed... URL: From secnotice at fedoralegacy.org Mon Nov 13 07:42:12 2006 From: secnotice at fedoralegacy.org (David Eisenstein) Date: Mon, 13 Nov 2006 01:42:12 -0600 Subject: [FLSA-2006:211760] Updated gzip package fixes security issues Message-ID: <455821D4.1010607@fedoralegacy.org> --------------------------------------------------------------------- Fedora Legacy Update Advisory Synopsis: Updated gzip package fixes security issues Advisory ID: FLSA:211760 Issue date: 2006-11-13 Product: Red Hat Linux, Fedora Core Keywords: Bugfix CVE Names: CVE-2006-4334, CVE-2006-4338, CVE-2006-4335, CVE-2006-4336, CVE-2006-4337 --------------------------------------------------------------------- --------------------------------------------------------------------- 1. Topic: An updated gzip package is now available. The gzip package contains the GNU gzip data compression program. 2. Relevant releases/architectures: Fedora Core 3 - i386, x86_64 Fedora Core 4 - i386, x86_64 3. Problem description: Tavis Ormandy of the Google Security Team discovered two denial of service flaws in the way gzip expanded archive files. If a victim expanded a specially crafted archive, it could cause the gzip executable to hang or crash. (CVE-2006-4334, CVE-2006-4338) Tavis Ormandy of the Google Security Team discovered several code execution flaws in the way gzip expanded archive files. If a victim expanded a specially crafted archive, it could cause the gzip executable to crash or execute arbitrary code. (CVE-2006-4335, CVE-2006-4336, CVE-2006-4337) Users of gzip should upgrade to this updated package, which contain a backported patch and is not vulnerable to these issues. 4. Solution: Before applying this update, make sure all previously released errata relevant to your system have been applied. To update all RPMs for your particular architecture, run: rpm -Fvh [filenames] where [filenames] is a list of the RPMs you wish to upgrade. Only those RPMs which are currently installed will be updated. Those RPMs which are not installed but included in the list will not be updated. Note that you can also use wildcards (*.rpm) if your current directory *only* contains the desired RPMs. Please note that this update is also available via yum and apt. Many people find this an easier way to apply updates. To use yum issue: yum update or to use apt: apt-get update; apt-get upgrade This will start an interactive process that will result in the appropriate RPMs being upgraded on your system. This assumes that you have yum or apt-get configured for obtaining Fedora Legacy content. Please visit http://www.fedoralegacy.org/docs for directions on how to configure yum and apt-get. 5. Bug IDs fixed: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=211760 6. RPMs required: Fedora Core 3: SRPM: http://download.fedoralegacy.org/fedora/3/updates/SRPMS/gzip-1.3.3-16.1.fc3.legacy.src.rpm i386: http://download.fedoralegacy.org/fedora/3/updates/i386/gzip-1.3.3-16.1.fc3.legacy.i386.rpm x86_64: http://download.fedoralegacy.org/fedora/3/updates/x86_64/gzip-1.3.3-16.1.fc3.legacy.x86_64.rpm Fedora Core 4: SRPM: http://download.fedoralegacy.org/fedora/4/updates/SRPMS/gzip-1.3.5-6.1.0.legacy.src.rpm i386: http://download.fedoralegacy.org/fedora/4/updates/i386/gzip-1.3.5-6.1.0.legacy.i386.rpm x86_64: http://download.fedoralegacy.org/fedora/4/updates/x86_64/gzip-1.3.5-6.1.0.legacy.x86_64.rpm 7. Verification: SHA1 sum Package Name --------------------------------------------------------------------- fc3: 803cef0b8d4e06f79ae9ce64aee63cdd761e87b6 fedora/3/updates/i386/gzip-1.3.3-16.1.fc3.legacy.i386.rpm 602ad6828a3388063db0c45f13c256d92b12cc51 fedora/3/updates/x86_64/gzip-1.3.3-16.1.fc3.legacy.x86_64.rpm 7f4737f9e627480ee211022b9dffc1da5696adda fedora/3/updates/SRPMS/gzip-1.3.3-16.1.fc3.legacy.src.rpm fc4: 1cf4530543c8f7da0d331f11388bb7517fa013e4 fedora/4/updates/i386/gzip-1.3.5-6.1.0.legacy.i386.rpm 17fb012aacf13fcf623c5f6447d4ba127ed4a780 fedora/4/updates/x86_64/gzip-1.3.5-6.1.0.legacy.x86_64.rpm b49360a81b5d4df62dbbb3b2b094515678f41a35 fedora/4/updates/SRPMS/gzip-1.3.5-6.1.0.legacy.src.rpm These packages are GPG signed by Fedora Legacy for security. Our key is available from http://www.fedoralegacy.org/about/security.php You can verify each package with the following command: rpm --checksig -v If you only wish to verify that each package has not been corrupted or tampered with, examine only the sha1sum with the following command: sha1sum 8. References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4334 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4338 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4335 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4336 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4337 9. Contact: The Fedora Legacy security contact is . More project details at http://www.fedoralegacy.org --------------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From jason at reusch.net Mon Nov 13 16:31:28 2006 From: jason at reusch.net (Jason Reusch) Date: Mon, 13 Nov 2006 10:31:28 -0600 Subject: Wiki Correction Message-ID: <20061113103128.zr5br374hwcwcckw@mail.reusch.net> My apologies if this is not the appropriate place to post this correction. I signed up for the wiki, but the page is immutable. Many thanks for this project. It has been a big help to me. See: http://www.fedoraproject.org/wiki/Legacy/YumFC4Detailed Step 1.3: Check for yum package installation rpm -Uvh http://download.fedoralegacy.org/fedora/4/os/i386/yum-2.4.1-1.fc4.noarch.rpm The link is incorrect and returns a 404. I believe this is the correct link. http://download.fedoralegacy.org/fedora/4/updates/i386/yum-2.4.1-1.fc4.noarch.rpm Ahoy, Jason http://reusch.net http://jason.reusch.net From sundaram at fedoraproject.org Mon Nov 13 16:52:39 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 13 Nov 2006 22:22:39 +0530 Subject: Wiki Correction In-Reply-To: <20061113103128.zr5br374hwcwcckw@mail.reusch.net> References: <20061113103128.zr5br374hwcwcckw@mail.reusch.net> Message-ID: <4558A2D7.4040907@fedoraproject.org> Jason Reusch wrote: > > My apologies if this is not the appropriate place to post this > correction. I signed up for the wiki, but the page is immutable. Many > thanks for this project. It has been a big help to me. > You need to be in the edit group for wiki write access. See http://jkeating.livejournal.com/32250.html > > See: http://www.fedoraproject.org/wiki/Legacy/YumFC4Detailed > > > Step 1.3: Check for yum package installation > > rpm -Uvh > http://download.fedoralegacy.org/fedora/4/os/i386/yum-2.4.1-1.fc4.noarch.rpm > > > The link is incorrect and returns a 404. > > I believe this is the correct link. > > http://download.fedoralegacy.org/fedora/4/updates/i386/yum-2.4.1-1.fc4.noarch.rpm > Thanks. Fixed. Rahul From mattdm at mattdm.org Mon Nov 13 18:44:45 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Mon, 13 Nov 2006 13:44:45 -0500 Subject: I get this error when trying to upgrade my 2.4.20-8 to 2.6.3 after make install In-Reply-To: <20061108213648.68528.qmail@web90501.mail.mud.yahoo.com> References: <20061108213648.68528.qmail@web90501.mail.mud.yahoo.com> Message-ID: <20061113184445.GA4667@jadzia.bu.edu> On Wed, Nov 08, 2006 at 01:36:48PM -0800, Bill Perrotta wrote: > I get this error when trying to upgrade my 2.4.20-8 to 2.6.3 after make > install see below Any particular reason 2.6.3? Among other things, that's going to leave you with some huge security problems. But additionally, I don't think the infrastructure is there in RHL 9 to run the 2.6 kernel without a lot of work. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From billperrotta at yahoo.com Mon Nov 13 22:11:14 2006 From: billperrotta at yahoo.com (Bill Perrotta) Date: Mon, 13 Nov 2006 14:11:14 -0800 (PST) Subject: I get this error when trying to upgrade my 2.4.20-8 to 2.6.3 after make install In-Reply-To: <20061113184445.GA4667@jadzia.bu.edu> Message-ID: <20061113221114.94771.qmail@web90510.mail.mud.yahoo.com> Security is not a concern. I am using redhat 9 because it is almost the same as rhel3. This is a test not a production box. What kernel can i use to easilly upgrade rhel9 to have the disk quota feature because it is not there in 2.4.20-8 kernel. The disk quota feature is all i'm interested in because it's on the rhce exam. Forget about security or anything else. I need to complete the labs Thanks, Bill Matthew Miller wrote: On Wed, Nov 08, 2006 at 01:36:48PM -0800, Bill Perrotta wrote: > I get this error when trying to upgrade my 2.4.20-8 to 2.6.3 after make > install see below Any particular reason 2.6.3? Among other things, that's going to leave you with some huge security problems. But additionally, I don't think the infrastructure is there in RHL 9 to run the 2.6 kernel without a lot of work. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> -- fedora-legacy-list mailing list fedora-legacy-list at redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list --------------------------------- Access over 1 million songs - Yahoo! Music Unlimited. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mattdm at mattdm.org Tue Nov 14 03:27:28 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Mon, 13 Nov 2006 22:27:28 -0500 Subject: I get this error when trying to upgrade my 2.4.20-8 to 2.6.3 after make install In-Reply-To: <20061113221114.94771.qmail@web90510.mail.mud.yahoo.com> References: <20061113184445.GA4667@jadzia.bu.edu> <20061113221114.94771.qmail@web90510.mail.mud.yahoo.com> Message-ID: <20061114032728.GA28540@jadzia.bu.edu> On Mon, Nov 13, 2006 at 02:11:14PM -0800, Bill Perrotta wrote: > Security is not a concern. I am using redhat 9 because it is almost the > same as rhel3. This is a test not a production box. What kernel can i use CentOS 3 is probably a better choice there. > to easilly upgrade rhel9 to have the disk quota feature because it is not > there in 2.4.20-8 kernel. This is a bug in that kernel version. Make sure you have at least 2.4.20-18.7. You don't need to go all the way to 2.6.x. The latest RHL9 kernel 2.4.20-46.9.legacy. And, although I haven't specifically tested, I'd be shocked if the RHEL3/CentOS 3 kernel (kernel-2.4.21-47.0.1.EL) didn't have the problem fixed as well. That may or may not work without modification on RHL9 -- I wouldn't bother to try that route though and instead would just install CentOS. > The disk quota feature is all i'm interested in because it's on the rhce > exam. > Forget about security or anything else. I need to complete the labs. Why RHEL3, though? Wouldn't you want RHEL4? -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From rostetter at mail.utexas.edu Tue Nov 14 16:36:00 2006 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Tue, 14 Nov 2006 10:36:00 -0600 Subject: I get this error when trying to upgrade my 2.4.20-8 to 2.6.3 after make install In-Reply-To: <20061108213648.68528.qmail@web90501.mail.mud.yahoo.com> References: <20061108213648.68528.qmail@web90501.mail.mud.yahoo.com> Message-ID: <20061114103600.xt5ipr8lfcgs48o0@mail.ph.utexas.edu> Quoting Bill Perrotta : > Someone please help. I need to recompile redhat nine to add disk > quotas for my rhce. Okay. So recompile the correct version of the kernel. > I get this error when trying to upgrade my 2.4.20-8 to 2.6.3 after > make install see below You can't upgrade the kernel from 2.4 to 2.6 without upgrading lots of other packages also. RHL 9 doesnt' support 2.6, and while you can shoe-horn it on (I did), you need to upgrade a lot more than just the kernel (module utils being one of the biggest ones). Have you looked into this and done the other upgrades needed also? > CC drivers/isdn/hardware/avm/b1isa.o > drivers/isdn/hardware/avm/b1isa.c: In function `b1isa_init': > drivers/isdn/hardware/avm/b1isa.c:183: structure has no member named > `irq_resource' If that is really an ISDN thing, and you don't need ISDN, you might just try configuring the kernel to not use ISDN. Most people don't need ISDN support. -- Eric Rostetter The Department of Physics The University of Texas at Austin Go Longhorns! From rostetter at mail.utexas.edu Tue Nov 14 18:50:22 2006 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Tue, 14 Nov 2006 12:50:22 -0600 Subject: I get this error when trying to upgrade my 2.4.20-8 to 2.6.3 after make install In-Reply-To: <20061113221114.94771.qmail@web90510.mail.mud.yahoo.com> References: <20061113221114.94771.qmail@web90510.mail.mud.yahoo.com> Message-ID: <20061114125022.qmplvdfj680wsgc8@mail.ph.utexas.edu> Quoting Bill Perrotta : > The disk quota feature is all i'm interested in because it's on the > rhce exam. > Forget about security or anything else. I need to complete the labs RHL 9 had disk quota support. The same support basically as RHEL 3.x. You should not have to upgrade to any newer kernel. If you want a RHEL type system, why not use a clone like CentOS instead? It is mucher closer to RHEL than RHL 9 will ever be. -- Eric Rostetter The Department of Physics The University of Texas at Austin Go Longhorns! From mic at npgx.com.au Tue Nov 14 19:52:11 2006 From: mic at npgx.com.au (Michael Mansour) Date: Wed, 15 Nov 2006 05:52:11 +1000 Subject: I get this error when trying to upgrade my 2.4.20-8 to 2.6.3 after make install In-Reply-To: <20061113221114.94771.qmail@web90510.mail.mud.yahoo.com> References: <20061113184445.GA4667@jadzia.bu.edu> <20061113221114.94771.qmail@web90510.mail.mud.yahoo.com> Message-ID: <20061114195117.M94719@npgx.com.au> Hi Bill, > Security is not a concern. I am using redhat 9 because it is almost > the same as rhel3. This is a test not a production box. What kernel > can i use to easilly upgrade rhel9 to have the disk quota feature > because it is not there in 2.4.20-8 kernel. The disk quota feature > is all i'm interested in because it's on the rhce exam. Forget about > security or anything else. I need to complete the labs Thanks, > Bill Then you really should be using CentOS or Scientific Linux which give you a much more accurate representation of the OS used for the exam than RH9. Regards, Michael. From martin at bugs.unl.edu.ar Tue Nov 14 19:56:27 2006 From: martin at bugs.unl.edu.ar (Martin Marques) Date: Tue, 14 Nov 2006 16:56:27 -0300 (ART) Subject: Mailman vulnerability In-Reply-To: <200611080719.11376.jkeating@redhat.com> References: <20061005161245.GB17040@mail.harddata.com> <200611080719.11376.jkeating@redhat.com> Message-ID: On Wed, 8 Nov 2006, Jesse Keating wrote: > On Wednesday 08 November 2006 06:45, Martin Marques wrote: >> Would you people like to see the patches first or do I send the src.rpm? > > Either way. We now manage FC-4 in CVS so adding just a patch to generate a > updates-testing rpm is easy enough. OK. I finished adding patches to mailman from RHEL to FC4, risulting in the next src.rpm: http://bugs.unl.edu.ar/~martin/mailman-2.1.8-1.FC4.1.legacy.src.rpm Also have a binary: http://bugs.unl.edu.ar/~martin/mailman-2.1.8-1.FC4.1.legacy.i386.rpm At this moment I can't test the rpm because the only FC4 I have is a dedicated server. But be sure that the only change I add from privoius version was add the las 2 patches (see the .spec file). Let me know how things work out. -- 21:50:04 up 2 days, 9:07, 0 users, load average: 0.92, 0.37, 0.18 --------------------------------------------------------- Lic. Mart?n Marqu?s | SELECT 'mmarques' || Centro de Telem?tica | '@' || 'unl.edu.ar'; Universidad Nacional | DBA, Programador, del Litoral | Administrador --------------------------------------------------------- From mattdm at mattdm.org Tue Nov 14 20:04:16 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 14 Nov 2006 15:04:16 -0500 Subject: I get this error when trying to upgrade my 2.4.20-8 to 2.6.3 after make install In-Reply-To: <20061114125022.qmplvdfj680wsgc8@mail.ph.utexas.edu> References: <20061113221114.94771.qmail@web90510.mail.mud.yahoo.com> <20061114125022.qmplvdfj680wsgc8@mail.ph.utexas.edu> Message-ID: <20061114200416.GA1649@jadzia.bu.edu> On Tue, Nov 14, 2006 at 12:50:22PM -0600, Eric Rostetter wrote: > RHL 9 had disk quota support. The same support basically as RHEL 3.x. > You should not have to upgrade to any newer kernel. Actually, there was a bug in quota support in the kernel shipped with the initial RHL9 release. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From jkeating at redhat.com Wed Nov 15 03:47:30 2006 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 14 Nov 2006 22:47:30 -0500 Subject: Important information regarding the merger of core and extras, and what this means to Legacy Message-ID: <200611142247.30110.jkeating@redhat.com> See my blog regarding the future of Legacy as a project. Please remember these are just proposals and not final solutions. A wiki page will follow soon. http://jkeating.livejournal.com/#entry_34659 -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rostetter at mail.utexas.edu Wed Nov 15 04:06:57 2006 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Tue, 14 Nov 2006 22:06:57 -0600 Subject: Important information regarding the merger of core and extras, and what this means to Legacy In-Reply-To: <200611142247.30110.jkeating@redhat.com> References: <200611142247.30110.jkeating@redhat.com> Message-ID: <20061114220657.0je0ht9m8vwcgow8@mail.ph.utexas.edu> Quoting Jesse Keating : > See my blog regarding the future of Legacy as a project. Please remember > these are just proposals and not final solutions. A wiki page will follow > soon. First I would like to say to those who say Fedora Legacy has failed, that it _did_ work (i.e. didn't fail) for the most critical time period and the most critical OS version (RHL 7-9, FC1). If it has failed, or is failing, it must not be forgotten that before it failed it worked exceedingly well. Second, I'm fairly comfortable with saying that if FC goes to a 13 month support cycle, FL is basically not needed anymore. IMHO, people can upgrade once a year when presented with a known/documented release cycle, and known documented alternatives. Now, I don't know that FC will change, or if FL is needed any more even if FC doesn't change. But I do know that FL saved my life by being there when I needed it, and while I don't really need it any more I'm forever grateful to it for being there when I did need it. -- Eric Rostetter The Department of Physics The University of Texas at Austin Go Longhorns! From deisenst at gtw.net Wed Nov 15 06:50:46 2006 From: deisenst at gtw.net (David Eisenstein) Date: Wed, 15 Nov 2006 00:50:46 -0600 Subject: Mailman vulnerability In-Reply-To: References: <20061005161245.GB17040@mail.harddata.com> <200611080719.11376.jkeating@redhat.com> Message-ID: <455AB8C6.4000702@gtw.net> Martin Marques wrote: > On Wed, 8 Nov 2006, Jesse Keating wrote: > >> On Wednesday 08 November 2006 06:45, Martin Marques wrote: >> >>> Would you people like to see the patches first or do I send the src.rpm? >> >> >> Either way. We now manage FC-4 in CVS so adding just a patch to generate a >> updates-testing rpm is easy enough. > > > OK. I finished adding patches to mailman from RHEL to FC4, risulting in > the next src.rpm: > > http://bugs.unl.edu.ar/~martin/mailman-2.1.8-1.FC4.1.legacy.src.rpm > > Also have a binary: > > http://bugs.unl.edu.ar/~martin/mailman-2.1.8-1.FC4.1.legacy.i386.rpm > > At this moment I can't test the rpm because the only FC4 I have is a > dedicated server. But be sure that the only change I add from privoius > version was add the las 2 patches (see the .spec file). > > Let me know how things work out. Thanks a bunch, Martin! :) Info on your source package has been placed into Bugzilla #209891 , and hopefully we'll soon have this QA'ed and published in the Legacy repositories! We still need work on the FC3 version of this package: mailman-2.1.5-32.fc3.src.rpm in Bugzilla #211676. Thanks again. :) -David -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From jkeating at redhat.com Wed Nov 15 12:25:02 2006 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 15 Nov 2006 07:25:02 -0500 Subject: Important information regarding the merger of core and extras, and what this means to Legacy In-Reply-To: <20061114220657.0je0ht9m8vwcgow8@mail.ph.utexas.edu> References: <200611142247.30110.jkeating@redhat.com> <20061114220657.0je0ht9m8vwcgow8@mail.ph.utexas.edu> Message-ID: <200611150725.05939.jkeating@redhat.com> On Tuesday 14 November 2006 23:06, Eric Rostetter wrote: > First I would like to say to those who say Fedora Legacy has failed, that > it _did_ work (i.e. didn't fail) for the most critical time period and the > most critical OS version (RHL 7-9, FC1). ?If it has failed, or is failing, > it must not be forgotten that before it failed it worked exceedingly well. YES! I forgot to mention this in my blog, but when we were doing the RHL updates, there was a LOT of interest and a lot of community participation, and the project worked pretty darn well. I think it became evident by the dramatic drop in participation that there just wasn't the interest we thought there would be in long term Fedora releases. This is why I think its OK in slightly extending the 'official' lifespan and bringing Legacy in to help with that aspect. Thank you for your feedback Eric, you've forever kept us honest! (: -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkosin at beta.intcomgrp.com Wed Nov 15 13:49:50 2006 From: jkosin at beta.intcomgrp.com (James Kosin) Date: Wed, 15 Nov 2006 08:49:50 -0500 Subject: Important information regarding the merger of core and extras, and what this means to Legacy In-Reply-To: <200611142247.30110.jkeating@redhat.com> References: <200611142247.30110.jkeating@redhat.com> Message-ID: <455B1AFE.2080905@beta.intcomgrp.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jesse Keating wrote: > See my blog regarding the future of Legacy as a project. Please remember > these are just proposals and not final solutions. A wiki page will follow > soon. > > http://jkeating.livejournal.com/#entry_34659 > I hope this doesn't mean Legacy is going away for good. I may have some critical things to say about participation; but, I still believe the community of participators can support a 6-12 month window with the FC releases fall aside. This will give those who choose to wait for a few months before upgrading the chance to keep up-to-date with security fixes while they wait. - -James -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFWxr+kNLDmnu1kSkRAuCoAJ94wq8mwcSaUorE92KkFk2QDqPDvgCfTxH4 pnYlEDi+uZoFFI97hPTkn8o= =wnDn -----END PGP SIGNATURE----- -- Scanned by ClamAV - http://www.clamav.net From jkeating at redhat.com Wed Nov 15 14:15:05 2006 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 15 Nov 2006 09:15:05 -0500 Subject: Important information regarding the merger of core and extras, and what this means to Legacy In-Reply-To: <455B1AFE.2080905@beta.intcomgrp.com> References: <200611142247.30110.jkeating@redhat.com> <455B1AFE.2080905@beta.intcomgrp.com> Message-ID: <200611150915.05105.jkeating@redhat.com> On Wednesday 15 November 2006 08:49, James Kosin wrote: > I may have some critical things to say about participation; but, I > still believe the community of participators can support a 6-12 month > window with the FC releases fall aside. ?This will give those who > choose to wait for a few months before upgrading the chance to keep > up-to-date with security fixes while they wait. The Fedora project would be offering 13~ months of updates (security only for the last part), which gives you the opportunity to go from say Fedora 7 to Fedora 9 + 1 month. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mattdm at mattdm.org Wed Nov 15 14:23:04 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 15 Nov 2006 09:23:04 -0500 Subject: Important information regarding the merger of core and extras, and what this means to Legacy In-Reply-To: <20061114220657.0je0ht9m8vwcgow8@mail.ph.utexas.edu> References: <200611142247.30110.jkeating@redhat.com> <20061114220657.0je0ht9m8vwcgow8@mail.ph.utexas.edu> Message-ID: <20061115142304.GA12538@jadzia.bu.edu> On Tue, Nov 14, 2006 at 10:06:57PM -0600, Eric Rostetter wrote: > First I would like to say to those who say Fedora Legacy has failed, that > it _did_ work (i.e. didn't fail) for the most critical time period and the > most critical OS version (RHL 7-9, FC1). If it has failed, or is failing, > it must not be forgotten that before it failed it worked exceedingly well. Or at least moderately well. Let's not over-sell. :) > Second, I'm fairly comfortable with saying that if FC goes to a 13 month > support cycle, FL is basically not needed anymore. IMHO, people can upgrade > once a year when presented with a known/documented release cycle, and known > documented alternatives. One month of annual overlap is still a bit short. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From martin at bugs.unl.edu.ar Wed Nov 15 14:25:23 2006 From: martin at bugs.unl.edu.ar (Martin Marques) Date: Wed, 15 Nov 2006 11:25:23 -0300 Subject: Mailman vulnerability In-Reply-To: <455AB8C6.4000702@gtw.net> References: <455AB8C6.4000702@gtw.net> Message-ID: On Wed, 15 Nov 2006 00:50:46 -0600, David Eisenstein wrote: > > We still need work on the FC3 version of this package: > mailman-2.1.5-32.fc3.src.rpm > in Bugzilla #211676. This should be easier, as the patches I used from RHEL (attached in this mail) were for mailmail 2.1.5. Maybe they can be applied directly. -- --------------------------------------------------------- Lic. Mart?n Marqu?s | SELECT 'mmarques' || Centro de Telem?tica | '@' || 'unl.edu.ar'; Universidad Nacional | DBA, Programador, del Litoral | Administrador --------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: mailman-2.1-CVE-2006-2941.patch Type: text/x-patch Size: 2030 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: mailman-2.1-CVE-2006-3636.patch Type: text/x-patch Size: 10148 bytes Desc: not available URL: From jkosin at beta.intcomgrp.com Wed Nov 15 14:45:11 2006 From: jkosin at beta.intcomgrp.com (James Kosin) Date: Wed, 15 Nov 2006 09:45:11 -0500 Subject: Important information regarding the merger of core and extras, and what this means to Legacy In-Reply-To: <200611150915.05105.jkeating@redhat.com> References: <200611142247.30110.jkeating@redhat.com> <455B1AFE.2080905@beta.intcomgrp.com> <200611150915.05105.jkeating@redhat.com> Message-ID: <455B27F7.6030802@beta.intcomgrp.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jesse Keating wrote: > > The Fedora project would be offering 13~ months of updates > (security only for the last part), which gives you the opportunity > to go from say Fedora 7 to Fedora 9 + 1 month. > I though Fedora project would be keeping only one previous version, so by FC9, FC7 would have been taboo to even mention. And with the quick pace of releases, 13 months would be about FC13 or 14 by then. Just kidding.... Hmmm..... maybe a better upgrade path would be in order. Allowing users to keep their configuration; with minor changes and upgrade the units to FC6->FC7->FC8 etc. without any troubles. I'll have to give that a try someday. - -James -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFWyfxkNLDmnu1kSkRAvk7AJ0SotwaV8aSMNlS+kg1AsHqr8geigCePq4e dVUQir8Q6T2Z6xyrSmvUhtk= =Ixre -----END PGP SIGNATURE----- -- Scanned by ClamAV - http://www.clamav.net From jkeating at redhat.com Wed Nov 15 14:48:25 2006 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 15 Nov 2006 09:48:25 -0500 Subject: Important information regarding the merger of core and extras, and what this means to Legacy In-Reply-To: <455B27F7.6030802@beta.intcomgrp.com> References: <200611142247.30110.jkeating@redhat.com> <200611150915.05105.jkeating@redhat.com> <455B27F7.6030802@beta.intcomgrp.com> Message-ID: <200611150948.25650.jkeating@redhat.com> On Wednesday 15 November 2006 09:45, James Kosin wrote: > Hmmm..... ? maybe a better upgrade path would be in order. ?Allowing > users to keep their configuration; with minor changes and upgrade the > units to FC6->FC7->FC8 etc. ?without any troubles. > > I'll have to give that a try someday. We're also committing to testing FC6 -> FC8 in one jump. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From gene.heskett at verizon.net Wed Nov 15 14:54:32 2006 From: gene.heskett at verizon.net (Gene Heskett) Date: Wed, 15 Nov 2006 09:54:32 -0500 Subject: Important information regarding the merger of core and extras, and what this means to Legacy In-Reply-To: <20061115142304.GA12538@jadzia.bu.edu> References: <200611142247.30110.jkeating@redhat.com> <20061114220657.0je0ht9m8vwcgow8@mail.ph.utexas.edu> <20061115142304.GA12538@jadzia.bu.edu> Message-ID: <200611150954.32735.gene.heskett@verizon.net> On Wednesday 15 November 2006 09:23, Matthew Miller wrote: >On Tue, Nov 14, 2006 at 10:06:57PM -0600, Eric Rostetter wrote: >> First I would like to say to those who say Fedora Legacy has failed, >> that it _did_ work (i.e. didn't fail) for the most critical time >> period and the most critical OS version (RHL 7-9, FC1). If it has >> failed, or is failing, it must not be forgotten that before it failed >> it worked exceedingly well. > >Or at least moderately well. Let's not over-sell. :) > >> Second, I'm fairly comfortable with saying that if FC goes to a 13 >> month support cycle, FL is basically not needed anymore. IMHO, people >> can upgrade once a year when presented with a known/documented release >> cycle, and known documented alternatives. > >One month of annual overlap is still a bit short. I can't help but agree that its too short. 3 or 6 would be much more realistic from the users viewpoint, who has his setup all fine tuned and doesn't want to go thru that on an annual basis. There are other things to life you know. -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2006 by Maurice Eugene Heskett, all rights reserved. From jkeating at redhat.com Wed Nov 15 15:10:13 2006 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 15 Nov 2006 10:10:13 -0500 Subject: Important information regarding the merger of core and extras, and what this means to Legacy In-Reply-To: <200611150954.32735.gene.heskett@verizon.net> References: <200611142247.30110.jkeating@redhat.com> <20061115142304.GA12538@jadzia.bu.edu> <200611150954.32735.gene.heskett@verizon.net> Message-ID: <200611151010.14026.jkeating@redhat.com> On Wednesday 15 November 2006 09:54, Gene Heskett wrote: > I can't help but agree that its too short. 3 or 6 would be much more > realistic from the users viewpoint, who has his setup all fine tuned and > doesn't want to go thru that on an annual basis. ?There are other things > to life you know. So why don't you use CentOS which as a annual or every other year release? -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From gene.heskett at verizon.net Wed Nov 15 15:32:33 2006 From: gene.heskett at verizon.net (Gene Heskett) Date: Wed, 15 Nov 2006 10:32:33 -0500 Subject: Important information regarding the merger of core and extras, and what this means to Legacy In-Reply-To: <200611151010.14026.jkeating@redhat.com> References: <200611142247.30110.jkeating@redhat.com> <200611150954.32735.gene.heskett@verizon.net> <200611151010.14026.jkeating@redhat.com> Message-ID: <200611151032.33591.gene.heskett@verizon.net> On Wednesday 15 November 2006 10:10, Jesse Keating wrote: >On Wednesday 15 November 2006 09:54, Gene Heskett wrote: >> I can't help but agree that its too short. 3 or 6 would be much more >> realistic from the users viewpoint, who has his setup all fine tuned >> and doesn't want to go thru that on an annual basis. ?There are other >> things to life you know. > >So why don't you use CentOS which as a annual or every other year > release? Theres several reasons, the old kernel version being one of them. Firewire doesn't work that I know of, and I have a firewire movie camera. -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2006 by Maurice Eugene Heskett, all rights reserved. From sheltren at cs.ucsb.edu Wed Nov 15 15:41:42 2006 From: sheltren at cs.ucsb.edu (Jeff Sheltren) Date: Wed, 15 Nov 2006 11:41:42 -0400 Subject: Important information regarding the merger of core and extras, and what this means to Legacy In-Reply-To: <200611150915.05105.jkeating@redhat.com> References: <200611142247.30110.jkeating@redhat.com> <455B1AFE.2080905@beta.intcomgrp.com> <200611150915.05105.jkeating@redhat.com> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Nov 15, 2006, at 10:15 AM, Jesse Keating wrote: > On Wednesday 15 November 2006 08:49, James Kosin wrote: >> I may have some critical things to say about participation; but, I >> still believe the community of participators can support a 6-12 month >> window with the FC releases fall aside. This will give those who >> choose to wait for a few months before upgrading the chance to keep >> up-to-date with security fixes while they wait. > > The Fedora project would be offering 13~ months of updates > (security only for > the last part), which gives you the opportunity to go from say > Fedora 7 to > Fedora 9 + 1 month. > I like this idea, and I'd be happy to see official support for an FC release last ~13 months. Of course, this would end all interest I have in Fedora Legacy, which at this point is mostly to allow upgrading (well, re-installing in my case) from FCN to FCN+2. How much of this is just speculation at this point, and how close is this to being actual policy? - -Jeff -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFFWzU5Ke7MLJjUbNMRApSRAJ98qSe5tHDiKuKEPFcspi2Z/OtbOQCgzC5d liw9n163X6Sml5UR73JLUXo= =/0t0 -----END PGP SIGNATURE----- From billperrotta at yahoo.com Wed Nov 15 15:42:04 2006 From: billperrotta at yahoo.com (Bill Perrotta) Date: Wed, 15 Nov 2006 07:42:04 -0800 (PST) Subject: Important information regarding the merger of core and extras, and what this means to Legacy In-Reply-To: <200611151010.14026.jkeating@redhat.com> Message-ID: <20061115154204.80489.qmail@web90503.mail.mud.yahoo.com> That is fine where can i download an iso of centos? If it is similar enough to do all labs for rhel3 rhce that is my only concern. Jesse Keating wrote: On Wednesday 15 November 2006 09:54, Gene Heskett wrote: > I can't help but agree that its too short. 3 or 6 would be much more > realistic from the users viewpoint, who has his setup all fine tuned and > doesn't want to go thru that on an annual basis. There are other things > to life you know. So why don't you use CentOS which as a annual or every other year release? -- Jesse Keating Release Engineer: Fedora -- fedora-legacy-list mailing list fedora-legacy-list at redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list --------------------------------- Sponsored Link Mortgage rates near 39yr lows. $510,000 Mortgage for $1,698/mo - Calculate new house payment -------------- next part -------------- An HTML attachment was scrubbed... URL: From guallar at easternrad.com Wed Nov 15 15:55:46 2006 From: guallar at easternrad.com (Josep L. Guallar-Esteve) Date: Wed, 15 Nov 2006 10:55:46 -0500 Subject: Important information regarding the merger of core and extras, and what this means to Legacy In-Reply-To: <20061115154204.80489.qmail@web90503.mail.mud.yahoo.com> References: <20061115154204.80489.qmail@web90503.mail.mud.yahoo.com> Message-ID: <200611151055.46985.guallar@easternrad.com> On Wednesday 15 November 2006 10:42, Bill Perrotta wrote: > That is fine where can i download an iso of centos? If it is similar enough > to do all labs for rhel3 rhce that is my only concern. CentOS-3 is a rebuild of the freely available of source code of RHEL-3 CentOS-4 is a rebuild of the freely available of source code of RHEL-4 As a result of being a rebuild, Centos-X is binary-compatible with RHEL-X You can download CentOS after a very easy search at the ultra-secret-website: http://www.google.com/search?q=linux+centos Regards, Josep -- Josep L. Guallar-Esteve - IT Department From nils at lemonbit.nl Wed Nov 15 15:57:32 2006 From: nils at lemonbit.nl (Nils Breunese (Lemonbit)) Date: Wed, 15 Nov 2006 10:57:32 -0500 Subject: [SPAM] LOW * Re: Important information regarding the merger of core and extras, and what this means to Legacy In-Reply-To: <20061115154204.80489.qmail@web90503.mail.mud.yahoo.com> References: <20061115154204.80489.qmail@web90503.mail.mud.yahoo.com> Message-ID: <42A13B9E-55BD-430B-ACD3-FDBFFBEDD195@lemonbit.nl> Bill Perrotta wrote: > That is fine where can i download an iso of centos? If it is > similar enough to do all labs for rhel3 rhce that is my only concern. Come on, Google is your friend. Go to http://www.centos.org/ and take it from there. CentOS 3 is exactly the same as RHEL 3, except for the branding. Nils. From sheltren at cs.ucsb.edu Wed Nov 15 15:57:31 2006 From: sheltren at cs.ucsb.edu (Jeff Sheltren) Date: Wed, 15 Nov 2006 11:57:31 -0400 Subject: Important information regarding the merger of core and extras, and what this means to Legacy In-Reply-To: <20061115154204.80489.qmail@web90503.mail.mud.yahoo.com> References: <20061115154204.80489.qmail@web90503.mail.mud.yahoo.com> Message-ID: <7B21DBC7-D250-4658-B682-2A5669280D5C@cs.ucsb.edu> On Nov 15, 2006, at 11:42 AM, Bill Perrotta wrote: > That is fine where can i download an iso of centos? If it is > similar enough to do all labs for rhel3 rhce that is my only concern. > www.centos.org CentOS is a rebuild of RHEL, so it is pretty similar :) -Jeff From jkeating at redhat.com Wed Nov 15 16:03:02 2006 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 15 Nov 2006 11:03:02 -0500 Subject: Important information regarding the merger of core and extras, and what this means to Legacy In-Reply-To: <200611151032.33591.gene.heskett@verizon.net> References: <200611142247.30110.jkeating@redhat.com> <200611151010.14026.jkeating@redhat.com> <200611151032.33591.gene.heskett@verizon.net> Message-ID: <200611151103.02882.jkeating@redhat.com> On Wednesday 15 November 2006 10:32, Gene Heskett wrote: > Theres several reasons, the old kernel version being one of them. Firewire > doesn't work that I know of, and I have a firewire movie camera. And when CentOS5 comes out? -- Jesse Keating Release Engineer: Fedora -------------- 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 redhat.com Wed Nov 15 16:16:01 2006 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 15 Nov 2006 11:16:01 -0500 Subject: Important information regarding the merger of core and extras, and what this means to Legacy In-Reply-To: <20061115154204.80489.qmail@web90503.mail.mud.yahoo.com> References: <20061115154204.80489.qmail@web90503.mail.mud.yahoo.com> Message-ID: <200611151116.01601.jkeating@redhat.com> On Wednesday 15 November 2006 10:42, Bill Perrotta wrote: > That is fine where can i download an iso of centos? If it is similar enough > to do all labs for rhel3 rhce that is my only concern. Centos.org -- Jesse Keating Release Engineer: Fedora -------------- 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 redhat.com Wed Nov 15 16:17:19 2006 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 15 Nov 2006 11:17:19 -0500 Subject: Important information regarding the merger of core and extras, and what this means to Legacy In-Reply-To: References: <200611142247.30110.jkeating@redhat.com> <200611150915.05105.jkeating@redhat.com> Message-ID: <200611151117.19252.jkeating@redhat.com> On Wednesday 15 November 2006 10:41, Jeff Sheltren wrote: > I like this idea, and I'd be happy to see official support for an FC > release last ~13 months. > > Of course, this would end all interest I have in Fedora Legacy, which > at this point is mostly to allow upgrading (well, re-installing in my > case) from FCN to FCN+2. So by having 13~ months you would be able to do FCN to FCN+2 > How much of this is just speculation at this point, and how close is > this to being actual policy? Depends on your feedback (: -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mattdm at mattdm.org Wed Nov 15 16:22:31 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 15 Nov 2006 11:22:31 -0500 Subject: Important information regarding the merger of core and extras, and what this means to Legacy In-Reply-To: <200611151010.14026.jkeating@redhat.com> References: <200611142247.30110.jkeating@redhat.com> <20061115142304.GA12538@jadzia.bu.edu> <200611150954.32735.gene.heskett@verizon.net> <200611151010.14026.jkeating@redhat.com> Message-ID: <20061115162231.GA18170@jadzia.bu.edu> On Wed, Nov 15, 2006 at 10:10:13AM -0500, Jesse Keating wrote: > So why don't you use CentOS which as a annual or every other year release? We use CentOS too. However, people a) want more cutting-edge and b) want Fedora. And if my group doesn't provide something that covers that demand, people will go off on their own, and then the security team will go back to being hugely overloaded with Linux break-ins. To expand on my earlier kvetching (sorry, no coffee yet): I'm not able to force anyone here to do anything. Therefore, I have to encourage good practice entirely via "carrots". This works best when we align with the academic year -- a release in the spring, current through the following summer to allow time for upgrades. Ideally, *two* years and a summer, but I understand that's not practical. As it is, what will happen is: whatever Fedora release is current as of June-July-August will get installed on people's systems, and, with goading, upgraded the next summer. If the actual Fedora release happens to be new in June-July, the 13-month plan will be great, but if the latest release was from, say, January, that leaves a big hole in which systems *will* get broken into. But, I find "If you need it to really work, use CentOS" to be a bad answer for Fedora. CentOS is great, but since it is by necessity in its own world, CentOS users don't feed back into the Fedora ecosystem in the same way, which is a big loss for Fedora. (With the new baby, I missed out on following the extras-for-RHEL discussion -- I need to check into how that's panning out, and how it fits with merging Extras and Core. The availability of Extras is currently a huge draw for Fedora over CentOS.) So, given the realities, we probably will end up shifting our main BU Linux efforts to Fedora, but may also provide a "BU Linux Extreme" Fedora spin. I'm not sure how best to fit this into our calendar. If we disregard that, we'll end up with insecure systems that just disregard *us*. Extending the lifespan from ~9 to ~13 months is a huge help, but to cover the gaps, we really need more like 18-19. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From mattdm at mattdm.org Wed Nov 15 16:27:55 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 15 Nov 2006 11:27:55 -0500 Subject: Important information regarding the merger of core and extras, and what this means to Legacy In-Reply-To: <200611151117.19252.jkeating@redhat.com> References: <200611142247.30110.jkeating@redhat.com> <200611150915.05105.jkeating@redhat.com> <200611151117.19252.jkeating@redhat.com> Message-ID: <20061115162755.GB18170@jadzia.bu.edu> On Wed, Nov 15, 2006 at 11:17:19AM -0500, Jesse Keating wrote: > > How much of this is just speculation at this point, and how close is > > this to being actual policy? > Depends on your feedback (: Don't get me wrong -- this is definitely a positive development. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From mattdm at mattdm.org Wed Nov 15 16:30:24 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 15 Nov 2006 11:30:24 -0500 Subject: Important information regarding the merger of core and extras, and what this means to Legacy In-Reply-To: <200611151103.02882.jkeating@redhat.com> References: <200611142247.30110.jkeating@redhat.com> <200611151010.14026.jkeating@redhat.com> <200611151032.33591.gene.heskett@verizon.net> <200611151103.02882.jkeating@redhat.com> Message-ID: <20061115163024.GC18170@jadzia.bu.edu> On Wed, Nov 15, 2006 at 11:03:02AM -0500, Jesse Keating wrote: > > Theres several reasons, the old kernel version being one of them. > And when CentOS5 comes out? Well, based on history, it'll be slightly behind-the-newest at release date (RHEL stabilization + a month or so for CentOS) but generally current enough, but then by this spring we'll see a batch of computers with hardware that doesn't work. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From sheltren at cs.ucsb.edu Wed Nov 15 16:40:16 2006 From: sheltren at cs.ucsb.edu (Jeff Sheltren) Date: Wed, 15 Nov 2006 12:40:16 -0400 Subject: Important information regarding the merger of core and extras, and what this means to Legacy In-Reply-To: <200611151117.19252.jkeating@redhat.com> References: <200611142247.30110.jkeating@redhat.com> <200611150915.05105.jkeating@redhat.com> <200611151117.19252.jkeating@redhat.com> Message-ID: <88415D74-BC58-4E14-8516-36668B59DF50@cs.ucsb.edu> On Nov 15, 2006, at 12:17 PM, Jesse Keating wrote: > On Wednesday 15 November 2006 10:41, Jeff Sheltren wrote: >> I like this idea, and I'd be happy to see official support for an FC >> release last ~13 months. >> >> Of course, this would end all interest I have in Fedora Legacy, which >> at this point is mostly to allow upgrading (well, re-installing in my >> case) from FCN to FCN+2. > > So by having 13~ months you would be able to do FCN to FCN+2 Yes, that's exactly what I'm saying - that's what I want to do, and having ~13 months of support would allow that to happen. > >> How much of this is just speculation at this point, and how close is >> this to being actual policy? > > Depends on your feedback (: I'm all for it. -Jeff From jkeating at redhat.com Wed Nov 15 16:43:10 2006 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 15 Nov 2006 11:43:10 -0500 Subject: Important information regarding the merger of core and extras, and what this means to Legacy In-Reply-To: <20061115163024.GC18170@jadzia.bu.edu> References: <200611142247.30110.jkeating@redhat.com> <200611151103.02882.jkeating@redhat.com> <20061115163024.GC18170@jadzia.bu.edu> Message-ID: <200611151143.13897.jkeating@redhat.com> On Wednesday 15 November 2006 11:30, Matthew Miller wrote: > Well, based on history, it'll be slightly behind-the-newest at release date > (RHEL stabilization + a month or so for CentOS) but generally current > enough, but then by this spring we'll see a batch of computers with > hardware that doesn't work. Isn't this where the quarterly updates with new hardware support come in? -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From sheltren at cs.ucsb.edu Wed Nov 15 16:45:16 2006 From: sheltren at cs.ucsb.edu (Jeff Sheltren) Date: Wed, 15 Nov 2006 12:45:16 -0400 Subject: Important information regarding the merger of core and extras, and what this means to Legacy In-Reply-To: <20061115162231.GA18170@jadzia.bu.edu> References: <200611142247.30110.jkeating@redhat.com> <20061115142304.GA12538@jadzia.bu.edu> <200611150954.32735.gene.heskett@verizon.net> <200611151010.14026.jkeating@redhat.com> <20061115162231.GA18170@jadzia.bu.edu> Message-ID: On Nov 15, 2006, at 12:22 PM, Matthew Miller wrote: > Extending the lifespan from ~9 to ~13 months is a huge help, but to > cover > the gaps, we really need more like 18-19. If Fedora decides to officially support releases for ~13 months, perhaps there is enough interest in extending them another 5-6 months to keep Legacy going? If my thinking is correct, that would leave legacy with 2 releases at a time, which *should* be manageable.. ;) -Jeff From mattdm at mattdm.org Wed Nov 15 16:48:53 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 15 Nov 2006 11:48:53 -0500 Subject: Important information regarding the merger of core and extras, and what this means to Legacy In-Reply-To: <200611151143.13897.jkeating@redhat.com> References: <200611142247.30110.jkeating@redhat.com> <200611151103.02882.jkeating@redhat.com> <20061115163024.GC18170@jadzia.bu.edu> <200611151143.13897.jkeating@redhat.com> Message-ID: <20061115164853.GA20460@jadzia.bu.edu> On Wed, Nov 15, 2006 at 11:43:10AM -0500, Jesse Keating wrote: > > Well, based on history, it'll be slightly behind-the-newest at release > > date (RHEL stabilization + a month or so for CentOS) but generally > > current enough, but then by this spring we'll see a batch of computers > > with hardware that doesn't work. > Isn't this where the quarterly updates with new hardware support come in? Is RHEL5 going to go wholesale to new kernel versions with the quarterly updates, or is it actually going to backport all updated drivers to the older release? -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From jkeating at redhat.com Wed Nov 15 16:49:13 2006 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 15 Nov 2006 11:49:13 -0500 Subject: Important information regarding the merger of core and extras, and what this means to Legacy In-Reply-To: References: <200611142247.30110.jkeating@redhat.com> <20061115162231.GA18170@jadzia.bu.edu> Message-ID: <200611151149.13597.jkeating@redhat.com> On Wednesday 15 November 2006 11:45, Jeff Sheltren wrote: > If Fedora decides to officially support releases for ~13 months, ? > perhaps there is enough interest in extending them another 5-6 months ? > to keep Legacy going? ?If my thinking is correct, that would leave ? > legacy with 2 releases at a time, which *should* be manageable.. This is what we're trying to do now, and not succeeding very well. Or were about to. I think there really needs to be significant interest in it, more than just Matt Miller, although he is a very interesting case. The majority of what we saw in the community was 'enough time to skip a release' and if we can provide that, the need for more is no where near as much. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mattdm at mattdm.org Wed Nov 15 16:50:13 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 15 Nov 2006 11:50:13 -0500 Subject: Important information regarding the merger of core and extras, and what this means to Legacy In-Reply-To: References: <200611142247.30110.jkeating@redhat.com> <20061115142304.GA12538@jadzia.bu.edu> <200611150954.32735.gene.heskett@verizon.net> <200611151010.14026.jkeating@redhat.com> <20061115162231.GA18170@jadzia.bu.edu> Message-ID: <20061115165013.GB20460@jadzia.bu.edu> On Wed, Nov 15, 2006 at 12:45:16PM -0400, Jeff Sheltren wrote: > If Fedora decides to officially support releases for ~13 months, > perhaps there is enough interest in extending them another 5-6 months > to keep Legacy going? If my thinking is correct, that would leave Perhaps, yeah. > legacy with 2 releases at a time, which *should* be manageable.. ;) Another possibility would be to pick either even- or odd-numbered fedora releases, and have Legacy only extend *one* of those. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From mattdm at mattdm.org Wed Nov 15 16:56:37 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 15 Nov 2006 11:56:37 -0500 Subject: Important information regarding the merger of core and extras, and what this means to Legacy In-Reply-To: <200611151149.13597.jkeating@redhat.com> References: <200611142247.30110.jkeating@redhat.com> <20061115162231.GA18170@jadzia.bu.edu> <200611151149.13597.jkeating@redhat.com> Message-ID: <20061115165637.GA21005@jadzia.bu.edu> On Wed, Nov 15, 2006 at 11:49:13AM -0500, Jesse Keating wrote: > about to. I think there really needs to be significant interest in it, more > than just Matt Miller, although he is a very interesting case. The majority Yeah, because frankly, I have a _lot_ more interest than time. It's, like, a 10:1 ratio. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From jkeating at redhat.com Wed Nov 15 16:58:02 2006 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 15 Nov 2006 11:58:02 -0500 Subject: Important information regarding the merger of core and extras, and what this means to Legacy In-Reply-To: <20061115164853.GA20460@jadzia.bu.edu> References: <200611142247.30110.jkeating@redhat.com> <200611151143.13897.jkeating@redhat.com> <20061115164853.GA20460@jadzia.bu.edu> Message-ID: <200611151158.02748.jkeating@redhat.com> On Wednesday 15 November 2006 11:48, Matthew Miller wrote: > Is RHEL5 going to go wholesale to new kernel versions with the quarterly > updates, or is it actually going to backport all updated drivers to the > older release? From what I gather out in the community (not looking at any internal documentation), that the new drivers would be backported. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rostetter at mail.utexas.edu Wed Nov 15 17:15:51 2006 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Wed, 15 Nov 2006 11:15:51 -0600 Subject: Important information regarding the merger of core and extras, and what this means to Legacy In-Reply-To: <20061115142304.GA12538@jadzia.bu.edu> References: <200611142247.30110.jkeating@redhat.com> <20061114220657.0je0ht9m8vwcgow8@mail.ph.utexas.edu> <20061115142304.GA12538@jadzia.bu.edu> Message-ID: <20061115111551.9q6u3qpa1l44gsss@mail.ph.utexas.edu> Quoting Matthew Miller : > On Tue, Nov 14, 2006 at 10:06:57PM -0600, Eric Rostetter wrote: >> First I would like to say to those who say Fedora Legacy has failed, that >> it _did_ work (i.e. didn't fail) for the most critical time period and the >> most critical OS version (RHL 7-9, FC1). If it has failed, or is failing, >> it must not be forgotten that before it failed it worked exceedingly well. > > Or at least moderately well. Let's not over-sell. :) I really think we did do incredibly well to start. We were often faster than others, and often had less bugs than others (e.g. Progeny, spelling?). We've only had two major problems with releases (one where a kernel install failed to update lilo correctly but worked with grub, and one where sendmail didn't work correctly on some older RHL upgrades). We did have to dump RHL 8 quickly, and later RHL 7.2, but we stayed strong for a couple of years on RHL 7.3 and RHL 9. And did a pretty darn good job on FC1 also IMHO. Now we don't have much demand for RHL any more, and we've failed pretty bad to get any timely updates out for FC 2 through FC 4, but that isn't the initial period I was talking about. That is the current situation, which I admit hasn't gone well... >> Second, I'm fairly comfortable with saying that if FC goes to a 13 month >> support cycle, FL is basically not needed anymore. IMHO, people can upgrade >> once a year when presented with a known/documented release cycle, and known >> documented alternatives. > > One month of annual overlap is still a bit short. _IF_ you want to use Fedora Core, you need to be willing to upgrade once a year. And the 13 month window gives you just this amount of time to upgrade. If you can't upgrade once a year, then you most certainly should not be using Fedora Core. My problem has always been I work in University settings where updates only happen during breaks (Spring break, Summer break, or Winter break). On the current Fedora Core schedule, a release can come at any time, and leave me unprotected (if not for FL) until the next University break comes along. With 13 months, I can easily stay with a release until the next break period when I can upgrade. I really don't see a problem with the 13 month support period, given Fedora Core's mission of being cutting edge. You can't be cutting edge, free/community-based, and support a release more than a year or so... -- Eric Rostetter The Department of Physics The University of Texas at Austin Go Longhorns! From kirk at k4ro.net Wed Nov 15 17:30:27 2006 From: kirk at k4ro.net (Kirk Pickering) Date: Wed, 15 Nov 2006 11:30:27 -0600 Subject: Upgrading FC releases via yum In-Reply-To: <455B27F7.6030802@beta.intcomgrp.com> References: <200611142247.30110.jkeating@redhat.com> <455B1AFE.2080905@beta.intcomgrp.com> <200611150915.05105.jkeating@redhat.com> <455B27F7.6030802@beta.intcomgrp.com> Message-ID: <20061115173027.GA27868@darkstar.k4ro.net> On Wed, Nov 15, 2006 at 09:45:11AM -0500, James Kosin wrote: > Hmmm..... maybe a better upgrade path would be in order. Allowing > users to keep their configuration; with minor changes and upgrade the > units to FC6->FC7->FC8 etc. without any troubles. I am trying the procedure at the link below right now on a FC4 laptop. It's a method to upgrade from FC4 to FC5 via yum. So far, it seems to be working well on a fairly clean FC4 installation. One nice aspect of doing it this way is that I only have to download 710MB of package updates, as opposed to 5 CD-ROMs stuffed with packages that I don't need. Has anyone on this list tried the following method? http://www.makuchaku.info/blog/how-to-upgrade-from-fc4-to-fc5-via-yum -Kirk From sundaram at fedoraproject.org Wed Nov 15 18:01:55 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 15 Nov 2006 23:31:55 +0530 Subject: Upgrading FC releases via yum In-Reply-To: <20061115173027.GA27868@darkstar.k4ro.net> References: <200611142247.30110.jkeating@redhat.com> <455B1AFE.2080905@beta.intcomgrp.com> <200611150915.05105.jkeating@redhat.com> <455B27F7.6030802@beta.intcomgrp.com> <20061115173027.GA27868@darkstar.k4ro.net> Message-ID: <455B5613.9060308@fedoraproject.org> Kirk Pickering wrote: > On Wed, Nov 15, 2006 at 09:45:11AM -0500, James Kosin wrote: >> Hmmm..... maybe a better upgrade path would be in order. Allowing >> users to keep their configuration; with minor changes and upgrade the >> units to FC6->FC7->FC8 etc. without any troubles. > > I am trying the procedure at the link below right now on a FC4 > laptop. It's a method to upgrade from FC4 to FC5 via yum. So far, > it seems to be working well on a fairly clean FC4 installation. > > One nice aspect of doing it this way is that I only have to > download 710MB of package updates, as opposed to 5 CD-ROMs > stuffed with packages that I don't need. > > Has anyone on this list tried the following method? > > http://www.makuchaku.info/blog/how-to-upgrade-from-fc4-to-fc5-via-yum The guy on the blog is my colleague. We do it all the time but it doesnt work well with random packages and repositories. When Fedora Core adopted the extras packaging guidelines a number of packages didnt have a proper upgrade path and I had to do some post upgrade manual clean up. It isnt yet good enough for me to recommend to new users. Rahul From mattdm at mattdm.org Wed Nov 15 18:21:44 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 15 Nov 2006 13:21:44 -0500 Subject: Important information regarding the merger of core and extras, and what this means to Legacy In-Reply-To: <200611151158.02748.jkeating@redhat.com> References: <200611142247.30110.jkeating@redhat.com> <200611151143.13897.jkeating@redhat.com> <20061115164853.GA20460@jadzia.bu.edu> <200611151158.02748.jkeating@redhat.com> Message-ID: <20061115182144.GA24846@jadzia.bu.edu> On Wed, Nov 15, 2006 at 11:58:02AM -0500, Jesse Keating wrote: > > Is RHEL5 going to go wholesale to new kernel versions with the quarterly > > updates, or is it actually going to backport all updated drivers to the > > older release? > From what I gather out in the community (not looking at any internal > documentation), that the new drivers would be backported. We'll have to see how this works out. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From michal at harddata.com Wed Nov 15 18:23:10 2006 From: michal at harddata.com (Michal Jaegermann) Date: Wed, 15 Nov 2006 11:23:10 -0700 Subject: Upgrading FC releases via yum In-Reply-To: <20061115173027.GA27868@darkstar.k4ro.net> References: <200611142247.30110.jkeating@redhat.com> <455B1AFE.2080905@beta.intcomgrp.com> <200611150915.05105.jkeating@redhat.com> <455B27F7.6030802@beta.intcomgrp.com> <20061115173027.GA27868@darkstar.k4ro.net> Message-ID: <20061115182310.GB15520@mail.harddata.com> On Wed, Nov 15, 2006 at 11:30:27AM -0600, Kirk Pickering wrote: > > Has anyone on this list tried the following method? > > http://www.makuchaku.info/blog/how-to-upgrade-from-fc4-to-fc5-via-yum You can do that but how easy/straightforward that be depends very much on what you got installed on a box and from where. I did something of that sort bringing a box from FC3 to FC5, and I finished with a working and correctly upgraded system; but this required some careful thinking and planning of stages, and in some moments the system was obviously broken but enough was working to make the progress possible. With a "bad move" somewhere you may get stuck. Not for a "general public" or faint in the heart. Looks to me that this is in "if you have to read instructions how to do that you better not try this at home" category. Sure, sometimes it will work even if you will just follow instructions. Michal From mattdm at mattdm.org Wed Nov 15 18:24:09 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 15 Nov 2006 13:24:09 -0500 Subject: Important information regarding the merger of core and extras, and what this means to Legacy In-Reply-To: <20061115111551.9q6u3qpa1l44gsss@mail.ph.utexas.edu> References: <200611142247.30110.jkeating@redhat.com> <20061114220657.0je0ht9m8vwcgow8@mail.ph.utexas.edu> <20061115142304.GA12538@jadzia.bu.edu> <20061115111551.9q6u3qpa1l44gsss@mail.ph.utexas.edu> Message-ID: <20061115182409.GB24846@jadzia.bu.edu> On Wed, Nov 15, 2006 at 11:15:51AM -0600, Eric Rostetter wrote: > My problem has always been I work in University settings where updates only > happen during breaks (Spring break, Summer break, or Winter break). On the Same here -- except I'm not sure I can rely on people to update during the spring and especially winter breaks, or that the 13th month hits the summer break in a convenient way. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From rostetter at mail.utexas.edu Wed Nov 15 19:25:44 2006 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Wed, 15 Nov 2006 13:25:44 -0600 Subject: Important information regarding the merger of core and extras, and what this means to Legacy In-Reply-To: <20061115182409.GB24846@jadzia.bu.edu> References: <200611142247.30110.jkeating@redhat.com> <20061114220657.0je0ht9m8vwcgow8@mail.ph.utexas.edu> <20061115142304.GA12538@jadzia.bu.edu> <20061115111551.9q6u3qpa1l44gsss@mail.ph.utexas.edu> <20061115182409.GB24846@jadzia.bu.edu> Message-ID: <20061115132544.sr2tnfa9m6o8sg88@mail.ph.utexas.edu> Quoting Matthew Miller : > On Wed, Nov 15, 2006 at 11:15:51AM -0600, Eric Rostetter wrote: >> My problem has always been I work in University settings where updates only >> happen during breaks (Spring break, Summer break, or Winter break). On the > > Same here -- except I'm not sure I can rely on people to update during the > spring and especially winter breaks, or that the 13th month hits the summer > break in a convenient way. I don't have to "rely on people to update during the spring and especially winter breaks" since I'm the only one who does the upgrades, and I can usually depend on myself. ;) Of course, this doesn't scale well... Fortunately I only have 80 machines to worry about, so it is no big deal. If I had to do this in such a short time period with say 200+ machines, then we'd have a problem... -- Eric Rostetter The Department of Physics The University of Texas at Austin Go Longhorns! From rostetter at mail.utexas.edu Wed Nov 15 19:31:58 2006 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Wed, 15 Nov 2006 13:31:58 -0600 Subject: Important information regarding the merger of core and extras, and what this means to Legacy In-Reply-To: <200611151103.02882.jkeating@redhat.com> References: <200611142247.30110.jkeating@redhat.com> <200611151010.14026.jkeating@redhat.com> <200611151032.33591.gene.heskett@verizon.net> <200611151103.02882.jkeating@redhat.com> Message-ID: <20061115133158.qcdwc0soijgkkgg4@mail.ph.utexas.edu> Quoting Jesse Keating : > On Wednesday 15 November 2006 10:32, Gene Heskett wrote: >> Theres several reasons, the old kernel version being one of them. Firewire >> doesn't work that I know of, and I have a firewire movie camera. I missed what this is about, but if it is about the CentOS/RHEL kernel, then simply install the unsupported kernel to get the firewire support. Works for me at least (with firewire removable disk drives). -- Eric Rostetter The Department of Physics The University of Texas at Austin Go Longhorns! From rostetter at mail.utexas.edu Wed Nov 15 20:00:47 2006 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Wed, 15 Nov 2006 14:00:47 -0600 Subject: Important information regarding the merger of core and extras, and what this means to Legacy In-Reply-To: <20061115162231.GA18170@jadzia.bu.edu> References: <200611142247.30110.jkeating@redhat.com> <20061115142304.GA12538@jadzia.bu.edu> <200611150954.32735.gene.heskett@verizon.net> <200611151010.14026.jkeating@redhat.com> <20061115162231.GA18170@jadzia.bu.edu> Message-ID: <20061115140047.rq0sjzdewnw8wo0k@mail.ph.utexas.edu> Quoting Matthew Miller : > I'm not able to force anyone here to do anything. Therefore, I have to That's the first problem... You either need to be able to force them to do the right thing, or punish them for failure. If you can't do one or the other of those then you're screwed, to put it bluntly. > encourage good practice entirely via "carrots". "sticks" work also. You get hacked, we unplug you from the network until you comply. Gets their attention real fast when they are removed from the network. Works better than carrots actually, in the long run. > This works best when we > align with the academic year -- a release in the spring, current through the > following summer to allow time for upgrades. Ideally, *two* years and a > summer, but I understand that's not practical. 13 months for two versions gives you a lot of time IMHO... > As it is, what will happen is: whatever Fedora release is current as of > June-July-August will get installed on people's systems, and, with goading, > upgraded the next summer. Upgraded in the summer, whether the summer of the same or next year, and the problem is solved for 99% of the cases... Only way that fails is if you install early in the year (from January to April) and the next release is done right after school (fall) starts that year... In which case, that will hopefully be a small number of machines which you can knock off during winter or spring break, leaving the majority until the summer. The draw back of the above of course is you need to track all the machines, their versions, and installation dates, and keep that data updated. Basically you need a good DB of the machine information... > If the actual Fedora release happens to be new in > June-July, the 13-month plan will be great, but if the latest release was > from, say, January, that leaves a big hole in which systems *will* get > broken into. If you install in January, then just upgrade in the summer if a new release is out by then. See above for the rest of the details. I suppose there could be a small hole, which is why most release cycles are 1.5 years instead of 1.08 years... But your call for 2.5 years seems way too long for a project that wants to be cutting edge (and which you point out your users want because it is cutting edge. If they want cutting edge, they need to upgrade once a year, or else they are not cutting edge anymore). > panning out, and how it fits with merging Extras and Core. The availability > of Extras is currently a huge draw for Fedora over CentOS.) CentOS has Extras/Plus also for a lot of packages... And there are lots of other packagers making "extras like" repositories out there... For the "desktop" user this should be more than sufficient. It may of course violate "server" or "production" users who have QA issues with that type of thing. In fact, one advantage of RHEL over FC/CentOS/anything-completely-opensource is it actually comes with non-opensource software that is commonly desired, and which is kept updated for security problems... > Extending the lifespan from ~9 to ~13 months is a huge help, but to cover > the gaps, we really need more like 18-19. I really disagree. The project is to be cutting edge, your users want cutting edge, the only way to do that is to upgrade yearly. Otherwise, both the project and your users are not cutting edge. If you can't manage the upgrades in a year, then you need to hire more staff locally (or better automate your upgrades). Now, I really do feel for you and your situation. But I don't think you can impose your bad situation on the Fedora Project, when you claim your users really do want the same thing as Fedora Project, which means you really do need to upgrade yearly, and not every 2.5 years. Fedora Legacy is doing your users a disservice IMHO by not allowing them to be cutting edge as they want to be. In your case, I would think the only way to meet your needs would be with Fedora Legacy, as Fedora Core just can't do 2.5 years of support and meet its mission. But I'm not sure there are enough people in such a unique situation, and who are so fixated on Fedora Core over other distributions, to sustain something like Fedora Legacy. Of course, I could be completely wrong... :) -- Eric Rostetter The Department of Physics The University of Texas at Austin Go Longhorns! From mattdm at mattdm.org Wed Nov 15 20:34:17 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 15 Nov 2006 15:34:17 -0500 Subject: Important information regarding the merger of core and extras, and what this means to Legacy In-Reply-To: <20061115140047.rq0sjzdewnw8wo0k@mail.ph.utexas.edu> References: <200611142247.30110.jkeating@redhat.com> <20061115142304.GA12538@jadzia.bu.edu> <200611150954.32735.gene.heskett@verizon.net> <200611151010.14026.jkeating@redhat.com> <20061115162231.GA18170@jadzia.bu.edu> <20061115140047.rq0sjzdewnw8wo0k@mail.ph.utexas.edu> Message-ID: <20061115203417.GA32666@jadzia.bu.edu> On Wed, Nov 15, 2006 at 02:00:47PM -0600, Eric Rostetter wrote: > >I'm not able to force anyone here to do anything. Therefore, I have to > That's the first problem... You either need to be able to force them > to do the right thing, or punish them for failure. If you can't do one > or the other of those then you're screwed, to put it bluntly. Well, we're screwed, then. :) > "sticks" work also. You get hacked, we unplug you from the network until > you comply. Gets their attention real fast when they are removed from > the network. Works better than carrots actually, in the long run. Oh, we do that if it comes to that. However, the goal is to avoid that in the first place. [...] > 1.08 years... But your call for 2.5 years seems way too long for a project > that wants to be cutting edge (and which you point out your users want > because it is cutting edge. If they want cutting edge, they need to upgrade > once a year, or else they are not cutting edge anymore). Well, as I said, 2.5 years would be ideal, but I recognize it to be not really obtainable. I really would like, however, to see 1.5, or better, 1.6. > >panning out, and how it fits with merging Extras and Core. The availability > >of Extras is currently a huge draw for Fedora over CentOS.) > CentOS has Extras/Plus also for a lot of packages... And there are lots of Nothing like Fedora Extras, though. And third-party repos can be helpful but coordinating them is work, and each requires a layer of maintenance of its own. [...] > I really disagree. The project is to be cutting edge, your users want > cutting edge, the only way to do that is to upgrade yearly. Otherwise, Oh yes. In short, users want cake and they want to shoot themseves in the foot with it. > both the project and your users are not cutting edge. If you can't > manage the upgrades in a year, then you need to hire more staff locally Yes, it'd be great to be able to convince everyone I support to hire more staff. That ain't going to happen. > (or better automate your upgrades). There's significant engineer resistance to working towards making Fedora yum-upgradable between releases. So that's really a non-starter. > Now, I really do feel for you and your situation. But I don't think you > can impose your bad situation on the Fedora Project, when you claim your Clearly I'm in no position to impose anything. However, it'd certainly be helpful to us if Legacy could contine to extend the lifespan beyond the new proposed 13 months. And I mention it in case I'm not alone. [*] * In fact, I'm pretty certain I'm not, and that there are thousands of users running FC1, FC2, and FC3 and just waiting to become botnet members if they're not already. The difference is that my users have me to care about them. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From jkeating at redhat.com Wed Nov 15 20:43:43 2006 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 15 Nov 2006 15:43:43 -0500 Subject: Important information regarding the merger of core and extras, and what this means to Legacy In-Reply-To: <20061115203417.GA32666@jadzia.bu.edu> References: <200611142247.30110.jkeating@redhat.com> <20061115140047.rq0sjzdewnw8wo0k@mail.ph.utexas.edu> <20061115203417.GA32666@jadzia.bu.edu> Message-ID: <200611151543.43644.jkeating@redhat.com> On Wednesday 15 November 2006 15:34, Matthew Miller wrote: > Clearly I'm in no position to impose anything. However, it'd certainly be > helpful to us if Legacy could contine to extend the lifespan beyond the new > proposed 13 months. And I mention it in case I'm not alone. [*] > > > > > * In fact, I'm pretty certain I'm not, and that there are thousands of > users running FC1, FC2, and FC3 and just waiting to become botnet members > if they're not already. The difference is that my users have me to care > about them. But is there enough "you" to go around to do the updates? That's the real question here. We can't stop people from being dumb and not upgrading their release when it goes dead. If we gave them 2 years, they'd take it and still not upgrade and then what? I think the Fedora project is really trying to reach a reasonable amount of time that it can throw its entire support behind. The Legacy folks of past and present are totally awesome, and we could really use their knowledge and eagerness to help in perhaps more productive fashions. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rostetter at mail.utexas.edu Wed Nov 15 20:53:47 2006 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Wed, 15 Nov 2006 14:53:47 -0600 Subject: Important information regarding the merger of core and extras, and what this means to Legacy In-Reply-To: <20061115203417.GA32666@jadzia.bu.edu> References: <200611142247.30110.jkeating@redhat.com> <20061115142304.GA12538@jadzia.bu.edu> <200611150954.32735.gene.heskett@verizon.net> <200611151010.14026.jkeating@redhat.com> <20061115162231.GA18170@jadzia.bu.edu> <20061115140047.rq0sjzdewnw8wo0k@mail.ph.utexas.edu> <20061115203417.GA32666@jadzia.bu.edu> Message-ID: <20061115145347.k6sgledd8qw4ogwg@mail.ph.utexas.edu> Quoting Matthew Miller : > * In fact, I'm pretty certain I'm not, and that there are thousands of users > running FC1, FC2, and FC3 and just waiting to become botnet members if > they're not already. The difference is that my users have me to care about > them. Well, I agree there are _at least_ thousands of users running FC1-3 waiting to be botnet members. And most of them neither know about Fedora Legacy nor have someone like you to care about them, so extending support via FL won't help the majority of them... Sad, but no doubt true... That doesn't mean FL shouldn't exist. Even if we can only stop a small percentage from being hacked, that is still a very worthy goal which will have positive effects on the internet/world. However, if you can find a sufficient number of those who do know (or will learn) about FL, or who have people like you who will care for them, and can get them to support FL is some way, then there would be no problem keeping FL alive to do so. But there has to be a certain level of support, and I really don't see that happening myself. Again, I could be wrong... The reason there was so much RHL 7/9 and FC 1 support was Red Hat really dropped us with almost no advanced notice. We were aleady on the Red Hat gravy train and the rug was yanked out from under us, and we had little choice. I don't consider people installing Fedora Core 3/4/5/6 to be in that same boat: they should know what they are getting into, and should have a plan that meets their needs for the future. As such, there are not so many people dependent on FC 3/4/5/6 and hence less people willing to do the hard work for it. Basically, FL was a _need_ for some of us at the start, but it isn't a need for most people now. There are easy alternatives now that didn't exist back when RHL was dropped and FC was started. Anyway, I'm going to try to stop participating in this thread after this message. I think I've said more than I should have already... I'd be more than happy to see FL survive. I'd even be willing to help out some. But it is no longer something I need, just something that gives me a warm, fuzzy feeling... -- Eric Rostetter The Department of Physics The University of Texas at Austin Go Longhorns! From mattdm at mattdm.org Wed Nov 15 21:05:49 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 15 Nov 2006 16:05:49 -0500 Subject: Important information regarding the merger of core and extras, and what this means to Legacy In-Reply-To: <200611151543.43644.jkeating@redhat.com> References: <200611142247.30110.jkeating@redhat.com> <20061115140047.rq0sjzdewnw8wo0k@mail.ph.utexas.edu> <20061115203417.GA32666@jadzia.bu.edu> <200611151543.43644.jkeating@redhat.com> Message-ID: <20061115210549.GA2307@jadzia.bu.edu> On Wed, Nov 15, 2006 at 03:43:43PM -0500, Jesse Keating wrote: > But is there enough "you" to go around to do the updates? That's the real Speaking for me personally, no. :) > question here. We can't stop people from being dumb and not upgrading their > release when it goes dead. If we gave them 2 years, they'd take it and still > not upgrade and then what? I think the Fedora project is really trying to Oh, that's for sure -- I routinely see incredibly ancient RHL machines still in production. However, there's a curve, and the shorter the lifespan the more people will be caught in it. At the current 9 months, I wouldn't be surprised if it actually includes the majority of users. At 13 months, not so bad -- but still a huge amount. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From gene.heskett at verizon.net Wed Nov 15 21:33:05 2006 From: gene.heskett at verizon.net (Gene Heskett) Date: Wed, 15 Nov 2006 16:33:05 -0500 Subject: Important information regarding the merger of core and extras, and what this means to Legacy In-Reply-To: <200611151103.02882.jkeating@redhat.com> References: <200611142247.30110.jkeating@redhat.com> <200611151032.33591.gene.heskett@verizon.net> <200611151103.02882.jkeating@redhat.com> Message-ID: <200611151633.05115.gene.heskett@verizon.net> On Wednesday 15 November 2006 11:03, Jesse Keating wrote: >On Wednesday 15 November 2006 10:32, Gene Heskett wrote: >> Theres several reasons, the old kernel version being one of them. >> Firewire doesn't work that I know of, and I have a firewire movie >> camera. > >And when CentOS5 comes out? I've no idea when, or if firewire is back among the living. It took till the last new kernel for FC5 before it worked well enough to be usable. Where does that place centos5 then? -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2006 by Maurice Eugene Heskett, all rights reserved. From jkeating at redhat.com Wed Nov 15 21:36:28 2006 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 15 Nov 2006 16:36:28 -0500 Subject: Important information regarding the merger of core and extras, and what this means to Legacy In-Reply-To: <200611151633.05115.gene.heskett@verizon.net> References: <200611142247.30110.jkeating@redhat.com> <200611151103.02882.jkeating@redhat.com> <200611151633.05115.gene.heskett@verizon.net> Message-ID: <200611151636.28720.jkeating@redhat.com> On Wednesday 15 November 2006 16:33, Gene Heskett wrote: > I've no idea when, or if firewire is back among the living. ?It took till > the last new kernel for FC5 before it worked well enough to be usable. ? > Where does that place centos5 then? RHEL5 kernel is largely based on the FC6 kernel. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From gene.heskett at verizon.net Wed Nov 15 23:31:10 2006 From: gene.heskett at verizon.net (Gene Heskett) Date: Wed, 15 Nov 2006 18:31:10 -0500 Subject: Important information regarding the merger of core and extras, and what this means to Legacy In-Reply-To: <200611151636.28720.jkeating@redhat.com> References: <200611142247.30110.jkeating@redhat.com> <200611151633.05115.gene.heskett@verizon.net> <200611151636.28720.jkeating@redhat.com> Message-ID: <200611151831.10962.gene.heskett@verizon.net> On Wednesday 15 November 2006 16:36, Jesse Keating wrote: >On Wednesday 15 November 2006 16:33, Gene Heskett wrote: >> I've no idea when, or if firewire is back among the living. ?It took >> till the last new kernel for FC5 before it worked well enough to be >> usable. Where does that place centos5 then? > >RHEL5 kernel is largely based on the FC6 kernel. Which isn't at all stable. Old kino, before a 1394 re-write was started about 18 months ago now, was bulletproof and worked just fine on this exact same hardware. It was very stable when controlling my camera. Now, the two versions compatible with the later libraries etc are both so unstable, doing segfault exits so quickly that the only chance I have of using it is with the last FC5 kernel, running on my lappy. Either 8.0, 0.9.2 or 0.9.3 take a segfault exit, stage right, on about the second mouse click, or even the first on this machine with the latest non-xen kernel(s). I don't think this is kino's fault, particularly since Dan is unable to duplicate it on whatever system(s) he is using. -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2006 by Maurice Eugene Heskett, all rights reserved. From nils at lemonbit.nl Thu Nov 16 03:40:57 2006 From: nils at lemonbit.nl (Nils Breunese (Lemonbit)) Date: Wed, 15 Nov 2006 22:40:57 -0500 Subject: Important information regarding the merger of core and extras, and what this means to Legacy In-Reply-To: <20061115162231.GA18170@jadzia.bu.edu> References: <200611142247.30110.jkeating@redhat.com> <20061115142304.GA12538@jadzia.bu.edu> <200611150954.32735.gene.heskett@verizon.net> <200611151010.14026.jkeating@redhat.com> <20061115162231.GA18170@jadzia.bu.edu> Message-ID: <9FF4598F-4B23-4A32-BF22-78BAB51CA62C@lemonbit.nl> Matthew Miller wrote: > I'm not able to force anyone here to do anything. Therefore, I have to > encourage good practice entirely via "carrots". This works best > when we > align with the academic year -- a release in the spring, current > through the > following summer to allow time for upgrades. Ideally, *two* years > and a > summer, but I understand that's not practical. > > As it is, what will happen is: whatever Fedora release is current > as of > June-July-August will get installed on people's systems, and, with > goading, > upgraded the next summer. If the actual Fedora release happens to > be new in > June-July, the 13-month plan will be great, but if the latest > release was > from, say, January, that leaves a big hole in which systems *will* get > broken into. Every system needs an admin. I don't think it's realistic to not run 'yum update' for a year and expect everything to be fine. If you'd run Windows on those systems you'd have to run Windows Update once in a while. Now, I know Linux is less likely to get hacked very fast, but like I said: every system needs an admin. If systems don't have a proper admin, *then* they'll get hacked. This is not a Fedora- specific issue. Nils Breunese. From nils at lemonbit.nl Thu Nov 16 03:40:57 2006 From: nils at lemonbit.nl (Nils Breunese (Lemonbit)) Date: Wed, 15 Nov 2006 22:40:57 -0500 Subject: Important information regarding the merger of core and extras, and what this means to Legacy In-Reply-To: <20061115162231.GA18170@jadzia.bu.edu> References: <200611142247.30110.jkeating@redhat.com> <20061115142304.GA12538@jadzia.bu.edu> <200611150954.32735.gene.heskett@verizon.net> <200611151010.14026.jkeating@redhat.com> <20061115162231.GA18170@jadzia.bu.edu> Message-ID: <9FF4598F-4B23-4A32-BF22-78BAB51CA62C@lemonbit.nl> Matthew Miller wrote: > I'm not able to force anyone here to do anything. Therefore, I have to > encourage good practice entirely via "carrots". This works best > when we > align with the academic year -- a release in the spring, current > through the > following summer to allow time for upgrades. Ideally, *two* years > and a > summer, but I understand that's not practical. > > As it is, what will happen is: whatever Fedora release is current > as of > June-July-August will get installed on people's systems, and, with > goading, > upgraded the next summer. If the actual Fedora release happens to > be new in > June-July, the 13-month plan will be great, but if the latest > release was > from, say, January, that leaves a big hole in which systems *will* get > broken into. Every system needs an admin. I don't think it's realistic to not run 'yum update' for a year and expect everything to be fine. If you'd run Windows on those systems you'd have to run Windows Update once in a while. Now, I know Linux is less likely to get hacked very fast, but like I said: every system needs an admin. If systems don't have a proper admin, *then* they'll get hacked. This is not a Fedora- specific issue. Nils Breunese. From ssrat at mailbag.com Wed Nov 15 14:25:29 2006 From: ssrat at mailbag.com (David Douthitt) Date: Wed, 15 Nov 2006 08:25:29 -0600 Subject: RHEL3: Problem going from RH 2.4.20 to Linus 2.4.33 Message-ID: <455B2359.4030601@mailbag.com> I compiled a version of Linus' kernel 2.4.33 for CentOS 3 (RHEL 3) and found that several programs started failing with core dumps or lockups. It seems to center on two different things: the clone() call, and some kind of file locking call that isn't supported ("fuserlock"?) The clone() call resulted in core dumps; the other resulted in programs receiving an unexpected "not implemented" result and entering an endless loop waiting for a positive result. Any tips? I'd like to keep the kernel current.... From nils at lemonbit.nl Thu Nov 16 06:19:44 2006 From: nils at lemonbit.nl (Nils Breunese (Lemonbit)) Date: Thu, 16 Nov 2006 01:19:44 -0500 Subject: [SPAM] HIGH * Re: RHEL3: Problem going from RH 2.4.20 to Linus 2.4.33 In-Reply-To: <455B2359.4030601@mailbag.com> References: <455B2359.4030601@mailbag.com> Message-ID: David Douthitt wrote: > I compiled a version of Linus' kernel 2.4.33 for CentOS 3 (RHEL 3) > and found that several programs started failing with core dumps or > lockups. > > It seems to center on two different things: the clone() call, and > some kind of file locking call that isn't supported ("fuserlock"?) > > The clone() call resulted in core dumps; the other resulted in > programs receiving an unexpected "not implemented" result and > entering an endless loop waiting for a positive result. > > Any tips? I'd like to keep the kernel current.... CentOS 3 is still maintained, so why not just use yum to get the latest CentOS 3 kernel? Or do you specifically need features from the latest 2.4 kernel version? And most importantly: why are you posting this to the Fedora Legacy list? CentOS has forums, mailinglists, etc. Nils Breunese. From lizard_king825 at yahoo.com Thu Nov 16 06:23:27 2006 From: lizard_king825 at yahoo.com (Lizard King825) Date: Wed, 15 Nov 2006 22:23:27 -0800 (PST) Subject: Self Introduction Message-ID: <20061116062327.66969.qmail@web38515.mail.mud.yahoo.com> Self-Introduction: Dana E Hoffman Jr Full legal name Dana E Hoffman Jr Location (Country, City, etc) Usa, West Chazy, Ny , 12992 Profession or Student status Disabled & part time self empolyed Company or School Extreme Computers Your goals in the Fedora Legacy Project I want to be a part of helping fedora project, I have time and I am willing to learn Which OS versions are you interested in? fedora 3,4,5,6, etc... Do you want to do QA for packages? If I can learn it I will. * Anything else special? I am willing to learn and help as much as I can possible for the fedora project If I get stuck I like to do my research and ask around, this is one really nice thing about fedora is it a friendly people o/s I think. What other projects have you worked on in the past? This will be my first project :) What computer languages and other skills do you know? I dont have know computer languages Why should we trust you? I want to help the community with this project, I will be loyal and honest at all times. I will be proud to be part of the fedora project. Be sure that your GPG key is uploaded to pgp.mit.edu. Use "gpg --keyserver pgp.mit.edu --send-key KEYID". done gpg --fingerprint 2C3A3E42 pub 1024D/2C3A3E42 2006-11-16 Key fingerprint = 3C07 CCC8 9E75 900A 0C16 44C6 648F 5940 2C3A 3E42 uid Dana E Hoffman Jr sub 2048g/C87D953D 2006-11-16 thank you Dana --------------------------------- Sponsored Link Mortgage rates as low as 4.625% - $150,000 loan for $579 a month. Intro-*Terms -------------- next part -------------- An HTML attachment was scrubbed... URL: From sheltren at cs.ucsb.edu Thu Nov 16 12:48:16 2006 From: sheltren at cs.ucsb.edu (Jeff Sheltren) Date: Thu, 16 Nov 2006 08:48:16 -0400 Subject: Self Introduction In-Reply-To: <20061116062327.66969.qmail@web38515.mail.mud.yahoo.com> References: <20061116062327.66969.qmail@web38515.mail.mud.yahoo.com> Message-ID: Hi Dana, and welcome! We could definitely use some help with QA at the moment. Please check out http://fedoraproject.org/wiki/Legacy/ QATesting for more info on how it all works. You can see a list of current bugs here: http://www.netcore.fi/pekkas/buglist.html or just search for Legacy bugs at bugzilla.redhat.com for the most current list. -Jeff On Nov 16, 2006, at 2:23 AM, Lizard King825 wrote: > Self-Introduction: > Dana E Hoffman Jr > > Full legal name > Dana E Hoffman Jr > > Location (Country, City, etc) > Usa, West Chazy, Ny , 12992 > > Profession or Student status > Disabled & part time self empolyed > > Company or School > Extreme Computers > > Your goals in the Fedora Legacy Project > I want to be a part of helping fedora project, I have time and I am > willing to learn > > Which OS versions are you interested in? > fedora 3,4,5,6, etc... > > Do you want to do QA for packages? > If I can learn it I will. * > > Anything else special? > I am willing to learn and help as much as I can possible for the > fedora project > If I get stuck I like to do my research and ask around, this is one > really nice thing about > fedora is it a friendly people o/s I think. > > What other projects have you worked on in the past? > This will be my first project :) > > What computer languages and other skills do you know? > I dont have know computer languages > > Why should we trust you? > I want to help the community with this project, I will be loyal and > honest at all times. > I will be proud to be part of the fedora project. > > Be sure that your GPG key is uploaded to pgp.mit.edu. Use "gpg -- > keyserver pgp.mit.edu --send-key KEYID". > done > > gpg --fingerprint 2C3A3E42 > pub 1024D/2C3A3E42 2006-11-16 > Key fingerprint = 3C07 CCC8 9E75 900A 0C16 44C6 648F 5940 > 2C3A 3E42 > uid Dana E Hoffman Jr > sub 2048g/C87D953D 2006-11-16 > > > thank you > Dana > Sponsored Link > > Mortgage rates as low as 4.625% - $150,000 loan for $579 a month. > Intro-*Terms > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-legacy-list From Mike.McCarty at sbcglobal.net Thu Nov 16 13:48:21 2006 From: Mike.McCarty at sbcglobal.net (Mike McCarty) Date: Thu, 16 Nov 2006 07:48:21 -0600 Subject: Important information regarding the merger of core and extras, and what this means to Legacy In-Reply-To: <200611150954.32735.gene.heskett@verizon.net> References: <200611142247.30110.jkeating@redhat.com> <20061114220657.0je0ht9m8vwcgow8@mail.ph.utexas.edu> <20061115142304.GA12538@jadzia.bu.edu> <200611150954.32735.gene.heskett@verizon.net> Message-ID: <455C6C25.6080307@sbcglobal.net> Gene Heskett wrote: > > I can't help but agree that its too short. 3 or 6 would be much more > realistic from the users viewpoint, who has his setup all fine tuned and > doesn't want to go thru that on an annual basis. There are other things > to life you know. Yeah, like repairing vintage tube radios! Mike -- p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);} This message made from 100% recycled bits. You have found the bank of Larn. I can explain it for you, but I can't understand it for you. I speak only for myself, and I am unanimous in that! From martin at bugs.unl.edu.ar Thu Nov 16 14:04:39 2006 From: martin at bugs.unl.edu.ar (Martin Marques) Date: Thu, 16 Nov 2006 11:04:39 -0300 (ART) Subject: Mailman vulnerability In-Reply-To: <455AB8C6.4000702@gtw.net> References: <20061005161245.GB17040@mail.harddata.com> <200611080719.11376.jkeating@redhat.com> <455AB8C6.4000702@gtw.net> Message-ID: On Wed, 15 Nov 2006, David Eisenstein wrote: > Thanks a bunch, Martin! :) Info on your source package has been placed > into Bugzilla #209891 , and hopefully we'll soon > have this QA'ed and published in the Legacy repositories! > > We still need work on the FC3 version of this package: > mailman-2.1.5-32.fc3.src.rpm > in Bugzilla #211676. Try this for FC3: http://bugs.unl.edu.ar/~martin/mailman-2.1.5-33.fc3.legacy.src.rpm All I did was add the 2 patches from RHEL. Check it out. -- 21:50:04 up 2 days, 9:07, 0 users, load average: 0.92, 0.37, 0.18 --------------------------------------------------------- Lic. Mart?n Marqu?s | SELECT 'mmarques' || Centro de Telem?tica | '@' || 'unl.edu.ar'; Universidad Nacional | DBA, Programador, del Litoral | Administrador --------------------------------------------------------- From mattdm at mattdm.org Thu Nov 16 15:30:22 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 16 Nov 2006 10:30:22 -0500 Subject: Important information regarding the merger of core and extras, and what this means to Legacy In-Reply-To: <9FF4598F-4B23-4A32-BF22-78BAB51CA62C@lemonbit.nl> References: <200611142247.30110.jkeating@redhat.com> <20061115142304.GA12538@jadzia.bu.edu> <200611150954.32735.gene.heskett@verizon.net> <200611151010.14026.jkeating@redhat.com> <20061115162231.GA18170@jadzia.bu.edu> <9FF4598F-4B23-4A32-BF22-78BAB51CA62C@lemonbit.nl> Message-ID: <20061116153022.GA11936@jadzia.bu.edu> On Wed, Nov 15, 2006 at 10:40:57PM -0500, Nils Breunese wrote: > Every system needs an admin. I don't think it's realistic to not run > 'yum update' for a year and expect everything to be fine. If you'd If there's no updates available, it doesn't matter how often they run yum update. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From nils at lemonbit.nl Thu Nov 16 15:39:12 2006 From: nils at lemonbit.nl (Nils Breunese (Lemonbit)) Date: Thu, 16 Nov 2006 10:39:12 -0500 Subject: Important information regarding the merger of core and extras, and what this means to Legacy In-Reply-To: <20061116153022.GA11936@jadzia.bu.edu> References: <200611142247.30110.jkeating@redhat.com> <20061115142304.GA12538@jadzia.bu.edu> <200611150954.32735.gene.heskett@verizon.net> <200611151010.14026.jkeating@redhat.com> <20061115162231.GA18170@jadzia.bu.edu> <9FF4598F-4B23-4A32-BF22-78BAB51CA62C@lemonbit.nl> <20061116153022.GA11936@jadzia.bu.edu> Message-ID: <1EDE8EFD-B4E5-4A53-BA95-52961AD43E62@lemonbit.nl> Matthew Miller wrote: > On Wed, Nov 15, 2006 at 10:40:57PM -0500, Nils Breunese wrote: >> Every system needs an admin. I don't think it's realistic to not run >> 'yum update' for a year and expect everything to be fine. If you'd > > If there's no updates available, it doesn't matter how often they > run yum > update. That's why every system needs an admin (and not a nightly yum cron job). A real admin will know or notice there are no updates available and take appropriate action. Nils Breunese. From smooge at gmail.com Thu Nov 16 15:58:56 2006 From: smooge at gmail.com (Stephen John Smoogen) Date: Thu, 16 Nov 2006 08:58:56 -0700 Subject: RHEL3: Problem going from RH 2.4.20 to Linus 2.4.33 In-Reply-To: <455B2359.4030601@mailbag.com> References: <455B2359.4030601@mailbag.com> Message-ID: <80d7e4090611160758u33a79c55v4d69ac77fb05c074@mail.gmail.com> On 11/15/06, David Douthitt wrote: > I compiled a version of Linus' kernel 2.4.33 for CentOS 3 (RHEL 3) and > found that several programs started failing with core dumps or lockups. > You can not use 2.4.33 on Centos 3 or RHL 9 systems. The base kernel for RHL-9 and RHEL-3/Centos-3 have several incompatible sections backported from the 2.5.xx kernel series to give features that were wanted but not in the 2.4 kernel. Thus you can not have the most current 2.4.xx kernel. If you are wanting to do that you will be wanting a different OS than any of the 'Enterprise' systems. > It seems to center on two different things: the clone() call, and some > kind of file locking call that isn't supported ("fuserlock"?) > > The clone() call resulted in core dumps; the other resulted in > programs receiving an unexpected "not implemented" result and entering > an endless loop waiting for a positive result. > > Any tips? I'd like to keep the kernel current.... > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-legacy-list > -- Stephen J Smoogen. -- CSIRT/Linux System Administrator How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From mattdm at mattdm.org Thu Nov 16 18:53:05 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 16 Nov 2006 13:53:05 -0500 Subject: Important information regarding the merger of core and extras, and what this means to Legacy In-Reply-To: <1EDE8EFD-B4E5-4A53-BA95-52961AD43E62@lemonbit.nl> References: <200611142247.30110.jkeating@redhat.com> <20061115142304.GA12538@jadzia.bu.edu> <200611150954.32735.gene.heskett@verizon.net> <200611151010.14026.jkeating@redhat.com> <20061115162231.GA18170@jadzia.bu.edu> <9FF4598F-4B23-4A32-BF22-78BAB51CA62C@lemonbit.nl> <20061116153022.GA11936@jadzia.bu.edu> <1EDE8EFD-B4E5-4A53-BA95-52961AD43E62@lemonbit.nl> Message-ID: <20061116185305.GA20609@jadzia.bu.edu> On Thu, Nov 16, 2006 at 10:39:12AM -0500, Nils Breunese (Lemonbit) wrote: > That's why every system needs an admin (and not a nightly yum cron > job). A real admin will know or notice there are no updates available > and take appropriate action. Preaching to the choir. However, there's reality for you. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From gene.heskett at verizon.net Thu Nov 16 19:29:35 2006 From: gene.heskett at verizon.net (Gene Heskett) Date: Thu, 16 Nov 2006 14:29:35 -0500 Subject: Important information regarding the merger of core and extras, and what this means to Legacy In-Reply-To: <455C6C25.6080307@sbcglobal.net> References: <200611142247.30110.jkeating@redhat.com> <200611150954.32735.gene.heskett@verizon.net> <455C6C25.6080307@sbcglobal.net> Message-ID: <200611161429.35831.gene.heskett@verizon.net> On Thursday 16 November 2006 08:48, Mike McCarty wrote: >Gene Heskett wrote: >> I can't help but agree that its too short. 3 or 6 would be much more >> realistic from the users viewpoint, who has his setup all fine tuned >> and doesn't want to go thru that on an annual basis. There are other >> things to life you know. > >Yeah, like repairing vintage tube radios! > Chuckle, how close to right was I? >Mike -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2006 by Maurice Eugene Heskett, all rights reserved. From rlavoie at ncsoft.com Fri Nov 17 16:49:28 2006 From: rlavoie at ncsoft.com (Russ Lavoie) Date: Fri, 17 Nov 2006 10:49:28 -0600 Subject: Openssl updates Message-ID: <88166C23A9B8784C9C54619E6E5037505E9A83@NCUSPOSTAL01.ncaustin.com> I have noticed that Openssl has not been updated for FC4 even though there is a security vulnerability. http://www.openssl.org/news/secadv_20060928.txt The most current version I can find for FC4 is 0.9.7l Where can I find this new rpm? Russ -------------- next part -------------- An HTML attachment was scrubbed... URL: From donjr at maner.org Fri Nov 17 17:00:13 2006 From: donjr at maner.org (Donald Maner) Date: Fri, 17 Nov 2006 11:00:13 -0600 Subject: Openssl updates References: <88166C23A9B8784C9C54619E6E5037505E9A83@NCUSPOSTAL01.ncaustin.com> Message-ID: <4A5DA14CF063A54C9DB0C98CCE35B3737706@selket.home.maner.org> New RPMs are in the QA process right now. You're welcome to download the SRPM that has been created for FC4, compile it, test it, and report on your test. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=209116 ________________________________ From: fedora-legacy-list-bounces at redhat.com on behalf of Russ Lavoie Sent: Fri 11/17/2006 10:49 AM To: fedora-legacy-list at redhat.com Subject: Openssl updates I have noticed that Openssl has not been updated for FC4 even though there is a security vulnerability. http://www.openssl.org/news/secadv_20060928.txt The most current version I can find for FC4 is 0.9.7l Where can I find this new rpm? Russ -------------- next part -------------- A non-text attachment was scrubbed... Name: winmail.dat Type: application/ms-tnef Size: 4536 bytes Desc: not available URL: From laroche at redhat.com Sat Nov 18 09:20:11 2006 From: laroche at redhat.com (Florian La Roche) Date: Sat, 18 Nov 2006 10:20:11 +0100 Subject: Openssl updates In-Reply-To: <88166C23A9B8784C9C54619E6E5037505E9A83@NCUSPOSTAL01.ncaustin.com> References: <88166C23A9B8784C9C54619E6E5037505E9A83@NCUSPOSTAL01.ncaustin.com> Message-ID: <20061118092011.GA5912@dudweiler.stuttgart.redhat.com> On Fri, Nov 17, 2006 at 10:49:28AM -0600, Russ Lavoie wrote: > I have noticed that Openssl has not been updated for FC4 even though > there is a security vulnerability. > > > > http://www.openssl.org/news/secadv_20060928.txt > > > > The most current version I can find for FC4 is 0.9.7l > > > > Where can I find this new rpm? Interest in Fedora Legacy has slowed down. You can find some FC4 updates at http://www.jur-linux.org/rpms/fc-updates/4/ , but some updates will probably also soon show up at http://fedoralegacy.org/ regards, Florian La Roche From mattdm at mattdm.org Sat Nov 18 14:09:22 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Sat, 18 Nov 2006 09:09:22 -0500 Subject: Openssl updates In-Reply-To: <20061118092011.GA5912@dudweiler.stuttgart.redhat.com> References: <88166C23A9B8784C9C54619E6E5037505E9A83@NCUSPOSTAL01.ncaustin.com> <20061118092011.GA5912@dudweiler.stuttgart.redhat.com> Message-ID: <20061118140922.GA14506@jadzia.bu.edu> > Interest in Fedora Legacy has slowed down. You can find some > FC4 updates at http://www.jur-linux.org/rpms/fc-updates/4/ , > but some updates will probably also soon show up at > http://fedoralegacy.org/ Is anyone actively working on the open OpenSSL bug at this point? -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From donjr at maner.org Sat Nov 18 16:35:42 2006 From: donjr at maner.org (Donald Maner) Date: Sat, 18 Nov 2006 10:35:42 -0600 Subject: Openssl updates In-Reply-To: <20061118140922.GA14506@jadzia.bu.edu> Message-ID: <4A5DA14CF063A54C9DB0C98CCE35B37398C2@selket.home.maner.org> I needs some source QA, then to be built. The SRPMs have been made and posted to bugzilla. -----Original Message----- From: fedora-legacy-list-bounces at redhat.com [mailto:fedora-legacy-list-bounces at redhat.com] On Behalf Of Matthew Miller Sent: Saturday, November 18, 2006 8:09 AM To: Discussion of the Fedora Legacy Project Subject: Re: Openssl updates > Interest in Fedora Legacy has slowed down. You can find some > FC4 updates at http://www.jur-linux.org/rpms/fc-updates/4/ , > but some updates will probably also soon show up at > http://fedoralegacy.org/ Is anyone actively working on the open OpenSSL bug at this point? -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> -- fedora-legacy-list mailing list fedora-legacy-list at redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list From lists at benjamindsmith.com Sun Nov 19 16:20:45 2006 From: lists at benjamindsmith.com (Benjamin Smith) Date: Sun, 19 Nov 2006 08:20:45 -0800 Subject: Openssl updates In-Reply-To: <20061118092011.GA5912@dudweiler.stuttgart.redhat.com> References: <88166C23A9B8784C9C54619E6E5037505E9A83@NCUSPOSTAL01.ncaustin.com> <20061118092011.GA5912@dudweiler.stuttgart.redhat.com> Message-ID: <200611190820.45662.lists@benjamindsmith.com> On Saturday 18 November 2006 01:20, Florian La Roche wrote: > Interest in Fedora Legacy has slowed down. You can find some > FC4 updates at http://www.jur-linux.org/rpms/fc-updates/4/ , > but some updates will probably also soon show up at > http://fedoralegacy.org/ I can see why this would be the case. I don't want to knock your efforts in any way (very much appreciated!) but the truth is that FL exists to extend the short shelf-life of Fedora. And anything that demands a longer shelf-life I've moved over to CentOS or RHEL. I have but one remaining machine using Fedora as a server (running FC1, in a fairly protected environment) that will be upgraded to CentOS 5 once it's released. FL was more or less born when those who started using Fedora to replace RHL on the servers were bitten by Fedora's short lifespan. (myself included) Even with FL's efforts, the life expectancy is still on the short side... I currently plan against using Fedora in any long-term environment where FL would even be needed... and I'm sure I'm not unique in that! -Ben -- "The best way to predict the future is to invent it." - XEROX PARC slogan, circa 1978 From lizard_king825 at yahoo.com Tue Nov 21 03:17:23 2006 From: lizard_king825 at yahoo.com (Lizard King825) Date: Mon, 20 Nov 2006 19:17:23 -0800 (PST) Subject: Questor from Harley-D Message-ID: <20061121031723.21986.qmail@web38502.mail.mud.yahoo.com> Questor: I recieved your email I was glad to get it I was trying to move it out of my bulk folder but somehow I deleted it. hoping you will receive this can you please forward me the email back you wrote to me please. Hope your trip is going ok and you receive this Thanks Dana E Hoffman Jr --------------------------------- Sponsored Link Mortgage rates as low as 4.625% - $150,000 loan for $579 a month. Intro-*Terms -------------- next part -------------- An HTML attachment was scrubbed... URL: From deisenst at gtw.net Wed Nov 29 19:26:12 2006 From: deisenst at gtw.net (David Eisenstein) Date: Wed, 29 Nov 2006 13:26:12 -0600 Subject: nails in coffins? Re: Openssl updates In-Reply-To: <200611190820.45662.lists@benjamindsmith.com> References: <88166C23A9B8784C9C54619E6E5037505E9A83@NCUSPOSTAL01.ncaustin.com> <20061118092011.GA5912@dudweiler.stuttgart.redhat.com> <200611190820.45662.lists@benjamindsmith.com> Message-ID: <456DDED4.1020400@gtw.net> Benjamin Smith wrote: > On Saturday 18 November 2006 01:20, Florian La Roche wrote: > >>Interest in Fedora Legacy has slowed down. You can find some >>FC4 updates at http://www.jur-linux.org/rpms/fc-updates/4/ , >>but some updates will probably also soon show up at >>http://fedoralegacy.org/ > > > I can see why this would be the case. I don't want to knock your efforts in > any way (very much appreciated!) but the truth is that FL exists to extend > the short shelf-life of Fedora. And anything that demands a longer shelf-life > I've moved over to CentOS or RHEL. I have but one remaining machine using > Fedora as a server (running FC1, in a fairly protected environment) that will > be upgraded to CentOS 5 once it's released. > > FL was more or less born when those who started using Fedora to replace RHL on > the servers were bitten by Fedora's short lifespan. (myself included) Even > with FL's efforts, the life expectancy is still on the short side... I > currently plan against using Fedora in any long-term environment where FL > would even be needed... and I'm sure I'm not unique in that! > > -Ben Quite understandable, Ben. And this is why I am looking into stepping down from continuing being a Fedora Legacy maintainer/builder. Neither me, nor Jesse Keating, nor Marc Deslauriers nor any of the others can do this alone. It is just too much work for too little reward and too many headaches for those who care. If there were a magic wand I could wave . . . . but I don't have the acumen or skill to compel folks to be contributors nor the patience to more clearly document the processes that we use (and that I learned how they work just by doing them and making many, many mistakes). When people don't step up, this is what happens. I wish I could do more. But really, I don't know that that wish is realistic. Does anyone else wish more could be done? Or do we just kill the project? Warm regards, David Eisenstein From mattdm at mattdm.org Wed Nov 29 19:29:28 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 29 Nov 2006 14:29:28 -0500 Subject: nails in coffins? Re: Openssl updates In-Reply-To: <456DDED4.1020400@gtw.net> References: <88166C23A9B8784C9C54619E6E5037505E9A83@NCUSPOSTAL01.ncaustin.com> <20061118092011.GA5912@dudweiler.stuttgart.redhat.com> <200611190820.45662.lists@benjamindsmith.com> <456DDED4.1020400@gtw.net> Message-ID: <20061129192928.GA2432@jadzia.bu.edu> On Wed, Nov 29, 2006 at 01:26:12PM -0600, David Eisenstein wrote: > I wish I could do more. But really, I don't know that that wish is > realistic. Does anyone else wish more could be done? Or do we just kill the > project? Well, as I've said, I wish more could be done, but I can't really do it. I think the best thing is to officially hang up the "Closed" sign as soon as possible. If, later, there's interest in extending the lifespan of a particular release, we can revisit. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From rlavoie at ncsoft.com Wed Nov 29 19:29:51 2006 From: rlavoie at ncsoft.com (Russ Lavoie) Date: Wed, 29 Nov 2006 13:29:51 -0600 Subject: nails in coffins? Re: Openssl updates In-Reply-To: <456DDED4.1020400@gtw.net> Message-ID: <88166C23A9B8784C9C54619E6E503750657854@NCUSPOSTAL01.ncaustin.com> I would like to see it go further myself. All the work you guys do is greatly appreciated by myself and probably my others as well. Russ -----Original Message----- From: fedora-legacy-list-bounces at redhat.com [mailto:fedora-legacy-list-bounces at redhat.com] On Behalf Of David Eisenstein Sent: Wednesday, November 29, 2006 1:26 PM To: lists at benjamindsmith.com; Discussion of the Fedora Legacy Project Subject: nails in coffins? Re: Openssl updates Benjamin Smith wrote: > On Saturday 18 November 2006 01:20, Florian La Roche wrote: > >>Interest in Fedora Legacy has slowed down. You can find some >>FC4 updates at http://www.jur-linux.org/rpms/fc-updates/4/ , >>but some updates will probably also soon show up at >>http://fedoralegacy.org/ > > > I can see why this would be the case. I don't want to knock your efforts in > any way (very much appreciated!) but the truth is that FL exists to extend > the short shelf-life of Fedora. And anything that demands a longer shelf-life > I've moved over to CentOS or RHEL. I have but one remaining machine using > Fedora as a server (running FC1, in a fairly protected environment) that will > be upgraded to CentOS 5 once it's released. > > FL was more or less born when those who started using Fedora to replace RHL on > the servers were bitten by Fedora's short lifespan. (myself included) Even > with FL's efforts, the life expectancy is still on the short side... I > currently plan against using Fedora in any long-term environment where FL > would even be needed... and I'm sure I'm not unique in that! > > -Ben Quite understandable, Ben. And this is why I am looking into stepping down from continuing being a Fedora Legacy maintainer/builder. Neither me, nor Jesse Keating, nor Marc Deslauriers nor any of the others can do this alone. It is just too much work for too little reward and too many headaches for those who care. If there were a magic wand I could wave . . . . but I don't have the acumen or skill to compel folks to be contributors nor the patience to more clearly document the processes that we use (and that I learned how they work just by doing them and making many, many mistakes). When people don't step up, this is what happens. I wish I could do more. But really, I don't know that that wish is realistic. Does anyone else wish more could be done? Or do we just kill the project? Warm regards, David Eisenstein -- fedora-legacy-list mailing list fedora-legacy-list at redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list From Axel.Thimm at ATrpms.net Thu Nov 30 02:33:59 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 30 Nov 2006 03:33:59 +0100 Subject: nails in coffins? Re: Openssl updates In-Reply-To: <20061129192928.GA2432@jadzia.bu.edu> References: <88166C23A9B8784C9C54619E6E5037505E9A83@NCUSPOSTAL01.ncaustin.com> <20061118092011.GA5912@dudweiler.stuttgart.redhat.com> <200611190820.45662.lists@benjamindsmith.com> <456DDED4.1020400@gtw.net> <20061129192928.GA2432@jadzia.bu.edu> Message-ID: <20061130023359.GG16360@neu.nirvana> On Wed, Nov 29, 2006 at 02:29:28PM -0500, Matthew Miller wrote: > On Wed, Nov 29, 2006 at 01:26:12PM -0600, David Eisenstein wrote: > > I wish I could do more. But really, I don't know that that wish is > > realistic. Does anyone else wish more could be done? Or do we just kill the > > project? > > Well, as I've said, I wish more could be done, but I can't really do it. I > think the best thing is to officially hang up the "Closed" sign as soon as > possible. If, later, there's interest in extending the lifespan of a > particular release, we can revisit. I would rephrase it in a positive way: Legacy is merged with Core and Extras under one umbrella redefining EOL time marks. E.g. there is a shorter total lifespan, but during that lifespan there is more manpower assigned to get timely security fixes out. The current compromise is that FL was extending Fedora by 12 months, where now it will be only 4 additional months. Reviving FL in these terms would mean to try to extend a couple more months. But let's give that new model a new chance first and measure demand and available manpower after the first implementation of this model. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mattdm at mattdm.org Thu Nov 30 02:37:02 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 29 Nov 2006 21:37:02 -0500 Subject: nails in coffins? Re: Openssl updates In-Reply-To: <20061130023359.GG16360@neu.nirvana> References: <88166C23A9B8784C9C54619E6E5037505E9A83@NCUSPOSTAL01.ncaustin.com> <20061118092011.GA5912@dudweiler.stuttgart.redhat.com> <200611190820.45662.lists@benjamindsmith.com> <456DDED4.1020400@gtw.net> <20061129192928.GA2432@jadzia.bu.edu> <20061130023359.GG16360@neu.nirvana> Message-ID: <20061130023702.GA21766@jadzia.bu.edu> On Thu, Nov 30, 2006 at 03:33:59AM +0100, Axel Thimm wrote: > I would rephrase it in a positive way: Legacy is merged with Core and > Extras under one umbrella redefining EOL time marks. E.g. there is a > shorter total lifespan, but during that lifespan there is more > manpower assigned to get timely security fixes out. > > The current compromise is that FL was extending Fedora by 12 months, > where now it will be only 4 additional months. Reviving FL in these > terms would mean to try to extend a couple more months. But let's give > that new model a new chance first and measure demand and available > manpower after the first implementation of this model. Sounds good. I think the important thing, though, is to state clearly that FC3, FC4, and before are effectively unsupported *right now*. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From jkeating at redhat.com Thu Nov 30 02:54:31 2006 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 29 Nov 2006 21:54:31 -0500 Subject: nails in coffins? Re: Openssl updates In-Reply-To: <20061130023702.GA21766@jadzia.bu.edu> References: <88166C23A9B8784C9C54619E6E5037505E9A83@NCUSPOSTAL01.ncaustin.com> <20061130023359.GG16360@neu.nirvana> <20061130023702.GA21766@jadzia.bu.edu> Message-ID: <200611292154.31442.jkeating@redhat.com> On Wednesday 29 November 2006 21:37, Matthew Miller wrote: > On Thu, Nov 30, 2006 at 03:33:59AM +0100, Axel Thimm wrote: > > I would rephrase it in a positive way: Legacy is merged with Core and > > Extras under one umbrella redefining EOL time marks. E.g. there is a > > shorter total lifespan, but during that lifespan there is more > > manpower assigned to get timely security fixes out. > > > > The current compromise is that FL was extending Fedora by 12 months, > > where now it will be only 4 additional months. Reviving FL in these > > terms would mean to try to extend a couple more months. But let's give > > that new model a new chance first and measure demand and available > > manpower after the first implementation of this model. > > Sounds good. I think the important thing, though, is to state clearly that > FC3, FC4, and before are effectively unsupported *right now*. I think this would be best. Legacy was an experiment that worked for a period of time and has overtime worked less and less. Interest has waned as well as willingness to participate. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mattdm at mattdm.org Thu Nov 30 02:58:06 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 29 Nov 2006 21:58:06 -0500 Subject: nails in coffins? Re: Openssl updates In-Reply-To: <200611292154.31442.jkeating@redhat.com> References: <88166C23A9B8784C9C54619E6E5037505E9A83@NCUSPOSTAL01.ncaustin.com> <20061130023359.GG16360@neu.nirvana> <20061130023702.GA21766@jadzia.bu.edu> <200611292154.31442.jkeating@redhat.com> Message-ID: <20061130025806.GA22815@jadzia.bu.edu> On Wed, Nov 29, 2006 at 09:54:31PM -0500, Jesse Keating wrote: > I think this would be best. Legacy was an experiment that worked for a period > of time and has overtime worked less and less. Interest has waned as well as > willingness to participate. Okay, what more do we need to make it official? -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From jkeating at redhat.com Thu Nov 30 03:12:11 2006 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 29 Nov 2006 22:12:11 -0500 Subject: nails in coffins? Re: Openssl updates In-Reply-To: <20061130025806.GA22815@jadzia.bu.edu> References: <88166C23A9B8784C9C54619E6E5037505E9A83@NCUSPOSTAL01.ncaustin.com> <200611292154.31442.jkeating@redhat.com> <20061130025806.GA22815@jadzia.bu.edu> Message-ID: <200611292212.11119.jkeating@redhat.com> On Wednesday 29 November 2006 21:58, Matthew Miller wrote: > Okay, what more do we need to make it official? Webpage changes to note our wrapup, reporting to the Fedora Board regarding our project status, postings to fedora-announce-list, and then watching the flames roll in. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mattdm at mattdm.org Thu Nov 30 11:55:46 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 30 Nov 2006 06:55:46 -0500 Subject: nails in coffins? Re: Openssl updates In-Reply-To: <200611292212.11119.jkeating@redhat.com> References: <88166C23A9B8784C9C54619E6E5037505E9A83@NCUSPOSTAL01.ncaustin.com> <200611292154.31442.jkeating@redhat.com> <20061130025806.GA22815@jadzia.bu.edu> <200611292212.11119.jkeating@redhat.com> Message-ID: <20061130115546.GA6959@jadzia.bu.edu> On Wed, Nov 29, 2006 at 10:12:11PM -0500, Jesse Keating wrote: > > Okay, what more do we need to make it official? > Webpage changes to note our wrapup, reporting to the Fedora Board regarding > our project status, postings to fedora-announce-list, and then watching the > flames roll in. Is the 13-month lifespan for Core (i.e. "merged Legacy") accepted as official? -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From jkeating at redhat.com Thu Nov 30 13:12:53 2006 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 30 Nov 2006 08:12:53 -0500 Subject: nails in coffins? Re: Openssl updates In-Reply-To: <20061130115546.GA6959@jadzia.bu.edu> References: <88166C23A9B8784C9C54619E6E5037505E9A83@NCUSPOSTAL01.ncaustin.com> <200611292212.11119.jkeating@redhat.com> <20061130115546.GA6959@jadzia.bu.edu> Message-ID: <200611300812.53718.jkeating@redhat.com> On Thursday 30 November 2006 06:55, Matthew Miller wrote: > Is the 13-month lifespan for Core (i.e. "merged Legacy") accepted as > official? That honestly depends on if releasing core to the outside world gets the approval of Red Hat management. We hope it does, and if it does (and if Legacy and FESCO agrees) than the 13month will fall into effect. So it hasn't been decided yet. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Thu Nov 30 14:29:04 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 30 Nov 2006 15:29:04 +0100 Subject: nails in coffins? Re: Openssl updates In-Reply-To: <200611300812.53718.jkeating@redhat.com> References: <88166C23A9B8784C9C54619E6E5037505E9A83@NCUSPOSTAL01.ncaustin.com> <200611292212.11119.jkeating@redhat.com> <20061130115546.GA6959@jadzia.bu.edu> <200611300812.53718.jkeating@redhat.com> Message-ID: <20061130142904.GC3546@neu.nirvana> On Thu, Nov 30, 2006 at 08:12:53AM -0500, Jesse Keating wrote: > On Thursday 30 November 2006 06:55, Matthew Miller wrote: > > Is the 13-month lifespan for Core (i.e. "merged Legacy") accepted as > > official? > > > That honestly depends on if releasing core to the outside world gets the > approval of Red Hat management. We hope it does, and if it does (and if > Legacy and FESCO agrees) than the 13month will fall into effect. So it > hasn't been decided yet. If some statement from legacy is needed about FC3/FC4 before that decision is made (which IMHO is needed), how about something along a heading of "Fedora Legacy is ending its current support model working towards direct involvement in maintenance of upcoming Fedora releases in FL's spirit of extending lifetimes of Fedora releases. Within this anticipated release model there will be no distinction between FL and other entities." We don't pre-announce anything that hasn't been decided on, but still show where FL is heading to. It's better than simply hanging a "closed" sign upfront the website. :) -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From nils at lemonbit.nl Thu Nov 30 14:59:55 2006 From: nils at lemonbit.nl (Nils Breunese (Lemonbit)) Date: Thu, 30 Nov 2006 15:59:55 +0100 Subject: nails in coffins? Re: Openssl updates In-Reply-To: <20061130142904.GC3546@neu.nirvana> References: <88166C23A9B8784C9C54619E6E5037505E9A83@NCUSPOSTAL01.ncaustin.com> <200611292212.11119.jkeating@redhat.com> <20061130115546.GA6959@jadzia.bu.edu> <200611300812.53718.jkeating@redhat.com> <20061130142904.GC3546@neu.nirvana> Message-ID: <78B938E7-7777-40FC-A1BD-97285BEFD6AF@lemonbit.nl> Axel Thimm wrote: > If some statement from legacy is needed about FC3/FC4 before that > decision is made (which IMHO is needed), how about something along a > heading of > > "Fedora Legacy is ending its current support model working towards > direct involvement in maintenance of upcoming Fedora releases in > FL's spirit of extending lifetimes of Fedora releases. Within this > anticipated release model there will be no distinction between FL > and other entities." > > We don't pre-announce anything that hasn't been decided on, but still > show where FL is heading to. > > It's better than simply hanging a "closed" sign upfront the > website. :) But FC3/4 admins reading this statement might think their versions are still supported somehow. At least I don't see 'FC3 and FC4 are effectively EOL right now' between the lines and I think people should know plans have changed and they aren't getting any updates anymore. I think it's sad Fedora Legacy seems to be ending a little prematurely, but I totally understand that the people that were carrying this dying beast have decided to just put it down and let it be. Unfortunately I will have to be migrating our last Fedora servers over to CentOS even sooner now... Thanks for all the work guys, Nils Breunese. -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: Dit deel van het bericht is digitaal ondertekend URL: From rdieter at math.unl.edu Thu Nov 30 15:11:52 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 30 Nov 2006 09:11:52 -0600 Subject: nails in coffins? Re: Openssl updates References: <88166C23A9B8784C9C54619E6E5037505E9A83@NCUSPOSTAL01.ncaustin.com> <200611292212.11119.jkeating@redhat.com> <20061130115546.GA6959@jadzia.bu.edu> <200611300812.53718.jkeating@redhat.com> <20061130142904.GC3546@neu.nirvana> <78B938E7-7777-40FC-A1BD-97285BEFD6AF@lemonbit.nl> Message-ID: Nils Breunese (Lemonbit) wrote: > Unfortunately I will have to be migrating our last Fedora servers > over to CentOS even sooner now... I take it, then, that extending Fedora's (supported) life-cycle to 13+ mos isn't sufficient for your needs? -- Rex From tony.molloy at ul.ie Thu Nov 30 15:25:19 2006 From: tony.molloy at ul.ie (Tony Molloy) Date: Thu, 30 Nov 2006 15:25:19 +0000 Subject: nails in coffins? Re: Openssl updates In-Reply-To: <78B938E7-7777-40FC-A1BD-97285BEFD6AF@lemonbit.nl> References: <88166C23A9B8784C9C54619E6E5037505E9A83@NCUSPOSTAL01.ncaustin.com> <20061130142904.GC3546@neu.nirvana> <78B938E7-7777-40FC-A1BD-97285BEFD6AF@lemonbit.nl> Message-ID: <200611301525.19222.tony.molloy@ul.ie> On Thursday 30 November 2006 14:59, Nils Breunese (Lemonbit) wrote: > > I think it's sad Fedora Legacy seems to be ending a little > prematurely, but I totally understand that the people that were > carrying this dying beast have decided to just put it down and let it > be. Unfortunately I will have to be migrating our last Fedora servers > over to CentOS even sooner now... > > Thanks for all the work guys, > > Nils Breunese. Well for me in a University environment a 13 month lifetime for a Fedora release is perfect. Our servers already all run Centos-4. Our desktops are installed each year at the begining of Sept with the latest available Fedora, and reinstalled in late January during the break between semesters. We just missed out on Fedora 6 this year ;-( So thanks for everything, Tony -- Tony Molloy. System Manager. Dept. of Comp. Sci. University of Limerick From mattdm at mattdm.org Thu Nov 30 15:30:58 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 30 Nov 2006 10:30:58 -0500 Subject: nails in coffins? Re: Openssl updates In-Reply-To: References: <88166C23A9B8784C9C54619E6E5037505E9A83@NCUSPOSTAL01.ncaustin.com> <200611292212.11119.jkeating@redhat.com> <20061130115546.GA6959@jadzia.bu.edu> <200611300812.53718.jkeating@redhat.com> <20061130142904.GC3546@neu.nirvana> <78B938E7-7777-40FC-A1BD-97285BEFD6AF@lemonbit.nl> Message-ID: <20061130153058.GA15901@jadzia.bu.edu> On Thu, Nov 30, 2006 at 09:11:52AM -0600, Rex Dieter wrote: > > Unfortunately I will have to be migrating our last Fedora servers > > over to CentOS even sooner now... > I take it, then, that extending Fedora's (supported) life-cycle to 13+ mos > isn't sufficient for your needs? That's the case here too, and as I suggested earlier, is also true for many, many other people who haven't said anything. (I'm basing this on circumstantial evidence, but, for example, observe the number of people who crop on fedora-list with FC3 questions.) However, ample evidence has made it clear that without significant resources from someone with money to dedicate to this project (i.e. at least one full-time position), more than 13 months is not practical. Therefore, CentOS is the best answer for this large segment of users. That's a loss for Fedora, but, whatchagonnado. Going to 13 months will at least cover a different largish segment. ..__ ....____ ......._______ ..........__________ __ ............._____________.. _____ ............._____________.... _______ ............._____________...... ._________ ............._____________........_ .._________ ............._____________........___ ....._________ ............._____________........_______________ Fedora +13 mo. CentOS/RHEL RHEL Unix Still running mainframes -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From mattdm at mattdm.org Thu Nov 30 15:30:58 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 30 Nov 2006 10:30:58 -0500 Subject: nails in coffins? Re: Openssl updates In-Reply-To: References: <88166C23A9B8784C9C54619E6E5037505E9A83@NCUSPOSTAL01.ncaustin.com> <200611292212.11119.jkeating@redhat.com> <20061130115546.GA6959@jadzia.bu.edu> <200611300812.53718.jkeating@redhat.com> <20061130142904.GC3546@neu.nirvana> <78B938E7-7777-40FC-A1BD-97285BEFD6AF@lemonbit.nl> Message-ID: <20061130153058.GA15901@jadzia.bu.edu> On Thu, Nov 30, 2006 at 09:11:52AM -0600, Rex Dieter wrote: > > Unfortunately I will have to be migrating our last Fedora servers > > over to CentOS even sooner now... > I take it, then, that extending Fedora's (supported) life-cycle to 13+ mos > isn't sufficient for your needs? That's the case here too, and as I suggested earlier, is also true for many, many other people who haven't said anything. (I'm basing this on circumstantial evidence, but, for example, observe the number of people who crop on fedora-list with FC3 questions.) However, ample evidence has made it clear that without significant resources from someone with money to dedicate to this project (i.e. at least one full-time position), more than 13 months is not practical. Therefore, CentOS is the best answer for this large segment of users. That's a loss for Fedora, but, whatchagonnado. Going to 13 months will at least cover a different largish segment. ..__ ....____ ......._______ ..........__________ __ ............._____________.. _____ ............._____________.... _______ ............._____________...... ._________ ............._____________........_ .._________ ............._____________........___ ....._________ ............._____________........_______________ Fedora +13 mo. CentOS/RHEL RHEL Unix Still running mainframes -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From mattdm at mattdm.org Thu Nov 30 15:32:42 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 30 Nov 2006 10:32:42 -0500 Subject: nails in coffins? Re: Openssl updates In-Reply-To: <200611300812.53718.jkeating@redhat.com> References: <88166C23A9B8784C9C54619E6E5037505E9A83@NCUSPOSTAL01.ncaustin.com> <200611292212.11119.jkeating@redhat.com> <20061130115546.GA6959@jadzia.bu.edu> <200611300812.53718.jkeating@redhat.com> Message-ID: <20061130153242.GB15901@jadzia.bu.edu> On Thu, Nov 30, 2006 at 08:12:53AM -0500, Jesse Keating wrote: > That honestly depends on if releasing core to the outside world gets the > approval of Red Hat management. We hope it does, and if it does (and if > Legacy and FESCO agrees) than the 13month will fall into effect. So it > hasn't been decided yet. Everyone's pretty much talking like this is a done deal. Any idea when an official decision will be made? -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From jkeating at j2solutions.net Thu Nov 30 15:35:44 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Thu, 30 Nov 2006 10:35:44 -0500 Subject: nails in coffins? Re: Openssl updates In-Reply-To: <20061130153242.GB15901@jadzia.bu.edu> References: <88166C23A9B8784C9C54619E6E5037505E9A83@NCUSPOSTAL01.ncaustin.com> <200611300812.53718.jkeating@redhat.com> <20061130153242.GB15901@jadzia.bu.edu> Message-ID: <200611301035.44737.jkeating@j2solutions.net> On Thursday 30 November 2006 10:32, Matthew Miller wrote: > Everyone's pretty much talking like this is a done deal. Any idea when an > official decision will be made? I'm involved in discussions with RH management this week, and probably next week. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mattdm at mattdm.org Thu Nov 30 15:40:44 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 30 Nov 2006 10:40:44 -0500 Subject: nails in coffins? Re: Openssl updates In-Reply-To: <200611301035.44737.jkeating@j2solutions.net> References: <88166C23A9B8784C9C54619E6E5037505E9A83@NCUSPOSTAL01.ncaustin.com> <200611300812.53718.jkeating@redhat.com> <20061130153242.GB15901@jadzia.bu.edu> <200611301035.44737.jkeating@j2solutions.net> Message-ID: <20061130154044.GA16879@jadzia.bu.edu> On Thu, Nov 30, 2006 at 10:35:44AM -0500, Jesse Keating wrote: > > Everyone's pretty much talking like this is a done deal. Any idea when an > > official decision will be made? > I'm involved in discussions with RH management this week, and probably next > week. Okay, thanks for the update. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From nils at lemonbit.nl Thu Nov 30 15:40:55 2006 From: nils at lemonbit.nl (Nils Breunese (Lemonbit)) Date: Thu, 30 Nov 2006 16:40:55 +0100 Subject: nails in coffins? Re: Openssl updates In-Reply-To: References: <88166C23A9B8784C9C54619E6E5037505E9A83@NCUSPOSTAL01.ncaustin.com> <200611292212.11119.jkeating@redhat.com> <20061130115546.GA6959@jadzia.bu.edu> <200611300812.53718.jkeating@redhat.com> <20061130142904.GC3546@neu.nirvana> <78B938E7-7777-40FC-A1BD-97285BEFD6AF@lemonbit.nl> Message-ID: Rex Dieter wrote: >> Unfortunately I will have to be migrating our last Fedora servers >> over to CentOS even sooner now... > > I take it, then, that extending Fedora's (supported) life-cycle to > 13+ mos > isn't sufficient for your needs? Not for that couple of FC3 machines my clients have running. Or am I misunderstanding the 13 months of support somehow? FC3 was released on November 8 2004. Also, FC4 (I don't have any FC4 machines) was released on June 13 2005, so I guess that is also EOL effectively. Nils Breunese. From mattdm at mattdm.org Thu Nov 30 16:11:37 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 30 Nov 2006 11:11:37 -0500 Subject: nails in coffins? Re: Openssl updates In-Reply-To: References: <88166C23A9B8784C9C54619E6E5037505E9A83@NCUSPOSTAL01.ncaustin.com> <200611292212.11119.jkeating@redhat.com> <20061130115546.GA6959@jadzia.bu.edu> <200611300812.53718.jkeating@redhat.com> <20061130142904.GC3546@neu.nirvana> <78B938E7-7777-40FC-A1BD-97285BEFD6AF@lemonbit.nl> Message-ID: <20061130161137.GA18307@jadzia.bu.edu> On Thu, Nov 30, 2006 at 04:40:55PM +0100, Nils Breunese (Lemonbit) wrote: > Not for that couple of FC3 machines my clients have running. Or am I > misunderstanding the 13 months of support somehow? FC3 was released > on November 8 2004. Also, FC4 (I don't have any FC4 machines) was > released on June 13 2005, so I guess that is also EOL effectively. In terms of "have their been a meaningful number of updates for real security problems", they are EOL *now* -- just sans announcement. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From nils at lemonbit.nl Thu Nov 30 16:40:45 2006 From: nils at lemonbit.nl (Nils Breunese (Lemonbit)) Date: Thu, 30 Nov 2006 17:40:45 +0100 Subject: nails in coffins? Re: Openssl updates In-Reply-To: <20061130161137.GA18307@jadzia.bu.edu> References: <88166C23A9B8784C9C54619E6E5037505E9A83@NCUSPOSTAL01.ncaustin.com> <200611292212.11119.jkeating@redhat.com> <20061130115546.GA6959@jadzia.bu.edu> <200611300812.53718.jkeating@redhat.com> <20061130142904.GC3546@neu.nirvana> <78B938E7-7777-40FC-A1BD-97285BEFD6AF@lemonbit.nl> <20061130161137.GA18307@jadzia.bu.edu> Message-ID: <10E9DB3D-96E4-4CDD-89FA-EB009592E6F5@lemonbit.nl> Op 30-nov-2006, om 17:11 heeft Matthew Miller het volgende geschreven: > On Thu, Nov 30, 2006 at 04:40:55PM +0100, Nils Breunese (Lemonbit) > wrote: >> Not for that couple of FC3 machines my clients have running. Or am I >> misunderstanding the 13 months of support somehow? FC3 was released >> on November 8 2004. Also, FC4 (I don't have any FC4 machines) was >> released on June 13 2005, so I guess that is also EOL effectively. > > In terms of "have their been a meaningful number of updates for real > security problems", they are EOL *now* -- just sans announcement. I know, but not everybody knows. If FL is going to make an official statement I'd vote for telling it like it is. Giving the whole thing a positive spin (by saying Legacy is merging with Core) is fine with me, but I suggest we do tell people FC3 and FC4 are EOL as of *now* (unlike what some people may be thinking). Nils Breunese. From smooge at gmail.com Thu Nov 30 21:02:19 2006 From: smooge at gmail.com (Stephen John Smoogen) Date: Thu, 30 Nov 2006 14:02:19 -0700 Subject: nails in coffins? Re: Openssl updates In-Reply-To: References: <88166C23A9B8784C9C54619E6E5037505E9A83@NCUSPOSTAL01.ncaustin.com> <200611292212.11119.jkeating@redhat.com> <20061130115546.GA6959@jadzia.bu.edu> <200611300812.53718.jkeating@redhat.com> <20061130142904.GC3546@neu.nirvana> <78B938E7-7777-40FC-A1BD-97285BEFD6AF@lemonbit.nl> Message-ID: <80d7e4090611301302o1ba8d129he34a29066006ca85@mail.gmail.com> On 11/30/06, Rex Dieter wrote: > Nils Breunese (Lemonbit) wrote: > > > Unfortunately I will have to be migrating our last Fedora servers > > over to CentOS even sooner now... > > I take it, then, that extending Fedora's (supported) life-cycle to 13+ mos > isn't sufficient for your needs? > For my previous government jobs it took about 3 months to get an OS certified from the time it was gold to when it could be used. That leaves 10 months of usefulness of it, which I think will work well for the cluster people who needed the latest stuff as they will be really only using it for 6 months before the next upgrade. The finalized large cluster would go onto being Centos or RHEL as it would need to run the same code sets for 5 years. Depending on the department, a 10 month lifetime would also be ok for desktops. For servers, it is too short of a time as it usually takes about 2 months after the OS is ok to be used for the various services to be solid. However, it is what people get for living off the work of others (eg gratis) -- Stephen J Smoogen. -- CSIRT/Linux System Administrator How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From smooge at gmail.com Thu Nov 30 21:02:19 2006 From: smooge at gmail.com (Stephen John Smoogen) Date: Thu, 30 Nov 2006 14:02:19 -0700 Subject: nails in coffins? Re: Openssl updates In-Reply-To: References: <88166C23A9B8784C9C54619E6E5037505E9A83@NCUSPOSTAL01.ncaustin.com> <200611292212.11119.jkeating@redhat.com> <20061130115546.GA6959@jadzia.bu.edu> <200611300812.53718.jkeating@redhat.com> <20061130142904.GC3546@neu.nirvana> <78B938E7-7777-40FC-A1BD-97285BEFD6AF@lemonbit.nl> Message-ID: <80d7e4090611301302o1ba8d129he34a29066006ca85@mail.gmail.com> On 11/30/06, Rex Dieter wrote: > Nils Breunese (Lemonbit) wrote: > > > Unfortunately I will have to be migrating our last Fedora servers > > over to CentOS even sooner now... > > I take it, then, that extending Fedora's (supported) life-cycle to 13+ mos > isn't sufficient for your needs? > For my previous government jobs it took about 3 months to get an OS certified from the time it was gold to when it could be used. That leaves 10 months of usefulness of it, which I think will work well for the cluster people who needed the latest stuff as they will be really only using it for 6 months before the next upgrade. The finalized large cluster would go onto being Centos or RHEL as it would need to run the same code sets for 5 years. Depending on the department, a 10 month lifetime would also be ok for desktops. For servers, it is too short of a time as it usually takes about 2 months after the OS is ok to be used for the various services to be solid. However, it is what people get for living off the work of others (eg gratis) -- Stephen J Smoogen. -- CSIRT/Linux System Administrator How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice"