<clever>
something would have to be seriously wrong with the build slave, or the xz program is being broken
<clever>
yeah
<clever>
same storepath for the .tar.xz, for both the good and bad builds
<clever>
yeah, i see it on hydra
<clever>
yep, thats normal
<clever>
magnetophon: cant see anything weird with the derivation, it should just work
<clever>
oops, doubled it up a tad, but that command will give you the exact tar hydra is using
<clever>
magnetophon: and one neat quirk of how the binary cache works, nix-store -r nix-store -r /nix/store/yckqmy6q8sl988x3i5g1sbb310ig5f1v-x42-plugins-20160825.tar.xz
<clever>
magnetophon: looks like it should just use line 519-522
<clever>
tomberek: and the page ends with <tr><td rowspan="1" c
<clever>
tomberek: that is oddly short...
<clever>
domenkozar: .a files are basicaly just a zip of .o's, at least in the non-haskell world
<clever>
marvin3k: nix-store forwards the env variables to nix-daemon
<clever>
marvin3k: nix will also block out nearly all env variables, only a fixed-output derivation can get some, but you need to use an agent, or the key is still readable to every builder
<clever>
marvin3k: nix will use the env variables from the nix-store command, not the nix-daemon command
<clever>
marvin3k: fixed-output derivations are special, the path depends on the contents, rather then the directions
<clever>
marvin3k: but then the output path of that will depend on the implementation, and everything after that will rebuild without warning
<clever>
and nix-daemon enforces the rules, so the bad sudo winds up at a different path
<clever>
marvin3k: and the $out path is based on a hash of the script nix-daemon runs to produce it, so if a malicious user builds a tainted copy of sudo, it will be at a different path, and nobody will use it
<clever>
marvin3k: the rest of the derivations, nix-daemon will fork of a child to do the build, which runs as a member of the nixbld group
<clever>
marvin3k: nix-instantiate will generate the contents for .drv files, which are stored at a path based on the hash of their contents
<clever>
marvin3k: nix-daemon also manages the builds
<clever>
marvin3k: so only you can revoke the keys when your done, or just not put the agent in the include path when you dont need it
<clever>
marvin3k: that guide gives every single job you build read access to the ssh private key
<clever>
marvin3k: then nix-build will run nix-store -r on the drv files, to build everything
<clever>
marvin3k: when you run nix-build, it will internaly call nix-instantiate as your user (so your NIX_PATH matters), and that will talk with the daemon to write files to /nix/store
<clever>
marvin3k: nix-daemon comes into play after $NIX_PATH has done its job
<clever>
monad_cat: i think its nix.nixPath, check the man page for configuration.nix
<clever>
monad_cat: nixpkgs is what loads configuration.nix, so whatever you set within there will only take effect after the build is done (when its too late to matter, but it will effect the NEXT rebuild)
<clever>
that makes no sense, unstable updated 4 hours ago, but the change was commited in march
<clever>
i think somebody broke config.platform on unstable, but it appears to already be fixed on master
<clever>
error: attempt to call something which is not a function but a set, at /nix/store/442fh8j84z1ixqa1sj71kdl3hlbjy3dx-git-export/pkgs/top-level/default.nix:52:9
<clever>
monad_cat: that can also work, as long as you wrap it with ( and )
<clever>
monad_cat: you can just make a packageOverride with foo = pkgs.callPackage /home/clever/nixpkgs/foo/bar/default.nix {}; to get just 1 package, or kmicu's command to get all
<clever>
lula_: can you gist your configuration.nix and the files listed under imports?
<clever>
lula_: the syntax is identical to configuration.nix, thats already a nixos module
<clever>
lula_: create a nixos module that puts it into systemPackages?
<clever>
vdemeester: glibc.static needs to be in the buildInputs
<clever>
vdemeester: there are sometimes options in the cmakelists.txt file to enable static building
<clever>
signal4: i dont think there are any ld flags you would want to tune
<clever>
chpatrick: because packages keep ignoring the old $LDFLAGS variables
<clever>
chpatrick: the g++ in $PATH is a shell script that obeys the special $NIX_ ones
<clever>
chpatrick: have a look at the output of "env | grep NIX_"
<clever>
chpatrick: that one should have g++ available, the stdenv will alter $NIX_LDFLAGS and similar variables, to make it find everything in the buildInputs at compile/link time
<clever>
chpatrick: what arguments are you calling nix-shell with?
<clever>
chpatrick: but there is nix-shell --pure, which will clean $PATH up more
<clever>
chpatrick: the sandbox only works for automated builds
<clever>
gchristensen: so if it goes offline without warning, the lack of a msg causes an update
<clever>
gchristensen: i was thinking of udp packets sent at regular intervals, advertising the builder username, and the supported arches
<clever>
chpatrick: just run nix-shell on your derivation, and use configure+make as normal
<clever>
chpatrick: nix-shell should be fine for that
<clever>
chpatrick: for a manual or automated build?
<clever>
gchristensen: so i just need a bit of software to detect the slaves coming and going, and add/remove them from a 2nd machines file
<clever>
gchristensen: and with the hydra option you helped find, i can dynamicaly add that slave to hydra without a rebuild-switch
<clever>
and all state is wiped clean at reboot
<clever>
gchristensen: 100% of its writeable storage, is tmpfs's, with swap for the overflow, so there is nothing left to corrupt upon improper shutdown
<clever>
and it is happily building nix packages in a sandbox
<clever>
gchristensen: but i now have a build slave running on a 40mb ramdisk
<clever>
yeah
<clever>
i made my build slave a little too minimal
<clever>
the entire dns subsystem of linux lost the ability to identify what a bare IP address was
<clever>
gchristensen: whats worse, is that ntpdate was unable to resolve 192.168.2.1, because /etc/services was missing
<clever>
then the source is always newer, and it can never finish the build
<clever>
ronny: tools like make compare the mod-times of everything, and if the new .o's are from 1970, and the source is from 2016
<clever>
but that will only happen on systems that are not configured properly, until we get time travel :P
<clever>
if the time is prior to the source tar's creation, it needs more tools
<clever>
so technicaly, the build dependencies depends on the time
<clever>
ronny: at least one of the failed builds, where caused by configure.ac being newer then configure, so it wanted autoconf, which wasnt in buildInputs
<clever>
2 or 3 packages refused to compile, because it was 1970
<clever>
ronny: clocks, and overly pure envionments also caused a couple build failures on my end
<clever>
uptime cant go backwards, and ntp cant make uptime skip ahead
<clever>
domenkozar: for measuring elapsed time, the uptime is usualy better
<clever>
gchristensen: ive had an even worse bug in my irc server before, if the clock went backwards even 1 second, all of the math overflowed, and every single user ping timeout'd
<clever>
in my case, the clock advanced by ~46 years
<clever>
if the clock advances by more then 10 hours, nix thinks the build has gone 10 hours without any output, and kills it
<clever>
LnL: its an extremely slow leak, so its hard to even notice until you have months of uptime
<clever>
LnL: and at the other extreme of memory usage, i now have a nix build slave, running on a 40mb ramdisk
<clever>
LnL: that has no effect on performance, until it runs out, the cause is a memory leak, so the data in swap is never referenced again
<clever>
LnL: ive done worse, one of my servers has 64gig of swap, which fills up about 2 or 3 times a year
<clever>
LnL: ah
<clever>
signal4: only thing left now, is to figure out which of your tweaks to the build is causing it, try just turning them off one by one?
<clever>
LnL: ?
<clever>
signal4: so now you need to figure out why /nix/store/yw47gp1zd8y143d3wvsank97gbq55lg8-systemd-231/lib/systemd/catalog/ is present in the $lib output
<clever>
signal4: $lib doesnt make any reference to $out on my systemd
<clever>
sphalerite: look at the contents of the ghc script itself
<clever>
signal4: the next step is to run the same procedure on a valid systemd, to see how yours differs
<clever>
sphalerite: run file on the result of the ghc in "type ghc"
<clever>
signal4: and a bunch of libraries in $out that depend on $lib, there is the cycle
<clever>
signal4: ok, so you have a single library in the lib output, that depends on $out
<clever>
domenkozar: so once the 68-98 block has ran, mount-count should be +1, so the -C 0 on 65 wont help any (it will be 1, not 0, and resize2fs will want a check)
<clever>
signal4: ok, so the systemd.so in -lib output depends on the main $out output, now we check out
<clever>
domenkozar: and its not safe to mess with the filesystem while its mounted
<clever>
domenkozar: the mount operation on line 68 will increment the mount-count
<clever>
need to reset it to zero after 98, once its been umount'd
<clever>
so the -C 0 would be pointless
<clever>
that happens right before it mounts
<clever>
domenkozar: every time mount-count reaches max-mount-counts, it will want to do a regular fsck
<clever>
domenkozar: -c is a related option, that is max-mount-counts
<clever>
domenkozar: i think the kernel will increment the mount-count every time you mount it r/w, and fsck resets it to zero upon finishing
<clever>
domenkozar: tune2fs may also work, -C i think
<clever>
signal4: now run strings on that so, and pipe it thru the same grep (omiting the lib path), that should tell us which thing its referencing
<clever>
but you would have to modify whatever was calling resize2fs
<clever>
domenkozar: there is a force option in resize2fs, -f Forces resize2fs to proceed with the filesystem resize operation, overriding some safety checks which resize2fs normally enforces.
<clever>
domenkozar: it wont risk the chance that some corruption went unnoticed, and horribly screws things up
<clever>
domenkozar: resize2fs refuses to resize an FS until fsck has flagged it as clean
<clever>
signal4: we then need to run a similar command, on whatever turns up
<clever>
ronny: ive found some tabs that date back to 2 or 3 months ago before
<clever>
rly: it takes chromium an hour to resume
<clever>
rly: poorly :P
<clever>
if your as insane as i am (over 800 tabs in chrome right now), 32gig of swap and 16gig of ram
<clever>
rly: so it will just skip the hdd half the time, if you have enough ram
<clever>
rly: another quirk of how i setup this build slave stuff, that may improve speed a lot, the nix store is union'd with a tmpfs, so all buildInputs go to ram first (and swap second)
<clever>
i think i stripped it down a bit too much
<clever>
and sucess!, it needed a /etc/services file to "resolve" an ip to an ip, lol
<clever>
6 Dec 10:19:16 ntpdate[198]: step time server 192.168.2.1 offset 1481019508.187349 sec
<clever>
i now run on a pair of SSD's in a zfs mirror, so data loss isnt as likely
<clever>
i was on a magnetic hdd at the time, and performance didnt really improve when i switched to zfs
<clever>
then it took another hour for nix-collect-garbage to get rid of the test files
<clever>
rly, jazzencat: when i was messing with hydra stuff on btrfs (it wanted to create 12,000 files), it took over an hour, and ended with the filesystem going read-only until i rebooted
<clever>
but e.assert doesnt let you access it, needs e."assert" and now its more complex to use
<clever>
oh, wasnt expecting { "assert" = "bar"; } to also work
<clever>
qknight: so does this: nix-repl> { "${"assert"}" = "bar"; }
<clever>
qknight: this happens to work
<clever>
qknight: nix-repl> let foo."assert" = "bar"; in { inherit (foo) "assert"; }
<clever>
rly: sed? heh
<clever>
rly: simplest (and most ugly) thing i can think of is php, just foo = <?php echo $foo ?>; as needed
<clever>
qknight: i think meta is fine, but throw/assert will probably have trouble
<clever>
ocharles_: its configured via nix.buildMachines in configuration.nix
<clever>
ocharles_: it always needs a slave in /etc/nix/machines
<clever>
yep
<clever>
nekroze: i dont see any way to insert commands (like ulimit) before systemd-nspawn, so you would need to modify a clone of nixpkgs and rebuild with -I nixpkgs=foo to test
<clever>
find out which plugin is causing it to rebuild the heavy part
<clever>
ive noticed an issue with one of the plugin options recently
<clever>
try commenting one of the plugins out and see what nix-env does
<clever>
can you pastebin ~/.nixpkgs/config.nix ?
<clever>
is this happening at nixos-install, nixos-rebuild or nix-env?
<clever>
64bit or 32bit?
<clever>
i just grab it from the binary cache and its done
<clever>
e1: cant think of any reason why its missing, is it causing an issue on your end?
<clever>
and then it will round-robin between them as they call accept() (or go to just the new, if the old never calls accept again, and closes)
<clever>
angerman: this lets you pass an open file descriptor between processes, so the old instance can pass the handle to the new instance, without the port ever closing
<clever>
angerman: there is also a unix feature that may be of use
<clever>
and the new intance re-opens the port
<clever>
then the old instance closes the listening socket, but continues to handle open connections to nginx, and shuts down once all are handled
<clever>
angerman: so you may want to re-implement what lighttpd has done within your application, the new instance signals the old instance
<clever>
angerman: ah
<clever>
angerman: if you name an http server, i can see if nixos already has anything special for it
<clever>
you will need to look into what your http server offers for seamless restarts
<clever>
lighttpd has a special seamless restart mechanic in it, where the new instance will contact the old instance, and then the old one stops listening but keeps serving the open connections
<clever>
the rest, would depend a lot on what http server your using, and if you want nix to also manage its config
<clever>
angerman: if you ran that on say public_html, it would atomicly swap the entire document root out in one command
<clever>
angerman: this command will replace a symlink called something, with a link to /nix/store/foo, and make that something a GC root
<clever>
anelson: pretty much all i did last time was hardware.wireless.enable = true; and wpa_passphrase ESSID >> /etc/wpa_supplicant.conf
<clever>
the wiki hasnt been updated in ages and is read-only
<clever>
anelson: no idea what happened to wpa_supplicant, last i tried (a month ago) it just worked when i put a config file in /etc/wpa_supplicant.conf
<clever>
marantz: line 9 of the link, exactly what i said to remove