Re: mpich C++ translation (to the correct list)
Steve Langasek <vorlon@debian.org> writes:
> 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.
Ah, excellent, thank you! Thank you both for this and for the
build-depends query. grep-dctrl is a tool that I need to use more often.
> 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.
It does. So hdf5 is going to have to transition as well. I'll work on
tracking that down after I track down the remaining bits of mpich.
> 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.
This is good, though, since transitioning in two pieces will make it much
easier to keep everything coordinated so that it can all go in.
> 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: fftw
Oh, ick. Well, this package has an RC bug in that it doesn't build its
shared libraries with proper dependencies. Thankfully, it doesn't use the
C++ libraries, but it does need a bug reported against it to fix the
library dependency problems, since it's certainly not statically linking
with mpich.
# don't use mpicc to create the shared lib or the mpich static lib
# will be included
cd mpi && gcc -shared -Wl,-soname \
-Wl,libfftw_mpi.so.$(version_major) \
-o .libs/libfftw_mpi.so.$(lib_version) sched.lo \
TOMS_transpose.lo transpose_mpi.lo fftwnd_mpi.lo fftw_mpi.lo
mv mpi/.libs/libfftw_mpi.so.$(lib_version) \
mpi/.libs/librfftw_mpi.so.$(lib_version) shared
> Package: k6fftwgel
> Package: k7fftwgel
> Package: p4fftwgel
These all have the same problem.
> Package: mpb
> Package: python-scientific
> Package: hypre
Uses mpicc and therefore statically linked, and doesn't use the C++
libraries. It looks like these can be ignored for the purposes of this
transition (although ideally they really should be dynamically linked,
which is an mpicc problem).
hypre also needs an RC bug filed against it to transition to something
other than the (now removed) mpich package, though. I can take care of
that.
> Package: warped
This is another library package and needs to do its own C++ transition as
well. This will also require tracking some things down, unfortunately.
There are other things I don't really understand about this package, too;
it clearly links with mpich and appears to link with the dynamic library,
but the binary package doesn't have the dependency. I think this is
related to its mpich build dependency; I wonder if that pulled in a static
library but not the shared library.
Anyway, warped isn't in testing and has two other RC bugs, so it too can
be ignored for the purposes of getting mpich into testing, but it needs
another RC bug filed for the transition.
> Package: blacs-mpi
> Package: hdf5
> Package: netpipe
> Package: petsc
> Package: scalapack
> Package: parmetis
Previously discussed.
>> * 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.
Oh, okay, I remember that one now that you mention it.
> 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.
I'm certainly happy to, although I'm not entirely sure what to do about it
other than just remember it, ask the package maintainer if removing the
sparc build is okay, and reminding to do that as part of the transition.
If that's what you meant by follow through, absolutely. If you meant
more, please let me know.
>> * 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.
Will do. I wasn't sure if that was the right etiquette, so I appreciate
the word on that.
I didn't get a chance to do this today, but I should be able to start on
this tomorrow.
>> 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. :)
Okay.
>> * 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.
Will also work on this tomorrow.
> Sorry for not getting you feedback on this sooner; but yes, you seem to
> be on the right track.
Thank you very much for the help and analysis! With some more practice, I
should be able to start doing this without waiting to be double-checked.
--
Russ Allbery (rra@stanford.edu) <http://www.eyrie.org/~eagle/>
Reply to: