Cyril Brulebois <kibi@debian.org> (2017-01-19):
> Summing up things from IRC:
> - in an uptodate sid chroot (both development version and minimal one
> with daily-build script): no DNS issues with the generated mini.iso
> (amd64, tested within stable's kvm on amd64). My image was also
> tested successfully by Steve, so not a setup issue.
>
> - I can reproduce the issue with dailies from 2017-01-18, and from
> 2017-01-19 (I picked it in advance during its build on barriere).
>
> - I can reproduce the issue in the above mentioned sid chroot if
> I downgrade these packages to testing's version (-9 → -8):
> sudo apt-get install libc6:amd64=2.24-8 libc6-dev:amd64=2.24-8 libc-dev-bin=2.24-8
>
> - The older set of libc* packages is installed in barriere's current
> amd64 sid chroot, too.
>
> - Steve could only produce broken images when building locally, until
> he upgraded his libc* packages as well.
And since Steve was wondering how we could release something for Stretch
RC 1 with that… I've just confirmed that using -8 .deb with a -8 .udeb
(reversioned as -9+hack so that its being dropped under localudebs makes
it take precedence over sid's .udeb) leads to an image that's working
fine. And AFAICT that's the combination we had at the time.
I suspect the implementation change through the following patch in -9:
glibc-2.24/debian/patches/any/cvs-resolv-internal-qtype.diff
plus 283e7a294275a7da53258600deaaafbbec6b96c1 in debian-installer.git is
what is triggering the issue? (Explaining why host's libc .deb have an
impact on the built images.)
It's been a while since I last looked at/understood mklibs stuff though,
feel free to fix my suspicions/conclusions.
KiBi.
Attachment:
signature.asc
Description: Digital signature