Every once in a while there is a package that requires more than three hours to run autopkgtest. One example is pyinstaller-hooks-contrib.
https://tracker.debian.org/pkg/pyinstaller-hooks-contrib On amd64, armhf, and i386, the tests currently take slightly less than 3 hours. But on arm64, the tests timeout because they take longer than 3 hours (I think the timeout might be closer to 2.75 hours, but I rounded it to 3 hours here for discussion). https://ci.debian.net/packages/p/pyinstaller-hooks-contrib/testing/ arm64/60336360/ When there are two versions of Python in testing, which happens during transitions in between releases, the test for all architectures would take longer than 3 hours, because the tests would run twice, once for each available version of Python. Although tests that take this long are uncommon, this is not the only package that has this problem. Pyinstaller (related) has the same issue, and during forky I would like to enable tests on qt6-webengine, which I expect to also run for a long time, although I don’t know if it would exceed 3 hours. I have two questions. 1. Is there a way to override the 3 hour time limit for Debian CI for a particular package? 2. Would there be objections to reconsidering the 3 hour default time limit for all packages? For reference, I setup a custom Salsa runner on my own hardware to handle Salsa CI and bumped the default timeout to 8 hours, which so far has worked even when there are two versions of Python in testing. I would hate to have to disable autopkgtest for some or all architectures on these packages, as the output has been beneficial. But I also don’t want to prevent migration to testing just because the tests are timing out. -- Soren Stoutner so...@debian.org
signature.asc
Description: This is a digitally signed message part.
