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.
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.
Adding a source parameter to the SourcePackage allow finding the source
the object is referring to, so that parameter doesn't have to be passed
along separately.
Signed-off-by: Ivo De Decker <ivodd@debian.org>
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>
If a new pseudo-essential package was added to testing *and* it is
mutually-exclusive with an existing member, britney would incorrectly
flag it as uninstallable (unless another change triggered a cache
invalidation of the pseudo-essential set).
With this commit, the cache invalidation is now done based on whether
we add something that *might* be in the (effective) pseudo-essential
set. It is an overapproximation as there are cases where the
invalidation is unnecessary, but at the moment it is not a performance
concern.
Closes: https://bugs.debian.org/944190
Signed-off-by: Niels Thykier <niels@thykier.net>
The optimizations relies on assumptions that are not valid with the
allow-uninst that has not been corrected. When these assumptions, we
end up with invalid nuninst counters.
Signed-off-by: Niels Thykier <niels@thykier.net>
The spec for Release files says that (at least) one of "Suite" and
"Codename" will be defined. This implies that "Suite" is optional
in some cases and SuiteLoader now correctly falls back to using
"Codename" in that case.
Closes: https://bugs.debian.org/942104
Signed-off-by: Niels Thykier <niels@thykier.net>
When an allow-uninst hint is added for an unversioned binary package, items
are allowed to migrate, even if they make that binary package uninstallable
(on the architecture specified in the hint, if one was specified, or on all
architectures otherwise).
Using this hint should avoid using force-hint to allow specific breakage.
Signed-off-by: Ivo De Decker <ivodd@debian.org>
The code that was supposed to check uninstallability of existing binaries was
broken:
- it only checked arch: all on nobreakall archs, not arch any
- it checked if the new binary was in testing (this never happens)
- it doesn't work when binaries from both unstable and tpu are needed
Note that _excuse_unsat_deps() now handles nobreakall correctly.
don't show information about unsatisfiable depends that is not blocking
migration:
* arch all not on nobreakall arch
* arch any or arch all on breakarch
Also, set verdict to REJECTED_PERMANENTLY explicitly. This was already done
implicitly, because that is the default and it was never set to anything else.
Also, set verdict to REJECTED_PERMANENTLY explicitly. This was already done
implicitly, because that is the default and it was never set to anything else.
If the cruft removal item has a different version than the binary currently in
testing, then the cruft item was replaced since it was added, or it was added
in error. In this case, the item should not be processed.
Signed-off-by: Ivo De Decker <ivodd@debian.org>
When the item is a cruft removal item, the variable contains the binary name,
not the source name. So rename it to item_package and set source_name, to the
source in both cases.
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>
We allow this already now even though dpkg/1.19.1 is not in stable as
it will not cause issues with upgrades (only dpkg-checkbuilddeps
needed change, so it will not cause issues on the buildds as we can
rely on dpkg from buster being present there).
Signed-off-by: Niels Thykier <niels@thykier.net>
With this change, we reduce the number of migration items creted only
to be discarded because the item is not relevant/actionable.
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>
When an item is migrated to the target suite, always create a new
SourcePackage object with a separate binaries list (independent from the list
in the source suite). That list is updated for every binary that is added,
updated or removed. This should ensure consistent source package information
in the target suite.
The undo code doesn't need to be updated for this, because the old
SourcePackage object is put back on undo, with the old binary list.
Signed-off-by: Ivo De Decker <ivodd@debian.org>
When the item is a single binary cruft removal, the source name is different
from the package. compute_groups has this info anyway, so just pass it on as a
returm value.
Signed-off-by: Ivo De Decker <ivodd@debian.org>
This test checks if every binary in the target suite is listed as a binary for
its source package and vice-versa.
This adds a config option check_consistency_level:
0: no checks
1: only check at the end
2: also check for every hint run (default)
3: check for every transaction (slow - only useful for the testsuite)
Signed-off-by: Ivo De Decker <ivodd@debian.org>
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>
Ivo De Decker
Paul Gevers
Niels Thykier
Steve Langasek
Mattia Rizzolo