[pkg-gnupg-maint] Bug#902316: Bug#902316: gnupg failing completely in dgit autopkgtests [and 1 more messages]
ijackson at chiark.greenend.org.uk
Fri Jun 26 21:18:17 BST 2020
Daniel Kahn Gillmor writes ("Re: [pkg-gnupg-maint] Bug#902316: gnupg failing completely in dgit autopkgtests [and 1 more messages]"):
> Hi Ian--
> I don't know what the current status of the failing tests suites is for
> dgit -- last i heard, you had to have major, clunky workarounds to avoid
> problems with concurrent access to gpg-agent, or else gpg-agent would
> (intermittently, unpredictably) fail on some requests.
> Please correct me if that description is wrong. It sounds pretty
Hi. The workarounds are horrific, yes. That description is accurate.
These workarounds have been working, so I don't know what bug(s)
> I'd like to nudge upstream about this, but getting feedback in the wild
> would be really useful.
> I don't know whether you have any patience left to experiment with this,
> or whether you're still using gpg at all, but if you are, this would be
> a useful test for me:
> - set aside the scaffolding you used as a workaround to avoid these
> - reproduce the failure
> - add "auto-expand-secmem" to the relevant gpg-agent.conf before you
> start the agent for dgit
> - try to reproduce the failure again
Why do you think this option might make any difference ? Doesn't
whatever condition it avoids produce an error message somewhere ?
I remember being fairly convinced that the real problem was simply
that gnupg and its various daemonic subprocesses didn't have a
race-free startup/shutdown approach. From the sound of the option
that doesn't seem likely to be the issue.
> Sorry for the hassle here, and i hope this is useful in moving the
> situation forward. (if you've given up, that's also fair -- please let
> me know if that's the case so i can try to track down the errors in a
> more synthetic context).
At the very least I could point you to the tests.
The test site is src:dgit and is a standard autopkgtest suite which
you can run via adt-run. But to run the tests ad-hoc in a highly
[ install the test dependencies, sorry I don't know
a better way than to read debian/test/control and prat
dgit clone dgit # or git clone salsa something something
If you have `nproc' installed it will parallelise.
I forget precisely how to disable the workarounds, but I think,
in tests/setup/gnupg, comment out the line
and I think all the several bodges hang off that.
This way of disabling the bodges will also disable passing some other
options to gpg-agent, notably --debug-quick-random, which I don't
think there was a way to easily control other than by wrapping
AFAICT the bodges are in
and tests/tstunt/gpg-locked is a previous attempt which is no longer
Ian Jackson <ijackson at chiark.greenend.org.uk> These opinions are my own.
Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.
More information about the pkg-gnupg-maint