2020-05-12

<clever> immae: that "wrong" ld.so, starts its search in the wrong dir
<clever> immae: and its using the ld.so from ldd's package, not the ld.so your binary wanted
<clever> immae: ldd just runs ld.so with a special env var set
<clever> betaboon: yeah, thats about the only way to avoid having to hold the entire image in ram
<clever> betaboon: put the rootfs on iscsi instead of embeding into the initrd
<clever> `_: not sure then
<clever> `_: your likely using the xterm window manager, there is a nixos option to disable that, which will switch you to another one
<clever> balsoft: i'm also running custom firmware in the bootcode.bin as well
<clever> energizer: nixops has some internal stuff, to turn a hashmap into a set
<clever> energizer: rnix is also a thing
<clever> pjt_014: personally, i use hydra to do similar, it roots the entire build-time closure
<clever> pjt_014: lorri might do that, you can also just run `nix-store -r /nix/store/foo --add-root result-1 --indirect` to make a root for any given path
<clever> atemu12[m]: if bash cant execute something, it just blindly assumes its a bash script, and runs itself on that file
<clever> atemu12[m]: nope
<clever> balsoft: but i have recently discovered, that half the #! scripts are using the x86 bash, and yet it somehow still boots
<clever> balsoft: ive been cross-compiling an entire nixos and deploying it with nixops
<clever> pjt_014: what expr are you using and how is it failing?
<clever> keithy[m]: thats why everybody just uses static lists, and only if you decide to edit the cfg, will things change
<clever> keithy[m]: yep, that will silently ignore any file that doesnt exist
<clever> nix-repl> :p a
<clever> [ /home/clever/.bash_history ]
<clever> if a file is missing both config and options, it gets wrapped with a config = { ... }; automatically
<clever> then merge the .config and .options of everything together
<clever> then recursively repeat on every file in imports
<clever> read the imports list
<clever> the module system will then run the function to get access to the set within
<clever> a module is something in the form of `{ config, pkgs, ... }: { config = { something; }; options = { something; }; imports = [ something ]; }`
<clever> keithy[m]: the config and options returned by every module gets merged, and then the merged result is passed as input back into every module
<clever> keithy[m]: the imports list is part of the module system, it will recursively load every file in the imports list, then fix-point them all together
<clever> keithy[m]: the import function takes a single path, parses the nix within, and returns whatever expr is within
<clever> ,xy keithy[m]
<clever> nix-repl> builtins.pathExists ./arc
<clever> true
<clever> energizer: not sure
<clever> energizer: what do you get for `config` ?
<clever> energizer: i can see _module just fine
<clever> { args = { ... }; check = true; }
<clever> nix-repl> config._module
<clever> energizer: did you use <nixpkgs/nixos> ?
<clever> energizer: it will only fail if you try to use foo somewhere
<clever> energizer: it is recursive, but also lazy
<clever> energizer: this line is the reason you can even use pkgs in that line, https://github.com/NixOS/nixpkgs/blob/release-20.03/nixos/modules/misc/nixpkgs.nix#L229-L232
<clever> keithy[m]: because i dont want things like router.nat.nix to activate on other machines, and all of these files are in one directory
<clever> energizer: _modules is a normal config option
<clever> keithy[m]: look at lines 16-29 in the above link
<clever> keithy[m]: most people define things in the nix file, and dont make it magically change when files get added
<clever> keithy[m]: this is the config for my router, https://github.com/cleverca22/nixos-configs/blob/master/router.nix
<clever> keithy[m]: it may help if you read other peoples nixos config
<clever> energizer: thats how pkgs even wound up in there
<clever> energizer: yep, _module.args.foo lets you { foo, config, pkgs, ... }:
<clever> energizer: but the list is relatively small
<clever> energizer: it also varies, and nixops can add more things to it
<clever> energizer: simplest answer is to just remove the ... and let the errors tell you
<clever> and then use lib like normal
<clever> you can do { pkgs, lib, ... }: on line 1
<clever> if you want to run the examples in the docs, use <nixpkgs>
<clever> if you want to do stuff with nixos and configuration.nix, use <nixpkgs/nixos>
<clever> <nixpkgs/nixos> if you want to do nixos things
<clever> <nixpkgs> if you want to do stuff with packages and lib
<clever> keithy[m]: i said <nixpkgs> not <nixpkgs/nixos>
<clever> keithy[m]: can you screenshot the terminal?
<clever> keithy[m]: did you start the repl the same way i did?
<clever> keithy[m]: that example worked perfectly, just pasting into the repl
<clever> nix-repl> lib.attrsets.setAttrByPath [ "a" "b" ] 3
<clever> { a = { ... }; }
<clever> [clever@amd-nixos:~]$ nix repl '<nixpkgs>'
<clever> keithy[m]: which example is failing?
<clever> keithy[m]: did you try in `nix repl '<nixpkgs>'` ?
<clever> then just `config`
<clever> that will load configuration.nix on its own
<clever> keithy[m]: `nix repl '<nixpkgs/nixos>'`
<clever> keithy[m]: nix repl
<clever> keithy[m]: can you pastebin the code you used?
<clever> keithy[m]: then just put that whole list of filenames into the imports list
<clever> keithy[m]: will each file contain nixos options?
<clever> and then?
<clever> keithy[m]: what do you want to then do with that list of nix files?
<clever> and map to iterate over the list
<clever> keithy[m]: now you can use `builtins.match` to see if its a .nix file, and import to import it
<clever> it may need a :p at the front
<clever> keithy[m]: now what about `builtins.attrNames (builtins.readDir ./.)` ?
<clever> keithy[m]: first, what do you get when you `builtins.readDir ./.` in `nix repl` ?
<clever> keithy[m]: try doing `builtins.readDir ./.` in a `nix repl`
<clever> keithy[m]: map over the results from builtins.readDir
<clever> keithy[m]: something = lib.mkMerge [ { set1 } {set2} {set3} ];
<clever> keithy[m]: you can also use mkMerge in nixos config
<clever> keithy[m]: why are you trying to merge those sets?, what will then consume the result?
<clever> defaults is a special key applied to all machines
<clever> imports can contain a file, a function(returning a set), or a bare set
<clever> imports = [ ({config, pkgs, ... }: { ...}) ];
<clever> cole-h: i think nixops passes each function as an imports list
<clever> cole-h: nope
<clever> but recursiveUpdate doesnt use that type system
<clever> cole-h: things like lib.types.lines, can accept "foo" and "bar", but magicaly turn it into "foo\nbar"
<clever> cole-h: because it doesnt know what rules to use for merging
<clever> cole-h: when keys collide, the later overwrites
<clever> > :p lib.recursiveUpdate { a = [1]; } { a = [2]; }
<clever> > lib.recursiveUpdate { a = [1]; } { a = [2]; }
<clever> cole-h: what you want, is to just use defaults or `imports = [ ./common.nix ];`
<clever> cole-h: so it will still wreak havoc on your nixos config
<clever> cole-h: recursiveUpdate wont merge lists properly
<clever> nixops merges it for you
<clever> Henson: anything you put into defaults, applies to all machines
<clever> Henson: have you seen the defaults key?

2020-05-11

<clever> devalot: yeah, that could be an issue...
<clever> devalot: then you just flag your service as depending on that one
<clever> devalot: nixops creates a -keys service automatically, you should see it in /etc/systemd/system and the nixops docs
<clever> lib.overrideDerivation is the old way of doing it
<clever> morgrimm: you can usually just use pkgs.foo.overrideAttrs now
<clever> morgrimm: ah, the override is gone now, youd have to check its git history
<clever> morgrimm: you can override it as well, look at toxvpn/default.nix in nixpkgs
<clever> betaboon: probably
<clever> betaboon: meta = old.meta // { platforms = old.meta.platforms ++ [ more ]; };
<clever> evanjs: ive not seen it before
<clever> evanjs: its cache.nixos.org
<clever> nopsled: nix-build with --dry-run and see if its in the list of things to download
<clever> betaboon: and it may need both the 397 and 442 at the same time, so thats 839mb needed, plus some overhead and your getting close
<clever> danderson: though for group stuff, you can just chgrp the socket, and use normal unix permissions to allow/deny connection, seperate from querying the uid
<clever> betaboon: that 397mb initrd is compressed, if you `cat initrd | gunzip > temp ; ls -lh temp`, how big does it inflate to?
<clever> betaboon: might not fit after you uncompress, can you give it more ram?
<clever> betaboon: how much ram? how big is the initrd?
<clever> nopsled: update-users-groups.pl generates it
<clever> nopsled: weird, thats not json, just a plain list of names
<clever> nopsled: that is normal
<clever> nopsled: how big is the corrupt uid-map, what does `hexdump -C` say about it?
<clever> nopsled: did you include any unicode characters in any usernames?
<clever> bqy: so it was infinite recursion!
<clever> ah
<clever> danderson: what errors are you having?
<clever> danderson: iohk already has nsis fully cross-compiling
<clever> lafrenierejm: the mdadm in the middle might be confusing systemd-boot
<clever> danderson: iohk is using nixpkgs to crosscompile a lot of things to windows
<clever> lafrenierejm: is your /boot on a fat32 partition, ontop of GPT?
<clever> lafrenierejm: your using systemd-boot, so boot.loader.grub is just ignored
<clever> lafrenierejm: can you pastebin the full output when it fails?
<clever> lafrenierejm: what is the full value you set it to?
<clever> danderson: ^
<clever> > pkgsCross.mingwW64.buildPackages.gcc
<clever> lafrenierejm: did you set boot.loader.grub.device to a weird value?
<clever> danderson: i think thats what you want, for arm
<clever> > pkgsCross.raspberryPi.buildPackages.gcc
<clever> bqy: yeah, id give bisect a try, it shouldnt be using that much for 1 machine
<clever> bqy: what did you change most recently?
<clever> bqy: did you add something recursive to your config?
<clever> bqy: which process is consuming most of the ram? what if you run it with `-vvvv` ?
<clever> bqy: try using ulimit to limit how much ram it can consume
<clever> cole-h: NIX_SHOW_STATS only prints the stats upon successful exit

