Debian Bug report logs - #376833
openmpi - FTBFS: error: No atomic primitives available for s390-ibm-linux-gnu

version graph

Package: openmpi; Maintainer for openmpi is Debian Open MPI Maintainers <pkg-openmpi-maintainers@lists.alioth.debian.org>;

Reported by: Bastian Blank <waldi@debian.org>

Date: Wed, 5 Jul 2006 11:03:27 UTC

Severity: wishlist

Tags: confirmed, help, upstream

Found in version openmpi/1.0.2-1

Reply or subscribe to this bug.

Toggle useless messages

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to debian-bugs-dist@lists.debian.org, unknown-package@qa.debian.org:
Bug#376833; Package openmpi. Full text and rfc822 format available.

Acknowledgement sent to Bastian Blank <waldi@debian.org>:
New Bug report received and forwarded. Copy sent to unknown-package@qa.debian.org. Full text and rfc822 format available.

Message #5 received at submit@bugs.debian.org (full text, mbox):

From: Bastian Blank <waldi@debian.org>
To: submit@bugs.debian.org
Subject: openmpi - FTBFS: error: No atomic primitives available for s390-ibm-linux-gnu
Date: Wed, 5 Jul 2006 12:49:44 +0200
Package: openmpi
Version: 1.0.2-1
Severity: important

There was an error while trying to autobuild your package:

> Automatic build of openmpi_1.0.2-1 on lxdebian.bfinv.de by sbuild/s390 85
[...]
> checking whether to enable smp locks... yes
> configure: error: No atomic primitives available for s390-ibm-linux-gnu
> make: *** [config.status] Error 1
> ******************************************************************************
> Build finished at 20060705-1225
> FAILED [dpkg-buildpackage died]



Information forwarded to debian-bugs-dist@lists.debian.org, Debian OpenMPI Maintainers <pkg-openmpi-maintainers@lists.alioth.debian.org>:
Bug#376833; Package openmpi. Full text and rfc822 format available.

Acknowledgement sent to Dirk Eddelbuettel <edd@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian OpenMPI Maintainers <pkg-openmpi-maintainers@lists.alioth.debian.org>. Full text and rfc822 format available.

Message #10 received at 376833@bugs.debian.org (full text, mbox):

From: Dirk Eddelbuettel <edd@debian.org>
To: 376833@bugs.debian.org, 405929@bugs.debian.org, 389306@bugs.debian.org
Cc: pkg-openmpi-maintainers@lists.alioth.debian.org, control@bugs.debian.org
Subject: Open bug reports on OpenMPI for 'no atomic primitives' on s390, hppa and m68k
Date: Tue, 31 Jul 2007 15:15:27 -0500
tags 376833 + upstream
tags 405929 + upstream
tags 389306 + upstream
severity 376833 wishlist
severity 405929 wishlist
thanks


Hi,

These three bugs are basically the same bug: lack of upstream support for
"atomic primitives" for OpenMPI at the upstream level.  

We (as in the recently-created OpenMPI maintainer group for Debian) spoke to
upstream, and the result is that is it unlikely that these three arches will
be supported any time soon by the upstream team. IIRC some faint is there for
hppa, and help from Debian's hppa team would be appreciated.

So (at least for the forseeable future) we are left with an unbuildable
package on these arches.  I would suggest that the port maintainers for s390,
m68k and hppa actually blacklist openmpi which may be the easiest solution. 
Else we may specify an 'active list of arches' in debian/control.

Comments welcome,  Dirk

-- 
Three out of two people have difficulties with fractions.



Tags added: upstream Request was from Dirk Eddelbuettel <edd@debian.org> to control@bugs.debian.org. (Tue, 31 Jul 2007 20:18:07 GMT) Full text and rfc822 format available.

Severity set to `wishlist' from `important' Request was from Dirk Eddelbuettel <edd@debian.org> to control@bugs.debian.org. (Tue, 31 Jul 2007 20:18:08 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Debian OpenMPI Maintainers <pkg-openmpi-maintainers@lists.alioth.debian.org>:
Bug#376833; Package openmpi. Full text and rfc822 format available.

Acknowledgement sent to Riku Voipio <riku.voipio@iki.fi>:
Extra info received and forwarded to list. Copy sent to Debian OpenMPI Maintainers <pkg-openmpi-maintainers@lists.alioth.debian.org>. Full text and rfc822 format available.

Message #19 received at 376833@bugs.debian.org (full text, mbox):

From: Riku Voipio <riku.voipio@iki.fi>
To: 376833@bugs.debian.org
Subject: re: Open bug reports on OpenMPI for 'no atomic primitives' on s390, hppa and m68k
Date: Thu, 21 Feb 2008 16:04:25 +0200
Hi,

I think becoming a serious instead of wishlist problem.

Some packages have started to add openmpi support (such as petsc), and more
pacakges have wishlist bugs to add openmpi support. These packages are
no longer buildable on multiple debian release architectures.

Why not use libatomic-ops which includes atomic primitives for all
supported architectures and more?


-- 
"rm -rf" only sounds scary if you don't have backups




Information forwarded to debian-bugs-dist@lists.debian.org, Debian OpenMPI Maintainers <pkg-openmpi-maintainers@lists.alioth.debian.org>:
Bug#376833; Package openmpi. Full text and rfc822 format available.

Acknowledgement sent to Dirk Eddelbuettel <edd@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian OpenMPI Maintainers <pkg-openmpi-maintainers@lists.alioth.debian.org>. Full text and rfc822 format available.

Message #24 received at 376833@bugs.debian.org (full text, mbox):

From: Dirk Eddelbuettel <edd@debian.org>
To: Riku Voipio <riku.voipio@iki.fi>, 376833@bugs.debian.org
Subject: Re: [Pkg-openmpi-maintainers] Bug#376833: Open bug reports on OpenMPI for 'no atomic primitives' on s390, hppa and m68k
Date: Thu, 21 Feb 2008 09:26:25 -0600
On 21 February 2008 at 16:04, Riku Voipio wrote:
| Some packages have started to add openmpi support (such as petsc), and more
| pacakges have wishlist bugs to add openmpi support. These packages are
| no longer buildable on multiple debian release architectures.

You can do what I did for Rmpi and use Open MPI where available and LAM where
not:

      Build-Depends: debhelper (>> 4.1.0), cdbs, r-base-dev (>= 2.6.0), \
	libopenmpi-dev (>= 1.2.4-5) [i386 amd64 alpha ia64 powerpc sparc], \
	lam4-dev [!i386 !amd64 !alpha !ia64 !powerpc !sparc]

Nothing wrong with that.

| Why not use libatomic-ops which includes atomic primitives for all
| supported architectures and more?

Are you sure that these atomic ops are the one mssing in Open MPI?  Could you
provide a proof of concept for one arch so that I could take that to upstream?

Dirk

-- 
Three out of two people have difficulties with fractions.




Information forwarded to debian-bugs-dist@lists.debian.org, Debian OpenMPI Maintainers <pkg-openmpi-maintainers@lists.alioth.debian.org>:
Bug#376833; Package openmpi. Full text and rfc822 format available.

Acknowledgement sent to Riku Voipio <riku.voipio@iki.fi>:
Extra info received and forwarded to list. Copy sent to Debian OpenMPI Maintainers <pkg-openmpi-maintainers@lists.alioth.debian.org>. Full text and rfc822 format available.

Message #29 received at 376833@bugs.debian.org (full text, mbox):

From: Riku Voipio <riku.voipio@iki.fi>
To: Dirk Eddelbuettel <edd@debian.org>
Cc: 376833@bugs.debian.org
Subject: Re: [Pkg-openmpi-maintainers] Bug#376833: Open bug reports on OpenMPI for 'no atomic primitives' on s390, hppa and m68k
Date: Sat, 1 Mar 2008 16:17:54 +0200
[Message part 1 (text/plain, inline)]
On Thu, Feb 21, 2008 at 09:26:25AM -0600, Dirk Eddelbuettel wrote:
> You can do what I did for Rmpi and use Open MPI where available and LAM where
> not:

>       Build-Depends: debhelper (>> 4.1.0), cdbs, r-base-dev (>= 2.6.0), \
> 	libopenmpi-dev (>= 1.2.4-5) [i386 amd64 alpha ia64 powerpc sparc], \
> 	lam4-dev [!i386 !amd64 !alpha !ia64 !powerpc !sparc]

