Steve Langasek <[EMAIL PROTECTED]> writes: > This is the single most common build failure on arm, hppa, and m68k right > now, and has affected literally dozens or hundreds of other packages. I > do kinda know it on sight by this point. > >> Moreover, this bug should remain filed against gcc-4.0, because it is, >> in fact, a bug in gcc 4.0. There is a *separate* bug filed against >> lilypond referring to this one. This bug should remain open and filed >> against gcc-4.0 until a fix is uploaded for Debian. > > That's fine; I had reassigned it to lilypond before I received the mail that > you had filed a separate bug there. But this is a duplicate of 323133, so > merging. It also is not a release-critical bug because there is a valid > workaround for all affected packages, and in spite of the sizeable impact > it's non-trivial to fix and has been triaged out of necessity.
I find it ludicrous to think that the best solution here is to force a jillion maintainers to workaround the bug and recompile. I recall not too recently that you thought hacking version numbers was an acceptible solution, but I guess that's when your package was the one that was being asked to have a workaround. Hrm, seriously though, why not backport the fix (though the upstream bug record doesn't seem to show one yet, while the Debian bug record says fixed-upstream)? Or, failing that, take gcc-4.0 out of use on arm, hppa, and m68k? I see no necessity for "triaging" the bug; this is an excellent reason simply not to have gcc-4.0 in the archive on the affect archs. Certainly it should not be in testing! Surely this is a canonical example of a release-critical toolchain bug? Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]