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.
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
Rework the dependencies between excuses.
Dependencies are specified based on packages (source or binary). Based
on these packages, dependencies on other excuses (that have these
packages) are calculated.
As with package dependencies, dependencies between excuses can contain
alternatives.
Each alternative can satisfy the dependency, so the excuse only becomes
invalid if all of the alternatives of a specific dependency are
invalidated.
Tracking of the alternatives and their validity is moved to separate
objects.
Because autopkgtest failure in a package is now a serious bug (RC), packages
that don't opt-in should not be tested. Due to the way autopkgtest and autodep8
work together, package that don't declare they have an autopkgtest can still be
tested. However, maintainers should not be force to say their package doesn't
work with autodep8 by introducing a fake test.
When there is no test in testing, and a failing test in unstable, don't
allow the package to migrate. Doing so would make it instantly RC-buggy.
Signed-off-by: Ivo De Decker <ivodd@debian.org>
When the arch: all packages were uploaded by the maintainer, a binnmu (built
on the buildds) shouldn't be blocked, because it doesn't contain the arch: all
binaries anyway.
Signed-off-by: Ivo De Decker <ivodd@debian.org>
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
This avoid messages like
Required age reduced by 0 days because of autopkgtest
that is hardly useful.
Signed-off-by: Mattia Rizzolo <mattia@debian.org>
The intialise method is already complex enough and this was a trivial
snippet to extract to reduce the complexity a bit.
Signed-off-by: Niels Thykier <niels@thykier.net>
When we convert legacy results in the autopkgtest-results.cache file,
we are only touching leaf results. By moving the loops into a
function, we can remove 2-3 levels of ("redundant") nesting. This in
turn makes it more clear what is relevant in the conversion.
This same also holds in save_state when we convert an Enum to a
string.
Signed-off-by: Niels Thykier <niels@thykier.net>
Move the logic of apply_src_policy and apply_srcarch_policy into PolicyEngine.
This fixes an issue with the excuses.yaml output introduced in commit
15e5228669: only the last verdict was added to the excuse info for that
policy.
Signed-off-by: Ivo De Decker <ivodd@debian.org>
When a source has only arch: all binaries, the Build-Depends had no relevant
architectures, so the check was skipped. Instead check it on any architecture,
just like Build-Depends-Indep.
Signed-off-by: Ivo De Decker <ivodd@debian.org>
The src_policy defines wether, for source items, the source policy should be
run (RUN_SRC, the default), the arch policy should be run on every arch
(RUN_ON_EVERY_ARCH_ONLY), or both (RUN_SRC_AND_EVERY_ARCH).
Signed-off-by: Ivo De Decker <ivodd@debian.org>
The recent code changes made use remove from the "binaries" field in
SourcePackages. Lists are not particularly optimized for this kind
of removal and we have a few source packages with a lot of binary
packages (e.g. libreoffice, gcc-X-cross{,-ports}) that might trip
poor performance.
Signed-off-by: Niels Thykier <niels@thykier.net>
Regex compilation is often rather expensive and in this case, we can
do it once instad of once per migration item.
Signed-off-by: Niels Thykier <niels@thykier.net>
Note that this now also applies to binNMUs. A source block also blocks
binaries. Binaries on a specific architecture can be unblock with an
architecture-specific unblock hint.
This also means all binaries from non-primary suites
(testing-proposed-updates, etc) need approval.
Closes: #916209
Currently no policy implements this.
A policy can now implement apply_src_policy_impl or apply_srcarch_policy_impl
(or both), so apply_src_policy_impl is no longer an abstractmethod.
Signed-off-by: Ivo De Decker <ivodd@debian.org>
apply_src_policy expects an excuse with a new source and binaries. It doesn't
apply to srcarch excuses, which only have new binaries for an existing source.
Signed-off-by: Ivo De Decker <ivodd@debian.org>
This is a step towards making migration unit-testable. This step
reduces the need for global state (in the MigrationItem class as class
fields) and with another step we can remove the global state entirely
and enable unit tests to create migration items without having to
worry about other unit tests.
Signed-off-by: Niels Thykier <niels@thykier.net>
All types of dependencies between excuses (Depends, Build-Depends,
Build-Depends-Indep, ...) are handled by the same code. The DependencyType is
used to distinguish between the types where needed.
Signed-off-by: Ivo De Decker <ivodd@debian.org>
This is useful to run tests with the data files from a specific point in time,
without changes due to ageing when the test runs later.
Signed-off-by: Ivo De Decker <ivodd@debian.org>
Currently autopkgtest tries to install our trigger from unstable and the rest
from testing. If that fails, than autopkgtest has a fall-back to allow all
packages from unstable to be installed. This has two severe issues:
1) the version of the test and the package it came from may be out-of-sync
2) too much from unstable may be installed, even stuff that should not/is not
allowed to migrate as it breaks stuff.
Make sure that test depends also get added to triggers if they are broken.
E.g. imagine the following scenario: trigger X changes (breaks) the output
generated by Y. Package Z has Y in the test dependencies and compares the
output in the autopkgtest. We want to have the opportunity that a new version
is automatically fixing the situation.
Two use cases are currently unsupported: needs-build (autopkgtest restriction)
and test dependencies generated by autodep8.
Paul Gevers
Ivo De Decker
Steve Langasek
Niels Thykier
Mattia Rizzolo
Iain Lane