On 7/21/25 23:03, James McCoy wrote:
On Mon, Jul 21, 2025 at 02:43:21AM +0200, Yadd wrote:
On 7/21/25 02:20, Yadd wrote:
On 7/20/25 20:47, Yadd wrote:
Starting from today, test_mkorigtargz, test_debsign and some
test_uscan*
fail due to some gpg errors:
- short keyid looks forbidden now
- $GPGHOME should be chmod 700
- even after this 2 fixes, tests continue to fail with "invalid
signature" or other unclear messages
I did my best for 3 hours without finding what is different between
testing an unstable (test pass locally on testing).
Hope someone will find what happened and succeed to fix the test.
This isn't showing up in ci.debian.net, but it is showing up in Salsa.
That suggests there's something specific about the Salsa environment
that's causing this.
Found why: the package "gpg-from-sq" is declared as "Provides: gpg (=
2.2.46)" but is unusable here. When installing the real gpg and drop
gpg-sq, the test pass...
So the fix is easy: replace "gpg" by "gnupg" in (build-)?dependencies.
Since I pushed 2.25.16 into experimental with uscan changes, I think
the way to fix Trixie is to push a 2.25.15+deb13u1 (or 2.25.15.1 ?).
That reverts an explicit decision to move away from Depending on gnupg
in 1ffd7004b913ab2f898cdc91215ac7db17d41ead (and MR !492).
Maybe for Trixie we could use gnupg as build-dependency and keep gpg
virtual package in dependencies? This will fix the issue.
Then after we could fix tests to use gpg.
An alternative would be to not provide "gpg" into "gpg-from-sq"
because it has not the same coverage than gnupg.
Which way is preferred ?
Ccing guillem (as author of said MR) and dkg (for general knowledge in
this space) to see if they can chime in.
Cheers,
