Re: [OMPI devel] Update SLURM FAQ entry?

2014-04-15 Thread Anthony Alba
Sure - how about this: 2. Yes, if you have configured OMPI --with-pmi=foo, where foo is the path to the directory where pmi.h/pmi2.h is located. Slurm (> 2.6, > 14.03) installs PMI-2 support by default. Older versions of Slurm install PMI-1 by default. If you desire PMI-2, Slurm requires that

Re: [OMPI devel] .gitignore_global and .hgignore_global

2014-04-15 Thread Ralph Castain
Thanks Jeff!! On Tue, Apr 15, 2014 at 3:27 PM, Jeff Squyres (jsquyres) wrote: > All -- > > See https://svn.open-mpi.org/trac/ompi/changeset/31408. > > There's now a cron script running at IU that will keep svn:ignore > properties in sync with .gitignore_global and .hgignore_global. It's > cu

[OMPI devel] .gitignore_global and .hgignore_global

2014-04-15 Thread Jeff Squyres (jsquyres)
All -- See https://svn.open-mpi.org/trac/ompi/changeset/31408. There's now a cron script running at IU that will keep svn:ignore properties in sync with .gitignore_global and .hgignore_global. It's currently running at 1am US Eastern time (that time was picked pretty arbitrarily). Begin forw

[OMPI devel] Open MPI developer's meeting: June 24-26

2014-04-15 Thread Jeff Squyres (jsquyres)
We decided on the call today to have the developer meeting from 9am (US Central time) on Tuesday, June 24 through early afternoon on Thursday, June 26. We're assuming everyone will travel to Chicago on Monday, and then can fly out either Thursday afternoon or Friday morning. Please sign up on t

Re: [OMPI devel] [EXTERNAL] Build failures from r31393: opal atomics

2014-04-15 Thread Jeff Squyres (jsquyres)
Perfect -- thanks! On Apr 15, 2014, at 11:36 AM, "Grant, Ryan Eric (-EXP)" wrote: > Jeff, > > Ack, sorry. I've grouped the built-in atomics into a family 020x as > discussed. I've also got the built-ins renamed as OMPI_BULTIN_name. Commit > is coming up soon. > > --Ryan > > On 4/15/14 8:57 A

Re: [OMPI devel] RFC: move sensor framework to ORCM

2014-04-15 Thread Ralph Castain
Crud - we missed this on today's telecon. Any last words on this subject? Otherwise, I'll move this framework later today. Ralph On Apr 7, 2014, at 7:53 AM, Ralph Castain wrote: > What: move the sensor framework from ORTE to the ORCM code repo, essentially > "svn delete" it from the OMPI cod

Re: [OMPI devel] [EXTERNAL] Build failures from r31393: opal atomics

2014-04-15 Thread Grant, Ryan Eric (-EXP)
Jeff, Ack, sorry. I've grouped the built-in atomics into a family 020x as discussed. I've also got the built-ins renamed as OMPI_BULTIN_name. Commit is coming up soon. --Ryan On 4/15/14 8:57 AM, "Jeff Squyres (jsquyres)" wrote: >Ryan -- > >I'm getting build failures with this: > >- >make[1

[OMPI devel] Build failures from r31393: opal atomics

2014-04-15 Thread Jeff Squyres (jsquyres)
Ryan -- I'm getting build failures with this: - make[1]: Entering directory `/home/jsquyres/svn/ompi5/openmpi-1.9a1r31394M/_build/opal/asm' CC asm.lo In file included from ../../../opal/asm/asm.c:21: ../../../opal/include/opal/sys/atomic.h:144:7: error: invalid digit "8" in octal co

Re: [OMPI devel] Update SLURM FAQ entry?

2014-04-15 Thread Jeff Squyres (jsquyres)
Would you mind sending us updated text? I don't know if any of us follows the SLURM releases closely... (I assume you're referring specifically to question 4, right?) On Apr 11, 2014, at 11:42 PM, Anthony Alba wrote: > Is it time to update the SLURM FAQ entry? > > 1. SLURM 2.6.9 and 14.03

Re: [OMPI devel] configure fails on the trunk since r31390

2014-04-15 Thread Mike Dubman
fixed in r31392 sorry about that. On Tue, Apr 15, 2014 at 8:11 AM, Ralph Castain wrote: > Hi Gilles > > There really isn't any need to open tickets when things like this happen. > A simple note to devel is usually considered adequate. The problem will > either be repaired by the responsible org

Re: [OMPI devel] configure fails on the trunk since r31390

2014-04-15 Thread Ralph Castain
Hi Gilles There really isn't any need to open tickets when things like this happen. A simple note to devel is usually considered adequate. The problem will either be repaired by the responsible organization when they return to work, or we will revert the offending commit if the fix is going to