On Fri 2026-08-21 17:29:06 +0000, John Scott wrote: > Andreas Metzler wrote: >> does the incus virtualisation provide /run/user/nnn? gpg-agent requires it.
It seems likely to me that /run/user/nnn is provided if only because the debian/tests/simple-tests seems to succeed, and that test requires key generation and signing, both of which should use gpg-agent at least. > I want to assert that, if this were the culprit, it's still wrong for > our autopkgtest to fail, and this failure may be pointing out a > genuine issue to us. Indeed, gpg is brittle, and we might be able to identify some additional brittleness, regardless of whoever's (good!) idea produced /run/user/nnn If we can diagnose it, we should report back to upstream. If https://dev.gnupg.org/ is back up by then, opening an issue in the issue tracker would be good. otherwise, it's probably worth mailing [email protected] I haven't been able to replicate the failure myself, but maybe someone who can replicate it with incus could try it by increasing the logging of the agent in that script and then looking at the artifact directory produced by the failing test. With the following patch to the gnupg2 package: --- a/debian/tests/verify-openpgp +++ b/debian/tests/verify-openpgp @@ -126,6 +126,11 @@ librepgp() { local GNUPGHOME="$WORKDIR/librepgp-$profile" export GNUPGHOME mkdir -p -m 0700 "$GNUPGHOME" + cat > "$GNUPGHOME/gpg-agent.conf" <<EOF +debug-level guru +debug-all +log-file $GNUPGHOME/gpg-agent.log +EOF if [[ "$profile" =~ default ]]; then algo="$profile" # this is a dummy placeholder: Then the debug logs should be visible in the CI artifact directory as: workdir/librepgp-*/gpg-agent.log If anyone manages to get any results (even if you don't know how to interpret the gpg-agent logs), please follow up on this debian issue. Thanks! --dkg
