[Secure-testing-team] Moving forward with the 2.4.27 and 2.6.8 kernels

Horms horms at debian.org
Tue Aug 16 06:31:22 UTC 2005


Hi,

Here is my proposal for the immediate future of 2.4.27 and 2.6.8. 
I'm pretty comforatble with the shape of both of them in SVN,
and its probably a good time to think about some releases -
security bugs keep coming in all the time, but I really think
we have to draw a line in the sand and make a release.

To get this ball rolling I plan to release kernel-source-2.4.27
2.4.27-11 and kernel-image-2.4.27-i386 2.4.27-11 into unstable tomorrow.
This is tagged in SVN, and I have made the packages available at
http://packages.vergenet.net/pending/ (i386 still building, will
be available soon). I will upload to unstable tomorrow if there
are no objections.  Other architecture maintainers, now would be a good
time to either kick of a build, of file a bug with the ftp maintainers
to have your arch's 2.4.27 kernel removed from Sid. This has already
been done for powerpc.

On the topic of Sid, I think we need to keep 2.4.27 there for now.
I've been told that the s390 installer works it, and its needed
for some m68k flavours (mac users who want a working keyboard IRRC).
In any case Christoph Hellwig pointed out that as long as its
just a matter of recompiling the sarge kernel, its not much of a bother.

So for now, the most up to date 2.4.27 is going to be in Sid, and sarge
updates can be cherry-picked from there. And as I mentioned above,
arches whose upstream has abandoned 2.4 (like powerpc) should be removed
from Sid.

2.6.8 will be removed from Sid shortly, so it might be appropriate
to use volatile to make new 2.6.8 kernels available. But I'd rather
just use volatile for 2.6.12, which seems more in the spirit of
volatile, and just make proposed-updates and proposed-secrity-updates
for 2.6.8. Anyone with input on what queues to use, please, lets
discuss that here.

Back to releases. After 2.4.27-11 is out, which should be very soon,
I would like to take what we have in SVN for both 2.6.8 and 2.4.27,
strip out all the non-security patches since Sarge (2.6.8-16 and
2.4.27-10) and make a security release. When I say strip out, I
mean comment out the changelog line and the patch entry in the
series file. Thats all. There doesn't seem any reason to hide
other changes that have been included in SVN. Nor any reason
not to include the patches in the release - even if they aren't applied.
In short, this should make producing a security release a simple matter
of reading the changelog, adding a dozen or so # characters,
tagging and building. 

Of course as many arches need to do builds as possible. And as I
mentioned above, I am a little unsure about what queue to use for
security updates. Which is why I am writing this message.

After all of that I'd like to look at getting some packages together
for a Sarge update (i.e. Sarge r1). Thats probably just a matter
of uploadin to the right queue. Though it would be nice to know
about what the planned timing for releasing r1 is, as it would
be nice to make sure a kernel came out a bit before the release.

-- 
Horms




More information about the Secure-testing-team mailing list