• Bug#1109607: devscripts: GPG part of tests starting to fail

    From James McCoy@21:1/5 to Yadd on Mon Jul 21 23:10:02 2025
    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).

    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,
    --
    James (he/him)
    GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7 2D23 DFE6 91AE 331B A3DB

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Holger Levsen@21:1/5 to James McCoy on Tue Jul 22 13:10:01 2025
    control: severity -1 important
    thanks

    On Mon, Jul 21, 2025 at 05:03:10PM -0400, James McCoy wrote:
    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.

    downgrading accordingly, also because this is resolver specific.

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

    yes, I also noticed and am not happy with this. Also because gnupg has a lot more depends than gpg...


    --
    cheers,
    Holger

    ⢀⣴⠾⠻⢶⣦⠀
    ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org
    ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
    ⠈⠳⣄

    "We are running the most dangerous experiment in history right now, which is
    to see how much carbon dioxide the atmosphere can handle before there is an environmental catastrophe."
    Source: Elon Musk speech at Paris-Sorbonne University, December 2, 2015.

    -----BEGIN PGP SIGNATURE-----

    iQIzBAABCgAdFiEEuL9UE3sJ01zwJv6dCRq4VgaaqhwFAmh/b58ACgkQCRq4Vgaa qhzraBAAninifSyjJG6B9ydA0WOqSfzuTJnmKjmv8xJqw9eKSbLptu6+Qq4FZt9H YOkUPl0NdnbwrEywEa3cH9oJ1qkUBy7Zwjyg4f16rqJIvsPn4QOkwn+T1F5lIPbC c+a4VT2OgtKCYYHc4yfqyonP2TWlMEuBo56KYHueyUPYZfrCk3k/4CDzVQx+lrTT HUUldNL3LO1QDkWJetEioB3e22C+fSdLSkn77Q1xXcFNJfuYGPE6ZmjJggWdRmpG gdkgbz5Odc4YARPh8N1oELamaHqCvatr128E3mpYJSEh68qwE7rBmRgZZQ4KfX00 PM4eW+SMUqHl6MylsyMa67/tn2ZRB/A0iTathRTlr1GMx9X76u5D9L2FhHDkXcsd Z1Z55kUB4bEE+ZYeU9HyGN+4dlqTSbTF6JCeC3MkdfJl38B1SAamYW