2018-05-20

<clever> phry: that is the right track
<clever> leotaku: that error doesnt have anything to do with the hash being right or wrong
<clever> and any use of recursiveUpdate wont obey the nixos options merge rules
<clever> any use of // will overwrite things at the wrong layer
<clever> Myrl-saki: just use imports
<clever> leotaku: can you pastebin the entire output when the hash is wrong?
<clever> phry: look at the BootOrder field to see what is enabled
<clever> phry: but you can also use efiboormgr to view the config, to see if its set right
<clever> phry: yeah
<clever> phry: the uuid of the FS and the path to the .efi has to be configured in the bios, using tools like efibootmgr
<clever> Boot0003* UEFI OS HD(1,GPT,27c99b08-455d-4dfe-a44f-6150cbc09ef8,0x800,0x100000)/File(\EFI\BOOT\BOOTX64.EFI)..BO
<clever> BootCurrent: 0003
<clever> [root@system76:~]# efibootmgr -v
<clever> phry: what does efibootmgr say?
<clever> probably
<clever> thats fine for development, since its only in the node_modules dir
<clever> and buildGoPackage
<clever> there is already buildRustCrate and cargo2nix
<clever> yeah
<clever> in generall, you should only install things with nix, and not use any other package managaers
<clever> package them properly with nix
<clever> nikivi: it tries to install into the nix store, which is immutable
<clever> and -i -g wont ever work in nix
<clever> i'm not sure why the alias hasnt been updated
<clever> nikivi: its an alias to version 6 in all-packages.nix
<clever> /home/clever/apps/nixpkgs/pkgs/top-level/all-packages.nix: nodejs = hiPrio nodejs-6_x;
<clever> then its available in the binary cache, and people can easily choose to use it
<clever> but having a static output on the derivation in nixpkgs would help
<clever> manveru: or just apply the same override your modified makeStaticLibraries was doing
<clever> makefu: have you tried yarn2nix?
<clever> manveru: id just make a normal override on openssl, to do that
<clever> ah, i can see how that would happen
<clever> Dezgeg: i also suspect the state and log dir have to be set correctly
<clever> try `NIX_STATE_DIR=/home/user/nix/var/nix nix help`
<clever> what ./configure options did you use?
<clever> 42 , nixDaemonSocketFile(canonPath(nixStateDir + DEFAULT_SOCKET_PATH))
<clever> what does gdb say the backtrace is?
<clever> a stack-trace would also help
<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: nix-collect-garbage --delete-older-than 30d
<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> yeah
<clever> yeah
<clever> infinisil: odd, on master it does exist, something must have been changed
<clever> infinisil: i dont see a nixos in the attrpath for stateVersion
<clever> saeedgnu: if you set nativeBuildInputs = [ qmake ]; then it will automatically run the project.pro file i believe
<clever> yeah
<clever> nschoe: yeah
<clever> -I/home/nschoe/nixpkgs doesnt tell it to load nixpkgs, that tells it that it can search in that dir when you do things like <foo>
<clever> nschoe: then you want -A libwsclient
<clever> nix-build cant run it directly
<clever> that default.nix can only be loaded with callPackage
<clever> nschoe: you want nix-build /home/nschoe/nixpkgs -A libwsclient-d416f
<clever> nschoe: you didnt tell it which file to load, so it opened default.nix in the current dir
<clever> if its working, it will show you your own github username
<clever> nikivi: you can also test your github setup with just `ssh git@github.com`
<clever> nikivi: your public key hasnt been added to your github account
<clever> nikivi: its possible that the ssh in nixpkgs has those features disabled, or somethign else you did performed automated changes to ssh_config
<clever> too many n names talking at once, lol
<clever> nschoe: your ssh_config file contains config that ssh doesnt understand, you may want to comment those lines out
<clever> nschoe: nix-build -E 'with import <nixpkgs> {}; callPackage ./. {}' is a quick way to test it
<clever> that will use ssh instead of https
<clever> nikivi: try cloning git@github.com:felixangell/mac then
<clever> nikivi: do you happen to have an ssh key setup with github for pushing?
<clever> nikivi: try `export SSL_CERT_FILE=/nix/var/nix/profiles/default/etc/ssl/certs/ca-bundle.crt` and then clone again
<clever> nikivi: env | grep ssl, what does this find?
<clever> nikivi: are you in a nix-shell?
<clever> nikivi: nix-env -iA nixpkgs.gitAndTools.gitFull gives you the full git and everything
<clever> nschoe: the default git lacks gui and some other things
<clever> the runtime deps are a strict subset of the build-time ones
<clever> yeah
<clever> but if you dont refer to them in the output, then they wont be runtime deps
<clever> nschoe: if your naughty and refer to the native build inputs in $out, yes
<clever> and it has to download those before it can download the thing that depends on them
<clever> nschoe: any path you refer to becomes a runtime dep
<clever> nschoe: after the build is done, nix will basically grep the output for the paths of every single input
<clever> nschoe: thats entirely seperate
<clever> alexteves: nix will run that script to build the thing you wanted to build
<clever> alexteves: runCommand "name" { buildInputs = []; } "script"
<clever> roconnor: if your already on 18.03, nothing
<clever> [root@amd-nixos:~]# nixos-option system.stateVersion
<clever> ah, the option is system.stateVersion, not nixos.stateVersion
<clever> roconnor: did you run it on an option name?
<clever> roconnor: nixos-option
<clever> roconnor: if everything is currently working, set it to the default value from `nixos-option nixos.stateVersion`
<clever> and only if that service is enabled
<clever> disasm: most of the time, the user is defined once in the service that uses it
<clever> disasm: what if you make a module that defines the user once, and has an enable option?
<clever> alexteves: have you tried runCommand?
<clever> not sure though
<clever> jD91mZM2: i think it only evals when your using cross-compiling
<clever> jD91mZM2: yeah
<clever> jD91mZM2: i think you want windows.pthreads
<clever> while import <nixpkgs/lib> is just the lib and nothing else, no support for overrides, overlays, cross-compiling, and 20,000 packages
<clever> (import <nixpkgs> {}).lib imports the top-level of nixpkgs, which is a much more complex expression, and potentially slower
<clever> think of it like #include <foo/bar.h> in c/c++
<clever> jD91mZM2: it refers to the lib directory in nixpkgs, not the lib attribute
<clever> (import <nixpkgs> { crossSystem = (import <nixpkgs/lib>).systems.examples.raspberryPi; }).hello would be a 32bit arm binary with normal glibc
<clever> and this produces an rpi kernel
<clever> (import <nixpkgs> { crossSystem = (import <nixpkgs/lib>).systems.examples.raspberryPi; }).linuxPackages_rpi.kernel
<clever> this would produce a 32bit arm binary targeting musl
<clever> (import <nixpkgs> { crossSystem = (import <nixpkgs/lib>).systems.examples.muslpi; }).hello
<clever> jD91mZM2: yep
<clever> alexteves: there is also runCommand
<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> nixosnewbie: here is an example of an overlay i recently did: https://github.com/cleverca22/nixos-configs/blob/master/qemu.nix#L35-L37
<clever> the nixpkgs manual doesnt explain how the nixos side of things work
<clever> you may want to check the nixos manual
<clever> and that file will look like this, self: super: { ... }
<clever> nixosnewbie: you put a relative (or absolute) path into configuration.nix like this
<clever> nixosnewbie: nixpkgs.overlays = [ (import ./overlayfile.nix) ];
<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> nix-repl> :b (import <nixpkgs> { crossSystem = (import <nixpkgs/lib>).systems.examples.muslpi; }).hello