> Nothing wrong with that.

I think a portable solution would be better.

> | Why not use libatomic-ops which includes atomic primitives for all
> | supported architectures and more?

> Are you sure that these atomic ops are the one mssing in Open MPI?  Could you
> provide a proof of concept for one arch so that I could take that to upstream?

I don't really know anything about openmpi internals, but looking at
atomic-powerpc32-linux.s all but opal_sys_timer_get_cycles have similar
definitions in libatomic-ops-dev.

-- 
"rm -rf" only sounds scary if you don't have backups
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian OpenMPI Maintainers <pkg-openmpi-maintainers@lists.alioth.debian.org>:
Bug#376833; Package openmpi. Full text and rfc822 format available.

Acknowledgement sent to Dirk Eddelbuettel <edd@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian OpenMPI Maintainers <pkg-openmpi-maintainers@lists.alioth.debian.org>. Full text and rfc822 format available.

Message #34 received at 376833@bugs.debian.org (full text, mbox):

From: Dirk Eddelbuettel <edd@debian.org>
To: Riku Voipio <riku.voipio@iki.fi>
Cc: 376833@bugs.debian.org
Subject: Re: [Pkg-openmpi-maintainers] Bug#376833: Open bug reports on OpenMPI for 'no atomic primitives' on s390, hppa and m68k
Date: Sat, 1 Mar 2008 09:07:08 -0600

On 1 March 2008 at 16:17, Riku Voipio wrote:
| On Thu, Feb 21, 2008 at 09:26:25AM -0600, Dirk Eddelbuettel wrote:
| > You can do what I did for Rmpi and use Open MPI where available and LAM where
| > not:
| 
| >       Build-Depends: debhelper (>> 4.1.0), cdbs, r-base-dev (>= 2.6.0), \
| > 	libopenmpi-dev (>= 1.2.4-5) [i386 amd64 alpha ia64 powerpc sparc], \
| > 	lam4-dev [!i386 !amd64 !alpha !ia64 !powerpc !sparc]
| 
| > Nothing wrong with that.
| 
| I think a portable solution would be better.

"Would" and "could" are great terms as there are millions of things we
"could" improve around Debian. :)

But we *do* currently build against MPI -- either Open MPI or LAM -- on all
arches, so in my book the matter is at worst somewhat aethestically
unpleasant, but not all that urgent.
 
| > | Why not use libatomic-ops which includes atomic primitives for all
| > | supported architectures and more?
| 
| > Are you sure that these atomic ops are the one mssing in Open MPI?  Could you
| > provide a proof of concept for one arch so that I could take that to upstream?
| 
| I don't really know anything about openmpi internals, but looking at
| atomic-powerpc32-linux.s all but opal_sys_timer_get_cycles have similar
| definitions in libatomic-ops-dev.

Our invitation is still open -- come join the open-mpi lists and discuss it
there.  We need people with actual knowledge of a given arch, and access to
such a box to do some testing. I'd help, but I know little beyond x86 and
even then little about architecture matters.   So join in the effort and make
change happen.

On the other hand, just standing on a soap box and wishing for a pony won't
solve the issue. That's why the bug report is open.  We brought it up once or
twice on list and some people volunteered ... only to disappear thereafter.

I really do appreciate the follow-up, but we need more concrete next steps.

Dirk

-- 
Three out of two people have difficulties with fractions.




Information forwarded to debian-bugs-dist@lists.debian.org, Debian OpenMPI Maintainers <pkg-openmpi-maintainers@lists.alioth.debian.org>:
Bug#376833; Package openmpi. Full text and rfc822 format available.

Acknowledgement sent to Adam C Powell IV <hazelsct@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian OpenMPI Maintainers <pkg-openmpi-maintainers@lists.alioth.debian.org>. Full text and rfc822 format available.

Message #39 received at 376833@bugs.debian.org (full text, mbox):

From: Adam C Powell IV <hazelsct@debian.org>
To: 376833@bugs.debian.org
Subject: Next steps
Date: Sat, 08 Mar 2008 09:12:44 -0500
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...

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

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





Information forwarded to debian-bugs-dist@lists.debian.org, Debian OpenMPI Maintainers <pkg-openmpi-maintainers@lists.alioth.debian.org>:
Bug#376833; Package openmpi. Full text and rfc822 format available.

Acknowledgement sent to Dirk Eddelbuettel <edd@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian OpenMPI Maintainers <pkg-openmpi-maintainers@lists.alioth.debian.org>. Full text and rfc822 format available.

Message #44 received at 376833@bugs.debian.org (full text, mbox):

From: Dirk Eddelbuettel <edd@debian.org>
To: Adam C Powell IV <hazelsct@debian.org>, 376833@bugs.debian.org
Cc: Manuel Prinz <debian@pinguinkiste.de>, Jeff Squyres <jsquyres@cisco.com>, Tim Mattox <timattox@open-mpi.org>
Subject: Re: [Pkg-openmpi-maintainers] Bug#376833: Next steps
Date: Sat, 8 Mar 2008 09:30:15 -0600
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?   

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.

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

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.

Dirk  

-- 
Three out of two people have difficulties with fractions.




Information forwarded to debian-bugs-dist@lists.debian.org, Debian OpenMPI Maintainers <pkg-openmpi-maintainers@lists.alioth.debian.org>:
Bug#376833; Package openmpi. Full text and rfc822 format available.

Acknowledgement sent to Adam C Powell IV <hazelsct@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian OpenMPI Maintainers <pkg-openmpi-maintainers@lists.alioth.debian.org>. Full text and rfc822 format available.

Message #49 received at 376833@bugs.debian.org (full text, mbox):

From: Adam C Powell IV <hazelsct@debian.org>
To: Dirk Eddelbuettel <edd@debian.org>
Cc: 376833@bugs.debian.org, Manuel Prinz <debian@pinguinkiste.de>, Jeff Squyres <jsquyres@cisco.com>, Tim Mattox <timattox@open-mpi.org>
Subject: Re: [Pkg-openmpi-maintainers] Bug#376833: Next steps
Date: Tue, 11 Mar 2008 04:51:29 -0400
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/





Information forwarded to debian-bugs-dist@lists.debian.org, Debian OpenMPI Maintainers <pkg-openmpi-maintainers@lists.alioth.debian.org>:
Bug#376833; Package openmpi. Full text and rfc822 format available.

Acknowledgement sent to Jeff Squyres <jsquyres@cisco.com>:
Extra info received and forwarded to list. Copy sent to Debian OpenMPI Maintainers <pkg-openmpi-maintainers@lists.alioth.debian.org>. Full text and rfc822 format available.

Message #54 received at 376833@bugs.debian.org (full text, mbox):

From: Jeff Squyres <jsquyres@cisco.com>
To: Adam C Powell IV <hazelsct@debian.org>
Cc: Dirk Eddelbuettel <edd@debian.org>, 376833@bugs.debian.org, Manuel Prinz <debian@pinguinkiste.de>, Tim Mattox <timattox@open-mpi.org>
Subject: Re: [Pkg-openmpi-maintainers] Bug#376833: Next steps
Date: Tue, 18 Mar 2008 08:58:40 -0400
On Mar 11, 2008, at 4:51 AM, Adam C Powell IV wrote:

>> [ 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 ]

Good context; thanks.

>> 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...]

