<clever>
and i cant see any clear reason why its doing that
<clever>
so the nc your running, is connecting to that 2nd netcat, not the openvpn
<clever>
tobiasBora: b: you have a 2nd instance of netcat that is listening on 1194 tcp
<clever>
tobiasBora: a: openvpn is listening on udp, and netcat is tcp
<clever>
tobiasBora: and also `netstat -anp | grep 1194`
<clever>
tobiasBora: yeah
<clever>
tobiasBora: what about `netcat 127.0.0.1 1194` ?
<clever>
tobiasBora: need more of the output
<clever>
tobiasBora: run it under strace
<clever>
seafood: and an example of finding the direct deps of the coreutils from the gist: select path from ValidPaths where id in (select reference from Refs where referrer = 157219);
<clever>
its safer if you copy db.sqlite and then poke around on the copy
<clever>
seafood: just be careful when looking in that db, you can break the entire store and have to reinstall the system
<clever>
iqubic: NIX_PATH is also described in the nix-build man page
<clever>
Add a path to the Nix expression search path. This option may be given multiple times. See the NIX_PATH environment variable for information on the semantics of the Nix search path. Paths added through -I take precedence over NIX_PATH.
<clever>
-I path
<clever>
iqubic: its exactly the same as <nixpkgs> within nix expressions
<clever>
If no paths are specified, then nix-build will use default.nix in the current directory, if it exists.
<clever>
if you dont specify a file, then it reads default.nix from the current dir
<clever>
iqubic: that tells it to load nixpkgs from $NIX_PATH
<clever>
read the man pages
<clever>
to just build&install what `nix-build default.nix -A whatever` would have built
<clever>
you can also nix-env -f default.nix -iA whatever
<clever>
i think you can
<clever>
it lets you ./result/bin/foo to test things without installing them
<clever>
iqubic: that is a symlink
<clever>
iqubic: if you want it in your nix-env profile, then run nix-env -i /nix/store/path
<clever>
iqubic: nix-build always adds it to the store
<clever>
release.nix would have to be modified to correctly set crossSystem when generating the tarball
<clever>
crossSystem is an argument for import <nixpkgs> { crossSystem = ... ; }
<clever>
M-liberdiko: if any element of -A foo.bar.baz winds up being a function, it will be auto-called, using the args listed with --arg
<clever>
M-liberdiko: --arg doesnt work with -E
<clever>
nothing special
<clever>
non-root users can use any port between 1024 and 65535
<clever>
8081
<clever>
Enzime: nix-shell --pure will closely emulate that context
<clever>
tobiasBora: .script instead of .serviceConfig.ExecStart
<clever>
tobiasBora: activation scripts run both on bootup (before network is online, before systemd has even ran), and also when you nixos-rebuild switch
<clever>
its very easy for an activation script to break and stop the entire machine from booting
<clever>
create your own systemd service that will do the job, and flag it to run before openvpn
<clever>
oh, and id avoid using an activation script for that kind of task
<clever>
iqubic: you need to build it with nix, and then install it with nix-env
<clever>
iqubic: nix doesnt know about those executables, and will GC away the deps, and break them
<clever>
kalbasit: that sounds more like a nixpkgs test, rather then a nixos test, so it should be in the pkgs/top-level/release.nix i think, and the derivation should just fail if the test fails
<clever>
infinisil: id expect it to break when you GC
2018-07-13
<clever>
kalbasit: run `nix repl nixos/release.nix` and then type in `tests`
<clever>
kalbasit: run nix repl on that file and eval tests to poke around
<clever>
kalbasit: they are attributes on nixos/release.nix
<clever>
it can also be done with a --option flag, but i havent used that one much
<clever>
tobiasBora: that is a user@host, the arches it supports, the path to an unencrypted ssh private key, and then how many parallel builds it can support, the relative speed, and features
<clever>
thats why i pin the nixpkgs in the deployment config
<clever>
yeah
<clever>
also of note, if your nixpkgs rev is different, then it will be upgrading the rpi, so it has to download everything anyways
<clever>
yeah
<clever>
nixpkgs.localSystem.system = "aarch64-linux"; i think
<clever>
if you have set the arch to arm, yeah
<clever>
and then it will crosscompile EVERYTHING
<clever>
it will only crosscompile if you configure nixops to crosscompile
<clever>
or you can try the cross-compiling stuff, which is a bit more untested
<clever>
yes
<clever>
tobiasBora: no mater what, it must build at least a few of the files
<clever>
tobiasBora: it must still build config files like /etc/hosts
<clever>
tobiasBora: nixops is also specialized a bit more around the machine running nixops being able to do builds, but it can also use build slaves in the case where you cant
<clever>
tobiasBora: if you are deploying to 2 raspberry pi's, the laptop will download it once, then copy it to both pi's
<clever>
if you dont enable rollback support, then it can be GC'd
<clever>
yeah
<clever>
the machine running nixops will usually also be caching everything, so it only has to happen once
<clever>
thats just the way nix and nixops work
<clever>
tobiasBora: nixops builds it locally (or on a build slave), after evaling it locally
<clever>
tobiasBora: and this includes config files, which must be built on an arm device
<clever>
so when building something like the system-path directory, it must have a copy of every program in system-path
<clever>
when building any derivation, all of its inputs must exist
<clever>
which may be faster if your internet modem is the bottleneck
<clever>
it would download from the rpi->laptop
<clever>
tobiasBora: if you set the rpi up as a binary cache, it can
<clever>
tobiasBora: if you can paste the storepath of one of the programs it downloads, i can check its arch
<clever>
tobiasBora: if youve set the arch right in nixops
<clever>
tobiasBora: yeah
<clever>
tobiasBora: and all dependencies must exist before it can create something that depends on them
<clever>
tobiasBora: it doesnt know what the pi needs until after it has recreated the entire os
<clever>
iqubic: probably
<clever>
i always enable it
<clever>
pure xfce
<clever>
grp: echo $buildInputs or echo $nativeBuildInputs
<clever>
so if i spin up a second machine with slightly different boot config, it cant conflict
<clever>
manveru: i keep the bare minimum required to boot in configuration.nix, and put the rest into what you have named kappa.nix