On Fri, Dec 22, 2006 at 12:09:45PM +0100, maximilian attems wrote: > On Fri, Dec 22, 2006 at 11:28:29AM +0100, Marc 'HE' Brockschmidt wrote: > > Bastian Blank <[EMAIL PROTECTED]> writes: > > > On Fri, Dec 22, 2006 at 10:30:57AM +0100, Marc 'HE' Brockschmidt wrote: > > >> Sorry, I don't accept this. We are talking about an *overheating* > > >> problem, which means *broken* hardware. There needs to be at least a fix > > >> documented in the release-notes. > > > Garbage-in, garbage-out. The BIOS of that machines is broken. Do you > > > really expect that an interpreter (in this case the ACPI interpreter) > > > accepts any garbage? > > > > Other OSes don't destroy the hardware. There is a patch for Linux not to > > - I don't see why Debian should release with a kernel that destroys > > hardware, without even giving users a warning. Not everyone who buys a > > notebook is aware of ACPI problems, and we shouldn't expect all users to > > do so. > > > > Fix it or document it, I don't care. But the current state is not > > releasable. > > we are not talking about "a" patch. > what you need is an backport of the 2.6.19 acpi release to 2.6.18. > > acpi linux releases are tested as one release and you open a can of worm > once you start picking acpi patches. only mjg59 is insane enough to do > that. anyway the fix for those broken aml tables has a big dependency > so the backport is insane. > > i looked at it 2 month ago and dropped the case, we are shortly before > release. i restate those broken hardware needs a newer kernel fullstop.
Well, this would mean that we could provide a semi-official set of newer kernels for etch. We would, once etch is released, provide a backportet kernel of the new unstable kernel, as well as a etch-installing d-i for them. This would allow users to install a stable etch, but including a newer kernel, which is what probably most of us are doing anyway. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
