<clever>
did you pass yes to any config params when building nix?
<clever>
crystalgamma[m]: and its failing because the path "yes" does not begin with a /
<clever>
crystalgamma[m]: the error came from here
<clever>
src/libutil/util.cc: throw Error(format("not an absolute path: '%1%'") % path);
<clever>
crystalgamma[m]: it appears to still be finding all of those libs in /lib/
<clever>
i suspect what your seeing is entirely normal
<clever>
crystalgamma[m]: can you pastebin the whole strace output?
<clever>
crystalgamma[m]: which one?
<clever>
crystalgamma[m]: try running it under strace to see what its doing, or add -vvvv to the nix command
<clever>
probably, check what each result points to and decide if you want to keep it or not
<clever>
`ls -l /nix/var/nix/gcroots/auto` is a list of all result links you have forgotten about
<clever>
nix-build also creates such links
<clever>
only build creates a result link
<clever>
magnetophon: both test and switch should not create result links
<clever>
magnetophon: what is your current alias?
<clever>
magnetophon: rm -rf will fail, because the output is in the store and read-only
<clever>
MichaelRaskin: lol :D
<clever>
chmod -R is recursive, so you just point it at the root and it does it all
<clever>
in reverse order
<clever>
and the directory that directory is in
<clever>
and the directory that directory is in
<clever>
and the directory that directory is in
<clever>
bhipple[m]: you have to also +w the directory the file is in
<clever>
emmanuelrosa: thats safe to ignore, its just a $NIX_PATH entry looking for anything you may have added with nix-channel
<clever>
bhipple[m]: that tends to be a result of copying files from an input, you just need to chmod -R +w $out
<clever>
nix wont garbage-collect the build until you delete the result link
<clever>
/root/.dot/zprezto/.zprezto/result is from `nixos-rebuild build` you simply forgot to delete result
<clever>
you may have simply ran a nix-build in that directory and forgotten to delete result
<clever>
if they are even using it
<clever>
ghc itself, or something using ghc?
<clever>
also, what does the result link point to?
<clever>
i dont know how your config has been setup, so it may be simpler to just wait for it to break
<clever>
or just delete the result symlink and wait till it breaks
<clever>
youll want to upgrade that to the new version from the current nixpkgs, and repair whatever config was refering to it
<clever>
and you never upgraded the config/root
<clever>
i'm guessing you rooted those GHC's, so they couldnt be garbage collected, because emacs needs a ghc to do things
<clever>
yeah
<clever>
try the --roots on a 2nd ghc
<clever>
this all seems pretty low, lets hunt down those 2 other GHC's and see what happens when they are gone
<clever>
magnetophon: how many things in `ls -l /nix/var/nix/gcroots/auto` ?
<clever>
one min
<clever>
ah
<clever>
magnetophon: when is the last time you ran a GC?
<clever>
how many system links exist in /nix/var/nix/profiles/ ?
<clever>
try a different copy of ghc
<clever>
that ghc is needed by the current nixos version, so you cant easily get rid of it
<clever>
that will tell you why it cant be GC'd
<clever>
magnetophon: run `nix-store --query --roots` on one of the larger packages your thinking of getting rid of
<clever>
rauno: the stateversion is based on the image nixops first booted the machine with, and in general, it should only be changed when reinstalling, enless your prepared to deal with the migrations
<clever>
and it only posts status when jobs finish
<clever>
check the logs on the hydra, journalctl -f -u hydra-queue-runner
<clever>
ryantrinkle: ah, i think it needs repo:status
2018-05-19
<clever>
ryantrinkle: as long as your user has push access, it can create status's on any rev
<clever>
ryantrinkle: i dont believe it needs any special perms
<clever>
johnw: all unfree stuff is blocked on hydra
<clever>
as long as the nixos components dont come from the a nixpkgs channel
<clever>
yeah, it only works on profiles it has write access to
<clever>
Rovanion: if ran as root, it can delete from every profile
<clever>
Rovanion: but, you also have 2 version inside 84-88, which is a different problem, `nix why-depends $(realpath /run/current-system) /nix/store//a7hvkr0waaw7b6rsp7iilkrk1kipzfrw-mono-4.0.4.1` and then again on the y1kv variant, and see what is to blame
<clever>
Rovanion: so you can `nix-env -p /nix/var/nix/profiles/system --delete-generations 82 83` to get rid of the 2nd one in the pastebin
<clever>
and the command tells you which generation needs each variant of mono
<clever>
thats where the nixos generations are stored
<clever>
Rovanion: thats what i thought, its your 3rd profile, `nix-env -p /nix/var/nix/profiles/system --list-generations`
<clever>
Rovanion: what does it output?
<clever>
Rovanion: run nix-store --query --roots on each version of mono
<clever>
it parses the blocks in that order, and stops at the first match
<clever>
ryantrinkle: hydra will then check the github url of the input named by input, and the rev from that build, and report the status there
<clever>
ryantrinkle: then you need a <githubstatus> block, jobs is a regex (with hidden anchors), that matches the job name from project:jobset:job
<clever>
ryantrinkle: first, you need a github_authorization block, that contains "owner = token <sha1>" pairs, using github personal access tokens, the token just needs push access to the repo
<clever>
there was a special thing to handle that side, but i havent looked at how the cross-compiler changes affect it
<clever>
mjacob: my only guess is that overlays may apply to the cross-compiled side, and not the inputs of the cross-compiler, whic happens to include the libc itself
<clever>
you have to close whatever program was using the file first
<clever>
i'm not sure if the nfs server allows deleting thost ghost files
<clever>
of*
<clever>
mjacob: none that i know it
<clever>
leading to directories that are empty yet not empty
<clever>
jack[m]: nfs doesnt fully support that, and will rename things to a specially hidden name to keep the file alive
<clever>
jack[m]: with most filesystems, you can delete a file that is still in-use, and it will magically garbage collect the file when its last handle it closed
<clever>
the gcc is linked against glibc, and uses that at runtime, but it also has the path of musl hard-coded into it, as the libc it uses in the generated binaries
<clever>
so its using the same musl and gcc that the cache has
<clever>
i didnt override musl
<clever>
so changing the musl makes it rebuild the gcc
<clever>
mjacob: i think the path to the libc is hard-coded into the gcc at build-time
<clever>
and in not even 60 seconds, it cross-compiled hello-world for 32bit arm, with musl
<clever>
mjacob: neat, there is even a muslpi target, which also has a compiler on the cache
<clever>
path is '/nix/store/3x7dwzq014bblazs7kq20p9hyzz0qh8g-hello-2.10.tar.gz'
<clever>
nixer: there is also nix-prefetch-url -A
<clever>
nixer: i dont think --check can rebuild that kind of thing, you generally need to either give each version a unique name, or corrupt the hash by just replacing a few chars with ffff to make it fail
<clever>
and cause problems
<clever>
then its a race condition, somebody could steal the file name
<clever>
but nix-build can overwrite symlinks
<clever>
eacameron: nix-build wont overwrite a file that already exists, and deleting it creates a race condition
<clever>
eacameron: id use withTempDirectory
<clever>
joepie91: and there is also yarn2nix
<clever>
nikivi: i can use a for loop in nixops to generate 10 machines, that each have 10 systemd services, and then just do `nixops deploy` and it spins up 100 instances of a program on AWS
<clever>
pxc: nix run just gives a shell suitable for using X and nothing more
<clever>
pxc: nix-shell gives you a shell with gcc that is suitable for building things, so it has to run setup hooks and download build-time deps
<clever>
eacameron: what i prefer doing is something like: nix-build '<nixpkgs>' -A git -o git ; export PATH=./git/bin:$PATH
<clever>
nikivi: nix-shell already downloaded the package and left it cached in /nix/store/
<clever>
eacameron: nix run nixpkgs.git
<clever>
eacameron: nix run is faster
<clever>
eacameron: yeah
<clever>
nikivi: correct
<clever>
eacameron: if a garbage collection happens in the middle of that script running, it might delete git on you
<clever>
eacameron: but also, nix wont know that your depending on git if you keep the path in a random var like that, so its best so use the result symlink nix-build makes
<clever>
nikivi: correct, and you use exit to exit, or eof
<clever>
nikivi: it added nodejs to $PATH and thats it
<clever>
nikivi: nix-env -iA nixpkgs.nodejs
<clever>
nikivi: yes, and node will be in $PATH in that shell
<clever>
eacameron: nix-build prints the path to stdout
<clever>
eacameron: why are you running which against it?
<clever>
nikivi: nix-shell -p nodejs
<clever>
always
<clever>
petersjt014[m]: if you specify a serverXml in your nixos config, it will use that string as the contents, if not, it uses the result of the sed call you linked
2018-05-17
<clever>
ryantm: so you can just jam in whatever you want to throw in there
<clever>
ryantm: nixos will eval that string when creating the final derivation that winds up at /run/current-system
<clever>
all nixos cares about is that import <nixos-config> (or $NIXOS_CONFIG if that exists) returns a function
<clever>
arianvp2: you could point that to a file that returns the nixos configuration function
<clever>
arianvp2: internally, nixos just imports <nixos-config> to find the config
<clever>
ryantm: potentially, a FS corruption issue could also just eat your entire drive :P
<clever>
boomshroom: probably, but i havent checked
<clever>
boomshroom: hydra detected that failure, and correctly refused to update nixos-unstable
<clever>
boomshroom: there was a bug in nixpkgs-unstable a year ago, that corrupted the grub config, removing your ability to reboot to an earlier version
<clever>
boomshroom: if you run nixos from nixpkgs-unstable, you risk bricking the machine
<clever>
so nixos-rebuild just fails, rather then reverting all changes
<clever>
that one will change the default search path of configuration.nix
<clever>
and its a one-time thing, because creating that file stops itself from running
<clever>
but thats only if the /root/.nix-channels file is somehow missing
<clever>
ryantm: if channels have never been configured before, and you open a shell as root, it sets up the "nixos" channel pointing to the system.nixos.defaultChannel