The guy who did the majority of atomic assembly is no longer on the  
project :-(, so I can't say for sure where they came from.  It was  
probably a mixture of many different sources, such as instruction  
manuals for the chipsets involved, etc.

What platforms in particular are not supported that Debian wants?

>> 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.

I'm afraid I know nothing about libatomic-ops-dev -- I did a few quick/ 
lame google searches and couldn't turn up a home page for this project  
(including on debian.org).  Could someone point me in the right  
direction?

We can investigate it and see if it meets our needs.

> 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.

Without knowing anything about libatomics-ops-dev, three roadblocks to  
integrating libatomic-ops-dev into Open MPI could be:

1. license: Open MPI is BSD -- what's libtatomics-ops-dev?

2. portability: does it work outside of Linux?  Does it work with non- 
gcc compilers?  The first is surmountable (see below), but the second  
would be quite difficult to fix -- we would likely need fixes from the  
libatomics-ops-dev maintainers.

3. distribution: we have a core philosophy of aggressively trying to  
decrease the number of dependencies of Open MPI to enable simple  
download/install by novice users (we can't always succeed in this, but  
we do try).  To this point, we have embedded a few "core" dependencies  
in the Open MPI source code distribution itself so that you don't have  
to have them installed to build/run Open MPI (e.g., particularly on  
platforms that may not have them already installed, such as OS X or  
Solaris).  The atomic operations likely fit into this category such  
that the OMPI community may be resistant to requiring a 3rd party  
library just to be able to install/run.

One *possibility* is that we could use the included atomics unless  
specifically directed to use libatomic-ops (e.g., via a configure  
option such as --with-libatomic-ops=/foo).  There's lots of "if's" in  
there, though -- if the license is compatible, if the library meets  
our needs, ...etc.  So we would need to investigate a few things first.

>> 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.

We're not always quick to reply, but we try.  :-)

>> 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.


The biggest problem is maintenance.  I can't easily justify to my  
employer spending time on maintenance of platforms that we officially  
don't care about.  Such is true with many of the other Open MPI  
developers -- we don't really have someone who is "batting cleanup" to  
pick up all the loose odds and ends on platforms that aren't  
officially supported.  :-\

If libatomic-ops-dev can fix some of these problems (by automatically  
picking up [atomic ops] support on some platforms that we don't  
actively support, especially since our main assembly developer is now  
gone), that would be great.  But it'll require some investigation first.

I should also point out that we're gearing up for branching for the  
v1.3 series and are rushing to finish some critical features before  
deadline.  To be honest and not inflate expectations, I kinda doubt  
that we'll have the time to be able to perform due diligence on  
libatomic-ops-dev and/or integrate it before 1.3 branching.  :-(

-- 
Jeff Squyres
Cisco Systems





Information forwarded to debian-bugs-dist@lists.debian.org, Debian OpenMPI Maintainers <pkg-openmpi-maintainers@lists.alioth.debian.org>:
Bug#376833; Package openmpi. Full text and rfc822 format available.

Acknowledgement sent to Dirk Eddelbuettel <edd@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian OpenMPI Maintainers <pkg-openmpi-maintainers@lists.alioth.debian.org>. Full text and rfc822 format available.

Message #59 received at 376833@bugs.debian.org (full text, mbox):

From: Dirk Eddelbuettel <edd@debian.org>
To: Jeff Squyres <jsquyres@cisco.com>
Cc: Adam C Powell IV <hazelsct@debian.org>, Dirk Eddelbuettel <edd@debian.org>, 376833@bugs.debian.org, Manuel Prinz <debian@pinguinkiste.de>, Tim Mattox <timattox@open-mpi.org>
Subject: Re: [Pkg-openmpi-maintainers] Bug#376833: Next steps
Date: Tue, 18 Mar 2008 11:10:32 -0500
Hi Jeff et al,

Thanks for the follow-up!  Lots of good points raised, I'll try to reply 'in
full' and apologize in advance for the length of the email.

On 18 March 2008 at 08:58, Jeff Squyres wrote:
| On Mar 11, 2008, at 4:51 AM, Adam C Powell IV wrote:
| 
| >> [ 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 ]
| 
| Good context; thanks.
| 
| >> 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...]
| 
| The guy who did the majority of atomic assembly is no longer on the  
| project :-(, so I can't say for sure where they came from.  It was  
| probably a mixture of many different sources, such as instruction  
| manuals for the chipsets involved, etc.
| 
| What platforms in particular are not supported that Debian wants?

We havevery good success with Open MPI on

	i386 amd64 alpha ia64 powerpc sparc

and we are out of luck on

	arm    [ and a new variant armel with fpu support was added IIRC ]
	hppa
	m68k   [ though that architecture may get purged ... ]
	mips   [ there are some compute blades using this IIRC ]
	mipsel       
	s390

For these we can fall back to LAM but that is kinda lame (bad pun alert).
 
| >> 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.
| 
| I'm afraid I know nothing about libatomic-ops-dev -- I did a few quick/ 
| lame google searches and couldn't turn up a home page for this project  
| (including on debian.org).  Could someone point me in the right  
| direction?
| 
| We can investigate it and see if it meets our needs.

[ You can reply on the file debian/copyright to point to the upstream
sources; and these Debian files are visibile via the 'package tracking
system' pages eg http://packages.qa.debian.org/liba/libatomic-ops.html -- and
I do not mean to imply that you could or should have known that. 

This PTS also shows that the package is actively maintained: recent upoads,
no bugs. Good! ]

The copyright at 
http://packages.debian.org/changelogs/pool/main/liba/libatomic-ops/current/copyright
says downloaded from 

	http://www.hpl.hp.com/research/linux/atomic_ops/download.php4

and lists Hans Boehm and David Mosberger as authors, with their hp.com
addresses and with HP as copyright holders.  Pestering these famous kernel
hackers may be next on our agenda then :)

Is/Was HP part of Open MPI ?   Or are they 'neutral', or worse in 'enemy
territory' ?

| > 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.
| 
| Without knowing anything about libatomics-ops-dev, three roadblocks to  
| integrating libatomic-ops-dev into Open MPI could be:
| 
| 1. license: Open MPI is BSD -- what's libtatomics-ops-dev?

Looks similar to me -- but see at the link above.

Mentions the GPL for subcomponents tests and sample apps, so looks like this
is not an issue.
 
| 2. portability: does it work outside of Linux?  Does it work with non- 
| gcc compilers?  The first is surmountable (see below), but the second  
| would be quite difficult to fix -- we would likely need fixes from the  
| libatomics-ops-dev maintainers.

Good points. Dunno -- we tend to be gcc only as far as Debian goes, but this
_should_ be vanilla C. 
 
| 3. distribution: we have a core philosophy of aggressively trying to  
| decrease the number of dependencies of Open MPI to enable simple  
| download/install by novice users (we can't always succeed in this, but  
| we do try).  To this point, we have embedded a few "core" dependencies  
| in the Open MPI source code distribution itself so that you don't have  
| to have them installed to build/run Open MPI (e.g., particularly on  
| platforms that may not have them already installed, such as OS X or  
| Solaris).  The atomic operations likely fit into this category such  
| that the OMPI community may be resistant to requiring a 3rd party  
| library just to be able to install/run.
| 
| One *possibility* is that we could use the included atomics unless  
| specifically directed to use libatomic-ops (e.g., via a configure  
| option such as --with-libatomic-ops=/foo).  There's lots of "if's" in  
| there, though -- if the license is compatible, if the library meets  
| our needs, ...etc.  So we would need to investigate a few things first.

Right. Or, if it is small, just pull it in. License permitting etc pp  [
Though as I said, we prefer using existing libraries but I understand that
yoru agenda is driven by different concerns. ]
 
| >> 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.
| 
| We're not always quick to reply, but we try.  :-)
| 
| >> 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.
| 
| 
| The biggest problem is maintenance.  I can't easily justify to my  
| employer spending time on maintenance of platforms that we officially  
| don't care about.  Such is true with many of the other Open MPI  
| developers -- we don't really have someone who is "batting cleanup" to  
| pick up all the loose odds and ends on platforms that aren't  
| officially supported.  :-\

Understood. Maybe you can get the IBM folks to look after s390 ;-)
 
| If libatomic-ops-dev can fix some of these problems (by automatically  
| picking up [atomic ops] support on some platforms that we don't  
| actively support, especially since our main assembly developer is now  
| gone), that would be great.  But it'll require some investigation first.
| 
| I should also point out that we're gearing up for branching for the  
| v1.3 series and are rushing to finish some critical features before  
| deadline.  To be honest and not inflate expectations, I kinda doubt  
| that we'll have the time to be able to perform due diligence on  
| libatomic-ops-dev and/or integrate it before 1.3 branching.  :-(

Debian is not worried about quarterly performance reports so for as long as
we get some pieces on motion, I'd be perfectly happy to defer to this to
1.3.$x with $x 'high' or even 1.4.0.   We are patient :)  I just spent 18+
months working with Argonne and the original author to get PGAPack relicensed
and back into Debian's main ;-)

