Hilmar Preusse <[email protected]> writes: > Source: guile-fibers > Version: 1.4.2-4 > Severity: important > Tags: ftbfs > > Dear Maintainer, > > The new TeX Info 7.3 is around the corner and sooner or later I will upload > to unstable. The current pre-releases are sitting in experimental. > During a test build of your package using TI 7.3 we noticed that the build > hangs in the dh_auto_test stage (build log is attached). This does not > happen when TI 7.2 is used. > > I had to ^C the running process: /usr/bin/guile-3.0 --no-auto-compile -s > ./tests/basic.scm > > An strace did not show action on the process in question any more.
How could that happen? Quoting debian/rules:
override_dh_auto_test:
-timeout --verbose --kill-after=1m 15m \
dh_auto_test $(DH_BUILD_OPTS)
timeout --verbose --kill-after=1m 15m \
dh_auto_test $(DH_BUILD_OPTS) -- TESTS="tests/basic.scm"
Is 'timeout' not killing the process after max 15 minutes?
Wouldn't that be a bug in timeout or the kernel?
Running guile library self tests in the debci infrastructure seems like
an never ending source of problem, as I've now seen similar problems be
reported multiple times for multiple guile-* projects. I think this
suggest some deep flaky issue with the Guile run-time. As you can see
above, I have already almost given up on running self-tests at all, but
I really don't understand how wrapping them within 'timeout' could still
cause an infloop.
Did you try re-running this a couple of times? Maybe it sometimes
succeed? That seems to be the case on some archs. Still, I don't
understand how it could ever infloop.
Hmm. Looking at timestamps in your log, it seems you only let the
build+test phase run ~2-3 minutes?! Could you let it run for longer?
The self-tests are not trivial, and often takes more time than that. I
am not confident the 15m timeout is sufficient, but I didn't want to use
an excessive long timeout in case 15m happened to be sufficient.
/Simon
signature.asc
Description: PGP signature
