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 interest: $ grep-dctrl -FBuild-Depends -sPackage mpich \ /var/lib/apt/lists/debian.oregonstate.edu_debian_dists_unstable_*Sources 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. Excellent. > 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. <nod> > 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. Yes. > * Follow up on the illuminator FTBFS problem on SPARC. Yes. > 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. 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