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 ([EMAIL PROTECTED]) [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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
