<clever>
vitiral-lap: it should be in the logs for the vpn, i would think
<clever>
hask_bee_3: you could also switch to using -E, nix-shell -E 'with import <nixos-17.09> {}; stdenv.mkDerivation { name = "foo"; buildInputs = [ hello ]; }'
<clever>
infinisil: you would need to properly talk to resolvconf and dhcpcd, to insert a dns override, and remove it when disconnecting
<clever>
vitiral-lap: yeah, thats a common vpn problem, you have to use the vpn dns to connect to anything, but that also breaks dns when you disconnect
<clever>
vitiral-lap: what did it add?
<clever>
vitiral-lap: what about /etc/resolv.conf?
<clever>
vitiral-lap: lines 12/13 show that you have routes for tun0, so you should be able to ping any ip in the network
<clever>
hask_bee_3: nix-shell -p is hard-coded to use <nixpkgs>, so you need to use -I or NIX_PATH to setup nixpkgs to point somewhere
<clever>
vitiral: does `ip addr` show it as having an address, and is it listed in `ip route` ?
<clever>
vitiral: do you have a new interface in `ip link` when its ocnnected?
<clever>
chreekat: try running that as root
<clever>
Baughn: however, the dhcp client in some of my bios's for netboot, times out rather fast, and fails before the port fully enables
<clever>
Baughn: the ethernet link is "live" for several seconds, without any routing, as it waits for SPAN broadcasts, to confirm i didnt f-up and create a cycle and broadcast storm :P
<clever>
Baughn: related, ive had issues with the SPAN support in my old cisco switch
<clever>
Baughn: lol
<clever>
hask_bee_3: just throw it into your .bashrc and it should be good
<clever>
Baughn: ah, yeah, online detection can be fun
<clever>
Baughn: heh
<clever>
pikajude: pkgs.runCommand
<clever>
chreekat: any time you do something like import "${foo}" where foo was a derivation
<clever>
chreekat: import from derivation can cause builds at eval time
<clever>
freeman42x]NixOS: somebody changed the haskell expressions, and didnt re-test its effects on 784
<clever>
freeman42x]NixOS: theres probably something wrong with the 784 package set
<clever>
freeman42x]NixOS: line 60 says that its somehow related to loading ghc-mod
<clever>
heh, the standard wall-of-text error!
<clever>
freeman42x]NixOS: what do you get if you --show-trace the error?
<clever>
it might be that the 784 package set is broken
<clever>
freeman42x]NixOS: do you have an overrides dealing with ghc-boot?
<clever>
__monty__: oh, if you just want to update the buildEnv, just -iA it again
<clever>
__monty__: -e only works on names, check nix-env -q to see the names
<clever>
__monty__: move?
<clever>
__monty__: i think the last one should work
<clever>
__monty__: under gentoo, it uses the channels from the user that installed nix
<clever>
Guanin_: also, you could do "sd${letter}1" and then drop the 'sd' and '1' from the list on 15
<clever>
Guanin_: try + instead of ++
<clever>
ottidmes: // will merge the set without recursion
<clever>
jsgrant_: can you gist that systemd one-shot service for Guanin_?
<clever>
Guanin_: and just throw a wall of bash at it
<clever>
Guanin_: simplest thing i can think of, is to create a systemd service that opens things after the machine has booted
<clever>
Guanin_: it looks like nixos doesnt have much support right now for opening luks devices unrelated to the rootfs, or opening things with keyfiles
<clever>
Guanin_: ah, yeah, this all happens before nixos begins mounting things
<clever>
angerman: sure
<clever>
sphalerite_: ive already seen users run into that problem when they try to install .dev to get headers working :P
<clever>
Guanin_: that will cause nixos to open the luks devices within the initrd, while booting
<clever>
sphalerite_: ah, thats probably meta.outputsToInstall i think
<clever>
sphalerite_: id try passing an absolute path and see what happens
<clever>
sphalerite_: but i did want to also make a plugin, that could mess with nix-store -q, to find the debug for any given binary, and fetch that debug off cache.nixos.org automatically
<clever>
sphalerite_: last time i delt with that, i had to manually add the right storepaths to the search path
<clever>
dalaing: the key detail, is that all import from derivation is broken in hydra evals
<clever>
dalaing: id say yes, ive also run into the same issue last week
<clever>
Guanin_: ah, is the raid array entirely seperate from the nixos root fs?
<clever>
Guanin_: you will need to fill that list with every luks device you have
<clever>
Guanin_: a configuration.nix entry like this, says that nvme0n1p2 is a luks device, it should be opened under the name root, and it should be opened before lvm is initialized
<clever>
Guanin_: but luks isnt auto-detected, youll need to add something like this to configuration.nix: ....
<clever>
Guanin_: then read the config it generates in /mnt/etc/nixos/, it configures some of it for you
<clever>
Guanin_: to start with, you will want to manually unlock all 11 luks devices, and assemble the mdadm raid, then mount it to the right spot under /mnt/, and run nixos-generate-config --root /mnt/
<clever>
fragamus: nix-shell -p stack2nix, then use it to generate a default.nix, and leave that shell, then you can just nix-build -A project, to build a given cabal project inside the stack project
<clever>
fragamus: in general, you shouldnt put development stuff into configuration.nix, but open a nix-shell with them
<clever>
dalaing: cabal2nix should work fine, its callCabal2nix that causes the issue
<clever>
fragamus: the ghc flags in the stack file are ignored
<clever>
infinisil: also, stack leaves things linking into the store in .stack-work, and then garbage collection breaks builds
<clever>
fragamus: i also prefer always building with nix, and just basically ignoring stack entirely
<clever>
niksnut: looks like you already found a lot of edge cases i hadnt thought about, my initial idea was to just tweak the forceValue implementation so it wouldnt falsely detect another thread's blackhole
<clever>
so it can fully resolve the toplevel derivation, but still return the entire tree, if you wish to do more complex things later on in the expression
<clever>
niksnut: and also something to actually return, just: systems
<clever>
niksnut: my idea, was to treat parallelMap similar to trace, you give it a list of thunks that you forceValue, like: map (x: x.config.system.build.toplevel) systems
<clever>
LnL: memoise looks simple, but you have to insert it everywhere you want gains, one of the other ideas i had was to alter the parser, to just memoize everything
<clever>
caching thunks and their outputs
<clever>
LnL: ahhh, thats a second half of what i was planning, that would be a lot more of an invasive change
<clever>
LnL: ah, ise, thats why i didnt find it with a quick search
<clever>
ah
<clever>
LnL: do you have more details?
<clever>
LnL: nope
<clever>
hask_bee_3: yeah, that should be fine
<clever>
niksnut: what do you think about adding a parallel map, to speed up the example in that gist?
<clever>
given enough cores, it could reduce a 36 second job down to 2 seconds
<clever>
sphalerite_: youve probably seen my qemu-user stuff?
<clever>
just forceValue() each item in the list, in seperate threads
<clever>
i think so
<clever>
sphalerite_: that reminds me, i had an idea for a new builtin, par
<clever>
:D
<clever>
yonk_: ah, that is probably it
<clever>
yonk_: what is in your hardware-configuration.nix file?
<clever>
yonk_: so it cant run any 32bit binaries
<clever>
yonk_: you somehow have 32bit support turned off in the kernel
<clever>
# CONFIG_IA32_EMULATION is not set
<clever>
sphalerite_: but if you know which derivation is failing a lot, you could config.nix package-override just that
<clever>
sphalerite_: oh
<clever>
rebuild the world, at least once
<clever>
but adding that to a derivation, changes the hash, so you get zero help from the binary cache
<clever>
that allows nix to remember it
<clever>
sphalerite_: if you set succeedOnFailure=true; on a derivation, it will still succeed, even upon failure, and create a $out/nix-support/failed file