openmpi/python-related problems in epel7 ppc buildroot

[Dave Love]

Orion Poplawski <orion at cora.nwra.com> writes:

> On 08/19/2015 06:20 AM, Dave Love wrote:
>> Orion Poplawski <orion at cora.nwra.com> writes:
>> 
>>> On 08/18/2015 09:21 AM, Dave Love wrote:
>>>> I'm trying to build a new package.  It's failing on epel-7-ppc64le
>>>> (only) with two sorts of errors in %check which appear to be problems
>>>> with the build root, e.g.
>>>> <https://koji.fedoraproject.org/koji/taskinfo?taskID=10740549>.  One is
>>>> from openmpi of a sort I don't recognize but which looks like an
>>>> installation problem:
>>>>
>>>>   [buildppc-01.phx2.fedoraproject.org:62215] [[INVALID],INVALID] ORTE_ERROR_LOG: Not found in file ess_hnp_module.c at line 170
>>>
>>> I would ask on the openmpi list.
>> 
>> Do you mean it's up to me to debug it?  I don't think it's reasonable to
>> try to without direct access to the buildroot, and I wouldn't be able to
>> fix it anyhow.
>
> Who else is it going be up to?  :)

It doesn't seem reasonable for someone who just wants to push a package
to debug the buildroot, just by submitting build requests, and then try
to get someone to fix it.  [Obviously I was getting mixed up with
different things in fedora and epel7, for which the openmpi maintainer
is presumably Red Hat.]

> BTW - I think it's ppc64, not ppc64le.
> See
> https://fedoraproject.org/wiki/Architectures/PowerPC#PPC_Shell_access_for_debugging
> for access to ppc64 hardware for testing.

If you mean that the openmpi package is just broken in epel7-ppc64, then
presumably we should just exclude it from packaging.

> I'm happy to help out as well, but
> first I would get the openmpi folks take on it.  They are very helpful.

I know the sort of thing they'll say, and if it was happening on a
system I adminned, I'd just debug it, but then I'd have proper access.

In case it's not clear,

  %_openmpi_load
  mpirun -np 1 date

fails because the orted won't start, as above
<https://koji.fedoraproject.org/koji/getfile?taskID=10766333&name=build.log&offset=-4000>.
It isn't a problem for any other target as far as I can tell.