2020-05-10

<clever> not sure what else to check then
<clever> morgrimm: they seem to be loading rather early
<clever> morgrimm: are the drivers in the initrd?
<clever> morgrimm: then you have crda already
<clever> morgrimm: does this file exist?
<clever> -r--r--r-- 1 root root 273 Dec 31 1969 /etc/udev/rules.d/85-regulatory.rules
<clever> morgrimm: it has its own line doing the same thing in the nixos module
<clever> morgrimm: network manager should also be doing it
<clever> /home/clever/apps/nixpkgs-rust2/nixos/modules/services/networking/networkmanager.nix: crda
<clever> morgrimm: ah, its done by wpa_supplicant via that line
<clever> /home/clever/apps/nixpkgs-rust2/nixos/modules/services/networking/wpa_supplicant.nix: services.udev.packages = [ pkgs.crda ];
<clever> ╚═══85-regulatory.rules: …M=="platform", RUN+="/nix/store/m87whb90czl5wsma1j6fbggqcy24iy6x-crda-3.18/bin/crda".…
<clever> => /nix/store/d7sw966qxg2kmpj4h5kcaa18w8lfw59j-udev-rules
<clever> morgrimm: it manages things like which RF channels are legal to use in your country
<clever> morgrimm: what about this file?
<clever> [ 1.503471] platform regulatory.0: Direct firmware load for regulatory.db failed with error -2
<clever> morgrimm: full
<clever> morgrimm: and do you know which kernel module was handling it before?
<clever> morgrimm: can you pastebin the dmesg output?
<clever> morgrimm: what does `ip link` say?
<clever> morgrimm: nice
<clever> dnlkrgr: then just nix-build -A machotool, to build one
<clever> dnlkrgr: lines 5 and 6 will auto-run cabal2nix for you, and add 2 packages to the haskell package set, and they can depend on eachother
<clever> dnlkrgr: something like this would do it
<clever> dnlkrgr: one min
<clever> shreyansh_k: there was a php problem that broke channel updating but didnt register on hydra
<clever> betawaffle: if there is a bug in the installer, yes
<clever> you may want to try --update
<clever> yep, as it should
<clever> betawaffle: did you run --list as root?
<clever> betawaffle: the installer might have missed the programs.sqlite, youll need to add a channel and --update
<clever> betawaffle: and when/how did you last update your channels?
<clever> betawaffle: what does `nix-channel --list` report?
<clever> betawaffle: what path is it looking at?
<clever> betawaffle: are you using channels, is the channel called nixos?
<clever> yep
<clever> ivegotasthma: the weechatScripts likely isnt marked for recursion, so `nix search` wont look within it
<clever> ivegotasthma: nix-env -iA nixos.weechatScripts.weechat-matrix
<clever> pkgs/applications/networking/irc/weechat/scripts/default.nix: weechat-matrix = python3Packages.callPackage ./weechat-matrix { };
<clever> so its at whatever attr it was at before
<clever> ivegotasthma: the PR didnt add a weechat-matrix to pkgs, it only changed the version
<clever> ivegotasthma: what happens when you `nix-env -iA nixos.weechat-matrix` ?
<clever> ivegotasthma: so you should already have it
<clever> ivegotasthma: that commit is a parent of fce7562cf46
<clever> and that commit itself, is 14 days old
<clever> yep
<clever> version*
<clever> ivegotasthma: `nix eval nixpkgs.lib.verison` ?
<clever> ivegotasthma: what does `nix-instantiate --find-file nixpkgs` return?
<clever> ivegotasthma: nixos-unstable last updated 11 days ago, and you want `sudo -i` not `sudo su`
<clever> matthewcroughan: and nix will then query all substituters, to see what paths are pre-built, and what it has to build locally
<clever> matthewcroughan: the configuration.nix is parsed to generate build directions for store paths, like /nix/store/0iwz12wb5vfv6mdr2mzgy34r8s7lrz90-nixos-system-amd-nixos-20.03pre202088.e89b21504f3
<clever> matthewcroughan: nope
<clever> matthewcroughan: yeah
<clever> ivegotasthma: https://status.nixos.org/
<clever> matthewcroughan: it will let you add storepaths into /nix/store/
<clever> matthewcroughan: so you could setup a server on the other side of the gap, to host the things
<clever> matthewcroughan: you can then either --from back from it, or host that directory over plain http, and do `--option substituters http://that.server`
<clever> matthewcroughan: this one creates a directory of .narinfo and .nar.xz files
<clever> matthewcroughan: there is also another version, let me confirm the cmd...
<clever> matthewcroughan: then `nix copy --from local?root=mnt /nix/store/something` to copy it back out into the host /nix/store on the other side
<clever> matthewcroughan: so `/mnt` could be a usb stick you carry over the airgap
<clever> matthewcroughan: but you can also use `nix copy --to local?root=/mnt /nix/store/something` to create a `/mnt/nix/store/something` dir
<clever> matthewcroughan: `nix-copy-closure` uses ssh to copy things between 2 machines
<clever> matthewcroughan: and you can download one of those store paths from a binary cache, or use nix-copy-closure to copy them between machins
<clever> matthewcroughan: each directory in /nix/store/ is the result of building a derivation
<clever> matthewcroughan: x86? arm? linux? mac?
<clever> matthewcroughan: which tar it downloads, is detected at runtime, based on your os and cpu
<clever> matthewcroughan: the nix install script download a tar file that has a minimal copy of /nix/store/
<clever> matthewcroughan: but you can use `nix-copy-closure` to copy paths between different machines, or run your own binary cache on the other side of the airgap
<clever> matthewcroughan: if your offline, you cant download any new paths
<clever> matthewcroughan: if you pre-download the dependencies for something, you can keep building stuff while offline
<clever> matthewcroughan: it would still work, it searches the copy of nixpkgs you have locally
<clever> matthewcroughan: the `nix` command doesnt have any docs yet, just `nix --help`
<clever> keithy[m]: if its in a string of bash, "source ${./foo.sh}"
<clever> keithy[m]: ./foo.sh, done
<clever> matthewcroughan: `nix search`
<clever> matthewcroughan: if you want to search, `nix search`
<clever> matthewcroughan: if you want htop, build htop
<clever> matthewcroughan: nix-build '<nixpkgs>' -A htop
<clever> keithy[m]: do you want the position of the script, or the nix expr that defines the script?
<clever> keithy[m]: at parse time, that is turned into an absolute path, based on the dir the file was in
<clever> keithy[m]: just use ./. in an expression
<clever> simpson: the hash in /nix/store/hash-name is truncated
<clever> matthewcroughan: one min
<clever> mpiechotka: you can re-run nixos-generate-config to update hardware-configuration.nix
<clever> ldlework: what does the backtrace in gdb say?
<clever> energizer: and the devs are naughty and changed the file on us
<clever> energizer: upstream could have changed things after it got in
<clever> and its now 5am here, i should get to bed
<clever> ldlework: ah, probably not the arch, its listing 2 libasound_module_pcm_pulse.so's because its trying both the 64bit and 32bit ones
<clever> ldlework: is sunvox a 32bit or 64bit binary?
<clever> ldlework: ive not updated my channel in a few months
<clever> awepfijas: lines 12 and 16 tell it what IP to ssh into when you deploy, nas.nix and router.nix then function the same way as the configuration.nix youve been building manually
<clever> awepfijas: and if your managing baremetal machines (or stuff manually provisioned elsehwere), your foo.nix can be this simple
<clever> awepfijas: but if you do `nixops modify -d name foo.nix -I nixpkgs=something`, it gets saved into the nixops state file, and will affect all future deployments
<clever> awepfijas: currently, that includes an `import <nixpkgs>`, so you would need to `-I nixpkgs=something`
<clever> awepfijas: nixops basically just runs nix-build on <nixops/eval-machine-info.nix>, and then its just down to whatever that nix code does
<clever> awepfijas: whats wrong with nixops?
<clever> balsoft: the nix-env step is mostly just to stop garbage collection from eating it, the switch is all that is needed to make it the default at boot
<clever> awepfijas: are you booting with efi or legacy?
<clever> fps: and lines 93-118 build a bootcode.bin for the rpi, using a vc4 cross-compiler, and line 101 copies the arm build of the chainloader into the right path before building
<clever> fps: lines 70-84 builds the arm chainloader for arm
<clever> fps: line 31-38 builds a libcommon.a, for both arm and vc4
<clever> fps: here is a bit more complex of an example: https://github.com/librerpi/rpi-open-firmware/blob/master/default.nix#L22
<clever> awepfijas: no need for the realpath there, symlinks will be followed automatically
<clever> awepfijas: double-check that you have the right fs mounted to /boot/, that kind of issue usually happens if it isnt mounted
<clever> awepfijas: was /boot mounted when you ran switch?
<clever> fps: instead, doing `src = ./app;`, it will filter things better, and rebuild less often, only when the contents of app changes
<clever> fps: but, if that . is the root of your repo, it also includes .git and default.nix, so even doing `git fetch` will change the "source" without changing any source files, and nix will want to build again
<clever> fps: if you add `src = ./.;` to that file, and run nix-build, it will copy whatever is in ./. to the nix store, and then build from that copy of the source
<clever> fps: i also try to avoid putting any source in the root dir of the repo, because it complicates `src = ./.;` you will want later
<clever> fps: then you can just run nix-shell with no args, to get those packages again
<clever> fps: make a default.nix that contains: with import <nixpkgs> {}; stdenv.mkDerivation { name = "name"; buildInputs = [ long list of packages ]; }
<clever> keithy[m]: set serviceConfig.User = "something";
<clever> mpiechotka: then you want mesonFlags = old.mesonFlags ++ [ more flags ];
<clever> mpiechotka: that should show the modified mesonFlags
<clever> mpiechotka: you can also run `nix-store --query --deriver /nix/store/97bywhzi2y48h65a3m1lajfvgwqdgygy-mutter-3.34.5` and then run `nix show-derivation` on that drv file
<clever> mpiechotka: and that version isnt in the binary cache, so its likely your custom one
<clever> mpiechotka: there is no other version it can see
<clever> mpiechotka: then gdm should already be using that version directly
<clever> mpiechotka: only one path?
<clever> mpiechotka: `nix-store -qR /run/current-system | grep mutter` what does this output?
<clever> ah
<clever> ldlework: how is the monitor connected to the gpu?
<clever> mpiechotka: and /run/current-system/etc/ gets mapped/linked into /etc, where /etc/systemd/system/ then controls which display-managaer.service is used
<clever> mpiechotka: that then gets symlinked to /run/current-system/
<clever> mpiechotka: when you boot, the systemConfig= in the bootloader config says where to start
<clever> ldlework: it looks completely normal to me
<clever> ldlework: it might be a problem between your GPU and the monitor?
<clever> ldlework: it worked on the 2nd attempt, i dont see any glitching at all
<clever> ldlework: connection timed out
<clever> numkem: though you probably just want `imports = [ ./path1 ./path2 ./path3 ];` and define more options, dont mix them into the args like that
<clever> > pkgs.which
<clever> pie_: which is in which
<clever> mpiechotka: if gdm depends on mutter directly
<clever> mpiechotka: the overlay should impact gdm too
<clever> energizer: user doesnt matter that much
<clever> mpiechotka: typo in my original example, oops
<clever> mpiechotka: gnome3 = super.gnome3.overrideScope'
<clever> energizer: so its more suited for non-nixos stuff