2020-11-20

<clever> and install them in systemPackages for you
<clever> and then it will filter the .shell of each user, on it being a valid shell
<clever> despite the users.defaultShell being bash
<clever> gchristensen: yeah, the default .shell for users is shadow (aka nologin)
<clever> 426 filter types.shellPackage.check shells;
<clever> 422 systemShells =
<clever> 156 type = types.either types.shellPackage types.path;
<clever> 157 default = pkgs.shadow;
<clever> gchristensen: this looks fishy
<clever> nixos/modules/config/users-groups.nix: filter types.shellPackage.check shells;
<clever> gchristensen: and bam, its now evaling this config!
<clever> [clever@amd-nixos:~/apps/nixpkgs-hasura]$ nix repl nixos --arg configuration '{users.mutableUsers=false; users.users.root.password="hunter2"; boot.loader.grub.device = "nodev"; fileSystems."/".device="/dev/sda1";}'
<clever> nixos/modules/programs/shadow.nix: type = types.either types.path types.shellPackage;
<clever> gchristensen: second one is toShellPath, to convert a package into a path to a binary within it
<clever> gchristensen: first one is for types.shellPackage, which just enforces that it must have a .shellPath, and be a package
<clever> nixos/lib/utils.nix: "/run/current-system/sw${shell.shellPath}"
<clever> leo60228: ahh, no idea there
<clever> gchristensen: but we should focus on what things have a shellPath key
<clever> lib/types.nix: check = x: (package.check x) && (hasAttr "shellPath" x);
<clever> gchristensen: i still dont know how c1a202de051c197675d3ae67dd0d934329309090 is breaking it....
<clever> leo60228: when you import nixpkgs, you pass it a config object
<clever> gchristensen: or your worktree was dirty, and causing the manual to not match
<clever> gchristensen: but you had a massive lead...., how did i almost catch up??
<clever> gchristensen: dang, you beat me by ~40 seconds!
<clever> c1a202de051c197675d3ae67dd0d934329309090 is the first bad commit
<clever> Bisecting: 4 revisions left to test after this (roughly 2 steps)
<clever> gchristensen: strangely, ive not built it once yet
<clever> copying path '/nix/store/j6vs5p2rs0icw3igilx2ryw36jng7d4l-nixos-manual' from 'http://nas.localnet:8081'...
<clever> Bisecting: 7283 revisions left to test after this (roughly 13 steps)
<clever> yeah, my cfg is also bork
<clever> -A vm, has result pointing to the wrong thing
<clever> oh, *doh*
<clever> maybe its -A vm vs -A system?
<clever> *confused*, now my cfg is also broken...
<clever> but my config doesnt enable the bug
<clever> something in your config, is enabling a bug in nixpkgs
<clever> id say its both
<clever> so half the problem is your nixos config
<clever> but its working with my cfg
<clever> it is broken with the above config
<clever> now checking this...
<clever> [clever@amd-nixos:~/apps/nixpkgs-hasura]$ nix-build nixos --arg configuration '{users.mutableUsers=false; users.users.root.password="hunter2";boot.loader.gummiboot.enable = true;fileSystems."/"={ device = "tank/system/junk";fsType = "zfs";options = [ "nodev" "nosuid" "noexec" ];};networking.hostId = "aaaaaaaa";}' -Q
<clever> ive been testing with this
<clever> [clever@amd-nixos:~/apps/nixpkgs-hasura]$ nix-build nixos --arg configuration '{users.mutableUsers=false; users.users.root.password="hunter2";}' -A vm -Q
<clever> gchristensen: so depending on how old/new your nixos-install script is, it may behave differently, when installing the exact same nixpkgs
<clever> gchristensen: ah, thats closer to what i remember, it was changed from directly parsing your config, to parsing the effects of your config
<clever> +if [ -z "$noRootPasswd" ] && [ -x $mountPoint/var/setuid-wrappers/passwd ] && [ -t 0 ]; then
<clever> -if [ -z "$noRootPasswd" ] && [ "$(chroot $mountPoint /run/current-system/sw/bin/sh -l -c "nix-instantiate --eval '<nixpkgs/nixos>' -A config.users.mutableUsers")" = true ] && [ -t 0 ] ; then
<clever> Date: Tue Aug 16 01:15:27 2016 +0100
<clever> commit 806e88c13771e5ec336f3ca14969c5f314482a67
<clever> gchristensen: not on the most recent nixpkgs
<clever> [clever@amd-nixos:~/apps/nixpkgs-hasura]$ ls result/sw/bin/passwd
<clever> ls: cannot access 'result/sw/bin/passwd': No such file or directory
<clever> but i remember there being another way...
<clever> gchristensen: an older version just did the test within the same chunk of shell code
<clever> + nixos-enter --root "$mountPoint" -c '[[ -e /nix/var/nix/profiles/system/sw/bin/passwd ]] && echo "setting root password..." && /nix/var/nix/profiles/system/sw/bin/passwd'
<clever> gchristensen: also, i think its sensitive to nixos-install and nixpkgs coming from the same version
<clever> gchristensen: i'm surprised its been broken for so long....
<clever> gchristensen: what does `ls -l result/sw/bin/passwd` say?
<clever> i'm not sure why it isnt setting it
<clever> pie_: you need to set some env vars for it to find that
<clever> waiting on a nix-build to confirm
<clever> gchristensen: i think i found the problem
<clever> gchristensen: on the machine where you where running nixos-install, check in its /mnt/
<clever> gchristensen: have you checked the actual install with this bug?
<clever> that doesnt make sense
<clever> keep in mind that the absolute symlinks dont work right enless you chroot or nixos-enter
<clever> gchristensen: does the passwd binary exist at the path its testing?
<clever> gchristensen: but if an activation script fails, does nixos-enter return a failure?
<clever> gchristensen: it uses nixos-enter to test for the existance of the passwd binary
<clever> cole-h: no, i read the source :P
<clever> why do i have that memorized??
<clever> pie_: and nix-shell can only ever receive a single derivation as an input
<clever> pie_: -p foo bar, basically translated to `-E 'with import <nixpkgs> {}; stdenv.mkDerivation { name="shell"; buildInputs = [ (foo) (bar) ]; }'
<clever> pie_: you cant mix -p and a file together

2020-11-19

<clever> pumpy: the linux kernel is pretty bloaty in some respects
<clever> cole-h: `-t kernel` will filter on a syslog category, and kernel is the category for dmesg, while `-k` filters based on the transport
<clever> pumpy: because the firewall is in the kernel, and it generally just dumps the fw logs to dmesg
<clever> `journalctl -t kernel -f` will show the latest things in dmesg, much like `dmesg -w` would
<clever> pumpy: try `journalctl -t kernel -f`
<clever> leo60228: its probably documented, but i'm not sure where
<clever> leo60228: it lets you provide a default when a given key isnt found
<clever> > let set = { a=42; }; in a.b or "fallback"

2020-11-18

<clever> dataFile."bash/.keep".text
<clever> pumpy: double-quote the bash/.keep
<clever> `old: ...` defines a function that takes 1 argument, called old
<clever> matthewcroughan_: overrideAttrs expects a function that returns a set

2020-11-16

<clever> and nixos will error out of its not valid, and your nix expr will never see an invalid one
<clever> pingiun: it behaves just like a string or int type, and the config value will just return one of the valid values
<clever> numkem: its hard-coded to 30
<clever> numkem: check the source
<clever> numkem: was more using hydra as a refernece, to figure out which direction Priority goes
<clever> numkem: yeah, thats what it sounds like
<clever> numkem: hydra is at 100 (weakest) so nix will use a proper cache over hydra
<clever> numkem: smaller numbers are stronger priority
<clever> /home/clever/apps/hydra/src/lib/Hydra/Controller/Root.pm: "Priority: 100\n";
<clever> numkem: nix will query all caches in parallel (i think), and then use that priority to decide which to use, when 2 caches have a given path
<clever> numkem: `curl https://cache.nixos.org/nix-cache-info` shows `Priority: 40`
<clever> > pkgs.path + "/nixos/lib"
<clever> fgaz: yeah, then + is what you want, like you showed
<clever> when in #include lines
<clever> it works the same way as <foo> in c/c++
<clever> fgaz: <nixpkgs/nixos/lib>
<clever> aidenholmes: services.syncthing.dataDir
<clever> aidenholmes: services.syncthing.user
<clever> aidenholmes: services.syncthing.enable = true; will set one up for you
<clever> aidenholmes: you just want a systemd service, cron is being horribly abused, lol

2020-11-15

<clever> KarlJoad: you can run `iptables-save` to print the current tables
<clever> KarlJoad: iptables -t filter -I nixos-fw --dport 22 -j nixos-fw-accept, i'm guessing
<clever> KarlJoad: all changes done with the iptables command are lost on shutdown
<clever> KarlJoad: you can always run the iptables command by hand to make changes
<clever> root's channels are the default channels for all other users
<clever> yeah, as root
<clever> hammer: you only have to do it as root, and you must --update for the change to take effect
<clever> hammer: does `nix-channel --list` say that nixos is using the new channel? dod you also `--update` ?
<clever> Ke: yep, just chanle what nixos points to
<clever> shellHook takes a multi-line string, which gets ran by bash in the shell
<clever> cryptomonad: you can also set a shellHook script, which does have access to the buildPhase functions
<clever> cryptomonad: that will give you a shell suitable to build hello, but with one more pkg added to the inputs
<clever> cryptomonad: nix-shell -E 'with import <nixpkgs> {}; hello.overrideAttrs (old: { buildInputs = old.buildInputs ++ [ newpkg ]; })'
<clever> growpotkin: i tend to just read the wrapper, export the vars in the current shell, and then run gdb on the original binary
<clever> growpotkin: strace can work on those bash scripts
<clever> growpotkin: for basic tracing, you can still use strace instead
<clever> growpotkin: the exe symlink always points to the real binary
<clever> growpotkin: you can also run `gdb /proc/123/exe 123` to attach to a process thats already running

2020-11-14

<clever> switch-to-configuration is only in the non sw /nix/store/something-nixos-system/bin/
<clever> Deiru: thats not sw/bin
<clever> Deiru: and add /nix/store/something-nixos-system/sw/bin to $PATH
<clever> Deiru: give it the absolute path, /nix/store/something-nixos-system/sw/bin/bash
<clever> Deiru: bash doesnt find what?
<clever> Deiru: ah, from non-nixos, try just running bash with chroot?
<clever> Deiru: you want nixos-enter to chroot into it and get a usable shell
<clever> spleeter: or for a one-time reset, `touch /etc/NIXOS_LUSTRATE` and reboot

2020-11-13

<clever> {^_^} also triggers it every time a /notice happens, so thats why i dont keep it loaded
<clever> modprobe that, and now `tput bel` makes the speaker on the mobo beep
<clever> ah, thats the one
<clever> /run/current-system/kernel-modules/lib/modules/5.4.64/kernel/drivers/input/misc/pcspkr.ko.xz
<clever> [root@amd-nixos:~]# find -L /run/current-system/kernel-modules/ | grep spkr
<clever> let me check my notes...
<clever> and if your sound driver routes bells into things
<clever> DigitalKiwi: depends on what your terminal emulator is
<clever> pumpy: if the screen is flashing, then the tty isnt filtering it
<clever> kernel issues
<clever> ive found that it rarely beeps for me on nixos
<clever> that should print the magic char, and respect what $TERM says
<clever> pumpy: double-check what `tput bel` says
<clever> kalbasit: username doesnt really mean much when in docker
<clever> kalbasit: id just use mkdir in the entry-point script

2020-11-12

<clever> ,libraries ivan
<clever> drangon: you want `nix-build '<nixpkgs>' -A glibc`
<clever> lordcirth: i tend to use >> when this bot is around
<clever> so they can differ from the main <nixpkgs> used to build nixos itself
<clever> that would let you pick and choose which nixpkgs to use for each program
<clever> yep
<clever> deni: if you use modify to set `-I nixpkgs=`, then all of nixops and the nixos being built, will use that version
<clever> basically, just `(import (sources.nixpkgs) {}).hello`, though you need to be careful if darwin machines get involved
<clever> ,unstable
<clever> if you wanted just a single package from 20.09, you can do the same thing you would do on normal nixos
<clever> so the internal <nixpkgs> used by nixops, will use that version of nixpkgs
<clever> deni: and then all future builds/deploys will act like you had `-I nixpkgs=URL` in the cmd line
<clever> deni: when using something like `nixops modify -I nixpkgs=URL`, that gets baked into the nixops state
<clever> deni: channels are still a thing, and are just branches on the main nixpkgs now
<clever> deni: https://github.com/nixos/nixpkgs-channels/ "DEPRECATED! This is an obsolete, read-only mirror of the NixOS/nixpkgs repository."
<clever> deni: `niv update nixpkgs -b nixos-20.09 -a repo=nixpkgs`
<clever> deni: which repo is it pointing to?
<clever> that will add a line to config.txt for you, which enables the fake kms drivers
<clever> jonge: boot.loader.raspberryPi.firmwareConfig = ''dtoverlay=vc4-fkms-v3d'';
<clever> jonge: ah, so nixos is fully managing /boot, that makes things simple
<clever> jonge: id first need to see your current configuration.nix to know how its booting
<clever> jonge: depends on if nixos is managing config.txt, and where you mounted the fat32 partition
<clever> but you need to first enable kms in config.txt
<clever> jonge: there has been recent work in the kernel to get proper kms support, and i think x11 just detects that automatically on startup
<clever> yep
<clever> st3r4g: nixos-install is a script to do the rebuild in a chroot for you

2020-11-11

<clever> srid: it could be that it only loads the tz offset once on startup, and you have to relog for it to notice you changed offset?
<clever> Henson: let foo = callPackage ./default.nix; in callPackage "${foo}/build.nix" {}
<clever> Henson: import from derivation
<clever> axx: youll need to look at your config and whats under fileSystems., and confirm if those devices are still present and setup right
<clever> axx: did you run nixos-generate-config?
<clever> axx: that can happen if you didnt configure the filesystems properly, and it cant find what you said to mount at /
<clever> axx: so the bootloader config is still pointing to the old build
<clever> axx: it sounds like you didnt configure the bootloader correctly

2020-11-10

<clever> eyJhb: `ncdu -x /`
<clever> jbal[m]: yes
<clever> cant think of any documents that i know of
<clever> because who would be crazy enough to allow a different libc in every single app? :P
<clever> nss wants to be able to dynamically shove a lib into any app on the system, and they expect only one libc
<clever> catern: its due to compatability problems between the libc nix choose, and how nss wants to dynamically load libs into the app for avahi's .local
<clever> heh
<clever> pittma: already played with that locally a while back
<clever> 91 #extraModulePackages = [ config.boot.kernelPackages.v4l2loopback ];

2020-11-09

<clever> pushqrdx: have a look at /nix/var/nix/profiles/per-user/root/channels/nixos/nixos/modules/config/console.nix, what is it doing with console.keyMap?
<clever> pushqrdx: are you sure you commented it out? can you pastebin the new configuration.nix?
<clever> Cadey: only put those into the imports list when using a nixops deployment.nix file

2020-11-08

<clever> asbachb: yeah
<clever> asbachb: there is also nix-prefetch-url to download it, hash it, and put it in /nix/store/
<clever> asbachb: when using pkgs.fetchurl, you can just use the plain sha256 of the tar.gz
<clever> > :p map (x: x*10) [ 1 2 3 ]
<clever> > map (x: x*10) [ 1 2 3 ]
<clever> map

2020-11-07

<clever> and if you later want to put things into nixpkgs, you can copy app.nix over, and just fill in the right src=
<clever> exactly
<clever> then you just nix-shell with no args
<clever> default.nix feeds packages to app.nix
<clever> other way around
<clever> its usually better to have an app.nix, and then a default.nix in the root dir, that does callPackage, with the right version of nixpkgs
<clever> so the ./default.nix will always look at ~/default.nix
<clever> pushqrdx: nope, relative paths in a .nix file, are relative to where that .nix file lives
<clever> bot*
<clever> it is a bit
<clever> and if you put it into default.nix, it will be the default file nix-shell and nix-build load
<clever> so you dont have to remember the whole thing
<clever> but you can also just put that string into a .nix file, and run nix-shell on it
<clever> nix-shell -E 'with import <nixpkgs> {}; callPackage ./default.nix {}'
<clever> if you want to load the default.nix as-is, you need to do what {^_^} said
<clever> it will try to open a shell with every single package at once
<clever> if you run `nix-shell '<nixpkgs>'`, then it ignores default.nix
<clever> the default.nix i gave above, loads wingpanel.nix, and supplies all of the packages it wants
<clever> nix-shell just loads either shell.nix or default.nix
<clever> 2020-11-07 12:39:44 < clever> pushqrdx: long answer, copy that default.nix to wingpanel.nix, then make a default.nix containing: with import <nixpkgs> {}; callPackage ./wingpanel.nix {}
<clever> that means you didnt follow the directions
<clever> what was the error?
<clever> so you can just `nix-shell`
<clever> the default.nix loads <nixpkgs> for you
<clever> it feeds it the packages that are defined in <nixpkgs>
<clever> pushqrdx: correct, you must use callPackage to fill those in
<clever> ,callPackage
<clever> supply it with all of the packages it wants, which are listed on the 1st line
<clever> pushqrdx: long answer, copy that default.nix to wingpanel.nix, then make a default.nix containing: with import <nixpkgs> {}; callPackage ./wingpanel.nix {}
<clever> pushqrdx: short answer, `nix-shell '<nixpkgs>' -A pantheon.wingpanel`
<clever> pkgs/desktops/pantheon/default.nix: wingpanel = callPackage ./desktop/wingpanel { };
<clever> that default.nix has to be loaded with callPackage, neither nix-build nor nix-shell can run it
<clever> what arguments?
<clever> and how did you run nix-shell?
<clever> what are the contents of the default.nix and shell.nix?
<clever> pushqrdx: run nix-shell on it, instead of nix-build

2020-11-06

<clever> and the client still thinks its encrypted
<clever> numkem: then you can packet-sniff the traffic from the nginx->minio
<clever> numkem: one trick you could maybe do, setup an nginx server, to do https->http proxy_pass
<clever> alexfmpe: you want to add it to the buildInputs instead
<clever> alexfmpe: nativeBuildInputs are only for tools ran at build time, not libraries/headers used in the build
<clever> not really clear why its hanging
<clever> bqv: 9 reads returned 2805
<clever> that will capture what nix-daemon is up to when you try the build
<clever> bqv: find the pid of the main nix-daemon (the one without a pid in its args list), and run `strace -f -p PID` on it, then repeat `nix-build '<nixpkgs>' -A hello` as non-root
<clever> when ran as root, it wont go thru the unix socket, and we can see the true hang
<clever> bqv: its most likely the unix socket talking to nix-daemon, ctrl+c that, pkill all nix-daemon's, and then repeat as root
<clever> bqv: what does `ls -l /proc/75805/fd/3` report?
<clever> bqv: and the parent is waiting on a futex owned by the child i believe
<clever> bqv: that thread did a blocking read on fd3, and never returned
<clever> bqv: at the end, we can see that the main pid (75805) forked out a thread with an id of 78281
<clever> bqv: run `strace -f nix-build '<nixpkgs>' -A hello`, what is the last thing it did before deadlocking?
<clever> bqv: if you didnt kill off the old nix-daemons from before the deadlock, those can still be the problem
<clever> and in this case, each directory cross-compiles to a different cpu, so i just `.${CPU}.${DIR}`
<clever> there is a default.nix in the root of the project, doing things like `callPackage ./firmware {}`
<clever> cinimod: usually, i just pull in a mkDerivation from elsehwere, in my shell.nix
<clever> [clever@amd-nixos:~/apps/rpi/rpi-open-firmware]$ cat firmware/shell.nix
<clever> (import ../. {}).vc4.firmware
<clever> cinimod: ive always considered mkShell as a useless function, you can do the exact same things with stdenv.mkDerivation
<clever> bqv: you can `--option min-free 1234` to lower the limit more
<clever> cinimod: and you get the exact environment nix-build would have been using
<clever> cinimod: which is exactly what nix-shell is for, you point it to a derivation that would have normally built it for you
<clever> cinimod: you likely dont even need shell.nix, try just running nix-shell on the same attr you would nix-build
<clever> cinimod: also, setting both propagatedBuildInputs and buildInputs at the same time isnt useful
<clever> cinimod: there is a gccStdenv, which already did the override
<clever> cinimod: are you building on linux or darwin?
<clever> i havent investigated why yet
<clever> you need to `killall -9 nix-daemon` then manually `nix-collect-garbage --max-freed 1g` as root, until your over the limit
<clever> ive had a few deadlocks too
<clever> its fighting over the gc-lock
<clever> then its not the sqlite
<clever> bqv: are you below the min-free?
<clever> bqv: do you have min-free set?
<clever> bqv: which process is stuck?
<clever> sometimes you can just `killall nix-daemon` and it will recover
<clever> bqv: try running `strace -p PID` on each one, and see what its up to
<clever> now check if one of them is busy doing something
<clever> bqv: ls -l /proc/*/fd/* | grep db.sqlite, and investigate each proc with the file open
<clever> with what error?
<clever> and to act as input when building the bootloader config
<clever> thibm: the main use of the generations, is so nix-collect-garbage knows what to keep
<clever> thibm: then the bootloader will continue to boot whatever the old config said to boot
<clever> bqv: the new config said to mount vda, and you where missing vda, so crash
<clever> bqv: this also explains why switch broke things so badly
<clever> qemu-vm.nix has a lot of mkForce commands to ignore your cfg, and then make it work under qemu
<clever> i dont think /bin/fsck can fix that :P
<clever> bqv: so its expecting you to boot under qemu
<clever> bqv: that looks like you included qemu-vm.nix in your imports
<clever> thibm: ah, it might be `--set -A ...`
<clever> bad?
<clever> nix-repl> :b config.system.build.bootStage1.fsInfo
<clever> nix-repl> config.system.build.bootStage1.fsInfo
<clever> «derivation /nix/store/gz69pyzfsbdvzfzc2fm08s5sgjdmddb2-initrd-fsinfo.drv»
<clever> [root@amd-nixos:~]# nix repl '<nixpkgs/nixos>'
<clever> which has an fsInfo file
<clever> 275 fsInfo =
<clever> such as bootStage1