Ian Jackson writes ("Re: Bug#902316: gnupg failing completely in dgit
autopkgtests [and 1 more messages]"):
> I attempted to work around this problem by explicitly starting and
> stopping the gpg-agent. This has dramatically reduced the failure
> probability.
...
> I am going to try even more ridiculous workarounds.
Well, I have managed to get it to pass with dgit 5.5+exp7, in
experimental, in the ci's "unstable" queue. My workarounds include:
* A global lock (for the whole test suite, in case anything is going
in parallel) which arranges that only one gnupg is ever run at
once
* When I want to run gnupg with a particular GNUPGHOME I use
gpg-connect-agent to kill any existing agents, repeatedly if need
be until it prints "no gpg-agent running".
* I then start an agent of my own (with a loop to wait for it to be
ready), run gpg, and use gpg-connect-agent to shut it down again.
(again, with a loop).
This involves two nexted wrapper scripts, one to take the lock and one
to mess with gpg-agent. In fact I also have a wrapper script for
gpg-agent so that I can pass --debug-quick-random.
With this I no longer seem to need the wrapper that would try to run
gpg again when it failed. That wasn't a very good workaround anyway.
I intend to merge my new workarounds into unstable soonish.
In the meantime I will leave this bug open because it is still a repro
recipe for a startup race bug: run the dgit 5.5 test suite (with
"whatever is in sid in late June 2018") in ci.debian.net.
Ian.
--
Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
