warning: Nix search path entry '$HOME/.nix-defexpr/channels' does not exist, ignoring #40165
Comments
|
Does this also happen if you use |
|
Hello, |
|
not with |
|
I expect the change is a consequence of #38351. |
|
I guess there's also a more general problem that even if the variable is expanded, a warning is printed if the user doesn't have any channels, e.g. a simple |
|
Maybe we could:
|
|
I ran This was enough to stop the warning, and seems to be the "proper" setup for a user subscribed to no channels. My system is several nixos releases old, so having to manually do something to adjust my home dir is fine, though it took me a while to think of trying that. Perhaps the warning message could suggest this fix if the missing NIX_PATH entry being ignored is ~/.nix-defexpr/channels? |
|
@cumber When I run it as root,I get: The warning remains, also at the next rebuild. |
|
@magnetophon I should probably have been clearer, I was referring to dezgeg's report that you get a warning printed even in contexts where the variable is expanded, e.g.: The behaviour I'm seeing is that nix commands run as my own user ( The cause of the former seems to be an "improper" state for no subscribed channels (nonexistent |
|
|
|
@jb55 That works, but I went with letting |
environment.sessionVariables cannot refer to the values of env vars, and as a result this has caused problems in a variety of scenarios. One use for these is that they're injected into /etc/profile, elewhere these are used to populate an 'envfile' for pam (`pam 5 pam_env.conf`) which mentions use of HOME being potentially problematic. Anyway if the goal is to make things easier for users, simply do the NIX_PATH modification as extraInit. This fixes the annoying problems generated by the current approach (NixOS#40165 and others) while hopefully serving the original goal. One way to check if things are borked is to try: $ sudo env | grep NIX_PATH Which (before this change) prints NIX_PATH variable with an unexpanded $HOME in the value. ------- This does mean the following won't contain user channels for 'will': $ sudo -u will nix-instantiate --eval -E builtins.nixPath However AFAICT currently they won't be present either, due to unescaped $HOME. Unsure if similar situation for other users of sessionVariables (not sudo) work with current situation (if they exist they will regress after this change AFAIK).
environment.sessionVariables cannot refer to the values of env vars, and as a result this has caused problems in a variety of scenarios. One use for these is that they're injected into /etc/profile, elewhere these are used to populate an 'envfile' for pam (`pam 5 pam_env.conf`) which mentions use of HOME being potentially problematic. Anyway if the goal is to make things easier for users, simply do the NIX_PATH modification as extraInit. This fixes the annoying problems generated by the current approach (NixOS#40165 and others) while hopefully serving the original goal. One way to check if things are borked is to try: $ sudo env | grep NIX_PATH Which (before this change) prints NIX_PATH variable with an unexpanded $HOME in the value. ------- This does mean the following won't contain user channels for 'will': $ sudo -u will nix-instantiate --eval -E builtins.nixPath However AFAICT currently they won't be present either, due to unescaped $HOME. Unsure if similar situation for other users of sessionVariables (not sudo) work with current situation (if they exist they will regress after this change AFAIK). (cherry picked from commit fa67ca1)
|
I've got these warnings after upgrading NixOS to 18.09. |
|
I've got this on unstable as well : 19.03pre151837.ca2ba44cab4 (Koi) nor silences it. |
grahamc
added
the
1.severity: blocker
environment.sessionVariables cannot refer to the values of env vars, and as a result this has caused problems in a variety of scenarios. One use for these is that they're injected into /etc/profile, elewhere these are used to populate an 'envfile' for pam (`pam 5 pam_env.conf`) which mentions use of HOME being potentially problematic. Anyway if the goal is to make things easier for users, simply do the NIX_PATH modification as extraInit. This fixes the annoying problems generated by the current approach (NixOS#40165 and others) while hopefully serving the original goal. One way to check if things are borked is to try: $ sudo env | grep NIX_PATH Which (before this change) prints NIX_PATH variable with an unexpanded $HOME in the value. ------- This does mean the following won't contain user channels for 'will': $ sudo -u will nix-instantiate --eval -E builtins.nixPath However AFAICT currently they won't be present either, due to unescaped $HOME. Unsure if similar situation for other users of sessionVariables (not sudo) work with current situation (if they exist they will regress after this change AFAIK). (cherry picked from commit fa67ca1)
environment.sessionVariables cannot refer to the values of env vars, and as a result this has caused problems in a variety of scenarios. One use for these is that they're injected into /etc/profile, elewhere these are used to populate an 'envfile' for pam (`pam 5 pam_env.conf`) which mentions use of HOME being potentially problematic. Anyway if the goal is to make things easier for users, simply do the NIX_PATH modification as extraInit. This fixes the annoying problems generated by the current approach (#40165 and others) while hopefully serving the original goal. One way to check if things are borked is to try: $ sudo env | grep NIX_PATH Which (before this change) prints NIX_PATH variable with an unexpanded $HOME in the value. ------- This does mean the following won't contain user channels for 'will': $ sudo -u will nix-instantiate --eval -E builtins.nixPath However AFAICT currently they won't be present either, due to unescaped $HOME. Unsure if similar situation for other users of sessionVariables (not sudo) work with current situation (if they exist they will regress after this change AFAIK). (cherry picked from commit fa67ca1)
|
Fix applied in ee582a3. |
environment.sessionVariables cannot refer to the values of env vars, and as a result this has caused problems in a variety of scenarios. One use for these is that they're injected into /etc/profile, elewhere these are used to populate an 'envfile' for pam (`pam 5 pam_env.conf`) which mentions use of HOME being potentially problematic. Anyway if the goal is to make things easier for users, simply do the NIX_PATH modification as extraInit. This fixes the annoying problems generated by the current approach (#40165 and others) while hopefully serving the original goal. One way to check if things are borked is to try: $ sudo env | grep NIX_PATH Which (before this change) prints NIX_PATH variable with an unexpanded $HOME in the value. ------- This does mean the following won't contain user channels for 'will': $ sudo -u will nix-instantiate --eval -E builtins.nixPath However AFAICT currently they won't be present either, due to unescaped $HOME. Unsure if similar situation for other users of sessionVariables (not sudo) work with current situation (if they exist they will regress after this change AFAIK).
|
Seems fixed now on 18.09 and master. And 18.03 shouldn't suffer from this IIRC. |
|
Got this warning on fresh NixOS 19.03 install, without any configs touched. @cumber 's comment (i.e., |
|
This issue has been mentioned on NixOS Discourse. There might be relevant details there: |
Issue description
Recently I've got following warning when running
nixos-rebuild. I can't remember change any configuration.Despite it is just a warning, not a critical one, I still want to know how to fix it properly.
Steps to reproduce
Technical details
"x86_64-linux"Linux 4.14.39, NixOS, 18.09pre139319.1d9330d63a5 (Jellyfish)yesnonix-env (Nix) 2.0.2"nixos-18.09pre139319.1d9330d63a5"""/nix/var/nix/profiles/per-user/root/channels/nixos/nixpkgsThe text was updated successfully, but these errors were encountered: