Dear maintainer(s),

I looked at the results of the autopkgtest of your package because it
was marked as regression for setuptools. I noticed that it regularly
fails. I scheduled 5 tests on i386 and it failed 4 times [1]. It seems
the test has an internal timeout (great), but it seems to short for our
infrastructure [2].

Because the unstable-to-testing migration software now blocks on
regressions in testing, flaky tests, i.e. tests that flip between
passing and failing without changes to the list of installed packages,
are causing people unrelated to your package to spend time on these
tests.

Don't hesitate to reach out if you need help and some more information
from our infrastructure.

Paul

[1] https://ci.debian.net/packages/p/pytest-mpi/testing/i386/

[2] https://ci.debian.net/packages/p/pytest-mpi/testing/i386/77422587/

734s =================================== FAILURES
===================================
734s _______________________________ test_mpi_tmpdir

Hello Francesco.

I have been looking at this. In summary:

- On i386, autopkgtests fail because they reach a timeout of 60 seconds.
- On loong64, autopkgtests fail because they reach a timeout of 5 seconds.

I also see that this patch which you wrote:

debian/patches/default_timeout_as_env_var.patch

conflates values which were hardcoded at 60 seconds with values which
were hardcoded at 5 seconds, so it may be the case that the patch is
actually *reducing* the timeout from 60 to 5 seconds in some cases.

Do you have an idea of how would you like to fix this?

Thanks.