[pkg-gnupg-maint] Bug#868550: Bug#868550: reprepro seems to provide a repro
ijackson at chiark.greenend.org.uk
Sun Jan 7 11:46:53 UTC 2018
> 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 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.
More information about the pkg-gnupg-maint