<clever>
CMCDragonkai: its an eval-time backdoor to just run something as whatever user is doing the eval
<clever>
CMCDragonkai: i currently handle code signing using builtins.exec
<clever>
CMCDragonkai: you also need the hash of the private keys (or add an impurity that lets every build see the keys)
<clever>
CMCDragonkai: but then you need to know when it was signed, to compute $out
<clever>
tpham: just run nix-shell with no args, it will try to load shell.nix first, and if not found, it loads default.nix
<clever>
tpham: either use lib.cleanSourceWith to exclude it (the proper method), or just `preConfigure = "rm -rf build";` to get rid of it within nix-build (the sloppy but simple method)
<clever>
the laptop is a remote builder for the desktop!
<clever>
i just have all of my hardware in the house work together
<clever>
ah
<clever>
lovesegfault: and this will auto-generate a nixos guest under qemu
<clever>
tpham: nativeBuildInputs are compiled for the host, buildInputs are compiled for the target
<clever>
tpham: thats also an option, it uses namespacing to automatically chroot and run within that
<clever>
tpham: simplest option then is to install nix, and then use nix-copy-closure and nix-env
<clever>
tpham: do you have write perms to /nix/ ?
<clever>
tpham: use nix-copy-closure to copy the storepath, and everything it depends on
<clever>
`configurePhase` is a function that will run cmake, with the cmakeFlags
<clever>
that explains everything perfectly
<clever>
tpham: and you omitted that when compiling in nix-shell by hand?
<clever>
tpham: ah, and then it wants a static copy of boost
<clever>
tpham: what was it?
<clever>
tpham: yes
<clever>
lovesegfault: both
<clever>
lovesegfault: --dry-run
<clever>
tpham: stdenv.mkDerivation gets the .dev automatically for you
<clever>
tpham: how are you finding the path under both nix-build and nix-shell?
<clever>
yep, those match up
<clever>
tpham: load up a `nix repl '<nixpkgs>'` and then try to eval both "${boost.out}" and "${boost.dev}"
<clever>
tpham: thats boost.out vs boost.dev
<clever>
tpham: yep
<clever>
dansho: makeOutputPath generates a similar string, based on the contents of the drv and the output name (.out .dev .lib), to create the hash in $out
<clever>
dansho: yeah
<clever>
i think references, is everything under inputSrcs and inputDrvs
<clever>
so the type from earlier, will be "text:<r1>:<r2>", with a list of references
<clever>
dansho: which then uses addTextToStore, from store-api.cc
<clever>
and then the hash-name.drv, is based on the hash of its own contents
<clever>
i believe the way it works, is that outpath, is a hash of the attrs to builtins.derivation (and some other constants)
<clever>
one min
<clever>
hmmm, wait, other way around
<clever>
but is rather, based on that hash
<clever>
out isnt part of the hash
<clever>
not sure why args is absent from env
<clever>
dansho: env, args, builder, and system
<clever>
yeah
<clever>
since they just become env vars, its a bit hard to list every single one, you have to read all of the shell scripts to see what they look for
<clever>
dansho: all args (including the required ones) just become env vars during the build, you can also run `nix show-derivation /nix/store/foo.drv` to see the whole set
<clever>
dansho: yeah, its and its the real primop behind things like stdenv.mkDerivation
<clever>
dansho: the set of every key/value pair passed to builtins.derivation
<clever>
tpham: id expect that to work then
<clever>
and all -p does, is put those strings into the buildInputs
<clever>
pretty sure boost belongs in buildInputs
<clever>
tpham: -p can take multiple arguments at once
<clever>
tpham: if you read the cmake file, how does it actually search for boost?
<clever>
tpham: looks like it exists for me and the bot
<clever>
> llvmPackages_9.stdenv.mkDerivation
<clever>
jusss: i either tab-complete within `nix repl '<nixpkgs>'` or grep nixpkgs, but there is also `nix search`
<clever>
tpham: llvmPackages_9.stdenv maybe?
<clever>
7700 clangStdenv = if stdenv.cc.isClang then stdenv else lowPrio llvmPackages.stdenv;
<clever>
tpham: adding pkgconfig on line 10 may fix the boost issues
<clever>
tpham: then you can delete lines 11 and 13
<clever>
tpham: use clangStdenv, not stdenv, when you want to use clang
<clever>
i can at least see why with rasbian, more noob friendly if you can just download any image, and it work on any pi
<clever>
rasbian still uses armv6 userland, so they can ship a single distro for every model of rpi
<clever>
samueldr: got my msg in #nixos-aarch64 ?
<clever>
bt``: i'm currently working on rpi firmware stuff, and using 32bit mode on an rpi3, despite it being 64bit capable
<clever>
bt``: that resulted in software i was working on, crashing due to illegal instructions
<clever>
bt``: the last dinosaur i retired was 64bit capable, but lacked some (now common) sse extensions
<clever>
Henson: cant hurt to contribute to both at once
<clever>
i believe so
<clever>
Henson: yeah, that sounds like a good idea
<clever>
Henson: if you set fileSystems."/something" = { fsType = "nfs"; device = "server:/something"; };, then nfs will be added to boot.supportedFilesystems automatically
<clever>
Henson: boot.supportedFilesystems = [ "nfs" ]; and nixos will setup all nfs client stuff for you
<clever>
monokrome: as i expected, the lock wasnt on-disk but was in-kernel
<clever>
monokrome: can you paste those 2 lines?
<clever>
monokrome: `sudo strace nix-channel --update`, what does it hang around?
<clever>
monokrome: what happens if you just `sudo nix-channel --update` ?
<clever>
monokrome: what exactly are you running, that causes it to block?
<clever>
monokrome: usually, those locks are kept in kernel space, and cleared on improper shutdown
<clever>
duairc: check `modinfo ipv6`, and try adding just its deps to boot.initrd.kernelModules?
<clever>
duairc: it might be that ipv6 was pulling in other stuff via its deps, that you needed
<clever>
and nothing will renew it
<clever>
and then it has to expire naturally, based on the expire listed in `ip route`
<clever>
ahh
<clever>
duairc: they are sent out at a regular interval, so it may take a while to see one
<clever>
duairc: id start with tcpdump to confirm that
<clever>
duairc: ack!
<clever>
pie_: i believe so
<clever>
pie_: check other activation scripts in nixpkgs to see examples
<clever>
pie_: thats what the deps= is for
<clever>
yep, just check this file in the linux github
<clever>
mid-term, add `sandbox = false` to nix.conf
<clever>
eacameron: short term, --option sandbox false
<clever>
eacameron: yep, /build being created is a sign of this bug, you should never have to do that
<clever>
ive seen this bug before
<clever>
eacameron: one minute
<clever>
duairc: does the script that --script points to, actually exist within the initrd env?
<clever>
keithy[m]: it should just work then, with only enable set
<clever>
keithy[m]: is this from the raspberry pi sd image?
<clever>
keithy[m]: can you show the above output, before you reboot, and after
<clever>
keithy[m]: what does `ls -lh /run/current-system` output?
<clever>
keithy[m]: then it should run on boot, one min
<clever>
__monty__: the error was trying to query it with nixos-option
<clever>
keithy[m]: what does `nixos-option systemd.services.sshd.wantedBy` output?
<clever>
Anton43: its possible something is already using the alsa device, so pulse cant use it
<clever>
keithy[m]: can you pastebin the entire output from `nixos-rebuild switch` before you remove it
<clever>
keithy[m]: the stackoverflow said to use systemd.services.sshd.wantedBy
<clever>
keithy[m]: yep, because services.sshd.wantedBy isnt a valid option
<clever>
keithy[m]: what does nixos-option services.sshd.wantedBy report?
<clever>
Anton43: then the issue is within pulseaudio, try `pactl exit` to restart it
<clever>
Anton43: what about pavucontrol ?
<clever>
one min
<clever>
keithy[m]: i would expect that to fail...
<clever>
keithy[m]: and your editing /etc/nixos/configuration.nix right?
<clever>
keithy[m]: what does `echo $NIX_PATH` say?
<clever>
keithy[m]: what happens if you run `nixos-rebuild switch` ?
<clever>
keithy[m]: `systemctl enable` will never work on nixos
<clever>
keithy[m]: they are completely different options
<clever>
keithy[m]: thats systemd.services.sshd, not services.sshd
<clever>
keithy[m]: what happens if you run `nixos-rebuild switch` ?
<clever>
keithy[m]: thats not a valid option!
<clever>
keithy[m]: wait a second, line 66 should just fail hard
<clever>
keithy[m]: you will also need to nixos-rebuild switch for the change to take effect
<clever>
keithy[m]: if you remove line 66 of configuration.nix, and try another reboot, what happens?
<clever>
__monty__: it isnt
<clever>
keithy[m]: can you pastebin it anyways?
<clever>
keithy[m]: and what about hardware-configuration.nix?
<clever>
keithy[m]: can you pastebin the configuration.nix file?
<clever>
keithy[m]: is this the installer image?
<clever>
simpson: the ssh service in nixos opens its own port up automatically
<clever>
keithy[m]: and if you do `systemctl status sshd` what does it report?
<clever>
keithy[m]: did you enable ssh in configuration.nix?
<clever>
even chromium has a test in the nixos framework
<clever>
CMCDragonkai: because $HOME isnt set, X11 apps are looking as /.Xauthority, not /root/.Xauthority
<clever>
CMCDragonkai: its not looking in /root/, is the problem
<clever>
CMCDragonkai: then $HOME isnt set right, HOME=/root/ in your case
<clever>
when `xauth list` starts with amd-nixos/unix:0, then that means it will only use that record when connecting to amd-nixos
<clever>
CMCDragonkai: you may need to install it within the container first, the hostname may also matter
<clever>
CMCDragonkai: what is the listing from inside docker?
<clever>
CMCDragonkai: if you run `xauth` and then `list` both inside and out, what does it say?
<clever>
CMCDragonkai: you can also use the xauth command, to export and import records from .Xauthority
<clever>
CMCDragonkai: .Xauthority contains the secret password that lets you connect, but you also need to be able to connect to the unix socket at /tmp/.X11-unix/X0
<clever>
both of which can add more context
<clever>
pie_: 1610, it will check a set for a .toString function or .outPath value
<clever>
pie_: line 1605, it will return either the copy or the original string (based on the bool), and only copyPathToStore is able to modify the context
<clever>
pie_: line 1600, if you try to coerceToString another string, it will return the string, and add the context to the given list
<clever>
pie_: but you found the other half i didnt link!
<clever>
pie_: "${foo}" calls coerceToString on whatever is within foo
<clever>
pie_: the bool passed to coerceToString controls if it will copy or not, the default is to copy
<clever>
lordcirth_: and if its the main router, you dont need the nat stuff
<clever>
lordcirth_: yeah, customize lines 20-27 and 12 to suit your needs
<clever>
lordcirth_: the original use, is that you plug any machine into the laptop ethernet, netboot it, run justdoit, and boom, its now nixos!
<clever>
lordcirth_: lines 20-27 are then a nixos config for the client, that will boot over the network
<clever>
lordcirth_: the main file, is meant to be a netboot server, on a laptop, you aim lan to an ethernet card, and wan to a wifi card, and it will NAT between them for you
<clever>
lordcirth_: config for the justdoit script, if you run `justdoit` on the netboot client, it will nuke /dev/vda, and install nixos using luks
<clever>
lordcirth_: this file also sets up everything needed for network booting
<clever>
lordcirth_: that puts the tftp dir into the nix store, and manages it with a nix expression