2019-12-04

<clever> tbenst: environment.etc, in the nixos manual
<clever> and default itself, is another symlink
<clever> yep
<clever> is a symlink into /nix/
<clever> catern: and the symlinks made by result will only work on one machine
<clever> catern: it should work fine, once you install nix on both machines, but they will have different things things in nix-env
<clever> bsima: i try to avoid runAsRoot, because it harms performance, even more if you lack access to /dev/kvm
<clever> bsima: the only way to get root is to run the entire command in a qemu vm
<clever> o1lo01ol1o: its usually a list, so swapDevices = [ { device = "/var/lib/swap1"; size = 2048; } ];
<clever> o1lo01ol1o: if you point device to a file (which can not exist), and also set size, then nixos will generate a file for you, of that size
<clever> swapDevices.*.device
<clever> swapDevices.*.size
<clever> o1lo01ol1o: and with only 500mb available, i can see how hydra might OOM
<clever> o1lo01ol1o: what does free -m report?
<clever> o1lo01ol1o: those are disk free, not ram free
<clever> o1lo01ol1o: `free -m` ?
<clever> o1lo01ol1o: anything in dmesg?
<clever> o1lo01ol1o: did you use sudo -i or plain sudo hydra-eval-jobset?
<clever> o1lo01ol1o: did it return to the hydra shell or the root shell?
<clever> then you can see the full eval output, without it getting mixed into other unrelated logs
<clever> o1lo01ol1o: as the hydra user, run hydra-eval-jobset <project> <jobset>
<clever> dmj`: but its difficult to confirm if your censoring all of the code!
<clever> dmj`: thats what i suspected, when i asked the very first question
<clever> dmj`: 2019-12-04 14:00:19 < clever> dmj`: is it a deployment file or nixos file?
<clever> dmj`: can you pastebin the whole `--show-trace` ?
<clever> dmj`: what is the exact error it gives?
<clever> dmj`: there is no { optimizations ? false }: anywhere in that example
<clever> dmj`: can you pastebin that file?
<clever> dmj`: is it a deployment file or nixos file?
<clever> and prevents such issues
<clever> builtins.path takes both a name and a filter
<clever> because the original hash1-foo and hash2-foo didnt match
<clever> Taneb: and when you filtered in hash2-foo, it copied&filtered, to hash4-hash2-foo
<clever> Taneb: when you did ./., in /nix/store/hash1-foo, it copied&filtered, to /nix/store/hash2-hash1-foo
<clever> Taneb: the names of the 2 inputs dont match, you must use builtins.path
<clever> Taneb: can you pastebin the output from nix-diff?
<clever> Taneb: can you paste a link to the hydra in question?
<clever> Taneb: try using nix-copy-closure to pull the .drv from hydra, and use nix-diff to compare to a local one?
<clever> Taneb: and are you looking at the src for the derivation hydra is building?
<clever> deni: did you use ${ like in my example?
<clever> Taneb: if its excluded, you wont see it in the nix store
<clever> then you may need to exclude .gitignore too
<clever> Taneb: are you using filterSource?
<clever> Taneb: what is nix-diff saying the difference is?
<clever> Taneb: you want builtins.path if you need to ensure ./. has the same name
<clever> but if you where, you would use passAsFile
<clever> deni: in your case, your not even editing the file, so you can just use cat or even cp
<clever> deni: '${dev_key}' will blow up the instant you have a ' in the json
<clever> bash chews up the json
<clever> deni: '' echo ${dev_key} > /some/path/key.json'' just generates: 'echo {"key":"value"} > /some/path/key.json'' and then
<clever> deni: nix is generating a bash script, and bash then runs that to produce the result
<clever> {key:value}
<clever> $ echo {"key":"value"}
<clever> deni: basically, try just doing `echo <json>` in a terminal, without any extra quoting
<clever> deni: you want just `cat ${./path/to/key.json} > /some/path/key.json` without the echo of readFile
<clever> deni: bash parsed all of the quotes in that and chewed it up
<clever> syzygyzer: so once its being read, its too late to change which nixpkgs your using
<clever> syzygyzer: the nixpkgs in the channel is what reads configuration.nix
<clever> syzygyzer: you usually dont want channels on the non-root user, only use channels on root
<clever> ,stateVersion Shoubit
<clever> jboy: `nix-env --profile /nix/var/nix/profiles/system --set /nix/store/something` will ask nix to just make a given build current
<clever> jboy: if you `ls -l /nix/var/nix/profiles` you can see what every generation is pointing to, and the main `system` symlink points to the current one
<clever> jboy: rollback doesnt delete generationd
<clever> that also applies to using sed
<clever> let PATH do things for you
<clever> just replace /usr/bin/gcc with plain old gcc
<clever> stdenv puts gcc in PATH
<clever> oh wait no
<clever> ah right, ack!
<clever> but sed is probably simpler
<clever> then use patches = [ ./foo.patch ];
<clever> Henson: if you are making a patch, edit the makefile, and use diff -u to generate a patch
<clever> Henson: patch the makefile, with either sed or a .patch file
<clever> zeta_0: though i notice, you have 2 ihaskell's in there, that will cause problems
<clever> zeta_0: looks fine
<clever> zeta_0: you dont need line 8, the pkgs on line 5 already gives you nixos unstable

2019-12-03

<clever> nh2: i think they are only meant for bootstrapping
<clever> zeta_0: { config, pkgs, lib, ... }:
<clever> zeta_0: which piece of code? for what?
<clever> siraben: probably fine
<clever> zeta_0: looks good
<clever> which would likely lead to more confusion
<clever> which is pointless
<clever> tilpner: both nixos and nixos-unstable map to nixos-unstable
<clever> zeta_0: you want to delete the duplicate nixos-unstable
<clever> siraben: id say you should also print that your own timeout triggered, when it triggers
<clever> that will do it
<clever> oh
<clever> tilpner: it failed in 56 seconds, that doesnt look like a timeout?
<clever> zeta_0: nixos-unstable or nixos-19.09
<clever> siraben: does /nix/store/dfcag0m309w32f9a2cgs3k5d3qj7slzf-mini-haskell.drv exist locally?
<clever> zeta_0: any channel
<clever> ,locate
<clever> ,locate bin/nix-locate
<clever> zeta_0: you must give both a name and url, the man page says which order they go in
<clever> Thra11: nix-locate and the ,locate command on {^_^}
<clever> zeta_0: use --add again, the man page says how to specify a name
<clever> tilpner: the default $NIX_PATH assumes its named nixos, and will complain if it isnt
<clever> zeta_0: one of them must be named "nixos" in the left column, and nixos-rebuild will use that
<clever> zeta_0: you dont have a channel with a name of "nixos" anymore, so its failing to find "nixos"
<clever> zeta_0: does `nix-channel --list` show a nixos channel?
<clever> zeta_0: pretty much
<clever> zeta_0: it still explains how to run software from a channel your not on
<clever> zeta_0: just swap the names in the directions
<clever> ,unstable zeta_0
<clever> mananamenos: if you want to access it as your own user, you need to use roles or similar, to grant yourself permission to another user
<clever> mananamenos: i think you have to run that as the linux user postgres
<clever> exceptions lead to it not creating $out
<clever> zeta_0: 35/36 will then do something with those variables, and in this case, the result is a binary "it worked" or "it failed", so it just always writes "done" to $out
<clever> zeta_0: this will grab a ghc that has cardano-sl-util, cardano-sl-infra, and split in scope, then compile lines 25-55, then it will execute the compiled haskell code, with the 2 env vars from lines 8&15
<clever> zeta_0: and here is an example of it in use, you execute runHaskell, pass it a name, a set of haskell packages to get things from, a list of haskell deps, an attribute set, and a string containing haskell code
<clever> whatever $code is, it should create a path at $out
<clever> zeta_0: and line 104 uses a 1 line shell script, to just run the compiled $code
<clever> zeta_0: lines 99-102 uses a 2 like shell script to compile $code with that ghc
<clever> zeta_0: line 97 will create a ghc that has a certain set of packages
<clever> hmmm, thats an older version, one min
<clever> zeta_0: but i have devices a way to abuse haskell instead of bash
<clever> zeta_0: yes
<clever> fairly simple when using cabal2nix
<clever> ive not really looked at them, and learned nix before they where around
<clever> yep
<clever> zeta_0: i did not say /nix/store/hcnlk56iv0aajdaa83piscvrjwifpn5q-simple
<clever> zeta_0: i said, /nix/store/hcnlk56iv0aajdaa83piscvrjwifpn5q-simple/simple
<clever> thats why the directions ended with "in your shell"
<clever> zeta_0: in a normal shell
<clever> zeta_0: can you just screenshot the whole terminal?
<clever> zeta_0: thats not what it should have done, at all
<clever> which is exactly what the docs said: Now you can run /nix/store/ni66p4jfqksbmsl616llx3fbs1d232d4-simple/simple in your shell.
<clever> you want /nix/store/hcnlk56iv0aajdaa83piscvrjwifpn5q-simple/simple
<clever> `bash /nix/store/hcnlk56iv0aajdaa83piscvrjwifpn5q-simple` wont work, because simple is a directory, not a file
<clever> and so on
<clever> then a store in that
<clever> that tells it to look for a nix in the current dir
<clever> zeta_0: `./nix/store/hcnlk56iv0aajdaa83piscvrjwifpn5q-simple` only works if your current dir is /
<clever> zeta_0: and what is the exact command you ran, and the output it gave?
<clever> are you using the exact hash from the page, or the hash you got yourself?
<clever> if its giving an error, then something is probably wrong
<clever> yes
<clever> zeta_0: what output does it give?
<clever> zeta_0: run `file` on the file your trying to run
<clever> zeta_0: what does `file` say about it?
<clever> gchristensen: if nothing else is using that kernel module, you can try to blacklist it
<clever> gchristensen: you need to compare against the drivers you see in lspci -k
<clever> so i could just hot-unplug a usb card, then hot-plug it into a guest
<clever> i mainly used that when doing pci passthru
<clever> and the bind file in the same folder, lets you re-connect things
<clever> without unloading the entire driver
<clever> that will let you basically unplug any device (usb or otherwise) from its driver
<clever> and if you echo the bus:slot:function id (like 04:00.0) into the unbind file, that will... unbind the device from the driver
<clever> gchristensen: if you use lspci -k, you can see which driver is using a given pci device
<clever> $ ls /sys/bus/pci/drivers/ohci-pci/unbind
<clever> one min
<clever> gchristensen: ah, maybe the others are just idle
<clever> i think the pastebin is truncated, i'm only seeing cpu's 1, 5, 4, and 2

2019-12-02

<clever> gchristensen: search it for the name of the thread in question
<clever> and did it show anything useful for the faulty worker?
<clever> gchristensen: have you seen my sysrq trick about how to backtrace?
<clever> gchristensen: which part?
<clever> dmj`: the binary cache db under ~/.cache/nix
<clever> najki: on the remote node that is serving things, run `nix-store --verify --check-contents`
<clever> srhb: ~/.cache/nix/
<clever> thomashoneyman: check what the group named "default" is going in your account
<clever> thomashoneyman: but the aws security groups sometimes block it
<clever> thomashoneyman: port 22 is opened on the nixos firewall automatically
<clever> ah, so its already fixed, and nixpkgs just needs a ver bump
<clever> philipp[m]: have you tried building with nix-bundle master, from github?
<clever> neeasade: i just `ls -ltrh /tmp/` and look at the most recent nix-build-name dirs
<clever> philipp[m]: or it will break projects i'm using it in currently
<clever> philipp[m]: it would need to support all of the existing flags, including the escape hatch
<clever> it needs to be -DNIX_SSL_CERT_FILE='"something"'
<clever> philipp[m]: NIX_SSL_CERT_FILE isnt quoted properly
<clever> philipp[m]: what eeror does it fail with?
<clever> ive not really used the new #! style shells much
<clever> it will run foo.sh, inside the shell.nix env
<clever> you can also `nix-shell --run ./foo.sh`
<clever> then nix-shell will run "shell code" when it loads that shell.nix
<clever> virus_dave: (import ./.).overrideAttrs (old: { shellHook = "shell code"; })
<clever> virus_dave: you can put that script into the shellHook in the shell.nix
<clever> philipp[m]: nix-bundle
<clever> virus_dave: you should just have a shell.nix that does the right thing, and only run nix-shell
<clever> if your doing things right, you shouldnt need a #!
<clever> yeah, try that first
<clever> you want the shell.nix to return default.nix directly, maybe with overrides
<clever> if the default.nix is in the buildInputs, then it gives you a shell suitable for using it, not developing with it
<clever> so you can just run `nix-shell` alone
<clever> shell.nix is also the default file
<clever> you want to run `nix-shell shell.nix`
<clever> virus_dave: -p gives you a shell suitable for using it, not for developing it
<clever> your only 1mb over my own, lol
<clever> -rw-r--r-- 1 root root 14M Nov 25 19:05 viaqcw6s1v579d06f4m8iz7vbfac7zbi-initrd-linux-4.19.81-initrd
<clever> so recursive sets make overriding imposible
<clever> the recursive b=a, reads the old a, before // changes a
<clever> DigitalKiwi: it doesnt :P
<clever> > (rec { a=1; b=a; }) // { a=2; }
<clever> DigitalKiwi: i think they also have a slight performance cost
<clever> DigitalKiwi: recursive sets are a pain to override things on
<clever> prefix your own name onto things!
<clever> > foo
<clever> theres already an a in scope
<clever> > a
<clever> DigitalKiwi: makes a set recursive
<clever> 2019-12-01 22:00:42 < clever> red[evilred]: replace the { with rec {
<clever> supermathieu: rec {
<clever> red[evilred]: replace the { with rec {
<clever> red[evilred]: rec {
<clever> which then spat out syntax errors
<clever> so, it ran sh on the arm llvm
<clever> and after failing to execute the arm binary, something decided, "well it must be a shell script"
<clever> i accidentally put an arm llvm into my x86 buildInputs
<clever> i just remembered something else ive seen today, that is fairly nasty
<clever> and then fill it in at runtime
<clever> elvishjerricco: you could also give systemd a fake util-linux, that only has a symlink from mount to /bin/mount
<clever> elvishjerricco: dont make my life any harder :P
<clever> /dev/sde2 48M 43M 1.6M 97% /boot
<clever> Filesystem Size Used Avail Use% Mounted on
<clever> elvishjerricco: but that means 2 mounts, and rebuilding systemd
<clever> elvishjerricco: i was thinking along the same lines, override it to a dir that has just mount, already patchelf'd
<clever> elvishjerricco: that works, you could even pass it a static busybox
<clever> boomshroom: renders normally here

2019-12-01

<clever> thats the worst kind of software to try and maintain on nix
<clever> ah, that will definitely break things
<clever> maybe search the issues to see if its already fixed?
<clever> youll need to fix the hash in nixpkgs, or wait for somebody else to fix it
<clever> so we dont know what the output should have been
<clever> it probably renamed it, to match the hash it got
<clever> ah
<clever> sounds like the hash in nixpkgs just needs to be updated
<clever> thats strange, i would expect them to differ
<clever> boomshroom: what path did you run it on?
<clever> boomshroom: what about `diff -r` between the directories they are in, the storepaths
<clever> boomshroom: what part doesnt look right?
<clever> boomshroom: check the output path, and confirm it looks valid
<clever> boomshroom: if you try again, does it fail with the same hashes in the error?
<clever> john67556: this will let you compare the kernel versions
<clever> ls -l /run/{current,booted}-system/kernel
<clever> kim0: youll need to reboot yourself to make that change take effect
<clever> but blueman was running
<clever> manveru: nothing was using the bluetooth at the time
<clever> it will take a 3 second nap, then wake up on its own
<clever> xidica: ive also got suspend problems, the laptop just wakes up 90% of the time i `systemctl suspend`
<clever> jco: you must `nix-env -e emacs` (as root) to remove that
<clever> jco: you installed emacs with nix-env as root, that has priority
<clever> jco: what does `type emacs` return in a shell?
<clever> jco: is configuration.nix then installing pkgs.emacs?
<clever> dmj`: if you set patchPhase, then it will stop obeying patches, you probably want to use postPatch
<clever> jco: you must do nixpkgs.overlays = [ (import /path/to/one/overlay.nix) ];
<clever> jco: nixos-rebuild doesnt read ~/.config/nixpkgs/overlays

2019-11-30

<clever> pistache: not currently
<clever> Nycatelos: its better to develop with nix-build, not nix-env
<clever> coderobe: did you nix-channel --update?
<clever> coderobe: use nix-channel --add as root, to change which channel its following
<clever> dirkx_: drop the destdir and see what happens
<clever> dirkx_: destdir says to prefix all paths with $out, including the $INCLUDEDIR
<clever> coderobe: things like llvm currently dont cross-compile
<clever> dirkx_: thats completely wrong, your headers are not in /nix/store/foo/include, they are in /nix/store/foo/nix/store/foo/include
<clever> then, i think, source the etc/profile.d/nix.sh in that path
<clever> coderobe: and then find the nix binary in the store, and run nix-env -i on that storepath
<clever> coderobe: youll want to load the db back within the tar (example here, https://github.com/cleverca22/nix-tests/blob/master/disk-image-tests.nix#L16 )
<clever> coderobe: https://hydra.angeldsis.com/build/97196 this contains a tarball with nix cross-compiled
<clever> coderobe: you just need nix-store in $PATH somehow, so you could just install nix onto a bunch of rasbian machines
<clever> coderobe: i think it took me ~2 days to build a usable amount of v7 on one or two pi's
<clever> coderobe: youll have to ask whoever is maintaining that, what rev they are on
<clever> dirkx_: what do you see when you `ls -l /nix/store/rsbdnyqr5b744hwv444rqjqb1yivahxn-mod_ca/` ?
<clever> and it will also work just fine in linux, lol
<clever> spill water in the wrong place, and the mouse will work in the bios, but not the os
<clever> i'm talking specifically about the laptops
<clever> ah
<clever> (for the touchpad)
<clever> betawaffle: also, the i2c pads are in just the right spot to be damaged by water spills, and the os lacks usb drivers :P
<clever> betawaffle: when in the bios, it uses usb, but when the os boots up, it switches to i2c
<clever> betawaffle: something ive heard is that the apple touchpad (on some models) is both usb and i2c based
<clever> dirkx_: all buildInputs get added to -I automatically
<clever> dirkx_: if you build mod_ca.nix, and then `ls result/include`, is the file right in that dir?
<clever> dirkx_: the () around the import are required
<clever> dirkx_: it will basically just insert the result of parsing the file, and build whatever is missing
<clever> dirkx_: that will load the other file
<clever> dirkx_: you need buildInputs = [ (import ./foo.nix) ]; at a bare minimum
<clever> dirkx_: yes
<clever> this will force it to test against v7, even if you run the test on an x86 machine
<clever> [root@amd-nixos:~]# nix-build --dry-run '<nixpkgs>' -A hello --argstr system armv7l-linux
<clever> coderobe: v6 v7 or aarch64?
<clever> thats the only real way to see if a binary cache has a given rev or not
<clever> coderobe: repeat this command on various versions of nixpkgs, until it stops wanting to build things
<clever> [root@amd-nixos:~]# nix-build --dry-run '<nixpkgs>' -A hello
<clever> these paths will be fetched (0.04 MiB download, 0.20 MiB unpacked): /nix/store/yhzvzdq82lzk0kvrp3i79yhjnhps6qpk-hello-2.10
<clever> coderobe: channels normally solve this problem for you, by only advertising a rev after its in the cache
<clever> coderobe: for every revision, instantaite an expresion, then test if that output is in the cache
<clever> betawaffle: maybe, try just booting an iso from usb and see what happens?
<clever> betawaffle: this allows linux to access the nvme devices
<clever> coderobe: that will work perfectly fine
<clever> something about only being able to access recovery mode once you do the initial setup
<clever> the newer T2 chip'd models also have a non-standard nvme controller, so the drive wont even exist if your kernel is unpatched
<clever> betawaffle: cant remember where it was, youll just need to google that part
<clever> betawaffle: its a pain in the ass to unwrap a new mac, and then be forced to do the entire setup, when your about to wipe the drive :P
<clever> betawaffle: you need to disable secureboot in the firmware first, which requires doing the entire initial setup procedure