Previously, we split affected into a "reverse relations with a
dependency on the migrated/change package" set and a set of "the
rest". With this commit we change the sets into a set of packages
with a direct relation on the migrated/changed package and the full
set of all affected.
The change has no effect on Britney's results as the first set is only
used as an optimization to reject some items faster.
Signed-off-by: Niels Thykier <niels@thykier.net>
Admittedly, no policy adds them yet so this is currently no-op code.
However, future commits can start to rely on this infrastructure code.
Signed-off-by: Niels Thykier <niels@thykier.net>
At the moment, the two are identical, but they are not intended to
remain identical (i.e. the name should eventually become the full
suite name).
Signed-off-by: Niels Thykier <niels@thykier.net>
Cherry-Pick: 80bf9060de
Cherry-Pick: f32907acea
Cherry-Pick: 9ef496177f86b18d9f910da1360dd773b82f1fb7
Cherry-Pick: b16530a37d
Signed-off-by: Niels Thykier <niels@thykier.net>
Flatten the defaultdict(set) for unsat_deps into a standard dict for output
In case autopkgtest triggering is delayed because the required builds aren't
ready yet or the package is not installable, currently there is only the
message that autopktest delays the migration, but no hint why. This commit adds
these hints.
The initial idea was to do this to bootstrap the baseline, but it turns out
that this has the drawback it triggers runs for a package that has a new
autopkgtest where it didn't have it in the version in the target suite. It was
considered harmless (as it would just have a failing reference), but due to
autodep8, package can have a passing result in the target suite while the new
autopkgtest is actually broken. Such a package should not be blocked / getting
a penalty.
The alternative is to make the check here smarter, but as this is only for
bootstrapping, lets do that outside of britney proper.
When determining whether a policy applies to a given item, use the
suite class rather than the suite name.
Signed-off-by: Niels Thykier <niels@thykier.net>
The "almost" comes from the fact that there is a reference to
"pu"/"stable" which does not have an obvious fix at the moment.
Signed-off-by: Niels Thykier <niels@thykier.net>
Previously, we would always create empty data structures for "pu" and
"tpu" if these optional suites were not configured. However, we only
reference "pu" and "tpu" directly in very few spots that can easily be
rewritten.
Signed-off-by: Niels Thykier <niels@thykier.net>
Niels Thykier
Mathieu Trudel-Lapierre
Paul Gevers