On Sat, Oct 22, 2005 at 11:18:00PM -0700, Thomas Bushnell BSG wrote: > Steve Langasek <vorlon@debian.org> 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 would be happy to see a patch submitted for g++-4.0 that makes it work correctly on arm/hppa/m68k so that we can stop having maintainers do busywork. But the busywork can be distributed across the affected maintainers, and backporting a gcc patch cannot. If you feel up to the task of providing a backport to fix this bug, I would certainly be grateful. At any rate, when the decision was made to start building packages with g++-3.4 on these archs, there was no fix yet upstream for the problem. > 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. I'm sorry, but there's a big difference between have a library package change its name in a critical transition period for reasons that don't match today's best practices, and having to make a decision between a number of unpleasant options in order to keep three of our ports in the game building packages. I don't consider the solution arrived at for gdk-imlib a "workaround", I consider it the only viable mode for maintaining the large number of interconnected library packages we have today. > 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? If the gcc maintainers think that pointing g++ at g++-3.4 on these archs is the best option, I'm game. One disadvantage is that it wouldn't let us get feedback about what else might be wrong with g++-4.0 on those architectures, but we probably already have all the information we're going to get about the current round of toolchain packages. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. vorlon@debian.org http://www.debian.org/
Attachment:
signature.asc
Description: Digital signature