Re: Why is ggml not migrating?
On Mon, Dec 08, 2025 at 08:35:42PM +0100, Christian Kastner wrote:
> Hi Adrian,
Hi Christian,
> On 2025-12-08 19:57, Adrian Bunk wrote:
> > 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:
> >> 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.
>
> the short explanation is that ggml needs two uploads:
> (1) src:ggml for regular ggml and the DFSG-free backends
> (2) binary-only build for bin:libggml0-backend-cuda
>
> There's a write-up on this [1] here. But the general idea is that
> previously, to address (2), people usually maintained an entire separate
> fork of the source (where upstream is even binary-identical), which is
> cumbersome, less discoverable, and adds maintenance burden all around.
>
> That's what I originally did for src:ggml, I had a src:ggml-cuda which
> was a copy built just the one backend [2].
>
> Since the CUDA stuff isn't auto-built anyway, and I need to build
> locally, I didn't think it would matter whether I used a build profile
> for that.
>
> ftp-master was OK with this. I didn't think to ask the RT as I didn't
> occur to me that this could be an issue.
>...
I am not a member of the RT, but having binaries from the same source
package built in two different ways in the archive sounds just wrong.
I am someone who does sometimes over 100 NMUs for RC bugs in a single
week - after an NMU the CUDA packages would just silently disappear?
A variant of that would be if someone other than you prepares a security
update for stable.
A similar issue is also present for downstream distributions like
Ubuntu or Raspbian, that might have different rules regarding what
is autobuildable for them.
A successful "dpkg-buildpackage -b" producing all binary packages is
a pretty fundamental assumption in various places.
>...
> people usually maintained an entire separate
> fork of the source (where upstream is even binary-identical), which is
> cumbersome, less discoverable, and adds maintenance burden all around.
>...
Regarding "cumbersome" and "maintenance burden", you are anyway doing
two uploads every time you update ggml. Something like the script you
used can just automate building src:ggml-cuda and then upload both.
This also removes the cumbersome maintenance burden for others to be
aware that your package is doing something very special and unexpected.
Regarding "discoverable", the profile approach is far worse.
People doing QA are doing archive rebuilds also for contrib and non-free,
which won't cover binary packages hidden behind a profile.
The security tracker would also not notice if there are binary packages
that have not been rebuilt, leaving users vulnerable to a fixed CVE.
> Best,
> Christian
>...
cu
Adrian
Reply to: