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
__________________________________________________