2018-05-18

<clever> and the resulting hello is musl, looks like it ticks all the boxes
<clever> and the gcc its using is linked against glibc
<clever> and it claims to only be building one thing, hello-2.10-x86_64-unknown-linux-musl
<clever> mjacob: this evaluates...
<clever> nix-repl> (import <nixpkgs> { crossSystem = (import <nixpkgs/lib>).systems.examples.musl64; }).hello
<clever> and it could take advantage of other cross-compile things, and use a glibc cmake, rather then a musl cmake
<clever> mjacob: that sort of sounds like a cross-compile setup, where gcc uses glibc, but targets musl
<clever> arianvp2: yeah
<clever> about all i can think of is a record of when you installed nix and how you may have updated
<clever> arianvp2: not sure how it broke then
<clever> arianvp2: how did you install nix?
<clever> yeah
<clever> or your manual install missed a step
<clever> arianvp2: you forgot to source nix.sh, which sets that up during the first run
<clever> arianvp2: fix .nix-profile to point to a path like what mine does, then manually run nix-env and nix-env -i its own path
<clever> arianvp2: also, your nix likely didnt delete itself, just the profile, try ls -l /nix/store/*/bin/nix-env
<clever> arianvp2: if it doesnt, nix wont know its in-use
<clever> arianvp2: profile-1-link must exist in /nix/var/nix/profiles
<clever> lrwxrwxrwx 1 clever users 45 Oct 11 2015 .nix-profile -> /nix/var/nix/profiles/per-user/clever/profile
<clever> arianvp2: that was supposed to point into a profile dir that is a gc root
<clever> arianvp2: theres your problem
<clever> arianvp2: what does ~/.nix-profile point to?
<clever> you probably want a function
<clever> and the space breaks it
<clever> nikivi: i'm pretty sure that will run `nix-env -iA nixpkgs. rustc`
<clever> the input can also be another derivation
<clever> though it needs the 1st example to actually find the file
<clever> > runCommand "name" { buildInputs = [ graphviz ]; } "graphviz input-file.txt -o $out"
<clever> > runCommand "name" { buildInputs = [ graphviz ]; } "graphviz ${./input} -o $out"
<clever> eacameron: yeah
<clever> $ nix-prefetch-url '<nixpkgs>' -A hello.src
<clever> 0ssi1wpaf7plaswqqjwigppsg5fyh99vdlb9kzl7c9lng89ndq1i
<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> nikivi: nox, nix search, nix-repl, https://nixos.org/nixos/packages.html
<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> ryantm: thats in the examples i linked
<clever> infinisil: with older nix, there was a bug that allowed a non-fixed fixed-output derivation
<clever> infinisil: if the params are not valid, nix 2 will just dis-allow network
<clever> arianvp2: everything in _module.args is available to all modules
<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> ryantm: and for nixops, this one is also handy: https://github.com/cleverca22/nixos-configs/blob/master/nixops-managed.nix
<clever> ryantm: that forces it to use the nixpkgs embeded into the nixos, by line 72, which refers to the pinned nixpkgs expression
<clever> yeah
<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
<clever> ryantm: checking...
<clever> arianvp2: and nixos is a directory inside there
<clever> arianvp2: /nix/var/nix/profiles/per-user/root/channels is in NIX_PATH
<clever> samueldr: yeah
<clever> elvishjerricco: -small only runs tests, normal waits for every single package to try to build
<clever> and it will obey some defaults
<clever> which runs make, optionally with -j
<clever> it will default to the buildPhase function in setup.sh
<clever> and it may not even exist if its using the default
<clever> yeah
<clever> RyanGlScott: { buildPhase = otherdrv.buildPhase; }
<clever> lol
<clever> jack[m]: its likely going to be a lot easyer to fix it then rewrite it from scratch
<clever> jack[m]: are you modifying the existing ghc bootstrap expression?