Hello all, 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.
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): blacs-mpich-test (blacs-mpi) illuminator-demo (illuminator) libluminate5 (illuminator) libluminate6 (illuminator) libparmetis3.1 (parmetis) netpipe-mpich (netpipe) scalapack1-mpich (scalapack) Note that libluminate5 is only in testing and libluminate6 is only in unstable since illuminator did an SONAME change with 0.9.0-1, but thankfully it looks like there are no other dependencies on those libraries to complicate matters. illuminator also depends on libpetsc2.2.0 which depends on libmpich1.0, but petsc has already done its own transition, so it's ready to go. 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. * 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. * 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. The illuminator problem is the only one that really looks worrisome. We may need some help on SPARC to track that one down. 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. illuminator and parmetis are maintained by the mpich maintainer, who already knows this. :) * 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. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