We want to do this right.

Thanks for listening,  Dirk

-- 
Three out of two people have difficulties with fractions.




Information forwarded to debian-bugs-dist@lists.debian.org, Debian OpenMPI Maintainers <pkg-openmpi-maintainers@lists.alioth.debian.org>:
Bug#376833; Package openmpi. Full text and rfc822 format available.

Acknowledgement sent to Adam C Powell IV <hazelsct@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian OpenMPI Maintainers <pkg-openmpi-maintainers@lists.alioth.debian.org>. Full text and rfc822 format available.

Message #64 received at 376833@bugs.debian.org (full text, mbox):

From: Adam C Powell IV <hazelsct@debian.org>
To: Dirk Eddelbuettel <edd@debian.org>
Cc: Jeff Squyres <jsquyres@cisco.com>, 376833@bugs.debian.org, Manuel Prinz <debian@pinguinkiste.de>, Tim Mattox <timattox@open-mpi.org>, Riku Voipio <riku.voipio@iki.fi>
Subject: Re: [Pkg-openmpi-maintainers] Bug#376833: Next steps
Date: Wed, 19 Mar 2008 09:19:22 -0400
On Tue, 2008-03-18 at 11:10 -0500, Dirk Eddelbuettel wrote:
> Hi Jeff et al,
> 
> Thanks for the follow-up!  Lots of good points raised, I'll try to reply 'in
> full' and apologize in advance for the length of the email.
> 
> On 18 March 2008 at 08:58, Jeff Squyres wrote:
> | On Mar 11, 2008, at 4:51 AM, Adam C Powell IV wrote:
> | 
> | >> [ 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 ]
> | 
> | Good context; thanks.
> | 
> | >> 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?
>  
> | >> 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.
> | 
> | I'm afraid I know nothing about libatomic-ops-dev -- I did a few quick/ 
> | lame google searches and couldn't turn up a home page for this project  
> | (including on debian.org).  Could someone point me in the right  
> | direction?
> | 
> | We can investigate it and see if it meets our needs.

Unless upstream has the resources and interest to do this, I think it's
our job in Debian to give it a try first, and then send a patch upstream
(with appropriate configure test) if it works.

Unfortunately, I'm a bit over my head here, because I don't know any
assembly (at least nothing more recent than the 6502 family, but I'm
dating myself).  And if the OpenMPI assembly person left the team, it's
hard to see upstream doing this for us.

Riku, you mentioned in a previous post to this bug that most of the
definitions in OpenMPI's atomic-powerpc32-linux.s have counterparts in
libatomic-ops-dev.  I see some similarities, but have to poke around
quite a bit; for example, opal/class/opal-atomic-lifo.h seems to
indicate that cmpset is compare-and-swap, though it sounds more like
test-and-set.  Also, OpenMPI requires that the arguments be 32-bit (for
architecture interoperability?); libatomic-ops uses AO_t which appears
to be the native integer width on the architecture.

At first glance, this doesn't look straightforward, and it's certainly
beyond my abilities...

The good news is opal_sys_timer_get_cycles (the one you identified as
missing from libatomic-ops) looks relatively easy to duplicate for the
other arches.

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

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





Information forwarded to debian-bugs-dist@lists.debian.org, Debian OpenMPI Maintainers <pkg-openmpi-maintainers@lists.alioth.debian.org>:
Bug#376833; Package openmpi. Full text and rfc822 format available.

Acknowledgement sent to Jeff Squyres <jsquyres@cisco.com>:
Extra info received and forwarded to list. Copy sent to Debian OpenMPI Maintainers <pkg-openmpi-maintainers@lists.alioth.debian.org>. Full text and rfc822 format available.

Message #69 received at 376833@bugs.debian.org (full text, mbox):

From: Jeff Squyres <jsquyres@cisco.com>
To: Dirk Eddelbuettel <edd@debian.org>
Cc: Adam C Powell IV <hazelsct@debian.org>, 376833@bugs.debian.org, Manuel Prinz <debian@pinguinkiste.de>, Tim Mattox <timattox@open-mpi.org>
Subject: Re: [Pkg-openmpi-maintainers] Bug#376833: Next steps
Date: Wed, 19 Mar 2008 09:41:03 -0400
On Mar 18, 2008, at 12:10 PM, Dirk Eddelbuettel wrote:

> | What platforms in particular are not supported that Debian wants?
>
> We havevery good success with Open MPI on
>
> 	i386 amd64 alpha ia64 powerpc sparc
>
> and we are out of luck on
>
> 	arm    [ and a new variant armel with fpu support was added IIRC ]
> 	hppa
> 	m68k   [ though that architecture may get purged ... ]
> 	mips   [ there are some compute blades using this IIRC ]
> 	mipsel
> 	s390

FWIW, I'm not aware of any current OMPI members who care about these  
platforms.

> The copyright at
> http://packages.debian.org/changelogs/pool/main/liba/libatomic-ops/current/copyright
> says downloaded from
>
> 	http://www.hpl.hp.com/research/linux/atomic_ops/download.php4

Perfect; thanks.

> Is/Was HP part of Open MPI ?   Or are they 'neutral', or worse in  
> 'enemy
> territory' ?

HP is a big company.  :-)

I believe that part of HP doesn't care about Open MPI, but most of the  
HPC portion HP is probably against Open MPI because HP sells their own  
MPI (HP MPI).  So HP will likely never be a formal member of the Open  
MPI Project.

But we all work together; the MPI implementor community is fairly  
small and many of us know each other.  We have good working  
relationships.  Part of the goal of Open MPI is to come up with good  
ideas and let others use them.  :-)

> | 1. license: Open MPI is BSD -- what's libtatomics-ops-dev?
>
> Looks similar to me -- but see at the link above.
>
> Mentions the GPL for subcomponents tests and sample apps, so looks  
> like this
> is not an issue.

