On Mon, May 23, 2005 at 01:19:36AM +0200, Matthias Klose wrote: > > On Sat, May 14, 2005 at 10:52:23PM +0200, Matthias Klose wrote: > > Content-Description: message body text > > > I'm proposing the following updates for gcc-3.3 for testing:
> > > gcc-3.3 (1:3.3.5-13) testing-proposed-updates; urgency=low > > > * Disable running the boehm-gc testsuite on hppa. Hangs the buildd's > > > on some builds. > > > Sometimes seen on the buildd's. Conditionally done for hppa, should > > > not affect the other architectures. > > > * Don't call dh_shlibdeps on 64bit libraries, fixing FTBFS on sparc, > > > which couldn't be observed before (addresses: #307625). > > > The same fix as done for gcc-3.4. > > Shouldn't both of the above problems go away anyway post-release when the > > buildds are updated with (presumably) fixed kernels? > I've seen the former on a current hppa sarge system as well, I cannot > comment on the second one. Ok. I'm not really keen on disabling the testsuite, but it seems necessary here. For the sparc issue, I don't see the need, so would rather not have this changed now; all the evidence says that this problem is fixed properly in the sarge kernels. > > > * Manually patch all `configure' files for libraries to use > > > deplibs_check_method=pass_all unconditionally for all linux > > > architectures; > > > disable the autoreconf patch. > > > > > Reviewed by Ryan Murray, applied in the 3.3.6 package. Test builds on > > > mips were done by Thiemo Seufer. > > > > What problem does this fix? > The configury get's wrong, if autoconf is installed on the build > system. See #310167. Adding a build-conflict on autoconf is an > alternative, but I would prefer the patch as submitted. Yes, might as well fix the configure script, then. > > > Three upstream changes, which are in gcc-3.3.6. > > > - Fix for http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20670, wrong > > > code generation on ia64, patch is local to ia64, fixed in > > > 3.3.6, 3.4.4 (not yet fixed in the gcc-3.4 testing version, where it > > > should be fixed as well, the shared libgcc is built from gcc-3.4). > not needed, because gcc-3.4 is configure --with-system-libunwind Then indeed, please leave it out. :) > > > - Fix for http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19579, wrong > > > code generation at -O2 for -march=i686, a regression from 3.3.4, > > > 3.3.5, 3.4.0, 3.4.3, fixed in the gcc-3.4 version in testing. > checked only that the testcase. > > > - Fix for http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20286, an > > > ice-on-valid-code, patch is local to ia64, a regression from > > > 3.3.5 and 3.3.4. > > > "The current PAPI (icl.cs.utk.edu) source code does not compile > > > on Debian/testing on IA-64. The current gcc 3.3.5 panics when > > > compiling threads.c" > > Are these linked to known problems within Debian packages, or suspected to > > affect the buildability of binary packages currently in sarge? > An ice-on-valid-code results in an FTBFS, so this should have been > detected. Wrong code generation for -march=i686 might effect packages > built with this optimization (we do have some), but it's not a "known > problem within a Debian package". Known bad code generation is bad enough. Known bad code generation is a bug, but that doesn't make it an RC bug. We should be *more* conservative with toolchain updates during the freeze than we are with other packages, not less so; and wrong code generation that only occurs when using a build option that is against policy for most packages to use is not RC. The ICE here seems to be about software that's not in Debian, so it doesn't seem to be a FTBFS bug that affects us, either. So, if these bugs aren't going to cause problems for being able to rebuild packages in sarge, they should not be included in the upload to t-p-u. The hppa testsuite, the configure change for mips, and the update-alternatives changes you mentioned previously would all be good to have, so please go ahead and upload those fixes to t-p-u. If there's other evidence that one of the remaining fixes is RC, then go ahead and include it as well. Thanks, -- Steve Langasek postmodern programmer
signature.asc
Description: Digital signature
