<clever>
illegalprime[m]: thats in the nixos module format, not the config.nix format
<clever>
imalison: also try just `sudo -i` then `echo $NIX_PATH`
<clever>
imalison: so your not seeing roots version of the variable
<clever>
imalison: bash evals that before it runs sudo
<clever>
imalison: it helps a lot to `sudo -i` and then do everything in that root shell
<clever>
imalison: sudo can sometimes be configured to sanitize the env, and that can unset $NIX_PATH
<clever>
imalison: what does this command print out? and try to just paste it, rather then re-type it: nix-instantiate --find-file nixpkgs
<clever>
ah
<clever>
imalison: what exactly are you trying to do?
<clever>
imalison: you need to use --set when trying to manage the system profile
<clever>
imalison: does that nixpkgs dir its pointing to exist?
<clever>
imalison: the - in ~/.nix-defexpr/ is missing
<clever>
imalison: what does `echo $NIX_PATH` say?
<clever>
catern: its an internal part of how systemPackages is handled, and doesnt really work with nix-env
<clever>
same limits there
<clever>
yeah, nix-env puts it in ~/.nix-profile/
<clever>
inquisitiv3: its not capable of doing systemd like things and enabling services
<clever>
inquisitiv3: all nixos does with the systemPackages is put them in /run/current-system/sw/
<clever>
and it also saves you from having to list everything twice, once in systemPackages and again in services
<clever>
inquisitiv3: some packages can be ran on bootup without installing them, and some need to install specialized versions
<clever>
inquisitiv3: yes
<clever>
i'm guessing you just installed it, and never ran it
<clever>
inquisitiv3: setting that enable thing does 2 things, first it adds spice-vdagent to systemPackages for you (so you can remove your own line for that), and second, it runs it on bootup
<clever>
inquisitiv3: things added to systemPackages cant configure nixos level options
<clever>
infinisil: maybe a buildenv between the wrapper and original, with the wrapper as a higher prio
<clever>
tnks: read the bash script in the wrapped variant
<clever>
tnks: its a commom problem with wrappers in nixpkgs, chrome has the same issue
<clever>
tnks: thats why i asked about overrides
<clever>
tnks: and what does just `which rofi` return?
<clever>
tnks: how did you find /nix/store/q4fsdj22yaiacadd4qfm5indkfkgw5gh-rofi-unwrapped-1.5.1/share/man/man1/rofi.1.gz ?
<clever>
tnks: then nix-env is not to blame
<clever>
tnks: if you run `nix-build '<nixpkgs>' -A rofi` and then `ls -l result/` does it contain a share/man dir?
<clever>
tnks: did you apply any overrides with config.nix?
<clever>
johanot: any time i'm dealing with something that wants yaml, i just use builtins.toJSON in nix
<clever>
johanot: of note, yaml is a superset of json, so all yaml parsers can accept json
<clever>
ixxie: i dont think one exists yet
<clever>
YegorTimoshenko[: yeah, it was just a bit weird to be given an exe file when i askd for a linux binary
<clever>
ixxie: ive also found .net stuff to be weird, ive seen a project linking a .exe file as the linux build!, and it just works when you run mono on it under nixpkgs!
<clever>
ixxie: this will cross-compile a 64bit windows binary for the hello package
<clever>
logiq: but if you use a different name, it can run into issues
<clever>
logiq: id usually stick to `nix-env -iA nixpkgs.foo`
<clever>
logiq: and the channel is called nixos when on nixos, so you instead need `nix-env -iA nixos.foo`
<clever>
logiq: <nixpkgs> and `nix-env -iA nixpkgs.` can wind up pointing to different things
<clever>
logiq: nix-env follows different rules, and will search for nixpkgs in ~/.nix-defexpr/, which will point to a channel called nixpkgs when added with nix-channel
<clever>
logiq: `-f <nixpkgs>` will search for nixpkgs in $NIX_PATH, while `-f .` just opens the default.nix in the current dir
<clever>
Mic92: let me just upstream the fix and then file a PR with that diff
<clever>
mafo: i would just re-launch the shell after it fails, and then try make in the dir it made
<clever>
e*
<clever>
mafo: i think genericBuild may change the s state again
<clever>
mafo: what commands have you ran?
<clever>
mafo: backtraces, in a shell script??
<clever>
Mic92: (facepalm), i think my pr that was just merged only fixes it on 32bit...
<clever>
Mic92: what do you think about backporting my openat PR to 18.03 and/or 17.09?, they may have the same issue because the previous PR was also backported
<clever>
mupf: i think its `set +e`
<clever>
the nixos hydra doesnt pre-build much with cross-compiling, but it does do some native aarch64 builds
<clever>
it will use the build slaves that have the same arch as the hydra machine
<clever>
manveru: just put the above expression into a release.nix file
<clever>
Lorne1: youll need to investigate how its starting by reading /etc/systemd/system/xrdp.service
<clever>
Lorne1: i'm guessing xrdp may also have its own integrated window manager, and it may also not obey the normal services.xserver options
<clever>
Lorne1: maybe -u xrdp
<clever>
Lorne1: oh, then it wont be under the normal name
<clever>
oh, and also `-u display-manager` to limit it further
<clever>
the display manager should be near the top
<clever>
Lorne1: you can also add `-b 0` to the command to limit it to the current boot
<clever>
Lorne1: the journal should say what it is
<clever>
Lorne1: slim doesnt have any mouse interaction at all
<clever>
Lorne1: from slim, you can hit f1 to cycle thru the desktop managers and window managers
<clever>
ah, i cant find that wrapper anymore, it may not be needed
<clever>
thekolb: but you may need to use the special wrapper in nixos
<clever>
kmod.out 0 s /nix/store/jyfq8333jy09vh743jmzsqwvv12kdxxi-kmod-24/bin/modprobe
<clever>
logzet: --since and --until
<clever>
or select the right one at the login screen
<clever>
also of note, there is a xterm window-manager that sometimes winds up as default, you may need to services.xserver.desktopManager.xterm.enable = false;
<clever>
logzet: the journal should contain the logs
<clever>
hoshineko: should be safe to ignore
<clever>
inquisitiv3: a lot of the dynamic options in nixos work like that
<clever>
inquisitiv3: if you set boot.initrd.luks.devices.foo = { ... }; then the name will default to "foo"
<clever>
inquisitiv3: my laptop happens to use the list form instead of the attrset form, but they are pretty much identical