Re: mpich C++ transition status
Steve Langasek <vorlon@debian.org> writes:
> Things are far enough along that I've gone ahead and added a preliminary
> hint for lam/mpich, visible at
> <http://ftp-master.debian.org/testing/hints/vorlon>. This will let us
> get feedback via
> http://ftp-master.debian.org/testing/update_output.txt.gz in subsequent
> britney runs, so we can see at a glance what issues are still
> outstanding, and also catch any problems that weren't visible to the
> naked eye.
I'm not really sure how to read the britney output. I think that this is
the relevant failure:
now: 157+0: a-13:a-14:h-13:i-18:i-14:m-17:m-16:m-13:p-14:s-15:s-10
* alpha: blacs-mpich-dev, blacs-mpich-test, blacs1-mpich, libhdf5-mpich-1.6.2-0, libhdf5-mpich-dev, mpb-mpi, netpipe-mpich, scalapack-mpich-dev, scalapack-mpich-test, scalapack1-mpich
[...]
FAILED
but that would seem to imply that it's still exploding on all the
blacs-mpi stuff, which is part of the hint? Or maybe it wasn't part of
the hint at the last britney run and you just added that?
Anyway, the whole thing won't go without new versions of:
Source: netpipe
Source: xmpi
Source: clustalw-mpi (non-free)
at least, even with more hint refinement. Maybe we're getting towards
time for NMUs of those remaining packages?
> Since m68k is still not catching up very well, I'm forcing consideration
> of all the related packages where m68k is the only architecture we're
> missing. From your list, there are still the following packages in need
> of builds/uploads on other architectures, according to the output of the
> last britney run: pytables, rmpi, scalapack, semidef-oct, octave-gpc,
> and parmetis. In addition, plplot needs an ftp-master to remove the
> plplot9-driver-gnome binaries from unstable.
Looking through these:
pytables has failed on Alpha. The error message is:
/usr/bin/python2.3 setup.py build
Can't find a local numarray Python installation.
Please, read carefully the README and remember
that PyTables needs the numarray package to
compile and run.
but python2.3-numarray was installed. I'm mystified on this one. I'll
submit a bug against pytables in the hope that the maintainer can take a
look at it; it may need to get reassigned to python-numarray.
rmpi is in dep-wait on arm waiting for libf2c2 (which is building), and in
dep-wait on hppa waiting for r-base. r-base failed on hppa with an odd
error:
running code in 'utils-Ex.R' ...make[1]: *** [check] Terminated
make[2]: *** [test-all-basics] Terminated
make[3]: *** [test-Examples] Terminated
semop(2): encountered an error: Invalid argument
make: *** [check-stamp] Terminated
make[4]: *** [test-Examples-Base] Error 1
Build killed with signal 15 after 150 minutes of inactivity
Not really sure what to do with that problem; it smells a little like a
buildd issue rather than a problem with the package?
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.
octave-gpc needs a requeue (and I think that's all) on alpha and mips, as
it couldn't find libgpcl-dev and that package now appears to be available.
I'm not sure what's going on with it on ia64; it installs libgpcl-dev and
then can't find the header file from that package. Maybe (he says
hopefully) a rebuild will help there too? Should I mail the arch
addresses @buildd.debian.org about those two requeues?
semidef-oct is now fine, as is parmetis.
For the removal of plplot9-driver-gnome, should I submit a bug against
ftp.debian.org, or leave that for the package maintainer to do?
> If you aren't already familiar with it,
> http://people.debian.org/~igloo/status.php is a useful resource for
> getting an at-a-glance view of the build status of multiple packages
> across all architectures. You may want to load this list of packages up
> into that page, and see if there are any build failures that might
> require additional hand-holding.
Very good idea.
--
Russ Allbery (rra@stanford.edu) <http://www.eyrie.org/~eagle/>
Reply to: