Comment 25 for bug 1647204

Revision history for this message
Andre Heinecke (aheinecke) wrote :

> https://www.python.org/dev/peps/pep-0524/

This has nothing to do with it. GpgME does not gather the entropy / randomness itself but leaves this to libgcrypt / gpg-agent. On Linux system this means to add some entropy from /dev/random into the mix. If nothing is available there it will block indefinitely until enough entropy is available.

So I agree with dkg's suggestion that a lack of entropy in your build environments is a likely explanation.
I can reproduce a fairly long hang by starving my system of entropy using "cat /dev/random > /dev/null" and then running make check.

It could be worked around by something like "rngd -r /dev/urandom" but the testsuite should not rely on hard entropy. GnuPG's testsuite itself includes a solution to that problem, launching gpg-agent with --debug-quick-random.

I've changed the start script of the gpg-agent in gpgme accordingly with:

https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gpgme.git;a=commitdiff;h=a98951a30a6ae603ffac4ec8c5168aa6d1019933

To also use that option. Please confirm if this fixes the Problem in your build environment.