[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#916209: marked as done (britney: handling of binNMUs in tpu broken)



Your message dated Sat, 5 Jan 2019 14:35:14 +0100
with message-id <20190105133511.juc74w5ghu4fzvuk@debian.org>
and subject line Re: britney: handling of binNMUs in tpu broken
has caused the Debian Bug report #916209,
regarding britney: handling of binNMUs in tpu broken
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
916209: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=916209
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message ---
Package: release.debian.org
Severity: serious
User: release.debian.org@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 <ivodd@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 <ivodd@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


--- End Message ---
--- Begin Message ---
This bug is fixed in the current britney code.

The fix is based on 2 changes:

- a migration cannot cause binary and source versions to go backwards
- binNMUs from *pu now also need an unblock (just like sources).

Ivo

--- End Message ---

Reply to: