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:/ /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=commitdif f;h=a98951a30a6 ae603ffac4ec8c5 168aa6d1019933
To also use that option. Please confirm if this fixes the Problem in your build environment.