[Pkg-openmpi-maintainers] Bug#376833: Bug#376833: Next steps

Adam C Powell IV hazelsct at debian.org
Tue Mar 11 08:51:29 UTC 2008


On Sat, 2008-03-08 at 09:30 -0600, Dirk Eddelbuettel wrote:
> Hi Adam,  
> 
> [ Jeff/Tim: This is about the outstanding Debian bug report(s) regarding the
> architectures without atomic ops -- where we cannot build Open MPI. It has
> been suggested in the past to try libatomic-ops-dev which seems to lack one
> or two instructions needed by Open Mpi ]
> 
> On 8 March 2008 at 09:12, Adam C Powell IV wrote:
> | Hi Dirk,
> | 
> | I'm afraid I don't have a lot of time just now, but to me next steps
> | seem like:
> |      1. Install libatomic-ops-dev.
> |      2. Try building openmpi without the included atomic ops and with
> |         this lib.
> |      3. If it works, great!  If it doesn't, try to adjust the calls
> |         and/or ask on the openmpi mailing list.
> |      4. If they suggest a workaround, great!  If not, wishlist
> |         libatomic-ops-dev to add the needed functionality.
> |      5. When everything works, push the change upstream.
> | 
> | If you don't get to it first, I can do 1-2 in about 2-3 weeks...
> 
> Do you have access to any of the missing arches without atomic ops from
> upstream?

No, but if it works on the existing arches, it should work on the
missing ones, right?  Furthermore, if the ops happen to be the same,
what's to say upstream didn't get them from this lib in the first place?
[Jeff/Tim, I welcome your comments...]

> Or are you in fact suggesting that supplant what upstream has with
> libatomic-ops-dev?  I would hesitate a great before doing that -- I tend to
> trust upstream in these matters.

That's fair.  On the other hand, it can't hurt to try it, and we have a
good bit of time now for users to test it before the lenny release.  If
nothing else, it's worth giving it a go in experimental.  As I said, if
you don't get it to it in a couple of weeks, I'll give it a go.

Debian has generally emphasized sharing code wherever possible.  So for
example, ffmpeg and mplayer have been strongly urged to do what it takes
to share the decoder libraries, which are developed together, though the
release schedules of those two "front ends" have been very different.
Likewise, I shoehorned the pysparse python sparse solver front end to
fit with Debian's superlu and umfpack (suitesparse package) libraries in
place of the versions provided in the upstream source.  I think the same
principal is at work here.

> Generally speaking, it may be worthwhile going to upstream now. So lemme CC
> them, as well as co-maintainer Manuel.

Good idea.  I often work with non-responsive upstream developers, so my
first recourse is usually to "just do it", but thankfully that is not
the case with openmpi.

> I should point out to Jeff and Tim that we do get quasi-constant grief about
> Open MPI not spanning the Debian universe of arches.  I personally fall back
> to Lam where Open MPI is missing but that is indeed somewhat cheesy.
> Longer-term, full support across all hardware platform would be great.
> But I am talking way out of area of expertise here -- what do you upstream
> guys think? Let us have it, and don't hold back.

I look forward to more discussion.

-Adam
-- 
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

Engineering consulting with open source tools
http://www.opennovation.com/







More information about the Pkg-openmpi-maintainers mailing list