In Ubuntu, we only fetch results on demand, so we might not
have seen the results yet.
Debian always fetches results at the beginning so has all the
data ready.
Due to the number of hints in standing use in Ubuntu, hints.search() is an
expensive operation, and we call it once for *every single test* referenced
from -proposed. Since force-reset-test are a small proportion of the hints
in use, searching once for all the hints of this type and only searching
this subset for each autopkgtest improves performance (with 23000
autopkgtests referenced in -proposed, this saves roughly 1 minute of
runtime, or 11% on a 9-minute britney run; the number of packages in
-proposed is typically much higher at other points in the release cycle,
therefore the absolute improvement in performance is expected to be
greater.)
The force-reset-test hints are an Ubuntu delta so this is not expected to be
upstreamed; and it could eventually be dropped if and when baseline
retesting is implemented in Ubuntu and the number of hints required drops.
This could be implemented with a more generic, elegant solution in
HintsCollection, but again, the scalability problem of hints is hopefully
short-lived so I didn't consider it worth the investment here.
urlopen() supports non-http URLs, but when called on them, http-related
features are absent - such as getcode(). Make the code work with file:///
URLs.
Since we've never used remove hints in Ubuntu and never will, we shouldn't
pay the cost for them in britney runs. Remove references to them entirely,
to speed up britney runs.
This is an Ubuntu delta not expected to be upstreamed, and can be dropped at
some future point when we don't have 11,000 active hints. (This count of
hints is expected to drop dramatically once we have autopkgtest baseline
retesting.)
The existing code attempts to "short circuit" processing of binaries in
unstable by first checking if the package is subject to a removal hint.
This is invalid in Ubuntu for two reasons:
- we do not use removal hints for removing packages from the release pocket
- there are 11,000 hints in Ubuntu (due to force-reset-test) - searching all
hints is time-consuming and not a short-circuit at all.
Reorder the code so we only scan the hints if there's otherwise an
indication of something to do.
We currently skip the ALWAYSFAIL/REGRESSION handling for kernels. This
can lead to us missing genuine regressions in kernel uploads. The
idea is that results from one kernel flavour shouldn't influence
another.
We can keep this idea but do better and actually check for regressions:
when looking at results, if we're considering a kernel, only look at
results which were triggered by this kernel.
We currently have excuses.html saying:
x264 (2:0.155.2917+git0a84d98-2 to 2:0.159.2999+git296494a-2)
Migration status for x264 (2:0.155.2917+git0a84d98-2 to 2:0.159.2999+git296494a-2): BLOCKED: Cannot migrate due to another item, which is blocked (please check which dependencies are stuck)
Issues preventing migration:
Implicit dependency: x264 nageru (not considered)
Invalidated by implicit-dependency
Implicit dependency: x264 ffmpeg
Implicit dependency: x264 gst-plugins-ugly1.0
Implicit dependency: x264 handbrake
Implicit dependency: x264 libquicktime
Implicit dependency: x264 mplayer
Implicit dependency: x264 mythtv
Implicit dependency: x264 obs-studio
Implicit dependency: x264 vlc
Implicit dependency: x264 xpra
Additional info:
8 days old
Apart from `nageru` it's not clear here that some further packages need
working on to move this migration forward. In fact, the package
`gst-plugins-ugly1.0` is FTBFS
Migration status for gst-plugins-ugly1.0 (1.16.2-2build2 to
1.16.2-2build3): BLOCKED: Maybe temporary, maybe blocked but Britney
is missing information (check below)
as is xpra. The remaining packages are simply those which are part of
this SONAME transition, as such they have
Migration status for mplayer (2:1.3.0-8build6 to 2:1.3.0-8build7):
BLOCKED: Cannot migrate due to another item, which is blocked (please
check which dependencies are stuck)
All of these excuses are (or should be) "invalid", but only the ones
which are not BLOCKED_BY_ANOTHER_ITEM require direct action. We should
show this, so that maintainers can see what they need to concentrate on.
When outputting depdencency problems, consider the policy verdict of the
excuse. If it's one that indicates further work is required for that
excuse, indicate this by outputting "(not considered)".
We often introduce new kernels post-release, and we still want to not
trigger tests for the kernel image packages. Check for -meta in the
*source* suite as well as the target.
Fix the -meta name calculation for linux-signed-foo.
We currently skip running autopkgtests where there is an installability
problem, but in a few cases the depends policy notes these only, but
otherwise doesn't block migration on them.
In these cases, let's try to run the autopkgtests anyway. There will be
a few instances of uninstallability here, but since we migrate the
packages we should give them a chance to be tested.
We currently concatenate all triggers together into a string, but the
AMQP consumer expects this to be a list.
When using AMQP, keep the triggers as a list. Ensure that the "real"
trigger (the package being tested) is kept first, as before.
If we have this situation
- Binary in target taken over by new source
- Not cleaned up yet
- New source updated in source suite
We can have *three* copies of a source package visible to britney at
once. Handle this case by recording the source package a pkgid was seen
in before, and trying to remove from that and the current source.
On some distros (Ubuntu), arch:all packages are built along with one of
the architectures. We shouldn't be listing 'all' as its own arch in this
case. Instead we filter out the binaries except for on the
'all_buildarch'.
We just had the autopkgtest queues DoSed because britney was crashing
after requesting each reverse dependency for a perl upload, but before
it had written pending.json out so it knew what not to request again.
This was 25,000 requests per arch...
Let's write pending.json straight after sending each request, so that
the next run - even after a crash - won't re-request the same things
again.
These have a hash appended.
We don't actually use the baseline retrying, which is where the ID
parsing is used, but we might as well handle this, not least so we don't
crash.
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.
Most DKMS packages do not declare Testsuite: autopkgtest-pkg-dkms, but
we can detect this anyway, and this way we can enforce that the module
is buildable.
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.
We want to treat linux-$flavor and linux-meta-$flavor as one set in
britney which goes in together or not at all. We never want to promote
linux-$flavor without the accompanying linux-meta-$flavor.
Add a new LinuxPolicy which runs after most of the other policies, which
invalidates linux-foo if linux-meta-foo is invalid.
Sometimes (for the LinuxPolicy), excuses don't have enough information
when they are processed. They need to defer some of their work until
another excuse has been evaluated and then perhaps get invalidated.
Introduce the concept of "external invalidation" to deal with this. A
policy can keep references to other excuses around, and then invalidate
them later (when processing another one). The excuse finder needs to
know this happened to remove the excuse from the list of "actionable
excuses".
For example. The Linux policy invalidates linux-foo if linux-meta-foo is
invalid. If linux-foo is encountered first, we will not yet know if
linux-meta-foo is going to be invalid. We effectively defer the
evaluation until after linux-meta-foo has been dealt with, and then we
know whether we need to invalidate linux-foo or not.
For packages with lots of reverse dependencies, new versions of those reverse
dependencies may keep on showing up in testing. If migration is blocked until
the results for these new version, migration may take extremely long. If there
are results for the current trigger but for the previous version of the reverse
dependency, use those until the fresh resuts are available.
Similar for the reference runs.
Hint to allow smooth update, even if the section isn't allowed in the
configuration.
Note that this takes the source name and the source version IN TESTING
of the binaries that must be allowed to stay around to allow a smooth
update.
Currently, britney only schedules reference runs when they don't exist. It does
strip out runs against older versions of the autopkgtest, but the current version
may exist for a while and the reference run can be old. So, add an option to
ignore old results.
When the architecture are read from the Release file, they are not
defined in the config file.
Adding 'all' as an architecture will not give the correct result. To
avoid confusion, explicitly check for this and error out if it is added.
We only want to add packages which conflict in testing, but don't
conflict in unstable. For those, the newer version (from unstable)
probably fixes the conflict.
When an arch:all binary is uninstallable on a non-nobreakall arch, don't
block it, but still mark it as uninstallable, so the autopkgtest policy
knows not to schedule tests for it.
Currently when a package is uninstallable on an arch, no autopkgtests for that arch are triggered
and the autopkgtest policy blocks migration. However it's not the job of the autopkgtest policy
to judge uninstallability and packages that build an arch:all package that just isn't installable
on the autopkgtest arch should not be blocked for this.
Closes: #918620
Use the info based on the binaries in the Suite object, instead of the
inst_tester. This should also include packages that are in testing, but
are not installable.
Julian Andres Klode
Steve Langasek
Iain Lane
Michael Hudson-Doyle
Iain Lane
Colin Watson
Łukasz 'sil2100' Zemczak
Tiago Daitx
Robert Bruce Park
Martin Pitt
Paul Gevers
Ivo De Decker