*05:12:10* more information, such as the ld(1) and ld.so(8) manual pages.
*05:12:10*
--
*05:12:10* make[3]: Leaving directory
`/scrap/jenkins/workspace/hpc-ompi-shmem/label/r-vmb-centos5-u7-x86-64/ompi/mca/btl/vader'
*05:12:10*
Folks,
i commited 248acbbc3ba06c2bef04f840e07816f71f864959 in order to fix a
hang in coll/ml
when using srun (both pmi1 and pmi2)
could you please git it a try ?
Cheers,
Gilles
On 2014/10/22 23:03, Joshua Ladd wrote:
> Privet, Artem
>
> ML is the collective component that is invoking the calls
Mike,
the root cause is vader was not fully backported to v1.8
(two OPAL_* macros were not backported to OMPI_*)
i fixed it in https://github.com/open-mpi/ompi-release/pull/49
please note a similar warning is fixed in
https://github.com/open-mpi/ompi-release/pull/48
Cheers,
Gilles
On 2014/10/
Ralph and George,
i just made PR 249 https://github.com/open-mpi/ompi/pull/249
this fixes heterogeneous support for the master by moving the jobid,vpid
from the ORTE down to the OPAL layer.
this required to add the OPAL_NAME dss type in order to correctly convert
an opal_process_name_t on an hete
I already fixed this immediately after it was detected. We don't want to
backport the opal changes that occurred when we moved the BTLs down to OPAL.
All that was required was to rename opal_process_info back to ompi_process_info
Mike: these stale Jenkins reports are causing people to waste time
sure,
was it fixed in the master only or in the origin/v1,8 as well?
On Thu, Oct 23, 2014 at 3:57 PM, Ralph Castain wrote:
> I already fixed this immediately after it was detected. We don't want to
> backport the opal changes that occurred when we moved the BTLs down to
> OPAL. All that was requ
My bad - I see what Gilles is talking about. Still need to figure out a way to
avoid these commit-by-commit complaints when later commits already fixed the
problem. Isn't there some way to educate Jenkins to avoid it?
> On Oct 23, 2014, at 5:57 AM, Ralph Castain wrote:
>
> I already fixed thi
but fix was in the master
jenkins complained about v1.8 where fix is not present.
do I miss something?
On Thu, Oct 23, 2014 at 4:01 PM, Ralph Castain wrote:
> My bad - I see what Gilles is talking about. Still need to figure out a
> way to avoid these commit-by-commit complaints when later commi
Yes - I fixed it in v1.8 immediately after the nightly tarball failed to build.
So telling us it -was- broken is a stale report - a subsequent Jenkins run
would show it as fixed.
> On Oct 23, 2014, at 6:07 AM, Mike Dubman wrote:
>
> but fix was in the master
> jenkins complained about v1.8 wh
