<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, May 15, 2017 at 1:52 AM, Guillaume Delacour <span dir="ltr"><<a href="mailto:gui@iroqwa.org" target="_blank">gui@iroqwa.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<div><div class="h5"><br>
Le 15/05/2017 à 00:50, Adam Borowski a écrit :<br>
<br>
><br>
> So it's a fully _reproducible_ bug, with a well-defined immediate cause<br>
> (even if we haven't identified the indirect cause yet) -- unlike the<br>
> original report by Santiago Villa. Thus, it looks we have two different<br>
> bugs that just happen to trigger the same failure mode.<br>
><br>
> And thus, even if we fix the schroot issue, Santiago's bug likely won't be<br>
> fixed.<br>
><br>
>> Now, the next question is: where does this /etc/hosts come from? The file<br>
>> is present in the above form directly after unpacking the schroot tarball,<br>
>> before even entering the schroot.<br>
><br>
>> Running debootstrap does not produce an /etc/hosts in --variant=minbase and<br>
>> --variant=buildd. When run without --variant, it does produce an<br>
>> /etc/hosts, but that looks correct:<br>
> [snip]<br>
>> So, where does the file get mangled? I can’t find any traces in the schroot<br>
>> and sbuild sources. Does anyone know by chance?<br>
><br>
> Even more puzzling: I just recreated the chroot again, and despite using the<br>
> very same command to do so as before (last on 2017-05-04) there's no<br>
> /etc/hosts in the chroot now, which makes sslh build correctly.<br>
><br>
> The version from 2017-05-04 includes has an /etc/hosts, with ::1 replaced by<br>
> 127.0.0.1 just as you noticed. And I see no uploads of debootstrap, sbuild,<br>
> schroot or a package that looks related in that time period.<br>
><br>
> Got an unrelated big build running at the moment, once it's done I'll boot<br>
> from a snapshot (got backups from 2017-05-01 (plus earliers) and dailies<br>
> since 2017-05-06) to see if it's a matter of an installed package.<br>
><br>
> But again, this is probably unrelated to Santiago's bug other than for the<br>
> results.<br>
<br>
</div></div>As this bug is not related to sslh package itself, i've removed the<br>
pending tag, i let Michael revert<br>
<a href="https://anonscm.debian.org/cgit/collab-maint/sslh.git/commit/?id=243bb3faa682afa8168664eaf5a4f72cfc21ee27" rel="noreferrer" target="_blank">https://anonscm.debian.org/<wbr>cgit/collab-maint/sslh.git/<wbr>commit/?id=<wbr>243bb3faa682afa8168664eaf5a4f7<wbr>2cfc21ee27</a><br>
and closing this bug to disable the autoremoval in testing.<br></blockquote><div><br></div><div>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 :).</div></div><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">Best regards,<br>Michael</div>
</div></div>