<clever>
ryantrinkle: run nix repl on release.nix, and look at the build attribute
<clever>
kandinski: the issue has to do with xauth files, we need to find a fixed path that the tokens can be found in, and pass them to xauth
<clever>
kandinski: the synergy service was broken when a security problem in xorg was fixed
<clever>
either by putting that into a file or by using -E
<clever>
boomshroom: yeah, you still have to evaluate: with import <nixpkgs>{}; callPackage ./foo.nix {}
<clever>
boomshroom: it has to be loaded with callPackage i'm guessing
<clever>
ping
2018-03-29
<clever>
webchat: its dynamicaly linked, but nix tracks things better, and forces a rebuild because nix thinks that the libc change could have any kind of side-effect on the build
<clever>
tmplt: all attributes given to mkDerivation just become env variables at build-time
<clever>
ah
<clever>
proot might be forcing 32bit only, and your /bin/sh is 64bit
<clever>
i just use it as a guideline and delete the checkboxes that dont count
<clever>
to find out why it wont let you delete things
<clever>
run nix-store --delete /nix/store/hash-name
<clever>
you do
<clever>
tobiasBora: nix-store --query --roots and nix-store --delete
2018-03-28
<clever>
jluttine: if its in the same derivation, it will trigger a rebuild
<clever>
in the case of firefox and chrome, there is also an unwrapped package
<clever>
yeah
<clever>
so it only has to "recompile" the bash script when the runtime thing changes
<clever>
the 2nd derivation generates a bash script that just prefixes PATH, then runs the binary from the 1st
<clever>
jluttine: thats exactly how the firefox/chrome plugins are managed
<clever>
jluttine: make a 2nd derivation, that wrapProgram's the PATH over the 1st's binary
<clever>
jluttine: i would use makeWrapper and prefix PATH with the bin dirs
<clever>
for the things that depend on it
<clever>
vaibhavsagar: propagatedBuildInputs is only at build-time
<clever>
vaibhavsagar: shellshock i believe was just because bash was in the workflow, but no bash scripts where involved
<clever>
and given how much its used
<clever>
if bash is already in-ram, the binary size doesnt really matter much
<clever>
unlmtd: what will /bin/sh be then?
<clever>
yeah, it can also be used for that as well if the normal shell is broken
<clever>
unlmtd: i have a dedicated user called builder that is used for all remote builds
<clever>
unlmtd: double-check that PATH is being handled properly for non-interactive shells
<clever>
unlmtd: how did you try running it?
2018-03-27
<clever>
michas_: nothing says you cant just keep using that disk image as a server
<clever>
michas_: the 1st step runs the test env for justdoit, where just logging in and running justdoit will install nixos, the 2nd step runs it with just the disk image from the 1st, to confirm it boots
<clever>
michas_: oh, you could also use that justdoit release.nix just to get nixos running inside qemu
<clever>
michas_: ah
<clever>
michas_: you could potentially chain the 2 things, so the netboot server is also a diskless nixos inside qemu!
<clever>
michas_: line 6 grabs a configuration.nix that already references the netboot-base file, then builds its kernel+initrd, and boots those directly in qemu
<clever>
michas_: i also have methods of booting a diskless nixos image in qemu
<clever>
michas_: since your not using it to install things,line 12 and 21-26 of my version can just be commented out
<clever>
michas_: thats a nixos module, just add imports = [ ./netboot_server.nix ]; to your existing configuration.nix, and set netboot_server.network = { wan = "foo"; lan = "bar"; }; with the right interface names
<clever>
michas_: lines 20-27 is the config for the OS that the target machines run
<clever>
michas_: originally, i had written that to turn my old laptop into a netboot server, to it could hijack the new laptop, and it also includes justdoit (line 12), which will wipe the entire machine with 1 command (run justdoit, lol :D), but you can customize it to run other services and remove that
<clever>
michas_: it also handles the dhcp and dns server, and performs NAT between the internet and the LAN that the client machines are on
<clever>
michas_: this is a complete diskless nixos server, without even an NFS mount, the machines run entirely from a ramdisk, and all state is lost at reboot
<clever>
but a side-effect is that <lib> also works, but only when the path is set "wrong"
<clever>
so <nixpkgs> still maps correctly
<clever>
ottidmes: sometimes NIX_PATH can wind up set like NIX_PATH=/home/clever/nixpkgs/ and the dist tarball includes a nixpkgs symlink to .
<clever>
and then registering it as valid
<clever>
manually copying it into /nix/store
<clever>
there was a thing on the nix mailing list, about using a nix tool to compute the output path of a given thing
<clever>
throwup: since it doesnt exist for newly created users
<clever>
throwup: i would expect the desktop env to replace that on login
<clever>
elvishjerricco: not sure
<clever>
throwup: have you rebooted yet?
<clever>
infinisil: also look into tarsnap
<clever>
though if you aggregate 2 links with a vpn, you can bypass that
<clever>
and tcp connections cant change uplink
<clever>
infinisil: but the problem is that half your facebook http connections tie up one uplink, keeping it "busy" with idle connections, then all your high bandwidth stuff is stuck on the 2nd modem
<clever>
infinisil: iptables has a way to load-balance with some weights, and then bind each connection to a given interface
<clever>
now i have 300mbit down and i cant max it out, lol
<clever>
infinisil: i used to use tc, back when my router ran LFS and i only had 600kbyte/sec down
<clever>
fresheyeball: you must use super.haskellPackages.override { overrides = { hsself: hssuper: { ... }; }; }; to write a haskellPackages overlay
<clever>
fresheyeball: // overwrites the hlibsass atttribute of the resulting haskellPackages, but it does not make other haskell packages use the new version
<clever>
fresheyeball: can you gist the overlay?
<clever>
anixos: i think you need to set mutableUsers = false; for that to work
<clever>
anixos: are you using hashedPassword or initialHashedPassword?
<clever>
yep
<clever>
it will need device and fsType
<clever>
neededForBoot is automatic
<clever>
yeah, if the data has already been moved, you dont need it
<clever>
if the data is already moved over then you just need to update configuration.nix and reboot i believe
<clever>
make the new LV, format it, and move all of /nix over
<clever>
then youll have a new generation in grub that expects it to be moved, and an old that doesnt
<clever>
how: you can add filesystems."/nix" = ... and `nixos-rebuild boot` before you move it, to save some trouble
<clever>
how: ive used that to do exactly what your doing, move my laptop /nix into its own zfs dataset
<clever>
how: for rescue-boot, you add imports = [ ./rescue_boot.nix ]; to your configuration.nix, and it will generate a new grub option that boots into a rescue OS
<clever>
how: boot from another system, like the installer iso or a recovery image
<clever>
how: id recomend moving it while the system is not running, just rsync the data to the new filesystem, delete the old, and convince it to boot with the new fs mounted at the right place, then fix the nixos config
<clever>
nick_l: line 30 says it will accept any icmp with type 8, which should be ping-request
<clever>
ive written my own VPN and have brought wifi up without wpa_supplicant before
<clever>
it gets every table
<clever>
i also prefer using iptables-save to list the rules
<clever>
and then icmp, when allowed, is accepted later on, for all interfaces
<clever>
the lo interface is special-cased in the firewall to accept everything
<clever>
neonfuz: if you have never installed something with nix-env as root, then that wont exist
<clever>
neonfuz: thats what .nix-profile is supposed to point to
<clever>
Hackapepper: looks good
<clever>
Hackapepper: this will cause the final nix binary to try to act on $HOME/nix/store, using the value of $HOME from the build host, not the target machine
<clever>
krey: also, buildEnv itself is a derivation, so you dont need to symlink it to $out
<clever>
krey: you almost never need to set the builder attribute
<clever>
so it works without the env vars
<clever>
and the overrides are to make the nix within that non-standard store act on the same non-standard store, during its own runtime
<clever>
infinisil: yeah, the env vars are to affect the un-modified nix, to make it act on a non-standard store
<clever>
neonfuz: expanding is easy, shrinking is imposible
<clever>
while debian cant really undo updates so seamlessly
<clever>
kandinski: the biggest difference is that nixos has rollbacks, so you can undo any change
<clever>
neonfuz: probably just personal preference
<clever>
kandinski: the simplest thing right now would probably be to just run nixos-unstable for a month, its a lot more stable then the name sudjests
<clever>
neonfuz: i use this bash script to install my systems
<clever>
Hackapepper: probably, youll also want to change the confDir in the override
<clever>
yeah, that will switch it over to a 32bit nix
<clever>
for root itself, its just ~/.nix-defexpr/channels/nixos/
<clever>
the channels_root directory points to the channels managed by root
<clever>
kandinski: compare the files modified in the PR to what you have in ~/.nix-defexpr/channels_root/nixos/
<clever>
allowing you to build it for a path you cant make
<clever>
and then NIX_REMOTE to re-root that, so you dont need write to that final destination
<clever>
and the .override, so that nix will target the same place
<clever>
NIX_CONF_DIR, NIX_LOG_DIR, NIX_STORE all have to be set when running nix-build, to modify the config of where the nix its making will live
<clever>
infinisil: the main limit i can see with your variant, is that the nix it initially builds still lives in the store of the nix that built it, not the paths you passed to it
<clever>
while evaluating 'makeSearchPathOutput' at /home/clever/apps/nixpkgs/lib/strings.nix:94:42, called from /home/clever/apps/nixpkgs/pkgs/applications/virtualization/docker/gc.nix:23:28:
<clever>
and now i can just --show-trace it
<clever>
i can also reproduce that issue on a random rev of nixpkgs i jsut happened to have checked out
<clever>
i think
<clever>
nix-instantiate pkgs/top-level/release.nix -A docker-gc.x86_64-darwin
<clever>
typetetris: so now try to nix-build docker-gc on darwin and see what happens
<clever>
typetetris: it sounds like docker-gc somehow depends on procps-ng
<clever>
typetetris: does hydra say anything else on nearby lines?