Hi, On Tue, 10 Sep 2024 21:37:20 +0200 Stefano Rivera <stefa...@debian.org> wrote: > During a test rebuild, bmap-tools failed to rebuild. > > I see it has hung in the same place in the past, on a buildd. > Filing at the important level as it apparently built after being > retried, on the buildd. > > ------------------------------------------------------------------------------- > [...] > debian/rules override_dh_auto_test > make[1]: Entering directory '/<<PKGBUILDDIR>>' > faketime '2022-06-26 17:10:50' dh_auto_test > I: pybuild base:311: cd /<<PKGBUILDDIR>>/.pybuild/cpython3_3.12/build; > python3.12 -m pytest tests > ============================= test session starts > ============================== > platform linux -- Python 3.12.5, pytest-8.3.2, pluggy-1.5.0 > rootdir: /<<PKGBUILDDIR>>/.pybuild/cpython3_3.12/build > configfile: pyproject.toml > plugins: typeguard-4.3.0 > collected 19 items > > tests/test_CLI.py ..... [ > 26%] > tests/test_api_base.py > E: Build killed with signal TERM after 150 minutes of inactivity
my guess is, that this is due to the system starved of random numbers. The function generate_test_files() makes heavy use of the python random module to generate lots of data. Maybe the build system is just starved of entropy and maybe this is also why it's not failing reliably? I wasn't able to reproduce this issue locally with sbuild but saw in htop that the test in question was not using much CPU but was generating a lot of I/O by writing out all the temporary test files. The effect also happened on the buildds where the build ran into a timeout on x86-csail-02 but then built successfully within 2 minutes on x86-grnet-02 a week later: https://buildd.debian.org/status/logs.php?pkg=bmap-tools&ver=3.8.0-1&arch=all Thanks! cheers, josch
signature.asc
Description: signature
