Dear Maintainer,

The package fails to build:

cc -o test ../src/base32.o  ../src/base64.o ../src/common.o ../src/read.o ../src/dns.o ../src/encoding.o ../src/login.o ../src/md5.o ../src/user.o ../src/fw_query.o test.o base32.o base64.o common.o read.o dns.o encoding.o login.o user.o fw_query.o -L/usr/local/lib `pkg-config check --libs` -lpthread `sh ../src/osflags Linux link`
Running suite(s): iodine
95%: Checks: 68, Failures: 3, Errors: 0
common.c:100:F:Common:test_parse_format_ipv4:0: Assertion 'addr_len == sizeof(struct sockaddr_in)' failed
common.c:120:F:Common:test_parse_format_ipv4_listen_all:0: Assertion 'addr_len == sizeof(struct sockaddr_in)' failed
common.c:170:F:Common:test_parse_format_ipv4_mapped_ipv6:0: Assertion 'addr_len == sizeof(struct sockaddr_in6)' failed
Makefile:12: recipe for target 'all' failed

Full build log:
https://reproducible.debian.net/rb-pkg/unstable/amd64/iodine.html

Control: severity -1 important
Control: tag -1 + confirmed

Thanks for the bug report.

I can reproduce the test failures with USENETWORK=no in pbuilderrc
(and a cowbuilder unstable amd64 + i386 chroot); with USENETWORK=yes
the tests pass.

The failing tests all involve IPv4 addresses; test_parse_format_ipv6
interestingly doesn't fail. The difference is

test_parse_format_ipv4: addr_len = get_addr(host, 53, AF_INET, 0, &addr);
test_parse_format_ipv4_listen_all: addr_len = get_addr(NULL, 53, AF_INET, AI_PASSIVE, &addr);
test_parse_format_ipv6: addr_len = get_addr(host, 53, AF_UNSPEC, 0, &addr);
test_parse_format_ipv4_mapped_ipv6: addr_len = get_addr(v4mapped, 53, AF_INET6, 0, &addr);

addr_len is -2 for the 3 failing-under-USENETWORK=no tests.
Changing AF_INET to AF_UNSPEC in test_parse_format_ipv4 makes it pass
as well even under USENETWORK=no.


I'm lowering the severity of the bug for now, since this doesn't
look like a bug in the code itself but like a weird interaction
between the test suite and pbuilder's optional use of namespaces.


Cheers,
gregor

Heh.  I try and eliminate these cases by rebuilding them on lxc (which
it also failed in the same way), but lxc /also/ has weird uses of
namespaces, so.. :)