[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: mpich C++ transition status

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.

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

Reply to: