On Fri, Mar 25, 2005 at 08:45:40AM -0700, dann frazier wrote: > 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. > Just to clarify - what is meant by 'these kernel updates'? All kernels? > All ia64 kernels? All ABI changes? - any kernel that builds against kernel-tree-2.6.8-14 or newer - kernel-source-2.4.27-9 or newer and anything that builds against it This is to ensure that we don't end up with *accidental* skew between the kernel source and kernel images, or between the kernel images and the udebs. If we decide later that the skew isn't important enough to block updates, or if we decide to roll a d-i update for one or more architectures (which looks like it might happen for 2.6 on sparc -- more in the BTS on that soon), we can unblock selectively. The three kernel packages that have explicitly *not* been blocked from testing are kernel-patch-powerpc-2.6.8 and kernel-image-2.6.8-m68k, which needed to be updated so they would continue building against kernel-tree-2.6.8-13 after kernel-source-2.6.8 2.6.8-14 accidentally made it into testing; and kernel-source-2.6.8 itself, which can now be updated in testing without adversely affecting any of the binaries now that all 2.6 archs are using the kernel-tree magic. 2.4 still has archs not using kernel-tree to full effect, so everything from that kernel branch needs to be held out together. -- Steve Langasek postmodern programmer
Attachment:
signature.asc
Description: Digital signature