Bug#1064427: [Britney] blocks a binNMU if a binary takeover of that package is in progress

2024-02-29 Thread Dalton Durst
Like #1064428, copying things here that we discussed on IRC... Sorry if I was unclear. The title is indeed incorrect if the binary takeover is arch:all. I think the behavior is alright. If that's true, it should probably be tested for, because it might be unexpected and broken by future

Bug#1064428: [Britney] does not migrate new arch:all packages after initial migration of same source

2024-02-29 Thread Dalton Durst
To copy comments from our discussion in IRC... In my case, blocking a migration until the entire Package-List is filled out or waiting for arch: all binaries if the source package lists all as an architecture does not solve the problem. I regularly put Britney2 in situations where a package

Bug#1064428: [Britney] does not migrate new arch:all packages after initial migration of same source

2024-02-22 Thread Dalton Durst
ge entirely. On Wed, Feb 21, 2024, at 11:59 PM, Paul Gevers wrote: > On 21-02-2024 23:50, Dalton Durst wrote: > > > If the > > package were binNMU'd, though, britney would migrate everything > > including the arch:all package if it passed checks. > > In Debian, binNMU-in

Bug#1064428:

2024-02-21 Thread Dalton Durst
Sorry, missed the links mentioned by [1] and [2] in the above mail. [1] https://salsa.debian.org/release-team/britney2/-/commit/b1603db2e459a2499de76d38179e49107d46be9d#7440b429abaafd59360558493c5473fab20e5088_0_425 [2]

Bug#1064428: [Britney] does not migrate new arch:all packages after initial migration of same source

2024-02-21 Thread Dalton Durst
Package: release.debian.org Severity: normal Usertags: britney Consider the following situation: test-src migrated after its amd64 and i386 binaries appeared. It also has architecture-independent binaries that miraculously only showed up after migration was complete (maybe someone hinted through

Bug#1064427: [Britney] blocks a binNMU if a binary takeover of that package is in progress

2024-02-21 Thread Dalton Durst
Package: release.debian.org Severity: normal Usertags: britney Consider the following situation: * pkga produces takeover and pkga1 - it is already in testing * pkgb is taking over takeover and also produces pkgb1 - it is not a candidate for migration because it is missing a build