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.
signature.asc
Description: This is a digitally signed message part
