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

Binary uploads to stable (was Re: Why is ggml not migrating?)



On Mon, 2025-12-08 at 20:57 +0200, Adrian Bunk wrote:
> Adam, could something be done about binary uploads to stable?
> 
> While looking at this I noticed the following:
> /srv/ftp-
> master.debian.org/buildinfo/2025/12/08/diffoscope_297+deb13u1_amd64.b
> uildinfo: DEB_BUILD_PROFILES="nocheck"
>  55def2d8401ffe167e9b06f781852e0dda683e76cae09890a485a8900118264e
> 5075 diffoscope_297+deb13u1.dsc
>  494dc4e3cb210c6168e1bf371036afefd26aa13d4004f450d964f9c1d39d7f5f
> 155908 diffoscope-minimal_297+deb13u1_all.deb
>  58187a04b064ad8e25fc1b08e0214f4abb4231ac71fc3879adb8109fc5dd3a01
> 41628 diffoscope_297+deb13u1_all.deb
> 
> The nocheck is not even the biggest problem, but could the queue 
> viewer[1] flag such maintainer-built binaries in (old)stable-pu-new?
> 
> It defeats the whole reproducible effort when binaries are accepted
> in pu, and binary-all does not even allow a binNMU.

queue-viewer *does* flag maintainer-built binaries, albeit not with a
big flashing siren. The "architectures" column for a package in (o)pu-
new lists those present, and should usually list "source" (excepting
syncs from security.d.o, obviously).

If you check the entry for diffoscope there, you will notice that it
doesn't list any binaries. Indeed there are no diffoscope binary
packages currently in stable-new, just the source.

> emacs-libvterm/bookworm[1] would be a recent example of a package
> with binaries accepted.

That was simple human error. For some reason I thought that there had
been a trip through NEW involved, but I was clearly mistaken.

Regards,

Adam


Reply to: