If our policy marks a bunch of related packages here as non-candidates, a
force hint processed later for the package which was not a candidate is
insufficient. Instead, check here for a force hint that would
unconditionally mark a package a candidate before marking related packages
as non-candidates.
If reverse-dependencies of this package still exist on the architecture, these
would be captured as uninstallables; we don't need to additionally trigger
tests that can never succeed, would tell us nothing about the package if they
did, and will just cause more work to hint away the results.
Testsuite regression from 4c27eadffa01bc1c084e947a7fa1e8a7509d1653.
submit-time is the time the request was submitted to amqp. For tests
it's the time the testcase was run. Many of our testcases test the exact
parameters that were passed to amqp, so they now fail because
submit-time is in there but it's not being checked for. It would be
possible to either verify the submit-time too, or switch to fuzzy
matching - but it's actually not very valuable to test submit-time,
since it is only for human readers of autopkgtest-cloud log files or
autopkgtest.ubuntu.com/running.
Instead strip the field from the amqp parameters before any tests see
them.
The update of gcc to gcc-9 introduced a regression in buildability of
anything relying on kernel headers. This could have been caught by the
kernel's standard rebuild autopkgtest, but we currently only trigger the
linux autopkgtest for source packages named gcc-N, which excludes
gcc-defaults.
Include gcc-defaults in the list of packages that trigger a linux rebuild
test.
Bug-Ubuntu: https://bugs.launchpad.net/bugs/1836100
Use @patch decorator instead of ExitStack context manager. This is more
consistent with the rest of the testsuite we have in britney.
Use some more idiomatic assertions, e.g.
unittest.mock.assert_not_called().
It works like this. We wait until all tests have finished running. and
then grab their results. If there are any regressions, we mail each bug
with a link to pending-sru.html. There's a state file which records the
mails we've sent out, so that we don't mail the same bug multiple times.
The apt version comparison sorts 'blacklisted' greater than most version
numbers, which means that we accidentally apply force hints for version
'blacklisted' to all uploads. Since this is the only case of a hacked
version number, let's special case it so that 'blacklisted' hints only
match packages with 'blacklisted' version.
We're supposed to synthesise an "unknown" version for these, but a bug
in the worker meant we didn't do that in some cases and these leaked
into swift. Let's repair it client-side.
This means 'all tests were skipped', or 'no tests in this package'. The
former case is new after our recent autopkgtest rebase.
Upstream britney (624b185ba60709f1686fbaa2a7623a94c5cb23ef) handles this
as "neutral", which doesn't influence the result and is a more explicit
(better) way of expressing this situation. Once we rebase, we should
take that approach.
