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

Bug#1063820: faketime does not fake timestamps in stat(1) or ls(1)

2024-02-12 Thread Dalton Durst
Package: faketime X-Debbugs-Cc: deb...@daltondur.st Version: 0.9.10-2.1+b1 Severity: normal Dear Maintainer, faketime and libfaketime in and after Debian 11 (bullseye) do not fake timestamps to common commands which use the statx syscall, such as stat(1) or ls(1). Instead, the on-disk timestamps

Bug#1034792: libreoffice-sdbc-postgresql: cannot be coinstalled with libreoffice-nogui, which recommends it

2023-04-24 Thread Dalton Durst
Package: libreoffice-sdbc-postgresql Version: 4:7.4.5-2 Severity: normal Dear Maintainer, libreoffice-sdbc-postgresql has an odd dependency chain which prevents its coinstallation with libreoffice-nogui. libreoffice-nogui, however, Recommends libreoffice-sdbc postgresql. This can cause Apt to