Re: end of Fedora Legacy mirror at Iowa State
On Mon, Jun 11, 2007 at 09:28:21AM -0500, Dave Edsall - JETSETer wrote: Max Spevack announced last month that Fedora Core 5's end of life would be June 29th. That gives us a good milestone for removing our Fedora Legacy mirror. Traffic was high for two months after the announcement of Fedora Legacy's demise but has dwindled since April. So, beginning July 1, 2007, Iowa State will no longer offer a mirror of Fedora Legacy. Grab what you would like between now and then. Would whoever is responsible for http://download.fedoralegacy.org/download/f edoralegacy-mirrors.php please remove us from that page at your leisure? Could you also remove ATrpms' mirror? Many thanks to everyone who worked on that project! Dito! -- Axel.Thimm at ATrpms.net pgpYZbxCoka7U.pgp Description: PGP signature -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
end of Fedora Legacy mirror at Iowa State
Max Spevack announced last month that Fedora Core 5's end of life would be June 29th. That gives us a good milestone for removing our Fedora Legacy mirror. Traffic was high for two months after the announcement of Fedora Legacy's demise but has dwindled since April. So, beginning July 1, 2007, Iowa State will no longer offer a mirror of Fedora Legacy. Grab what you would like between now and then. Would whoever is responsible for http://download.fedoralegacy.org/download/f edoralegacy-mirrors.php please remove us from that page at your leisure? Many thanks to everyone who worked on that project! Dave - Dave Edsall Academic Systems Software Information Technology Services Iowa State University - -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Re: end of Fedora Legacy mirror at Iowa State
On Monday 11 June 2007 16:28, Dave Edsall - JETSETer wrote: Max Spevack announced last month that Fedora Core 5's end of life would be June 29th. That gives us a good milestone for removing our Fedora Legacy mirror. Traffic was high for two months after the announcement of Fedora Legacy's demise but has dwindled since April. So, beginning July 1, 2007, Iowa State will no longer offer a mirror of Fedora Legacy. Grab what you would like between now and then. Many thanks to everyone who worked on that project! Dave Hi Dave. Thanks for the upfront notification. I've been using Fedora Legacy since FC1, and it's sad to see that it's thrown in the towel. I'm still using FC2 from day to day on one machine, and think that it's one of the better Fedora releases, though no longer supported. Can you give me a URL for the mirror, preferably for apt, but yum will do. I'll try and download as many of the FC2 packages that I can, depending on harddrive space. Thanks again for letting us know in advance that the server is going down soon. That has to be better than a Debian multimedia repo, that when Etch went stable, just trashed all the packages on the Sarge repo, with no upfront notification at all. All the best. Nigel. -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Re: Fedora Legacy shutting down
Jesse Keating wrote: On Tuesday 02 January 2007 11:06, Eric Rostetter wrote: Fixed on www.fedoralegacy.org, but not on download.fedoralegacy.org. Can someone please change these? They're both very small changes, but I think it's best not to confuse people now. Jesse will have to do download.fedoralegacy.org. The plan for download.fedoralegacy.org is to point it at the document describing the project status with a pointer to the last known mirror list. This way repos will break, people will go to the URL to see whats up, notice the project closure, and reconfigure for one of the mirrors if they still need updates, and make informed decisions regarding their system's future. So download.fedoralegacy.org is down now, but there is no document there describing the project status. Of course people should be looking at www.fedoralegacy.org after trying download.fedoralegacy.org, but can a page a like still be put up? Also I'd like to know if there's a list of mirrors that will continue to be available for a while. If not I'd like to know how I can rsync all packages created by the Fedora Legacy Project without also rsyncing the packages that are still available at download.fedora.redhat.com. Most packages have legacy in their filename, but I believe some do not. Can anyone shed some more light on this? I'd like to have the Fedora Legacy archive available because sometimes I have start managing an old Fedora box and I like to be able to at least get the latest legacy fixes on them directly as planning a migration takes a little time. Thanks, Nils Breunese. PGP.sig Description: Dit deel van het bericht is digitaal ondertekend -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Re: Fedora Legacy shutting down
Heya, Also I'd like to know if there's a list of mirrors that will continue to be available for a while. If not I'd like to know how I can rsync all packages created by the Fedora Legacy Project without also rsyncing the packages that are still available at download.fedora.redhat.com. Most packages have legacy in their filename, but I believe some do not. Can anyone shed some more light on this? I believe PlanetMirror still has a full mirror over here: http://public.www.planetmirror.com/pub/fedoralegacy I will ask the appropriate people to leave it up as long as possible. Stuart -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Fedora Legacy
Hi, All. It is with some sadness I have noted that the fedora legacy project has significantly downscaled it's scope. Not least because it leaves me a job to do with my fedora servers (many of which are FC3)! That got me thinking... should I be lamenting lack of community interest in the project, and moving on; or should I be trying to help. First of all, qualifications: Experienced linux sysadmin, from way back (well RH6 ish), and a good background in managing RedHat / Fedora servers and (some) workstations. Now snags: Limited (in the most limited sense of the word!) programming skills. Bash, perl, php, some c and that's about it. I do however have a few hours a week to contribute, and therefore propose that I may be suitable as your mirror coordinator [seems a documentation / support role to me, suitable for a mere sysadmin ;-)], and can also act as a tester / qa tester. I have a reasonable scope of hardware to run or emulate a range of OSs. Let me know if I can be of use. Thanks Andrew Wilson Research Systems Support Officer School of Physics Astronomy The University of Nottingham. (+44) 115 951 5182 [EMAIL PROTECTED] This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Re: Fedora Legacy
On 1/12/07, Wilson Andrew [EMAIL PROTECTED] wrote: Hi, All. It is with some sadness I have noted that the fedora legacy project has significantly downscaled it's scope. Not least because it leaves me a job to do with my fedora servers (many of which are FC3)! That got me thinking... should I be lamenting lack of community interest in the project, and moving on; or should I be trying to help. At this point.. I think moving on is the status. The Fedora Legacy project pretty much closed doors, rolled up the sidewalk, and drove out of town in December 2006. -- 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 -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Re: Fedora Legacy
On Fri, Jan 12, 2007 at 09:33:43PM -, Wilson Andrew wrote: Not least because it leaves me a job to do with my fedora servers (many of which are FC3)! That got me thinking... should I be lamenting lack of community interest in the project, and moving on; or should I be trying to help. Well, you probably could have helped five months ago. -- Matthew Miller [EMAIL PROTECTED] http://mattdm.org/ Boston University Linux -- http://linux.bu.edu/ -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Re: Fedora Legacy shutting down
Axel Thimm wrote: On Mon, Jan 01, 2007 at 11:29:28PM -0500, seth vidal wrote: On Mon, 2007-01-01 at 20:54 -0500, Jesse Keating wrote: On Monday 01 January 2007 20:42, Jesse Keating wrote: It wouldn't take space Correction, wouldn't take huge amounts of space. It's 63GB in total. I count about 10GB. The difference is probably the fedora/redhat non-legacy updates from *.redhat.com, but in any case if someone wants to archive FL's work he needs just 10GB. The legacy and non-legacy updates are not in separate directories on download.fedoralegacy.org. Is there an easy way to just download (rsync?) the legacy updates? The non-legacy base and updates packages are still available at download.fedora.redhat.com. Or does anyone know of a download.fedoralegacy.org mirror that won't shutdown after download.fedoralegacy.org goes away? Nils Breunese. PGP.sig Description: Dit deel van het bericht is digitaal ondertekend -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Re: Fedora Legacy shutting down
On Tue, Jan 02, 2007 at 11:37:51AM +0100, Nils Breunese (Lemonbit) wrote: Axel Thimm wrote: On Mon, Jan 01, 2007 at 11:29:28PM -0500, seth vidal wrote: On Mon, 2007-01-01 at 20:54 -0500, Jesse Keating wrote: On Monday 01 January 2007 20:42, Jesse Keating wrote: It wouldn't take space Correction, wouldn't take huge amounts of space. It's 63GB in total. I count about 10GB. The difference is probably the fedora/redhat non-legacy updates from *.redhat.com, but in any case if someone wants to archive FL's work he needs just 10GB. The legacy and non-legacy updates are not in separate directories on download.fedoralegacy.org. Yes, I'm removing the packages that already exist on the non-legacy updates (I have a mirror of them, too). Is there an easy way to just download (rsync?) the legacy updates? I think all packages have legacy in their names, so using proper rsync options like excluding '*.rpm' and then including '*legacy*rpm' should work. The non-legacy base and updates packages are still available at download.fedora.redhat.com. Or does anyone know of a download.fedoralegacy.org mirror that won't shutdown after download.fedoralegacy.org goes away? -- Axel.Thimm at ATrpms.net pgpakBGQQ4KxG.pgp Description: PGP signature -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Re: Fedora Legacy shutting down
On Tuesday 02 January 2007 11:06, Eric Rostetter wrote: Fixed on www.fedoralegacy.org, but not on download.fedoralegacy.org. Can someone please change these? They're both very small changes, but I think it's best not to confuse people now. Jesse will have to do download.fedoralegacy.org. The plan for download.fedoralegacy.org is to point it at the document describing the project status with a pointer to the last known mirror list. This way repos will break, people will go to the URL to see whats up, notice the project closure, and reconfigure for one of the mirrors if they still need updates, and make informed decisions regarding their system's future. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) pgpaenihsdwBU.pgp Description: PGP signature -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Re: Fedora Legacy shutting down
On Saturday 30 December 2006 00:23, [EMAIL PROTECTED] wrote: Discussions last night on the #Fedora-Legacy channel have brought to light the fact that certain Fedora Legacy properties (servers) may be going away soon, such as the repository at http://download.fedoralegacy.org/ and the build server. Legacy folks need to let us know what they want to be done with the content in the repository mirrors. If you don't speak up, we may find ourselves in a place where 'yum update' commands will fail in the near future for the Red Hat and Fedora Core releases that Legacy has supported in the past. I would like to make clear that the servers are only going offline because the project is ending, and keeping them online consumes real resources. This consumption is unnecessary if the project is shut down. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) pgpP6wWeDpVfn.pgp Description: PGP signature -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Re: Fedora Legacy shutting down
30.12.2006 06:23 David Eisenstein wrote: Legacy folks need to let us know what they want to be done with the content in the repository mirrors. Hello, like other people i depend on FC3 for production systems. I would like to see the repositories being accessible. Not only to be able to install additional rpms and there dependencies. Besides - many thanks for your efforts. M. -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Re: Thanks FL! (was: Fedora Legacy shutting down)
On Sat, Dec 30, 2006 at 12:10:33PM +0100, Axel Thimm wrote: On Fri, Dec 29, 2006 at 11:23:47PM -0600, David Eisenstein wrote: In case any of you are not aware, the Fedora Legacy project is in the process of shutting down. I think since this is the very official end of the project, very official thanks for all efforts are in order! Yes, thank you so much, everyone. All of your work has been very helpful. -- Matthew Miller [EMAIL PROTECTED] http://mattdm.org/ Boston University Linux -- http://linux.bu.edu/ -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Re: Fedora Legacy shutting down
In case any of you are not aware, the Fedora Legacy project is in the process of shutting down. Does have anyone a rscync line for me to get the whole FC3 tree to my local hdd? I am still using some FC3 boxes, and dont want to miss the FL packages if i need some... Danny. -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Re: Fedora Legacy shutting down
In case any of you are not aware, the Fedora Legacy project is in the process of shutting down. Does have anyone a rscync line for me to get the whole FC3 tree to my local hdd? I am still using some FC3 boxes, and dont want to miss the FL packages if i need some... I wanted to do the same, but 'rsync download.fedoralegacy.org::legacy legacy' told me I wasn't allowed to do that because I'm not a registered mirror. The mirror page tells me mirror registration is disabled. Any other way to get the tree without having to download each individual package? Nils Breunese. -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Re: Fedora Legacy shutting down
On Sat, 2006-12-30 at 16:38 +0100, [EMAIL PROTECTED] wrote: In case any of you are not aware, the Fedora Legacy project is in the process of shutting down. Does have anyone a rscync line for me to get the whole FC3 tree to my local hdd? I am still using some FC3 boxes, and dont want to miss the FL packages if i need some... I wanted to do the same, but 'rsync download.fedoralegacy.org::legacy legacy' told me I wasn't allowed to do that because I'm not a registered mirror. The mirror page tells me mirror registration is disabled. Any other way to get the tree without having to download each individual package? Try it now. -sv -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Re: Fedora Legacy shutting down
In case any of you are not aware, the Fedora Legacy project is in the process of shutting down. Does have anyone a rscync line for me to get the whole FC3 tree to my local hdd? I am still using some FC3 boxes, and dont want to miss the FL packages if i need some... I wanted to do the same, but 'rsync download.fedoralegacy.org::legacy legacy' told me I wasn't allowed to do that because I'm not a registered mirror. The mirror page tells me mirror registration is disabled. Any other way to get the tree without having to download each individual package? Try it now. # rsync download.fedoralegacy.org::legacy legacy Fedora Legacy Rsync - Restricted use. To sign up to be an official mirror, visit http://fedoralegacy.org/download/mirror-form.php -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Re: Fedora Legacy shutting down
On Saturday 30 December 2006 03:33, Bill McGonigle wrote: I'm wondering if anybody is working on a communications piece for the shutdown. A who-what-when-where-why-how sort of article? I'm assuming it would be on the Wiki/homepage if it were, but here's asking anyhow. Reading this list over the last year or so would be good info. So, assuming it hasn't been, I can volunteer to put something together, to save the multitudes the effort of investigation. I spent some time looking over the last couple months of mailing list archives, the internetnews piece, and Jesse's blog, but I'm not convinced I have the whole story. Some outstanding questions would be: * was there any attempt to recruit new leadership? Yes, leadership does no good without contributors. * ditto for sponsorship Nobody has responded to our calls for help. Nobody. * is there data on usage (I saw that 'interest was low' but I'm not sure if it means interest in volunteering or interest in terms of yum updates) Sure, there are a good number of consumers, people who will happily consume until the project ends, however they are not willing to actually DO any of the work necessary to keep the project alive. They would be better suited consuming updates from a product that is designed for their usage cases. * probably lots more I'm not thinking about now, and it's late so my reading comprehension is likely sub-par -- Jesse Keating Release Engineer: Fedora pgpPrafdopjJ2.pgp Description: PGP signature -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Re: Fedora Legacy shutting down
On Saturday 30 December 2006 05:32, Nils Breunese (Lemonbit) wrote: I'd like to mirror the legacy tree (at least the FC2, FC3 and FC4 part of it) to a local server, but 'rsync download.fedoralegacy.org legacy' tells me I cannot mirror the tree as I'm not an official mirror. http://www.fedoralegacy.org/download/mirror-form.php tells me mirror registration is disabled. Is there a quick way to get those files? I'd rather not download them one by one and I might want to use a couple of those rpms before I have completed migrating my EOL'd Fedora servers. If you read the message more carefully you'll see that you aren't being denied access, only that mirrors have a special port to use that should the load become too high only the mirrors would get access. You're perfectly capable of rsyncing all the content you want. -- Jesse Keating Release Engineer: Fedora pgp13FFv3HF7R.pgp Description: PGP signature -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Re: Fedora Legacy shutting down
seth vidal wrote: seems to work for me if you use: rsync -avH download.fedoralegacy.org::legacy legacy Works me for me too now. Nils Breunese. PGP.sig Description: Dit deel van het bericht is digitaal ondertekend -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Re: Fedora Legacy shutting down
David Eisenstein wrote: In case any of you are not aware, the Fedora Legacy project is in the process of shutting down. Thank you to everybody who helped in this project. Happy New Year :) -- Josep -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Re: You Need Fedora Legacy!! Re: [fab] looking at our surrent state a bit
Eric Rostetter wrote: Quoting Axel Thimm [EMAIL PROTECTED]: 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 -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Re: You Need Fedora Legacy!! Re: [fab] looking at our surrent state a bit
Quoting David Eisenstein [EMAIL PROTECTED]: 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! -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Re: You Need Fedora Legacy!! Re: [fab] looking at our surrent state a bit
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 pgpVbq54kOKDm.pgp Description: PGP signature -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Re: You Need Fedora Legacy!! Re: [fab] looking at our surrent state a bit
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 -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Re: You Need Fedora Legacy!! Re: [fab] looking at our surrent state a bit
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 -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Re: Fedora Legacy Test Update Notification: gzip
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 Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Re: You Need Fedora Legacy!! Re: [fab] looking at our surrent state a bit
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 pgpIWeDderKt5.pgp Description: PGP signature -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Re: You Need Fedora Legacy!! Re: [fab] looking at our surrent state a bit
Quoting Axel Thimm [EMAIL PROTECTED]: 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! -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Re: You Need Fedora Legacy!! Re: [fab] looking at our surrent state a bit
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 pgpcVFDQZoUHJ.pgp Description: PGP signature -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Re: You Need Fedora Legacy!! Re: [fab] looking at our surrent state a bit
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/msg6.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 -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Re: You Need Fedora Legacy!! Re: [fab] looking at our surrent state a bit
Eric Rostetter wrote: Quoting Axel Thimm [EMAIL PROTECTED]: 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 -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Re: Some supporting ideas regarding fedora legacy project when FC6 is out today
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 -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
You Need Fedora Legacy!! Re: [fab] looking at our surrent state a bit
- Original Message - From: Thorsten Leemhuis [EMAIL PROTECTED] To: [EMAIL PROTECTED] 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 -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Re: You Need Fedora Legacy!! Re: [fab] looking at our surrent state a bit
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@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. -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Re: You Need Fedora Legacy!! Re: [fab] looking at our surrent state a bit
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) pgpYFyMtloKhA.pgp Description: PGP signature -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Re: You Need Fedora Legacy!! Re: [fab] looking at our surrent state a bit
-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 -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Re: You Need Fedora Legacy!! Re: [fab] looking at our surrent state a bit
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 [EMAIL PROTECTED] http://mattdm.org/ Boston University Linux -- http://linux.bu.edu/ -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Fedora Legacy Test Update Notification: gzip
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 [EMAIL PROTECTED] 1.3.3-16.1.fc3.legacy - Add BuildRequires: texinfo, so gzip.info will be properly created. * Sat Nov 4 2006 David Eisenstein [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] - 1.3.5-9 - rebuilt for Legacy Bugzilla #211760. - fixes CVE-2006-{4334,4335,4336,4337,4338}. * Sun Oct 01 2006 Jesse Keating [EMAIL PROTECTED] - 1.3.5-9 - rebuilt for unwind info generation, broken in gcc-4.1.1-21 * Wed Sep 20 2006 Ivana Varekova [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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. signature.asc Description: OpenPGP digital signature -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Re: lwn article on the death of Fedora Legacy
At 03:32 PM 10/24/2006, Jesse Keating wrote: On Tuesday 24 October 2006 18:21, Mike McCarty wrote: These are interesting stats, and indicate that Linux may now be crossing the gap. I belive most offices are still firmly MS product houses, and a move to Linux would not even be considered. I know that every time I see a request for a resume, the format requested is MS Word. Just because it's MSWord doesn't mean it is Windows... and even OpenOffice can export as Word native... so if someone wants Word format, Linux can deliver, as is PDF... It's funny that if you create a text file, and put that MS specific .DOC extension, Word can read it just fine... it has converters to do that, and most corporate installs have it already in place. Try it, you'll see... Use on the desktop should not be tied to use in the server room. You'll find a MUCH higher usage of linux in the server room. However since the majority of the desktops are Windows, MS Word gets used a lot. A really open cross platform format should be used, such as PDF, but that's not a here nor there question. Linux is great in the server room/network closet. Linux runs every one of my servers on my home LAN, and I've been an advocate of Linux in the enterprise space to supplement/replace other platforms for servers. We can do it faster/better/cheaper (pick any three) in this arena... On the desktop, it's another story... Sorry if I'm getting a tad bit into advocacy... The KDE/Gnome folks have made excellent progress when you compare it to the shell or to CDE/OpenWindows... and it's a long way from NextStep (although OpenStep is working hard to resolve that vector). The Linux Desktop - It's similar to where MacOS was in the early days of System6, and Windows 3.1 days... and those days weren't bad. The Windows Program Manager/File Manager was a good shell to launch modal applications, and Mac's Finder in System6 isn't much different as compared to what Gnome is using. MacOS6 plus MultiFinder Win's OLE API's and Mac's Publish/Subscribe model at the system level is not really prevalent on the Linux desktop as of yet, however XMPP is a good step forward, if the desktop and apps folks buy into it... There's a long way to go before Linux can really challenge WindowsXP and OSX on the desktop... challenge is good, it motivates folks, and that may be the bridge to resolving the main Linux desktop problem, which is the KDE/Gnome issue. Until this is resolved, Linux will remain in the server room, where it is very suited, and will suffer on the desktop. Just my $0.02 worth... Tim -- Do not dwell in the past, do not dream of the future, concentrate the mind on the present moment. -Buddha -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.408 / Virus Database: 268.13.11/493 - Release Date: 10/23/2006 -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Re: lwn article on the death of Fedora Legacy
On Tuesday 24 October 2006 10:19, Mike McCarty wrote: Gene Heskett wrote: [snip] Maybe the question we should be asking is: Can we do this? We don't have the number of people that Debian Security has on supporting old releases.. and because we have fallen so far behind with everything.. can we dig ourselves out.. or do we need to completely reboot the whole thing (new people, new goals, new name) with the new people really knowing that A) we arent going to get much help from 3rd party vendors B) we arent going to get much help from the community I'd comment that for this fedora user at least, the security etc stuffs should be extended at least to the point where we each of us, has a system, old though it may be in FC years, that works and does everything WE want it to do. Hi, Gene. I haven't been around here for a while. Nice to see something from you. That's my situation, too. But I don't think that the FC project is really set up for that. I use FC2, and when I finally bite the bullet and feel it imperative to upgrade it won't be to FCx. That isn't what FC is about, it seems. For the reason you give, it doesn't really suit my needs. Throwing us to the wolves doesn't make me want to format and update at anywhere near the release cycle for FC. My email archive alone goes back into 1998 here. Yes, there are backups, and I do them rather religiously Umm, FC didn't exist in 1998. Of course not, but RH5 did. Anyway, FC is really for tinkerers, not for people who want a distro that just works. I installed it because I was asked to do so by a company which hired me for a contract. For my *own* needs, Debian would have been better. Much slower release cycle. Fewer defects. But I'm not about to do this every 6 months as planned by the FC people, I Well, that's what FC *is*. I have several friends who have started using Linux over the last few years, and we are all going through culture shock at what is called QA in the Linux World. FC, even in Linux terms, is a use at your own risk kind of distro. Not that care isn't taken, but stuff is gonna break when a new release comes out. So we've noticed, and its the really blatant breakage that irks us the most, like FC4's x crashing on probably half the boxes at the initial reboot. With no clues of course because the only way to get to the logs was to reboot from the cd in single mode. And not being fam with the mount tree, the logs are hard to find. But, that FC4 fiaso that had many of us threatening to burn someone at the stake did help in that it brought the attention of TPTB that additional checking and bodies needed to be assigned to the FC releases, and that additional effort can certainly be seen in the overall quality of the FC5 release. Unforch, now I'm reading between the lines and coming to the conclusion that fedora is again being body starved. We'll see in a couple of days I guess. If you don't want installing the OS to be a hobby, perhaps you should consider a different distro. I know I am. Yup, I have one kubuntu box now running emc2-head, and there may be a kubuntu install on this box in another few weeks. Although, after the initial fixups of FC5 on my lappy, its all working pretty well, so the coin with kubuntu 6.10 on one side, and FC6 on the other, is still up in the air. Kubuntu's main problem is the cups install is about half, like one testical didn't come down, so there's a lot of wheels to reinvent there before cups does its thing with networked printers. I made it work by copying stuff off other working systems, thank $favorite-deity for samba someone telling me howto make a real root account on a kubuntu box... 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. -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Re: lwn article on the death of Fedora Legacy
On Tuesday 24 October 2006 10:23, Mike McCarty wrote: Matthew Miller wrote: [snip] Using the Chasm marketing model [*], without Legacy, Fedora is only a viable solution for Early Adopters and of dubious value to the second Pragmatist group. However, Fedora has been enough of a success that many Pragmatists are indeed using Fedora. I'm not familiar with that, but I'll look into it. I agree with your statement. I couldn't say it any better either. This results in large numbers of FC2, FC3, FC4 machines in production beyond their supported lifetime. Pragmatists, by their nature, don't wanna be upgrading all the time. Without Legacy, they're best served by CentOS and kin. That's fine, but it's a loss for Fedora, as they're then less likely to feed back into Extras, etc. And it's also a problem because it results in large numbers of potentially vulnerable machines in the wild. You have struck a very large nail upon the head with perfect orthogonality. I'm using FC2 here. Ditto, albeit with lots of stuff installed from tarballs because so much of FC2 was considerably more broken. IMO to release that without any kde testing should have been a no-no. As it was, just waving the mouse over a printing function in a kde menu brought the box down. Thats NOT good PR for fedora. Fedora people repeatedly state that the distribution is great for users beyond the tech-enthusiast Earlier Adopters. But without Legacy, it's really not true. Indeed. This is a statement which I have made on several occasions, only to be hooted down. Well, in my case I picked a distro that spoke english, then fixed what needed to be fixed. That wasn't as easy as it should have been when one can't stand the gnome's constant nagging about being root, dammit its my machine, why the heck should I put another million miles on my mouse getting rid of nag windows cause I'm root! That meant that cups, gimp, imagemajik, kino, qt and kde all got installed outside the rpm box from tarballs that FC2 would never backport even though what they had was broken. Now kino has died due to kernel changes (currently running 2.6.19-rc3), so the next vcd I make will be on my lappies teeny little 60GB partition for linux. Or on this box after I put FC6||kubuntu on it. Would the world be worse off if fedora died? Obviously yes, even for the pragmatists. We all bet on our favorite horse you know. 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. -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Re: Some supporting ideas regarding fedora legacy project when FC6 is out today
On Tuesday 24 October 2006 14:52, Robinson Tiemuqinke wrote: But FC5 and FC6 are released too closely -- only three months apart. while FC4 had released over one year before FC5 appeared. Where the heck are you getting your figures? FC5 was released 3/20/2006, FC4 was released 6/13/2005, that's 9~ months. FC6 was released today, 10/24, about 7 months since FC5 was released. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) pgpZjNDJ5TZMg.pgp Description: PGP signature -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Re: Some supporting ideas regarding fedora legacy project when FC6 is out today
On 10/24/06, Robinson Tiemuqinke [EMAIL PROTECTED] wrote: But FC5 and FC6 are released too closely -- only three months apart. while FC4 had released over one year before FC5 appeared. Huh? There has been at least 6 months between each FC release. FC1 release: Nov 5 2003 FC2 release: May 18 2004 FC3 release: Nov 8 2004 FC4 release: Jun 13 2005 FC5 release: Mar 20 2006 FC6 release: Oct 24 2006 -Dave -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Re: Sorry for confusion -- Re: Some supporting ideas regarding fedora legacy project when FC6 is out today
Robinson Tiemuqinke wrote: Currently FC just scares aways small business users to Debian/Gentoo because the former have so short a lifespan. Without real business users play in these FC test-beds RHEL will die away shortly. Why do you think they will move to Debian or Gentoo? And why Debian or Gentoo? I really don't see the logic. If they like the Red Hat-way of running Linux they'll almost certainly prefer CentOS or RHEL if they like Fedora but want a longer life cycle. Nils Breunese. PGP.sig Description: Dit deel van het bericht is digitaal ondertekend -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Re: Some supporting ideas regarding fedora legacy project when FC6 is out today
Quoting Robinson Tiemuqinke [EMAIL PROTECTED]: Based on the above fact, one idea will flow out naturally: based on the limited resourses of fedora legacy groups, and facing losing users because limited legacy support is flatted to each FC legacy release. Is it possible to support only some subset of releases? We can take the following strategy: Sure. We can just support one release if we want. Kind of makes the project rather pointless though if we keep changing the rules constantly. The _ONLY_ way there is a justification for Fedora Legacy is if it has, and maintains, a schedule so that people can depend on it. Otherwise, there really is no point to it. 1, for each odd-numbered release, take it as a alpha version release, and don't support it with limited fedora legacy resources. So FC5, FC7, FC9 will not go into fedora legacy. and they will be in official(redhat) support status in no more than half year, or even a quarter. And people who unkowning install one of those and then find out about FL are just out of luck? 2, for each even-numbered release, take it as a post-beta version release. these version will stay in official support for more than one year like FC4, then after its ending of official support, the release will go to fedora legacy for another one and half years or even longer based on resources. This implies that Fedora Core will support the even numbered releases for more than a year which is not something they will guarantee. So this won't work. This way we can bring FC releases back into the free RH years since RH6.0 to RH9, helpful for FC, RH and users. I don't understand what you are trying to say here. You want to reduce support, then you compare that to the fantastic support of the old RHL days? Doesn't make any sense to me. If FL is to have any trust from the users and Fedora community, it _must_ keep a support schedule, and not change it willy nilly. (Actually, it is okay to extend support for something, or even reduce support for future unreleased versions, but not to reduce or eliminate support that was already promised for a release that is already in use). -- Eric Rostetter The Department of Physics The University of Texas at Austin Go Longhorns! -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Re: lwn article on the death of Fedora Legacy
On 10/24/06, Mike McCarty [EMAIL PROTECTED] wrote: Stephen John Smoogen wrote: On 10/20/06, Matthew Miller [EMAIL PROTECTED] wrote: On Fri, Oct 20, 2006 at 09:36:15AM -0600, Stephen John Smoogen wrote: The problem is that we are just beat. Jesse has a kid, a release cycle, a new knee, and a lot of other stuff on his real job. The other people who have been doing stuff have also had 'stuff happen', and temporary schedule changes that have become permanent. Yes. In order to survive the project needs some real support from Red Hat. (Or some other large company who wants to do Red Hat a favor, but that seems even less likely.) Using the Chasm marketing model [*], without Legacy, Fedora is only a viable solution for Early Adopters and of dubious value to the second Pragmatist group. However, Fedora has been enough of a success that many Pragmatists are indeed using Fedora. I would argue that the pragmatists had been using it out of a trust model. They had used Red Hat Linux when it has crossed the chasm, and I don't believe that Linux in general has crossed the chasm yet. I think it's *all* still in the early adopters stage. But within the Linux community (oxymoron) FC is the early adopters of the early adopters. That would put you in the conservative column then. So far at the 3 10,000+ person companies I have worked at for the last 5 years, we have replaced 90% of our Solaris, AIX, mainframes etc with Linux. From what I have been helping with at other sites this has been the trend in the last 4 years. One site a friend works at just bought 5000 sun boxes. Although they each have a Solaris license, none of them will be using Solaris.. its just that the AMD hardware was considered better to run the clusters on. [snip] 2) I use Fedora to alpha/beta test for the next/current Red Hat Enterprise. How come when I state that FC is beta test, I get dog-piled, but you don't? Because I said I used Fedora as a beta test.. not that Fedora is a beta test. The two are not equal statements. Red Hat may not use it as such, but I as a consumer do. -- 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 -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Re: lwn article on the death of Fedora Legacy
On Tuesday 24 October 2006 18:21, Mike McCarty wrote: These are interesting stats, and indicate that Linux may now be crossing the gap. I belive most offices are still firmly MS product houses, and a move to Linux would not even be considered. I know that every time I see a request for a resume, the format requested is MS Word. Use on the desktop should not be tied to use in the server room. You'll find a MUCH higher usage of linux in the server room. However since the majority of the desktops are Windows, MS Word gets used a lot. A really open cross platform format should be used, such as PDF, but that's not a here nor there question. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) pgproA3J5P4VO.pgp Description: PGP signature -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Re: lwn article on the death of Fedora Legacy
Jesse Keating wrote: On Thursday 19 October 2006 11:44, Matthew Miller wrote: I think this is really unfortunate, because it makes a big gap in the Fedora ecosystem. This will be largely filled by migration to RHEL-rebuild distros like CentOS, which is well and good (and particularly painless from the end-user point of few) but bad for Fedora. 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. I can't speak for others, but going into Fedora Core, I knew what the limitations were, and I adjusted my expectations accordingly. I think what much it is boils down is to what is Fedora? It's a distro that is close to the tip of development on GNU/Linux, close enough to be cutting edge, but not so close to the tip to be useless. I knew this going in, and Fedora has done well for what I expected it to do. It's fairly stable, has up to date items for most of the things that I'm interested in for development, and let's me explore some of the items that are next step for RHEL... The realistic expectation is that SQA has been done for core and updates, along with extras... and that Fedora is not forever... If a longer life-cycle is desired, move over to RHEL/Clones... you'll be happier for it. Here is what I think can happen. A) Kill off RHL now. Stop trying to do stuff there when we just don't have the man power or the volunteers. Agreed, might get some flak here from others, but is Fedora Legacy the right place for supporting RHL? B) Move to using Extras infrastructure for building packages. They're ready for us for FC3 and FC4. Again, agreed... can prolong things to some extent... C) Move to Core style updates process. Spin a possible update, toss it in -testing. If nobody says boo after a period of time, release the darn thing. If somebody finds it to be broken, fix it and resubmit. For non-critical patches, this is more than fair... Somewhere in there convince Luke Macken to do the work to get a Fedora Update tool available for use externally that does the boring stuff like generate the email with the checksums and with the subpackage list and all that boring stuff. It could even handle moving the bug to 'MODIFIED' when it goes in updates-testing, and finally to CLOSED when it goes to release. Then it would be easier to get people to contribute, as they'd just be doing things like checking out a package module, copying a patch from somewhere, commit, build. That would help a lot. Somebody more senior in the project would fiddle with the tool to prepare the update, and do the sign+push. I honestly think that doing these things is the only way that Legacy will survive. What would be nice, in a perfect world, is that we change things... Dev/Stable/Maint... add one more level... Maint would be [security] updates only for -2 from current, Stable would be the previous release, and Dev would be the current release... on the eve of FC6 release (hopefully)... Dev - FC6 Stable - FC5 Maint - FC4 Obsolete - FC3 and earlier... And then increment once the next Development snapshot is formally released... Keeping that in mind, this reduces the load to Legacy, as Legacy can work through the maintainance of non-core/non-security updates, and this prolongs the Legacy releases... My biggest grip right now with moving from one snapshot to the next (i.e. from FC3 - FC4 or FC4- FC5) is that upgrading is not very clean. Sorry if this is a bit late... been busy in the real-world, but this is something that we can fix... both for supporting older releases as well as making the migration less painful... Tim -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Re: lwn article on the death of Fedora Legacy
On Fri, 20 Oct 2006, Eric Rostetter wrote: Quoting Jesse Keating [EMAIL PROTECTED]: And for a while Pekka was posting a list of all the work needed items. Was that not usable? I don't remember the discussion of a mailing list for bugs, Yes, it was, but as I said, I've not seen one for a while... Me not having sent the reminder doesn't mean that the bug list hasn't been updated. It has -- at least semi-regularly (once 1-2 days). I didn't bother because clearly the project failed to function some time ago and there didn't seem to be a point. -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Fedora-legacy open bugs; following them c
Hi Eric and all, Just as a point of information, if you all are interested in following already- existing Fedora Legacy bugs in Bugzilla, it is pretty easy if you have a Bugzilla account. All you need to do is, once logged in to Bugzilla, click the grey Account tab at the top of the page to get to your Bugzilla user preferences. Once there, click on the Email tab. That should put you on web-page https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email. There is a form entry on this page, Users to watch. If you enter [EMAIL PROTECTED] in that form, then suddenly you will be able to watch (that is get emails about) all bug activity happening on Fedora Legacy-related bugs, without having to be added to the [EMAIL PROTECTED] email alias by Jesse. Here are some bugs that have lately received at least some attention (that I am aware of): * Bug 209116 http://tinyurl.com/yz6n2e, openssl. A FC4 source package, openssl-0.9.7f-7.11.legacy, has been proposed for source-level 'PUBLISH' QA (are we still doing this?), and there are binary packages out there one can also look at and play with if one wants to. The openssl097a compatibility package still needs to be worked on for FC4. For FC3 (which maybe we can create a new Bug item for?), both its native openssl and its compatibility openssl096b packages need work. I have been hoping to get work done on these myself, but I am slow. Note that Red Hat employee Florian La Roche was kind enough to add some suggestions to make our work easier on this bug. * Bug 209167 http://tinyurl.com/yk284t, seamonkey. Seamonkey is the best we can do to fix Mozilla, because the Mozilla foundation has stopped supporting the Mozilla suite (web browser, email irc client) as of Mozilla-1.7.13. However, Seamonkey has up until now been produced by Fedora Extras, and Kai Engert has been its maintainer. Michal Jaegermann was kind enough to share information with us about his seamonkey replace- ment packages, and older versions for Red Hat/FC1/FC2 we can probably get from RHEL sources. So this bug is partly to work with Kai in getting the ball rolling and negotiating a (necessary, in my opinion) port of seamonkey from being an Extras package into becoming a Mozilla-replacement Core (Legacy) package, upon which other software (like epiphany and yelp) depend. That way we fix *all* Mozilla-related security bugs. * Other bugs needing some attention: - mailman (bugs 209891 for FC4, 211676 for FC3, I guess ). There is also a much older mailman bug report (bug #193843) that perhaps we can still get work done on for RHL 7.3, RHL 9, FC1 FC2. - openssh (bug 208727). Originally opened to deal with FC3, FC4, RHL 7.3 RHL 9 releases. - kernel (Bug 200034). Many patches were added for FC3 when this bug was being worked originally, but time has elapsed and this bug has grown stale. We now need packages for fc4 as well as fc3, since no doubt there are new kernel vulnerabilities since Legacy was given fc4. This bug was also opened to help RHL 7.3, RHL 9, FC1 FC2 distros. By the way, Pekka Savola (bless his heart!) still maintains his Fedora Legacy bug-list, here: http://www.netcore.fi/pekkas/buglist.html. There are also, no doubt, scores packages with security bugs that have never been filed in Bugzilla for FC3 and FC4. Like for firefox/thunderbird/httpd/ kdelibs/php/etc. etc. Hope this helped. Regards, David Eisenstein -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Re: Fedora-legacy open bugs; following them c
On Sat, Oct 21, 2006 at 04:29:15AM -0500, David Eisenstein wrote: * Other bugs needing some attention: ... - openssh (bug 208727). Originally opened to deal with FC3, FC4, RHL 7.3 RHL 9 releases. A comment #2, put there by David Eisenstein, :-) in bug 208727 mentions ftp://ftp.harddata.com/pub/Legacy_srpms/openssh-4.2p1-fc4.10.1mj.src.rpm Lifting fixes from RHEL packages and applying to other distribution sources does not look here like a very big deal. In general whatever is available in Legacy_srpms is surely in worksforme state and in an actual use. OTOH FC4 machines around me most likely pretty soon will be moved to FC6. Michal -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Re: lwn article on the death of Fedora Legacy
Quoting Pekka Savola [EMAIL PROTECTED]: Me not having sent the reminder doesn't mean that the bug list hasn't been updated. It has -- at least semi-regularly (once 1-2 days). Yep, but my point was that people like me, and I've often said on this list I'm basically lazy, want a push rather than pull system. I didn't bother because clearly the project failed to function some time ago and there didn't seem to be a point. I'm not disagreeing. Just answering Jesse's question to me. I do appreciate that you tried for so long to make a difference by maintaining the list and sending it to the list. At least you took and active role and tried to make things better. More than I can really give myself credit for really. You've been a great help to the project, at least IMHO. -- Eric Rostetter The Department of Physics The University of Texas at Austin Go Longhorns! -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Re: lwn article on the death of Fedora Legacy
Quoting Matthew Miller [EMAIL PROTECTED]: I know that personally I haven't been able to contribute the amount of time I'd like to make this succeed. But I have a full-time job and a young child, and am mildly active in umpteen other projects. Legacy support is hard work, and really needs two or three full-time workers to be a success. It's tempting to blame the lack of volunteers, but this sort of project works best if there's a solid base. I can't disagree with that. I think this is really unfortunate, because it makes a big gap in the Fedora ecosystem. This will be largely filled by migration to RHEL-rebuild distros like CentOS, which is well and good (and particularly painless from the end-user point of few) but bad for Fedora. I think it is good for everyone. RHEL and its clones have a different mission than Fedora, and people should use the one that fits their needs. The two fill different needs. 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. It is exactly what it is supposed to be. Yes, that is only part of the mission, the other major part being a test-bed for RHEL. The mission also includes helping developers, providing consistency of interfaces, and making the Fedora experience better for the end user. But the whole point of Fedora is to be leading/cutting edge, and you can't be leading edge with a long lifetime. Fedora Legacy is really only there to allow for a more flexible upgrade schedule for the users, not to extend the lifetime any real length of time. That is, maybe a particular site can only upgrade 2 times per year, and those times don't match with the Fedora Project release schedule. Fedora Legacy allows them to keep running the previous version in a _secure_ manor until their update window comes along. That's really all Fedora Legacy is for, as concerns Fedora Core (not Red Hat Linux, which is a slightly different issue). Now, maybe we've dropped the ball (on delivering the secure part of the promise). I won't argue that. Nor can I say exactly why the ball might have been dropped, or how best to pick it back up. -- Eric Rostetter The Department of Physics The University of Texas at Austin Go Longhorns! -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Re: lwn article on the death of Fedora Legacy
On 10/20/06, Nils Breunese (Lemonbit) [EMAIL PROTECTED] wrote: Matthew Miller wrote: I know that personally I haven't been able to contribute the amount of time I'd like to make this succeed. But I have a full-time job and a young child, and am mildly active in umpteen other projects. Legacy support is hard work, and really needs two or three full-time workers to be a success. It's tempting to blame the lack of volunteers, but this sort of project works best if there's a solid base. The Fedora Infrastructure team recently sent out an announce mail to let people know they could use a couple of extra hands. Already a couple of people mailed that team and said they could help out. Maybe Fedora Legacy should send out such an email? I think we sent out one before the Infrastructure team did.. -- 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 -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Re: lwn article on the death of Fedora Legacy
Quoting Jesse Keating [EMAIL PROTECTED]: 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. As noted, I disagree with the above statement. Here is what I think can happen. A) Kill off RHL now. Stop trying to do stuff there when we just don't have the man power or the volunteers. But, then there is no trust in the project. You said you would support it until December, and people depend on that. If you drop it now, then where is the trust? How can we be sure you will support FC5 for the length of time you claim, rather than just dropping it? Is 2 months really worth losing trust over? B) Move to using Extras infrastructure for building packages. They're ready for us for FC3 and FC4. Then why haven't we started doing this yet? C) Move to Core style updates process. Spin a possible update, toss it in -testing. If nobody says boo after a period of time, release the darn thing. If somebody finds it to be broken, fix it and resubmit. I think this is fine for FC releases. No problem... It is in line with the FC philosophy. Somewhere in there convince Luke Macken to do the work to get a Fedora Update tool available for use externally that does the boring stuff like generate the email with the checksums and with the subpackage list and all that boring stuff. It could even handle moving the bug to 'MODIFIED' when it goes in updates-testing, and finally to CLOSED when it goes to release. Then it would be easier to get people to contribute, as they'd just be doing things like checking out a package module, copying a patch from somewhere, commit, build. That would help a lot. Somebody more senior in the project would fiddle with the tool to prepare the update, and do the sign+push. Is he the only one who can do this stuff? Does he need help? I honestly think that doing these things is the only way that Legacy will survive. I agree with all but dropping RHL 2 months early. -- Eric Rostetter The Department of Physics The University of Texas at Austin Go Longhorns! -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Re: lwn article on the death of Fedora Legacy
Quoting Jesse Keating [EMAIL PROTECTED]: On Thursday 19 October 2006 12:04, Matthew Miller wrote: So RHL has been the hold-up there? In that case, *definitely* time to end RHL support; RHL != Fedora anyway. IMHO, Fedora Legacy was started for RHL, not FC, and the name is shouldn't dictate policy, the original purpose should dictate policy. My thoughts too. I keep trying to be nice to these people, and they never help out. So screw 'em. /personal opinion Yeah, and when offers of help are met with resistence, people do tend to not help out. When people say stuff like So screw 'em then people tend to not help out. I really, really think the bugzilla process should be moved to be more normal, too -- one bug # per release, even if the issue is identical in FC3 and FC4. (That's why there's the clone bug bugzilla feature.) Absolutely. This works much better when the update tool can automanage bugs, so that each gets closed when the update goes out, and we're not so tied to every release must be fixed for the bug to be closed. (note, there can be a top level tracker but for the CVE itself, and individual bugs are cloned for each vuln Fedora release) So, hey, here's an idea: Let's do that! What's the hold up? C) Move to Core style updates process. Spin a possible update, toss it in -testing. If nobody says boo after a period of time, release the darn thing. If somebody finds it to be broken, fix it and resubmit. Yes. Better this than nothing. No problem for FC releases. Since there is only 2 months left on RHL, there isn't much of a problem there either (in particular if you set the period of time to be a month or one week before the EOL date, which ever comes first. Yes. How much work will this convincing take? Does he accept bribes? I think he does. A lot of it is a time issue. Again, could he use help with this? If so, what kind of help? Even gentle encouragement? Or money? Or coding support? Or documentation support? Or??? -- Eric Rostetter The Department of Physics The University of Texas at Austin Go Longhorns! -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Re: lwn article on the death of Fedora Legacy
On Friday 20 October 2006 10:48, Eric Rostetter wrote: IMHO, Fedora Legacy was started for RHL, not FC, and the name is shouldn't dictate policy, the original purpose should dictate policy. Actually no. Fedora Legacy came from when Fedora was created. Fedora Alternatives and Extras were other proposed projects. I picked up Legacy because I wanted to provide Fedora to my customers, and provide them a slightly longer life span. I was persuaded to do updates for RHL too, which I really think was a mistake. My thoughts too. I keep trying to be nice to these people, and they never help out. So screw 'em. /personal opinion Yeah, and when offers of help are met with resistence, people do tend to not help out. When people say stuff like So screw 'em then people tend to not help out. Where we need help is testing packages, reporting and vetting issues (not just 'hey this CVE was filed, does it effect us?' Actually LOOK at the package and package sources to see, perhaps provide a patch? Where are you meeting resistance doing this kind of work? I really, really think the bugzilla process should be moved to be more normal, too -- one bug # per release, even if the issue is identical in FC3 and FC4. (That's why there's the clone bug bugzilla feature.) Absolutely. This works much better when the update tool can automanage bugs, so that each gets closed when the update goes out, and we're not so tied to every release must be fixed for the bug to be closed. (note, there can be a top level tracker but for the CVE itself, and individual bugs are cloned for each vuln Fedora release) So, hey, here's an idea: Let's do that! What's the hold up? Getting software in place. Time. Energy. C) Move to Core style updates process. Spin a possible update, toss it in -testing. If nobody says boo after a period of time, release the darn thing. If somebody finds it to be broken, fix it and resubmit. Yes. Better this than nothing. No problem for FC releases. Since there is only 2 months left on RHL, there isn't much of a problem there either (in particular if you set the period of time to be a month or one week before the EOL date, which ever comes first. Yes. How much work will this convincing take? Does he accept bribes? I think he does. A lot of it is a time issue. Again, could he use help with this? If so, what kind of help? Even gentle encouragement? Or money? Or coding support? Or documentation support? Or??? I don't know. Email him. Find out. He's on the fedora infrastructure team which has this listed as one of the projects. http://fedoraproject.org/wiki/Infrastructure Don't wait on me to make it happen. -- Jesse Keating Release Engineer: Fedora pgp9qqENtwraL.pgp Description: PGP signature -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Re: lwn article on the death of Fedora Legacy
On Friday 20 October 2006 10:52, Eric Rostetter wrote: You're misunderstanding me; I meant RHL has been the hold-up for switching to the Extras build infrastructure. Can't we somehow run the two build systems in parallel? Use the old one for RHL, and test the new one out for FC releases? That way we also get a good test in, and have a backup if the new build system isn't working right, etc. Only if we agree to split RHL updates from Fedora updates and nothold one up for the other. -- Jesse Keating Release Engineer: Fedora pgpTrcH3J1zGu.pgp Description: PGP signature -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Re: lwn article on the death of Fedora Legacy
On Friday 20 October 2006 11:36, Stephen John Smoogen wrote: I just have enough time currently to answer questions for people on #fedora-legacy, trying to put in 10-20 hours to qa a package because I don't know how much qa it really takes to ship a fix (especially after all the negative feedback when we put out a patch that 'broke' systems). Yikes, 10-20 hours seems CRAZY. It built, patch applied, app launches, push it as a testing update. (sure you could do a LITTLE more testing, but trying to fit 20 hours of heavy qa on an app is just silly) -- Jesse Keating Release Engineer: Fedora pgpILFvYZ3h85.pgp Description: PGP signature -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Re: lwn article on the death of Fedora Legacy
On Friday 20 October 2006 12:21, Jesse Keating wrote: Yikes, 10-20 hours seems CRAZY. It built, patch applied, app launches, push it as a testing update. (sure you could do a LITTLE more testing, but trying to fit 20 hours of heavy qa on an app is just silly) I should note that the only way we'll REALLY know its qad is if people use it in similar setups to their system, and updates-testing is usually the only way to get packages to them for testing. -- Jesse Keating Release Engineer: Fedora pgpYq6GwHySpv.pgp Description: PGP signature -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Re: lwn article on the death of Fedora Legacy
On Fri, Oct 20, 2006 at 10:59:39AM -0400, Jesse Keating wrote: Only if we agree to split RHL updates from Fedora updates and nothold one up for the other. This is another benefit of one bug per distro release. FC3 packages shouldn't hold up FC4, for that matter. -- Matthew Miller [EMAIL PROTECTED] http://mattdm.org/ Boston University Linux -- http://linux.bu.edu/ -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Re: lwn article on the death of Fedora Legacy
On Friday 20 October 2006 11:36, Stephen John Smoogen wrote: On 10/20/06, Jesse Keating [EMAIL PROTECTED] wrote: On Friday 20 October 2006 10:48, Eric Rostetter wrote: IMHO, Fedora Legacy was started for RHL, not FC, and the name is shouldn't dictate policy, the original purpose should dictate policy. Actually no. Fedora Legacy came from when Fedora was created. Fedora Alternatives and Extras were other proposed projects. I picked up Legacy because I wanted to provide Fedora to my customers, and provide them a slightly longer life span. I was persuaded to do updates for RHL too, which I really think was a mistake. I am getting deja-vu from the last time we tried fixing things about 6 months ago. I think the problem isn't RHL updates, Fedora updates etc. The problem is that we are just beat. Jesse has a kid, a release cycle, a new knee, and a lot of other stuff on his real job. The other people who have been doing stuff have also had 'stuff happen', and temporary schedule changes that have become permanent. I just have enough time currently to answer questions for people on #fedora-legacy, trying to put in 10-20 hours to qa a package because I don't know how much qa it really takes to ship a fix (especially after all the negative feedback when we put out a patch that 'broke' systems). Most of the other people who have been really interested in the project have been interested in a certain release (FC1, RHL-7.2, etc) and once we stopped supporting it, they went away. I really do not know of anyone new who has wanted to support FC-4 or FC-5 in 4 months. Maybe the question we should be asking is: Can we do this? We don't have the number of people that Debian Security has on supporting old releases.. and because we have fallen so far behind with everything.. can we dig ourselves out.. or do we need to completely reboot the whole thing (new people, new goals, new name) with the new people really knowing that A) we arent going to get much help from 3rd party vendors B) we arent going to get much help from the community I'd comment that for this fedora user at least, the security etc stuffs should be extended at least to the point where we each of us, has a system, old though it may be in FC years, that works and does everything WE want it to do. Throwing us to the wolves doesn't make me want to format and update at anywhere near the release cycle for FC. My email archive alone goes back into 1998 here. Yes, there are backups, and I do them rather religiously at the feet of a gal named amanda, but it would still be a weeks work to get stuff back to the Just Works(TM) state here if I was to put FC5 on this box today. But after an extended rattlesnake sorting session on my lappy, FC5 is now looking working pretty good, so FC6 will probably get installed when its out or shortly after. But I'm not about to do this every 6 months as planned by the FC people, I have other things these machines need to do, and do on a set it up in cron so I can forget about it scenario. My $0.02, adjust for inflation. :-) C) etc -- 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. -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Re: lwn article on the death of Fedora Legacy
On Fri, Oct 20, 2006 at 10:59:13AM -0400, Jesse Keating wrote: Where we need help is testing packages, reporting and vetting issues (not just 'hey this CVE was filed, does it effect us?' Actually LOOK at the package and package sources to see, perhaps provide a patch? Where are you meeting resistance doing this kind of work? Although, hey, this CVE was filed, does it affect us in bugzilla is helpful too as a starting point -- a lot of issues which do affect us aren't even that far along at this point. -- Matthew Miller [EMAIL PROTECTED] http://mattdm.org/ Boston University Linux -- http://linux.bu.edu/ -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Re: lwn article on the death of Fedora Legacy
On Fri, Oct 20, 2006 at 09:36:15AM -0600, Stephen John Smoogen wrote: The problem is that we are just beat. Jesse has a kid, a release cycle, a new knee, and a lot of other stuff on his real job. The other people who have been doing stuff have also had 'stuff happen', and temporary schedule changes that have become permanent. Yes. In order to survive the project needs some real support from Red Hat. (Or some other large company who wants to do Red Hat a favor, but that seems even less likely.) Using the Chasm marketing model [*], without Legacy, Fedora is only a viable solution for Early Adopters and of dubious value to the second Pragmatist group. However, Fedora has been enough of a success that many Pragmatists are indeed using Fedora. This results in large numbers of FC2, FC3, FC4 machines in production beyond their supported lifetime. Pragmatists, by their nature, don't wanna be upgrading all the time. Without Legacy, they're best served by CentOS and kin. That's fine, but it's a loss for Fedora, as they're then less likely to feed back into Extras, etc. And it's also a problem because it results in large numbers of potentially vulnerable machines in the wild. Fedora people repeatedly state that the distribution is great for users beyond the tech-enthusiast Earlier Adopters. But without Legacy, it's really not true. * http://www.ericsink.com/Act_Your_Age.html -- Matthew Miller [EMAIL PROTECTED] http://mattdm.org/ Boston University Linux -- http://linux.bu.edu/ -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Re: lwn article on the death of Fedora Legacy
On Fri, Oct 20, 2006 at 08:58:33AM -0400, James Kosin wrote: E) See if any Fedora Core engineers are interested in, out of the goodness of their hearts, building updates for their packages in Legacy when it isn't much extra work -- and enabling them to easily do so. The only problem with this is WHY ever go with the latest FC6 or 7 or whatever if you can have the packages updated to the latest even if you have FC2. I really don't think that's a major concern. Most packages wouldn't be updated to the newest version -- just the ones where that's the easiest thing to do. Legacy is all about security-updates!!! ONLY!!! The policy is update with PATCHES if at all possible. From RH even better; otherwise fall back to other sources for patches such as the development groups, etc. Only if EVERYTHING else fails, you can update to the latest stable release to fix the flaw. Right now, everything is clearly failing. -- Matthew Miller [EMAIL PROTECTED] http://mattdm.org/ Boston University Linux -- http://linux.bu.edu/ -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Re: lwn article on the death of Fedora Legacy
Quoting Jesse Keating [EMAIL PROTECTED]: On Friday 20 October 2006 10:52, Eric Rostetter wrote: You're misunderstanding me; I meant RHL has been the hold-up for switching to the Extras build infrastructure. Can't we somehow run the two build systems in parallel? Use the old one for RHL, and test the new one out for FC releases? That way we also get a good test in, and have a backup if the new build system isn't working right, etc. Only if we agree to split RHL updates from Fedora updates and nothold one up for the other. Fine with me. -- Jesse Keating Release Engineer: Fedora -- Eric Rostetter The Department of Physics The University of Texas at Austin Go Longhorns! -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Re: lwn article on the death of Fedora Legacy
On Friday 20 October 2006 13:58, Eric Rostetter wrote: First, my interest doesn't really fit there. It is in testing what is in updates-testing (which is nothing). If there was something in updates-testing to test, I would test it and report the results. Its tough to get to updates-testing without the pre-work done. So thats where we need the help right now. Secondly, I've offered to help many times with other infrastructure issues, and been turned down over and over. Where? When? You refused to use IRC, you've refused to even try to get a wiki account. Third, when I've tried to help test packages before updates-testing, I met with lots of trouble. Someone: No, you have to do this, this way, not that way! Me: Okay, where's that documented? Someone: No where. Me: Okay, I'll document that and resubmit Someone: No, you still missed Step X. Me: Okay, where is that documented? Someone: No where. Me: Okay, I'll document that... And so on. Eventually of course, my documentation is no longer good because it is a web page and now it should all be wiki, and I don't have access to the wiki. By the time I finally get access to the wiki, I've lost interest. When did you try to get a wiki account? We always welcome more documentation. Third, I had a big project that took about a year of my life, during which I could not spend a lot of time of FL work. That is over now, and I could go back to working on FL again, but I really don't see where I'm needed now. I've outlined what help we need. The fact that I only have one FC machine to play with (FC 3 x86_64 now, could upgrade to FC4 or what ever if needed) doesn't help. I'm willing to put it towards FL work if you tell me what you need me to do. But you can't expect me to do everything any more than I expect you to do everything. And as long as you keep refusing my offers to help saying you'll do it yourself, you won't get many unsolicited offers from me, so you better start soliciting if you want anything. So, hey, here's an idea: Let's do that! What's the hold up? Getting software in place. Time. Energy. Is there anything I can do to help, or not? Again, I don't know, you'd have to ask Luke and / or the Infrastructure team. Again, could he use help with this? If so, what kind of help? Even gentle encouragement? Or money? Or coding support? Or documentation support? Or??? I don't know. Email him. Find out. He's on the fedora infrastructure team which has this listed as one of the projects. http://fedoraproject.org/wiki/Infrastructure Don't wait on me to make it happen. Is there a particular reason to contact only him instead of the whole infrastructure team? Mostly because he owns the project. -- Jesse Keating Release Engineer: Fedora pgpAxNbXQG0oY.pgp Description: PGP signature -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Re: lwn article on the death of Fedora Legacy
Quoting Matthew Miller [EMAIL PROTECTED]: Fedora people repeatedly state that the distribution is great for users beyond the tech-enthusiast Earlier Adopters. But without Legacy, it's really not true. It is only good for tech-savy people who can upgrade outside of pre-set windows. Legacy extends this to tech-savy people who can upgrade at some point during the year. Someday the Fedora Documentation Project along with Fedora Legacy (if it survives) may extend this to non-tech-savy people who can upgrade within a year... Let's face it. Fedora Legacy use is limited. The fact that some Fedora people say otherwise doesn't make it true. -- Eric Rostetter The Department of Physics The University of Texas at Austin Go Longhorns! -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Re: lwn article on the death of Fedora Legacy
On Fri, Oct 20, 2006 at 01:19:08PM -0400, Gene Heskett wrote: My email archive alone goes back into 1998 here. Yes, there are backups, and I do them rather religiously at the feet of a gal named amanda, but it would still be a weeks work to get stuff back to the Just Works(TM) state here if I was to put FC5 on this box today. Eh? How come? Not that I am trying to tell you upgrade right now but I have around machines which went through numerous release upgrades, some with original installations dating back to times of RH6.x realeases or maybe even earlier, and it never took me weeks to do such thing. Rather small hours when most of the time I was doing something else when a machine was busy installing updated packages. I am not trying to imply that there is no work involved. It is easier when you can do that over a network or from DVD, or otherwise you have to babysit a machine and switch CDs from time to time, but I never had a situation that such operation destroyed my data or made a machine inoperable. It is also true that after such step there is some cleanup to perform; but with possible small exceptions this is not extremely urgent and can be done here and there at your leisure. 'rpm -qa --last' will make you a list where possible leftovers are easy to pick up and you should go through assorted '.rpmnew' and '.rpmsave' files. 'locate' is of a great help here after you updated its database. On some occasions I did even such nasty things as 'rpm -Uvh --nodeps fedora-release*', with that rpm from a target distro, followed by 'yum update yum* rpm* python*' and after that 'yum update ...' (various things as needed), but such trickery may require assorted manual interventions which depend on what you really have already installed and falls into if you have to ask how to do that you should not be doing it category. Still it worked fine in the final account (with a different set of tradeoffs than a normal update). Yes, I know that some claim that to upgrade a release one should do an install from scratch and restore personal data from backups. Unless you really messed up previously your installation doing things like 'rpm --Uvh --nodeps ...' all over the place, and other nasties of that sort, this is misguided. But after an extended rattlesnake sorting session on my lappy, FC5 is now looking working pretty good, so FC6 will probably get installed when its out or shortly after. But I'm not about to do this every 6 months as planned by the FC people, I have other things these machines need to do, and do on a set it up in cron so I can forget about it scenario. My $0.02, adjust for inflation. :-) C) etc -- 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. -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Re: lwn article on the death of Fedora Legacy
Quoting Jesse Keating [EMAIL PROTECTED]: On Friday 20 October 2006 13:58, Eric Rostetter wrote: First, my interest doesn't really fit there. It is in testing what is in updates-testing (which is nothing). If there was something in updates-testing to test, I would test it and report the results. Its tough to get to updates-testing without the pre-work done. So thats where we need the help right now. Yes, true. But, like I said, you can't expect one person to do everything... If we had a way to know what work needed to be done, it might be easier for people like me to help. Long ago I suggested that there be a mailing list for entries in bugzilla, and while it was received well by many on this list, it was rejected by you. If I got an e-mail saying we need to test package X, and I decided I could test package X, I would do it. But I don't have the time to go crawling through bugzilla looking to see what needs to be tested, and I've not seen a mailing to this list lately with a list of things that needed testing. In other words, I personally respond better to a push to me of what is needed than having to expend effort to pull what is needed from various sources. Secondly, I've offered to help many times with other infrastructure issues, and been turned down over and over. Where? When? You refused to use IRC, you've refused to even try to get a wiki account. Yes, I basically refuse to use IRC. If that means I can't help with FL, then so be it. That's your problem. My requests to help go back to the beginning, like setting up CVS for the web site, a web-interface to the CVS, a mailing list for the CVS, etc. You refused all that help, saying you already planned to do that kind of stuff and would do it yourself, etc. You did setup the CVS, but none of the rest. I've never managed to get access to change bugzilla entry white boards, etc. though I've asked about it, etc. As for a wiki access, I _did_ get it. But, I'm really never been sure how you plan to split the web site and wiki, if at all, and what you want done, and personally I _hate_ the idea of putting everything in the wiki. I specifically hate putting the advisories in the wiki, but you say you want to. Well, so be it, but I've not seen any work done to do it, and I've not been asked to help in doing so. I'll document that... And so on. Eventually of course, my documentation is no longer good because it is a web page and now it should all be wiki, and I don't have access to the wiki. By the time I finally get access to the wiki, I've lost interest. When did you try to get a wiki account? We always welcome more documentation. I _did_ get access to the wiki (though I don't know if it still works or not). In fact I say that above where you quote me. Third, I had a big project that took about a year of my life, during which I could not spend a lot of time of FL work. That is over now, and I could go back to working on FL again, but I really don't see where I'm needed now. I've outlined what help we need. No, you said we need lots of stuff. I said, okay, I'm trying to do some of that stuff. You said, no, we need this other stuff since the stuff I want to do can't be done until the other stuff is done... Well, fine, if I have to do that other stuff I'm willing, if it is made easy for me to do. Is anyone willing to make it easier for me to do? Again, I don't know, you'd have to ask Luke and / or the Infrastructure team. I'll reread the thread, and _if_ I understand what is desired, I'll approach them about it. If not, then I'll _try_ to get someone here to explain to me what it is I'm supposed to ask them. -- Eric Rostetter The Department of Physics The University of Texas at Austin Go Longhorns! -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Re: lwn article on the death of Fedora Legacy
Quoting Jesse Keating [EMAIL PROTECTED]: But I don't have the time to go crawling through bugzilla looking to see what needs to be tested, and I've not seen a mailing to this list lately with a list of things that needed testing. In other words, I Please read the above. And for a while Pekka was posting a list of all the work needed items. Was that not usable? I don't remember the discussion of a mailing list for bugs, Yes, it was, but as I said, I've not seen one for a while... there is a '[EMAIL PROTECTED]' email alias, if you want on that, by all means I'll add you. I do know that I don't want bug discussion to happen on a list and out of the bug. Correct, it should be a one-way mailing only. Yes, if you want me to help, please add me to [EMAIL PROTECTED] When this was happening, I had thought you had left the project, so it wasn't much of a thought process. I've never left the project, I've just become much less active in it. I would like EVERYTHING except advisories (see above) and the GPG keys. David Eisenstein has done a lot of work of porting some content over, I'm sure he'd like a hand with that. I like the wiki as it is a LOT lower overhead to contribute content, make updates as things change, refine processes, interlink with other Fedora documentation such as how to use the CVS system, how to get an account, how to use the build system, etc... Okay, I'll take you at your word on the above. And I'll just keep my own opinions about it to myself where they belong. -- Eric Rostetter The Department of Physics The University of Texas at Austin Go Longhorns! -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Re: lwn article on the death of Fedora Legacy
On Friday 20 October 2006 15:16, Eric Rostetter wrote: Yes, if you want me to help, please add me to [EMAIL PROTECTED] You've been added. -- Jesse Keating Release Engineer: Fedora pgpYLRQYfyfNc.pgp Description: PGP signature -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Re: lwn article on the death of Fedora Legacy
On 10/20/06, Matthew Miller [EMAIL PROTECTED] wrote: On Fri, Oct 20, 2006 at 09:36:15AM -0600, Stephen John Smoogen wrote: The problem is that we are just beat. Jesse has a kid, a release cycle, a new knee, and a lot of other stuff on his real job. The other people who have been doing stuff have also had 'stuff happen', and temporary schedule changes that have become permanent. Yes. In order to survive the project needs some real support from Red Hat. (Or some other large company who wants to do Red Hat a favor, but that seems even less likely.) Using the Chasm marketing model [*], without Legacy, Fedora is only a viable solution for Early Adopters and of dubious value to the second Pragmatist group. However, Fedora has been enough of a success that many Pragmatists are indeed using Fedora. I would argue that the pragmatists had been using it out of a trust model. They had used Red Hat Linux when it has crossed the chasm, and were using Fedora out of the same trust model. However, Fedora seems to have only been for Early Adopters. Legacy was an added on idea by people who realized that if you are going to put service software in an OS, people arent going to want to upgrade every 6 months. The problem with that is that maintaining an OS is always more effort/cost than creating it. That is why Pragmatists, Conservatives, and Laggards are better suited with an Enterprise linux. The problem with trying to stay on the Early Adopter side is that they will most likely drop you for the next shiney thing (Gentoo 3 years ago, Ubuntu today, xPath in 3 years) Fedora people repeatedly state that the distribution is great for users beyond the tech-enthusiast Earlier Adopters. But without Legacy, it's really not true. To be honest, there are only 2 reasons I use Fedora these days: 1) I drank the Bob Young koolaid long ago, and I am too much an RPM man to change to something else.. and 2) I use Fedora to alpha/beta test for the next/current Red Hat Enterprise. Even if Red Hat does not use Fedora as a alpha/beta test for Red Hat Enterprise.. I and many other people who are RHEL/Centos/etc customers do. I use Fedora because I need to know what the next RHEL will have in it. I use it to see what tools in extras I can pull over to my production systems because I need a plone, git, or other tool for some project. I do like having the nice new distro every 6 to 9 months, but I don't get paid to have it... and I am not longer the young kid who has time to twiddle with all the nobs to find out why something isnt working. * http://www.ericsink.com/Act_Your_Age.html Heh. I hadn't seen that for a long time. Erik Sink was sort of my boss before I went to work for Red Hat. The books Crossing the Chasm and Inside the Tornado should be required reading for anyone dealing with emerging markets. -- 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 -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
lwn article on the death of Fedora Legacy
http://lwn.net/Articles/204722/ This is subscriber-only content for two weeks, but the gist is: there's a whole lotta unpatched vulnerabilities in FC4. Can we really pretend this is an ongoing concern? I know that personally I haven't been able to contribute the amount of time I'd like to make this succeed. But I have a full-time job and a young child, and am mildly active in umpteen other projects. Legacy support is hard work, and really needs two or three full-time workers to be a success. It's tempting to blame the lack of volunteers, but this sort of project works best if there's a solid base. When Jesse Keating worked at Pogo, that was largely true, but with his duties at RH and with his new kid, it doesn't seem to be the case anymore. I'm sure this is not Jesse's fault -- there needs to be commitment from above, and that's clearly not the case. I think this is really unfortunate, because it makes a big gap in the Fedora ecosystem. This will be largely filled by migration to RHEL-rebuild distros like CentOS, which is well and good (and particularly painless from the end-user point of few) but bad for Fedora. 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. -- Matthew Miller [EMAIL PROTECTED] http://mattdm.org/ Boston University Linux -- http://linux.bu.edu/ -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Re: lwn article on the death of Fedora Legacy
On Thursday 19 October 2006 11:44, Matthew Miller wrote: When Jesse Keating worked at Pogo, that was largely true, but with his duties at RH and with his new kid, it doesn't seem to be the case anymore. I'm sure this is not Jesse's fault -- there needs to be commitment from above, and that's clearly not the case. I think this is really unfortunate, because it makes a big gap in the Fedora ecosystem. This will be largely filled by migration to RHEL-rebuild distros like CentOS, which is well and good (and particularly painless from the end-user point of few) but bad for Fedora. 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. Here is what I think can happen. A) Kill off RHL now. Stop trying to do stuff there when we just don't have the man power or the volunteers. B) Move to using Extras infrastructure for building packages. They're ready for us for FC3 and FC4. C) Move to Core style updates process. Spin a possible update, toss it in -testing. If nobody says boo after a period of time, release the darn thing. If somebody finds it to be broken, fix it and resubmit. Somewhere in there convince Luke Macken to do the work to get a Fedora Update tool available for use externally that does the boring stuff like generate the email with the checksums and with the subpackage list and all that boring stuff. It could even handle moving the bug to 'MODIFIED' when it goes in updates-testing, and finally to CLOSED when it goes to release. Then it would be easier to get people to contribute, as they'd just be doing things like checking out a package module, copying a patch from somewhere, commit, build. That would help a lot. Somebody more senior in the project would fiddle with the tool to prepare the update, and do the sign+push. I honestly think that doing these things is the only way that Legacy will survive. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) pgp6BazXvdPlf.pgp Description: PGP signature -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Re: lwn article on the death of Fedora Legacy
On Thu, 19 Oct 2006, Matthew Miller wrote: A) Kill off RHL now. Stop trying to do stuff there when we just don't have the man power or the volunteers. B) Move to using Extras infrastructure for building packages. They're ready for us for FC3 and FC4. So RHL has been the hold-up there? ... That is an incorrect conclusion. FWIW, Marc was the most active contributor, only interested in FC1, but willing to do the work for other versions as well. Up until some time ago, I was willing to help but my interest was only the RHLs but was willing ot do PUBLISH/VERIFY for other versions in order to get RHL updates. There were a couple of other people who did some VERIFYs and proposed a couple of packages. That's it. A better phrasing could maybe be that RHL/old distros was what kept FL going, because those had significant deployment base before people realized that trying to use Fedora and expect long maintenance wasn't a good idea (and hence folks moved to CentOS). You could say that there is some problem with the process if e.g., sendmail MIME vulnerability updates (which are declared ready) haven't been published during the 1.5 months they've been ready [1]. I guess the issue is that no one with privileges to send the notification or move stuff from updates-testing to updates has been around during that time. As a result, there are very few people left who care enough about FC3/FC4 updates. There just aren't enough people to do the job, and the machinery to do the job has been way too heavyweight for a long time. I guess one could still move the FC3/FC4 stuff to extras (instead of just declaring the project dead) but I doubt the number of contributors is going to rise dramatically as a result even if extras were used. Some administrative overhead would be reduced but you'd someone would still be needed to do the work. [1] http://netcore.fi/pekkas/buglist.html https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=195418 -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Re: lwn article on the death of Fedora Legacy
On Thu, Oct 19, 2006 at 08:57:31PM +0300, Pekka Savola wrote: On Thu, 19 Oct 2006, Matthew Miller wrote: A) Kill off RHL now. Stop trying to do stuff there when we just don't have the man power or the volunteers. B) Move to using Extras infrastructure for building packages. They're ready for us for FC3 and FC4. So RHL has been the hold-up there? ... That is an incorrect conclusion. You're misunderstanding me; I meant RHL has been the hold-up for switching to the Extras build infrastructure. time. I guess one could still move the FC3/FC4 stuff to extras (instead of just declaring the project dead) but I doubt the number of contributors is going to rise dramatically as a result even if extras were used. Some administrative overhead would be reduced but you'd someone would still be needed to do the work. Agreed. -- Matthew Miller [EMAIL PROTECTED] http://mattdm.org/ Boston University Linux -- http://linux.bu.edu/ -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Re: lwn article on the death of Fedora Legacy
On Thursday 19 October 2006 13:57, Pekka Savola wrote: As a result, there are very few people left who care enough about FC3/FC4 updates. There just aren't enough people to do the job, and the machinery to do the job has been way too heavyweight for a long time. I guess one could still move the FC3/FC4 stuff to extras (instead of just declaring the project dead) but I doubt the number of contributors is going to rise dramatically as a result even if extras were used. Some administrative overhead would be reduced but you'd someone would still be needed to do the work. A good chunk of my proposal is removing administrative overhead. Its overhead now because we have to manually assemble the email, do write out the content, checksome the packages, push them around etc.. Its VERY cumbersome, and requires a lot of permissions I'm not happy about giving folks. Moving it to Extras and tying into existing scripts or slightly new scripts to do most the work would lighten the load SIGNIFICANTLY. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) pgpLOdtRkh4xv.pgp Description: PGP signature -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Re: lwn article on the death of Fedora Legacy
On 10/19/06, Jesse Keating [EMAIL PROTECTED] wrote: On Thursday 19 October 2006 11:44, Matthew Miller wrote: When Jesse Keating worked at Pogo, that was largely true, but with his duties at RH and with his new kid, it doesn't seem to be the case anymore. I'm sure this is not Jesse's fault -- there needs to be commitment from above, and that's clearly not the case. I think this is really unfortunate, because it makes a big gap in the Fedora ecosystem. This will be largely filled by migration to RHEL-rebuild distros like CentOS, which is well and good (and particularly painless from the end-user point of few) but bad for Fedora. 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. Here is what I think can happen. A) Kill off RHL now. Stop trying to do stuff there when we just don't have the man power or the volunteers. B) Move to using Extras infrastructure for building packages. They're ready for us for FC3 and FC4. C) Move to Core style updates process. Spin a possible update, toss it in -testing. If nobody says boo after a period of time, release the darn thing. If somebody finds it to be broken, fix it and resubmit. D) Move to Core style plan. Figure out what core packages we are going to backport for, and what packages we are just going to push the latest stuff for. Mozilla - Seamonkey Gaim - Gaim latest etc. -- 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 -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Re: lwn article on the death of Fedora Legacy
On Thu, Oct 19, 2006 at 05:07:30PM -0600, Stephen John Smoogen wrote: D) Move to Core style plan. Figure out what core packages we are going to backport for, and what packages we are just going to push the latest stuff for. Mozilla - Seamonkey Gaim - Gaim latest Yeah. And also, if at all possible, E) See if any Fedora Core engineers are interested in, out of the goodness of their hearts, building updates for their packages in Legacy when it isn't much extra work -- and enabling them to easily do so. -- Matthew Miller [EMAIL PROTECTED] http://mattdm.org/ Boston University Linux -- http://linux.bu.edu/ -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Re: Fedora Core 4 Transferred to Fedora Legacy
On Fri, 2006-08-11 at 17:55 -0400, Jim Cornette wrote: Aaron Konstam wrote: On Mon, 2006-08-07 at 22:30 +0100, Chris Jones wrote: There is something I have forgotten or maybe I never really knew. How does the transfer of FC4 to the Legacy Project affect the ability to do a yum install or yum upgrade? I cannot confirm how it got there, but in my /etc/yum.repos.d directory I have a fedora-legacy.repo file which contains [legacy-updates] name=Fedora Legacy $releasever - $basearch - Updates mirrorlist=http://fedora.redhat.com/download/mirrors/legacy-updates-released-fc$releasever enabled=0 gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-legacy [legacy-testing] name=Fedora Legacy $releasever - $basearch - Updates Testing mirrorlist=http://fedora.redhat.com/download/mirrors/legacy-updates-testing-fc$releasever enabled=0 gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-legacy Is this what is needed to activate legacy support. I must say my box is FC5 so I haven't worried about it too much.. I have the normal repos online and these legacy repos disabled. cheers Chris Look, I can't get any any answer from the fedora-legacy-list on this so I guess I am invisible. The legacy-updates-testing-fc$releasever for FC4 does not exist and the one for FC5 exists bit is empty. So how does one get legacy updates? It looks like there are i386 updates at the below link. There is a mirror list for ftp and http methods. ftp://ftp.planetmirror.com/pub/fedoralegacy/fedora/4/updates/i386 Jim That is intersting except when you go to that site it wants you to logon. When I say I want togin anonomously I get back a message that content can not be displayed. Am I the only one that is driven to distraction by the fac that the fedora legacy repositories just don't exist or don't work. -- Aaron Konstam [EMAIL PROTECTED] -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Re: Fedora Core 4 Transferred to Fedora Legacy
On Tuesday 15 August 2006 09:50, Aaron Konstam wrote: That is intersting except when you go to that site it wants you to logon. When I say I want togin anonomously I get back a message that content can not be displayed. Am I the only one that is driven to distraction by the fac that the fedora legacy repositories just don't exist or don't work. I'm sorry Aaron, perhaps we haven't made it absolutely clear yet. The legacy-yumconf we provided a link to for you will install an extra repository into your yum setup. Currently the repository it points to is just as all of the released updates from Fedora thus far. Fedora Legacy has not ADDED any updates yet. You shouldn't have to touch anyother yum configs, leave them all enabled. You'll still be able to do yum installs and yum updates. When Legacy makes an update to Fedora Core 4, we will add it to the repository that our yumconf points to, and the next time you yum update you'll see that update. Is this clear yet? Can you please please please tell me if you're still unclear on something? I'm somewhat upset that you're telling people that we aren't responding to you, when in fact multiple people on this list are trying to help you. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) pgpIGOEQ0LonZ.pgp Description: PGP signature -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Re: Fedora Core 4 Transferred to Fedora Legacy
10:16am Jesse Keating said: legacy-yumconf we provided a link to for you will install an extra repository into your yum setup. Currently the repository it points to is just as all of the released updates from Fedora thus far. Fedora Legacy has not ADDED any updates yet. You shouldn't have to touch anyother yum configs, leave them all enabled. You'll still be able to do yum installs and yum updates. When Legacy makes an update to Fedora Core 4, we will add it to the repository that our yumconf points to, and the next time you yum update you'll see that update. This makes perfect sense. And I was thinking... Having just done: # rpm -ivh http://download.fedoralegacy.org/fedora/4/updates/$HOSTTYPE/legacy-yumconf-4-2.fc4.noarch.rpm Which involved a bit of copy/paste to ensure I got the URL correct. Would it be possible in fc6 or fc7 to add the legacy-yumconf as an optional package in either core or extras? Then, in 2008 or whenever those core releases go to pasture, the transition could be as smooth as: # yum -y install legacy-yumconf ../C -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Re: Fedora Core 4 Transferred to Fedora Legacy
Curtis Doty wrote: This makes perfect sense. And I was thinking... Having just done: # rpm -ivh http://download.fedoralegacy.org/fedora/4/updates/$HOSTTYPE/legacy-yumconf-4-2.fc4.noarch.rpm Which involved a bit of copy/paste to ensure I got the URL correct. Would it be possible in fc6 or fc7 to add the legacy-yumconf as an optional package in either core or extras? Then, in 2008 or whenever those core releases go to pasture, the transition could be as smooth as: # yum -y install legacy-yumconf Fedora Core 5 already includes the fedora-legacy repository file. You just have to enable it. Rahul -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
fedora legacy broken upgrade paths (was: Broken upgrade paths in FC+FE 2006-06-28)
Hi, I extracted the FL relevant parts of broken upgrade paths. This is part of an automated mail sent to the fedora-extras list: On Wed, Jun 28, 2006 at 09:10:24AM -0400, [EMAIL PROTECTED] wrote: mozilla: 3: 37:1.7.13-1.3.1.legacy (FL3-updates) 4: 37:1.7.13-1.1.fc4 (FC4-updates) 5: 37:1.7.13-1.1.fc5 (FC5-updates) 6: 37:1.7.13-1.1.fc5 (FC6) This happend because instead of fc3 the disttag was chosen to be simply 3 which is rpm-bigger than any fcX. The only way to fix FL broken paths is to bump the evr of the subsequent releases :/ FL or a spokesman of FL like Jesse need to lobby FC or FE for something like this to happen. Let's hope there will be some new security issue in mozilla 1.7.13 soon ;) -- Axel.Thimm at ATrpms.net pgpZ5ARWvVqcz.pgp Description: PGP signature -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Fedora Legacy Test Update Notification: mozilla
- Fedora Legacy Test Update Notification FEDORALEGACY-2006-189137-1 Bugzilla https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=189137 2006-05-15 - Name: mozilla Versions: rh7.3: mozilla-1.7.13-0.73.1.legacy Versions: rh9: mozilla-1.7.13-0.90.1.legacy Versions: fc1: mozilla-1.7.13-1.1.1.legacy Versions: fc2: mozilla-1.7.13-1.2.1.legacy Versions: fc3: mozilla-1.7.13-1.3.1.legacy Summary : A Web browser. Description : Mozilla is an open-source Web browser, designed for standards compliance, performance, and portability. - Update Information: Updated mozilla packages that fix several security bugs are now available. Mozilla is an open source Web browser, advanced email and newsgroup client, IRC chat client, and HTML editor. Several bugs were found in the way Mozilla processes malformed javascript. A malicious web page could modify the content of a different open web page, possibly stealing sensitive information or conducting a cross-site scripting attack. (CVE-2006-1731, CVE-2006-1732, CVE-2006-1741) Several bugs were found in the way Mozilla processes certain javascript actions. A malicious web page could execute arbitrary javascript instructions with the permissions of chrome, allowing the page to steal sensitive information or install browser malware. (CVE-2006-1727, CVE-2006-1728, CVE-2006-1733, CVE-2006-1734, CVE-2006-1735, CVE-2006-1742) Several bugs were found in the way Mozilla processes malformed web pages. A carefully crafted malicious web page could cause the execution of arbitrary code as the user running Mozilla. (CVE-2006-0748, CVE-2006-0749, CVE-2006-1730, CVE-2006-1737, CVE-2006-1738, CVE-2006-1739, CVE-2006-1790) A bug was found in the way Mozilla displays the secure site icon. If a browser is configured to display the non-default secure site modal warning dialog, it may be possible to trick a user into believing they are viewing a secure site. (CVE-2006-1740) A bug was found in the way Mozilla allows javascript mutation events on input form elements. A malicious web page could be created in such a way that when a user submits a form, an arbitrary file could be uploaded to the attacker. (CVE-2006-1729) A bug was found in the way Mozilla executes in-line mail forwarding. If a user can be tricked into forwarding a maliciously crafted mail message as in-line content, it is possible for the message to execute javascript with the permissions of chrome. (CVE-2006-0884) Users of Mozilla are advised to upgrade to these updated packages containing Mozilla version 1.7.13 which corrects these issues. - Changelogs rh7.3: * Sat Apr 22 2006 Marc Deslauriers [EMAIL PROTECTED] 37:1.7.13-0.73.1.legacy - Updated to 1.7.13 to fix security issues rh9: * Sat Apr 22 2006 Marc Deslauriers [EMAIL PROTECTED] 37:1.7.13-0.90.1.legacy - Updated to 1.7.13 to fix security issues fc1: * Fri Apr 21 2006 Marc Deslauriers [EMAIL PROTECTED] 37:1.7.13-1.1.1.legacy - Updated to 1.7.13 to fix security issues fc2: * Fri Apr 21 2006 Marc Deslauriers [EMAIL PROTECTED] 37:1.7.13-1.2.1.legacy - Updated to 1.7.13 to fix security issues fc3: * Fri Apr 21 2006 Marc Deslauriers [EMAIL PROTECTED] 37:1.7.13-1.3.1.legacy - Updated to 1.7.13 to fix security issues - This update can be downloaded from: http://download.fedoralegacy.org/ (sha1sums) rh7.3: b7616c52ee2776f3577fcda0a0628c5ec6cffae7 redhat/7.3/updates-testing/i386/mozilla-1.7.13-0.73.1.legacy.i386.rpm a6234bd3b89616ce5b924a36c95ba1421b6b8ecf redhat/7.3/updates-testing/i386/mozilla-chat-1.7.13-0.73.1.legacy.i386.rpm 3d7b92d47b825f5a936c54ca63679916f428917e redhat/7.3/updates-testing/i386/mozilla-devel-1.7.13-0.73.1.legacy.i386.rpm 2b4c765543b3f4fc5ac04127ca70c70a33fddaec redhat/7.3/updates-testing/i386/mozilla-dom-inspector-1.7.13-0.73.1.legacy.i386.rpm c15eceb55105a87f8d5dc0db24b9cf95e815a5a2 redhat/7.3/updates-testing/i386/mozilla-js-debugger-1.7.13-0.73.1.legacy.i386.rpm 09dcdb176779a013efc6b1819e5391854d94a751 redhat/7.3/updates-testing/i386/mozilla-mail-1.7.13-0.73.1.legacy.i386.rpm 5126d56d8ff98dfdcd69ed6864821120fc959c55 redhat/7.3/updates-testing/i386/mozilla-nspr-1.7.13-0.73.1.legacy.i386.rpm d2db357f5fe0d1ffce22db18f7d95c96dcfcffa3 redhat/7.3/updates-testing/i386/mozilla-nspr-devel-1.7.13-0.73.1.legacy.i386.rpm 7b3a403f4981d5ffa676aa38e5699fca9e7c2f18 redhat/7.3/updates-testing/i386/mozilla-nss-1.7.13-0.73.1.legacy.i386.rpm 3eea1812fa6a6ef13ed8826cd7734bd266c9b0fb redhat/7.3/updates-testing/i386/mozilla-nss-devel-1.7.13-0.73.1.legacy.i386.rpm 46393b4afb72fcd8100de2c61b6531d9ffe1dbf5 redhat/7.3/updates-testing/i386/galeon-1.2.14-0.73.6.legacy.i386.rpm
Fedora Legacy Test Update Notification: firefox
- Fedora Legacy Test Update Notification FEDORALEGACY-2006-189137-2 Bugzilla https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=189137 2006-05-15 - Name: firefox Versions: fc3: firefox-1.0.8-1.1.fc3.1.legacy Summary : Mozilla Firefox Web browser. Description : Mozilla Firefox is an open-source web browser, designed for standards compliance, performance and portability. - Update Information: An updated firefox package that fixes several security bugs is now available. Mozilla Firefox is an open-source web browser, designed for standards compliance, performance and portability. Several bugs were found in the way Firefox processes malformed javascript. A malicious web page could modify the content of a different open web page, possibly stealing sensitive information or conducting a cross-site scripting attack. (CVE-2006-1731, CVE-2006-1732, CVE-2006-1741) Several bugs were found in the way Firefox processes certain javascript actions. A malicious web page could execute arbitrary javascript instructions with the permissions of chrome, allowing the page to steal sensitive information or install browser malware. (CVE-2006-1727, CVE-2006-1728, CVE-2006-1733, CVE-2006-1734, CVE-2006-1735, CVE-2006-1742) Several bugs were found in the way Firefox processes malformed web pages. A carefully crafted malicious web page could cause the execution of arbitrary code as the user running Firefox. (CVE-2006-0748, CVE-2006-0749, CVE-2006-1724, CVE-2006-1730, CVE-2006-1737, CVE-2006-1738, CVE-2006-1739, CVE-2006-1790) A bug was found in the way Firefox displays the secure site icon. If a browser is configured to display the non-default secure site modal warning dialog, it may be possible to trick a user into believing they are viewing a secure site. (CVE-2006-1740) A bug was found in the way Firefox allows javascript mutation events on input form elements. A malicious web page could be created in such a way that when a user submits a form, an arbitrary file could be uploaded to the attacker. (CVE-2006-1729) Users of Firefox are advised to upgrade to these updated packages containing Firefox version 1.0.8 which corrects these issues. - Changelogs fc3: * Wed Apr 19 2006 Marc Deslauriers [EMAIL PROTECTED] 0:1.0.8-1.1.fc3.1.legacy - Update to firefox 1.0.8 - This update can be downloaded from: http://download.fedoralegacy.org/ (sha1sums) fc3: 8b719bb18c6dfe14b472c684ac5133d82d1b96d0 fedora/3/updates-testing/i386/firefox-1.0.8-1.1.fc3.1.legacy.i386.rpm 946f2ccbc412675ee6959a3dee50c2cb3ba90c3a fedora/3/updates-testing/x86_64/firefox-1.0.8-1.1.fc3.1.legacy.x86_64.rpm 0747aa65730e328a9274ec66c0de8dc30645dc1d fedora/3/updates-testing/SRPMS/firefox-1.0.8-1.1.fc3.1.legacy.src.rpm - Please test and comment in bugzilla. signature.asc Description: OpenPGP digital signature -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Fedora Legacy Test Update Notification: tetex
- Fedora Legacy Test Update Notification FEDORALEGACY-2006-152868 Bugzilla https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=152868 2006-04-26 - Name: tetex Versions: rh73: tetex-1.0.7-47.5.legacy Versions: rh9: tetex-1.0.7-66.3.legacy Versions: fc1: tetex-2.0.2-8.2.legacy Versions: fc2: tetex-2.0.2-14FC2.3.legacy Summary : The TeX text formatting system. Description : TeTeX is an implementation of TeX for Linux or UNIX systems. TeX takes a text file and a set of formatting commands as input and creates a typesetter-independent .dvi (DeVice Independent) file as output. Usually, TeX is used in conjunction with a higher level formatting package like LaTeX or PlainTeX, since TeX by itself is not very user-friendly. - Update Information: Updated tetex packages that fix several security issues are now available. TeTeX is an implementation of TeX. TeX takes a text file and a set of formatting commands as input and creates a typesetter-independent .dvi (DeVice Independent) file as output. A number of integer overflow bugs that affect Xpdf were discovered. The teTeX package contains a copy of the Xpdf code used for parsing PDF files and is therefore affected by these bugs. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the names CVE-2004-0888 and CVE-2004-1125 to these issues. Several flaws were discovered in the teTeX PDF parsing library. An attacker could construct a carefully crafted PDF file that could cause teTeX to crash or possibly execute arbitrary code when opened. The Common Vulnerabilities and Exposures project assigned the names CVE-2005-3191, CVE-2005-3192, CVE-2005-3193, CVE-2005-3624, CVE-2005-3625, CVE-2005-3626, CVE-2005-3627 and CVE-2005-3628 to these issues. Users of teTeX should upgrade to these updated packages, which contain backported patches and are not vulnerable to these issues. - Changelogs rh73: * Tue Apr 25 2006 Marc Deslauriers [EMAIL PROTECTED] 1.0.7-47.5.legacy - Added tetex tetex-latex and tetex-dvips to BuildPreReq! * Fri Apr 21 2006 Marc Deslauriers [EMAIL PROTECTED] 1.0.7-47.4.legacy - Added patch to remove expiration check * Wed Apr 19 2006 Marc Deslauriers [EMAIL PROTECTED] 1.0.7-47.3.legacy - Added missing netpbm-progs, ghostscript, ed and texinfo to BuildPrereq * Fri Mar 17 2006 Donald Maner [EMAIL PROTECTED] 1.0.7-47.2.legacy - Patches for CESA-2004-007, CAN-2004-1125, CAN-2004-0888, CVE-2005-3193 rh9: * Tue Apr 25 2006 Marc Deslauriers [EMAIL PROTECTED] 1.0.7-66.3.legacy - Added missing tetex, tetex-latex and tetex-dvips to BuildPreReq * Fri Apr 21 2006 Marc Deslauriers [EMAIL PROTECTED] 1.0.7-66.2.legacy - Added missing ed and texinfo to BuildPrereq * Thu Mar 16 2006 Donald Maner [EMAIL PROTECTED] 1.0.7-66.1.legacy - Patches for CESA-2004-007 CAN-2004-0888 CAN-2004-1125 CVE-2005-3193 (#152868) fc1: * Wed Apr 26 2006 Marc Deslauriers [EMAIL PROTECTED] 2.0.2-8.2.legacy - Added missing ed, texinfo, tetex, tetex-latex and tetex-dvips to BuildPreReq * Thu Mar 16 2006 Donald Maner [EMAIL PROTECTED] 2.0.2-8.1.legacy - Patches for CAN-2004-0888, CAN-2004-1125, CAN-2005-0064 and 2005-3193 fc2: * Tue Apr 25 2006 Marc Deslauriers [EMAIL PROTECTED] 2.0.2-14FC2.3.legacy - Fixed release tag - Added missing tetex, tetex-latex and tetex-dvips to BuildPreReq * Thu Mar 16 2006 Donald Maner [EMAIL PROTECTED] 2.0.2-14.3.legacy - Patch CVE-2005-3193 (#152868) - This update can be downloaded from: http://download.fedoralegacy.org/ (sha1sums) rh73: 80b05b7896c5db589e960da0d73b1cd4ae120cce redhat/7.3/updates-testing/i386/tetex-1.0.7-47.5.legacy.i386.rpm 28c6022b4f6a237d4695d1f268276ec6b18dcf4c redhat/7.3/updates-testing/i386/tetex-afm-1.0.7-47.5.legacy.i386.rpm 017fa321d9834685f04819070d4f5fb799e05d01 redhat/7.3/updates-testing/i386/tetex-doc-1.0.7-47.5.legacy.i386.rpm 3303175840f2fc37c5f3f77e672eeb3fafae718a redhat/7.3/updates-testing/i386/tetex-dvilj-1.0.7-47.5.legacy.i386.rpm fa43c7cbdf02cb7d439c9beeb0e358f8c69a5f22 redhat/7.3/updates-testing/i386/tetex-dvips-1.0.7-47.5.legacy.i386.rpm 1e69a574c3d47cec5b58963387956dfc8337d6ec redhat/7.3/updates-testing/i386/tetex-fonts-1.0.7-47.5.legacy.i386.rpm bb229acb3b38ae16025d56a77c41cab939a512ac redhat/7.3/updates-testing/i386/tetex-latex-1.0.7-47.5.legacy.i386.rpm d21419415faefcb90b688f8d8dc60a57a6374bad redhat/7.3/updates-testing/i386/tetex-xdvi-1.0.7-47.5.legacy.i386.rpm f646b3f3c2ebafa6ae264f20a3f056c778bd84db redhat/7.3/updates-testing/SRPMS/tetex-1.0.7-47.5.legacy.src.rpm rh9: 26f54ca0403372b21e6fd441d9bb64073f23e7de redhat/9/updates-testing/i386/tetex-1.0.7-66.3.legacy.i386.rpm e74de7855d1d07bcef6a713f4a8735e8008f5249 redhat
Fedora Legacy Test Update Notification: emacs
- Fedora Legacy Test Update Notification FEDORALEGACY-2006-152898 Bugzilla https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=152898 2006-04-26 - Name: emacs Versions: rh73: emacs-21.2-3.legacy Versions: rh9: emacs-21.2-34.legacy Versions: fc1: emacs-21.3-9.2.legacy Summary : The libraries needed to run the GNU Emacs text editor. Description : Emacs is a powerful, customizable, self-documenting, modeless text editor. Emacs contains special code editing features, a scripting language (elisp), and the capability to read mail, news, and more without leaving the editor. - Update Information: Updated Emacs packages that fix a string format issue are now available. Emacs is a powerful, customizable, self-documenting, modeless text editor. Max Vozeler discovered several format string vulnerabilities in the movemail utility of Emacs. If a user connects to a malicious POP server, an attacker can execute arbitrary code as the user running emacs. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CVE-2005-0100 to this issue. Users of Emacs are advised to upgrade to these updated packages, which contain backported patches to correct this issue. - Changelogs rh73: * Sun Mar 12 2006 Jesse Keating [EMAIL PROTECTED] 21.2-3.legacy - Patch for CAN-2005-0100 (#152898) rh9: * Sun Mar 12 2006 Jesse Keating [EMAIL PROTECTED] 21.2-34.legacy - Patch for CAN-2005-0100 (#152898) fc1: * Wed Mar 15 2006 David Eisenstein [EMAIL PROTECTED] 21.3-9.2.legacy - Clean up the #101818 (vm/break dumper problem) workaround * Wed Mar 15 2006 David Eisenstein [EMAIL PROTECTED] 21.3-9.1.legacy - Oops. Forgot to rework make install for the broken setarch. Now done. * Wed Mar 15 2006 David Eisenstein [EMAIL PROTECTED] 21.3-9.legacy - Re-instate setarch stuff; but make use of setarch dependent upon whether or not it is broken in this given invocation of rpmbuild. Why? If setarch doesn't break, it is probably needed and will be used for the bugzilla #101818 issue. If setarch *does* break, then it is likely breaking because it is operating within another setarch (FC1's setarch breaks under that circumstance), such as when being built by plague/mock. In that instance, it is not needed. * Sun Mar 12 2006 Jesse Keating [EMAIL PROTECTED] 21.3-8.legacy - Patch for CAN-2005-0100 (#152898) - Remove setarch stuff, not needed in new build system - Added builddep on autoconf213 - This update can be downloaded from: http://download.fedoralegacy.org/ (sha1sums) rh73: 4441c55cfe91aabf2203d68bcbc0cf2bbd5f8798 redhat/7.3/updates-testing/i386/emacs-21.2-3.legacy.i386.rpm 33e802e8f306f13519dd2c3f045eb9efe5e4680a redhat/7.3/updates-testing/i386/emacs-el-21.2-3.legacy.i386.rpm f6293ffe1c51c3bb31f1b3941da0938d8a98eff2 redhat/7.3/updates-testing/i386/emacs-leim-21.2-3.legacy.i386.rpm a5767f1100037b49602abb80831fa22da135c081 redhat/7.3/updates-testing/SRPMS/emacs-21.2-3.legacy.src.rpm rh9: ae56dba68d59f5d49105f7afb6918ac945ad8b01 redhat/9/updates-testing/i386/emacs-21.2-34.legacy.i386.rpm 84047366c8488fa3c95070466b1bd20ce5d8687a redhat/9/updates-testing/i386/emacs-el-21.2-34.legacy.i386.rpm 8eb8449c456e7d475157992c3e6f8bc4bdf64c7b redhat/9/updates-testing/i386/emacs-leim-21.2-34.legacy.i386.rpm 4cf0ba484c3ab93210d186beb3c79b68b4e56984 redhat/9/updates-testing/SRPMS/emacs-21.2-34.legacy.src.rpm fc1: d56260f010b4603c89516ccf2ddd09c33c8c53c4 fedora/1/updates-testing/i386/emacs-21.3-9.2.legacy.i386.rpm 6bf7cb9bacc6c0f9374849fa4507ededa13193cf fedora/1/updates-testing/i386/emacs-el-21.3-9.2.legacy.i386.rpm fb23df114772b6c758499401751dfc389e2e1d88 fedora/1/updates-testing/i386/emacs-leim-21.3-9.2.legacy.i386.rpm 1a1133d917d4993c92a03c30ba08e8916c6a7bfe fedora/1/updates-testing/SRPMS/emacs-21.3-9.2.legacy.src.rpm - Please test and comment in bugzilla. signature.asc Description: OpenPGP digital signature -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
[UPDATED] Fedora Legacy Test Update Notification: gnupg
The rh73 packages were updated to correct a broken info page. - Fedora Legacy Test Update Notification FEDORALEGACY-2006-185355 Bugzilla https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=185355 2006-04-01 - Name: gnupg Versions: rh73: gnupg-1.0.7-13.3.legacy Versions: rh9: gnupg-1.2.1-9.2.legacy Versions: fc1: gnupg-1.2.3-2.2.legacy Versions: fc2: gnupg-1.2.4-2.3.legacy Versions: fc3: gnupg-1.2.7-1.2.legacy Summary : A GNU utility for secure communication and data storage. Description : GnuPG (GNU Privacy Guard) is a GNU utility for encrypting data and creating digital signatures. GnuPG has advanced key management capabilities and is compliant with the proposed OpenPGP Internet standard described in RFC2440. Since GnuPG doesn't use any patented algorithm, it is not compatible with any version of PGP2 (PGP2.x uses only IDEA for symmetric-key encryption, which is patented worldwide). - Update Information: An updated GnuPG package that fixes signature verification flaws is now available. GnuPG is a utility for encrypting data and creating digital signatures. Tavis Ormandy discovered a bug in the way GnuPG verifies cryptographically signed data with detached signatures. It is possible for an attacker to construct a cryptographically signed message which could appear to come from a third party. When a victim processes a GnuPG message with a malformed detached signature, GnuPG ignores the malformed signature, processes and outputs the signed data, and exits with status 0, just as it would if the signature had been valid. In this case, GnuPG's exit status would not indicate that no signature verification had taken place. This issue would primarily be of concern when processing GnuPG results via an automated script. The Common Vulnerabilities and Exposures project assigned the name CVE-2006-0455 to this issue. Tavis Ormandy also discovered a bug in the way GnuPG verifies cryptographically signed data with inline signatures. It is possible for an attacker to inject unsigned data into a signed message in such a way that when a victim processes the message to recover the data, the unsigned data is output along with the signed data, gaining the appearance of having been signed. This issue is mitigated in the GnuPG shipped with Red Hat Enterprise Linux as the --ignore-crc-error option must be passed to the gpg executable for this attack to be successful. The Common Vulnerabilities and Exposures project assigned the name CVE-2006-0049 to this issue. Please note that neither of these issues affect the way RPM or up2date verify RPM package files, nor is RPM vulnerable to either of these issues. All users of GnuPG are advised to upgrade to this updated package, which contains backported patches to correct these issues. - Changelogs rh73: * Sat Apr 01 2006 Marc Deslauriers [EMAIL PROTECTED] 1.0.7-13.3.legacy - Added missing texinfo to BuildPrereq * Thu Mar 23 2006 Marc Deslauriers [EMAIL PROTECTED] 1.0.7-13.2.legacy - Added missing openldap-devel and zlib-devel to BuildPrereq * Wed Mar 15 2006 Donald Maner [EMAIL PROTECTED] 1.0.7-13.1.legacy - add patch from Werner Koch to error out on ambiguous armored signatures in message, with some more bits from Klaus Singvogel to handle argument parsing, backported (CVE-2006-0049, #185355) - add backport of patch from Werner Koch to fix the exit status when verifying signatures when no signature is provided (CVE-2006-0455, #185355) rh9: * Thu Mar 23 2006 Marc Deslauriers [EMAIL PROTECTED] 1.2.1-9.2.legacy - Added missing openldap to BuildPrereq * Wed Mar 15 2006 Donald Maner [EMAIL PROTECTED] 1.2.1-9.1.legacy - add patch from Werner Koch to error out on ambiguous armored signatures in message, with some more bits from Klaus Singvogel to handle argument parsing, backported (CVE-2006-0049, #185355) - add backport of patch from Werner Koch to fix the exit status when verifying signatures when no signature is provided (CVE-2006-0455, #185355) fc1: * Thu Mar 23 2006 Marc Deslauriers [EMAIL PROTECTED] 1.2.3-2.2.legacy - Added missing openldap-devel and zlib-devel to BuildPrereq * Wed Mar 15 2006 Donald Maner [EMAIL PROTECTED] 1.2.3-2.1.legacy - add patch from Werner Koch to error out on ambiguous armored signatures in message, with some more bits from Klaus Singvogel to handle argument parsing, backported (CVE-2006-0049, #185355) - add backport of patch from Werner Koch to fix the exit status when verifying signatures when no signature is provided (CVE-2006-0455, #185355) fc2: * Thu Mar 23 2006 Marc Deslauriers [EMAIL PROTECTED] 1.2.3-2.3.legacy - Added missing openldap-devel, bzip2-devel and zlib-devel to BuildPrereq * Wed Mar 15 2006 Donald Maner
Fedora Legacy Test Update Notification: ncpfs
- Fedora Legacy Test Update Notification FEDORALEGACY-2006-152904 Bugzilla https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=152904 2006-03-28 - Name: ncpfs Versions: rh73: ncpfs-2.2.0.18-6.1.legacy Versions: rh9: ncpfs-2.2.1-1.1.legacy Versions: fc1: ncpfs-2.2.3-1.1.legacy Versions: fc2: ncpfs-2.2.4-1.1.legacy Versions: fc3: ncpfs-2.2.4-5.FC3.1.legacy Summary : Utilities for the ncpfs filesystem, a NetWare client. Description : Ncpfs is a filesystem which understands the Novell NetWare(TM) NCP protocol. Functionally, NCP is used for NetWare the way NFS is used in the TCP/IP world. For a Linux system to mount a NetWare filesystem, it needs a special mount program. The ncpfs package contains such a mount program plus other tools for configuring and using the ncpfs filesystem. - Update Information: An updated ncpfs package is now available. Ncpfs is a file system that understands the Novell NetWare(TM) NCP protocol. Buffer overflows were found in the nwclient program. An attacker, using a long -T option, could possibly execute arbitrary code and gain privileges. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CVE-2004-1079 to this issue. A bug was found in the way ncpfs handled file permissions. ncpfs did not sufficiently check if the file owner matched the user attempting to access the file, potentially violating the file permissions. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CVE-2005-0013 to this issue. A buffer overflow was found in the ncplogin program. A remote malicious NetWare server could execute arbitrary code on a victim's machine. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CVE-2005-0014 to this issue. All users of ncpfs are advised to upgrade to this updated package, which contains backported fixes for these issues. - Changelogs rh73: * Fri Mar 10 2006 Marc Deslauriers [EMAIL PROTECTED] 2.2.0.18-6.1.legacy - fixed getuid security bug CVE-2005-0013 rh9: * Fri Mar 10 2006 Marc Deslauriers [EMAIL PROTECTED] 2.2.1-1.1.legacy - Added patches for CVE-2004-1079, CVE-2005-0013 and CVE-2005-0014 fc1: * Sat Mar 11 2006 Marc Deslauriers [EMAIL PROTECTED] 2.2.3-1.1.legacy - Added patches for CVE-2004-1079, CVE-2005-0013 and CVE-2005-0014 fc2: * Sat Mar 11 2006 Marc Deslauriers [EMAIL PROTECTED] 2.2.4-1.1.legacy - Added patches for CVE-2004-1079, CVE-2005-0013 and CVE-2005-0014 fc3: * Sat Mar 11 2006 Marc Deslauriers [EMAIL PROTECTED] 2.2.4-5.FC3.1.legacy - Added missing part of CVE-2005-0013 fix - This update can be downloaded from: http://download.fedoralegacy.org/ (sha1sums) rh73: 16740d3fa5e17a46429ad3586e4adf9a14a64f8d redhat/7.3/updates-testing/i386/ncpfs-2.2.0.18-6.1.legacy.i386.rpm 21f8520c8a2a3d60e55041c0db028e03549f8544 redhat/7.3/updates-testing/i386/ipxutils-2.2.0.18-6.1.legacy.i386.rpm 6704d55f1f43360b6ad4211e2ca0f92e9f2174c8 redhat/7.3/updates-testing/SRPMS/ncpfs-2.2.0.18-6.1.legacy.src.rpm rh9: 6acd3b7b7d09cb0e47769b43a888adf72a6278ac redhat/9/updates-testing/i386/ncpfs-2.2.1-1.1.legacy.i386.rpm c49d83f88b229ce57c689d313eccb4df7b89f36b redhat/9/updates-testing/i386/ipxutils-2.2.1-1.1.legacy.i386.rpm ac833c51fcf831bca3edef5d0275ccd1ae0a530f redhat/9/updates-testing/SRPMS/ncpfs-2.2.1-1.1.legacy.src.rpm fc1: 8379face8f68fe556d40bf32f72a5ab368e8eb6d fedora/1/updates-testing/i386/ncpfs-2.2.3-1.1.legacy.i386.rpm eefaa839a26179ca5d41897eacf7bbf3c49661e1 fedora/1/updates-testing/i386/ipxutils-2.2.3-1.1.legacy.i386.rpm ede00a8544200515b5e09a7a40836d8f558cac9d fedora/1/updates-testing/SRPMS/ncpfs-2.2.3-1.1.legacy.src.rpm fc2: 1d32d2f0c39475f98206d78f87c587d4f96ddb70 fedora/2/updates-testing/i386/ncpfs-2.2.4-1.1.legacy.i386.rpm c095ce2d66184b605516231609cddc30520c3eb5 fedora/2/updates-testing/i386/ipxutils-2.2.4-1.1.legacy.i386.rpm 874f8a48f85fef80615b5892a70d214f0935ed7a fedora/2/updates-testing/SRPMS/ncpfs-2.2.4-1.1.legacy.src.rpm fc3: dc329c8b3558f67350486358b01b6a62f6f467af fedora/3/updates-testing/i386/ncpfs-2.2.4-5.FC3.1.legacy.i386.rpm 1ddd6caafe4a693d4a69d341be69600df446de3b fedora/3/updates-testing/i386/ipxutils-2.2.4-5.FC3.1.legacy.i386.rpm db8660759a23570a6d06bda37c619e0931425ef8 fedora/3/updates-testing/x86_64/ncpfs-2.2.4-5.FC3.1.legacy.x86_64.rpm 1e8bc7d10995fde90688b424f5001c14f7d3e3bc fedora/3/updates-testing/x86_64/ipxutils-2.2.4-5.FC3.1.legacy.x86_64.rpm 7f29dd88dcf31f19970e22c8c3af7267c62a5508 fedora/3/updates-testing/SRPMS/ncpfs-2.2.4-5.FC3.1.legacy.src.rpm - Please test and comment in bugzilla
Fedora Legacy Test Update Notification: fetchmail
- Fedora Legacy Test Update Notification FEDORALEGACY-2006-164512 Bugzilla https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=164512 2006-03-28 - Name: fetchmail Versions: rh73: fetchmail-5.9.0-21.7.3.2.legacy Versions: rh9: fetchmail-6.2.0-3.4.legacy Versions: fc1: fetchmail-6.2.0-8.2.legacy Versions: fc2: fetchmail-6.2.5-2.2.legacy Summary : A remote mail retrieval and forwarding utility. Description : Fetchmail is a remote mail retrieval and forwarding utility intended for use over on-demand TCP/IP links, like SLIP or PPP connections. Fetchmail supports every remote-mail protocol currently in use on the Internet (POP2, POP3, RPOP, APOP, KPOP, all IMAPs, ESMTP ETRN, IPv6, and IPSEC) for retrieval. Then Fetchmail forwards the mail through SMTP so you can read it through your favorite mail client. - Update Information: Updated fetchmail packages that fix security flaws are now available. Fetchmail is a remote mail retrieval and forwarding utility. A bug was found in the way fetchmail allocates memory for long lines. A remote attacker could cause a denial of service by sending a specially- crafted email. The Common Vulnerabilities and Exposures project has assigned the name CVE-2003-0792 to this issue. A buffer overflow was discovered in fetchmail's POP3 client. A malicious server could cause send a carefully crafted message UID and cause fetchmail to crash or potentially execute arbitrary code as the user running fetchmail. The Common Vulnerabilities and Exposures project assigned the name CAN-2005-2335 to this issue. A bug was found in the way the fetchmailconf utility program writes configuration files. The default behavior of fetchmailconf is to write a configuration file which may be world readable for a short period of time. This configuration file could provide passwords to a local malicious attacker within the short window before fetchmailconf sets secure permissions. The Common Vulnerabilities and Exposures project has assigned the name CVE-2005-3088 to this issue. A bug was found when fetchmail is running in multidrop mode. A malicious mail server can cause a denial of service by sending a message without headers. The Common Vulnerabilities and Exposures project has assigned the name CVE-2005-4348 to this issue. Users of fetchmail should update to this erratum package which contains backported patches to correct these issues. - Changelogs rh73: * Sat Mar 11 2006 Donald Maner [EMAIL PROTECTED] 6.2.0-3.2.legacy - add patch for CAN-2003-0792 (#164512) - add patch for CAN-2005-4348 (#164512) - add patch for CAN-2005-3088 from RHEL 2.1 (#164512) * Thu Jul 28 2005 Jeff Sheltren [EMAIL PROTECTED] 5.9.0-21.7.3.1.legacy - add patch for POP3 buffer overflow - CAN-2005-2355 (#164512) rh9: * Thu Mar 23 2006 Marc Deslauriers [EMAIL PROTECTED] 6.2.0-3.4.legacy - Added missing e2fsprogs-devel to BuildPrereq * Sat Mar 11 2006 Donald Maner [EMAIL PROTECTED] 6.2.0-3.2.legacy - add patch for CAN-2003-0792 (#164512) - add patch for CAN-2005-3088 (#164512) * Thu Jul 28 2005 Jeff Sheltren [EMAIL PROTECTED] 6.2.0-3.1.legacy - add patch for POP3 buffer overflow - CAN-2005-2355 (#164512) fc1: * Sun Mar 12 2006 Donald Maner [EMAIL PROTECTED] 6.2.0-8.2.legacy - add patch for CAN-2005-3088 (#164512) - add patch for CAN-2005-2355 (#164512) * Thu Jul 28 2005 Jeff Sheltren [EMAIL PROTECTED] 6.2.0-8.1.legacy - add patch for POP3 buffer overflow - CAN-2005-2355 (#164512) fc2: * Sun Mar 12 2006 Donald Maner [EMAIL PROTECTED] 6.2.5-2.2.legacy - add patch for crash on empty message - CVE-2005-4348 (#164512) - add patch for CAN-2005-3088 (#164512) * Thu Jul 28 2005 Jeff Sheltren [EMAIL PROTECTED] 6.2.5-2.1.legacy - add patch for POP3 buffer overflow - CAN-2005-2355 (#164512) - This update can be downloaded from: http://download.fedoralegacy.org/ (sha1sums) rh73: 8b49bca60dc8bcbba7634b8e0559c82fbeef3db5 redhat/7.3/updates-testing/i386/fetchmail-5.9.0-21.7.3.2.legacy.i386.rpm 9c9c861757b4b8b2866f1d0e91dbc16d5037d956 redhat/7.3/updates-testing/i386/fetchmailconf-5.9.0-21.7.3.2.legacy.i386.rpm 9cca4f274cb21928d459ed25883e5d3c1f758f10 redhat/7.3/updates-testing/SRPMS/fetchmail-5.9.0-21.7.3.2.legacy.src.rpm rh9: 0fd22e51f83aab97d8c1790ed95423882f01aa9b redhat/9/updates-testing/i386/fetchmail-6.2.0-3.4.legacy.i386.rpm 7d2eb582d0aba96e07710eb89cd8c4c41c4530d3 redhat/9/updates-testing/SRPMS/fetchmail-6.2.0-3.4.legacy.src.rpm fc1: 5df158a0ba6bb0c323a75464e04b11e246dd8f98 fedora/1/updates-testing/i386/fetchmail-6.2.0-8.2.legacy.i386.rpm 927ed2783b8b4a29d0669e7936c1d27fd05564eb fedora/1/updates-testing/SRPMS/fetchmail-6.2.0-8.2.legacy.src.rpm fc2
Fedora Legacy Test Update Notification: gnupg
- Fedora Legacy Test Update Notification FEDORALEGACY-2006-185355 Bugzilla https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=185355 2006-03-28 - Name: gnupg Versions: rh73: gnupg-1.0.7-13.2.legacy Versions: rh9: gnupg-1.2.1-9.2.legacy Versions: fc1: gnupg-1.2.3-2.2.legacy Versions: fc2: gnupg-1.2.4-2.3.legacy Versions: fc3: gnupg-1.2.7-1.2.legacy Summary : A GNU utility for secure communication and data storage. Description : GnuPG (GNU Privacy Guard) is a GNU utility for encrypting data and creating digital signatures. GnuPG has advanced key management capabilities and is compliant with the proposed OpenPGP Internet standard described in RFC2440. Since GnuPG doesn't use any patented algorithm, it is not compatible with any version of PGP2 (PGP2.x uses only IDEA for symmetric-key encryption, which is patented worldwide). - Update Information: An updated GnuPG package that fixes signature verification flaws is now available. GnuPG is a utility for encrypting data and creating digital signatures. Tavis Ormandy discovered a bug in the way GnuPG verifies cryptographically signed data with detached signatures. It is possible for an attacker to construct a cryptographically signed message which could appear to come from a third party. When a victim processes a GnuPG message with a malformed detached signature, GnuPG ignores the malformed signature, processes and outputs the signed data, and exits with status 0, just as it would if the signature had been valid. In this case, GnuPG's exit status would not indicate that no signature verification had taken place. This issue would primarily be of concern when processing GnuPG results via an automated script. The Common Vulnerabilities and Exposures project assigned the name CVE-2006-0455 to this issue. Tavis Ormandy also discovered a bug in the way GnuPG verifies cryptographically signed data with inline signatures. It is possible for an attacker to inject unsigned data into a signed message in such a way that when a victim processes the message to recover the data, the unsigned data is output along with the signed data, gaining the appearance of having been signed. This issue is mitigated in the GnuPG shipped with Red Hat Enterprise Linux as the --ignore-crc-error option must be passed to the gpg executable for this attack to be successful. The Common Vulnerabilities and Exposures project assigned the name CVE-2006-0049 to this issue. Please note that neither of these issues affect the way RPM or up2date verify RPM package files, nor is RPM vulnerable to either of these issues. All users of GnuPG are advised to upgrade to this updated package, which contains backported patches to correct these issues. - Changelogs rh73: * Thu Mar 23 2006 Marc Deslauriers [EMAIL PROTECTED] 1.0.7-13.2.legacy - Added missing openldap-devel and zlib-devel to BuildPrereq * Wed Mar 15 2006 Donald Maner [EMAIL PROTECTED] 1.0.7-13.1.legacy - add patch from Werner Koch to error out on ambiguous armored signatures in message, with some more bits from Klaus Singvogel to handle argument parsing, backported (CVE-2006-0049, #185355) - add backport of patch from Werner Koch to fix the exit status when verifying signatures when no signature is provided (CVE-2006-0455, #185355) rh9: * Thu Mar 23 2006 Marc Deslauriers [EMAIL PROTECTED] 1.2.1-9.2.legacy - Added missing openldap to BuildPrereq * Wed Mar 15 2006 Donald Maner [EMAIL PROTECTED] 1.2.1-9.1.legacy - add patch from Werner Koch to error out on ambiguous armored signatures in message, with some more bits from Klaus Singvogel to handle argument parsing, backported (CVE-2006-0049, #185355) - add backport of patch from Werner Koch to fix the exit status when verifying signatures when no signature is provided (CVE-2006-0455, #185355) fc1: * Thu Mar 23 2006 Marc Deslauriers [EMAIL PROTECTED] 1.2.3-2.2.legacy - Added missing openldap-devel and zlib-devel to BuildPrereq * Wed Mar 15 2006 Donald Maner [EMAIL PROTECTED] 1.2.3-2.1.legacy - add patch from Werner Koch to error out on ambiguous armored signatures in message, with some more bits from Klaus Singvogel to handle argument parsing, backported (CVE-2006-0049, #185355) - add backport of patch from Werner Koch to fix the exit status when verifying signatures when no signature is provided (CVE-2006-0455, #185355) fc2: * Thu Mar 23 2006 Marc Deslauriers [EMAIL PROTECTED] 1.2.3-2.3.legacy - Added missing openldap-devel, bzip2-devel and zlib-devel to BuildPrereq * Wed Mar 15 2006 Donald Maner [EMAIL PROTECTED] 1.2.3-2.1.legacy - add patch from Werner Koch to error out on ambiguous armored signatures in message, with some more bits from Klaus Singvogel to handle
[UPDATED] Fedora Legacy Test Update Notification: sendmail
These updated test packages for rh73, rh9 and fc1 fix problems with the previous sendmail update. - Fedora Legacy Test Update Notification FEDORALEGACY-2006-186277 Bugzilla https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=186277 2006-03-28 - Name: sendmail Versions: rh73: sendmail-8.12.11-4.22.10.legacy Versions: rh9: sendmail-8.12.11-4.24.3.legacy Versions: fc1: sendmail-8.12.11-4.25.3.legacy Summary : A widely used Mail Transport Agent (MTA). Description : The Sendmail program is a very widely used Mail Transport Agent (MTA). MTAs send mail from one machine to another. Sendmail is not a client program, which you use to read your email. Sendmail is a behind-the-scenes program which actually moves your email over networks or the Internet to where you want it to go. - Update Information: Updated sendmail packages that fix a flaw in the handling of asynchronous signals are now available. A flaw in the handling of asynchronous signals was discovered in Sendmail. A remote attacker may be able to exploit a race condition to execute arbitrary code as root. The Common Vulnerabilities and Exposures project assigned the name CVE-2006-0058 to this issue. In order to correct this issue for RHL 7.3 users, it was necessary to upgrade the version of Sendmail from 8.11 as originally shipped to Sendmail 8.12.11 with the addition of the security patch supplied by Sendmail Inc. This erratum provides updated packages based on Sendmail 8.12 with a compatibility mode enabled as provided by Red Hat for RHEL 2.1. After updating to these packages, users should pay close attention to their sendmail logs to ensure that the upgrade completed sucessfully. In order to correct this issue for RHL 9 and FC1 users, it was necessary to upgrade the version of Sendmail from 8.12.8 and 8.12.10 respectively to 8.12.11 with the addition of the security patch supplied by Sendmail Inc. After updating to these packages, users should pay close attention to their sendmail logs to ensure that the upgrade completed sucessfully. Users of Sendmail should upgrade to this updated package, which contains a backported patch to correct this issue. - Changelogs rh73: * Sat Mar 25 2006 Marc Deslauriers [EMAIL PROTECTED] 8.12.11-4.22.10.legacy - Added hesiod-devel to BuildRequires - Reverted to previous alternatives files - Removed new triggers - Modified instructions in sendmail.mc * Wed Mar 22 2006 Jesse Keating [EMAIL PROTECTED] 8.12.11-4.22.9.legacy - Sourced in for RHL7.3 - Added groff buildreq - Enable alternatives rh9: * Sun Mar 26 2006 Marc Deslauriers [EMAIL PROTECTED] - 8.12.11-4.24.3.legacy - Reverted statistics file path in mc file - Reverted CERT paths in mc file - Don't enable statistics by default * Sat Mar 25 2006 Marc Deslauriers [EMAIL PROTECTED] - 8.12.11-4.24.2.legacy - Reverted statistics file to /etc/mail - Reverted to previous alternatives files * Wed Mar 22 2006 Jesse Keating [EMAIL PROTECTED] - 8.12.11-4.24.1.legacy - fixed VU#834865 (#186277) - disable -fpie - enable old_setup - Add BuildReq gdbm-devel - Use sasl1 fc1: * Sun Mar 26 2006 Marc Deslauriers [EMAIL PROTECTED] - 8.12.11-4.25.3.legacy - Reverted statistics file path in mc file - Reverted CERT paths in mc file - Don't enable statistics by default * Sat Mar 25 2006 Marc Deslauriers [EMAIL PROTECTED] - 8.12.11-4.25.2.legacy - Reverted statistics file to /etc/mail - Reverted to previous alternatives files - Added gdbm-devel to BuildRequires * Wed Mar 22 2006 Jesse Keating [EMAIL PROTECTED] - 8.12.11-4.25.1.legacy - fixed VU#834865 (#186277) - enable old_setup - This update can be downloaded from: http://download.fedoralegacy.org/ (sha1sums) rh73: 950fc853550d93f521d4203b9f78023721fbdecd redhat/7.3/updates-testing/i386/sendmail-8.12.11-4.22.10.legacy.i386.rpm d8c06f3f92d7dd526426b86e52bdd244e75c061a redhat/7.3/updates-testing/i386/sendmail-cf-8.12.11-4.22.10.legacy.i386.rpm dde44f59a60481edae75ddf6d854341308e4ce62 redhat/7.3/updates-testing/i386/sendmail-devel-8.12.11-4.22.10.legacy.i386.rpm faf27d20eb151227225cc4e2ac5014bb205aa350 redhat/7.3/updates-testing/i386/sendmail-doc-8.12.11-4.22.10.legacy.i386.rpm e0b9ece564e8103a254311da19c6bc41a21c8ffc redhat/7.3/updates-testing/SRPMS/sendmail-8.12.11-4.22.10.legacy.src.rpm rh9: 9f1caeadce45e2922f6bc29ea0f4e7bce4e26d02 redhat/9/updates-testing/i386/sendmail-8.12.11-4.24.3.legacy.i386.rpm 6b7b437bb58ac9f805185ae992da9a157a0d755d redhat/9/updates-testing/i386/sendmail-cf-8.12.11-4.24.3.legacy.i386.rpm ae48cf1d3a5d8f5bfc789a408de392fe27e84b73 redhat/9/updates-testing/i386/sendmail-devel-8.12.11-4.24.3.legacy.i386.rpm
Long RTT on fedora-legacy-list (was: Question about yum.conf for fc2)
On 2006-03-23 23:49:53 -0500, Gene Heskett wrote: Received: from listman.util.phx.redhat.com (localhost.localdomain [127.0.0.1]) by listman.util.phx.redhat.com (8.13.1/8.13.1) with ESMTP id k2OH5hkP031529; Fri, 24 Mar 2006 12:06:05 -0500 ^ Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by listman.util.phx.redhat.com (8.13.1/8.13.1) with ESMTP id k2O4o2sH012586 for [EMAIL PROTECTED]; Thu, 23 Mar 2006 23:50:02 -0500 ^ [...] Humm, this is the second copy, to the list, posted at 14:00 your time, just now walked in the door Seth, its 23:48 here now. As somebody else already noted, the fedora-legacy-list sometimes has extremely long round-trip times. This mail seems to have been more than 12 hours on listman.util.phx.redhat.com, before it was sent on. hp -- _ | Peter J. Holzer| If I wanted to be academically correct, |_|_) | Sysadmin WSR | I'd be programming in Java. | | | [EMAIL PROTECTED] | I don't, and I'm not. __/ | http://www.hjp.at/ | -- Jesse Erlbaum on dbi-users pgpmzI8uFKKj7.pgp Description: PGP signature -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Re: Fedora Legacy Update : kdelibs dependency problems
On Wed, Mar 22, 2006 at 06:54:03PM +, A E Lawrence wrote: Synopsis: Updated kdelibs packages fix security issues Advisory ID: FLSA:178606 download.fedoralegacy.org/fedora/3/updates/x86_64/kdelibs-3.4.2-1.fc3.1.legacy.x86_64.rpm Trying to update (yum) the kdelibs and kdelibs-devel rpms fails on a AMD64 FC3 legacy system because all the other kde packages appear to require kdebase-3.3.1-4.3.FC3. There is something not kosher with your system as in August 2005 there was an FC3 update of various things KDE and this included kdelibs-3.4.2-0.fc3.2; on x86_64 too. I suspect that I can force the upgrade without breaking anything by a manual rpm -Fhv --nodeps ..., Don't do that. Quite likely something will break. I guess that you should first run all available updates from pre-legacy servers and only after that apply what was provided later. There is an assumption here that all earlier updates were already applied. Michal -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Re: Fedora Legacy Update : kdelibs dependency problems
A E Lawrence wrote: Synopsis: Updated kdelibs packages fix security issues Advisory ID: FLSA:178606 download.fedoralegacy.org/fedora/3/updates/x86_64/kdelibs-3.4.2-1.fc3.1.legacy.x86_64.rpm Trying to update (yum) the kdelibs and kdelibs-devel rpms fails on a AMD64 FC3 legacy system because all the other kde packages appear to require kdebase-3.3.1-4.3.FC3. I can't see anyone else reporting this problem in the archives of this list, so I am mystified. I suspect that I can force the upgrade without breaking anything by a manual rpm -Fhv --nodeps ..., but I shouldn't need to do this, should I? ael - Snippets from failed yum update:- Dependencies Resolved Transaction Listing: Update: kdelibs.i386 6:3.4.2-1.fc3.1.legacy - updates Update: kdelibs.x86_64 6:3.4.2-1.fc3.1.legacy - updates Update: kdelibs-devel.x86_64 6:3.4.2-1.fc3.1.legacy - updates Total download size: 54 M Is this ok [y/N]: y Downloading Packages: Running Transaction Test Finished Transaction Test Transaction Check Error: file /usr/bin/kcmshell from install of kdelibs-3.4.2-1.fc3.1.legacy conflicts with file from package kdebase-3.3.1-4.3.FC3 file /usr/lib/kde3/kcmshell.la from install of kdelibs-3.4.2-1.fc3.1.legacy conflicts with file from package kdebase-3.3.1-4.3.FC3 ... file /usr/share/apps/kstyle/themes/plastik.themerc from install of kdelibs-3.4.2-1.fc3.1.legacy conflicts with file from package kdeartwork-3.3.1-1 - This is strange. The latest version of KDE for FC3 in updates is 3.4.2. Yum is supposed to take care of figuring out all of the dependencies, so I would have thought that it would also have downloaded the other kde___-3.4.2 packages as well, instead of giving you this error. What version of yum do you have installed? What does your yum.conf look like? What was the command you gave on the command line to update kdelibs? What happens when you do '# yum check-update'? As a workaround, you might try this: # yum update `rpm -qa kde* --qf '%{name} '` and see if that works for you. -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Fedora Legacy Test Update Notification: sendmail
- Fedora Legacy Test Update Notification FEDORALEGACY-2006-186277 Bugzilla https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=186277 2006-03-22 - Name: sendmail Versions: rh73: sendmail-8.12.11-4.22.9.legacy Versions: rh9: sendmail-8.12.11-4.24.1.legacy Versions: fc1: sendmail-8.12.11-4.25.1.legacy Versions: fc2: sendmail-8.12.11-4.26.legacy Versions: fc3: sendmail-8.13.1-3.legacy Summary : A widely used Mail Transport Agent (MTA). Description : The Sendmail program is a very widely used Mail Transport Agent (MTA). MTAs send mail from one machine to another. Sendmail is not a client program, which you use to read your email. Sendmail is a behind-the-scenes program which actually moves your email over networks or the Internet to where you want it to go. If you ever need to reconfigure Sendmail, you will also need to have the sendmail.cf package installed. If you need documentation on Sendmail, you can install the sendmail-doc package. - Update Information: An updated tar package that fixes a flaw in the handling of asynchronous signals. A flaw in the handling of asynchronous signals was discovered in Sendmail. A remote attacker may be able to exploit a race condition to execute arbitrary code as root. The Common Vulnerabilities and Exposures project assigned the name CVE-2006-0058 to this issue. By default on Red Hat Enterprise Linux 2.1 and later, Sendmail is configured to only accept connections from the local host. Therefore only users who have configured Sendmail to listen to remote hosts would be able to be remotely exploited by this vulnerability. In order to correct this issue for RHL 7.3 users, it was necessary to upgrade the version of Sendmail from 8.11 as originally shipped to Sendmail 8.12.11 with the addition of the security patch supplied by Sendmail Inc. This erratum provides updated packages based on Sendmail 8.12 with a compatibility mode enabled as provided by Red Hat for RHEL 2.1. After updating to these packages, users should pay close attention to their sendmail logs to ensure that the upgrade completed sucessfully. In order to correct this issue for RHL 9 and FC1 users, it was necessary to upgrade the version of Sendmail from 8.12.8 and 8.12.10 respectively to 8.12.11 with the addition of the security patch supplied by Sendmail Inc. After updating to these packages, users should pay close attention to their sendmail logs to ensure that the upgrade completed sucessfully. For Fedora Core 3 users, the patch supplied by Sendmail Inc. applies cleanly to the latest sendmail package previously released for Fedora Core 3. Users of Sendmail should upgrade to this updated package, which contains a replacement backported patch to correct this issue. - Changelogs rh73: * Wed Mar 22 2006 Jesse Keating [EMAIL PROTECTED] 8.12.11-4.22.9.legacy - Sourced in for RHL7.3 - Added groff buildreq rh9: * Wed Mar 22 2006 Jesse Keating [EMAIL PROTECTED] - 8.12.11-4.24.1.legacy - fixed VU#834865 (#186277) - disable -fpie - enable old_setup - Add BuildReq gdbm-devel - Use sasl1 fc1: * Wed Mar 22 2006 Jesse Keating [EMAIL PROTECTED] - 8.12.11-4.25.1.legacy - fixed VU#834865 (#186277) - enable old_setup fc2: * Wed Mar 22 2006 Jesse Keating [EMAIL PROTECTED] - 8.12.11-4.26.legacy - fixed VU#834865 (#186277) fc3: * Wed Mar 22 2006 Jesse Keating [EMAIL PROTECTED] 8.13.1-3.legacy - fixed VU#834865 (#186277) - This update can be downloaded from: http://download.fedoralegacy.org/ (sha1sums) rh73: d9c001d8a34f11f528ff6be2a9f8dd15818caf40 redhat/7.3/updates-testing/SRPMS/sendmail-8.12.11-4.22.9.legacy.src.rpm 80f02c886b020e6d6ef17389c22c8b530fb05a48 redhat/7.3/updates-testing/i386/sendmail-8.12.11-4.22.9.legacy.i386.rpm 285816881a55fe4b8a74fee48205c8ceedaee5e5 redhat/7.3/updates-testing/i386/sendmail-cf-8.12.11-4.22.9.legacy.i386.rpm b4154a342e7747d980b7acaf352649ddc1dcc40d redhat/7.3/updates-testing/i386/sendmail-devel-8.12.11-4.22.9.legacy.i386.rpm 81a36048a12cc5c08a8e93490dde6817c402ae54 redhat/7.3/updates-testing/i386/sendmail-doc-8.12.11-4.22.9.legacy.i386.rpm rh9: 272bbff91a52692991f6f0fd434a27fda1c92057 redhat/9/updates-testing/SRPMS/sendmail-8.12.11-4.24.1.legacy.src.rpm 683d48df1c5aabb1e9768d4bfb37036d0d7ff7c6 redhat/9/updates-testing/i386/sendmail-8.12.11-4.24.1.legacy.i386.rpm a6e967294f6cbe9f623e5626e20e33fbbc410f68 redhat/9/updates-testing/i386/sendmail-cf-8.12.11-4.24.1.legacy.i386.rpm da996e582bb27144c7c26050e0ba51ce7cb727d7 redhat/9/updates-testing/i386/sendmail-devel-8.12.11-4.24.1.legacy.i386.rpm 8d03dc1dd178543cb9d9050198774b599967bfcd redhat/9/updates-testing/i386/sendmail-doc