[pkg-gnupg-maint] Bug#1144784: gnupg2: autopkgtest fails under incus-lxc: FAILURE: Failed to generate --compliance=gnupg ed25519/v5+cv25519/v5

[John Scott]

Andreas Metzler wrote:
> does the incus virtualisation provide /run/user/nnn? gpg-agent requires it.

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.

If Incus—or any container/virtual environment, for that matter—didn't provide /run/user/$UID, I don't see how that would be the caller's error. At the very least, GnuPG needs to provide a better error message in this case. It is a legitimate problem for our users if they're stuck with "General error" when GnuPG doesn't work in their legitimate environment.

Second, a web search tells me that /run/user/$UID is an invention of pam_systemd. This is intended to be used as $XDG_RUNTIME_DIR (an environment variable that GnuPG intentionally does not use; see the comments in the source code). If that isn't set and /run/user/$UID doesn't exist, the standard advice at https://specifications.freedesktop.org/basedir/latest/#variables ought to apply. In particular, we should arrange for gpg-agent to put its stuff into $AUTOPKGTEST_TMP, try to make /run/user/$UID ourselves with the right permissions, or else—if using gpg-agent outside of a PAM+systemd session is not supported—make libpam-systemd a hard dependency of gpg-agent, make the test run "skippable", and skip it when we're not in such a session and unable to make one.

Neither the Filesystem Hierarchy Standard nor Debian Policy require /run/user/$UID, so the test shouldn't fail in such a legitimate configuration.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 411 bytes
Desc: This is a digitally signed message part
URL: <http://alioth-lists.debian.net/pipermail/pkg-gnupg-maint/attachments/20260821/bf7153d7/attachment.sig>