For reference our downstream tracker of this is https://bugs.gentoo.org/683254 including patches

So, the keyserver operator had thrown in a hockeypuck server in the pool, causing this.. While the keyserver remains in the exclude list until confirmation it has been resolved, that explains the behavior and it has been made clear that separate software needs to use different names in the future.

I believe this would be a good improvement in user experience

hkps pool really should be the most responsive, and it already requires clustered only servers for a couple of weeks to try to increase the responsiveness. Experience has shown that any keyserver with less than 3 nodes in a cluster should not be used towards end-users. But do you have any more debugging output as to the problem at hand?

The patch is available in our downstream bugtracker as attachment to https://bugs.gentoo.org/646194

Thanks, that is interesting info, I need to look into that.

I'm not entirely sure whether it is due to low usage or little problems with the service, but it seems to work pretty OK. My primary concern is that as opposed to DNS based system, the onionbalance system requires my node to be running and available and as such constitutes a SPOF. Although I've cleaned up my scripts sufficiently, e.g network outage will make this service unavailable whereby the hkps pool will continue to function.

In T3331#101967, @werner wrote:

If you don't have a TCP enabled OS, you can use configure --disable-dirmngr.

I'm not sure if this post ever made it into a bug report, but has master been tested with tiling WM like awesome to see if issue is fixed? https://lists.gnupg.org/pipermail/gnupg-devel/2017-February/032608.html (if not I'm sure robbat2 is helpful enough with that if picking up the thread)

as a quick fix something like the attached seems to avoid the immediate issue{F166535}

Issue seems to be gone in gpg (GnuPG) 2.1.22-beta75

Additional info: I tried setting up a reproducer without using a smartcard, and it fails with no secret key similar to earlier versions

How about _pgpkey-http._tcp. record?

The downstream issue does not persist in gcc 4.9.3 but triggers for 4.8.5

Fwiw we're tracking this downstream as "dev-libs/libgcrypt-1.7.0: impossible
constraints on 'asm' operand" - https://bugs.gentoo.org/show_bug.cgi?id=580270

Thanks, I can confirm that this solves it.

As an additional point, the client max body size in nginx defaults to 1 MiB[0].
Currently no checking is done for larger request bodies for inclusion in the
keyserver pools. Apache does not have such a limit by default.

Reference:
[0] http://nginx.org/en/docs/http/ngx_http_core_module.html#client_max_body_size

looks good to me

Thanks, but I'm afraid that's not sufficient; the issue of the whitespace after
have_qt5_libs still exists after that commit for bash.

See the following test case: $ cat ./test.sh
#!/bin/bash
have_qt5_libs="no";
echo ${have_qt5_libs}

have_qt5_libs2 = "no";
echo ${have_qt5_libs2}

$ ./test.sh
no
./test.sh: line 5: have_qt5_libs2: command not found

The good news is that besides this buglet I've now pushed the updated revision
to our testing repository and have yet to get any bug reports. The patch I've
pushed is
https://gitweb.gentoo.org/repo/gentoo.git/tree/app-crypt/pinentry/files/pinentry-0.9.6-add-disable-pinentry-qt5-option.patch#n38
which doesn't experience this issue.

"+ have_qt5_libs = no;" result in command not found issues in configure so I
changed this to "+ have_qt5_libs="no";".

I've done some preliminary packaging tests and things seems to be working as
expected, will give it some more local testing before pushing it onto users in
testing

Thank you, that is exactly the kind of mechanism I was looking for. I'll give it
a try to packaging over the next few days.