In Debian, the same override is applied to both suites and they are
always consistent. It's not the case in Kali, we keep the value from
Debian when we import the package in britney's source distribution, but
if the same version is already present in the target distribution, it
keeps its original section (dating back to its initial import). In those
situations, the code will fail with an error like this one:
E: [2018-12-28T19:57:57+0000] - Mismatch found coinor-libdylp0 1.6.0-1.1 amd64 differs
I: [2018-12-28T19:57:57+0000] - ... section libs != science
[...]
ValueError: Inconsistent / Unsupported data set
Commit 7efa865a04 which was supposed to
move code around introduced the check on this field. Prior to this, the
section was not checked. Since the section only has an impact on which
packages take part to the smooth updates feature, the impact of such a
mismatch is negligible so I simply dropped that check.
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>
Have the transaction code verify that there is at most one active
child at the time and no one is using the parent while child is
active. This is how the code is intended to be used and also the
code almost certainly does not work otherwise.
The new code does not cover commiting/rolling back a parent before a
child but that is already covered by the existing code (it will
trigger when child transaction is rolled back/committed or when
leaving the contextmanager from start_transaction).
This would have caught 7d758760d1
immediately with an assertion error.
Signed-off-by: Niels Thykier <niels@thykier.net>
Correct the return value of current_transaction that treated the
_transaction field incorrectly as a queue rather than a stack like
everything else. This completely broke the ability to commit and
rollback child transactions (correctly). Fortunately, it could only
trigger on a "hint"-hint.
Signed-off-by: Niels Thykier <niels@thykier.net>
When we try to compute_groups for a group which has a source or a binary with
a lower version than testing, throw an exception. In the cases where this can
happen, the exception is caught. In other cases, it is not and it serves as an
assert.
This can only happen when there are multiple candidates (from multiple suites)
changing the same source or binary.
This should fix the ordering issues tested in these tests:
- tpu-unstable-binnmu
- binnmu-tpu
- tpu-with-unstable-binnmu
With this change, it should be possible to accept binNMUs from *pu again.
Signed-off-by: Ivo De Decker <ivodd@debian.org>
This isolates the undo handling in the new transaction object and in
doop_source, which currently generates the undo items. This commit
will be a stepping stone to rewriting the undo handling.
Signed-off-by: Niels Thykier <niels@thykier.net>
When calculating smooth updateable binaries, filter out cruft binaries from
unstable, because they will not be part of the set of packages that britney
will try to migrate to testing.
Signed-off-by: Ivo De Decker <ivodd@debian.org>
The parsing of migration items should also look for the suite name in the
architecture part. This fixes the parsing for migration items like
some-src/amd64_tpu and some-src/amd64_tpu/1.0-1
Signed-off-by: Ivo De Decker <ivodd@debian.org>
This commit updates the test suite to use the BinaryPackageUniverse
instead of the InstallabilityTester where that makes sense. The rest
of Britney has yet to be updated except where absolutely necessary (as
that will come in a later commit).
Signed-off-by: Niels Thykier <niels@thykier.net>
The InstallabilityTester is suffering from a lack of clear purpose
because it serves multiple. This commit extracts most of one of these
purposes into the BinaryPackageUniverse class while retaining the
original API of the InstallabilityTester.
Signed-off-by: Niels Thykier <niels@thykier.net>
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.
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>
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>
Into 3 categories:
* target suite ("testing")
* primary source suite ("unstable")
* additional source suites ("pu" and "tpu")
This will be useful for implementing logic working with suites without
basing it on the name of the suite.
Signed-off-by: Niels Thykier <niels@thykier.net>
At the moment, it is just a glorified dict. However, we will
eventually use it to get rid of the hardcoded references to "testing"
etc. all over the code.
Signed-off-by: Niels Thykier <niels@thykier.net>
1) the update didn't happen for all but the first
2) we don't want a package that fixes a regression in unstable to influence the
reference for another package until it actually migrates, so this updating
is flawed.
Given that only one value is defined ("reference"), it is a better
option to allow the config to be unset when one does not want to have
adt_baseline set to "reference".
Signed-off-by: Niels Thykier <niels@thykier.net>
Notable omissions are "pending_tests" and "tests_results". This is
omission is due to these (some times) being initialized from the
output of "json.load" (so we cannot assume defaultdict semantics
without manually imported the data into one).
Signed-off-by: Niels Thykier <niels@thykier.net>
The first case is to avoid a creating a list, which is then converted
to a set only to throw away the list again. Here we can just create
the set right away without a list inbetween.
The second case is "if x in [...]:" is better written as "if x in
{...}:" as sets provides faster "__contains__" (assuming you are on a
"recent enough python3", which britney is).
Signed-off-by: Niels Thykier <niels@thykier.net>
Arguable, this is not a problem in the code as the failure case
invokes sys.exit. However, this is more future proof as the sys.exit
may be replaced (or we may later catch another exception that is
"recoverable").
Signed-off-by: Niels Thykier <niels@thykier.net>
- revert most of commit adbe6d5 as checking the version in testing doesn't work
when other packages migrate and cause regressions
- Alternative way of determining if a package is regressing, by comparison to a
reference set. The reference set is to be created by a holy trigger that
doesn't take packages from the base suite, but instead tests in the testing
suite. This reference needs a retry when a package causing regression
migrates nevertheless, e.g. due to hints or to bounty/penalty policy.
This commit rewrites the make-shift "log" methods to use the logging
framework without requiring changes to the callers. This will be done
in a latter commit to keep things reviewable.
Signed-off-by: Niels Thykier <niels@thykier.net>
Raphaël Hertzog
Ivo De Decker
Niels Thykier
Iain Lane
Paul Gevers
Mathieu Trudel-Lapierre