From my pbuilder build log:

...
   debian/rules override_dh_auto_test
make[1]: Entering directory '/build/python-apt-1.4.0~beta2'
set -e; for python in python2.7 python3.5 ; do \
$python tests/test_all.py -q || [ "linux" = "hurd" ]; \
done;
[tests] Running on 2.7.13 (default, Feb  9 2017, 10:00:34) [GCC 6.3.0 20170205]
Using library_dir:
'/build/python-apt-1.4.0~beta2/build/lib.linux-x86_64-2.7'WARNING:
Failed to read mirror file
WARNING: Failed to read mirror file
WARNING: Failed to read mirror file
WARNING: Failed to read mirror file
WARNING: Failed to read mirror file
WARNING: Failed to read mirror file
WARNING: Failed to read mirror file
WARNING: Failed to read mirror file
======================================================================
ERROR: testAddKeyFromServer (test_auth.TestAuthKeys)
Install a GnuPG key from a remote server.
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/build/python-apt-1.4.0~beta2/tests/test_auth.py", line 230,
in testAddKeyFromServer
    "hkp://localhost:%d" % self.keyserver_port)
  File "/build/python-apt-1.4.0~beta2/build/lib.linux-x86_64-2.7/apt/auth.py",
line 129, in add_key_from_keyserver
    _add_key_from_keyserver(keyid, keyserver, tmp_keyring_dir)
  File "/build/python-apt-1.4.0~beta2/build/lib.linux-x86_64-2.7/apt/auth.py",
line 157, in _add_key_from_keyserver
    keyserver, keyid))
AptKeyError: recv from 'hkp://localhost:19191' failed for
'0xa1bD8E9D78F7FE5C3E65D8AF8B48AD6246925553'
----------------------------------------------------------------------
Ran 94 tests in 11.363s

FAILED (errors=1, skipped=3)
debian/rules:50: recipe for target 'override_dh_auto_test' failed
make[1]: *** [override_dh_auto_test] Error 1
make[1]: Leaving directory '/build/python-apt-1.4.0~beta2'
debian/rules:16: recipe for target 'build' failed
make: *** [build] Error 2
dpkg-buildpackage: error: debian/rules build gave error exit status 2
-- 
Daniel Schepler

Control: tag -1 moreinfo

Retry it. Maybe it timed out or something.

I just retried it 5 times, and got 5 more failures.

retitle 856152 python-apt: FTBFS: AptKeyError: recv from 'hkp://localhost:19191' failed for '0xa1bD8E9D78F7FE5C3E65D8AF8B48AD6246925553'
thanks

Julian Andres Klode wrote:

I don't think this is a timeout issue, but if it is, surely the package
build should be a little more reliable? :)


Regards,

Control: severity 856152 important

Well, it's some GPG issue, we can't figure out every GPG thing.

This works fine with an up-to-date sid chroot in sbuild, so I don't
really care, or well, can't reproduce it. Seems more like a pbuilder
related issue.

Control: reassign -1 dirmngr 2.1.18-6
Control: retitle -1 dirmngr: Fails to resolve localhost and loopback addresses when only a loopback interface is available

So the issue here is that, by default, pbuilder runs the build in a
separate network namespace with only a loopback interface configured.
The loopback interface works, you can bind and connect as normal
(otherwise this would have been found a long time ago), but getaddrinfo
has a slightly interesting deviation from POSIX. POSIX states[1]:

However, glibc's manpage states this:

Note that in fact glibc is in agreement with RFC 3493, which has the
following modified version of POSIX's definition (thanks to Olly Betts
for finding this):

Now, GPG is using getaddrinfo with AI_ADDRCONFIG[2]. I have yet to
confirm that this is the issue here, but #853107 is a very similar bug,
and removing the AI_ADDRCONFIG flag makes the build succeed.

I don't know what the solution should be. Glibc's implementation seems
sensible in the general case, but horribly broken when resolving
localhost/127.0.0.1 with just a loopback interface up, which should be a
perfectly valid thing to do. I believe that trying to build on a machine
without a non-loopback interface up would also run into this bug, which
is a rare situation these days, but not completely out of the question.
In my opinion, glibc should not be ignoring the loopback address in this
case, but I don't know whether that's easily possible in general and
whether it would break existing programs. For pbuilder I guess we could
work around it by bringing up a separate virtual interface, but I really
don't like that idea, and it doesn't solve the problem of building on
machines without a non-loopback interface.

Here is a reproduction of the issue with plain GPG. I have a local SKS
instance bound to 127.0.0.1:11371 which contains a single key. I had to
kill dirmngr in between because it seems to cache lookups.

Regards,
James

[1] http://pubs.opengroup.org/onlinepubs/9699919799/functions/getaddrinfo.html
[2] https://sources.debian.net/src/gnupg2/2.1.18-6/dirmngr/dns-stuff.c/#L839

(jrtc forgot to untag this...)

It also fails on my system now since I switched from dnsmasq to
systemd-resolved. That's really annoying.

Hi all,

Is anyone working on getting this fixed? I'm hereby offer a hand, or
two, to help with debugging, etc.

Thanks,
cheers,
Georg

Just a quick note that it's probably the same thing that is tracked in
glibc's #844420 (glibc FTBFS in pbuilder due a test failing to resolve
localhost).

I doubt it. The bug in #844420 is that glibc fails to resolve entries
from /etc/hosts when they are fully qualified. It means with the
standard /etc/hosts, it fails to resolv "localhost." but succeed in
resolving "localhost".
In the python-apt bug, it seems that the entry to be resolved is
"localhost".