[buildd-tools-devel] Bug#842634: Bug#851877: fails every time

[Adam Borowski]

On Sun, May 14, 2017 at 10:37:17PM +0200, Michael Stapelberg wrote:
> On Sun, May 14, 2017 at 7:59 AM, Adam Borowski <kilobyte at angband.pl> wrote:
> > > Use: gcc -Wall -o gai gai.c && ./gai localhost 9002
> >
> > On all three machines, it looks fine:
> >   ai_family = 10
> >     host=::1, serv=9002
> >   ai_family = 2
> >     host=127.0.0.1, serv=9002
> 
> This seems correct.

> > Inside the chroot:
> >   ai_family = 2
> >     host=127.0.0.1, serv=9002
> >   ai_family = 2
> >     host=127.0.0.1, serv=9002
> 
> This seems incorrect: the results are two IPv4 addresses (127.0.0.1:9002)
> as opposed to one IPv6 and one IPv4 address (or just one IPv4 address).
> 
> I can actually reproduce this issue on abel.debian.org (armhf porterbox):
> 
> On abel, my gai test program returns ::1, 127.0.0.1.
> On abel within an schroot, my gai test program returns 127.0.0.1, 127.0.0.1.
> 
> Looking at /etc/hosts within the schroot, I see:
> 127.0.0.1       localhost
> 127.0.0.1       localhost ip6-localhost ip6-loopback
> 172.28.17.11    abel.debian.org abel
> 
> Modifying /etc/hosts by replacing ::1 with 127.0.0.1 results in being able
> to reproduce the issue on other machines as well.

So it's a fully _reproducible_ bug, with a well-defined immediate cause
(even if we haven't identified the indirect cause yet) -- unlike the
original report by Santiago Villa.  Thus, it looks we have two different
bugs that just happen to trigger the same failure mode.

And thus, even if we fix the schroot issue, Santiago's bug likely won't be
fixed.
 
> Now, the next question is: where does this /etc/hosts come from? The file
> is present in the above form directly after unpacking the schroot tarball,
> before even entering the schroot.

> Running debootstrap does not produce an /etc/hosts in --variant=minbase and
> --variant=buildd. When run without --variant, it does produce an
> /etc/hosts, but that looks correct:
[snip]
> So, where does the file get mangled? I can’t find any traces in the schroot
> and sbuild sources. Does anyone know by chance?

Even more puzzling: I just recreated the chroot again, and despite using the
very same command to do so as before (last on 2017-05-04) there's no
/etc/hosts in the chroot now, which makes sslh build correctly.

The version from 2017-05-04 includes has an /etc/hosts, with ::1 replaced by
127.0.0.1 just as you noticed.  And I see no uploads of debootstrap, sbuild,
schroot or a package that looks related in that time period.

Got an unrelated big build running at the moment, once it's done I'll boot
from a snapshot (got backups from 2017-05-01 (plus earliers) and dailies
since 2017-05-06) to see if it's a matter of an installed package.

But again, this is probably unrelated to Santiago's bug other than for the
results.


Meow!
-- 
Don't be racist.  White, amber or black, all beers should be judged based
solely on their merits.  Heck, even if occasionally a cider applies for a
beer's job, why not?
On the other hand, corpo lager is not a race.