For items not having an age requirements (e.g. urgency=critical)
always list the "missing build" note if present.
Signed-off-by: Niels Thykier <niels@thykier.net>
This hint will block all "new" source migrations. Source migrations
for packages already in testing will be affected by this. As usual,
this hint can be overruled by an unblock hint.
Closes: GH#8
Signed-off-by: Niels Thykier <niels@thykier.net>
Reduce a "loop over all valid items" to a "loop over an item's
dependencies + reverse dependencies". For sparse graphs, this
is much more efficient.
Signed-off-by: Niels Thykier <niels@thykier.net>
python-apt's "TagFile" seems to cut the field short if it meets a
comment. Therefore allow comments in the actual field value to avoid
this nasty behaviour.
Signed-off-by: Niels Thykier <niels@thykier.net>
Packages in main should not need them. Presuming we eventually make
Britney enforce separation between components, "non-free" seems like a
better default.
Signed-off-by: Niels Thykier <niels@thykier.net>
If there is a regression in "present-and-installable" constraints (on
non-break architectures), then discard the item even if the nuninst
counters have improved.
Signed-off-by: Niels Thykier <niels@thykier.net>
For (non-hint) migrations, split the set of affected into two
parts; one for reverse dependencies and one "negative dependencies"
(e.g. Conflicts).
If there are only regressions in the nuninst after checking the first
set, then there is no reason to continue with the second set (as
"negative dependencies" can only make it worse at that point).
Signed-off-by: Niels Thykier <niels@thykier.net>
Ideally we would reject all items with known unsatisfiable
dependencies as they would not be installable in testing. However,
there are a few known corner cases where we still want to migrate them
(notably when they are already broken in testing).
This commit is an attempt to weed out some of the "obviously" broken
items that will not successfully migrate.
Signed-off-by: Niels Thykier <niels@thykier.net>
In the next commit, the binary packages will be turned into
namedtuples and will become immutable objects.
Signed-off-by: Niels Thykier <niels@thykier.net>
In an architecture only migration, we currently see two notes for
every arch:all packages:
* Ignoring "new" arch:all package
* Ignoring "removal" of arch:all package
But a closer look at the situation is that the arch:all packages is
generally the same in both testing and the source suite.
This commit removes these notes when the arch:all is the same in both
suites.
Signed-off-by: Niels Thykier <niels@thykier.net>
There was an implicit assumption in Britney that was violated recently
(presumbly in 12d9ae8). This assumption is that a source package will
reference the *latest* version of an arch:all package; even if that
version is not built by that source (version).
Image the following packages:
* p-all/1 and p-all/2 are arch:all packages.
- p-all/1 is generally superseded by p-all/2 except it has not
been removed yet (regardless of why that happens).
* src-a/2 builds p-all/2.
When Britney loads the packages (assuming packages are sorted[1]):
* p-all/1 is read and associated with src-a/2 (despite not being
built from that source)
* p-all/2 is read afterwards. It would replace p-all/1 and be
assoicated with src-a/2 as well.
- Prior to 12d9ae8, the assoication would be "pkg, arch" and
therefore the same.
- In 12d9ae8a and after, the association would include version
and both would be associated at the same time.
* Since p-all/1 is discarded, it is never added to the
installability tester (nor the solver). It then promptly throws
an exception when asked to deal with a package it believe does
not exist.
- This can trivially be solved by removing the association
between p-all/1 and src-a/2 when p-all/2 is read.
So far so good. Unfortunately, this adds another another problem!
When Britney migrates a binNMU, she currently removes *all* binary
packages on that architecture - *including* the arch:all packages.
This works out in the end because the arch:all packages be re-added
since they associated with the source package.
At first glance, this appears to be a non-issue until you add
hijacking to the mix. This is *exactly* the case behind #709460.
However, now we end up in a situation where the arch:all package is
removed during binNMU and not re-added (because the arch:all package
is not associated with *that* source any more).
This commit fixes all of the above by:
1) Correctly disassociating superseded arch:all packages from their
source packages
2) Falsely associating the "new" arch:all package to the source that
provided the superseded arch:all package (to avoid issues with
binNMUs and hijacked packages).
- This should probably be undone at some point when Britney does
not need this "hack" any more.
This fix is currently relying on the packages being sorted. But so
did the fix for #709460 (see [1] again). It might be prudent to fix
that as well (or at least reject the packages file rather than produce
"random" results).
[1] Which is another assumption we have been relying and that is
currently satisfied.
Signed-off-by: Niels Thykier <niels@thykier.net>
* A package being removed is *not* affected
- It will just be filtered out later in "check_packages"
* Since all transitive reverse dependencies will be added to
"affected" at the end of the method, there is no reason to
find the immediate set of reverse dependencies of a package
if the package is added itself as well.
Signed-off-by: Niels Thykier <niels@thykier.net>
Adds a --components command line argument (and corresponding config file
option). If specified, package info is expected to be in the usual Debian
mirror layout, ie:
testing/source/Sources
testing/binary-${ARCH}/Packages
(nthykier: Squashed, rebased and did some porting to Python3)
Signed-off-by: Niels Thykier <niels@thykier.net>
A package can have old cruft no longer in testing, which can't
migrate because it depends on old libraries or packages that
aren't in testing anymore, preventing migration.
There's no point in trying to migrate old cruft that has already
been removed in testing anyway, so don't do that.
Signed-off-by: Emilio Pozuelo Monfort <pochu@debian.org>
Signed-off-by: Niels Thykier <niels@thykier.net>
The "include_hijacked" parameter of "_compute_groups" was always
false, so there was little point in having it.
Signed-off-by: Niels Thykier <niels@thykier.net>
The same_source is supposed to compare two versions and (if needed)
"massage" a binNMU version into a source version. This extra feature
of same_source happens to be unused (and not generally applicable):
1) We always compare two source versions, so there is never a
binNMU version in the first place.
2) binary versions are *not* always equal to their source version
(even with the binNMU suffix stripped). This happens when
packages use "dpkg-gencontrol -v<version>".
Note this causes results from some live-data tests to change, because
there has been a sourceful upload with a binNMU version. It was
intended as a binNMU, but was uploaded with the source as well. As
Britney no longer works around this issue, it makes her remove the
affected packages in the end (as their source version does not match
the version in testing).
Signed-off-by: Niels Thykier <niels@thykier.net>
This bug involves a corner case that involves:
* source orig providing liborig1 and orig-doc in testing
* source orig providing liborig2 and orig-doc in unstable
* source hijack providing liborig2 and orig-doc in both testing and unstable,
where the versions of hijack's binaries has a higher version than those of
"orig".
The arch:all packages are needed to trigger this, because Britney
flags an arch:any package as "out of date" and stops the migration
there. However, she is more lenient with arch:all packages.
What happens is that Britney realises that src:orig need to be updated
in testing (to remove liborig1). This leaves src:orig with no
binaries left in testing (as the orig-doc from hijack is used) and it
is therefore removed as an obsolete source. The obsolete removal then
exploded because Britney was also trying to remove the liborig1
package, which is no longer there.
Signed-off-by: Niels Thykier <niels@thykier.net>
With this patch, Britney will correctly parse (and deparse) a
versioned Provides. Furthermore, she will allow it to satisfy any
unversioned dependency on the provided package.
This is the easy half of #786803.
Signed-off-by: Niels Thykier <niels@thykier.net>
It can be used to A) to make the mismatch check more efficient and B)
share identical binaries between suites.
Signed-off-by: Niels Thykier <niels@thykier.net>
Previously whether such packages received excuses, and the specific
content of such excuses, was dependent on the order in which their
binary packages were considered.
Signed-off-by: Adam D. Barratt <adam@adam-barratt.org.uk>
This made iter_packages_hint a thin wrapper around try_migration, so
it was inlined into its only caller "do_all".
Signed-off-by: Niels Thykier <niels@thykier.net>
The callers of get_dependency_solvers need to do those table lookups
anyway. By moving it out, it is now possible to reuse the results.
Signed-off-by: Niels Thykier <niels@thykier.net>
Rely on the Installability tester to locate all of the affected
packages plus their transitive reverse dependencies. As the
InstallabilityTester is suite agnostic, the set of affected packages
now includes (versions of) packages not in testing, which is filtered
out during the check.
Signed-off-by: Niels Thykier <niels@thykier.net>
If we have an up-to-date arch all package available for this architecture,
that doesn't mean this architecture has an up-to-date build. We need an
architecture specific up-to-date package for that.
Signed-off-by: Ivo De Decker <ivodd@debian.org>
For fucked architectures, binaries from older versions are allowed to be in
testing, so we only remove them if they are gone from unstable.
Signed-off-by: Ivo De Decker <ivodd@debian.org>
Niels Thykier
Julien Cristau
Anthony Towns
Emilio Pozuelo Monfort
Paul Wise
Adam D. Barratt
Ivo De Decker