I sent the link for the project to a few OMPI developers yesterday,  
and our collective IANAL opinion is that only one sub-library in  
libatomics_ops needs to be avoided (because it's specifically GPL) --  
all other library bits are MIT and therefore are ok.

> | 2. portability: does it work outside of Linux?  Does it work with  
> non-
> | gcc compilers?  The first is surmountable (see below), but the  
> second
> | would be quite difficult to fix -- we would likely need fixes from  
> the
> | libatomics-ops-dev maintainers.
>
> Good points. Dunno -- we tend to be gcc only as far as Debian goes,  
> but this
> _should_ be vanilla C.

It's not the C that's the problem -- it's the assembly.  It *looks*  
like they use inline assembly only, and not all compilers support  
that.  This is somewhat of a dealbreaker for us -- meaning that we  
couldn't make this the default / only option available.

More below.

> | 3. distribution: we have a core philosophy of aggressively trying to
> | decrease the number of dependencies of Open MPI to enable simple
> | download/install by novice users (we can't always succeed in this,  
> but
> | we do try).  To this point, we have embedded a few "core"  
> dependencies
> | in the Open MPI source code distribution itself so that you don't  
> have
> | to have them installed to build/run Open MPI (e.g., particularly on
> | platforms that may not have them already installed, such as OS X or
> | Solaris).  The atomic operations likely fit into this category such
> | that the OMPI community may be resistant to requiring a 3rd party
> | library just to be able to install/run.
> |
> | One *possibility* is that we could use the included atomics unless
> | specifically directed to use libatomic-ops (e.g., via a configure
> | option such as --with-libatomic-ops=/foo).  There's lots of "if's"  
> in
> | there, though -- if the license is compatible, if the library meets
> | our needs, ...etc.  So we would need to investigate a few things  
> first.

The consensus yesterday was:

- license looks ok, but needs official review
- looks like they support all the atomic ops we need except for timers
- we could probably make a patch for a --with-libatomic-ops configure  
switch that would swap out our default atomic ops with libatomic_ops

Brian (the developer who isn't officially on our project anymore, but  
OMPI is still in his heart...) said he could look at making up such a  
patch.  I wouldn't want to estimate a timeline, though.

We probably will not be embedding this package in Open MPI because:

- it doesn't work for all compilers
- it doesn't work for all OS's / platforms
- and therefore it won't be our default/core

Hence, linking to it via an external header / library is fine.

-- 
Jeff Squyres
Cisco Systems





Information forwarded to debian-bugs-dist@lists.debian.org, Debian OpenMPI Maintainers <pkg-openmpi-maintainers@lists.alioth.debian.org>:
Bug#376833; Package openmpi. Full text and rfc822 format available.

Acknowledgement sent to Jeff Squyres <jsquyres@cisco.com>:
Extra info received and forwarded to list. Copy sent to Debian OpenMPI Maintainers <pkg-openmpi-maintainers@lists.alioth.debian.org>. Full text and rfc822 format available.

Message #74 received at 376833@bugs.debian.org (full text, mbox):

From: Jeff Squyres <jsquyres@cisco.com>
To: Jeff Squyres <jsquyres@cisco.com>
Cc: Dirk Eddelbuettel <edd@debian.org>, Adam C Powell IV <hazelsct@debian.org>, 376833@bugs.debian.org, Manuel Prinz <debian@pinguinkiste.de>, Tim Mattox <timattox@open-mpi.org>
Subject: Re: [Pkg-openmpi-maintainers] Bug#376833: Next steps
Date: Wed, 19 Mar 2008 20:47:53 -0400
Guess what?  Brian sent a long list of thoughts and a patch for "75%  
of the work" to support libatomic-ops in Open MPI (as a backup for  
platforms that we don't support with our native assembly).  The  
remaining 25% requires access to the platforms that we don't support  
-- so perhaps that's appropriate for you guys to tackle...?

I put up the information Brian sent on our wiki:

    https://svn.open-mpi.org/trac/ompi/wiki/libatomic-ops

I branched from our SVN trunk and applied his patch -- the SVN URL you  
can check out is (it contains his patch):

    https://svn.open-mpi.org/svn/ompi/tmp-public/libatomic-ops

Be sure to see our "how to compile OMPI from SVN" page:

    http://www.open-mpi.org/svn/building.php

How does this sound?



On Mar 19, 2008, at 9:41 AM, Jeff Squyres wrote:

> On Mar 18, 2008, at 12:10 PM, Dirk Eddelbuettel wrote:
>
>> | What platforms in particular are not supported that Debian wants?
>>
>> We havevery good success with Open MPI on
>>
>> 	i386 amd64 alpha ia64 powerpc sparc
>>
>> and we are out of luck on
>>
>> 	arm    [ and a new variant armel with fpu support was added IIRC ]
>> 	hppa
>> 	m68k   [ though that architecture may get purged ... ]
>> 	mips   [ there are some compute blades using this IIRC ]
>> 	mipsel
>> 	s390
>
> FWIW, I'm not aware of any current OMPI members who care about these  
> platforms.
>
>> The copyright at
>> http://packages.debian.org/changelogs/pool/main/liba/libatomic-ops/current/copyright
>> says downloaded from
>>
>> 	http://www.hpl.hp.com/research/linux/atomic_ops/download.php4
>
> Perfect; thanks.
>
>> Is/Was HP part of Open MPI ?   Or are they 'neutral', or worse in  
>> 'enemy
>> territory' ?
>
> HP is a big company.  :-)
>
> I believe that part of HP doesn't care about Open MPI, but most of  
> the HPC portion HP is probably against Open MPI because HP sells  
> their own MPI (HP MPI).  So HP will likely never be a formal member  
> of the Open MPI Project.
>
> But we all work together; the MPI implementor community is fairly  
> small and many of us know each other.  We have good working  
> relationships.  Part of the goal of Open MPI is to come up with good  
> ideas and let others use them.  :-)
>
>> | 1. license: Open MPI is BSD -- what's libtatomics-ops-dev?
>>
>> Looks similar to me -- but see at the link above.
>>
>> Mentions the GPL for subcomponents tests and sample apps, so looks  
>> like this
>> is not an issue.
>
> I sent the link for the project to a few OMPI developers yesterday,  
> and our collective IANAL opinion is that only one sub-library in  
> libatomics_ops needs to be avoided (because it's specifically GPL)  
> -- all other library bits are MIT and therefore are ok.
>
>> | 2. portability: does it work outside of Linux?  Does it work with  
>> non-
>> | gcc compilers?  The first is surmountable (see below), but the  
>> second
>> | would be quite difficult to fix -- we would likely need fixes  
>> from the
>> | libatomics-ops-dev maintainers.
>>
>> Good points. Dunno -- we tend to be gcc only as far as Debian goes,  
>> but this
>> _should_ be vanilla C.
>
> It's not the C that's the problem -- it's the assembly.  It *looks*  
> like they use inline assembly only, and not all compilers support  
> that.  This is somewhat of a dealbreaker for us -- meaning that we  
> couldn't make this the default / only option available.
>
> More below.
>
>> | 3. distribution: we have a core philosophy of aggressively trying  
>> to
>> | decrease the number of dependencies of Open MPI to enable simple
>> | download/install by novice users (we can't always succeed in  
>> this, but
>> | we do try).  To this point, we have embedded a few "core"  
>> dependencies
>> | in the Open MPI source code distribution itself so that you don't  
>> have
>> | to have them installed to build/run Open MPI (e.g., particularly on
>> | platforms that may not have them already installed, such as OS X or
>> | Solaris).  The atomic operations likely fit into this category such
>> | that the OMPI community may be resistant to requiring a 3rd party
>> | library just to be able to install/run.
>> |
>> | One *possibility* is that we could use the included atomics unless
>> | specifically directed to use libatomic-ops (e.g., via a configure
>> | option such as --with-libatomic-ops=/foo).  There's lots of  
>> "if's" in
>> | there, though -- if the license is compatible, if the library meets
>> | our needs, ...etc.  So we would need to investigate a few things  
>> first.
>
> The consensus yesterday was:
>
> - license looks ok, but needs official review
> - looks like they support all the atomic ops we need except for timers
> - we could probably make a patch for a --with-libatomic-ops  
> configure switch that would swap out our default atomic ops with  
> libatomic_ops
>
> Brian (the developer who isn't officially on our project anymore,  
> but OMPI is still in his heart...) said he could look at making up  
> such a patch.  I wouldn't want to estimate a timeline, though.
>
> We probably will not be embedding this package in Open MPI because:
>
> - it doesn't work for all compilers
> - it doesn't work for all OS's / platforms
> - and therefore it won't be our default/core
>
> Hence, linking to it via an external header / library is fine.
>
> -- 
> Jeff Squyres
> Cisco Systems
>


-- 
Jeff Squyres
Cisco Systems





Information forwarded to debian-bugs-dist@lists.debian.org, Debian OpenMPI Maintainers <pkg-openmpi-maintainers@lists.alioth.debian.org>:
Bug#376833; Package openmpi. Full text and rfc822 format available.

Acknowledgement sent to Dirk Eddelbuettel <edd@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian OpenMPI Maintainers <pkg-openmpi-maintainers@lists.alioth.debian.org>. Full text and rfc822 format available.

Message #79 received at 376833@bugs.debian.org (full text, mbox):

From: Dirk Eddelbuettel <edd@debian.org>
To: Jeff Squyres <jsquyres@cisco.com>
Cc: Adam C Powell IV <hazelsct@debian.org>, 376833@bugs.debian.org, Manuel Prinz <debian@pinguinkiste.de>, Tim Mattox <timattox@open-mpi.org>
Subject: Re: [Pkg-openmpi-maintainers] Bug#376833: Next steps
Date: Wed, 19 Mar 2008 21:06:21 -0500
On 19 March 2008 at 20:47, Jeff Squyres wrote:
| Guess what?  Brian sent a long list of thoughts and a patch for "75%  
| of the work" to support libatomic-ops in Open MPI (as a backup for  
| platforms that we don't support with our native assembly).  The  
| remaining 25% requires access to the platforms that we don't support  
| -- so perhaps that's appropriate for you guys to tackle...?

Ok, I guess the ball in our court for that.  We need to round up the porters
on these architectures.  Now, that doesn't always work as some of those good
folks are spread thinly (eg I think there at the most two looking after our
20,000 packages for the s390...)

Adam: Any thoughts?  Posts to -devel or the arch lists?
 
| I put up the information Brian sent on our wiki:
| 
|      https://svn.open-mpi.org/trac/ompi/wiki/libatomic-ops
| 
| I branched from our SVN trunk and applied his patch -- the SVN URL you  
| can check out is (it contains his patch):
| 
|      https://svn.open-mpi.org/svn/ompi/tmp-public/libatomic-ops
| 
| Be sure to see our "how to compile OMPI from SVN" page:
| 
|      http://www.open-mpi.org/svn/building.php
| 
| How does this sound?

Very helpful, and I hope someone will run with this.  I do not know these
arches either and cannot drive this, but I will try my best to move it along.

Thanks for the follow-up -- it is greatly appreciated.

Dirk

-- 
Three out of two people have difficulties with fractions.




Information forwarded to debian-bugs-dist@lists.debian.org, Debian OpenMPI Maintainers <pkg-openmpi-maintainers@lists.alioth.debian.org>:
Bug#376833; Package openmpi. Full text and rfc822 format available.

Acknowledgement sent to Adam C Powell IV <hazelsct@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian OpenMPI Maintainers <pkg-openmpi-maintainers@lists.alioth.debian.org>. Full text and rfc822 format available.

Message #84 received at 376833@bugs.debian.org (full text, mbox):

From: Adam C Powell IV <hazelsct@debian.org>
To: Dirk Eddelbuettel <edd@debian.org>
Cc: Jeff Squyres <jsquyres@cisco.com>, 376833@bugs.debian.org, Manuel Prinz <debian@pinguinkiste.de>, Tim Mattox <timattox@open-mpi.org>
Subject: Re: [Pkg-openmpi-maintainers] Bug#376833: Next steps
Date: Thu, 20 Mar 2008 09:17:17 -0400
On Wed, 2008-03-19 at 21:06 -0500, Dirk Eddelbuettel wrote:
> On 19 March 2008 at 20:47, Jeff Squyres wrote:
> | Guess what?  Brian sent a long list of thoughts and a patch for "75%  
> | of the work" to support libatomic-ops in Open MPI (as a backup for  
> | platforms that we don't support with our native assembly).  The  
> | remaining 25% requires access to the platforms that we don't support  
> | -- so perhaps that's appropriate for you guys to tackle...?
> 
> Ok, I guess the ball in our court for that.  We need to round up the porters
> on these architectures.  Now, that doesn't always work as some of those good
> folks are spread thinly (eg I think there at the most two looking after our
> 20,000 packages for the s390...)
> 
> Adam: Any thoughts?  Posts to -devel or the arch lists?

Sounds good.  But let's first get it building with this patch on the
arches we have.
 
> | I put up the information Brian sent on our wiki:
> | 
> |      https://svn.open-mpi.org/trac/ompi/wiki/libatomic-ops

This is a remarkable writeup.  The 32-bit issue is one I pointed out in
a post yesterday morning -- the need for 32-bit operations on platforms
where AO_t is 64 bits, such as 64-bit hppa and s390.  I think the timers
issue should not be hard to address on any of those platforms.

If I can get it to build, I'll let you know.

> | I branched from our SVN trunk and applied his patch -- the SVN URL you  
> | can check out is (it contains his patch):
> | 
> |      https://svn.open-mpi.org/svn/ompi/tmp-public/libatomic-ops

Trouble in paradise.  I checked this out, but in the libatomic-ops
directory, opal/include/opal/sys/atomic.h has:

#elif OMPI_ASSEMBLY_ARCH == OMPI_LIBATOMIC_OPS
#include "opal/sys/libatomic_ops/atomic.h"

But it's not there.  opal/include/opal/sys doesn't have the
libatomic_ops directory at all.  Forgot to check in a directory?

> | Be sure to see our "how to compile OMPI from SVN" page:
> | 
> |      http://www.open-mpi.org/svn/building.php
> | 
> | How does this sound?
> 
> Very helpful, and I hope someone will run with this.  I do not know these
> arches either and cannot drive this, but I will try my best to move it along.

I can work with you on this -- I have a vested interest beyond just
spooles and petsc.  (I'm trying to get a couple of much larger packages
in using OpenMPI...)

> Thanks for the follow-up -- it is greatly appreciated.

Indeed!  I've never seen an upstream crew so responsive to complex
wishlist requests!

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

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





Information forwarded to debian-bugs-dist@lists.debian.org, Debian OpenMPI Maintainers <pkg-openmpi-maintainers@lists.alioth.debian.org>:
Bug#376833; Package openmpi. Full text and rfc822 format available.

Acknowledgement sent to Jeff Squyres <jsquyres@cisco.com>:
Extra info received and forwarded to list. Copy sent to Debian OpenMPI Maintainers <pkg-openmpi-maintainers@lists.alioth.debian.org>. Full text and rfc822 format available.

Message #89 received at 376833@bugs.debian.org (full text, mbox):

From: Jeff Squyres <jsquyres@cisco.com>
To: Adam C Powell IV <hazelsct@debian.org>
Cc: Dirk Eddelbuettel <edd@debian.org>, 376833@bugs.debian.org, Manuel Prinz <debian@pinguinkiste.de>, Tim Mattox <timattox@open-mpi.org>
Subject: Re: [Pkg-openmpi-maintainers] Bug#376833: Next steps
Date: Thu, 20 Mar 2008 09:31:22 -0400
On Mar 20, 2008, at 9:17 AM, Adam C Powell IV wrote:

>> |      https://svn.open-mpi.org/svn/ompi/tmp-public/libatomic-ops
>
> Trouble in paradise.  I checked this out, but in the libatomic-ops
> directory, opal/include/opal/sys/atomic.h has:
>
> #elif OMPI_ASSEMBLY_ARCH == OMPI_LIBATOMIC_OPS
> #include "opal/sys/libatomic_ops/atomic.h"
>
> But it's not there.  opal/include/opal/sys doesn't have the
> libatomic_ops directory at all.  Forgot to check in a directory?

Oops; yes, I missed the "svn add" for this from Brian's patch.  It's  
committed now:

    https://svn.open-mpi.org/trac/ompi/changeset/17892

Sorry about that!

-- 
Jeff Squyres
Cisco Systems





Information forwarded to debian-bugs-dist@lists.debian.org, Debian OpenMPI Maintainers <pkg-openmpi-maintainers@lists.alioth.debian.org>:
Bug#376833; Package openmpi. Full text and rfc822 format available.

Acknowledgement sent to Adam C Powell IV <hazelsct@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian OpenMPI Maintainers <pkg-openmpi-maintainers@lists.alioth.debian.org>. Full text and rfc822 format available.

Message #94 received at 376833@bugs.debian.org (full text, mbox):

From: Adam C Powell IV <hazelsct@debian.org>
To: Jeff Squyres <jsquyres@cisco.com>
Cc: Dirk Eddelbuettel <edd@debian.org>, 376833@bugs.debian.org, Manuel Prinz <debian@pinguinkiste.de>, Tim Mattox <timattox@open-mpi.org>
Subject: Re: [Pkg-openmpi-maintainers] Bug#376833: Next steps
Date: Thu, 20 Mar 2008 09:32:35 -0400
[Message part 1 (text/plain, inline)]
On Thu, 2008-03-20 at 09:31 -0400, Jeff Squyres wrote:

> On Mar 20, 2008, at 9:17 AM, Adam C Powell IV wrote:
> 
> >> |      https://svn.open-mpi.org/svn/ompi/tmp-public/libatomic-ops
> >
> > Trouble in paradise.  I checked this out, but in the libatomic-ops
> > directory, opal/include/opal/sys/atomic.h has:
> >
> > #elif OMPI_ASSEMBLY_ARCH == OMPI_LIBATOMIC_OPS
> > #include "opal/sys/libatomic_ops/atomic.h"
> >
> > But it's not there.  opal/include/opal/sys doesn't have the
> > libatomic_ops directory at all.  Forgot to check in a directory?
> 
> Oops; yes, I missed the "svn add" for this from Brian's patch.  It's  
> committed now:
> 
>      https://svn.open-mpi.org/trac/ompi/changeset/17892
> 
> Sorry about that!


Got it, thanks!

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

Engineering consulting with open source tools
http://www.opennovation.com/
[Message part 2 (text/html, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian OpenMPI Maintainers <pkg-openmpi-maintainers@lists.alioth.debian.org>:
Bug#376833; Package openmpi. Full text and rfc822 format available.

Acknowledgement sent to Adam C Powell IV <hazelsct@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian OpenMPI Maintainers <pkg-openmpi-maintainers@lists.alioth.debian.org>. Full text and rfc822 format available.

Message #99 received at 376833@bugs.debian.org (full text, mbox):

From: Adam C Powell IV <hazelsct@debian.org>
To: Jeff Squyres <jsquyres@cisco.com>
Cc: Dirk Eddelbuettel <edd@debian.org>, 376833@bugs.debian.org, Manuel Prinz <debian@pinguinkiste.de>, Tim Mattox <timattox@open-mpi.org>
Subject: Re: [Pkg-openmpi-maintainers] Bug#376833: Next steps
Date: Thu, 20 Mar 2008 17:51:23 -0400
[Message part 1 (text/plain, inline)]
On Thu, 2008-03-20 at 09:32 -0400, Adam C Powell IV wrote:
> On Thu, 2008-03-20 at 09:31 -0400, Jeff Squyres wrote: 
> > On Mar 20, 2008, at 9:17 AM, Adam C Powell IV wrote:
> > 
> > >> |      https://svn.open-mpi.org/svn/ompi/tmp-public/libatomic-ops
> > >
> > > Trouble in paradise.  I checked this out, but in the libatomic-ops
> > > directory, opal/include/opal/sys/atomic.h has:
> > >
> > > #elif OMPI_ASSEMBLY_ARCH == OMPI_LIBATOMIC_OPS
> > > #include "opal/sys/libatomic_ops/atomic.h"
> > >
> > > But it's not there.  opal/include/opal/sys doesn't have the
> > > libatomic_ops directory at all.  Forgot to check in a directory?
> > 
> > Oops; yes, I missed the "svn add" for this from Brian's patch.  It's  
> > committed now:
> > 
> >      https://svn.open-mpi.org/trac/ompi/changeset/17892
> > 
> > Sorry about that!
> 
> Got it, thanks!

I'm attaching two patches: a new patch 70 (against openmpi 1.2.5) and a
quick patch against debian/ files.  With these, the package builds on
amd64 using its default assembler.

However, it does not build when I force it to use libatomic-ops.  I'm
building by the following procedure: 
      * debian/rules patch-stamp 
      * Remove the section of configure from line 25324 to 25588 (the
        architecture "case" statement), forcing the case to go straight
        to *) which uses libatomic-ops. 
      * debian/rules build

This procedure produces a problematic warning then an error, first the
warning (repeated frequently):

In file included from ../opal/include/opal/sys/atomic.h:124,
                 from ../opal/threads/mutex_unix.h:47,
                 from ../opal/threads/mutex.h:337,
                 from threads/mutex.c:21:
../opal/include/opal/sys/libatomic_ops/atomic.h: In function ‘opal_atomic_cmpset_acq_64’:
../opal/include/opal/sys/libatomic_ops/atomic.h:140: warning: pointer targets in passing argument 1 of ‘AO_compare_and_swap_full’ differ in signedness
../opal/include/opal/sys/libatomic_ops/atomic.h: In function ‘opal_atomic_cmpset_rel_64’:
../opal/include/opal/sys/libatomic_ops/atomic.h:146: warning: pointer targets in passing argument 1 of ‘AO_compare_and_swap_full’ differ in signedness
../opal/include/opal/sys/libatomic_ops/atomic.h: In function ‘opal_atomic_cmpset_64’:
../opal/include/opal/sys/libatomic_ops/atomic.h:152: warning: pointer targets in passing argument 1 of ‘AO_compare_and_swap_full’ differ in signedness
../opal/include/opal/sys/libatomic_ops/atomic.h: In function ‘opal_atomic_add_32’:
../opal/include/opal/sys/libatomic_ops/atomic.h:161: warning: pointer targets in passing argument 1 of ‘AO_int_fetch_and_add_full’ differ in signedness
../opal/include/opal/sys/libatomic_ops/atomic.h: In function ‘opal_atomic_sub_32’:
../opal/include/opal/sys/libatomic_ops/atomic.h:167: warning: pointer targets in passing argument 1 of ‘AO_int_fetch_and_add_full’ differ in signedness
../opal/include/opal/sys/libatomic_ops/atomic.h: In function ‘opal_atomic_add_64’:
../opal/include/opal/sys/libatomic_ops/atomic.h:176: warning: pointer targets in passing argument 1 of ‘AO_fetch_and_add_full’ differ in signedness
../opal/include/opal/sys/libatomic_ops/atomic.h: In function ‘opal_atomic_sub_64’:
../opal/include/opal/sys/libatomic_ops/atomic.h:182: warning: pointer targets in passing argument 1 of ‘AO_fetch_and_add_full’ differ in signedness
In file included from ../opal/include/opal/sys/atomic.h:528,
                 from ../opal/threads/mutex_unix.h:47,
                 from ../opal/threads/mutex.h:337,
                 from threads/mutex.c:21:
../opal/include/opal/sys/atomic_impl.h: In function ‘opal_atomic_trylock’:
../opal/include/opal/sys/atomic_impl.h:346: warning: implicit declaration of function ‘opal_atomic_cmpset_acq_32’

I don't know how severe the signedness issues will be, but am not too
concerned.  The biggest problem is that AO_HAVE_int_compare_and_swap is
not defined (except on ia64 and 32-bit systems), so there is no 32-bit
compare-and-swap operation in libatomic-ops.

The error is related:

libtool: link: gcc -DNDEBUG -Wall -g -O2 -finline-functions -fno-strict-aliasing -pthread -o .libs/opal_wrapper opal_wrapper.o -Wl,--export-dynamic  ../../../opal/.libs/libopen-pal.so -ldl -lnsl -lutil -lm -pthread -Wl,-rpath -Wl,/usr/lib/openmpi/lib
../../../opal/.libs/libopen-pal.so: undefined reference to `opal_atomic_cmpset_acq_32'
collect2: ld returned 1 exit status
make[3]: *** [opal_wrapper] Error 1
make[3]: Leaving directory `/home/hazelsct/openmpi-1.2.5/opal/tools/wrappers'

So the 32-bit compare-and-swap is necessary for this to function.  And
there's no automatic method to do it on 64-bit arches in libatomic-ops,
unlike 32-bit arches which have AO_compare_double_and_swap_double* for
64 bits.

I went ahead and filed wishlist bug 471886 against libatomic-ops-dev for
this purpose.  Can someone test this on a 32-bit arch?  (I don't have a
32-bit system on my 64-bit machine.)

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

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

[libatomic_ops.patch (text/x-patch, attachment)]
[70support_libatomic_ops.dpatch (application/x-shellscript, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian OpenMPI Maintainers <pkg-openmpi-maintainers@lists.alioth.debian.org>:
Bug#376833; Package openmpi. Full text and rfc822 format available.

Acknowledgement sent to Dirk Eddelbuettel <edd@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian OpenMPI Maintainers <pkg-openmpi-maintainers@lists.alioth.debian.org>. Full text and rfc822 format available.

Message #104 received at 376833@bugs.debian.org (full text, mbox):

From: Dirk Eddelbuettel <edd@debian.org>
To: Adam C Powell IV <hazelsct@debian.org>
Cc: Jeff Squyres <jsquyres@cisco.com>, 376833@bugs.debian.org, Manuel Prinz <debian@pinguinkiste.de>, Tim Mattox <timattox@open-mpi.org>
Subject: Re: [Pkg-openmpi-maintainers] Bug#376833: Next steps
Date: Sun, 30 Mar 2008 11:29:36 -0500
Hi guys,

I went out of the country right after Adam posted his last message. Any news
on it since?  Did anybody have time to test on 32bit?  Manuel, could you?  I
am likely to be a bit overwhelmed for next few days...  

But *great* to see momentum on this, and I'd like to both second Adam's
notion of a round of applause to Open MPI -- you guys have been very, very
responsive on this -- and add some thanks to Adam for pushing this.  Either
Manuel or I will follow-up soon, I hope.

Cheers, Dirk

-- 

   I was off email for a few days and am now catching up. 
   My apologies for delayed responses and/or brevity.

--
Three out of two people have difficulties with fractions.




Information forwarded to debian-bugs-dist@lists.debian.org, Debian OpenMPI Maintainers <pkg-openmpi-maintainers@lists.alioth.debian.org>:
Bug#376833; Package openmpi. Full text and rfc822 format available.

Acknowledgement sent to Adam C Powell IV <hazelsct@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian OpenMPI Maintainers <pkg-openmpi-maintainers@lists.alioth.debian.org>. Full text and rfc822 format available.

Message #109 received at 376833@bugs.debian.org (full text, mbox):

From: Adam C Powell IV <hazelsct@debian.org>
To: Dirk Eddelbuettel <edd@debian.org>
Cc: Jeff Squyres <jsquyres@cisco.com>, 376833@bugs.debian.org, Manuel Prinz <debian@pinguinkiste.de>, Tim Mattox <timattox@open-mpi.org>
Subject: Re: [Pkg-openmpi-maintainers] Bug#376833: Next steps
Date: Sun, 30 Mar 2008 15:31:02 -0400
[Message part 1 (text/plain, inline)]
Hi,

On Sun, 2008-03-30 at 11:29 -0500, Dirk Eddelbuettel wrote:
> Hi guys,
> 
> I went out of the country right after Adam posted his last message. Any news
> on it since?  Did anybody have time to test on 32bit?  Manuel, could you?  I
> am likely to be a bit overwhelmed for next few days...

I tried this on IA32 last Monday, and it failed, because there is no
AO_compare_and_swap function on IA32.  (The libatomic-ops headers can
put together AO_int_compare_and_swap* prototypes from this if it's
there, but it's not.)

In the meantime, I had to modify atomic.h to the attached in order to
get the 64-bit functions to compile on 32-bit.

I filed wishlist bug 471886 against libatomic-ops-dev, which Ian Wienand
requested that I take upstream to the Boehm garbage collector, which is
the caconical source for this package:

http://www.hpl.hp.com/personal/Hans_Boehm/gc/
gc@linux.hpl.hp.com

I have not had time to request either the 64-bit int ops, nor the 32-bit
compare-and-swap (or fetch-and-add on other arches) on that list.

Of course, we could always push the OpenMPI cmpset functions up to
libatomic-ops, but that doesn't help us on the arches we lack. :-(

It occurred to me that we need some subtests within the libatomic-ops
test in ompi-config-asm.m4 to probe for the specific functions needed...

I'll put more time into this as soon as I can, but that may be a week or
more away.

> But *great* to see momentum on this, and I'd like to both second Adam's
> notion of a round of applause to Open MPI -- you guys have been very, very
> responsive on this --

Hear, hear!

> and add some thanks to Adam for pushing this.  Either
> Manuel or I will follow-up soon, I hope.

Thanks.  I'll do what I can as soon as I can...

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

Engineering consulting with open source tools
http://www.opennovation.com/
[atomic.h (text/x-chdr, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian OpenMPI Maintainers <pkg-openmpi-maintainers@lists.alioth.debian.org>:
Bug#376833; Package openmpi. Full text and rfc822 format available.

Acknowledgement sent to Manuel Prinz <debian@pinguinkiste.de>:
Extra info received and forwarded to list. Copy sent to Debian OpenMPI Maintainers <pkg-openmpi-maintainers@lists.alioth.debian.org>. Full text and rfc822 format available.

Message #114 received at 376833@bugs.debian.org (full text, mbox):

From: Manuel Prinz <debian@pinguinkiste.de>
To: Dirk Eddelbuettel <edd@debian.org>
Cc: Adam C Powell IV <hazelsct@debian.org>, Jeff Squyres <jsquyres@cisco.com>, 376833@bugs.debian.org, Tim Mattox <timattox@open-mpi.org>
Subject: Re: [Pkg-openmpi-maintainers] Bug#376833: Next steps
Date: Mon, 31 Mar 2008 14:14:07 +0200
Hi everyone!

Am Sonntag, den 30.03.2008, 11:29 -0500 schrieb Dirk Eddelbuettel:
> I went out of the country right after Adam posted his last message. Any news
> on it since?  Did anybody have time to test on 32bit?  Manuel, could
> you?  I am likely to be a bit overwhelmed for next few days...

Sorry for stepping in late. Hardware breakage and holidays kept me from
following the discussion. Both are "fixed" now. ;)

I'll try to re-read the discussion because I just had a quick glace at
it. I'll try to build on 32 bit but (unfortunately) I do not have access
to native i386 anymore. I have used an i386 chroot with no problems in
the past, so I think this will work out as well.

> But *great* to see momentum on this, and I'd like to both second Adam's
> notion of a round of applause to Open MPI -- you guys have been very, very
> responsive on this -- and add some thanks to Adam for pushing this.

Seconded! :)

> Either Manuel or I will follow-up soon, I hope.

I'm not very experienced with this but I'll give it a try. I'll follow
up later.

Best regards
Manuel





Tags added: help Request was from Manuel Prinz <debian@pinguinkiste.de> to control@bugs.debian.org. (Tue, 26 Aug 2008 11:24:05 GMT) Full text and rfc822 format available.

Tags added: confirmed Request was from Manuel Prinz <debian@pinguinkiste.de> to control@bugs.debian.org. (Tue, 26 Aug 2008 11:42:04 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Debian OpenMPI Maintainers <pkg-openmpi-maintainers@lists.alioth.debian.org>:
Bug#376833; Package openmpi. (Sat, 04 Apr 2009 20:24:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Riku Voipio <riku.voipio@iki.fi>:
Extra info received and forwarded to list. Copy sent to Debian OpenMPI Maintainers <pkg-openmpi-maintainers@lists.alioth.debian.org>. (Sat, 04 Apr 2009 20:24:02 GMT) Full text and rfc822 format available.

Message #123 received at 376833@bugs.debian.org (full text, mbox):

From: Riku Voipio <riku.voipio@iki.fi>
To: 376833@bugs.debian.org, 471886@bugs.debian.org
Subject: openmpi/libatomic-ops status?
Date: Sat, 4 Apr 2009 23:17:39 +0300
Hi,

If I understand correctly, libatomic-ops was found not completly
adequate for openmpi? Was this information passed to libatomic-ops
upstream (which is boehm gc?).

-- 
"rm -rf" only sounds scary if you don't have backups




Information forwarded to debian-bugs-dist@lists.debian.org, Debian OpenMPI Maintainers <pkg-openmpi-maintainers@lists.alioth.debian.org>:
Bug#376833; Package openmpi. (Sat, 04 Apr 2009 20:57:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Manuel Prinz <debian@pinguinkiste.de>:
Extra info received and forwarded to list. Copy sent to Debian OpenMPI Maintainers <pkg-openmpi-maintainers@lists.alioth.debian.org>. (Sat, 04 Apr 2009 20:57:03 GMT) Full text and rfc822 format available.

Message #128 received at 376833@bugs.debian.org (full text, mbox):

From: Manuel Prinz <debian@pinguinkiste.de>
To: Riku Voipio <riku.voipio@iki.fi>, 376833@bugs.debian.org
Cc: 471886@bugs.debian.org
Subject: Re: [Pkg-openmpi-maintainers] Bug#376833: openmpi/libatomic-ops status?
Date: Sat, 04 Apr 2009 22:55:25 +0200
[Message part 1 (text/plain, inline)]
Hi Riku!

Am Samstag, den 04.04.2009, 23:17 +0300 schrieb Riku Voipio:
> If I understand correctly, libatomic-ops was found not completly
> adequate for openmpi? Was this information passed to libatomic-ops
> upstream (which is boehm gc?).

We passed it to upstream a while ago. There was some preliminary patch
which added some support to it but that was never finished or updated. I
wanted to have a closer look at it once the other bugs are fixed and the
transition is done. But it is currently not very high on my TODO list. 

If you can offer some help I would be very happy. Most of the work done
so far should have references in the bug reports and/or the team mailing
list. I can dig that out for you, if you like to. But it will be a few
weeks until I can work on that.

Best regards
Manuel
[signature.asc (application/pgp-signature, inline)]

Send a report that this bug log contains spam.


Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Fri Apr 18 21:18:39 2014; Machine Name: buxtehude.debian.org

Debian Bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.