Re: mpich C++ translation (to the correct list)
Adam C Powell IV <firstname.lastname@example.org> writes:
> So what else is left?
> * mpb: not built on m68k
> * hdf5: not built on m68k, waiting for lam with m68k build trouble
> * blacs-mpi: not built on m68k
> * scalapack: not built on arm, m68k, powerpc+
> * netpipe: needs new upload vs. new mpich?
> +scalapack on arm failed 2-3 weeks ago because new blacs-mpi was not yet
> built at the time; powerpc has an interesting build failure:
> /usr/bin/ld: final link failed: Nonrepresentable section on output
> AFAICT, that's it, or am I missing anything? BTW, libffm needs to be
> hinted in with the rest of these.
The main thing that we're blocked on at the moment is lam. lam currently
FTBFS on m68k due to a gcc 4.0 bug. I'm going to provide a patch today to
lower the optimization to -O2 for all architectures, based on debian-devel
comments that -O3 isn't a good idea on i386 either, and then it probably
needs an NMU.
Once the new lam has been uploaded and builds on m68k, the other packages
that depend on it can get uploaded to build with the new lam (including
netpipe, which depends on both lam and mpich and hasn't been built for the
new lam yet).
> I'd like to upload a new petsc, any ideas on the timetable for these?
If the worry is whether you'll hold up the migration, it looks to me like
that's not going to be an issue at the moment given the number of things
that still have to be built. Unless we're going to increase the urgency
of all of them (in which case petsc could go as well), it's going to be
more than 10 days before all this can go.
That being said, if you think there's any possibility that the new petsc
will have RC bugs, I'd wait.
Russ Allbery (email@example.com) <http://www.eyrie.org/~eagle/>