Source: flatpak Version: 1.18.0-1 Severity: important X-Debbugs-Cc: [email protected], [email protected] User: [email protected] Usertags: amd64 Tags: ftbfs unreproducible help
flatpak_1.18.0-1 compiled successfully on the first attempt on all of the official buildds (all architectures) and on reproduce.debian.net (all architectures except amd64), but its build-time tests failed on reproduce.debian.net on amd64: https://reproduce.debian.net/amd64/api/v1/builds/261317/log >flatpak:test-auth.sh time out (After 90.0 seconds) >47/63 flatpak:test-auth.sh TIMEOUT >90.55s killed by signal 15 SIGTERM > >flatpak:test-preinstall.sh time out (After 90.0 seconds) >58/63 flatpak:test-preinstall.sh TIMEOUT >90.28s killed by signal 15 SIGTERM The log sections for those two tests don't show anything obviously wrong, until SIGTERM is received and cleanup starts. On the official amd64 buildd, the whole of test-auth.sh took 8.31 seconds. On reproduce.debian.net, test-auth.sh started at 7:13:09 and successfully completed 1 out of 3 sub-tests ("installed build-exported token-type app") shortly after 07:13:51, meaning about 42 seconds to complete 1 out of 3 sub-tests - that seems quite dramatically slower for a test that ought to be mostly I/O-bound. Based on this, I suspect the test might have passed if it had been given an arbitrarily large timeout. Similarly test-preinstall.sh seems to have still been making forward progress on the first of 12 sub-tests about a minute after it started (that's the last timestamp I can immediately see in its log), compared with having only taken 12.13 seconds in total for all 12 sub-tests on the official amd64 buildd. Obviously I can increase arbitrary timeouts if I have to (and non-x86 architectures already have a much longer timeout), but it seems unexpected that test-auth.sh took more than 10x as long as it did on the official amd64 buildd. For comparison, test-auth.sh and test-preinstall.sh both took about a minute on an official *riscv64* buildd, and the riscv64 buildds have been noted to be slow enough to be causing practical problems. The upstream default (from Meson) is that "most" tests are allowed 30 seconds to run and then killed, with a few exceptions where the timeout is extended for particularly slow tests. On x86 the Debian packaging multiplies timeouts by 3 (90s for most tests, scaling up appropriately for particularly slow ones), and on non-x86 it multiplies timeouts by 20 (10 minutes for most tests). I'm reluctant to increase the timeout excessively on x86, because Flatpak's test suite (like many test-suites) is rather complicated, and if one of the tests genuinely gets stuck (no longer making forward progress), having it block for multiple minutes before giving up is an unwelcome debugging experience. Can reproduce.debian.net jobs be retried, to see whether this might be a one-off glitch? Are reproduce.debian.net amd64 machines known to be significantly (orders of magnitude!) slower than official amd64 buildds, or my laptop, or even riscv64 buildds? Or does reproduce.debian.net perhaps parallelize builds of unrelated packages on the same machine, which might have caused the tests to be extra-slow? I also wonder whether running the build-time test-suite is necessary for reproduce.debian.net's goals: if we're trying to prove that the binaries in the archive are genuine, it seems to me that a build with the nocheck option would be sufficient for demonstrating that. Obviously test-suites that don't always work are a bug, but perhaps that's orthogonal to whether an existing package can be reproduced? Thanks, smcv
