Hi Andreas, On 03-03-2022 11:28, Andreas Beckmann wrote:
with the recent uploads of src:cub and src:libthrust I've added autopkgtests, which unfortunately are causing regressions. Please ignore these for now while I'll try to fine-tune them in the future.
Are you in a hurry to get these versions in testing? If so, please elaborate why. Otherwise, I suggest to either just work on fixing the tests or disable them for now. Failing autopkgtests in testing are considered RC, so without good reason, we don't want to ignore regressions.
Some tests are failing due to timeouts - is there is a way to increase the timeout values?
You mean timeouts in autopkgtest the binary? No, there's no way.
Or is it possible to use parallelism,
Sure. Inside your test you are free to do whatever you want.
i.e. building stuff with -j #P?There is --build-parallel=N (which probably sets DEB_BUILD_OPTIONS=parallel=N), but that does not seem applicable here since we are not building the package (no build-needed restriction), but only (a subset of) the testsuite (with some extra non-B-D packages available and different flags). I don't think '-j $(nproc)' would be a good idea ...
On our host with lots of cores (we have one with 160), we run multiple autopkgtests in parallel, so indeed that sounds like overkill. On the other hand we also have hosts with only 2 cores (where we don't run things in parallel). I don't know what's good advice here.
Paul
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature