Control: reassign -1 src:openmpi Control: found -1 openmpi/4.1.1-3 Control: tags -1 +unreproducible +help Control: retitle -1 openmpi breaks gyoto autopkgtest on i386 Control: thanks
Hi, I cannot reproduce this. I have set up a testing-i386 chroot (on my amd64 laptop) and installed openmpi from unstable (I also tried with mpi4py from unstable on top), as well as their versionned dependencies not in testing: libopenmpi-dev 4.1.1-5 libopenmpi3 4.1.1-5 openmpi-common 4.1.1-5 python3-mpi4py 3.0.3-10 I tried with gyoto from unstable (1.4.4-4) and from testing (1.4.4-3). Note that this is apparently different from what the debci infrastructure does (apparently recompiling instead of taking the binaries). I then ran the test from this chroot (as sbuild user): autopkgtest -B --test-name=gyoto-mpi -- null The test PASSED each time. I note that the test suite can take a long time to run and that the final line in the failure log for this test reads: mpirun.openmpi noticed that process rank 1 with PID 0 on node ci-262-d8ad913b exited on signal 9 (Killed). This happens after this test has been running for 1h and 55min. Could it be that the process is killed because of a timeout in the test environment? In the one hand it would feel strange because, on the debci infrastucture, the error always happens on the same file (example-startrace), near the beginning of the process (row 1/32). On the other hand I know this file is one of the longest to process (still below a couple of minutes on my laptop). Anyway, there's not much more I can do, except skip this test. I'm reassigning to openmpi because, on the debci infrastructure, the same failure occurs with openmpi/unstable also with mpi4py/testing. Advice welcome. Regards, Thibaut.
smime.p7s
Description: Signature cryptographique S/MIME
