[pkg-gnupg-maint] Bug#868550: Bug#868550: reprepro seems to provide a repro

[Ian Jackson]

> Here's the stderr output from one of the tests:
> 
> + gpg --detach-sign --armor -u 39B13D8A /home/ian/things/Dgit/dgit/tests/tmp/debpolicy-quilt-gbp/example/.git/dgit/tag.tmp
> gpg: WARNING: unsafe permissions on homedir '/home/ian/things/Dgit/dgit/tests/tmp/debpolicy-quilt-gbp/gnupg'
> gpg: agent invoked successfully, but...
> gpg: can't connect to the agent: IPC connect call failed
> gpg: skipped "39B13D8A": No secret key
> gpg: signing failed: No secret key
> WARNING - GNUPG FAILED 2 - STUNT GNUPG  --detach-sign --armor -u 39B13D8A /home/ian/things/Dgit/dgit/tests/tmp/debpolicy-quilt-gbp/example/.git/dgit/tag.tmp

I put a wrapper around my gpg wrapper, so that only one copy of gpg
could be invoked across the whole set of parallel tests, in case the
different processes were sharing something I wasn't aware of.

That didn't seem to make much difference.  I think this demonstrates
that the failure can occur with entirely sequential gnupg invocations.

I did notice that at one point all the tests seemed to get stuck for a
bit, but they recovered.  What seems to have happened is that one of
the tests' gpg invocations failed, and that was caught by my retry
script.  The retry script has a "sleep 10".  So all the other tests
that wanted to use gpg had to wait.  I think this just demonstrates
that my locking arrangements were working.

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.