Hi,
Ludovic Courtès wrote:
Log:
* Ignore services in nsswitch.conf that cannot be found (like
"mdns4_mininal" on Ubuntu). This is a fix for NIXPKGS-79. It
doesn't *quite* fix the problem in all cases (there might be people
actually using mDNS; they should just run the "nscd" daemon) but at
least it should keep curl from failing in Nixpkgs downloads.
(I'm assuming this change relates to
http://thread.gmane.org/gmane.linux.distributions.nixos/384 ).
That seems very hackish.
I think the problem (DNS lookup failures in the chroot) stems from the
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").
So this is for people running Nix/Nixpkgs on Debian, it's not a problem on
NixOS.
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.
`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.
--
Eelco Dolstra | http://www.st.ewi.tudelft.nl/~dolstra/
_______________________________________________
nix-dev mailing list
[email protected]
https://mail.cs.uu.nl/mailman/listinfo/nix-dev
