Re: Sarge kernels and Volatile
On Mon, 01 Aug 2005 18:40:26 +0900, Horms wrote:
> On Mon, Aug 01, 2005 at 09:28:37AM +0200, Andreas Barth wrote:
>> * Horms (horms@debian.org) [050801 08:23]:
>> > I am wondering if others thing that volatile is a good
>> > place for us to make uploads of updated 2.6.8 and 2.4.27 kerels for
>> > Sarge? This would allow us to remove these kernels from unstable/testing
>> > and still provide maintenence releases for users.
>>
>> Well, my basic approach to that is that nobody of the volatile team can
>> really do security stuff (or otherwise debugging) for the kernels. So,
>> if the kernel team is able and willing to do that, we could go that way.
>> But anything that is in volatile needs to be security-supported till the
>> distribution is archived (and the security support won't be done by the
>> security-team).
>
> What I am really looking for is a way to allow the kernel-team (me?) to
> provide updates for sarge. Primarily security updates, but there are
> other important fixes too. The security team hasn't doene kernel updates
> for a long time now, I guess they are busy with other things. So I think
> it is valuable for the kernel team to provide updates.
>
>> Also, you might consider if the current approach to rebuild the kernels
>> is the best one (but that's of course up to you as long as you do the
>> work :).
>
> I am not sure what you are getting at there.
>
> The current build process is a mess. We are tying to sort that
> out with single-source, which is what you can see for 2.6.12.
> If we can get this working, and convince ourselves that
> moving sarge from 2.6.8 to 2.6.12 is possible, then yes, we
> should do that. But for now, I'm really looking for a way
> to do maintenance on 2.4.27 and 2.6.8.
>
> --
> Horms
I should probably point out this:
http://lists.debian.org/debian-release/2005/07/msg00083.html
Joey responded (privately) asking for an outline of the plan. My response
was:
"We will update 2.4.27 and 2.6.8 for various security fixes (and only
security fixes). The netfilter frag queue security fix requires an
ABINAME bump, so the kernel packages will all be renamed from (for
example) kernel-image-2.6.8-2-686 to kernel-image-2.6.8-3-686. They
will be uploaded to stable-proposed-updates. This will happen for
kernel-source-$VERSION, the various architecture kernel packages (ie,
kernel-image-2.6.8-i386), and kernel-latest packages. Once they are
uploaded, joeyh will take over, updating d-i as necessary. He doesn't
plan to redo the d-i boot stuff (aiui), so d-i will boot the old 3.1r0
kernels, while it will install the 3.1r1 kernels (it would be better to
talk to him to clarify this, however).
Horms has been working on security fix kernels, with the intention of
doing a non-ABI changing kernel update, and has been trying to get ahold
of you; I'm not sure the status of this atm. However, depending on what
you'd prefer to see, we can roll the ABI change in there as well, and
just do one security update."
"The source package names will not be changing; only the binary package
names. kernel-image-2.6.8-i386 will remain the source package name;
however, the following binary packages that're generated from that will
change:
kernel-headers-2.6.8-2 -> kernel-headers-2.6.8-3
kernel-headers-2.6.8-2-386 -> kernel-headers-2.6.8-3-386
kernel-headers-2.6.8-2-686 -> kernel-headers-2.6.8-3-686
kernel-headers-2.6.8-2-686-smp -> kernel-headers-2.6.8-3-686-smp
kernel-headers-2.6.8-2-k7 -> kernel-headers-2.6.8-3-k7
kernel-headers-2.6.8-2-k7-smp -> kernel-headers-2.6.8-3-k7-smp
kernel-image-2.6.8-2-386 -> kernel-image-2.6.8-3-386
kernel-image-2.6.8-2-686 -> kernel-image-2.6.8-3-686
kernel-image-2.6.8-2-686-smp -> kernel-image-2.6.8-3-686-smp
kernel-image-2.6.8-2-k7 -> kernel-image-2.6.8-3-k7
kernel-image-2.6.8-2-k7-smp -> kernel-image-2.6.8-3-k7-smp
There are, as you can imagine, many more for each different architecture
(and for 2.4.27). Do you need a full list of these?"
I never received a response to that mail, however.
Reply to: