2018-06-08

<clever> did you change roots shell with configuration.nix?
<clever> normal shutdown -r or reboot?
<clever> did you properly un-mount everything when the install was done?
<clever> does that password contain any non-ascii characters?
<clever> mupf: did it ask for a password when it was done?
<clever> mupf: what command did you run to make the install?
<clever> mupf: how did you install nixos?
<clever> __monty__: check `top` to see whats using a lot of ram and see if you can free some up
<clever> __monty__: 32bit or 64bit cpu?
<clever> __monty__: how much is free in `free -g` right now?
<clever> __monty__: nix build slaves would still result in it trying to download ghc locally, then upload it to the slave
<clever> __monty__: your best option is to setup a swap file
<clever> __monty__: it still has to be restored into the store by nix, which is where the problem occurs
<clever> eeva: thats pretty recent, it should have the split-output improvements
<clever> eeva: thats not a git revision
<clever> eeva: which version of nixpkgs are you using?
<clever> eeva: are you able to build hakyll without pandoc?
<clever> eeva: you may need to also justStaticExecutables pandoc as well
<clever> eeva: do you know why you are refering to paths in pandoc?
<clever> eeva: site refers to a path within pandoc at runtime, and pandoc depends on ghc
<clever> eeva: can you also include the output of `nix why-depends /nix/store/yourthing /nix/store/6qd7z9w1hi1885almynw4088n8v0xii9-ghc-8.2.2`
<clever> and that new version checks the given set first, then falls back to pkgs
<clever> Myrl-saki: you run pkgs.newScope on a set, which will return a new variant of callPackage
<clever> nix-repl> myCallPackage ({ pythonPackages }: pythonPackages) {}
<clever> "foo"
<clever> nix-repl> myCallPackage = pkgs.newScope { pythonPackages = "foo"; }
<clever> Myrl-saki: you probably want newScope i think
<clever> Myrl-saki: if a contains a pythonPackages, it overwrites the entire pythonPackages
<clever> Myrl-saki: can you paste an example that you have tried?
<clever> eeva: are you able to pastebin the output of why-depends?
<clever> eeva: `nix why-depends /nix/store/yourthing /nix/store/ghc`
<clever> eeva: try nix why-depends
<clever> hodapp: boost166.override { enableStatic = true; }
<clever> hodapp: oh, one min
<clever> hodapp: an override of boost166 also effects boost
<clever> hodapp: it looks like it correctly cascades
<clever> "foo"
<clever> nix-repl> (import <nixpkgs> { overlays = [ (self: super: { boost166 = "foo"; }) ]; }).boost
<clever> mpickering: something will probably fail
<clever> so nearly all hydra config is in git and can be tracked and re-configured easily
<clever> samrose: each project has its own spec.json for declarative project definitions, which directs hydra to load the nearby default.nix to generate all jobsets
<clever> __monty__: the nix in nixpkgs needs to update, its a bit old
<clever> __monty__: which thing was it downloading when it failed?
<clever> Myrl-saki: ive seen some things doing pkgs.callPackage ({ stdenv, hello }: stdenv.mkDerivation { ... }) {}
<clever> samrose: i manage 3 hydra's and have helped others setup at least 2 more
<clever> samrose: pretty much
<clever> __monty__: probably
<clever> __monty__: the cabal file enables a ton of extensions globally, lol
<clever> it must have to do when what the file is doing
<clever> infinisil: oddly, bigger files compile faster
<clever> __monty__: ive found some files that take ghcid 30+ seconds to reload
<clever> i-am-the-slime: nix-build
<clever> i-am-the-slime: you can then just -A your package name with nix-build and it will build everything under nix
<clever> i-am-the-slime: if you run `stack2nix .` it will create a default.nix file that refers to every package defined in your stack.yaml
<clever> i-am-the-slime: try switching to stack2nix maybe?
<clever> __monty__: which ghc is it building?, i would expect it to be on the binary cache
<clever> i didnt know that
<clever> there is `let { ... }` and also `let foo = bar; in baz`
<clever> LnL: oh, i think we are confusing let's
<clever> LnL: oh, i think i see, `let foo = x; in bar` turns into `(rec { foo = x; body = bar; }).body`
<clever> LnL: oh wait, yeah, what you did is weird
<clever> LnL: no, the comments imply there is a special body attr in let blocks: https://github.com/NixOS/nix/blob/master/src/libexpr/parser.y#L387-L388
<clever> > let a = body; in a
<clever> let a = body; in a
<clever> let creates a recursive set
<clever> infinisil: look at lines 390 and 392!
<clever> let and rec are nearby
<clever> <foo> maps to (__find_file __nixPath "foo") when parsing
<clever> > (let a = b; in { inherit a; }).a
<clever> a is a thunk, that should fail when forced
<clever> > let a = b; in { inherit a; }
<clever> gchristensen: its probably a thunk that looks up a in the global vars, and will fail when forced, like you just did
<clever> > a
<clever> thats all rec does
<clever> > rec { a = 5; b = a; }
<clever> contrapumpkin: and then it cant refer to the default home nixos sets, so they began setting redundant home values on every user
<clever> contrapumpkin: ive also seen people use rec in nixos modules, and refer to users.users.foo.home
<clever> manveru: you could maybe set nixpkgs.system within the containers config

2018-06-07

<clever> and that config file directs them towards running the pulseaudio.package you configured, with the config you set
<clever> the pulseaudio client library that applications load, will check for a config file in /etc
<clever> gmarmstrong: hardware.pulseaudio.enable enables normal users to auto-start a local PA daemon
<clever> gmarmstrong: ive gotten it working without using a system-side PA
<clever> i'm in these groups and pulseaudio works just fine
<clever> uid=1000(clever) gid=100(users) groups=100(users),1(wheel),72(vboxusers),131(docker),500(wireshark)
<clever> the groups shouldnt matter
<clever> gmarmstrong: also check pavucontrol
<clever> yeah, that
<clever> manveru, gmarmstrong: did you change the pulseaudio package?
<clever> sorixelle: quote the path, you have configured it to import your entire music collection every time you nixos-rebuild
<clever> taohansen: if you use mkForce yes
<clever> nixops will then load and merge both
<clever> taohansen: create a second nix file, and add it to the first using requires = [ ./secondfile.nix ];

2018-06-06

<clever> that path is a hash of the URL
<clever> Lisanna: /var/root/.cache/nix/tarballs/0zs83a6jbq4ff7iaig1qblgh94v3wj8sdjrrwyv3wrdlviavxpm5.info will contain the last etag it saw
<clever> Lisanna: it claims the etag is a match to the previous value
<clever> shutting down on 200 HTTP response with expected ETag
<clever> i get output like this
<clever> finished download of 'https://d3g5gsiof5omrk.cloudfront.net/nixos/unstable/nixos-18.09pre140958.696c6bed4e8/nixexprs.tar.xz'; curl status = 0, HTTP status = 200, body = 11208088 bytes
<clever> Lisanna: what happens if you run it with -vvvv
<clever> Lisanna: check the most recently modified file in ~/.cache/nix/tarballs/
<clever> Lisanna: and is it different after you modify the file?
<clever> Lisanna: ah, i would expect that to change and correctly be unique
<clever> Lisanna: how is it hashing it and including it in the config?
<clever> Lisanna: how did you generate it?
<clever> gchristensen: nginx has nicer nixos config flags
<clever> Lisanna: its just a string
<clever> Lisanna: if you can make it unique each time, sure
<clever> Lisanna: that is likely also causing issues
<clever> Lisanna: is last-modified there?
<clever> Lisanna: check the `curl -i` output for differences
<clever> in my case, justdoit has to have the drive path (sda vs nvme0n1) configured in at compile-time
<clever> gchristensen: you could also probably use my simple-test.nix to emulate nvme and/or uefi in qemu for local testing
<clever> gchristensen: yeah, that looks like a more flexible justdoit
<clever> gchristensen: the only real difference would be the filesystem it uses i guess, my script uses zfs
<clever> the expect script appears to only test things, after it has been installed
<clever> gchristensen: if you can forcibly boot a packet.net server with a given kernel+initrd, then you can ssh into that, run justdoit, and have total control over the partition tables nixos is installed with
<clever> gchristensen: that also seems like a fun place to throw justdoit at
<clever> gchristensen: nice
<clever> samueldr: lol
<clever> gchristensen: i have 5 different configurations i need to simulate, and all of them are just a matter of running justdoit in a console, waiting for it to install nixos, rebooting, and then confirming it boots
<clever> gchristensen: i could probably use that to improve my justdoit tests
<clever> gchristensen: :O
<clever> Lisanna: check the source in the serverfault i linked
<clever> then nix-channel would only re-download when you re-copy the file (even if it hasnt changed)
<clever> Lisanna: and ensure the timestamp of the copy is the time when it was copied
<clever> Lisanna: configure nginx to serve it from some mutable directory, and setup a script to copy it there on startup/update
<clever> Lisanna: next option would be to not put the nixexprs.tar.gz into the store
<clever> Lisanna: if the etag is missing, then it will redownload it every time
<clever> Lisanna: you can also just set etag off;
<clever> gg nginx
<clever> because nix is nuking all timestamps, your etag is based purely on size
<clever> and the 9818 is the size in hex (38936 bytes)
<clever> the 1 is the last-mod timestamp (the nix store is to blame)
<clever> Lisanna: bingo
<clever> checking...
<clever> oh wait, thats a %x
<clever> what is the current value of the etag?
<clever> Lisanna: i think its based on the last-modified timestamp and something else
<clever> Lisanna: what about the output of `stat /nix/store/zqy5ymsxy5vwjj8s9f1697xf017wwqvg-nixexprs.tar.xz`
<clever> yep
<clever> __monty__: or add a dedicated user for the build slave and set that user back to bash
<clever> __monty__: zsh may behave differently, add echo's to any file zsh may source on startup
<clever> Lisanna: can you pastebin the whole nginx.conf file, from `ps aux | grep nginx`
<clever> Lisanna: as long as the etag is the same, nix will refuse to download the file again
<clever> Lisanna: then your nginx is not configured properly
<clever> dang
<clever> __monty__: i think you can also source /etc/bashrc from ~/.bashrc to get the same effect
<clever> __monty__: probably nix-daemon.sh
<clever> Lisanna: and does the etag change when you modify the file?
<clever> Lisanna: if you `curl -i` the file before and after the change, what http headers does it return each time?
<clever> __monty__: you can confirm its working by running `ssh user@mac nix-store --version`
<clever> __monty__: just make sure that ~/.bashrc sources the profile.d/nix.sh file nix installed
<clever> __monty__: yep
<clever> blame apple
<clever> apple also sets $HOME wrong when you sudo, so `sudo nix-channel --update` does not update roots channels
<clever> use `sudo -i` to get a proper root shell
<clever> bash expands that to the non-root directory, before running sudo
<clever> /home/clever/.cache
<clever> [clever@amd-nixos:~]$ sudo echo ~/.cache
<clever> using `sudo rm -rf ~/.cache/` ?
<clever> Lisanna: did you purge roots ~/.cache or your own?
<clever> Lisanna: what user did you run nix-channel as?
<clever> it also stores the timestamp of when it last checked in that dir
<clever> samueldr: nix stores the etag in ~/.cache/nix/tarballs, and will abort if it hasnt changed
<clever> Lisanna: if you blow away that tarballs dir, it has to recheck
<clever> Lisanna: and it uses the ~/.cache/nix/tarballs dir to manage the caching
<clever> Lisanna: according to the source, nix-channel always sets the ttl to 0
<clever> Path Downloader::downloadCached(ref<Store> store, const string & url_, bool unpack, string name, const Hash & expectedHash, string * effectiveUrl, int ttl)
<clever> auto filename = dl->downloadCached(store, url, false, "", Hash(), &effectiveUrl, 0);
<clever> hodapp: did you try adding pkgconfig to the nativeBuildInputs?
<clever> dima1: nixpkgs.overlays
<clever> depends on what exactly is failing
<clever> angerman: you may need to manually add "${openssl.out}/lib" to PATH because windows is dumb
<clever> angerman: generally, you just add openssl to the buildInputs, and nix uses the right one for you, but sometimes you need to add both to the buildInputs
<clever> angerman: those are the same nix expression, its just split outputs

2018-06-05

<clever> Aleksejs: run file on the ELF binary
<clever> you have to hash every file it read during the eval
<clever> the problem with just hashing the deployment file, is imports and readfile
<clever> it works purely on the sqlite state file
<clever> ldlework: there is `nixops info --no-eval` that can mostly deal with it, and also prevent any destructive operations
<clever> ldlework: thats what happens when you have 80+ machines in the deployment file
<clever> ldlework: i have also seen deployments where info takes 40gig of ram and takes 5 minutes
<clever> ldlework: running `nixops info` can be a potentially destructive operaiton if the `--arg` flags are using relative paths
<clever> Orbstheorem: realpath /nix/store/...-user-environment/bin/powertop
<clever> Orbstheorem: yeah
<clever> Orbstheorem: nix-store -q --referrers
<clever> Orbstheorem: you want the things refering to it
<clever> PolarIntersect: your welco,e
<clever> Orbstheorem: that is part of nixos, what derivation was refering to system-path?
<clever> Orbstheorem: so it will contain a mix of many nixpkgs revisions
<clever> Orbstheorem: that is a nix-env profile, not a nixos one
<clever> Orbstheorem: paste the full storepath for a given derivation
<clever> Orbstheorem: nixos derivations are special, the name of the derivation includes the git rev of the nixpkgs
<clever> Orbstheorem: not easily, you need at least the path to the nixpkgs that was used to build it
<clever> PolarIntersect: even with -la ?
<clever> PolarIntersect: and the default buildPhase already runs make, you dont need to do that
<clever> PolarIntersect: what does `ls -lh /nix/store/cgzkz8gdlx46wcvvn7n09h455wmhh97s-monokrome` show?
<clever> PolarIntersect: can you gist the whole output of nix-build?
<clever> yeah, it will use the directory the nix file is located in
<clever> PolarIntersect: thats normal
<clever> Orbstheorem: there is also nix-diff
<clever> Orbstheorem: i mostly just check the git logs, once i know the revisions of things
<clever> yeah, give it some time
<clever> then use `with import <unstable> {};`
<clever> try this: `sudo nix-channel --add https://nixos.org/channels/nixos-unstable unstable` and `sudo nix-channel --update`
<clever> 18.03 is the newest stable channel
<clever> 3: headers got properly moved into godot
<clever> 2: godot + godot_headers
<clever> 1: godot without headers
<clever> there are 3 different states that godot appears to have been in
<clever> its possible that the 18.03 channel is also too old
<clever> and nix will just build it for you
<clever> and if you set the src on your derivation properly, you can also just `nix-build` your default.nix file
<clever> ls -l result/
<clever> nix-build '<nixpkgs>' -A godot
<clever> so you can fix that later
<clever> you also dont need to nixos-rebuild to make this change apply in your nix-shell
<clever> yep
<clever> !tofu
<clever> use --show-trace to see where it is
<clever> that has been fixed in 18.03
<clever> one of your derivations was abusing a bug in nix1
<clever> what error does it give now?
<clever> nixos always uses the channel named nixos
<clever> if you want to upgrade to 18.03, also do `sudo nix-channel --add https://nixos.org/channels/nixos-18.03 nixos`
<clever> also, yes, `sudo nix-channel --remove nixpkgs ; sudo nix-channel --update`
<clever> you dont need it
<clever> on may 2nd, godot_headers was deleted from nixpkgs
<clever> yep
<clever> i'm checking the git logs now, something strange is happening
<clever> you added 18.03 under the name nixpkgs
<clever> what does `sudo nix-channel --list` report?
<clever> but, the channel your on may never get it
<clever> the --upgrade will automatically do a `nix-channel --update` for you
<clever> nix-channel --update
<clever> probably
<clever> yes
<clever> your derivation still lacks a name = "something";
<clever> what does this return?: nix-instantiate --eval '<nixpkgs>' -A lib.nixpkgsVersion
<clever> it finds godot_headers when i run it
<clever> [clever@amd-nixos:~/c9efc13830017160eda123e122d4514a]$ nix-shell -A yourthing
<clever> nix-instantiate --find-file nixpkgs
<clever> yeah
<clever> think of it like #include <math.h>
<clever> <nixpkgs> will search $NIX_PATH
<clever> and `with import <nixpkgs> {};` puts everything in its return value into scope
<clever> `import <nixpkgs> {}` then calls that function with an empty set
<clever> `import <nixpkgs>` returns the function at its top-level
<clever> <nixpkgs> returns the path to nixpkgs
<clever> no
<clever> line 1
<clever> then you can run nix-shell -A yourthing
<clever> you must load it with pkgs.callPackage
<clever> that derivation lacks a name
<clever> PolarIntersect: the attribute is not called nixpkgs
<clever> so nixops can break when inside a nix-shell that includes other python deps
<clever> robstr: when you add python packages to the buildInputs, it mutates the default PYTHONPATH, and nixops obeys that
<clever> PolarIntersect: can you pastebin your current .nix file with the latest errors?
<clever> robstr: try running nix-shell without shoving it into the buildInputs of something relatively unrelated
<clever> PolarIntersect: what nix-shell args are you using?
<clever> !library
<clever> PolarIntersect: libraries must never be installed
<clever> robstr: and does the default.nix it imports on line 12 do anything with python?
<clever> robstr: how did you pin it?
<clever> robstr: id say that python library is broken then
<clever> robstr: does the one its looking for exist?
<clever> robstr: what .so files exist?
<clever> oops, add an ls -l at the start
<clever> robstr: what does this report: `/nix/store/3g1si0y1d15dmsakgl1fnxzy8s8n97h0-python3.6-pycryptodome-3.5.1/lib/python3.6/site-packages/Crypto/Util/../Hash/`
<clever> robstr: it will automatically pass you the value of pkgs.pkgs

