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. -- Guillaume Delacour
signature.asc
Description: OpenPGP digital signature
