<clever>
or just edit configuration.nix instead, since nixos merges them together for you
<clever>
colecf: so if you want changes in hardware-configuration.nix to stick, you have to stop running nixos-generate-config
<clever>
colecf: nixos-generate-config will scan things like what is currently mounted, and then just blow away the whole hardware-configuration.nix and replace it
<clever>
colecf: add it to configuration.nix instead
<clever>
it needs its own syntax engine, vim-nix is one of them
<clever>
yep
<clever>
also, you dont want ${rcfile} but just rcfile;
<clever>
its much more visible when gist does syntax highlighting
<clever>
sxiii: the line before openbox/rc.xml, you have an autostart outside of the string
<clever>
sxiii: can you pastebin the configuration.nix file?
<clever>
la-jesystani: use an overlay, also in the nixpkgs manual
<clever>
hyper_ch: if you can configure the VM to forward trim from guest->host, then you can run fstrim inside the guest, or just mount it with auto-trim
<clever>
hyper_ch: the zvol has to be mounted only on the host for you to fstrim it
<clever>
hyper_ch: the manual trim tells zfs to forget about the unused blocks, and trim forwarding in the vm would automate it
<clever>
hyper_ch: nfs would let zfs know exactly what is happening, so the problem just vanishes
<clever>
hyper_ch: so the snapshots are holding onto every single deleted file as well
<clever>
hyper_ch: basically, when you delete a file in the guest, zfs doesnt know those blocks are unused
<clever>
hyper_ch: but you would still need to repeat that dance regularly, or setup trim forwarding in the vm, or use nfs
<clever>
hyper_ch: that will reduce your usage by 307gig immediately, and make any more snapshots you create a bit more optimal
<clever>
hyper_ch: umount it within the vm (or shutdown), then mount it anywhere on the host, and run fstrim against it
<clever>
hyper_ch: so if you run `blkid /dev/tankHB/encZFS/VMs/Mail` it reports ext4 directly?
<clever>
hyper_ch: what is within tankHB/encZFS/VMs/Mail? mbr? ext(2|3|4) ?
<clever>
hyper_ch: and its keeping that extra 307gig in every snapshot
<clever>
hyper_ch: yeah, you definitely want some trim, your only using 67gig, but zfs is keeping the unused blocks, so its using a total of 374gig for the current version
<clever>
la-jesystani: that should be in the nixpkgs manual
<clever>
hyper_ch: can you pastebin this? zfs list -t volume -o name,used,referenced,logicalused,logicalreferenced,written,usedbysnapshots,usedbydataset,refcompressratio,compressratio,compression,mountpoint,sync
<clever>
hyper_ch: is that a snapshot of a zvol?
<clever>
hyper_ch: so if you can configure the VM to pass the trim commands thru, it would help
<clever>
hyper_ch: one thing ive found, is that if i mount an ext4 zvol on the zfs host, and run fstrim, the zvol shrinks massively
<clever>
hyper_ch: unused blocks in the zvol probably
<clever>
hyper_ch: ahh, a zfs filesystem is better for that
<clever>
hyper_ch: you can also use a zvol to give the VM its own dedicated disk as a dataset
<clever>
hyper_ch: correct, i'm not sure if `zfs nfs export` even works on linux, it might be a solaris-only thing
<clever>
hyper_ch: but the clients are just more nixos machines on the LAN, not VM's
<clever>
hyper_ch: nfs.server = { enable = true; exports = ''.....''; }; is what ive been using
<clever>
and also to just search packages
<clever>
i use it to both experiment with new exprs, and to verify a nix file is doing the right thing
<clever>
yep
<clever>
and just a bit of tab-completing in `nix repl '<nixpkgs>'` and i find this
<clever>
Miyu-saki: depending on which backend your using, the nixops key itself may also be in /root/.ssh/authorized_keys
<clever>
matthewcroughan: that will install dolphin from master, but every time you nixos-rebuild, it will check if master has changed, and may cause a surprise rebuild if master has changed
<clever>
Miyu-saki: if you have your own keys in /root/.ssh/authorized_keys then you can get in anyways
<clever>
matthewcroughan: youll also want an overlay then, to be able to get dolphin master from configuration.nix
<clever>
matthewcroughan: not even files in / will persist
<clever>
matthewcroughan: thats more extreme, it wipes everything
<clever>
matthewcroughan: then use nix-env -e to uninstall things, and `nix-env -q` to list them
<clever>
matthewcroughan: nix-shell based stuff wont persist across a reboot
<clever>
kini: and the override can only update that if it changes all of the cmakeFlags
<clever>
kini: because the original expression is using cmakeFlags to set the version based on the original git rev
<clever>
drakonis: the developers encourage you to constantly update to latest, and the emulator itself enforces that everybody in multiplayer has a matching gitrev
<clever>
matthewcroughan: nix disables the network, and hashes every single input, so if any input changes, nix redoes the build
<clever>
matthewcroughan: it solves the nasty problem of things like `docker build` can just grab whatever it wants over the network, and you get a different version every time you build
<clever>
but your changing the cmakeFlags input
<clever>
matthewcroughan: if the inputs to a derivation havent changed, nix can reuse the entire output, as a cached build
<clever>
matthewcroughan: having something like ccache involved would poison it all
<clever>
matthewcroughan: nix's purity is based on hashing every input to a build, and redoing the build if any input has changed
<clever>
matthewcroughan: nix only has derivation level caching
<clever>
matthewcroughan: correct
<clever>
kini: yeah, that would make the override much simpler then what i gave above
<clever>
so you must set that to the revision your actually building from
<clever>
and if that string doesnt match, it assumes your not compatible
<clever>
internally, dolphin bakes DOLPHIN_WC_REVISION into its binary, and then shares that with the other multi-player members
<clever>
zecnate: you can use `--option sandbox-paths "paths"` to set it manually on a per-build basis
<clever>
zecnate: you could set sandbox-paths in nix.conf, to add usr/bin/env
<clever>
zecnate: because using /usr/bin/env in the final scripts installed to $out isnt pure, it encourages you to patchShebangs, so it becomes an absolute path
<clever>
yep
<clever>
yeah
<clever>
buckley310: exactly the same way -I works in gcc
<clever>
buckley310: it didnt find /var/empty/foo, so it tried the next sconfig in the search path
<clever>
buckley310: when you do <sconfig/foo> it will search for a foo in each sconfig
<clever>
then just use -I sconfig=
<clever>
buckley310: if you want to make smaller changes to just a part of it, the code has to be designed to allow those changes without replacing the whole <sconfig>
<clever>
buckley310: `-I sconfig=/path/to` lets you just override the whole thing by force, even if it wasnt made to accept it
<clever>
buckley310: all of your nixos modules get merged together, and you can use mkForce to override things
<clever>
buckley310: also, anything you put into imports, is a nixos module, which is seperate from nixpkgs
<clever>
buckley310: you can only add overrides if it was designed to accept overrides
<clever>
buckley310: which other channel do you want to override, and what?
<clever>
buckley310: -I nixpkgs=/path/to/nixpkgs
<clever>
and you should see the source
<clever>
run `nix-shell -p` then `type patchShebangs`
<clever>
or to give it a pre-built openssl?
<clever>
is there no way to tell it to just do the untar step?
<clever>
that maps /bin/sh to busybox when inside the sandbox