Bug#1120424: pmix: tests fail due to default foreign tool support

Drew Parsons dparsons at debian.org
Sun Nov 9 09:34:58 GMT 2025


Source: pmix
Version: 6.0.0+really5.0.9-1.1
Severity: serious
Justification: FTBFS
Control: block 1120413 by -1
Control: forwarded -1 https://github.com/openpmix/openpmix/issues/3717

I filed Bug#1120413 against scotch (and pmix upstream Issue#3717)
since ptscotch tests started failing with pmix 5.0.9. They give an
error message like

test 50
        Start  50: test_scotch_dgraph_coarsen_bump

50: Test command: /usr/bin/mpiexec "-n" "3" "/build/reproducible-path/scotch-7.0.10/obj-x86_64-linux-gnu/src/check/test_scotch_dgraph_coarsen" "/build/reproducible-path/scotch-7.0.10/src/check/data/bump.grf"
50: Working Directory: /build/reproducible-path/scotch-7.0.10/obj-x86_64-linux-gnu/src/check
50: Test timeout computed to be: 10000000
50: --------------------------------------------------------------------------
50: You requested support for remote tool connections, but no non-loopback
50: interfaces were found after applying any include or exclude directives:
50: 
50:   Include:    NULL
50:   Exclude:    NULL
50:   Available:  lo
50: 
50: Please adjust your include or exclude to allow selection of a
50: non-loopback interface.
50: --------------------------------------------------------------------------
 67/155 Test  #50: test_scotch_dgraph_coarsen_bump ................................................***Failed    0.02 sec


As far as I can see this is happening because pmix 5.0.9 switched to
activate foreign (remote) tool support be default, which fails in a
chroot environment when only the loopback interface lo is available.

The change was made in pmix upstream in PR#3674 (commit ab85e1a).

I'm not sure what the best way to resolve the problem is.
It seems likely there is a PMIX_MCA_ environment variable to
deactivate the setting for foreign tool support. If so, we can just
use it in debian scripts just as we already use other OMPI_ variables
to control runtime in our buildd and debci chroots. But I don't know
what the name of the variable is.

If appropriate, we could instead configure the pmix package to revert
back to the previous state not activating foreign tool support by
default.  This would be smoother on the client packages, but I imagine
upstream had a reason for activating it by default. I guess they will
advise soon in issue #3717.

In the meantime I'm filing this bug against pmix with severity serious
to prevent migration of 5.0.9 to testing, pending further discussion.



More information about the debian-science-maintainers mailing list