[pkg-gnupg-maint] Bug#902316: gnupg failing completely in dgit autopkgtests [and 1 more messages]

[Ian Jackson]

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 <ijackson at 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.