On Fri, Jul 17, 2009 at 01:25:54PM -0600, dann frazier wrote: > On Thu, Jul 16, 2009 at 11:53:38AM -0700, Alok Kataria wrote: > > > > On Wed, 2009-07-15 at 23:13 -0700, dann frazier wrote: > > > On Wed, Jul 15, 2009 at 10:09:59PM +0200, Moritz Muehlenhoff wrote: > > > > On Tue, Jul 14, 2009 at 10:17:24AM -0700, Alok Kataria wrote: > > > > > Ping....any news on when these patches will be picked ? > > > > > Please let me know if you have any questions regarding these patches. > > > > > > > > We can have to schedule these patches for the next time we bump the > > > > ABI of the kernel (usually triggered by security fixes requiring > > > > one). > > > > > > > > Or is there already a planned bump, Dann? > > > > > > There's not one, but we could create a branch to queue ABI-breaking > > > fixes. > > > > If we do that, would there be an ETA on when I can expect these patches > > in the kernel ? Does it still have to wait for a security fix requiring > > ABI bump ? > > Nah - ABI bumps can come for non-security reasons too. But, since it > can be a pain for users (and our installer folks), we try to do queue > non-critical ABI breakers and do them together.
fyi, I took a shot at backporting these changes. Unfortunately our source is from before the 32/64 tsc.c merge, and a couple of these patches can't easily apply (even with the intrepid patches). Specifically, these are the changesets I had issues with: commit 83db682 x86: Hypervisor detection and get tsc_freq from hypervisor commit 0532dac x86: Skip verification by the watchdog for TSC clocksource I'm not really comfortable applying the tsc-merge patches themselves since its not something I can easily spot check. Is it possible to recode these to apply to the pre-merge tsc files (and demonstrate a low risk of regression)? If so - and someone want to do that, it, then it would be an easier push for lenny. -- dann frazier -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org