Re: New proposed top level FAQ for the defunct FedoraLegacy project
Quoting Jesse Keating [EMAIL PROTECTED]: On Friday 09 February 2007 14:51, Rahul Sundaram wrote: Is funding really a issue? Unless you mean putting full time Red Hat employees on it, I dont see it as major problem. Without motivation like a paycheck, it is difficult to get people interested in doing the work. This is the same as saying Opensource can't work... Freeware will never catch on... Altruism doesn't exist. People only do things for money... These are not true, unless applied to specific individuals rather than as a generality. So funding, in that form, was an issue. I don't think so... Also current resources are being shut down due to them costing money. That is in part true. But why would someone fund them (waste money on them) when there is no real justification for their existance? In other words, they are being shutdown not just because they cost money, but because there is no way to justify spending any money on them. I'm betting if there was a reason to keep them alive, the funding would be found without any problem... But the sad truth is, there is no way to justify spending the money on them, as there is no real value to them. They lost their value when the project shutdown. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -- 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: New proposed top level FAQ for the defunct FedoraLegacy project
Quoting Jesse Keating [EMAIL PROTECTED]: No, it's not the same. Opensource works because a lot of people like working on creating new code and improving existing code. Maintaining old code is just not fun/glamorous work. Yet people do it without a paycheck. Why? Either because they have a self-interest in it besides a paycheck, or they want the fame, or they want to help others, or some other equally foolish reason. The point is, people will do it without a paycheck if it is important to them. The majority of work done in this area of opensource is done by paid engineers Yes, but that doesn't mean the minority should be ignored. and what isn't done by paid engineers is most often based on what paid engineers are doing. In certain types of projects, yes. (That was the way FL was run, since it was coding into the project that it was to be done that way). -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -- 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: New proposed top level FAQ for the defunct FedoraLegacy project
Quoting David A. Ranch [EMAIL PROTECTED]: It's not being re-examined. As far as I know, it is still being examined. I would change that line to say The FedoraLegacy Project has shutdown and has ceiesed offering any RPM updates for all legacy Redhat and FedoraCore distributions. Please see below for additional information. I think the information below makes that fairly clear. 2. The 4th QA section on the page is mis-formatted. Move the A: to a newline Fixed. 3. I would add a link to the Fedora-legacy-list archives as a final bullet for people to learn more about the shutdown beyond this short faq http://www.redhat.com/archives/fedora-legacy-list/ This is not under my control... Maybe someone else can do this though. 4. The download page should be completely removed or at least completely stripped. Why offer information on how to Legacy-enable old distros if the master download.fedoralegacy.org site is forever dead? Because people claim they want to still keep the mirrors going so people can download the updates... 5. Any news on how long the website will stay up? Who runs this server? Redhat or someone else? AFAIK Jesse does... --David -- 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: Legacy's Success; Re: why I'm using Ubuntu instead of Fedora ATM
Quoting David Eisenstein [EMAIL PROTECTED]: As a long-time contributor to and advocate for the Fedora Legacy Project, I have to say that, over most of its life, Legacy did not fail its mission, if one were to consider Legacy's mission to provide security updates to packages that people really cared about. Why? I agree completely. It was really when we decided the drop RHL and FC1 that things fell apart, IMHO. Of course, it didn't help that other options came along, but this is exactly what _should_ happen. I joined Fedora Legacy when Red Hat dropped RHL and didn't provide any _upgrade_ path (the only supported RHEL install was a fresh install, not an upgrade from RHL). My only other option was to switch to a non-RH distro, which would be as bad as a fresh RHEL install (but cheaper perhaps). Well, a few years later, we have lots of RHEL options (Centos, Whitebox, etc) and a community of users who will help provide community support to those who upgrade to those from RHL. We also have of course Fedora Core and its ability to upgrade between releases. So Fedora Legacy is no longer the only option. As such, it isn't needed as much. As such, it is natural that participation would fall off some. For the longest time, I personally cared about Fedora Core 1, and also cared about the old Red Hat Linux releases 7.3 and 9.0. The project Yes, I was in it for the RHL only. When that was killed off, I had no real reason to stay (but I did anyway). And what about Red Hat Linux 7.3 and 9? Even longer! For these three releases, and also perhaps FC2, this project was more successful than perhaps the founders of Fedora Legacy had hoped or dreamed it would be. Yes, and I think that was a problem too. Jesse didn't want to keep supporting RHL, but most of the community was most interested (IMHO) in RHL, and hence we had a problem. Jesse was most gracious in allowing us RHL folks to hijack his FC project, to tell the truth... A lot of the work towards the end of the useful life of Fedora Legacy was done by one man: Marc Deslauriers, to which all Fedora Legacy users owe a LOT (and I mean a *LOT*) of thank-you's! He was the one Yes, THANK YOU Marc! I really appreciate all you (and the other core people) did! Thank you from the bottom of my heart, Marc!!! Your example is one we should all be committed enough to follow and emulate! Indeed! for Marc. I believe the few who did most of the work finally burned out. Probably. But also lost some interest, when the versions they cared most about were discontinued, I suspect. That was the case for me at least. My assessment is this: If legacy failed it did so in these areas: * Management of contributor resources Not sure what that means really. * Devotion of people who knew how to motivate and cause people in the contributing community to feel valued, motivated and special, and to give a voice to those who cared. Definately. Legacy rarely had meetings, had no board to speak of, and therefore no clear mechanism of accountability. Yes. Getting any changes made that were not coming from Jesse, Marc or David, or Pekka seemed impossible. My suggestions on how to improve the situation never got anywhere... I hope the good folks of Legacy remember Legacy *not* as a failed experiment, but as one that lasted longer and did better than folks had any right to expect. Yes, that is about how I'll remember it. And I think all those who joined for RHL support will remember it that way too. Warm regards, David Eisenstein And I'd like to thank David for all he did for the project too! -- 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: {Spam?} Re: Legacy wiki -- statement?
Quoting Jesse Keating [EMAIL PROTECTED]: On Tuesday 12 December 2006 14:47, Eric Rostetter wrote: If Jesse approves, I can put the same notice on the fedoralegacy.org web site... Please do. I copied the wiki text to the website... I'm not happy with the way it looks, so I'll try to improve it when I get time, but at least it is up on the site now... -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -- 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: Legacy wiki -- statement?
Quoting David D. Eisenstein [EMAIL PROTECTED]: So what do we need to be saying here? Ideas? I think we're going a bit fast... Do we really want to wrap up the project now, or just put it on hold for a while, or wait until we hear back about the 13 month plan? I'm not sure we have a consences yet... http://fedoraproject.org/wiki/Legacy I would say we can come up with something that says we're evaluating our options, and you shouldn't expect (or depend on) timely updates at this time, yada yada yada. But I'm not sure we should completely pull the plug yet (without more consensus like discussions) and I sure don't think we should say stuff about the open-core/13-month-extension and so on that are not yet decided. Or, maybe I just missed the consensus? Or maybe I missed the principles statement they are bailing? -- 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: Important information regarding the merger of core and extras, and what this means to Legacy
Quoting Matthew Miller [EMAIL PROTECTED]: On Tue, Nov 14, 2006 at 10:06:57PM -0600, Eric Rostetter wrote: First I would like to say to those who say Fedora Legacy has failed, that it _did_ work (i.e. didn't fail) for the most critical time period and the most critical OS version (RHL 7-9, FC1). If it has failed, or is failing, it must not be forgotten that before it failed it worked exceedingly well. Or at least moderately well. Let's not over-sell. :) I really think we did do incredibly well to start. We were often faster than others, and often had less bugs than others (e.g. Progeny, spelling?). We've only had two major problems with releases (one where a kernel install failed to update lilo correctly but worked with grub, and one where sendmail didn't work correctly on some older RHL upgrades). We did have to dump RHL 8 quickly, and later RHL 7.2, but we stayed strong for a couple of years on RHL 7.3 and RHL 9. And did a pretty darn good job on FC1 also IMHO. Now we don't have much demand for RHL any more, and we've failed pretty bad to get any timely updates out for FC 2 through FC 4, but that isn't the initial period I was talking about. That is the current situation, which I admit hasn't gone well... Second, I'm fairly comfortable with saying that if FC goes to a 13 month support cycle, FL is basically not needed anymore. IMHO, people can upgrade once a year when presented with a known/documented release cycle, and known documented alternatives. One month of annual overlap is still a bit short. _IF_ you want to use Fedora Core, you need to be willing to upgrade once a year. And the 13 month window gives you just this amount of time to upgrade. If you can't upgrade once a year, then you most certainly should not be using Fedora Core. My problem has always been I work in University settings where updates only happen during breaks (Spring break, Summer break, or Winter break). On the current Fedora Core schedule, a release can come at any time, and leave me unprotected (if not for FL) until the next University break comes along. With 13 months, I can easily stay with a release until the next break period when I can upgrade. I really don't see a problem with the 13 month support period, given Fedora Core's mission of being cutting edge. You can't be cutting edge, free/community-based, and support a release more than a year or so... -- Eric Rostetter The Department of Physics The University of Texas at Austin Go Longhorns! -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Re: Important information regarding the merger of core and extras, and what this means to Legacy
Quoting Matthew Miller [EMAIL PROTECTED]: On Wed, Nov 15, 2006 at 11:15:51AM -0600, Eric Rostetter wrote: My problem has always been I work in University settings where updates only happen during breaks (Spring break, Summer break, or Winter break). On the Same here -- except I'm not sure I can rely on people to update during the spring and especially winter breaks, or that the 13th month hits the summer break in a convenient way. I don't have to rely on people to update during the spring and especially winter breaks since I'm the only one who does the upgrades, and I can usually depend on myself. ;) Of course, this doesn't scale well... Fortunately I only have 80 machines to worry about, so it is no big deal. If I had to do this in such a short time period with say 200+ machines, then we'd have a problem... -- Eric Rostetter The Department of Physics The University of Texas at Austin Go Longhorns! -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Re: Important information regarding the merger of core and extras, and what this means to Legacy
Quoting Jesse Keating [EMAIL PROTECTED]: On Wednesday 15 November 2006 10:32, Gene Heskett wrote: Theres several reasons, the old kernel version being one of them. Firewire doesn't work that I know of, and I have a firewire movie camera. I missed what this is about, but if it is about the CentOS/RHEL kernel, then simply install the unsupported kernel to get the firewire support. Works for me at least (with firewire removable disk drives). -- Eric Rostetter The Department of Physics The University of Texas at Austin Go Longhorns! -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Re: Important information regarding the merger of core and extras, and what this means to Legacy
Quoting Matthew Miller [EMAIL PROTECTED]: I'm not able to force anyone here to do anything. Therefore, I have to That's the first problem... You either need to be able to force them to do the right thing, or punish them for failure. If you can't do one or the other of those then you're screwed, to put it bluntly. encourage good practice entirely via carrots. sticks work also. You get hacked, we unplug you from the network until you comply. Gets their attention real fast when they are removed from the network. Works better than carrots actually, in the long run. This works best when we align with the academic year -- a release in the spring, current through the following summer to allow time for upgrades. Ideally, *two* years and a summer, but I understand that's not practical. 13 months for two versions gives you a lot of time IMHO... As it is, what will happen is: whatever Fedora release is current as of June-July-August will get installed on people's systems, and, with goading, upgraded the next summer. Upgraded in the summer, whether the summer of the same or next year, and the problem is solved for 99% of the cases... Only way that fails is if you install early in the year (from January to April) and the next release is done right after school (fall) starts that year... In which case, that will hopefully be a small number of machines which you can knock off during winter or spring break, leaving the majority until the summer. The draw back of the above of course is you need to track all the machines, their versions, and installation dates, and keep that data updated. Basically you need a good DB of the machine information... If the actual Fedora release happens to be new in June-July, the 13-month plan will be great, but if the latest release was from, say, January, that leaves a big hole in which systems *will* get broken into. If you install in January, then just upgrade in the summer if a new release is out by then. See above for the rest of the details. I suppose there could be a small hole, which is why most release cycles are 1.5 years instead of 1.08 years... But your call for 2.5 years seems way too long for a project that wants to be cutting edge (and which you point out your users want because it is cutting edge. If they want cutting edge, they need to upgrade once a year, or else they are not cutting edge anymore). panning out, and how it fits with merging Extras and Core. The availability of Extras is currently a huge draw for Fedora over CentOS.) CentOS has Extras/Plus also for a lot of packages... And there are lots of other packagers making extras like repositories out there... For the desktop user this should be more than sufficient. It may of course violate server or production users who have QA issues with that type of thing. In fact, one advantage of RHEL over FC/CentOS/anything-completely-opensource is it actually comes with non-opensource software that is commonly desired, and which is kept updated for security problems... Extending the lifespan from ~9 to ~13 months is a huge help, but to cover the gaps, we really need more like 18-19. I really disagree. The project is to be cutting edge, your users want cutting edge, the only way to do that is to upgrade yearly. Otherwise, both the project and your users are not cutting edge. If you can't manage the upgrades in a year, then you need to hire more staff locally (or better automate your upgrades). Now, I really do feel for you and your situation. But I don't think you can impose your bad situation on the Fedora Project, when you claim your users really do want the same thing as Fedora Project, which means you really do need to upgrade yearly, and not every 2.5 years. Fedora Legacy is doing your users a disservice IMHO by not allowing them to be cutting edge as they want to be. In your case, I would think the only way to meet your needs would be with Fedora Legacy, as Fedora Core just can't do 2.5 years of support and meet its mission. But I'm not sure there are enough people in such a unique situation, and who are so fixated on Fedora Core over other distributions, to sustain something like Fedora Legacy. Of course, I could be completely wrong... :) -- Eric Rostetter The Department of Physics The University of Texas at Austin Go Longhorns! -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Re: Important information regarding the merger of core and extras, and what this means to Legacy
Quoting Matthew Miller [EMAIL PROTECTED]: * In fact, I'm pretty certain I'm not, and that there are thousands of users running FC1, FC2, and FC3 and just waiting to become botnet members if they're not already. The difference is that my users have me to care about them. Well, I agree there are _at least_ thousands of users running FC1-3 waiting to be botnet members. And most of them neither know about Fedora Legacy nor have someone like you to care about them, so extending support via FL won't help the majority of them... Sad, but no doubt true... That doesn't mean FL shouldn't exist. Even if we can only stop a small percentage from being hacked, that is still a very worthy goal which will have positive effects on the internet/world. However, if you can find a sufficient number of those who do know (or will learn) about FL, or who have people like you who will care for them, and can get them to support FL is some way, then there would be no problem keeping FL alive to do so. But there has to be a certain level of support, and I really don't see that happening myself. Again, I could be wrong... The reason there was so much RHL 7/9 and FC 1 support was Red Hat really dropped us with almost no advanced notice. We were aleady on the Red Hat gravy train and the rug was yanked out from under us, and we had little choice. I don't consider people installing Fedora Core 3/4/5/6 to be in that same boat: they should know what they are getting into, and should have a plan that meets their needs for the future. As such, there are not so many people dependent on FC 3/4/5/6 and hence less people willing to do the hard work for it. Basically, FL was a _need_ for some of us at the start, but it isn't a need for most people now. There are easy alternatives now that didn't exist back when RHL was dropped and FC was started. Anyway, I'm going to try to stop participating in this thread after this message. I think I've said more than I should have already... I'd be more than happy to see FL survive. I'd even be willing to help out some. But it is no longer something I need, just something that gives me a warm, fuzzy feeling... -- Eric Rostetter The Department of Physics The University of Texas at Austin Go Longhorns! -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Re: I get this error when trying to upgrade my 2.4.20-8 to 2.6.3 after make install
Quoting Bill Perrotta [EMAIL PROTECTED]: Someone please help. I need to recompile redhat nine to add disk quotas for my rhce. Okay. So recompile the correct version of the kernel. I get this error when trying to upgrade my 2.4.20-8 to 2.6.3 after make install see below You can't upgrade the kernel from 2.4 to 2.6 without upgrading lots of other packages also. RHL 9 doesnt' support 2.6, and while you can shoe-horn it on (I did), you need to upgrade a lot more than just the kernel (module utils being one of the biggest ones). Have you looked into this and done the other upgrades needed also? CC drivers/isdn/hardware/avm/b1isa.o drivers/isdn/hardware/avm/b1isa.c: In function `b1isa_init': drivers/isdn/hardware/avm/b1isa.c:183: structure has no member named `irq_resource' If that is really an ISDN thing, and you don't need ISDN, you might just try configuring the kernel to not use ISDN. Most people don't need ISDN support. -- Eric Rostetter The Department of Physics The University of Texas at Austin Go Longhorns! -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Re: I get this error when trying to upgrade my 2.4.20-8 to 2.6.3 after make install
Quoting Bill Perrotta [EMAIL PROTECTED]: The disk quota feature is all i'm interested in because it's on the rhce exam. Forget about security or anything else. I need to complete the labs RHL 9 had disk quota support. The same support basically as RHEL 3.x. You should not have to upgrade to any newer kernel. If you want a RHEL type system, why not use a clone like CentOS instead? It is mucher closer to RHEL than RHL 9 will ever be. -- Eric Rostetter The Department of Physics The University of Texas at Austin Go Longhorns! -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Re: Important information regarding the merger of core and extras, and what this means to Legacy
Quoting Jesse Keating [EMAIL PROTECTED]: See my blog regarding the future of Legacy as a project. Please remember these are just proposals and not final solutions. A wiki page will follow soon. First I would like to say to those who say Fedora Legacy has failed, that it _did_ work (i.e. didn't fail) for the most critical time period and the most critical OS version (RHL 7-9, FC1). If it has failed, or is failing, it must not be forgotten that before it failed it worked exceedingly well. Second, I'm fairly comfortable with saying that if FC goes to a 13 month support cycle, FL is basically not needed anymore. IMHO, people can upgrade once a year when presented with a known/documented release cycle, and known documented alternatives. Now, I don't know that FC will change, or if FL is needed any more even if FC doesn't change. But I do know that FL saved my life by being there when I needed it, and while I don't really need it any more I'm forever grateful to it for being there when I did need it. -- Eric Rostetter The Department of Physics The University of Texas at Austin Go Longhorns! -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Re: Need SeaMonkey opinions - [Fwd: [RHSA-2006:0734-01] Critical: seamonkey security update]
Quoting David Eisenstein [EMAIL PROTECTED]: There are some old Bugzilla's that had been open for RHL 7.3, RHL 9, FC 1, FC 2, and FC 3 for Mozilla. There has been a running discussion (and no action -- largely my fault -- sorry!) about how and whether we upgrade Mozilla to SeaMonkey so that SeaMonkey becomes a Mozilla replacement (Core) package rather than an Extras package on a Bugzilla ticket for SeaMonkey. The Bugzilla number is 209167: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=209167. I personally think this would be a good thing. I'd vote for upgrading from mozilla to seamonkey, as long as we can get people to do the work... The advantage of having SeaMonkey do this is that all other packages (such as yelp, epiphany, possibly others) will inherit the more secure code from SeaMonkey, since they tap into the shared-library (.so) files that SeaMonkey would be providing. My understanding then also would be that SeaMonkey is meant to be API compatible with Mozilla, so that other programs that depend on functions (or objects) in Mozilla's shared-library should continue to work okay, possibly without recompilation, but probably requiring recompilation and pushing to updates. We'd need some real good testing for this upgrade of course. But I'm definately in favor of trying. Does anyone have any comments on how you wish the Legacy Project to approach this? I favor SeaMonkey as a Mozilla replacement, as it covers all vulnerabilities in packages that dynamically link to the shared libraries. But perhaps there are other ideas. I think that going to seamonkey is the logical thing to do for RHL and early FC releases. Not sure how later FC releases should be handled, since I don't use them. Note this is in-line with mozilla.org and redhat.com, and basically is the industry standard upgrade path. So I think we are fully justified in doing so. Since Legacy Mozilla/Firefox/Thunderbird security bugs have been open since June (and not worked on), I also advocate that we in Legacy build SeaMonkey packages for *all* releases of Fedora Core that we have ever supported (since older releases were supported at that time) and RHL 7.3 and RHL 9. Does anyone object to that? Sounds great. I can test them on RHL 7.3, RHl 9 and FC 3 64-bit. I'm willing to do any installation/functionality testing required on those versions. Those are the only versions I have access to for testing. What say ye?? Sounds good to me. Regards, David Eisenstein -- Eric Rostetter The Department of Physics The University of Texas at Austin Go Longhorns! -- 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
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: Migrating from RH9 Legacy to CentOS 3
Quoting Ralph E. Kenyon, Jr. [EMAIL PROTECTED]: I'm still using RedHat 9 and up2date. What would I have to do to upgrade to a fedora version? You can either: 1) Install yum and upgrade that way 2) Download and burn a Fedora Core (or whatever RHEL/FedoraCore based distro you want) ISO to a cdrom, boot from the cdrom, and upgrade that way. If you want to go from RHL 9 to some similar version (Centos 3.x, Fedora Core 1, etc) then you can upgrade fairly painlessly either way. If you want to skip generations (upgrade to Centos 4.x, Fedora Core 5, etc) then you will probably have lots of problems/issues, and I don't recommend skipping over versions like that. In those cases, I do multiple consecutive upgrades (e.g. RHL 9 - Fedora Core 1 - Fedora Core 2 - Fedora Core 5, or RHL 9 - Centos 3.x - Centos 4.x). There is just too much different between RHL 9 and current OS versions to rely on the upgrade between them without going through some inbetween releases. -- 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: 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
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: Fedora Core 4 x86_64 Yum update issues
Quoting Dennis [EMAIL PROTECTED]: I am trying to update my x86_64 installation of Fedora core 4 and I am getting the following message from Yum and I need help to resolve this issue. As someone else already pointed out, all of these are packages needed to run a cluster. Unless you know you need them (because you are running a cluster system, or a GFS file system), you can just remove them as the other person suggested, and in doing so not only fix it this time but also for future updates/upgrades. If you _do_ need these packages, then you should try the command yum upgrade kernel* which _should_ fix the problem allow your next yum update/upgrade to work. -- 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
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
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
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
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: apache logging problems
Quoting Joshua Andrews [EMAIL PROTECTED]:
now, sometimes after the Sunday 4:02 AM restart there is no more
logging (combined log or error log), for the virtual servers and I have
to stop and restart apache to get logging working again. The logs are
rotated properly and there are new files created which are writable but
no entries are made.
Apache isn't seeing that the files have been rotated, and is still
writing to the old files.
Any ideas what is going wrong?
Fix your logrotate scripts. Probably need a postrotate line to
restart apache, maybe even some other options Maybe something
like:
/var/log/httpd/*log {
missingok
notifempty
sharedscripts
compress
delaycompress
postrotate
/bin/kill -HUP `cat /var/run/httpd.pid 2/dev/null` 2
/dev/null || trueendscript
}
The compress and delaycompress are optional (i.e. only if you want the
logs compressed).
Of course, instead of kill -HUP you could use /etc/init.d/httpd or
/usr/sbin/apachectl directly to restart the web server...
Thanks,
-Joshua
--
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: apache logging problems
Quoting Joshua Andrews [EMAIL PROTECTED]:
The httpd logrotate script was much as you wrote it out but there are
so many entries because of the virtualhost logging that I have
consolidated them all into one expression;
/var/log/httpd/access_log /var/log/httpd/any_log etc... {
missingok
postrotate
/bin/kill -HUP `cat /var/run/httpd.pid 2/dev/null` 2 /dev/null || true
endscript
}
You left out the sharedscripts option.
I am thinking that restarting httpd so many times as I had logs may be
the problem.
Unless you use the sharedscripts option as I showed, it will still
restart it for each log file listed. The sharedscripts option tells
it to only run the script once after rotating all the logs
Thank you for the response, it helps getting another view.
-Joshua
No problem.
--
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: md5 errors
Quoting jim hamby [EMAIL PROTECTED]: Error: gpg key dosen't match for tetex-latex and XFree* Well I cured that with gpg=0 Yeah, or import the correct keys. It could be the Fedora Legacy Key, or the Red Hat key. Or it could be a red herring, and the keys are fine, but the downloaded files are corrupted. Now I get the following Error: MD5 Signature check failed for /var/cache/yum/updates/packages/tetex-latex-1.0.7-47.5.legacy.i386.rpm You may want to run yum clean or remove the file: /var/cache/yum/updates/packages/tetex-latex-1.0.7-47.5.legacy.i386.rpm Exiting. Usually this means there was either a network problem downloading the files, or a disk problem on your machine such as quota, disk full, etc. Check that your /var and/or / partition isn't full (after you get the message). I am totally lost Confirm that it isn't a disk space issue first, as that is the most likely problem. Once you answer that, we can move on to other ideas if needed. Jim -- 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: Yum config for Fedora Core 4
Quoting Jesse Keating [EMAIL PROTECTED]: You can pick up the config file from: http://download.fedoralegacy.org/ This page needs to be updated to reflect FC1 and FC2 being retired... -- 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: Yum config for Fedora Core 4
Quoting Jesse Keating [EMAIL PROTECTED]: You can pick up the config file from: http://download.fedoralegacy.org/ Oh, and to add a link to FC4 also :) -- 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: Yum config for Fedora Core 4
Quoting Aaron Konstam [EMAIL PROTECTED]: I must be the only incompetent on the list. Two things: Nope. 1. I find nothing related to FC4 on the website above. Try again, and use the page refresh button to make sure you have a recent copy. Or, just go to http://www.fedoralegacy.org/ and follow the links there. Both are very recent changes though. 2. I have no idea what the statement, Oh, and to add a link to FC4 also means. The page was out of date. It is now up-to-date. I keep- asking about this and I do not get an answer I can understand or use. Why is this? Because sometimes change takes time... It isn't that you are getting no answer or that changes are not being made; it's just that the changes and answers are sometimes slow to happen. -- 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: Yum config for Fedora Core 4
Quoting James Kosin [EMAIL PROTECTED]: I believe RH9 was retired many ages ago also. - -James Nope, see http://www.fedoralegacy.org/ for information on what is and is not retired by FL (and when RHL 9 will be retired). -- 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: Announcing End of Life times (Fedora Core 1, 2, Red Hat Linux 7.3, 9)
Quoting Erik Forsberg [EMAIL PROTECTED]: I fully understand the background to this decision, and I would like to thank the fedora legacy team for providing support for these distribution so long. AFAIK, FL is the last to drop support for these, as far as security backports goes (as compared to updating packages to newer versions). Now, if I still need to have some RHL7.3 machines running, are there any commercial alternatives available to fedora legacy for security updates? I haven't any, but perhaps my Google luck is not good enough? You can see if you can get a custom arrangement with http://transition.progeny.com/ They killed off their support also, but their page leads me to believe they might be willing to do individual support contracts still... Other than that, I would think you are out of luck with 7.3 machines... Just too old for anyone to take seriously any more... -- 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: Meeting results
Quoting Jesse Keating [EMAIL PROTECTED]: Fedora Core 1 and Fedora Core 2 go EOL (dropped by us) when we pick up Fedora Core 4. This follows our stated lifespan policy. RHL7.3/9 get a staged death: New issues (bugs) will be accepted until October 1st. No new bugs after that mark. Existing bugs will be resolved by Dec 31st or never resolved. I can live with this, if we announce it asap. If we don't get a decision and announce it in the by July 15th, then I would add one month to everything. -- 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: Fedora Core 4 coming . . . sunset, infrastructure issues . . . meeting?
Quoting Jesse Keating [EMAIL PROTECTED]: 4) Has the community reached any kind of consensus on the issues of potentially retiring Red Hat Linux 7.3, Red Hat Linux 9, Fedora Core 1, Fedora Core 2? The best plan I heard thus far was to phase out FC1 and 2 at the proper time (when FC6 reaches test2 and we get FC4), but give RHL 6~ months to get moved to something better. Sounds good to me. -- 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: Friday Flames - What to do with RHL7.3/9 and FC1/2
Quoting Jesse Keating [EMAIL PROTECTED]: Um, that's all we've BEEN doing is security fixes. Really, it should have been obvious to anybody that started using Legacy that one day we would stop supporting RHL9. If your product is in the hands of Legacy, perhaps it is time you start looking for a migration path. Plain and simple. The talk when FL started was that RHL would be supported for a long time, specifically as long as there was interest in it. This was probably bad talk to be spreading, but it was what was being spread. Anyway, the concern was to keep RHL alive until there was a good migration path. That path has been arriving as of late. So it is reasonable to now talk about dropping RHL. But just because some migration paths are now available doesn't mean people have planned for the migration. So we need to be sensitive to that, and give people a warning that the time is now to plan for the migration, and you have X amount of time to accomplish it. I've stayed with RHL a lot longer than I thought I would because the migration path simply wasn't there at first, and wasn't well tested and debugged until recently. I've slowly been migrating to non-RHL versions, and I _have_ been bit by a few things (like NIS incompatibilies for example). There are other issues (for example a supported RHEL or clone install of 3.x now requires 256 MB of memory, which was not the case for RHL, so people may need to upgrade RAM and other things (disk partition sizes, etc). I think that most of the problems with migration have either been worked out or found out (usually with a work around) by now, so it isn't a tremendous problem like it was 2-3 years back. So now is a good time to drop RHL IMHO. In fact, I think it is important we think about forcing people to move from RHL to something else now, while the options for a semi-compatible upgrade are available. What I mean is, most distro's are quickly running towards the 2.6 kernel and its various OS changes, and making an upgrade from RHL to a 2.6 distro is a painful thing to do for a complex production system. So they need to be encouraged to do the less painful jump from RHL to a 2.4 kernel based distro now, while those 2.4 kernel systems are still available and supported. If we coddle them to long, when our RHL support does die, it will be a real problem migrating to a 2.6 based system for many folks. And if those folks are still running RHL at this time, they are not likely to pay for support or migration services. Hence, as much as it pains me to say so, now _is_ the time to address this issue. -- 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: Friday Flames - What to do with RHL7.3/9 and FC1/2
Quoting Nils Breunese (Lemonbit Internet) [EMAIL PROTECTED]: that one to CentOS 4. How much time will there be between the announcement of EOL and the actual end of support? People might want to have some time to plan migrations. Nils Breunese. Indeed, or FL will be doing the same thing RH did to start FL, and we might need to create a FLL (Fedora Legacy Legacy) group to deal with it. ;) -- 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: Fedora products, to upgrade rather than backport?
Quoting James Kosin [EMAIL PROTECTED]: not to start any kind of flame war, but just for accuracy's sake, the recent sendmail release *was* tested before public release - i Yes, but IMHO not enough, but that is totally another matter. that may say that our required testing is insufficient; i wouldn't presume to comment on that. but i don't believe sendmail was rushed out the door any more untested than any other package would have been. It was tested as well as anything is, which isn't very well any more. But again, that is another issue. The relevant issue with this is that sendmail was indeed a case where backporting was not feasible, and upgrading was required, for some versions (in this case old RHL releases). And an example of both how FL does upgrade versions when needed, and what kind of issues can arise when that happens. As can be seen in the sendmail upgrade, lots of other things (alternatives, pam, etc) can come into play that are not immediately obvious. -- 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: Fedora products, to upgrade rather than backport?
Quoting Jesse Keating [EMAIL PROTECTED]: So in the RHL space, the choice was clear. Backport whenever possible. True. 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? Only because FL was originally do no harm type of philosophy, based on the idea that people would want stability, for example for servers. Now, one could argue that one shouldn't use FC for servers, and one shouldn't expect FC to be stable, and if so, one could say there is no reason to worry about backporting FC and that one should just upgrade packages. If we want to be transparent to end users we should follow what upstream does. Depends on what transparent means. If you want to be transparent in the sense of not breaking people's working machines, then no, you should backport. If you want to be transparent in the the sense of keeping with FC practices, then yes, you should upgrade instead of backporting. Flames? Thoughts? No flames, only thoughts, and not very deep thoughts at that. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -- 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: Fedora products, to upgrade rather than backport?
Quoting Stephen John Smoogen [EMAIL PROTECTED]: I think that we should try and take some reasonable goals for timelines for security: I don't think we have the man-power to set goals for all patches. But we should and do use the timeliness criterium for whether to backport or upgrade already. Second, how hard is it to backport? We alread consider this, though we have no defined process for doing so. Hard: Code is no longer maintained and a quick patch attempt showed lots of collisions and rewrites. Moderate: Code is maintained, but code is different. Low: Patch was given for this version or code is only slightly different. Seems reasonable, and is probably how we already would approach the situation even though it isn't really quantified. But, it also needs to look at the other side of the coin, that of upgrading: How hard would it be to upgrade rather than backport: Hard: Requires the non-trivial updating of other packages too (e.g. 2.4 kernel to 2.6 kernel requires too many other changes to be reasonable, same for LVM1 to LVM2, etc). Moderate: Requires a lot of work for the end-user (e.g. upgrade apache 1.x to apache 2.x requires configuration changes, may break many modules or require module upgrades, etc). Easy: Upgrading this package does not require any other packages to be upgraded (or if it does, they are also trivial/easy), doesn't require configuration files be manually upgraded, etc. Third, how expert are you (the patcher) on what the vulnerability is, what the code is, and how you are 'stopping' the vulnerability from being there. I'm not sure that should come into play per se. I think from those three, one could work out a decision tree on backporting or new release. In the case of new releases, we would make it part of the QA process to try and give a quick documentation of changes between old version and new version. -- 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: Fedora products, to upgrade rather than backport?
Quoting Jesse Keating [EMAIL PROTECTED]: Sure, for RHL it is about stability. But with FC it was more about extending the lifespan. And to me, it really doesn't make sense to change the way in which the Fedora Project treats a release just because a different set of folks are touching it. You can though think it does make sense to change the handling because it is EOL, independent of who is touching it. EOL means end of development which means end of upgrades, at least to some. One question is what size of upgrades are you talking about. There's a big difference in going from kernel 2.4.12 to 2.4.13 versus going from 2.4.12 to 2.6.10 (just made up version numbers, but you get the idea). Same with going from apache 1.x.5 to 1.x.6 versus going from apache 1.x.5 to apache 2.x.y. If the upgrade doesn't require other non-trivial upgrades, doesn't require too many other upgrades, doesn't require manual reconfiguration, doesn't break the command line API, doesn't break the system, then I don't have a problem with an upgrade. If the upgrade does any of the above, then I have a problem. I'm trying to establish a scenario where the Fedora Project as a whole has a certain lifespan for a Fedora (core+extras) release. An end user really shouldn't care how the updates are generated, just that they are published and announced in the same spaces, and that the content of said updates. As long as they don't break more than they fix... -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -- 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: Fedora products, to upgrade rather than backport?
Quoting Michal Jaegermann [EMAIL PROTECTED]: On Mon, May 15, 2006 at 02:29:03PM -0500, Eric Rostetter wrote: Depends on what transparent means. If you want to be transparent in the sense of not breaking people's working machines, then no, you should backport. When people intimately familiar with a given code, because they authored it, do not even attempt to provide security patches for older versions as internals were completely re-written and it is not even clear how to patch old holes, you expect that a small group of volunteers will do a deep analysis and come quickly with correct and safe patches for whatever? Such request is not even funny. FL already has a policy, and it applies to RHL as well as FL. If the code can't reasonable be backported, we upgrade. End of discussion. In case you wonder the above was exactly the case with relatively recent updates to sendmail and is normally the case with mozilla (try to peek into that code and you will see why). Yea, and postgresql, etc. But this isn't the issue at hand. What is more such leaf applications, as opposed to deeply intertwined libraries, are not a real problem - packaging hiccups notwithstanding. They can be, like in the case of postgresql which requires you dump your DB, upgrade, restore the DB, or else you are SOL. And we already know how many people just set yum to do automatic updates and would be burned in such a case. Think about all the problems we would have if we upgraded from PHP 4.x to PHP 5.x. Man, that would be a nightmare for the users... Michal -- 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: Fedora products, to upgrade rather than backport?
Quoting Michal Jaegermann [EMAIL PROTECTED]: I never tried to imply that automatic version chase is a good thing, and is definitely bad in case of libraries, but there are situations when you simply do not have a choice. Avoiding security updates because you do not want to change versions is in general not an option. Exactly what I'm am saying. Now we just need consensus on what situations call for which method. To me, the existing methods are fine. Jesse raised the question of should we change it. I answered him honestly and simply. Then I replied to a bunch of other post, in which I took an extreme position to the conservative side, for no other reason than to counter the many extreme positions to the liberal. Kind of Devil's Advocate if you will. I also think that for systems where you really want a long-term stable software base you should use nowadays distros like RHEL, or clones like CentOS, and for other pushing them far beyond EOL quickly becomes more trouble then it is worth. Then why not just end the FL project? But seriously, it isn't just pushing them far beyond EOL. It is pushing them just slightly beyond EOL in many cases. I don't care if FC3 is pushed for more than 6 months. I just want some time to schedule an upgrade, not an indefinate lifetime. Michal -- 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: sendmail update left me in a fix
Just to point out some potential issues (depending on upgrade paths, etc). Some old sendmail configurations kept files in /etc/ while newer configurations keep these files in /etc/mail/ instead. A similar problem might exist for some files moved from /etc/ or /etc/mail/ to /var/run et al. These changes might cause problems? Some people might have files linked or copied in multiple places because of these changes (thinking they were providing backwards compatibility or such) and this could really cause problems. In addition, the upgrade might have moved the base mc files on old systems which would cause the sendmail.mc file not to compile. If something does a blind update of sendmail.cf from sendmail.mc without checking for errors, it could produce a broken sendmail.cf file. I've not seen any of these problems with the latest sendmail package (but I've also not tested it much) but I did see some of these issues with the first sendmail update... IMHO, almost all the problems were caused by the first package, not the second package. The problem is everyone rushed to install the first package, and the if so, the second package can't undo all the problems the first one created... -- 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: sendmail update left me in a fix
Quoting Parker Jones [EMAIL PROTECTED]: Problem: Sending mail failed after the update. I send locally using nmh. Restarting sendmail didn't help. Receiving appeared to be unaffected. Quick fix: After waiting several days hoping the problem would just go away, I had to do something about it. I appear to have made the problem go away by replacing sendmail.cf with its old version (prior to the sendmail update) and restarting sendmail. Looking for an explanation: I tried to reproduce the problem by restoring the sendmail.cf supplied with the update and restarting sendmail. Surprisingly I could still send - I expected it to break. This would suggest that there is something else going on that I'm not taking into consideration (rebuilding of sendmail.mc perhaps?) So I still have no satisfactory explanation of the cause of the problem. Could it perhaps be the /etc/mail/submit.cf file that was the problem? I'm not sure how nmh submits the mail (via local sendmail invocation, or via port 25, or via port 587, etc. Each could have its own problems (missing symlink, bad .cf files, etc). If sendmail.mc is compiled will the problem reappear? Try it and find out (but I doubt it). -- 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: sendmail update left me in a fix
Quoting Parker Jones [EMAIL PROTECTED]: The 5th April sendmail update screwed up mail on my RH-7.3 box. How so? It is probably due to your having installed the earlier update actually, and not due to the current update. But in any case, if something is broken it is broken. But you never do say what it is that is broken. In /var/log/maillog I'm getting lots of these: Apr 7 01:28:17 stancomb sendmail[6702]: k36NSHhs006702: localhost [127.0.0.1] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA That message doesn't mean much of anything by itself. In fact, I see lots of these in normal operation. Now, something is no doubt causing them, but we can't tell what without more information from you. Not knowing anything about sendmail configuration this has left me in a fix. Sounds like you already got yourself out of the fix actually. But then, you never really told us what was broken. Out of urgency I reverted sendmail.cf to a version prior to the update and it now seems to work ok. That should be fine and should not cause any problems. A diff between the old and new sendmail.cf's shows several pages of changes which I can't even begin to understand. I am not sure of the implications of using the old sendmail.cf... It should work fine with the old sendmail.cf. But you should check the status of sendmail.mc also, to prevent problems in the future in case it rebuilds sendmail.cf from sendmail.mc. I appreciate the effort you guys put into packaging this code, but it's a royal pain when new problems like this are introduced. Yes. But if you want any help, you need to provide much more information, like at least what the problems where, and whether we should even bother to try to help as it sounds like you already fixed all the problems? -- 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: sendmail updates
Quoting Jancio Wodnik [EMAIL PROTECTED]: When i remember, there was an update of sendmail in march, wait, i will grep that for you: 25 of march my system was update with sendmail-8.12.11-4.22.9.legacy and then was problem with AUTH - mail from local lan were rejected, so i greep mailing list, irc and i made: alternatives --configure mta so (when i can well remember) this command rebuild all broken symlink, in /etc/pam.d too. After that, there cam another update of sendmail, sendmail-8.12.11-4.22.10.legacy which broke again AUTH, i fix that by making necessery symbolic links by hand, i make that quickly, alternatives --config mail didn't make necessry symlinks (wired ?). Yeah, I think that all is expected behaviour for that upgrade path. Unfortunately such was not stated in the update release, and wasn't stated on the mailing list until later (in response to your mail). Saddly, but all these boxes are production servers, so i have no time to do further investigation. Understood. Sory, but i can't experiment for that, it is production box and we are planning to move to CentOS. Yes, if it is working, there is no reason to do anything. How to apply ? By yum night updates ! I would never (personally) apply automatic updates to a production server... See http://www.fedoraproject.org/wiki/AutoUpdates for full details... I'm tired, so i close this case for me and will not do further investigation. Sorry. No problem. I think the long post by David E. about the 4 upgrade paths and what happens in each path documents the path well enough for now. And since any new updates will probably skip the intermediate package, this shouldn't be a problem for anyone in the future (I hope). -- 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: sendmail updates
Quoting Jancio Wodnik [EMAIL PROTECTED]: Hi. but above statement is not true. There are still problem with alternatives on rh7.3 and rh9 when updated to latest sendmail update. Lates update didn't fix that. Sorry, but there is still some work to do. Regrads, Irens. Then you best report what those issues are, and how to reproduce 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: sendmail updates
Quoting Jancio Wodnik [EMAIL PROTECTED]: I have got latest sendmail's update on my rh73 and rh9 boxes. Issues are still the same: after update there is lack of those files: After update from which version? Were any manual changes made those files on the machine before the latest install? Did you install or upgrade the package? 1) there is no more /etc/pam.d/smtp.sendmail - but thereis /etc/pam.d/smtp.rpmnew 2) there is no more /usr/lib/sendmail.sendmail See the excellent post by David E. and see which category you fit in, and whether or not his explainations there explain your problems or not. In /etc/alternatives were broken links: mta-pam, mta-sendmail, mta-sendmailman I can confirm if you did both updates in order you have broken links on RH9, but interesting my broken links are different from what you report. My sendmail rejects incoming mail form LAN, so i must by hand fix above broken symlinks, after that and sendmail reload all goes fine. If you remove sendmail and reinstall the latest package (you should certainly backup /etc/mail before doing this) does it resolve all the problems you see? So there are still problems with the latest update, when we spoke about: problems with alternatives and sendmail. In my opinion: the latest update didn't fix that. That's all. We need more info on what you did before we can conclude that. I think the biggest problem/complaint would be that the fine details about how to apply the newest package based on previous updates was missing. It should have made mention of what would happen in the 4 different cases. best reg ... Irens -- 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: New sendmail and missing /usr/lib/sendmail
Quoting Mike McCarty [EMAIL PROTECTED]: I think that everybody should send Jesse big thanks for preparing I'll second that, as well. Mike Depsite any differences I have with the Fedora Legacy Project, I very much appreciate all that Jesse has done for the project. Without him there wouldn't be a FL Project. And I know he works very hard on the project, and spends a lot of time on the project, and at least until very recently when he joined Red Hat all he got for it was a bunch of hassles. So, thanks Jesse! I _do_ appreciate all you put into the project. -- 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: Hi all
Quoting S Theyagarajan [EMAIL PROTECTED]: Hi people, iam S.Theyagarajan, a sophomore at National Institute Of technology trichy India. Iam glad to join in here. and i have been in to many opensource projects. and i just found there are some vacancies. I love writing technical documentations and security management. I would be glad if i am given an opportunity to contribute . We can use help with documentation. But you may also want to check out the Fedor Documentation Project (http://fedora.redhat.com/projects/docs/) if you want to do more... Thanks Taggy -- 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: New sendmail and missing /usr/lib/sendmail
Quoting Marc Deslauriers [EMAIL PROTECTED]: Curiously, sendmail actually DID get test votes for all platforms before it got moved to official updates. No part of the QA process was hastened. True, for the _current_ QA process. But not for the original QA process. The main problem I've had is that I've not had the required 4 days between the updates-testing e-mail notice and the released to updates e-mail notice. I don't know if this is because they are being released early, or because the mailing list was slow... This has happened before. Most packages that got pushed out that had serious problems had been through QA and had people test them. One of the php updates is an example I know of. Yes, but they often have only a few people testing them, with only one vote per OS version... Not much QA really... Marc. -- 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: sendmail upgrade issues
Quoting Marc Deslauriers [EMAIL PROTECTED]: On Sun, 2006-03-26 at 01:38 -0600, Eric Rostetter wrote: This is fixed in the package awaiting QA. I never received an email about any such package... I didn't know I had to send you one. :) I guess it is confusing to say awaiting QA since we have two forms of QA. I kind of assumed you meant it was in updates-testing, in which case there is usually an e-mail sent out. I guess you mean it is in step one though, were no e-mail is sent out... Look here: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=186277 Marc. -- 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: sendmail upgrade issues
Quoting Marc Deslauriers [EMAIL PROTECTED]: On Sun, 2006-03-26 at 01:44 -0600, Eric Rostetter wrote: Quoting Eric Rostetter [EMAIL PROTECTED]: So you have another rh9 machine that still has an old sendmail package on it? I think I might have one for immediate access. I might also have another one but I won't have access to it until probably Wednesday. Do you think you could do a rpm -Uvvv so we could get the output. If it goes wrong, we'll have something to look at. Marc. Well, sorry, I messed it up. I did: rpm -Fhvvv sendmail*.rpm | tee /tmp/sendmail.log Which gave me almost nothing... I should have done: rpm -Fhvvv sendmail*.rpm 21 | tee /tmp/sendmail.log instead. My scrollback buffer isn't big enough to catch the output completely. Later, I'll see if I can't reverse the changes and try again, but that won't be for a while... BTW, do you want me to do this with the released update or with the one proposed for QA? -- 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: New sendmail and missing /usr/lib/sendmail
Quoting Michal Jaegermann [EMAIL PROTECTED]:
On Sat, Mar 25, 2006 at 10:24:12AM -0500, David Eisner wrote:
Eric Rostetter wrote:
This sounds like what happens when we rush the QA processes...
Other distros had advance warning about this vulnerability, and hence
more time to apply patches and do testing.
Personally I _hugely_ prefer fixed packages with minor packaging
imperfections, which BTW can be trivially fixed by whomever is
installing them by adding a link or two, then waiting for something
which installs without a hitch and have a mail server owned in the
meantime. Headaches in both cases do not even start to compare.
Then you should install from updates-testing for your machines to
accomplish that.
Not everyone runing linux knows how to create the proper links, or
perhaps even how to create a symlink at all.
It actually amazes me that no one has suggested runing the proper
alternatives command to fix this, and no one has researched if
that fixes the problem, rather than suggesting that we manually
create the links.
I think that everybody should send Jesse big thanks for preparing
new packages on such short notice.
He didn't rush them, at his decision. So if anything you would ask
why he didn't rush them, as he considered it not to be an important
vulnerability. Why do I say this? Because that is what Jesse says
in bugzilla about it.
New-and-improved, which create
all needed links automatically on an installation, can be issued
later.
That doesn't help those who had their mail disabled for hours or days
in the meantime.
Of course it would help if people experiencing problems
would try to identify what went wrong (older 'alternatives' do not
work like they should?, some typos in %post scripts?, something
else?). Again, look at what 'rpm -q --scripts sendmail' reports
and check is something is amiss there, as the first step, if you
have seen troubles.
I've looked into it, and can't find any reason for the missing symlinks.
In fact, I've not had a system with missing symlinks yet. But, I did
have some systems that lost their custom sendmail.{mc,cf} files, which
is rather unrelated to the symlink issue.
Michal
--
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: New sendmail and missing /usr/lib/sendmail
Quoting Jesse Keating [EMAIL PROTECTED]:
I had verified votes for all the platforms.
True.
I also had LOTS of people
asking when a release would come out, again and again.
Should not be relevent, especially if there is one in updates-testing.
Unfortunately
sendmail is one of those really crappy packages that does a ton of stuff
in spec and deals w/ alternatives and gets used in so many different
ways that it is hard to test every corner case.
Very hard with only 4-5 people testing it. Yes.
Admittedly the missing
symlinks is a pretty glaring issue, but rpmdiff wouldn't find it as the
links aren't provided by the package, nor does it prevent normal mail
delivery, just things that look in /usr/lib/ for sendmail.
I've had issues with it moving my sendmail.mc to sendmail.mc.rpmsave
and either replacing it with a new sendmail.mc or leaving me with no
sendmail.mc at all. In either case, unless I catch this and fix it,
my mail _does not_ get delivered normally.
Then of course reverting to the old sendmail.mc causes warnings (if
the old versions still had AUTO_REBUILD enabled, or I added FEATURE
lines after the MAILER lines, etc). So I had to fix these to make it
work.
I _think_ there may have been similar problems with sendmail.cf, but
I can't be sure since I just got in the habit of rebuilding it from
sendmail.mc after the upgrade, due to the above issues.
I found several systems where sendmail was _not_ running after the upgrade.
I simply made sure the configs were okay (and rebuilt if not) and
started sendmail in those cases, without issue, but...
By the way, I never saw any of the symlink issues myself for some reason.
But I did have sendmail.{mc/cf} issues, and failures to run after the
upgrade...
--
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: New sendmail and missing /usr/lib/sendmail
Quoting Michael Kratz [EMAIL PROTECTED]: I just (yum) updated sendmail on a Redhat 7.3 box, and the RPM overwrote my sendmail.cf file and didn't create a .rpmnew or .rpmsave! Lucky I still had my custom .mc file and it didn't overwrite that. Can you tell what was different between the old .cf and the new one? I can see it tries to update the sendmail.cf to comment out any references to AutoRebuildAliases. This update might look more sinister than it is, or might even be more sinister than it means to be (e.g. if you run a non-standard configuration). In any case, it deletes the original without saving it... I can see where this could hose your configuration in very rare edge cases (like running out of disk space on the device while writing a file, etc). -- Michael -- 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: X-Chat 2.4.0 to 2.6
Quoting Danny Terweij - Net Tuning | Net [EMAIL PROTECTED]: Isn't that what FC4 is supposed to be? Where it ends? FC is not a good choice for production. Then don't use it. There are lots of other choices. Linux is stable, linux dont have to reboot much. Linux can run for years without a reboot. And it is that way exactly because we don't keep upgrading it to the lastest and greatest version of everything all the time. If you want the latest and greatest, you lose the stability. I do not want to upgrade my production machines every 6 months because FC has a new version. Yet you do want to upgrade your applications every 6 months? What's the difference? Those new versions holds new versions of software. Why cant they build one FC and update/upgrade just the installed versions? Because that isn't the mission of FC. That is the mission of RHEL et al. If that is what you want, then you are using the wrong OS. I suggest to rename the current legacy-updates to legacy-security or something like that. The project is Fedora Legacy. That names implies that we deal in legacy OS and legacy packages. Our updates then become legacy updates. Not much way around that. While your proposal isn't bad, it is a bit late in the ball game to make the change now I think. legacy-updates sounds like just updates of new versions to me like the normal repo's also is doing rather then security shit.. Yes, but if you look at more than the yum/apt channel name, like the project's web site or docs, you shouldn't be too confused. It's just a matter of the yum/apt channel names being terse that is the problem here. This has been gone over many times, here. I suggest you actually go and read the mission statement. You think every user reading that? You mention production machines and OS and uses above. I sure hope that any serious production admin would do so. No, I don't expect all home users or the like to do so. But surely if you run a production system in the traditional sense than you would read enough to know what you were using. But actualy it are not updates, but fixes/patches. Fixes/patches are updates. You're confusing symantics here. We _are_ updating your machine. We _are_ updating your software. We _are_ providing updates. What we are not doing is providing new versions of software when there are no known problems with the older versions. Note that we actually do, in some rare cases, provide newer versions of software packages. But we only do so if there is a need to, to fix a serious bug, or make support easier, or fix a security issue that can only be addressed that way. -After some time, he finds out that newer versions are not delivered. Yes, he finds that he is running legacy software. That is why he needs legacy support. That is why we provide legacy updates. -Finds alternate repos like atrpms dag dries livna etc... If he wants newer software, then yes, he should indeed find such sites. -doing yum update, oh look again new versions :) And now, realize that your stable system is potentially much less stable. This is a real example how most of the linux users are doing without read any statement text. Because its not intresting to read :) And this is fine for a home user, or my personal desktop machine at work. But it is not how I would run my company or institution mail server or web server or payroll system and so on. In other words, what you say is all fine and dandy, if applied to the correct situation. :) Danny -- 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: Rebuild exisitng errata for x86_64?
Quoting Jesse Keating [EMAIL PROTECTED]: packages, but the question remains, do we want to rebuild all previously released errata for x86_64, for releases that have x86_64 (FC1,2,3). Yes, if possible, but this is something to be done in the background, at lower priority, as time permits. In any case, I think we should _at least_ release all FC3 packages for x86_64. In other words, we shouldn't release new FC3 x86_64 without releasing also the older FC3 x86_64, for consistency. This could be a lot of work, and I'm concerned about the difference in build systems. Releasing x86_64 versions of packages built with a different build system than that which produced the i386 versions just doesn't sit well with me. Then again, neither does rebuilding EVERY errata on the new build system and re-releasing all the packages. Understandable. I'll let you and others who know more about this decide. That is why I said yes, if possible above rather than yes. So I guess the bottom line question is, is there a significant amount of users in the community that need these older FC's updates built for x86_64, would be willing to do some basic QA on them, and would be willing to accept packages built on a different build system? I am only interested in FC3 myself... Sorry. Or should we just continue from this point forward with just FC3+ supporting x86_64? (and set policy for if/when we get support for ppc packages) I'll let those who know more about the build system issues decide. I welcome your input. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -- 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: FC3 yum instructions
Quoting Jesse Keating [EMAIL PROTECTED]: On Tue, 2006-02-21 at 21:49 -0600, Eric Rostetter wrote: Fedora itself does not do it this way. I'd rather we didn't either. I do recognize that the other Fedora Community Projects do, but I don't consider us to be the same level as most of them. We're considering doing away with the fedora.redhat.com website. 1) It ties Fedora uneccessarily to Red Hat, 2) it takes a lot of effort to change something there. This has not that much to do with web vs wiki. It is really just a management or hosting issue. You can change the DNS and #1 goes away. You can change how things are updated and #2 goes away. Neither in anyway means one should use wiki over traditional web. With the new content management stuff going online for fedoraproject.org we may see fedora.redhat.com become just a link to this. Still being discussed AFAIK. If the goal is to move all projects fully to the fedoralegacy.org wiki, then fine. But no one has told me yet that such a goal exists. I'm working on getting us to the level that Extras is. I'm not really familiar with Extras, so that doesn't help me much. My impression from others talking about it is that they are not at a very high level, but that impression could be totally incorrect as it is based on second hand reports only. 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? That all sounds good. But that really isn't what I meant when I was talking about levels. Personally I don't find the wiki to inspire professionalism or confidence in the projects, and if you are expecting to draw users to _use_ your packages you want to project professionalism and give a sense of confidence. Now, maybe if you want to draw people into _contribute_ a wiki might help by making it a bit easier for (mostly minor) contributions. But it also makes it harder to maintain the integrity of the site. There are trade offs both ways... I guess the question is what is the goal here. Is it: 1) To consolidate all the projects in one place? 2) To make it easier to use/contribute/maintain? 3) To attract new people to the project? 4) To change for the sake of change? 5) Some other reason or reasons? -- 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: FC3 yum instructions
Quoting Pekka Savola [EMAIL PROTECTED]: 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. But what about web vs. wiki? Should we move to Fedora wiki, or stay as a more traditional web site, or some of each? Fedora Extras is at one end, Fedora Documentation Project is in the middle, we were at one end but are moving towards the other, etc. Where should the FL web be moving; towards wiki or towards web or towards a split between them? -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -- 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: FC3 yum instructions
Quoting Jesse Keating [EMAIL PROTECTED]: On Wed, 2006-02-22 at 10:21 -0600, Eric Rostetter wrote: 1) To consolidate all the projects in one place? Yes, Okay, then I guess we should scrape the web site asap and just use the wiki instead for everything. 5) Some other reason or reasons? To further make our selves seem as a project of the same level as the Extras or Documentation project, by existing in the same spaces that they do. I personally think we are lowering ourselves to their level, but so be it. Not my call. -- 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: FC3 yum instructions
Quoting seth vidal [EMAIL PROTECTED]: 5) Some other reason or reasons? To further make our selves seem as a project of the same level as the Extras or Documentation project, by existing in the same spaces that they do. I personally think we are lowering ourselves to their level, but so be it. Not my call. 'lowering ourselves' You might need a reality check if you think that legacy is 'lowering itself' to the level of extras. -sv Only in the sense of web site presence and presentation, not in the sense of community involvement, output/productivity, or many other areas where it clearly outshines FL. But then, our web presence has never been good anyway, since no one will participate in the process. I proposed an updated overview years ago, and have received basically no feedback of any sort, and no go-ahead to implement it, and any attempt to get it approved has failed. So if this community can't even be bothered to look at and approve or reject a document that is supposed to describe its existance and purpose, I guess it isn't much of a project. Maybe the nay-sayers are right. Maybe the project is crap, and we're all just wasting our time on it. Certainly is the least satisfying project I've ever been involved with. -- 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: FC3 yum instructions
Quoting Jesse Keating [EMAIL PROTECTED]: I agree. Extras has far surpassed us in quantity, quality, participation by the community, integration within Fedora itself, community exposure, etc, etc, etc We are very much trying to play catchup. Yes, but I was talking only in web presence... -- 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
FC3 yum instructions
I've added the following to the web site: http://www.fedoralegacy.org/docs/yum-fc3.php and would appreciate testing, feedback, etc. Thanks! -- 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: FC3 yum instructions
Quoting Jesse Keating [EMAIL PROTECTED]: We need to get this echoed to the wiki much like http://fedoraproject.org/wiki/Legacy/YumFC2Detailed Why do we have it in two places? That just leads to confusions and things being out of sync. Just make a new page named YumFC3Detailed and then link to it from the main http://fedoraproject.org/wiki/Legacy page. Why? To me it seems we should have either one or the other, not both. -- 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: FC3 yum instructions
Quoting Jesse Keating [EMAIL PROTECTED]: On Tue, 2006-02-21 at 14:50 -0600, Eric Rostetter wrote: Why do we have it in two places? That just leads to confusions and things being out of sync. Just make a new page named YumFC3Detailed and then link to it from the main http://fedoraproject.org/wiki/Legacy page. Why? To me it seems we should have either one or the other, not both. Honestly because I'd like to start moving all documentation into the wiki. Okay. I'm against this personally, but I know you want to do it. This is where the rest of the Fedora projects have their documentation. The need for our own webspace may go away in the future. Fedora itself does not do it this way. I'd rather we didn't either. I do recognize that the other Fedora Community Projects do, but I don't consider us to be the same level as most of them. I suppose you could compare us with the Fedora Documentation Project 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... Especially as we move toward using the same build software that Fedora Extras uses, we can use a lot of their documentation for our needs. Yes. But why not point to their content from our web page? No need to be a wiki to share content... Having all these things in the same space (the wiki) makes sense moving forward. I don't see it, but I won't stop you from doing that. My point is, if we want these things in the wiki, then we shouldn't have them in the web also. We should remove them from the web, and only have them in the wiki, and not duplicate them in both. I'll let the rest of the list comment, if they want. I've already told Jesse privately how I feel about the issue. -- 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: Comments on first verification QA
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. -- 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: no mandatory QA testing at all [Re: crazy thought about how to ease QA testing]
Quoting Benjamin Smith [EMAIL PROTECTED]: I'd rather err on the side of security. -Ben Then you would insist on a real QA test suite, one that also tested the security of the test. You would be against pushing untested updates. I think you would rather err on the side of timelyness rather than security... What we're proposing basically is a system in which someone can purposefully place a trojan horse or backdoor on all Fedora Legacy systems without any one checking for it ahead of time. You call that security? Putting all your eggs in your trust in one person rather than multiple people? That isn't security... I'm staying out of the argument for or against this proposal, as my fews should be well known from the last dozen times this has come up, and I'm tired of fighting for this. I can always just upgrade my machines to Centos should Fedora Legacy lose its security. -- 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: no mandatory QA testing at all [Re: crazy thought about how to ease QA testing]
Quoting James Kosin [EMAIL PROTECTED]: Jesse Keating wrote: If I'm not mistaken, the timeout period starts when there is a package for updates testing. 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. We can't get to the updates testing package phase w/out somebody doing the first level QA which includes making sure the patch uses is a known good patch from at least some other vendor. So I don't think this is true in theory; the patch need not come from some other vendor, or even upstream, in theory, though it perhaps always has in practice. Plus, the upstream patch is often modified, so there is always the chance for foul-play. the plot to root all Legacy systems is going to have to start further up the food chain. I don't think so. And in any case, I was refering to the suggestion on this list that we don't do QA to move to updates-testing, which would by-pass this whole issue you try to bring up. Maybe, its time I started witting something! A document on the whole process for everyone to review and agree upon... unless something like this already exists... which I've never seen. It's been done and re-done so many times it makes my head spin. Thanks, James Kosin -- 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: no mandatory QA testing at all [Re: crazy thought about how to ease QA testing]
Quoting Pekka Savola [EMAIL PROTECTED]: 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). There may have been little talk, but there was talk. And no one has said no to it until I brought it up here. The current policy change proposal was about reducing the amount of QA for moving updates-testing packages to updates. Actually, IIRC, it simply reduces the time to push it through... So, I'm not sure why we're having this conversation.. Because it was proposed, and until I started the conversation, neither you, Jesse, I, or anyone else has denounced it or retracted it. Now that Jesse and I have denounced it, and you have said you are not pushing it, the conversation can probably be terminated and forgotten. -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -- 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: no mandatory QA testing at all [Re: crazy thought about how to ease QA testing]
Quoting Jesse Keating [EMAIL PROTECTED]: On Wed, 2006-02-15 at 02:20 +0530, Rahul Sundaram wrote: Seems to be a misunderstanding here. There are separate repositories for testing and general legacy updates. Yes? He is speaking in virtual terms. Since we would introduce a timeout, he is afraid that the quality of packages coming into released will be lower than it is right now, and be considered testing packages. IMHO the quality of packages hitting updates-testing is pretty on par with the quality of packages hitting Fedora updates. So I'm not so sure what the problem is here. The problem is two fold: 1) You can't use Fedora standards for the RHL releases, only for the Fedora releases. 2) This is a major change to the tenents that FL was founded on. Any such change must be by consensus. We must establish if there is a consensus or not. -- 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: no mandatory QA testing at all [Re: crazy thought about how to ease QA testing]
Quoting Jesse Keating [EMAIL PROTECTED]: On Tue, 2006-02-14 at 22:34 +0200, Pekka Savola wrote: 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.. It is just a case of misunderstanding. Generic terms regarding QA can muddy the waters between updates-testing QA (phase 2?) and package source QA (phase 1?). NO! A proposal was made to effectively remove any need for QA by accepting packages without any QA. There is no misunderstanding. This was proposed on the list. Until just a few minutes ago, no one said it was dead, so it was still a valid point of conversation. Now it is dead, and can RIP. But it was not a misunderstanding, it was a real proposal made to the list. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -- 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: no mandatory QA testing at all [Re: crazy thought about how to ease QA testing]
Quoting Mike McCarty [EMAIL PROTECTED]: Then the Legacy Project has removed my ability not to subscribe to testing. No, the Legacy Project has _proposed_ to that, at least in your opinion. It was followed by something like unless we get a lot of objection so please, if you object, let it be known. Since Legacy is no longer in my yum configuration, it's no longer an issue for me, good or bad. Yes, we lose a few people from the community every time this issue comes up. I guess the hope is we will gain more if we release more, but I'm not sure it is true (hasn't been so far, as far as I can tell). I don't wish to subscribe to testing. Since testing and release have been merged, I have unsubscribed from release. No, it was proposed that we merge them, but it is still under consideration, and can still be blocked. Your action is a bit premature. But then, considering some of the responses you have received in e-mail (like having to pay to be notified) I don't blame you too much. If the security notices on FC2 get severe enough, I'll just move on to CentOs, Scientific Linux, or Debian. Since I'm already helping administer a Debian box, it might make sense to move to that. Of course your choice... Mike -- 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: no mandatory QA testing at all [Re: crazy thought about how to ease QA testing]
Quoting Jesse Keating [EMAIL PROTECTED]: Our hope is that if this proposal scares some people, it will scare them into finding ways to help out the project so that little to no packages escape updates-testing w/out some QA done on it. My fear is that we spend more time arguing about these than we do testing. As I've said the last 3-4 times this came up; if each of us spent as much time QA testing packages as we do arguing about the QA processing on the mailing list, we wouldn't have any problem at all. I know these threads stop me from doing any QA while they are going on. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -- 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: no mandatory QA testing at all [Re: crazy thought about how to ease QA testing]
Quoting Jesse Keating [EMAIL PROTECTED]: On Tue, 2006-02-14 at 15:45 -0600, Eric Rostetter wrote: The problem is two fold: 1) You can't use Fedora standards for the RHL releases, only for the Fedora releases. You are correct. However Fedora Legacy originally was just for Fedora. It was my choice and the choice of other users to extend the Legacy project to the RHL releases. To be perfectly honest, I'm not all that interested in maintaining these RHL releases, but the community seems to be for now. This is not the impression the project gives off in any way other than its name. 2) This is a major change to the tenents that FL was founded on. Any such change must be by consensus. We must establish if there is a consensus or not. Correct. We have some of that, although with some misunderstanding on many sides (; Honestly I haven't seen enough naysayers yet to discard this shortened timeout policy. Nor have I seen enough people in favor of it to counter those against it. In other words, we have very few stating anything at all. -- 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: Self Introduction
Quoting Kwan Lowe [EMAIL PROTECTED]: 1. Name: Kwan Lowe Welcome! 5. Goals: QA for FC1 Cool, we need that! 6. Qualifications: I've not worked on any open projects of note, though I have done so professionally at other software companies. My strengths are in systems administration, scripting and documentation. I currently maintain the TLDP Kernel Rebuild Guide and am familiar with the RPM build process. Could use help with documentation if you'd like to help... Just let me (or the list) know. Thanks for the introduction! -- 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: Self Introduction #2: Donald Maner
Quoting Donald Maner [EMAIL PROTECTED]: Hello, everyone. This is my second introduction. I lost my previous key, and the job has been preventing me from participating after my first initial attempt. I'd like to start again, espically since I have access to a nice beefy VMware ESX server. Welcome back! We'd appecriate any QA you can do to help out. 2. Location: McKinney, Texas, USA If you're ever in the Austin area feel free to look me 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: x86_64 support
Quoting Pekka Savola [EMAIL PROTECTED]: 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. My understanding is it _will_ be added, as soon as the build system supports it. 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, ..)? For 1) I don't care. For 2) Definately. 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. And not supporting what is sure to be a huge user base of 64-bit users will only drain the project of volunteers even more. I have access to 1 and only one FC machine. It is FC3 and it is x64. I've been waiting until we take over FC3 x64 so I can help. If we don't take that over, then I will not help with FC releases. 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. That is why I'm okay with not supporting the older FC releases in x64. But the new ones, I say we should do it. 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? Yes, for future releases. -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -- 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: issues list(s)
Quoting Pekka Savola [EMAIL PROTECTED]: (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.) Why is that? Would something like a script that would do the following be useful: * generate a GPG key for them if they didn't already have one * register their GPG key on pgp.mit.edu if not already there * If both of the above were done, then prompt them for the info for the self-introduction e-mail and generate the self-intro they need to send to the mailing list 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? Or an interactive script which does the same, ignoring any that were installed less than some-yet-to-be-decided-time-interval-in-the-past, and generates the needed output to be mailed or submitted to bugzilla? 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. We would either need a volunteer who would move the mailing list posting into the bugzilla for such messages, or it would have to go to the bugzilla instead of the list. To go to the bugzilla, we need to find a way to automate the finding of the bug number for the update, no? Also, this still has to be GPG signed, so we should do that here as well. That would go a long way in checking that updates-testing packages have been used and found working, instead of just having been installed. Agreed, but I think we're still missing some steps. -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -- 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: Auto-reporting of successful testing packages
Quoting Benjamin Smith [EMAIL PROTECTED]: Attached is a PHP script that, when run at the command line, returns a list of testing packages currently installed. I just looked at your script now. In it, it says: yum list installed puts a number and a colon at the beginning of the version info. I don't know what it's for, but it makes the packages fail pattern matching, so it's gotta go. That number and colon is the Epoch number of the RPM. Normally not used, but it shouldn't really be ignored in case it is used. I think the legacycheck.pl script is a better base to start with than yours (just my humble opinion), so there may be no need to modify your script, but I thought I'd let you know what those numbers mean as a matter of course... -- 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: FC3 and apt-get (apt-rpm)
Quoting David Eisenstein [EMAIL PROTECTED]: There is some sentiment for getting rid of apt-get for FC3 and newer distros, especially in terms of the proposed yum.conf RPM package being proposed prepared, legacy-yumconf-fc3.src.rpm, at https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=177966. I think this would be a Good Thing... This was discussed yesterday on IRC (irc.freenode.net channel #Fedora- Legacy). Wondering how the general legacy users feel about that? I for one agree. Will we continue supporting apt-get for the older distros? I think we will have to for the RHL releases. You could argue otherwise for FC releases, since most of them come with YUM by default. So I vote we keep yum and apt for RHL releases, and I'll defer for FC releases. By the way, I don't see directions on using apt-get for FC2 on the http://www.fedoralegacy.org/docs web-page, and I don't see directions for using yum for FC3 yet. Someone running those dists has to write them. I actually do have access to a FC3 system, so I can do the FC3 stuff. But I don't have any access to FC1 or FC2, so someone else should do those. Are we planning to update those docs? I Yes, but who will do it? Volunteers? -- 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: Need discussion, Re: Latest contrib perl
Quoting Jesse Keating [EMAIL PROTECTED]: My opinion on the matter is that if we already have some QA work done on a bug (like we do in this case) we shouldn't interrupt the process to add more fixes to the bug, unless other problems are found during the QA process. If no QA has been done then it is easy to add the new fix to the sources. This is only my opinion, I welcome others. I agree. I'm tired of doing QA and having it thrown out as more bug fixes are added, and then people complaining about the patches being so late to arrive... Once we have a sufficient amount of QA done, we should finish it and release it. New bugs that appear go into the next update of the package. Just my opionion though... -- 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: Fedora Updates testing
Quoting Benjamin Smith [EMAIL PROTECTED]: How many updates from FL have been rejected due to bugs or things not working? I updated my FC1 yum.conf to include testing, and I've not noticed anything unusual. (Wish I had the time to figure out how to test, let alone do the testing...) I don't know any numbers. But I can tell you if you are using the testing channel than you *are* testing, so you don't need to figure out how to test things, only how to report your test findings. Your needed steps now are: * Determine which test packages you have installed. * If needed, learn how to use gpg to make a clear signed message. * For each test package, create a message saying you tested it and found no problems. Then gpg clearsign that message, and copy/paste the result into the bugzilla entry for that bug. For information on determining which packages you have tested, ask this mailing list for help. For gpg help, see http://www.fedoraproject.org/wiki/Legacy/PGPHowTo For bugzilla help, see http://www.fedoralegacy.org/docs/bugzilla.php For any other questions about helping, ask this mailing list. For information on finding more time in your day, seek a spiritual guide or time management expert ;) -Ben -- Eric Rostetter -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Re: Upcoming transition of FC3
Quoting Jeff Sheltren [EMAIL PROTECTED]: Eric, in the case of our repo included with Fedora Core - this isn't happening with a package upgrade without the user's knowledge. It will be a separate 'fedora-legacy' package they need to install (I'm I thought it was just a change to the yum package or something. If it is a separate package, then I'm cool with it being enabled by default. In that case, I would have to install the package, so it wouldn't matter what the default it. (But, having said that, see below (end of message) for a counter argument.) If the change was an update to an existing package (update to yum, up2date, etc) then I would want it to be disabled by default. I admit I've not followed the argument blow-by-blow and I'm not sure exactly how it would be implemented. not sure if it will get installed by default on FC5, but I think that would be nice). I'm not too worried about that, as I always select packages to install manually. This is similar to how Fedora Extras has its repo enabled by default on all FC4 machines. It's just something that admins need to be aware of, if they don't like it, they can disable/ remove the repo. -Jeff Well, the Red Hat line since RHL 8 is install all services disabled rather than the line before that which was install all services enabled and doing so cut down almost completely on the number of worms being spread around the net for RHL machines. (Remember the worm outbreak with RHL 6 and 7 machines because all the services where enabled at installation?) I think that this is the correct philosophy, and I think it should extend to things like repositories. Just as if I install sendmail or apache they are disabled by default, I'd expect my repository to be disabled by default when I install it. Doing so would mean more consistency of installation behaviour IMHO. Your opinion may differ, and I respect that. -- Eric Rostetter -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Re: Upcoming transition of FC3
Quoting Jesse Keating [EMAIL PROTECTED]: On Mon, 2005-10-24 at 15:38 -0500, Eric Rostetter wrote: I thought it was just a change to the yum package or something. If it is a separate package, then I'm cool with it being enabled by default. In that case, I would have to install the package, so it wouldn't matter what the default it. (But, having said that, see below (end of message) for a counter argument.) Well, if it was included w/ Core, it would be most likely part of the same package that supplied the extras repo files and the core repo files. Given that things like Extras are enabled by default, we should enable ours as well, just not the updates-testing. I supppose to continue this argument further without knowing which package, or what kind of package, we would use, is rather pointless. WRT Red Hat Linux, this is indeed the correct philosophy. This is why our service is an opt-in rather than opt-out for RHL. However Fedora doesn't have exactly the same goals or philosophy that RHL did. For that reason, I think we should fall more inline with the feel and philosophy of Fedora when dealing w/ Fedora releases. I can see that to some extent. I can also see that the philosophy of Fedora is that it is dead when it is dead, and FL is not part of Fedora. So it is open to debate. And depends in part on how much the Fedora Project wants to officially recognize (endorse, etc) the Fedora Legacy Project. Anyway, as I said above, it is rather silly to argue about this until we decide how (in what package, etc) it is to be implemented. I don't think we can truely know what the best state (enabled or disabled) would be until we know what package we're talking about (a current package, a new package, etc). -- Jesse Keating RHCE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedoralegacy.org) GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub) -- Eric Rostetter -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Re: Upcoming transition of FC3
Quoting Jeff Sheltren [EMAIL PROTECTED]: Hi Eric, it will be different depending on if you are talking about fedora core 5 or FC5 and newer. For those like FC3, and FC4, we will provide our own package; for now I've named it legacy-yumconf. Those packages will not be incorporated into Fedora Core, they will need to be installed by the user of their own free will. I think that everyone is in agreement that for these packages the legacy base and updates repos should be enabled by default. I don't think everyone is in agreement that they should, but I think most people will allow them to be enabled by default, whether or not they think it is best or not. For FC5 and newer, the plan is to have a legacy.repo file included by default. I assume this would be included in the fedora-release RPM, which is what provides the other yum repo files, but that is up to the Fedora Steering Committee. I guess we can, and should, leave that up to the Fedora Steering Committee then. Basically you're saying it is their software, and hence they get to make the rules. -Jeff -- Eric Rostetter -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Re: releasing updates-testing packages without VERIFY votes
Quoting Pekka Savola [EMAIL PROTECTED]: I suggest changing the policy so that packages in updates-testing which haven't got any VERIFY votes could: First, let me say that it would take less time for the people invloved in these lets publish without QA discussions to just QA the packages than they are spending arguing if we should publish them without any QA. But, back to the current point of discussion... - after 2 weeks, marked with a timeout - after the timeout of 4 weeks [i.e., 6 weeks total] be officially published This goes against everything this group was founded on, and all Best Practices. However, it does seem to be popular with the few folks involved in these conversations. So, I'll approve of this, but only if ammended to include the following: After the 2 week period when it is marked with a timeout, a message MUST be posted to the [EMAIL PROTECTED] informing people that it is being marked for timeout, and making a plee for people to QA test it. In addition, if it is released without any QA, the bug ticket for the package MUST note that it was released without any QA. (And rp-pppoe and squid currently in updates-testing could be released immediately upon the acceptance of this policy.) I've just submitted QA for those for RHL 7.3 and RHL 9. Take those votes for what you will. 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)? I vote to just release them after a long timeout period. If there are any issues, we can quickly fix them afterwards. We most often use patches that came from upstream or from another distro anyway, so most of them have already gone through QA. I agree, with the above stipulation about announcing it to the mailing list and marking it as such in Bugzilla. -- Eric Rostetter The Department of Physics The University of Texas at Austin Why get even? Get odd! -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Re: issues list(s)
Quoting Pekka Savola [EMAIL PROTECTED]: I did update the whiteboard for VERIFYs. (Only the bug creator and specially privileged folks can edit these, unfortunately.) Thanks. 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. 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. 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. 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? -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -- Eric Rostetter -- 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
Quoting Pekka Savola [EMAIL PROTECTED]: On Fri, 23 Sep 2005, Mike McCarty wrote: If Legacy takes this move, then I predict mass exodus. If nothing happens, I predict mass exodus for the QA testers involved in the project. Wait... That has already happened. There are less than 5 people who do this stuff at least in semi-regular manner. There was no mass exodus, as there were never more than a handful of people anyway. Maybe folks writing on the list should consider how they could contribute to Fedora Legacy process so that we wouldn't NEED to have this discussion in the first place. Yes, like I said previously, we spend more time arguing about this than it would take to just do the QA in the first place. -- 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 -- Eric Rostetter -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
