Hi, Eelco Dolstra <[EMAIL PROTECTED]> writes:
> No, it's not about build problems in the chroot but about this bug: > > http://bugs.strategoxt.org/browse/NIXPKGS-79 > > I.e. packages that link against the Nixpkgs Glibc cannot do DNS > lookups on Ubuntu, because it has this line in /etc/nsswitch.conf: > > hosts: files mdns4_minimal [NOTFOUND=return] dns mdns4 > > This fails because "mdns4_minimal" can't be found and > "NOTFOUND=return" causes Glibc to not continue to "dns". This is > actually a bug in Glibc: failure to load the service should cause an > UNAVAIL error, not NOTFOUND (which means "the service says that the > name doesn't exist"). That's actually the same problem as when you set `avahi.nssmdns' to `true' in your configuration: the same `nsswitch.conf' is installed, leading to the same problems in the chroot. >> fact that the chroot sees a `resolv.conf' that specifies NSS modules >> that aren't mapped in the chroot. I can think of two solutions: >> >> 1. The best solution IMO would be to selectively bind-mount all NSS >> modules into the chroot and somehow make sure that they are in the >> lib search path of `curl' and other applications. >> >> 2. A simpler solution would be to provide the chroot with a >> `resolv.conf' that does not refer to any external NSS module. >> >> Now, I fail to see where the chroot gets its `/etc/resolv.conf' from. I really meant `nsswitch.conf', not `resolv.conf'. Sorry for the confusion. >> `DerivationGoal::startBuilder ()' in `libstore/build.cc' lists only >> `/dev', `/proc', and `/nix/store' as the paths that are mounted by >> default in the chroot. So where's `/etc'? Or is the above explanation >> incorrect? > > No, you're right. When I implemented the chroot option I didn't > consider DNS resolution. So fetchurl derivations currently just fail > in a chroot. But there is a simpler solution: we could just *not* > execute fixed-output derivations like fetchurl in a chroot. ("Fixed > output derivations" are derivations that specify the outputHash > attribute, i.e. the cryptographic hash required for the output.) Since > they have a guaranteed output anyway, we don't really care about their > purity, unlike normal derivations. Hmm, yes, but I'd prefer solution (2) above, which avoids special-casing. So where does the chroot's `/etc' come from? Thanks, Ludovic. _______________________________________________ nix-dev mailing list [email protected] https://mail.cs.uu.nl/mailman/listinfo/nix-dev
