Re: kernel-image-2.6.8-ia64 ABI reversion

[dann frazier <dannf@dannf.org>]

On Thu, 2005-03-24 at 19:37 -0800, Steve Langasek wrote:
> On Thu, Mar 24, 2005 at 06:22:32PM -0700, dann frazier wrote:
> > I'm trying to decide what I want to do about the ia64 kernel ABI.  I
> > rev'd it from -2 (currently in sarge) to -3 to turn off PREEMPT
> > (prevents at least one user triggerable oops).  This seemed convenient,
> > since the k-s-2.6.8-14 had its own ABI change.
> 
> > Well, turns out this was a bad idea - we've decided to revert the ABI
> > change from the kernel-source, and the ia64 images are blocked from
> > sarge because of it.
> 
> > Is it feasible (or even a good idea) to revert this ABI change?  The
> > only problem I can come up with is that sid systems that installed the
> > -2 ABI version and the -3 ABI version won't use -2 as a default kernel
> > after the upgrade.  That seems acceptable since after all, this is sid,
> > and once we do the pending ABI roll, it will be -3 once again.  And, I'd
> > like for sarge users to be able to test new uploads.
> 
> We want to keep any of these kernel updates from reaching testing before
> sarge release, unless there's agreement that we should do a full update
> (including revision of the d-i kernel udebs).  Kernels also aren't affected
> by the autobuilder problems with t-p-u right now, so that option is open for
> anything that does need to be uploaded for sarge.  I'd say there's no reason
> not to play with longshot-for-sarge kernel changes in unstable.

Thanks Steve.  I think this decision makes the outcome of the thread
'sarge kernel security transition' pretty important.  

It seems to me that the best use of everyone's time would be for the
kernel team to have an agreement with the security team that we will
restrict changes to our 2.4.27/2.6.8 kernels in such a way that they can
start with our unstable packages for sarge updates (with maybe a sarge
toolchain rebuild).  This way we can keep doing security updates and
uploading kernels to sid to get some testing, and if $deity forbid we
need to do an rc4, we've got new bits prepared for that as well.
There's no reason for us to be working w/ these kernel revs if our
changes aren't going to make it into sarge.

Security Team: is there a set of rules for our changes that would make a
transition like this work?

-- 
dann frazier <dannf@dannf.org>