Re: Why is ggml not migrating?
On Mon, Dec 08, 2025 at 05:42:45PM +0000, Adam D. Barratt wrote:
> On Mon, 2025-12-08 at 08:47 +0100, Christian Kastner wrote:
> > the tracker page for ggml [1] says it's blocked, but the "issues
> > preventing migration" point is empty.
>
> The cron log for the most recent britney run includes:
>
> I: [2025-12-08T16:04:14+0000] - signer mismatch for libggml0-backend-cuda (ggml 0.9.4-5) on amd64: christian@kvr.at, while buildd_amd64-x86-ubc-01@buildd.debian.org already listed
> I: [2025-12-08T16:04:14+0000] - signer mismatch for libggml0-backend-vulkan (ggml 0.9.4-5) on amd64: buildd_amd64-x86-ubc-01@buildd.debian.org, while christian@kvr.at already listed
>
> What appears to have happened is that you uploaded binary packages for
> amd64, including the two listed above. A binNMU was then scheduled so
> as not to block migration, but which did _not_ build the listed
> packages.
Paul, is it a known Britney bug that this is not listed in excuses?
> There are thus amd64 binary packages from the 0.9.4-5 source in
> unstable built from two different uploads, one signed by you and one by
> the buildd. That situation seems to be confusing britney (not
> unreasonably).
I'd guess for the Deep Learning Team it's really confusing when binaries
must be uploaded, and when they must not be uploaded, since everything
CUDA is in non-free/contrib and cannot be autobuilt but non-CUDA
packages are in main and should be upoloaded source-only.
> A new source upload would resolve that issue, but I've not checked the
> packaging in terms of what the expected outcome for the two packages
> listed above is.
Christian, this looks wrong:
/srv/ftp-master.debian.org/buildinfo/2025/12/04/ggml_0.9.4-4_amd64.buildinfo: DEB_BUILD_PROFILES="pkg.ggml.cuda"
/srv/ftp-master.debian.org/buildinfo/2025/12/04/ggml_0.9.4-4+hip~exp2_amd64.buildinfo: DEB_BUILD_PROFILES="pkg.ggml.cuda"
/srv/ftp-master.debian.org/buildinfo/2025/12/04/ggml_0.9.4-5_amd64.buildinfo: DEB_BUILD_PROFILES="pkg.ggml.cuda"
/srv/ftp-master.debian.org/buildinfo/2025/12/04/ggml_0.9.4-5+hip~exp1_amd64.buildinfo: DEB_BUILD_PROFILES="pkg.ggml.cuda"
Building with profiles is sometimes required for bootstrapping something
in the archive, but it shouldn't be part of regular uploads.
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.buildinfo: 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.
emacs-libvterm/bookworm[1] would be a recent example of a package with
binaries accepted.
> Regards,
>
> Adam
cu
Adrian
[1] https://release.debian.org/proposed-updates/stable.html
[2] https://buildd.debian.org/status/package.php?p=emacs-libvterm&suite=bookworm
Reply to: