Package: release.debian.org
Severity: serious
User: release.debian....@packages.debian.org
Usertags: britney
When {testing,stable}-proposed-updates has a binary-only item (binNMU or
missing build that arrived later), britney will use the binaries from unstable
instead, possibly migrating them even if they are from a different source and
should not be a candidate. During the freeze, a binNMU in tpu would cause the
binaries from a newer (blocked) source in unstable to show up in testing. As
this causes britney to potentially migrate random unwanted binaries, I filed
this bug as serious.
This is caused by wrong parsing of MigrationItem and can be fixed by the
attached patch.
Please note that the root cause of this issue is that the excuses calculation
uses detailed information about the binaries and sources involved, but this
information isn't passed on. Only the 'name' of the migration item is passed
on, and later on, britney tries to calculate the set of binaries and sources
again based on the info gathered from parsing this name.
With the attached patch, however, other issues with binNMUs in tpu show up:
When both a new source from unstable and a binNMU from tpu are candidates,
britney might migrate the new source first and then accept the binNMU. This
causes the architecture of the binNMU to have the older binaries from the
binNMU, while other architectures have the newer once. If there are no rdeps,
the older binaries are removed because they are considered old binaries from
smooth updates (because they are built by a different source version).
Allow the binNMU to migrate is clearly wrong, because after the migration of
the new source, the binNMU of the old source should no longer be considered.
Some of this is tested by the following tests in the testsuite:
binnmu-tpu
binnmu-tpu-rdeps
bug-unfiled-2
Additional tests could be useful for combinations with arch: all packages (on
some/all architectures) and binary takeovers (arch: all/any, on some/all
architectures, ...).
As a 'temporary' workaround, it might be good to disable binary-only items
from *pu completely for now, to avoid this issue.
More targeted workarounds could include:
- Only allow binNMUs from *pu with an explicit hint (which would have to be
used with care).
- Disable binary-only items that contain binaries that are also built by
source items that are a candidate. This would mean that a new source from
unstable must be blocked explicitly if you want to allow a binNMU from *pu
to migrate.
- Always try binary-only items before source items. I don't really know how
this could be enforced when multiple easy hints are tried or during a hint
run.
More ideas welcome...
Ivo
>From 67628b80ad208f0eca2262e79eb0d5fd5372b8c8 Mon Sep 17 00:00:00 2001
From: Ivo De Decker <iv...@debian.org>
Date: Tue, 11 Dec 2018 12:37:45 +0000
Subject: [PATCH] Fix parsing of migration item name for binNMU in tpu
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 <iv...@debian.org>
---
britney2/migrationitem.py | 3 +++
1 file changed, 3 insertions(+)
diff --git a/britney2/migrationitem.py b/britney2/migrationitem.py
index 1122852..f6b1090 100644
--- a/britney2/migrationitem.py
+++ b/britney2/migrationitem.py
@@ -97,6 +97,9 @@ class MigrationItem(object):
else:
self._architecture = 'source'
+ if '_' in self._architecture:
+ self._architecture, suite_name = self._architecture.split('_', 2)
+
if self._version in self.__class__.get_architectures():
(self._architecture, self._version) = \
(self._version, self._architecture)
--
2.11.0
