2018-06-08
17:33
<
clever >
did you change roots shell with configuration.nix?
17:33
<
clever >
normal shutdown -r or reboot?
17:32
<
clever >
did you properly un-mount everything when the install was done?
17:31
<
clever >
does that password contain any non-ascii characters?
17:31
<
clever >
mupf: did it ask for a password when it was done?
17:31
<
clever >
mupf: what command did you run to make the install?
17:30
<
clever >
mupf: how did you install nixos?
16:43
<
clever >
__monty__: check `top` to see whats using a lot of ram and see if you can free some up
16:42
<
clever >
__monty__: 32bit or 64bit cpu?
16:42
<
clever >
__monty__: how much is free in `free -g` right now?
16:40
<
clever >
__monty__: nix build slaves would still result in it trying to download ghc locally, then upload it to the slave
16:35
<
clever >
__monty__: your best option is to setup a swap file
16:35
<
clever >
__monty__: it still has to be restored into the store by nix, which is where the problem occurs
16:02
<
clever >
eeva: thats pretty recent, it should have the split-output improvements
16:01
<
clever >
eeva: thats not a git revision
16:00
<
clever >
eeva: which version of nixpkgs are you using?
15:57
<
clever >
eeva: are you able to build hakyll without pandoc?
15:55
<
clever >
eeva: you may need to also justStaticExecutables pandoc as well
15:55
<
clever >
eeva: do you know why you are refering to paths in pandoc?
15:54
<
clever >
eeva: site refers to a path within pandoc at runtime, and pandoc depends on ghc
15:51
<
clever >
eeva: can you also include the output of `nix why-depends /nix/store/yourthing /nix/store/6qd7z9w1hi1885almynw4088n8v0xii9-ghc-8.2.2`
15:50
<
clever >
and that new version checks the given set first, then falls back to pkgs
15:50
<
clever >
Myrl-saki: you run pkgs.newScope on a set, which will return a new variant of callPackage
15:49
<
clever >
nix-repl> myCallPackage ({ pythonPackages }: pythonPackages) {}
15:49
<
clever >
nix-repl> myCallPackage = pkgs.newScope { pythonPackages = "foo"; }
15:48
<
clever >
Myrl-saki: you probably want newScope i think
15:48
<
clever >
Myrl-saki: if a contains a pythonPackages, it overwrites the entire pythonPackages
15:46
<
clever >
Myrl-saki: can you paste an example that you have tried?
15:45
<
clever >
eeva: are you able to pastebin the output of why-depends?
15:41
<
clever >
eeva: `nix why-depends /nix/store/yourthing /nix/store/ghc`
15:36
<
clever >
eeva: try nix why-depends
15:35
<
clever >
hodapp: boost166.override { enableStatic = true; }
15:35
<
clever >
hodapp: oh, one min
15:34
<
clever >
hodapp: an override of boost166 also effects boost
15:34
<
clever >
hodapp: it looks like it correctly cascades
15:34
<
clever >
nix-repl> (import <nixpkgs> { overlays = [ (self: super: { boost166 = "foo"; }) ]; }).boost
15:11
<
clever >
mpickering: something will probably fail
15:03
<
clever >
so nearly all hydra config is in git and can be tracked and re-configured easily
15:03
<
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
15:02
<
clever >
__monty__: the nix in nixpkgs needs to update, its a bit old
14:52
<
clever >
__monty__: which thing was it downloading when it failed?
14:44
<
clever >
Myrl-saki: ive seen some things doing pkgs.callPackage ({ stdenv, hello }: stdenv.mkDerivation { ... }) {}
14:12
<
clever >
samrose: i manage 3 hydra's and have helped others setup at least 2 more
14:12
<
clever >
samrose: pretty much
13:37
<
clever >
__monty__: probably
13:35
<
clever >
__monty__: the cabal file enables a ton of extensions globally, lol
13:34
<
clever >
it must have to do when what the file is doing
13:34
<
clever >
infinisil: oddly, bigger files compile faster
13:33
<
clever >
__monty__: ive found some files that take ghcid 30+ seconds to reload
13:23
<
clever >
i-am-the-slime: nix-build
13:23
<
clever >
i-am-the-slime: you can then just -A your package name with nix-build and it will build everything under nix
13:22
<
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
13:21
<
clever >
i-am-the-slime: try switching to stack2nix maybe?
13:20
<
clever >
__monty__: which ghc is it building?, i would expect it to be on the binary cache
12:57
<
clever >
i didnt know that
12:56
<
clever >
there is `let { ... }` and also `let foo = bar; in baz`
12:56
<
clever >
LnL: oh, i think we are confusing let's
12:55
<
clever >
LnL: oh, i think i see, `let foo = x; in bar` turns into `(rec { foo = x; body = bar; }).body`
12:54
<
clever >
LnL: oh wait, yeah, what you did is weird
12:53
<
clever >
> let a = body; in a
12:53
<
clever >
let a = body; in a
12:51
<
clever >
let creates a recursive set
12:51
<
clever >
infinisil: look at lines 390 and 392!
12:51
<
clever >
let and rec are nearby
12:51
<
clever >
<foo> maps to (__find_file __nixPath "foo") when parsing
12:48
<
clever >
> (let a = b; in { inherit a; }).a
12:48
<
clever >
a is a thunk, that should fail when forced
12:47
<
clever >
> let a = b; in { inherit a; }
12:46
<
clever >
gchristensen: its probably a thunk that looks up a in the global vars, and will fail when forced, like you just did
12:46
<
clever >
thats all rec does
12:46
<
clever >
> rec { a = 5; b = a; }
12:43
<
clever >
contrapumpkin: and then it cant refer to the default home nixos sets, so they began setting redundant home values on every user
12:43
<
clever >
contrapumpkin: ive also seen people use rec in nixos modules, and refer to users.users.foo.home
09:50
<
clever >
manveru: you could maybe set nixpkgs.system within the containers config
2018-06-07
13:28
<
clever >
and that config file directs them towards running the pulseaudio.package you configured, with the config you set
13:27
<
clever >
the pulseaudio client library that applications load, will check for a config file in /etc
13:27
<
clever >
gmarmstrong: hardware.pulseaudio.enable enables normal users to auto-start a local PA daemon
13:25
<
clever >
gmarmstrong: ive gotten it working without using a system-side PA
13:19
<
clever >
i'm in these groups and pulseaudio works just fine
13:19
<
clever >
uid=1000(clever) gid=100(users) groups=100(users),1(wheel),72(vboxusers),131(docker),500(wireshark)
13:19
<
clever >
the groups shouldnt matter
13:19
<
clever >
gmarmstrong: also check pavucontrol
13:19
<
clever >
yeah, that
13:18
<
clever >
manveru, gmarmstrong: did you change the pulseaudio package?
02:28
<
clever >
sorixelle: quote the path, you have configured it to import your entire music collection every time you nixos-rebuild
01:43
<
clever >
taohansen: if you use mkForce yes
01:40
<
clever >
nixops will then load and merge both
01:40
<
clever >
taohansen: create a second nix file, and add it to the first using requires = [ ./secondfile.nix ];
2018-06-06
22:38
<
clever >
that path is a hash of the URL
22:38
<
clever >
Lisanna: /var/root/.cache/nix/tarballs/0zs83a6jbq4ff7iaig1qblgh94v3wj8sdjrrwyv3wrdlviavxpm5.info will contain the last etag it saw
22:37
<
clever >
Lisanna: it claims the etag is a match to the previous value
22:37
<
clever >
shutting down on 200 HTTP response with expected ETag
22:31
<
clever >
i get output like this
22:30
<
clever >
Lisanna: what happens if you run it with -vvvv
22:30
<
clever >
Lisanna: check the most recently modified file in ~/.cache/nix/tarballs/
22:30
<
clever >
Lisanna: and is it different after you modify the file?
22:29
<
clever >
Lisanna: ah, i would expect that to change and correctly be unique
22:29
<
clever >
Lisanna: how is it hashing it and including it in the config?
22:28
<
clever >
Lisanna: how did you generate it?
22:18
<
clever >
gchristensen: nginx has nicer nixos config flags
22:17
<
clever >
Lisanna: its just a string
22:17
<
clever >
Lisanna: if you can make it unique each time, sure
22:13
<
clever >
Lisanna: that is likely also causing issues
22:12
<
clever >
Lisanna: is last-modified there?
22:12
<
clever >
Lisanna: check the `curl -i` output for differences
22:05
<
clever >
in my case, justdoit has to have the drive path (sda vs nvme0n1) configured in at compile-time
22:04
<
clever >
gchristensen: you could also probably use my simple-test.nix to emulate nvme and/or uefi in qemu for local testing
22:04
<
clever >
gchristensen: yeah, that looks like a more flexible justdoit
22:03
<
clever >
gchristensen: the only real difference would be the filesystem it uses i guess, my script uses zfs
22:02
<
clever >
the expect script appears to only test things, after it has been installed
22:02
<
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
22:01
<
clever >
gchristensen: that also seems like a fun place to throw justdoit at
22:01
<
clever >
gchristensen: nice
22:00
<
clever >
samueldr: lol
22:00
<
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
21:59
<
clever >
gchristensen: i could probably use that to improve my justdoit tests
21:58
<
clever >
gchristensen: :O
21:58
<
clever >
Lisanna: check the source in the serverfault i linked
21:58
<
clever >
then nix-channel would only re-download when you re-copy the file (even if it hasnt changed)
21:57
<
clever >
Lisanna: and ensure the timestamp of the copy is the time when it was copied
21:57
<
clever >
Lisanna: configure nginx to serve it from some mutable directory, and setup a script to copy it there on startup/update
21:57
<
clever >
Lisanna: next option would be to not put the nixexprs.tar.gz into the store
21:55
<
clever >
Lisanna: if the etag is missing, then it will redownload it every time
21:55
<
clever >
Lisanna: you can also just set etag off;
21:54
<
clever >
because nix is nuking all timestamps, your etag is based purely on size
21:54
<
clever >
and the 9818 is the size in hex (38936 bytes)
21:54
<
clever >
the 1 is the last-mod timestamp (the nix store is to blame)
21:54
<
clever >
Lisanna: bingo
21:53
<
clever >
checking...
21:53
<
clever >
oh wait, thats a %x
21:53
<
clever >
what is the current value of the etag?
21:52
<
clever >
Lisanna: i think its based on the last-modified timestamp and something else
21:51
<
clever >
Lisanna: what about the output of `stat /nix/store/zqy5ymsxy5vwjj8s9f1697xf017wwqvg-nixexprs.tar.xz`
21:47
<
clever >
__monty__: or add a dedicated user for the build slave and set that user back to bash
21:47
<
clever >
__monty__: zsh may behave differently, add echo's to any file zsh may source on startup
21:45
<
clever >
Lisanna: can you pastebin the whole nginx.conf file, from `ps aux | grep nginx`
21:45
<
clever >
Lisanna: as long as the etag is the same, nix will refuse to download the file again
21:44
<
clever >
Lisanna: then your nginx is not configured properly
21:44
<
clever >
__monty__: i think you can also source /etc/bashrc from ~/.bashrc to get the same effect
21:43
<
clever >
__monty__: probably nix-daemon.sh
21:42
<
clever >
Lisanna: and does the etag change when you modify the file?
21:40
<
clever >
Lisanna: if you `curl -i` the file before and after the change, what http headers does it return each time?
21:39
<
clever >
__monty__: you can confirm its working by running `ssh user@mac nix-store --version`
21:39
<
clever >
__monty__: just make sure that ~/.bashrc sources the profile.d/nix.sh file nix installed
21:38
<
clever >
__monty__: yep
21:38
<
clever >
blame apple
21:38
<
clever >
apple also sets $HOME wrong when you sudo, so `sudo nix-channel --update` does not update roots channels
21:37
<
clever >
use `sudo -i` to get a proper root shell
21:37
<
clever >
bash expands that to the non-root directory, before running sudo
21:37
<
clever >
/home/clever/.cache
21:37
<
clever >
[clever@amd-nixos:~]$ sudo echo ~/.cache
21:37
<
clever >
using `sudo rm -rf ~/.cache/` ?
21:36
<
clever >
Lisanna: did you purge roots ~/.cache or your own?
21:36
<
clever >
Lisanna: what user did you run nix-channel as?
21:35
<
clever >
it also stores the timestamp of when it last checked in that dir
21:35
<
clever >
samueldr: nix stores the etag in ~/.cache/nix/tarballs, and will abort if it hasnt changed
21:34
<
clever >
Lisanna: if you blow away that tarballs dir, it has to recheck
21:33
<
clever >
Lisanna: and it uses the ~/.cache/nix/tarballs dir to manage the caching
21:32
<
clever >
Lisanna: according to the source, nix-channel always sets the ttl to 0
21:32
<
clever >
Path Downloader::downloadCached(ref<Store> store, const string & url_, bool unpack, string name, const Hash & expectedHash, string * effectiveUrl, int ttl)
21:31
<
clever >
auto filename = dl->downloadCached(store, url, false, "", Hash(), &effectiveUrl, 0);
15:29
<
clever >
hodapp: did you try adding pkgconfig to the nativeBuildInputs?
12:10
<
clever >
dima1: nixpkgs.overlays
11:59
<
clever >
depends on what exactly is failing
11:58
<
clever >
angerman: you may need to manually add "${openssl.out}/lib" to PATH because windows is dumb
11:53
<
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
11:53
<
clever >
angerman: those are the same nix expression, its just split outputs
2018-06-05
19:51
<
clever >
Aleksejs: run file on the ELF binary
19:37
<
clever >
you have to hash every file it read during the eval
19:36
<
clever >
the problem with just hashing the deployment file, is imports and readfile
19:36
<
clever >
it works purely on the sqlite state file
19:36
<
clever >
ldlework: there is `nixops info --no-eval` that can mostly deal with it, and also prevent any destructive operations
19:35
<
clever >
ldlework: thats what happens when you have 80+ machines in the deployment file
19:34
<
clever >
ldlework: i have also seen deployments where info takes 40gig of ram and takes 5 minutes
19:34
<
clever >
ldlework: running `nixops info` can be a potentially destructive operaiton if the `--arg` flags are using relative paths
07:04
<
clever >
Orbstheorem: realpath /nix/store/...-user-environment/bin/powertop
06:47
<
clever >
Orbstheorem: yeah
06:46
<
clever >
Orbstheorem: nix-store -q --referrers
06:46
<
clever >
Orbstheorem: you want the things refering to it
06:44
<
clever >
PolarIntersect: your welco,e
06:43
<
clever >
Orbstheorem: that is part of nixos, what derivation was refering to system-path?
06:42
<
clever >
Orbstheorem: so it will contain a mix of many nixpkgs revisions
06:42
<
clever >
Orbstheorem: that is a nix-env profile, not a nixos one
06:40
<
clever >
Orbstheorem: paste the full storepath for a given derivation
06:40
<
clever >
Orbstheorem: nixos derivations are special, the name of the derivation includes the git rev of the nixpkgs
06:38
<
clever >
Orbstheorem: not easily, you need at least the path to the nixpkgs that was used to build it
06:38
<
clever >
PolarIntersect: even with -la ?
06:34
<
clever >
PolarIntersect: and the default buildPhase already runs make, you dont need to do that
06:34
<
clever >
PolarIntersect: what does `ls -lh /nix/store/cgzkz8gdlx46wcvvn7n09h455wmhh97s-monokrome` show?
06:30
<
clever >
PolarIntersect: can you gist the whole output of nix-build?
06:29
<
clever >
yeah, it will use the directory the nix file is located in
06:21
<
clever >
PolarIntersect: thats normal
06:19
<
clever >
Orbstheorem: there is also nix-diff
06:19
<
clever >
Orbstheorem: i mostly just check the git logs, once i know the revisions of things
06:16
<
clever >
yeah, give it some time
06:15
<
clever >
then use `with import <unstable> {};`
06:14
<
clever >
18.03 is the newest stable channel
06:14
<
clever >
3: headers got properly moved into godot
06:14
<
clever >
2: godot + godot_headers
06:14
<
clever >
1: godot without headers
06:13
<
clever >
there are 3 different states that godot appears to have been in
06:13
<
clever >
its possible that the 18.03 channel is also too old
06:12
<
clever >
and nix will just build it for you
06:12
<
clever >
and if you set the src on your derivation properly, you can also just `nix-build` your default.nix file
06:11
<
clever >
ls -l result/
06:11
<
clever >
nix-build '<nixpkgs>' -A godot
06:09
<
clever >
so you can fix that later
06:09
<
clever >
you also dont need to nixos-rebuild to make this change apply in your nix-shell
06:05
<
clever >
use --show-trace to see where it is
06:05
<
clever >
that has been fixed in 18.03
06:05
<
clever >
one of your derivations was abusing a bug in nix1
06:04
<
clever >
what error does it give now?
06:03
<
clever >
nixos always uses the channel named nixos
06:01
<
clever >
also, yes, `sudo nix-channel --remove nixpkgs ; sudo nix-channel --update`
06:01
<
clever >
you dont need it
06:01
<
clever >
on may 2nd, godot_headers was deleted from nixpkgs
06:01
<
clever >
i'm checking the git logs now, something strange is happening
06:00
<
clever >
you added 18.03 under the name nixpkgs
05:59
<
clever >
what does `sudo nix-channel --list` report?
05:59
<
clever >
but, the channel your on may never get it
05:59
<
clever >
the --upgrade will automatically do a `nix-channel --update` for you
05:58
<
clever >
nix-channel --update
05:57
<
clever >
your derivation still lacks a name = "something";
05:56
<
clever >
what does this return?: nix-instantiate --eval '<nixpkgs>' -A lib.nixpkgsVersion
05:55
<
clever >
it finds godot_headers when i run it
05:55
<
clever >
[clever@amd-nixos:~/c9efc13830017160eda123e122d4514a]$ nix-shell -A yourthing
05:55
<
clever >
nix-instantiate --find-file nixpkgs
05:54
<
clever >
think of it like #include <math.h>
05:54
<
clever >
<nixpkgs> will search $NIX_PATH
05:53
<
clever >
and `with import <nixpkgs> {};` puts everything in its return value into scope
05:53
<
clever >
`import <nixpkgs> {}` then calls that function with an empty set
05:53
<
clever >
`import <nixpkgs>` returns the function at its top-level
05:53
<
clever >
<nixpkgs> returns the path to nixpkgs
05:52
<
clever >
then you can run nix-shell -A yourthing
05:51
<
clever >
you must load it with pkgs.callPackage
05:50
<
clever >
that derivation lacks a name
05:50
<
clever >
PolarIntersect: the attribute is not called nixpkgs
05:49
<
clever >
so nixops can break when inside a nix-shell that includes other python deps
05:49
<
clever >
robstr: when you add python packages to the buildInputs, it mutates the default PYTHONPATH, and nixops obeys that
05:45
<
clever >
PolarIntersect: can you pastebin your current .nix file with the latest errors?
05:44
<
clever >
robstr: try running nix-shell without shoving it into the buildInputs of something relatively unrelated
05:43
<
clever >
PolarIntersect: what nix-shell args are you using?
05:43
<
clever >
PolarIntersect: libraries must never be installed
05:42
<
clever >
robstr: and does the default.nix it imports on line 12 do anything with python?
05:40
<
clever >
robstr: how did you pin it?
05:39
<
clever >
robstr: id say that python library is broken then
05:35
<
clever >
robstr: does the one its looking for exist?
05:35
<
clever >
robstr: what .so files exist?
05:33
<
clever >
oops, add an ls -l at the start
05:33
<
clever >
robstr: what does this report: `/nix/store/3g1si0y1d15dmsakgl1fnxzy8s8n97h0-python3.6-pycryptodome-3.5.1/lib/python3.6/site-packages/Crypto/Util/../Hash/`
05:21
<
clever >
robstr: it will automatically pass you the value of pkgs.pkgs
2018-06-04
15:49
<
clever >
dash: there is also yarn2nix
13:19
<
clever >
robstr: yeah, that looks like it
13:18
<
clever >
jophish: the initrd is generated with a /init symlink pointing to stage1
13:18
<
clever >
yeah, that is stage 2
13:18
<
clever >
jophish: the kernel
13:17
<
clever >
and then require everybody to nix-shell first
13:17
<
clever >
you could also use a shell.nix file that sets NIX_PATH=nixpkgs=https://github.com/nixos/nixpkgs/archive/GITREV.tar.gz
13:16
<
clever >
i think there is a PR on nixops about improving it
13:16
<
clever >
robstr: i keep a command like the above as a comment in my deployment file, so others know what it should be on
13:14
<
clever >
robstr: nixops modify -d name deployment.nix -I nixpkgs=https://github.com/nixos/nixpkgs/archive/GITREV.tar.gz
13:13
<
clever >
robstr: it only effects nix-shell and nix-build
13:12
<
clever >
robstr: that doesnt work when doing things with nixos or nixops
13:10
<
clever >
robstr: nixops modify -d name deployment.nix -I nixpkgs=https://github.com/nixos/nixpkgs/archive/GITREV.tar.gz
12:38
<
clever >
i do pure ZFS on all of my installs
12:14
<
clever >
sorixelle: run `pwd` and `ls -ltrh` inside the installPhase, you should already be cd'd into the sourceRoot
12:09
<
clever >
you can just set installPhase to a bash script, directly quoted in the nix file
12:08
<
clever >
sorixelle: you rarely need to set builder directly, that tends to over-complicate things
12:06
<
clever >
sorixelle: can you gist your current nix file?
12:04
<
clever >
so you may be able to just `sed -i foo.txt`
12:04
<
clever >
sorixelle: also note, that the unpackPhase has already copied $src to . for you