Dear maintainer(s),

With a recent upload of mpich and openmpi the autopkgtest of netgen
fails in testing when that autopkgtest is run with either the binary
packages of mpich or openmpi from unstable. It passes when run with only
packages from testing. In tabular form:

                        pass            fail
mpich                  from testing    5.0.2-1
netgen                 from testing    6.2.2606+dfsg1-1
all others             from testing    from testing

I copied some of the output at the bottom of this report. The
autopkgtest actually doesn't fail because the test fails, but because
there is a deprecation warning on stderr. If you don't care about output
to stderr in the future, you can add the allow-stderr restriction to the
tests.

Currently this regression is blocking the migration of mpich to testing
[1]. Of course, mpich shouldn't just break your autopkgtest (or even
worse, your package), but it seems to me that the change in mpich was
intended and your package needs to update to the new situation.

If this is a real problem in your package (and not only in your
autopkgtest), the right binary package(s) from mpich should really add a
versioned Breaks on the unfixed version of (one of your) package(s).
Note: the Breaks is nice even if the issue is only in the autopkgtest as
it helps the migration software to figure out the right versions to
combine in the tests.

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=mpich

https://ci.debian.net/data/autopkgtest/testing/arm64/n/netgen/76265643/log.gz


260s 260s =============== 214 passed, 114 skipped, 9 deselected in
45.84s ================
261s 261s 261s Run MPI python test
261s ************************************************
261s We have detected that the runtime version
261s of the PMIx library we were given is binary
261s incompatible with the version we were built against:
261s 261s     Runtime: 0x70000
261s     Build:   0x50009
261s 261s Please update your LD_LIBRARY_PATH to point
261s us to the same PMIx version used to build PRRTE.
261s ************************************************
261s autopkgtest [17:35:21]: test netgen-test-python

Hi,
I am not fully sure why this has been filed against src:netgen. To me, it seems
that there is nothing we can do from here.

The error message clearly says that it is due to some incompatibility between
PMIx and PRRTE. A similar bug #1147135 is even open with Package: src:prrte and
Affects: src:pmix, with basically the same error message.

The same error message appears in debci runs for src:mpi4py, src:petsc, src:dolfin,
src:fenics-dolfinx, which we co-mantain. It's quite clear IMHO that this is an
issue with the MPI libraries rather than with the end user ones.

Finally, I can't seem to remember how the "Issues preventing migration" part is
being automatically generated by britney, but it looks very odd in
https://tracker.debian.org/pkg/openmpi .
For instance: dolfin, fenics-dolfinx and scifem are being tested with
autopkgtest, but e.g. PETSc and mpi4py (which also rely on the MPI libraries,
and which are runtime dependencies of each of the three packages mentioned above)
are not being tested at all. This means if there was an issue in PETSc, it would
only be discovered through e.g. dolfin, and one may not even realize at first
glance that the issue is not in dolfin but in PETSc.
The list reported in https://tracker.debian.org/pkg/mpich is much more complete.

Thanks,
Francesco

Hi Francesco,


I think I've made a mistake somewhere as I recall seeing an other error
than the one I included in my bug report. That issue is indeed tracked
in bug 1147135.

Indeed, I was thinking of the message I saw in [1]:

290s autopkgtest [09:05:30]: test netgen-test-python:  - - - - - - - - -
- stderr - - - - - - - - - -
290s
--------------------------------------------------------------------------
290s A deprecated MCA variable value was specified in the environment or
290s on the command line.  Deprecated MCA variables should be avoided;
290s they may disappear in future releases.
290s
290s   Deprecated variable: schizo_proxy
290s   New variable:        personality
290s
--------------------------------------------------------------------------
290s
--------------------------------------------------------------------------
290s A deprecated MCA variable value was specified in the environment or
290s on the command line.  Deprecated MCA variables should be avoided;
290s they may disappear in future releases.
290s
290s   Deprecated variable: rmaps_default_mapping_policy
290s   New variable:        mapby
290s
--------------------------------------------------------------------------

[1] https://ci.debian.net/packages/n/netgen/testing/amd64/76309948/


I didn't check the above, but we only test direct reverse (test)
dependencies. Might that explain the situation? If they need to run when
an indirect dependency gets updated, the autopkgtest spec [2] mentions
the hint-testsuite-triggers restriction.

Paul

[2]
https://salsa.debian.org/ci-team/autopkgtest/-/blob/master/doc/README.package-tests.rst?ref_type=heads

Hi Paul,
I prepared a new upload that fixes
  Deprecated variable: rmaps_default_mapping_policy
  New variable:        mapby
using the new variable name.

The part about schizo_proxy/personality is tracked by #1148924, and in unrelated
to the way openmpi is configured within netgen tests.

Cheers,
Francesco

I think the problem was fixed in OpenMPI 6