Re: mpich C++ translation (to the correct list)
Hello,
Just catching up on Debian stuff and found this email... Let me reply
to the parts relevant to my packages.
On Mon, 2005-08-29 at 20:02 -0700, Russ Allbery wrote:
> Steve Langasek <vorlon@debian.org> writes:
>
> > 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.
I'm doing builds (and uploads) of the (non-free) parmetis and hypre as
we speak, will address this dependency issue in hypre. I'm also fixing
another couple of errors in parmetis, which will make shared lib deps
work better for that package.
> > Package: petsc
Already transitioned, just waiting on mpich/glibc/gcc-4.0 etc.
> > Package: parmetis
Discussed above.
> >> * 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.
I'm fine with removing the sparc build of illuminator. Thanks. Do I
need to do anything to make this happen?
> >> 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.
Uh, okay, should I wait for the bugs before uploading the packages that
fix them? :-)
Thanks,
-Adam
--
GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6
Welcome to the best software in the world today cafe!
http://www.take6.com/albums/greatesthits.html
Reply to: