On Mon, May 15, 2017 at 1:52 AM, Guillaume Delacour <[email protected]> wrote:
> Hi, > > Le 15/05/2017 à 00:50, Adam Borowski a écrit : > > > > > 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. > > As this bug is not related to sslh package itself, i've removed the > pending tag, i let Michael revert > https://anonscm.debian.org/cgit/collab-maint/sslh.git/commit/?id= > 243bb3faa682afa8168664eaf5a4f72cfc21ee27 > and closing this bug to disable the autoremoval in testing. > Note that my commit still improves things, regardless of this specific bug report or others. I think the best outcome in the long run would be to keep the commit by upstreaming it. I can understand if you’d like to revert it while we’re in a freeze, but let’s not drop it entirely please :). -- Best regards, Michael
