Hi!

The just uploaded dpkg, got support for sqv, which is now installed by
default on minimal chroots due to apt pulling it in on some
architectures (instead of gpgv). But this support relies on new interfaces added in sqv 1.3.0.

On hurd-* and x32 ports, sqv looks outdated, which means it is present
but not new enough to be usable by dpkg, which makes it fail its test
suite (which will try to test it opportunistically).

To fix dpkg FTBFS, either a newer sqv needs to be built on those
ports, or maybe easier removed from now and then dpkg given back.
(apt might also need to be given back to pick up gpgv instead of sqv,
but have not checked, and maybe apt just works out of the box.)

Thanks,
Guillem

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hello,

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.

Samuel

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi!

On Mon, 2025-05-19 at 09:28:04 +0200, John Paul Adrian Glaubitz wrote:

On Mon, 2025-05-19 at 08:31 +0200, Guillem Jover wrote:

The just uploaded dpkg, got support for sqv, which is now installed by default on minimal chroots due to apt pulling it in on some
architectures (instead of gpgv). But this support relies on new interfaces added in sqv 1.3.0.

Shouldn't dpkg then get a versioned build-dependency for sqv >= 1.3.0.

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).

FWIW, on x32, rustc needs to be rebootstrapped but last time I tried this several months ago, it didn't work. I will try that again later this month.

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.

Thanks,
Guillem

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Guillem,

On Mon, 2025-05-19 at 08:31 +0200, Guillem Jover wrote:

The just uploaded dpkg, got support for sqv, which is now installed by default on minimal chroots due to apt pulling it in on some
architectures (instead of gpgv). But this support relies on new interfaces added in sqv 1.3.0.

Shouldn't dpkg then get a versioned build-dependency for sqv >= 1.3.0.

FWIW, on x32, rustc needs to be rebootstrapped but last time I tried this several months ago, it didn't work. I will try that again later this month.

Adrian

--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Samuel Thibault, le lun. 19 mai 2025 10:35:18 +0200, a ecrit:

Guillem Jover, le lun. 19 mai 2025 10:20:06 +0200, a ecrit:

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.

But better rebuild apt first? Otherwise in the meanwhile the whole
distrib becomes uninstallable and nothing will build, we cannot recreate chroots, etc.

(and I'd have to see how to do that rebuild, since to avoid sqv
installed for apt not to pick it up, that'd mean removing the apt
package in the build chroot...)

I have now rebuilt apt without sqv by removing sqv and apt between
chroot setup and package build. dpkg then built fine on hurd-amd64, it's pending later today on hurd-i386.

Samuel

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)