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: 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
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: openssl updates
On Fri, 29 Sep 2006, Matthew Miller wrote: Anything? I've created RHL73 RPMs for gnupg, openssl, and php (those updates that I'd backport myself as FL isn't useful for me anymore). Get them from http://staff.csc.fi/psavola/fl/ if interested. d446c94ebe14a471f10452f26182ecf17a5f770c gnupg-1.0.7-13.4.legacy.i386.rpm 028f3ac78dfaaee0a156697720d879f8e37d45ae gnupg-1.0.7-13.4.legacy.src.rpm 802cd5e83ff884e7a5cc17083e23818c3f8d1aa3 openssl-0.9.6b-39.11.legacy.i386.rpm 592bb8beec21af07ddac5e5dfebecba731246c18 openssl-0.9.6b-39.11.legacy.src.rpm c5c747edb36978f203b18e29e316190ae8d6b980 openssl-devel-0.9.6b-39.11.legacy.i386.rpm 02f4b171210ce5ecf6e85e6796ca62a7a5abe3e5 openssl-perl-0.9.6b-39.11.legacy.i386.rpm 258ada11b889cfc2777e66ebee2c389404b52c86 php-4.1.2-7.3.21.legacy.i386.rpm 81a02d3442c8454837b2eb70d987802a08619333 php-4.1.2-7.3.21.legacy.src.rpm 997c233ddc081916922280c686d37f36ebd818bf php-devel-4.1.2-7.3.21.legacy.i386.rpm 47c84d76c478dcf8d916a62b89b655295ac98e6a php-imap-4.1.2-7.3.21.legacy.i386.rpm ab20d09c5fd2d12f6c67d6004b309046a715a130 php-ldap-4.1.2-7.3.21.legacy.i386.rpm afc7fbbf488dec82f16bbca0036fdd5c1f1a0e42 php-manual-4.1.2-7.3.21.legacy.i386.rpm fb2f3bde5172c1d9d3616d9ef05aaa1663570ab6 php-mysql-4.1.2-7.3.21.legacy.i386.rpm 74a4f03f2030e3e2bc490c09385111f9b98b4895 php-odbc-4.1.2-7.3.21.legacy.i386.rpm 7a0cf808dcc689464c2f1a79b381742c882dd473 php-pgsql-4.1.2-7.3.21.legacy.i386.rpm 8ba7311e4b07e85dcce4b5d406124cdf6bff25ad php-snmp-4.1.2-7.3.21.legacy.i386.rpm -- 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: Fedora products, to upgrade rather than backport?
On Mon, 15 May 2006, Jesse Keating wrote: So in the RHL space, the choice was clear. Backport whenever possible. However the Fedora landscape is different. Upstream Core does not do backporting, they more often than not version upgrade to resolve security issues. Why should Legacy be any different? If we want to be transparent to end users we should follow what upstream does. My opinion here is: do whichever is the easiest. In some cases, doing a backport may be easier than upgrade [*]. One should also look at the approach chosen by other Fedora Core/RHEL releases. Other things being equal, prefer backporting. [*] For example: if you'd need to upgrade a package with a lot of dependencies which might need to be re-spun as well; or if the result would be a significant upgrade, getting assurance that the package would work, spec file updates required etc. could be significant work. -- 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: FC3 (j)whois on .eu fails
On Wed, 12 Apr 2006, Nils Breunese (Lemonbit Internet) wrote: But Red Hat maintained packages will probably be updated, while the legacy packages may not. The question is whether legacy should do update the FL maintained package or say: This has nothing to do with security so we won't fix it. I believe some people on this least agree this could be a slight security issue (at a stretch), i.e. when whois is used for automated lookups. Let me put a challenge for you guys. If I see work on jwhois src.rpm packages AND at least one another NEEDSWORK package [1], for all the relevant distributions [2], I would probably consider evaluation these under publish criteria. But unless a proponent of the update actually steps up to do the work (and some token work for some other Fedora Legacy updates), I wouldn't recommend anyone else from Fedora Legacy project to spend their time on this. We have far too many, much more important packages still sitting on the needs packages pile. [1] http://netcore.fi/pekkas/buglist.html [2] http://fedoraproject.org/wiki/Legacy/QASubmit 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: download.fedoralegacy.org not reachable
On Wed, 5 Apr 2006, Gene Heskett wrote: Am I the only one having trouble with this? I am getting a dns lookup failure. And this seems to be a chronic thing over the last 2-3 weeks for verizon's unprintable name servers. Btw, it would be nice if someone updated the private rsync access lists. -- 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: Sendmail Patch Breaks Virtusertable Settings
On Tue, 28 Mar 2006, Ralph Bearpark wrote: Do I get my config file from backup? Or re-do m4? Or await a new patch? Or what? A clear statement of advice - either here in the maillist or under advisories (http://www.fedoralegacy.org/updates/FC1/) would be very welcome/necessary. If you could test with the packages at: http://turbosphere.fedoralegacy.org/logs/fedora-1-core/69-sendmail-8.12.11-4.25.3.legacy/ , and report success/failure, it would be very helpful. If it doesn't help, you should probably do a bit of diffing to see what changed -- did .cf file change? Was it generated from Fedora Legacy or by you? What were the .mc file differences? -- 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
sendmail remote vulnerability
Hi, I hope FL core has had preliminary warning of the just-released sendmail remote vulnerability and if something has already been done about it, even better.. -- 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: 1-2-3 out, time for FC2?
On Mon, 20 Mar 2006, Gene Heskett wrote: I believe FC1 still has the following to warrant continued work, what about FC2? We're still out here, so count me in. Do you have a bugzilla account? Just wondering. -- 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: Updated tzdata packages?
On Mon, 20 Mar 2006, Matthew Miller wrote: On Tue, Mar 21, 2006 at 07:22:34AM +1000, Michael Mansour wrote: I'm just wondering has anyone considered updating the tzdata package for FC1/2? In Australia for example, our Daylight savings time changed due to the Commonwealth games. Red Hat have released updates for their distributions, but looking at FC1/2: FC1# tzdata-2004b-1.fc1 FC2# tzdata-2005f-1.fc2 And the Indiana change will bite people in the US, too. (2006a) Even though this is not a security issue, these have been fixed in any case. The tzdata/glibc packages should have been released a couple of weeks ago, but you can get them from updates-testing. RHL73/RHL9 (glibc) packages are based on tzdata 2006a; FC (tzdata) packages are based on 2005r. -- 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: Bugzilla status whiteboard explanation needed
On Tue, 14 Mar 2006, Pavel Kankovsky wrote: - rh73 and rh9 is used instead of rhl73 and rhl9 This may have been typo in the wiki, and these should be rh73 and rh90 (or rh9), at least that's what all current packages use. - impact=xxx is not documented at all It has no impact on FL ;-/ Should it? -- 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: FC3 yum instructions
On Tue, 21 Feb 2006, Jesse Keating wrote: at best, not the Extras Project. And they do maintain web pages as well as wiki pages. In fact, they only caved and went to wiki pages due to user input for various things to be in wiki (instead of requiring knowledge of XML, etc). I don't we have the same problem, and we've had wiki since (more or less) the start unlike the Documentation Project, so... I'm working on getting us to the level that Extras is. We now are a true subproject, I chair the project to the Fedora Foundation / board, same way that Extras is. We're getting closer to using Fedora CVS for our sources, and using a build system like Fedora Extras. What else keeps us from being of the same level? I'm all for getting FL closer to common Fedora infrastructure, especially as the focus on Fedora Core support is increasing. Hence, Fedora CVS, buildsystem, etc. is the direction we should go. -- 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: Comments on first verification QA
On Mon, 20 Feb 2006, Eric Rostetter wrote: Quoting Tres Seaver [EMAIL PROTECTED]: I am therefore very much inclined to back the idea that Legacy offer minimal images as starting points for would-be QA volunteers, along with directions on how to set up either VMWare's Server or Player products to use them. We might need to give people clues about using the snapshot facilities provided by the tools to ease the process, as well. Yes, I agree. I would love to see this done. I would then be able to use VM to test things also, which would be great. I guess this won't get done, unless someone gets this done. Anyone willing to do the work? -- 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: no mandatory QA testing at all [Re: crazy thought about how to ease QA testing]
On Tue, 14 Feb 2006, Mike McCarty wrote: Ok then, it seems to me that there is no longer any distinction between the released repository, and the test repository. So, please send out an e-mail three days before the first timed release so I can pull a last tested version before removing the legacy repository from my yum configuration. I can send such an email, but I'll have to charge 100 USD for the trouble. Credit cards accepted. Perhaps you forgot that Fedora Legacy is a community project? -- 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: no mandatory QA testing at all [Re: crazy thought about how to ease QA testing]
On Tue, 14 Feb 2006, Jesse Keating wrote: On Tue, 2006-02-14 at 12:54 -0600, Eric Rostetter wrote: There has been talk the last couple days of doing away with QA to get it to the updates-testing. This is what I was referencing, not the current setup. That is something I will not agree to. However the timeout period is, it strikes a balance. If we see too many packages get released w/out QA by the time the timeout hits, then that is very good indication that we can drop that platform. There has been little or no discussion or proposals regarding doing away with QA to get to updates-testing, except for a couple of misunderstandings and an idea about trusted fedora legacy [core] members who could create updates-testing packages on their own (but there wasn't much discussion on that). The current policy change proposal was about reducing the amount of QA for moving updates-testing packages to updates. So, I'm not sure why we're having this conversation.. -- 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: no mandatory QA testing at all [Re: crazy thought about how to ease QA testing]
On Sat, 11 Feb 2006, Jeff Sheltren wrote: What I'd like to see is to have something like this (Pekka's idea above) happen for regular package contributors (people that have submitted multiple packages to FL). People that haven't submitted many packages should require one of the trusted packagers/builders to do a publish QA before pushing the package to testing. Since the current state of things is that it's only a small group of people doing things, this won't really affect anyone at the moment- but it's just a way to ease new packagers in while being sure that they are submitting good packages. Yes, automatic publish without VERIFY QA depends a lot that the package proposals, PUBLISH QA (for every distro), and building and pushing to updates-testing (by FL core people) is done properly. Given that this currently (unfortunately) happens almost solely by a very small set of people (say, about 5), as you say, this isn't a problem now. Even if new people came up to join the PUBLISH crowd, I'm confident that they'd blend in because there's pretty good guidance in Wiki on how to do good package proposals, publish, etc. -- 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: no mandatory QA testing at all [Re: crazy thought about how to ease QA testing]
Hi, It seems there's rather strong agreement for this. Unless I hear major objections in two days, I'll start the two-week clock (from today) for all the pending packages. After that I'll also update the Wiki entry for QaVerify unless someone else has done it. On Sat, 11 Feb 2006, Marc Deslauriers wrote: I have proposed something simpler, and still do: 1) every package, even without any VERIFY QA votes at all, will be released automatically in X weeks (suggest: X=2). exception: at package PUBLISH time, the packager and/or publisher, if they think the changes are major enough (e.g., non-QAed patches etc.), they can specify that the package should not be automatically released. 2) negative reports block automatic publishing. 3) positive reports can speed up automatic publishing (for example: 2 VERIFY votes -- released within 1 week, all verify votes: released immediately after the last verify) There is no need (IMHO) to grade packages to more or less critical ones. Every QA tester and eventual package user uses his or her own value judgment. If (s)he fears that the (potentially untested) automatic update would break the system, (s)he would test it before two weeks are over. Publishing positive reports can be made simpler but that probably isn't on the critical path here. I agree to this. Marc -- 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
x86_64 support
Hi, There was some discussion this in bugzilla under the kernel bug, so bringing it up for wider comments. FC1, FC2, and FC3 have supported both x86 and x86_64. (FC4 has added ppc to the mix as well.) Fedora Legacy has only supported x86, but there has been discussion of extending this to x86_64. So, given that we're currently already supporting 5 different versions, 1) Should we start supporting all the architectures for previous releases (FC1, FC2) where we didn't from day zero ? 2) Should we support new architectures for new releases (FC3, FC4, ..)? My personal take would be, 1) NO, 2) Hopefully not. The reasons are simple: we don't do a very good job as it is, and adding even more versions to build and potentially test at VERIFY stage would strain this even more. Especially as many of the latest bugs seem 64-bit specific: especially for 1), we'd need to go back and check every package to make sure we didn't miss any 64-bit specific update. I'd like to pose the question as follows: is there anyone out there who would want FL to support either past, present or future non-x86 arches who is willing to commit to doing serious help? -- 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: issues list(s)
On Mon, 6 Feb 2006, Benjamin Smith wrote: 1) What testing packages are installed that you'd even care about? 2) What changes should I test for? 3) Looks good, how do I report it? So, I wrote a script to at least tell me what packages were officially testing and which were released. And, it seems to me that it's a fairly trivial step from there to take that output, and automate the feedback delivery step, if there's some kind of HTTP URI I can interface with to get the results to you. ... (Yes, I agree that this needs to be more straightforward. As I've said from the start, put a GPG-signed message w/ VERIFY vote to bugzilla _does not_ cut it. It's way too complicated if we want to involve a lot of folks.) Personally, I think the script should print out the list of testing updates currently installed, and then send it to the administrator of that system, basically asking These are the testing RPMs and here's when they were installed. Which ones do you _know_ that have been used since that date? Then the admin would send a mail to fedora-legacy-list or appropriate bugzilla entry saying, yes, we're installed the package since XXX, gpg signature is OK, and it's in active use. That would go a long way in checking that updates-testing packages have been used and found working, instead of just having been installed. -- 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: EOL planning
On Wed, 4 Jan 2006, Axel Thimm wrote: according to original planning, the following EOL dates apply: RH7.3,RH9: as long as community wants FC1: until the release of FC4 FC2: until the release of FC5 is this still reflecting the current setup? Is there some kind of statistics on the master server about which distribution is still in use? So, what's our approach here? Do we drop support for FC1 in all the subsequent updates (those where packages haven't been proposed yet)? Do we drop FC2 at the same time as we pick up FC3? -- 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
issues list(s)
Remember, there's always a need for folks to do some QA testing. See the wiki for instructions and how to get started: http://www.fedoraproject.org/wiki/Legacy/QATesting In particular, - hopefully someone from core can release the 5-6 pending updates and build some packages :) - squid needs yeah it seems to work testing, and xine a yeah, the fix seems fine -eyeballs - we need folks to propose updated packages (for all the supported distros) to fix problems, so that these packages can be QA'd. (personally I'm currently most concerned about missing kernel updates, the recent xpdf issues, and maybe the perl format string issue). http://www.netcore.fi/pekkas/buglist.html (all) http://www.netcore.fi/pekkas/buglist-rhl73.html http://www.netcore.fi/pekkas/buglist-rhl9.html http://www.netcore.fi/pekkas/buglist-core1.html http://www.netcore.fi/pekkas/buglist-fc2.html -- 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: What do users need to do to prepare?
On Fri, 16 Dec 2005, Jason Edgecombe wrote: Did the transition have to be the week of christmas, when many people are on vacation? Don't worry, unfortunately I doubt there will be any updates coming out in months so you don't need to sweat it ;-(. [1] [1] http://www.netcore.fi/pekkas/buglist.html I hope someone is working on the needsrelease and needsbuild piles above.. -- 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
active contributors and supporting distro foo
On Fri, 16 Dec 2005, Mike McCarty wrote: Whether or not there is user base for FC1 is irrelevant. Of course it's relevant. If nobody used or wanted FC1, it wouldn't be relevant. I suppose you mean that there being people who use it is insufficient to motivate you to continue to support it. This isn't directed at you, but as a more generic rant -- as I see a lot of people asking to support foo but not putting in any hours to help in the process. The project is WAY too understaffed already. ... The only thing relevant (IMHO) is whether there are ACTIVE people ACTUALLY putting in work to 'Make It Happen' (tm). There is no such thing as free lunch. If you want updates for foo, you should participate in creating those updates. Other folks may or may not do them for you. I'll rephrase to be clearer, because the project is way too understaffed already: - 90% of relevance: whether the distro has (enough) active contributors - 10% of relevance: whether there are sufficient number of users to make the effort worth the trouble of the active contributors - Only those who are or would be active contributors have a say in making a decision whether to support foo or not. -- 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: 8 more days 'til we inherit FC3; are we ready??; FWD: Fedora Core 3 Status Update
On Fri, 16 Dec 2005, Michael Mansour wrote: Just to add my 2 cents, I still use FC1, FC2 and FC3 on various servers and would still like to see FL support for them. Whether or not there is user base for FC1 is irrelevant. The key point is, are FC1 users willing to participate in pushing out packages (package proposal, verify QA, publish QA, etc.) ? The question is: If dropping FC1 wouldn't reduce the number of QA folks and the work they do [for other distros], we should drop it. -- 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
issues list(s)
Remember, there's always a need for folks to do some QA testing. See the wiki for instructions and how to get started: http://www.fedoraproject.org/wiki/Legacy/QATesting In particular, look at the both of the missing VERIFY sections or lacking PUBLISH. http://www.netcore.fi/pekkas/buglist.html (all) http://www.netcore.fi/pekkas/buglist-rhl73.html http://www.netcore.fi/pekkas/buglist-rhl9.html http://www.netcore.fi/pekkas/buglist-core1.html http://www.netcore.fi/pekkas/buglist-fc2.html -- 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: Build team?
On Wed, 19 Oct 2005, Dominic Hargreaves wrote: On Wed, Oct 19, 2005 at 09:47:13AM -0500, David Eisenstein wrote: I was wondering if we need more people on Fedora Legacy's build team? Since Dominic Hargreaves has not been able to participate, and my understanding is that Marc Deslauriers has lately had personal things to attend to, packages are not being built for updates-testing nor are release-ready packages being released. I'm happy to be prodded if build system stuff needs doing; let me know :) Sure.. There's _lot's_ of stuff waiting, just have a look at the first two categories of: http://netcore.fi/pekkas/buglist.html -- 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: FLSA:2404 (Redhat 9) question
On Wed, 19 Oct 2005, Jeff Sheltren wrote: On Oct 11, 2005, at 3:46 PM, Ben Feinstein wrote: Regarding Fedora Legacy Security Advisory 2404 of Mar 07 2005: The updated less-378-7.2.legacy RPM and SRPM are no longer available at the URLs listed in the advisory. Are these updates no longer applicable and were removed from the repository, or is there another reason the packages are now missing? Please address or CC me directly as I don't subscribe to this list... Thanks much, Ben Hi Ben, looks like they are in updates-testing: http://download.fedoralegacy.org/redhat/9/updates-testing/i386/ less-378-7.2.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates-testing/SRPMS/ less-378-7.2.legacy.src.rpm Moreover, if you look at the bug in question, some folks reported that yum crashed with this less update (though the patch was trivial and should not have changed anything in this regard). IMHO, the problem was/is likely with the build system. -- 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: Fwd: Re: releasing updates-testing packages without VERIFY votes
On Tue, 27 Sep 2005, Michal Jaegermann wrote: Personally I think that if a release early, release often principle would be applied to Legacy releases too, with a quick re-release to follow for an occasional dud (which happened anyway), we would be much further in the whole project. This seems to be a minority opinion. I totally agree with you here, especially when we're basically using the RHEL updates (which have already been subject to QA). Things would be a bit different for packages where we create the patches ourselves (or in a very non-straightforward manner), but I haven't seen many of those around.. -- 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: issues list(s)
On Fri, 23 Sep 2005, Eric Rostetter wrote: I didn't yet update the PUBLISH votes, because the patches need to be verified, check the requirements at: http://www.fedoraproject.org/wiki/Legacy/QAPublish That doesn't explicitely state that I must do so. If each of the things there *must* be done, then you need to make that more clear, and restate things that are optional as being optional, and restate what you mean since it isn't clear. It should: the first three steps are mandatory. I tried to see if I could add clarification on this, but apparently I don't have the edit rights for the page (shouldn't it be more open?) The latter bullet points are optional (which is mentioned there), implying (but not saying) that the previous ones are mandatory. I did diff the files, I did inspect the patch(es). I even *tested* the patched packages to make sure they fixed the problem. I didn't see anything unusal when I look at the patched code. I just didn't try to find the original source or upstream patch it was based on and compare them. Since others have already (before me) verified the patches versus the upstream provider, I think it can be implied that they are valid in my version since the sha1sum matched for both them and me. If not, the other person needs to be banished. ;) But I see there is a trust issue here, so I get why I should have done this step. The others have only verified the patch on the OS version for which they gave a PUBLISH vote; the patches could be different -- one could have a trojan (or just a honest mistake!), while the already QA'd version doesn't. If the SHA1sum of the patches (already verified) matches the one at your OS version (i.e., the identical patch in multiple OS versions), yes, there is no technical reason to have to verify the patch again. But for clarity, it should be pointed in the PUBLISH vote message. In additionl, PUBLISH needs to be done for all distro versions before the package can be built. Would it be possible to the FC1 review for a2ps? No, I don't run FC1. As you wish, but note that giving PUBLISH votes does not require one to run the OS version in question. I.e., it is not required to test the package; just reviewing 1) source integrity, 2) the .spec file, and 3) the new patches [if they come from an already-QA'd source] is sufficient. So, are my PUBLISH votes worth zero votes since I didn't compare the patch against the upstream publisher's version, dispite all the other work I did? Or maybe they can at least be a 0.5 vote? I'm a bit impartial in this because I proposed the packages in the first place, but I think verifying the patches is essential. Even thorough testing of the packages may not show problems if the patch is not (quite) right. -- 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
Mock [Re: issues list(s)]
On Fri, 23 Sep 2005, Jeff Sheltren wrote: Are you talking about creating packages for each distribution, or QAing them? If it's for creating them, I'd suggest using mock. Creating, yes. See: http://fedoraproject.org/wiki/Legacy/Mock Note that Paul Howarth found a bug in FC1 glibc which causes FC1 build root creation to fail on 32bit processors (everything seems to work fine on x86_64). I think this can be fixed like so: -- The workaround is to turn off vDSO support in the host kernel: # sysctl -w kernel.vdso=0 -- Hmm.. I guess this requires having quick access to all the RPMs in all the OS versions so building can be done quickly. Maybe the Fedora Legacy should provide 'Mock' as a service for creating packages for PUBLISH QA? That way all folks wouldn't need to set up their own Mock systems. -- 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: Fwd: Re: releasing updates-testing packages without VERIFY votes
On Fri, 23 Sep 2005, Eric Rostetter wrote: I guess there is still a question: If I QA a package on RL 7.3 and RHL 9 is that one vote (since one person did the QA) or two votes (since I did two OS versions)? That's two votes, by current counting. -- 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: issues list(s)
On Fri, 23 Sep 2005, Eric Rostetter wrote: Quoting Pekka Savola [EMAIL PROTECTED]: Remember, there's always a need for folks to do some QA testing. See the I've done PUBLISH QA for enscript and a2ps, but I can't update the whiteboard, so someone else will have to do that. I did VERIFY QA for rp-pppoe and squid, but again, can't update the whiteboard. Thanks. I did update the whiteboard for VERIFYs. (Only the bug creator and specially privileged folks can edit these, unfortunately.) I didn't yet update the PUBLISH votes, because the patches need to be verified, check the requirements at: http://www.fedoraproject.org/wiki/Legacy/QAPublish In additionl, PUBLISH needs to be done for all distro versions before the package can be built. Would it be possible to the FC1 review for a2ps? -- 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
issues list(s)
Remember, there's always a need for folks to do some QA testing. See the wiki for instructions and how to get started: http://www.fedoraproject.org/wiki/Legacy/QATesting In particular, IMHO the biggest need right now is getting people to propose updated packages for *ALL* the distribution versions (this is challenging at least for me because I don't have access to all of them -- are there any ways to make this easier). There are also 4 pretty trivial updates in lacking PUBLISH category. Lots of packages also need updates, but I don't think folks are inclined to create these until more people show up to do QA on the existing ones. http://www.netcore.fi/pekkas/buglist.html (all) http://www.netcore.fi/pekkas/buglist-rhl73.html http://www.netcore.fi/pekkas/buglist-rhl9.html http://www.netcore.fi/pekkas/buglist-core1.html http://www.netcore.fi/pekkas/buglist-fc2.html -- 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: Updated httpd packages
On Wed, 3 Aug 2005, Gilbert Sebenste wrote: Just thought I'd let you know I tried the httpd packages and the mod_ssl, and all appears to be well after running for 3 hours. Give this a +VERIFY. Could you put this (and also the OS version :) in bugzilla, preferably GPG signed? Thanks! https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=157701 -- 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 http://www.redhat.com/mailman/listinfo/fedora-legacy-list
Re: Mozilla update: jvm plugin broke?
On Mon, 25 Jul 2005, Marc Deslauriers wrote: On Mon, 2005-07-25 at 10:37 +0300, Pekka Savola wrote: .. It started working again when I replaced the symlink to the non-gcc32 version of the plugin. Did anyone else notice something like this? On what OS? Sorry, I said have said this before. RHL9. -- 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 http://www.redhat.com/mailman/listinfo/fedora-legacy-list
