[Nix-dev] Failure trying to build node package

[Nikolay Amiantov]

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.