On Thu, Apr 05, 2007 at 06:24:04PM -0400, Lennart Sorensen wrote: > On Thu, Apr 05, 2007 at 11:46:16PM +0200, Florian Weimer wrote: > > Document it in the release notes, please. It's not worth risking > > stability for the majority of users for this kind of bug.
> > Anyway, is there any particular reason why upstream (or you) don't use > > the Intel-recommended way for detection of CPUID support? A library > > twiddling with SIGILL isn't a terribly good idea. > I have no idea. I just made the smallest change possible to make mysql > not break 486 machines. The other option is to go back to what was done > for sarge as far as I can tell, which is use the C implementation rather > than the assembly one and loose the performance gains on newer CPUs. > And documenting in the release notes that 486s will break on upgrade > doesn't seem like a particularly good solution without a fixed package > being made. Well if nothing else it can go into 4.0r1 I guess, or a > proposed update in the mean time. Documenting it in the release notes isn't particularly *relevant* if a fixed package is made, AFAICS. The content for the r0 release notes is frozen now anyway, to let translators catch up, so any mention of this in the release notes would be included on CDs the same time as the fixed package, more or less defeating the purpose. We should probably consider an errata document for the website, to document r0-specific issues that didn't make it into the release notes, so that we don't have to choose between dropping translations for not mentioning such errata and publishing supposedly-complete translations that don't mention all the errata due to time constraints. Anyway, if this bug had been marked as RC at any point in the past months, it certainly would have been fixed before now. It's frustrating to see people escalating bug severities at the very last minute, when the bug has been known for a while and it's now too late to include a fix in r0 without causing the release timeline to slip. (This is not the only bug where this has been the case; c.f. bug #399761.) I do remember a bug thread months ago about cpuid detection in mysql, but the fact that it wasn't listed as an RC bug anymore means that it quickly fell off of *my* radar. In practical terms, it seems to me that part of the fix here should really be to declare that we don't officially support 486 CPUs anymore, since no one who is using one was involved enough in the etch release to have documented this bug as RC until three days before release. :P -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]