> 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?
Steve Langasek <email address hidden> 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