On Tue, Jan 31, 2017 at 10:09:57PM +0100, Georg Faerber wrote:
> > Daniel: What version of pbuilder are you using? If it's more than a
> > year old, then upgrading will probably fix this. If not, then either
> > that fix has regressed in pbuilder regression, or else something more
> > complex is going on.
>
> This is happening here [1] as well, which is a recent pbuilder version,
> I guess. I'm wondering if this is a bug in pbuilder or a wrapper around.
>
> Cheers,
> Georg
> (who debugged for some hours a similar problem over here [2]...)
Did you reach any useful conclusions?
FWIW, the code that appears to fail is:
struct addrinfo hints;
memset(&hints, 0, sizeof(struct addrinfo));
hints.ai_family = AF_INET;
hints.ai_socktype = SOCK_STREAM;
hints.ai_flags = AI_PASSIVE | AI_ADDRCONFIG | AI_NUMERICSERV;
hints.ai_protocol = 0;
hints.ai_canonname = NULL;
hints.ai_addr = NULL;
hints.ai_next = NULL;
const char * node = host.empty() ? NULL : host.c_str();
struct addrinfo *result;
int s = getaddrinfo(node, str(port).c_str(), &hints, &result);
if (s != 0) {
throw Xapian::NetworkError("Couldn't resolve host " + host,
eai_to_xapian(s));
}
Where host is "127.0.0.1" and port is "1239". It seems the error is:
EAI_NONAME
The node or service is not known; or both node and service are
NULL; or AI_NUMERICSERV was specified in hints.ai_flags and ser‐
vice was not a numeric port-number string.
The reproducible build used to work but it looks like it regressed in
1.3.4-1:
https://tests.reproducible-builds.org/debian/history/xapian-core.html
That's very suspicious as that's the first version packaged for Debian
which used getaddrinfo() (1.2.x used gethostbyname(), etc), and the
history shows that 1.2.x continued to build OK at the same time. So
that seems to point firmly to this not being a pbuilder regression.
But I've no idea what the cause is. My only thoughts are that perhaps
there's only IPv6 loopback (but then 1.2.x wouldn't work), or that
getaddrinfo() is interacting badly with the restricted networking.
Cheers,
Olly
