Re: dpkg FTBFS on ports (hurd, x32) with outdated sqv
Hi!
On Mon, 2025-05-19 at 09:58:07 +0200, John Paul Adrian Glaubitz wrote:
> On Mon, 2025-05-19 at 09:49 +0200, Guillem Jover wrote:
> > sqv is not available on all ports, so that would make it fail on all
> > those ports then. I think a versioned build-conflicts would have been
> > better (but I didn't think there would be outdated versions), but that
> > would then make it uninstallable on the affected ports anyway. Using an
> > arch-restricted build-dependency would be another alternative but I don't
> > feel like tracking where sqv is available over time on dpkg's build
> > dependencies (this seems wrong to me), and would also not fix the issue at
> > hand (on the affected ports dpkg would either be uninstallable, or if not
> > listed, still fail due to the binary being present but not new enough).
>
> So, what does it then use at the moment? How does it figure out whether sqv
> is available or not. You somehow have to whitelist the architectures with
> sqv, no?
dpkg has multi-backend OpenPGP support and will try to use any of the
backends it supports if the commands are available: gpg/gpgv,
gpg-sq/gpgv-sq, sq/sqv, or any available SOP/SOPV implementation
(sqop/sqopv, rsop/rsopv, gosop, pgpainless-cli.
If sqv is not available it will fallback to any other alternative, or
for the particular test suite, it will just skip the tests.
On Mon, 2025-05-19 at 10:03:02 +0200, Samuel Thibault wrote:
> John Paul Adrian Glaubitz, le lun. 19 mai 2025 09:58:07 +0200, a ecrit:
> > > If getting a new sqv version built is going to be too hard or time
> > > consuming for now, then perhaps removing the sqv binary packages from
> > > the port (like it's the state for several other ports) is the quickest
> > > fix to be able to build dpkg, as I mentioned in my original mail.
> >
> > Well, this is something Aurelien has to do. I don't have any access to
> > the Ports FTP servers, so I can't just easily remove packages, unfortunately.
>
> On hurd-any at least, apt currently depends on sqv, so removing sqv
> would make apt uninstallable.
Yes, as mentioned on my original mail, going this route might require
rebuilding apt. Checking now, it seems apt will also become a problem,
because if it gets built it will unconditionally generate a strict
versioned dependency on «sqv (>= 1.3.0)» if the /usr/bin/sqv program
is found, which would not be satisfiable on hurd-*. Checking apt now,
I see «apt/debian/rules:override_dh_gencontrol», and
«apt/CMakeLists.txt:.*SQV_EXECUTABLE» and
«apt/methods/CMakeLists.txt:.*sqv».
So I think removing the binary packages, and rebuilding both apt and
dpkg would be the best course of action.
Thanks,
Guillem
Reply to: