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
