On Tue, Oct 11, 2005 at 06:55:15PM -0700, Russ Allbery wrote: > Following up on the issues from my previous note that still exist. Sorry > that I hadn't given this attention sooner; I've been a bit buried > preparing for vacation. No worries. :) > Steve Langasek <vorlon@debian.org> writes: > > If the package previously built without trouble on hppa, it tends to > > suggest the package has gotten itself into an infinite loop of some > > kind, or else that a new version is substantially slower than previous > > versions for some unknown reason. It will almost certainly require > > coordination between the maintainer and the buildd admin to figure out. > I've filed a bug against r-base for this. I'm going to file it at > severity: important since I don't want the bug itself to block migration > if hppa gets built properly, but if that's not correct and it should be > upgraded, please feel free to either do so or ask me to do so. This really ought to be severity: serious; the package isn't going to get built without someone taking action, so I wouldn't worry about it getting fixed without the bug also being cleared. > >> scalapack failed on powerpc with: > >> /usr/bin/ld: /usr/lib/gcc/powerpc-linux-gnu/4.0.2/../../../../lib/libf2c.a(lread.o)(.got2+0xbc): unresolvable R_PPC_ADDR32 relocation against symbol `f__units' > >> /usr/bin/ld: final link failed: Nonrepresentable section on output > >> Does this ring a bell with anyone? That looks like a gcc issue, not a > >> problem with the package. It's also in dep-wait on arm waiting for > >> libf2c2. > I've now seen this problem elsewhere, and it's a problem with binutils on > powerpc. krb5 appears to also be affected. See Bug#329686 for more > details. Rebuilding the affected library from source should fix the > problem. > I'm not sure the right approach to take here. A new libf2c2 build on > powerpc with the current binutils will fix the problem; should I file a > bug against libf2c2 asking for a new sourceful upload to unstable, or is > this the place for a porter binary NMU? I never entirely understood how > those are supposed to work and when they are appropriate. I've requested a binNMU of libf2c2 for powerpc; scalapack will be retried automatically once the libf2c2 update is in the archive, so this should tell us pretty quickly if this fixes the bug. If so, we can get a binNMU of krb5 the same way. > > The removal will be semi-automatic once plplot has built on m68k, but > > that won't happen until octave2.1 is also available on m68k. But > > octave2.1 build-depends on gfortran, which is not available on m68k -- > > and not because the package hasn't built, because the package source is > > gcc-defaults. That looks like someone should file a bug against > > octave2.1, asking it to build-depend again on fort77 on m68k as previous > > versions did. > Bug filed. Looks good, thanks. Cheers, -- 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