Jon Peatfield wrote: > RHSA-2006:0140-9 is listed as Important: kernel security update and was > released on the 19th. A similar one was released for the Vendor's 4 > RHSA-2006:0101-9 Important: kernel security update on the 17th (not that > I have any production SL4 systems yet so I don't care so much about that > myself). > > I've not seen any SL errata yet. Does this mean that there has been > some problem observed during testing or is it just a lack of people to > do the building or able/willing to test them? > > Is there anything I can offer to do to help at all? I'll be building my > own versions if there arn't official ones from SL (I don't have many > days on which I can apply updates which require reboots and don't want > to wait too long for these)... > > -- Jon That's a fair question. First, before I answer why, know that the kernel updates should be out today. At least for S.L. 4x, and hopefully for S.L. 3.0.x Why does it take so long? The actual compiling takes a couple of hours. But that's not the real stickler. There are two things that slow things up. Kernel testing, and kernel package dependancies. We usually don't just roll out a kernel like everything else. We usually install it, make sure it works, and also listen to the various mailling lists (RHEL, CentOS, Tau) to see if there is any immediate problems. In this case, there was a report of a very common network driver not working. We have tried many way's, but simply cannot reproduce the problem, and have concluded that the person who had the problem must have downloaded the driver straight from the vendor and then forgot about that. The other problem is package dependancies. It's nice that we have openafs and the GFS cluster suite. The problem is with the GFS cluster suite. They are always a few days (and in one case a week) behind the release of a kernel. They finally released it for this kernel right as I was starting to hand redo the packages. For this kernel, we've also been a bit over-utilized because we were just about to release S.L. Fermi 4.2. So, we do appreciate your offer to help. In this case it has just been a strange combination of things that has slowed things up. Troy -- __________________________________________________ Troy Dawson [log in to unmask] (630)840-6468 Fermilab ComputingDivision/CSS CSI Group __________________________________________________