Hello. When I try to build the Debian package for cnvkit version 0.9.13 on a system with 1 CPU, the tests appear to work, but then the build never ends and it's finally killed by sbuild, the script controlling the build:
============================= test session starts ==============================
platform linux -- Python 3.13.12, pytest-9.0.3, pluggy-1.6.0
rootdir: /<<PKGBUILDDIR>>/.pybuild/cpython3_3.13_cnvkit/build
configfile: pyproject.toml
plugins: hypothesis-6.152.4, typeguard-4.4.4
collected 98 items
test/test_cnvlib.py ........... [ 11%]
test/test_commands.py ..................................... [ 48%]
test/test_genome.py ................... [ 68%]
test/test_io.py .......... [ 78%]
test/test_parallel.py ............ [ 90%]
test/test_r.py . [ 91%]
test/test_rna.py ........ [100%]
======================== 98 passed in 110.84s (0:01:50) ========================
E: Build killed with signal TERM after 60 minutes of inactivity
Note that version 0.9.12 used to work ok.
Is this a bug in the tests, or maybe I should skip all the tests when building the package on single-cpu systems?
(Conditionally skippìng the tests in debian/rules would be easy, but I believe it would be much better if tests which are known not to work, or create deadlocks, would be skipped with a simple skipif decorator, as that would be a solution which would benefit everybody).
Note: The easiest way to reproduce this kind of failures (if you don't have a single-cpu VM at hand) is by configuring GRUB with GRUB_CMDLINE_LINUX="nr_cpus=1" and rebooting.
Thanks.
Hello. When I try to build the Debian package for cnvkit version 0.9.13 on a system with 1 CPU, the tests appear to work, but then the build never ends and it's finally killed by sbuild, the script controlling the build:
Note that version 0.9.12 used to work ok.
Is this a bug in the tests, or maybe I should skip all the tests when building the package on single-cpu systems?
(Conditionally skippìng the tests in
debian/ruleswould be easy, but I believe it would be much better if tests which are known not to work, or create deadlocks, would be skipped with a simple skipif decorator, as that would be a solution which would benefit everybody).Note: The easiest way to reproduce this kind of failures (if you don't have a single-cpu VM at hand) is by configuring GRUB with
GRUB_CMDLINE_LINUX="nr_cpus=1"and rebooting.Thanks.