Re: Sarge kernels and Volatile
On Mon, Aug 01, 2005 at 12:11:29PM -0400, Andres Salomon wrote:
> 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.
Thanks, I wasn't aware of that. However it seems that
working with the security team on this is difficult -
lack of response being a primary issue. This is why
I was thinking volatile might be a good way to go.
That and there are some reasonably important non-security
fixes floating around and it would be nice to
have a way to make these available.
However, I am not fixed on the volatile idea, and
if security is a better way to go, I am happy with that.
Though that would require some sort of response from
the security team.
With regards to an ABI bump, to be honest I am dubious that we can ever
make an ABI update. It would probably be just as easy to jump to a
whole new kernel (2.6.8 -> 2.6.12?), which is something that we should
seriously consider.
--
Horms
Reply to: