Your message dated Sat, 5 Jan 2019 14:35:14 +0100 with message-id <20190105133511.juc74w5ghu4fz...@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 ow...@bugs.debian.org immediately.) -- 916209: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=916209 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
--- Begin Message ---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
--- 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 ---