2018-06-04

<clever> dash: there is also yarn2nix
<clever> robstr: yeah, that looks like it
<clever> jophish: the initrd is generated with a /init symlink pointing to stage1
<clever> yeah, that is stage 2
<clever> jophish: the kernel
<clever> and then require everybody to nix-shell first
<clever> you could also use a shell.nix file that sets NIX_PATH=nixpkgs=https://github.com/nixos/nixpkgs/archive/GITREV.tar.gz
<clever> i think there is a PR on nixops about improving it
<clever> robstr: i keep a command like the above as a comment in my deployment file, so others know what it should be on
<clever> robstr: nixops modify -d name deployment.nix -I nixpkgs=https://github.com/nixos/nixpkgs/archive/GITREV.tar.gz
<clever> robstr: it only effects nix-shell and nix-build
<clever> robstr: that doesnt work when doing things with nixos or nixops
<clever> robstr: nixops modify -d name deployment.nix -I nixpkgs=https://github.com/nixos/nixpkgs/archive/GITREV.tar.gz
<clever> i do pure ZFS on all of my installs
<clever> sorixelle: run `pwd` and `ls -ltrh` inside the installPhase, you should already be cd'd into the sourceRoot
<clever> you can just set installPhase to a bash script, directly quoted in the nix file
<clever> sorixelle: you rarely need to set builder directly, that tends to over-complicate things
<clever> sorixelle: can you gist your current nix file?
<clever> so you may be able to just `sed -i foo.txt`
<clever> sorixelle: also note, that the unpackPhase has already copied $src to . for you