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

Re: mpich C++ translation (to the correct list)

Hi Russ,

On Sat, Aug 27, 2005 at 09:10:12PM -0700, Russ Allbery wrote:
> I've volunteered to try to help coordinate the mpich C++ transition.  I'm
> still just learning how to do this, so this first message is just an
> outline of what I think the current state is and what actions are needed
> next so that more experienced people can correct me if I get any of it
> wrong.

Thanks for volunteering. :)

> apt-cache rdepends (is there a better tool?) turns up the following binary
> packages depending on libmpich1.0 or libmpich-mpd1.0 that are not part of
> the mpich package itself (source packages in parentheses):

apt-cache rdepends can sometimes miss things, because it won't report
reverse-dependencies for a package that it believes doesn't exist.  A
tool that gives more consistent results is grep-dctrl; i.e.,

$ grep-dctrl -FDepends -sPackage libmpich1.0 /var/lib/apt/lists/<foo>Packages

This also lets you limit the results by suite, without having to fiddle
with /etc/apt/sources.list.

>   blacs-mpich-test  (blacs-mpi)
>   illuminator-demo  (illuminator)
>   libluminate5      (illuminator)
>   libluminate6      (illuminator)
>   libparmetis3.1    (parmetis)
>   netpipe-mpich     (netpipe)
>   scalapack1-mpich  (scalapack)

One notable absence from this list is hdf5, which I know for certain
build-depends on mpich even though it doesn't depend on the shared
library.  If the hdf5 binary packages also export a C++ interface, then
all of its reverse-dependencies will also need to be chased down for the
transition.  Since hdf5 doesn't have any binary dependencies on mpich,
britney doesn't require these packages to be transitioned together, but
we do want to make sure we don't end up with unbuildable packages in
testing for long periods of time.

Anyway, this command turns up a few more source packages that may be of 

$ grep-dctrl -FBuild-Depends -sPackage mpich \
Package: blacs-mpi
Package: fftw
Package: hdf5
Package: k6fftwgel
Package: k7fftwgel
Package: mpb
Package: netpipe
Package: p4fftwgel
Package: petsc
Package: python-scientific
Package: scalapack
Package: warped
Package: hypre
Package: parmetis

Determining which of these are actually using the C++ libs unfortunately
requires digging through either source code or build logs.  Of course,
if they're statically linked, they *should* not FTBFS due to the ABI
change unless they're using a particular compiler version for building;
nevertheless, if any of these remaining source packages build C++
libraries, they need to go through the transition in a timely fashion,
and any other packages that are using the C++ bindings probably need to
have their maintainers notified that the fixed mpich is available.

> Thankfully, it looks like libluminate6 and libparmetis3.1 are not
> themselves written in C++ and therefore don't need a separate transition,
> just a rebuild against the newer library.


> So, at first glance it looks like blacs-mpi, illuminator, parmetis,
> netpipe, and scalapack all need to be rebuilt against libmpich1.0c2, and
> then all of those packages, mpich, and petsc can all go into testing
> together.  There are, however, a few holdups:

>  * illuminator currently FTBFS on sparc with the following error:

>    ldd: /lib/ld-linux.so.2 exited with unknown exit code (132)
>    dpkg-shlibdeps: failure: ldd on `debian/illuminator-demo/usr/bin/tsview-ng' gave error exit status 1
>    dh_shlibdeps: command returned error code 256

>    This error has persisted through a couple of attempted builds but
>    doesn't occur on any other platforms, which makes me think that it's a
>    toolchain problem of some sort.

Yes, this is actually a bug in the 2.4 kernels on sparc, AIUI.  There
are a couple ways that this can be addressed:

- Get someone to hand-build the new illuminator package on a sparc
  running 2.6.  The drawbacks of this are that it hides the buildd issue
  rather than ensuring it gets fixed, and that sparc porters are
  currently hard to come by.
- Have the illuminator sparc binaries removed from unstable once it's
  built on other archs, and wait until the sparc autobuilder is upgraded
  before they get back in.  Inconvenient for any sparc users of the
  package (especially since, with only one sparc autobuilder, I don't
  know that there are any plans to upgrade the kernel in the near
  future), but leaves it up to the maintainer and the sparc porters to
  get this taken care of.
- Have illuminator removed from testing once the other packages are
  ready to go, and leave it out of testing until the sparc autobuilder
  is fixed.  This is really only a fallback option if the second option
  above isn't acceptable for some reason.

It would be great if you would be willing to follow through on this
issue as well.

>  * blacs-mpi FTBFS on m68k the last time it was built, but looking at the
>    build log this looks like a buildd failure rather than any problem with
>    the package.  That means that the new upload to build against the
>    current mpich library should be fine.

Right; if not, we can re-examine it based on a fresh build failure.

>  * netpipe currently build-depends (and netpipe-mpich currently depends)
>    on mpich, a package that's been dropped from the current mpich package.
>    My guess is that this is supposed to be mpich-bin, libmpich1.0-dev
>    (although I need to take a closer look).  This is Bug#323744.


> So, here's what I believe the next steps to be:

>  * Mail the maintainers of blacs-mpi, netpipe, and scalapack and make sure
>    that they know that their packages need new uploads to build against
>    the new mpich libraries.

Yes, preferably mailed by way of the BTS, since these are all NMU-worthy
RC bugs in the respective packages.

> illuminator and parmetis are maintained by the mpich maintainer, who
> already knows this.  :)

Still doesn't hurt to put it in the BTS, so that other people know it
too. :)

>  * Check into the netpipe situation and follow up to Bug#323744 with the
>    appropriate patch for debian/control based on what the package really
>    needs to build and run.


>  * Follow up on the illuminator FTBFS problem on SPARC.


> Since this is the first time that I've done this, I'd appreciate it if
> someone could check me on my reasoning.  If this sounds good, I can start
> with those steps tomorrow.

Sorry for not getting you feedback on this sooner; but yes, you seem to
be on the right track.

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: