On 10/06/2014 03:36 PM, Wout Mertens wrote: > Ok, weird. Try also setting OPENSSL_X509_CERT_FILE to that file? OPENSSL_X509_CERT_FILE was originally set to same path as GIT_SSL_CAINFO. Setting it to /home/... did no effect. > So this error means that it can't verify the certificate. Normally, > with GIT_SSL_CAINFO it should be able to find it :-/ Perhaps npm > removes the environment variable? A quick grep showed that at least it doesn't fiddle with these variables at least, though it can clean the environment completely. It would be strange, though -- it then would need to set this variables, and grep found nothing. > I see that you can clone it yourself, can you try under `nix-shell -p > git --pure` as well? Can't verify the certificate. Setting GIT_SSL_CAINFO helps. > Note that if you use npm2nix, you should use nix to get the modules, > not npm. See also the work Sander is doing at > https://github.com/svanderburg/npm2nix/tree/reengineering , you might > want to use that version instead. Yes, but that problems looks connected. I have no error concerning SSL certificate with npm2nix, though -- just "error fetching" or something like that. I'll take a look at reengineering branch. > Yes, that's one way and the other is to set user environment > variables. Either way though we'll have to move some settings from > /nixos to /pkgs. > > However, how do you handle openssl? It's a library so you can't use a > shell wrapper and it needs OPENSSL_X509_CERT_FILE. Should that go into > user environment, into the wrapper for all programs that depend on > openssl, or should we create a wrapper library that loads the library > with the correct environment set (hmm interesting idea but still > requires rebuilding things that depend on it)? To tell the truth, I've started thinking about it after sending a reply. When we use nix stand-alone, do we require user to load some kind of environment? I've arrived to the last option (wrapper libraries, I've even done something like that), but I haven't thought of rebuilding problem. What's the problem with containing it within user environment? > Another interesting one is TZDIR, which is required for glibc to tell > timezones correctly. How do you handle that? You'd have to set it on > all programs that use glibc and in fact even on everything else on the > off chance that there's some library being loaded that uses glibc. So > then it would be better off being set in the user environment but then > if you upgrade the time zone data, the user has to log out for > everything to get the new data. So then you might be even better off > pointing it to some path on disk that has the correct data, like > $HOME/.nix-profile/etc/tzdata. But all users share the same data, so > you'd be better off pointing it somewhere global like > /usr/share/zoneinfo, and hardcoding that path in glibc, which is what > all other distros do. On NixOS it's /etc/zoneinfo because there's no > /usr but that means that either on NixOS the TZDIR environment > variable needs to be set for all processes, or glibc needs a different > hardcoded path and nixpkgs installations need to set TZDIR, or glibc > for NixOS is different from glibc for nixpkgs. Do we support "different tzdatas" and "different certfiles" on the system? If not, then I would use "$HOME/.nix-profile/etc/tzdata", which would be a symlink to the real tzdata. That would work on NixOS and other distributions as well. I just had an idea of using that to store some kind of "environment", which could be read by LD_PRELOADed or dynamically linked extra library (which may avoid rebuild, then), or nix-shell, for example. This would solve the problem with certificates. Advantages of the first solution is that we have no need to set the environment before running any executable, but I don't like this approach for the need of load some extra library that would use __constructor -- that looks "hacky" for me.
-- Nikolay. _______________________________________________ nix-dev mailing list [email protected] http://lists.science.uu.nl/mailman/listinfo/nix-dev
