Hi Maintainer

Since the upload of mpi-defaults 1.17, the autopkgtests of parmetis
have regressed on 32-bit architectures [1]:  I've copied what I hope
is the relevant part of the log below.

Regards
Graham


[1] https://ci.debian.net/packages/p/parmetis/testing/armhf/


42s autopkgtest [23:35:46]: test build1: [-----------------------
44s build: OK
44s [proxy:0@ci-243-6e53447b] HYDU_create_process
(lib/utils/launch.c:73): execvp error on file LL_parmetis (No such
file or directory)
44s [proxy:0@ci-243-6e53447b] HYDU_create_process
(lib/utils/launch.c:73): execvp error on file LL_parmetis (No such
file or directory)
44s [proxy:0@ci-243-6e53447b] HYDU_create_process
(lib/utils/launch.c:73): execvp error on file LL_parmetis (No such
file or directory)
44s [proxy:0@ci-243-6e53447b] HYDU_create_process
(lib/utils/launch.c:73): execvp error on file LL_parmetis (No such
file or directory)
44s autopkgtest [23:35:48]: test build1: -----------------------]

Hi,

The armhf failure is because mpich's mpirun (hydra) does not look for the
program in the current directory, so "mpirun -np 4 LL_parmetis" fails with
"execvp error on file LL_parmetis". Running "./LL_parmetis" fixes it; I
checked with mpich 5.0.1, where a bare program name fails exactly like
this and "./" works.

The test has a second problem with OpenMPI 5 on 64-bit architectures:
OpenMPI 5 ignores the OMPI_MCA_* variables the test sets, so on machines
with fewer than 4 cores it fails with "There are not enough slots
available in the system to satisfy the 4 slots". Setting the PRRTE
equivalents fixes it:

  export PRTE_MCA_plm_ssh_agent=/bin/false
  export PRTE_MCA_rmaps_default_mapping_policy=:oversubscribe

I kept the old variables so the test still works with OpenMPI 4.

With both changes, the test passes on a 2-CPU Ubuntu stonking container
with OpenMPI 5.0.10 and fails without them. I have not tested with the
OpenMPI 6.0 release candidate in unstable.

The attached debdiff against 4.0.3-7 changes only debian/tests/build1.

Regards,
Sebastien