Dear maintainer(s), Your package has an autopkgtest, great. However, it fails on armel. What's worse, it fails because it seems to hang and eventually times out due to autopkgtest. Can you please investigate the situation and fix it? I copied some of the output at the bottom of this report. Tests that time out (while normally running in much less time) are bad for our infrastructure. I have added your package to our reject_list on armel and will remove it once this bug is closed. More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [1] https://lists.debian.org/debian-devel-announce/2019/07/msg00002.html https://ci.debian.net/packages/c/cp2k/ https://ci.debian.net/data/autopkgtest/testing/armel/c/cp2k/26510840/log.gz Running MC_QS_cluster.inp >>> /tmp/autopkgtest-lxc._uoweqoc/downtmp/build.l8C/src/tools/regtesting/../..//TEST-Linux-armv8l-gfortran-psmp-2022-09-28_01-25-33/tests/MC/regtest MC_QS.inp -51.34794469 OK ( 31.92 sec) MC_QS_restart.inp -51.34909000 OK ( 38.61 sec) GEMC_NpT_box1.inp 0.49826574 OK ( 5.68 sec) GEMC_NVT_box1.inp 0.49803069 OK ( 5.25 sec) GEMC_swap_box1.inp 0.55872200 OK ( 9.25 sec) canonical.inp 0.55333815 OK ( 0.94 sec) canonical_bias.inp 0.38566238 OK ( 3.88 sec) virial.inp -.723498E+03 OK ( 3.35 sec) hmc.inp KILLED MC_QS_cluster.inp -123.50157228768187 KILLED <<< /tmp/autopkgtest-lxc._uoweqoc/downtmp/build.l8C/src/tools/regtesting/../..//TEST-Linux-armv8l-gfortran-psmp-2022-09-28_01-25-33/tests/MC/regtest (9 of 53) done in 551.00 sec Starting regression tests in /tmp/autopkgtest-lxc._uoweqoc/downtmp/build.l8C/src/tools/regtesting/../..//TEST-Linux-armv8l-gfortran-psmp-2022-09-28_01-25-33/tests/QS/regtest-ri-mp2 (10 of 53) Running RI_MP2_H2O.inp autopkgtest [04:12:14]: ERROR: timed out on command [...]
I think both paragraphs are wrong for cp2k... It is not normally running in much less time, the faster runs are failures for actual breakage (the last one in unstable that still has a test log was some openmpi/pmix breakage). I am not convinced that it actually hangs, I would guess your timeout is just too low. Running FPU-heavy code without FPU is slow. https://buildd.debian.org/status/logs.php?pkg=cp2k&arch=armhf https://buildd.debian.org/status/logs.php?pkg=cp2k&arch=armel This is build time (which should be similar on armel and armhf) plus test time, where an order of magnitude difference between armhf and armel is expected for FPU-heavy code. Could you try setting the timeout to 10 hours for cp2k on armel? I'd be optimistic that this will result in a pass. cu Adrian
Hi Paul, I guess that was supposed to be 9.1-2, as that is (was) current and the log you referenced also has that. I agree with Adrian and downgraded this bug to important for now. Michael
Hi, We don't have that flexibility. If the test can't run in a reasonable time (below 2:47h per stanza in d/t/control) on armel, please skip the test on armel until the infrastructure grows that option. Paul
Hi, We don't support armel in Debian anymore in unstable/forky, so let's consider this bug done. Paul