2020-03-06

<clever> lovesegfault: nixos will run install-openpi.sh, any time it wants to update the bootloader config
<clever> lovesegfault: and this then configures a custom bootloader in nixos
<clever> lovesegfault: in nixos.nix: nixpkgs.crossSystem.system = "armv7l-linux"; configures nixops to cross-compile to arm
<clever> lovesegfault: there are 2 key parts to making nixops do that
<clever> NemesisD: this configures everything needed to run plex automatically on boot, and by keeping it to its own file, i can easily remove media-center.nix from imports to turn it off, or add it to more systems in the future
<clever> NemesisD: anything that is using the module system, which would be nixos and home-manager mainly
<clever> NemesisD: but you can also start branching again after the trunk (like roots), and have certain role-specific stuff, like media-center.nix, that is only in imports on one machine, but nicely isolates the functions
<clever> then non-gui systems, skip gui-system.nix and go directly to core.nix
<clever> NemesisD: i always make a tree of modules, start at a leaf like laptop.nix or desktop.nix, then work my way up the branches, both of those do imports = [ ./gui-system.nix ]; for example, which then does imports = [ ./core.nix ];
<clever> NemesisD: it gives nixos a list of modules, that all have the same format as configuration.nix
<clever> lovesegfault: `nixops deploy -d rpi` will build the rpi firmware, cross-build the entire nixos, deploy it to the pi, and update the custom firmware in /boot/
<clever> lovesegfault: here is my most recent/crazy thing with nixops: https://github.com/librerpi/rpi-open-firmware/blob/master/nixops.nix
<clever> NemesisD: instead of using a symlink, make a configuration.nix with only { imports = [ /path/to/leaf.nix ]; }
<clever> mlatus: its a proxying mirror, so if it lacks something, it will just fetch it on the spot, so it can be your only cache
<clever> mlatus: that is pretty much exactly what https://github.com/cleverca22/cachecache/ is designed for
<clever> mlatus: then your down to luck, do both caches actually have the same thing, or does only one have what you want?
<clever> lovesegfault: it can, just use the "none" type (same as my router and nas) but with the ip of 127.0.0.1
<clever> mlatus: each cache advertises its own priority, and nix will sort them by that
<clever> Priority: 40
<clever> [root@amd-nixos:~]# curl -s https://cache.nixos.org/nix-cache-info | grep Prio
<clever> lovesegfault: and if i dont like an update, --rollback
<clever> lovesegfault: i run the laptop from nixos-unstable, and i only nix-channel --update when i want it to update
<clever> and nix-channel controls the laptop
<clever> lovesegfault: the laptop is managed by nixos-rebuild, but also hosts the nixops state for the router/nas
<clever> mlatus: nope
<clever> mlatus: you have to scroll up further
<clever> mlatus: if your using anything more then `-j1` it may print the error, and then keep going and build more things
<clever> cole-h: it was a bug with mime info, and only occurs if you have multiple things in your systemPackages
<clever> cole-h: i thought i reported it, but i dont see it on github
<clever> cole-h: i reported one issue, but had to turn repeat back off to even use the system
<clever> and if the 2 builds didnt produce identical outputs, the build fails
<clever> if you set `repeat = 1` in nix.conf, or build with `--option repeat 1` then nix will repeat every build 1 extra time
<clever> cole-h: then i discovered several bugs in nixos itself, that blocks nixos-rebuild
<clever> cole-h: i had turned on repeat in my nix.conf, while developing some software
<clever> lovesegfault: you can just install nixpkgs.niv i believe
<clever> lovesegfault: :D
<clever> salty_spaghetti: why does your test need internet?
<clever> lovesegfault: kernelPatches must be a list of these sets
<clever> > pkgs.kernelPatches.bridge_stp_helper
<clever> softinio[m]: what does the search output?
<clever> softinio[m]: that channel may not have nodejs 12
<clever> softinio[m]: which channel are you on?
<clever> softinio[m]: what attribute are you using?
<clever> lovesegfault: and it will internally respect that, for every `nixops deploy`
<clever> lovesegfault: but, if you run this, nixops will remember that `-I nixpkgs=foo` flag
<clever> # nixops modify -d house deployments/house.nix -I nixpkgs=https://github.com/nixos/nixpkgs/archive/dae9cf6106d.tar.gz
<clever> lovesegfault: nixops itself still uses <nixpkgs> to get the nixos that is going to eval your config
<clever> lovesegfault: that changes it
<clever> lovesegfault: $NIX_PATH will respect the pre-existing channels, by default
<clever> lovesegfault: nope
<clever> lovesegfault: and activate does misc stuff that has to be done on boot or switch
<clever> lovesegfault: test/switch, will update several symlinks, restart systemd services, and run activate
<clever> lovesegfault: so you can run `switch-to-configuration boot` to make it the default at next boot
<clever> lovesegfault: switch-to-configuration takes most of the args nixos-rebuild takes, including test, switch, boot
<clever> lovesegfault: what exactly are you trying to do?
<clever> lovesegfault: buildEnv

2020-03-05

<clever> iceypoi: nixos-rebuild will use <nixpkgs> i believe, and the default $NIX_PATH maps that to the nixos channel on root
<clever> { config, pkgs, ... }: accepts 2, and ignores the rest
<clever> the ... means it ignores any arguments not named
<clever> lovesegfault: defines a function, that accepts a set, and ignores all the arguments
<clever> lovesegfault: at, i see the trace on line 2 now, you would need to put that into the set on line 12, and then eval the attr its within
<clever> lovesegfault: replace <home-manager with (sources.home-manager + "/home-manager/home-manager.nix")
<clever> lovesegfault: `unset NIX_PATH` and stop using -I nixpkgs=, and then every non-pinned thing will reveal itself
<clever> lovesegfault: have a look at niv
<clever> lovesegfault: then add a `-I nixpkgs=` ?
<clever> lovesegfault: what about `NIX_PATH=notning nix-build -A foucault` ?
<clever> lovesegfault: how was the default.nix loaded?
<clever> lovesegfault: that would imply your not even respecting -I nixpkgs=
<clever> lovesegfault: which is none of the above...
<clever> lovesegfault: and if you cd into each nixpkgs dir, and `git rev-parse HEAD` what do you get?
<clever> lovesegfault: and what did -q --binding return, for each?
<clever> lovesegfault: and what is -I nixpkgs= set to?
<clever> lovesegfault: how does the file reference nixos?
<clever> lovesegfault: can you run `nix-store -q --binding revision` on the 2 drv files from line 59 and 60?
<clever> lovesegfault: line 78, the version of nixos differs
<clever> lovesegfault: try getting it from an older nixpkgs, or directly from the repo
<clever> lovesegfault: broken?
<clever> lovesegfault: then use nix-diff to compare the 2 drv files, how do they differ?
<clever> lovesegfault: then use nix-copy-closure to copy one .drv to the other machine, so they are both on one box
<clever> lovesegfault: use nix-instantiate to get the .drv file for the build, on both machines
<clever> johnw: you can likely just ignore trustedBinaryCaches entirely, only set binaryCaches
<clever> which nix-daemon will still trust to be safe
<clever> nix.trustedBinaryCaches is a list of non-default caches, which a user can opt-into, using `--option substituters ...`
<clever> nix.binaryCaches is the default list of caches for all users, which is trusted automatically
<clever> johnw: the other one
<clever> LnL: so any store paths shipped on the ISO can be used directly
<clever> LnL: i think the nixos installer does something very similar, to bind-mount the host /nix into the guest, and then use the host store as a cache
<clever> which is a read-only URI
<clever> LnL: i think substituters is now a list of URI's, and https://hydra.angeldsis.com just means use the narinfo protocol over https
<clever> johnw: try using `local?root=/tmp/cache` as the URI in both cases then
<clever> LnL: that might work also, with `local?root=/tmp/cache` in both nix copy and substituters
<clever> LnL: and i have used exactly such a URI as my cache before, when checking to see if it helps IFD stuff
<clever> $ cat /etc/nix/nix.conf | grep tmp
<clever> substituters = http://nas.localnet:8081/ file:///tmp/cache https://hydra.angeldsis.com
<clever> johnw: that creates a cache that is identical in layout to a binary cache
<clever> [clever@amd-nixos:~]$ nix copy --to file:///tmp/cache-test /nix/store/ghz4a2vzvy4ad8lw2f23ahijzyg7933n-bluez-5.50
<clever> johnw: if you use the right URI, yes
<clever> contrun[m]: gcc is actually a shell script (from cc-wrapper) that will read $NIX_CFLAGS_COMPILE and call the real gcc

2020-03-04

<clever> yeah
<clever> atemu12[m]: /tmp and /nix/store also tend to be different FS's, so hardlinking often fails
<clever> atemu12[m]: nix nukes all permissions and mtimes when the build finishes
<clever> and i forget to remove it
<clever> corvid: i tend to just put it there out of habbit, even when nix cant be interactive
<clever> atemu12[m]: i tend to use either `cp -vi` or `mv -vi`
<clever> corvid: depends on if your running it yourself from somewhere, or if you want standard tooling to add it to $PATH
<clever> it could be a file or symlink
<clever> it makes it more obvious when this happens
<clever> thats one reason i'm paranoid and always `mv -vi`
<clever> so include/foo.h lands at $out/foo.h

2020-03-03

<clever> xa0[m]: thats why its better to do it in a pure manner from nix
<clever> xa0[m]: ${/var/lib/foo} will copy the entire dir to the store
<clever> xa0[m]: ${/var/lib/foo.txt} would read the current value, at the time you ran nix-build
<clever> xa0[m]: the config file should be in the nix store
<clever> xa0[m]: why do you need to?
<clever> ive not done much python in nix, so i dont know the correct way to fix it
<clever> energizer`: its trying to do network during a build, which isnt allowed
<clever> mjrosenb: for that, run -qR on the result symlink from nix-build
<clever> mjrosenb: run `nix-store -qR` on the .drv file
<clever> mjrosenb: runtime or buildtime deps?
<clever> li_matrix: there is also `nix-store --query --binding out` which can query any single field of the drv
<clever> mjrosenb: .env.overrideAttrs(old: { buildInputs = old.buildInputs ++ [ pkgs.hello ]; })

2020-03-02

<clever> tA_: if you boot the installer, mount everything back to the right place, and edit the config, you can re-run nixos-install to update the install
<clever> boot.initrd.luks.devices = [ { name = "root"; device = "/dev/nvme0n1p2"; preLVM = true; }
<clever> tA_: is the luks properly configured in hardware-configuration.nix ?
<clever> evanjs: but nixos now supports reusing the luks pw on multiple devices, so you can do zfs on luks + swap on luks
<clever> evanjs: previously, you needed swap+zfs on lvm on luks, to not have to enter 2 passwords at login
<clever> samueldr: but zfs on lvm on luks confuses it
<clever> samueldr: it only detects that if your doing something simple like ext4 on luks, and i think ext4 on lvm on luks

2020-03-01

<clever> excelsiora: i tend to use `git branch -a`
<clever> oops, yeah
<clever> excelsiora: requirements.nix returns a set, propagatedBuildInputs wants a list of derivations
<clever> excelsiora: so it also has a use for generating nix files automatically
<clever> excelsiora: partially, hnix is a library to parse nix code into an AST, and turn the AST back into nix code
<clever> excelsiora: hnix is a project to re-implement it in haskell
<clever> genesis: $sourceRoot is usually relative to $NIX_BUILD_TOP
<clever> genesis: your already in $sourceRoot, try what i just gave
<clever> genesis: so you want `install -Dm644 icons/$i-48d24.png $out/share/icons/hicolor/48x48/apps`
<clever> genesis: after unpackPhase is ran, you get cd'd into $sourceRoot
<clever> genesis: postInstall should still be cd'd into the build dir, so you can just use the files in the working dir
<clever> genesis: all phases run in a single bash session, and can access any vars the previous ones setup
<clever> erhandsome: you can just ctrl+c the install and try again
<clever> erhandsome: if you fix the network, it should then download things
<clever> erhandsome: yeah
<clever> i think its a glibc bug, but i havent seen it in a while
<clever> its happened to make ~3 times, and to git once
<clever> emily: i have also seen make forget about a dead child on the floor, and the entire thing grinds to a halt, waiting for a SIGCHLD from the corpse thats already dead
<clever> emily: i did always wonder how recursive make managed that
<clever> and `ghc -j48` uses threads, not processes
<clever> ah, yeah
<clever> and yeah, a sudden spike can still murder the machine
<clever> not clear
<clever> Baughn: nix does `-j48 -l48`, so if the load avg goes over 48, make stops spawning children
<clever> gchristensen: and it would repeat your keystroke on each window
<clever> gchristensen: i think it was called cssh, it was a util to ssh into N machines at once
<clever> gchristensen: that reminds me
<clever> gchristensen: :O

2020-02-29

<clever> energizer`: so its much simpler to manage a complex chain of transformations to the data
<clever> energizer`: nix deals with compiling the tools if the source ever changes, and re-generating intermediate data if any of the tools ever change
<clever> energizer`: ive done that as well, processing multi-gig files down into a sqlite db and then into output stuff
<clever> energizer`: for nix, you want to use pkgs.fetchurl to download the large data file, then it wont have to hash it each time, and youll get much better performance
<clever> energizer`: git doesnt deal with large files very well, even worse if your modifying the file repeatedly
<clever> fionera: because git bisect is meant to find where it broke, and if its already fixed, it fails
<clever> fionera: when i replay the same bisect, it tells me this
<clever> The merge base 93aabab7605c21f5962df2dffa7fee9ac17ba848 is bad.
<clever> This means the bug has been fixed between 93aabab7605c21f5962df2dffa7fee9ac17ba848 and [ce9f1aaa39ee2a5b76a9c9580c859a74de65ead5].
<clever> can you screenshot `git bisect view` ?
<clever> fionera: what does `git bisect log` say?
<clever> fionera: have you given it both a good and a bad rev?
<clever> energizer`: the version of nixpkgs you use, is typically set by niv, not $NIX_PATH
<clever> cole-h: just like #include <something.h> and `-I /foo` would work in gcc
<clever> cole-h: yep
<clever> cole-h: you can also have a /foo in NIX_PATH, and then a /foo/something
<clever> cinimod_: line 36, you want myHaskellPackages
<clever> cinimod_: line 25-29, you want ps.random and friends
<clever> cinimod_: line 11, you forgot to callCabal2nix the new random
<clever> cinimod_: thats breaking the overlay
<clever> cinimod_: you still need to remove the 2nd nixpkgs on line 21
<clever> cinimod_: it will have no effect on cabal2nix, and you must use pkgs.myHaskellPackages to be affected
<clever> cinimod_: yeah, myHaskellPackages = ....
<clever> cinimod_: you can also do that by just not overriding pkgs.haskellPackages, rename the attr on line 3, and cabal2nix wont notice your overlay entirely
<clever> cinimod_: you want to override the main pkgs.cabal2nix, to sever the link and make hsuper.callCabal2nix not depend on random
<clever> cinimod_: on line 21, random is getting its deps from that 2nd nixpkgs, and ignoring this overlay
<clever> getting late here, i should head off to bed, goodnight
<clever> it created an audio source in pulseaudio, and auto-added a loopback, feeding that source back into the primary sink (the alsa device for the laptop)
<clever> lovesegfault: its an option i found while digging around in blueman-manager
<clever> lovesegfault: i once configured it to emulate a bluetooth speaker, so the phone was then able to connect, and play audio out of the laptop speakers
<clever> lovesegfault: there might be a foo.service.d directory
<clever> lovesegfault: cat result/etc/systemd/system/foo.service
<clever> as long as nothing depends on it
<clever> worldofpeace: you could also just systemd.services.systemd-udev-settle.wantedBy = mkForce []; i believe
<clever> fix the module to accept what you want as a proper option!
<clever> yes, its ugly as heck :P
<clever> and the empty one is a signal to systemd, to ignore the original copy
<clever> lovesegfault: if you set it to a list, you will add multiple ExecStart='s to the .service file, and the above would cause it to have 3 entries, the original, an empty, and the new one
<clever> lovesegfault: due to how .serviceConfig is an option and .ExecStart is technically not a nixos option, you cant use things like mkForce on it
<clever> energizer`: youll need to update the kernel to make it work
<clever> energizer`: it could be that user namespacing was just always on, and didnt have a seperate CLONE_NEWUSER flag at the time
<clever> energizer`: 2.6 is damn old :P
<clever> or they are disabled somehow
<clever> energizer`: your kernel may also be too old to support user namespaces, what does `uname -a` report?
<clever> cole-h: another module, that has its own nixos options
<clever> energizer`: add `strace -e unshare,fork -f` before the nix-user-chroot command, what does it output?
<clever> energizer`: and what happens when you `unshare --user --pid echo YES` ?
<clever> cole-h: not sure
<clever> mlatus_: you can use pkgs.extend to add more overlays to nixpkgs at any time, and then pull any package out, and it will rebuild whatever got stuck between A&C
<clever> mlatus_: (pkgs.extend (self: super: { C = ...; }).A
<clever> energizer`: have you read the docs for nix-user-chroot to see how its meant to be used?
<clever> energizer`: unpack the tarball used by the nix install.sh script
<clever> energizer`: because you likely need an entire nix store in nix/store
<clever> energizer`: that looks more like it just cant find the directory "nix"
<clever> energizer`: ah, i see it in the paste
<clever> energizer`: what error happens if you try to use namespacing?
<clever> energizer`: does /proc/sys/kernel/unprivileged_userns_clone exist?
<clever> energizer`: yeah, the source gets copied into /nix/store when built, and the whole store is world-readable
<clever> energizer`: thats an extra requirement that debian tossed in, defeating the main use of namespaces
<clever> and more privacy over sources in /nix/store/
<clever> energizer`: the only real advantage is that you dont need root to co-operate with your love of nix :P
<clever> energizer`: nix-daemon must also be running as root in that case, to peek at the env vars of every user
<clever> energizer`: so while a nix-shell is open, its deps cant be GC'd
<clever> energizer`: correct, but the env vars of every running process are also roots
<clever> energizer`: the result symlink made by nix-build, and your nix-env generations, are all gc roots
<clever> energizer`: thats what GC roots are for
<clever> and it still worked for lastpass alone, once i told it to go away
<clever> i suspect windows was trying to automate what you just did
<clever> i routed it to the vm, and then windows complained it doesnt have enough disk space to enable it, lol
<clever> i booted a win10 vm a few hours ago, and lastpass wanted the yubikey due to new 2fa config
<clever> but for obvious security reasons, if anybody gets ahold of that secret, they can dup your key, so you generally want to delete it afterwards
<clever> so you have to generate the private outside of the key, and import it into multiple kesy
<clever> the stuff you can transfer, are private keys used for the "something different", but i dont think it lets you export a private
<clever> the other login form, that requires more interaction and JS, does something different
<clever> and the auth is just based on the serial# and the signature being valid
<clever> and you can then verify the signature and extract the serial#
<clever> from what i understand, the string is just a signed serial#
<clever> and now i can verify you are you you claim to be in the future, if i write that down
<clever> lovesegfault: then i can see the serial# of your unit!
<clever> lovesegfault: now, if i paste that into https://demo.yubico.com/otp/verify ...
<clever> lovesegfault: yubikey power!
<clever> so instead, it loads all the modules into nscd, and proxy's the request thru that
<clever> combined, that makes it a nightmare to keep the nss modules compatible
<clever> but with nix involved, each process might have a different arch (32bit, 64bit), it might have a different glibc, and maybe a different gcc version
<clever> under normal linux, the nss modules get dlopen()'d into each process doing dns, by glibc

2020-02-28

<clever> pikajude: impureEnvVars i think only works for fixed-output derivations, so it wouldnt work there either
<clever> but a lot of the more unique modules and packages
<clever> evanjs: ive not memorized the source of every single package :P
<clever> JonReed: i sorta memorized a large chunk of nixpkgs....
<clever> JonReed: ah, but you want 9p not fuse, one min...
<clever> JonReed: this configures nixos to mount a fuse based fs on boot
<clever> JonReed: one minute
<clever> evanjs: you also need to wait for the device to appear, read stage-1-init.sh in nixpkgs
<clever> evanjs: you need to either use the special devtmpfs to auto-create nodes, or run udev to create them

2020-02-27

<clever> evanjs: the nix files have the full support of the module stuff in nixos, so i didnt need to link things in anymore
<clever> evanjs: its only in the manual config
<clever> evanjs: had that exact same problem mounting the rpi firmware from my custom kernel
<clever> so sd.ko is also required, in my case
<clever> evanjs: this also tells you the driver responsible for a given block dev
<clever> lrwxrwxrwx 1 root root 0 Feb 27 15:24 /sys/block/sda/device/driver -> ../../../../../../../bus/scsi/drivers/sd
<clever> [root@amd-nixos:~]# ls -l /sys/block/sda/device/driver
<clever> evanjs: several of these modules
<clever> scsi_mod 225280 4 sd_mod,scsi_transport_iscsi,libata,sr_mod
<clever> evanjs: ahci just enables it to speak to it over scsi
<clever> evanjs: you also need the scsi block device support
<clever> evanjs: which transport is qemu using?
<clever> ,callPackage
<clever> also, qemu may use virtio by default
<clever> Kernel driver in use: ahci
<clever> 07:00.0 SATA controller: ASMedia Technology Inc. ASM1062 Serial ATA Controller (rev 01) (prog-if 01 [AHCI 1.0])
<clever> evanjs: the driver in use, for the line following your sata controller
<clever> evanjs: also if your in qemu, try /dev/ttyS0 and link the serial to stdio
<clever> evanjs: just dump the whole thing to the screen?
<clever> evanjs: for lspci, check `lspci -v` and look under `Kernel driver in use`
<clever> evanjs: dmesg would have shown the device anyways, what about `lspci` and `lsblk` ?
<clever> havent found the exact cause yet
<clever> fresheyeball: ive been getting the same error in a nix-shell build of nix
<clever> which it then closed, before trying to stat itself
<clever> evanjs: then io should work fine, and yeah 3 is a bit special with ls, thats the fd dir itself
<clever> karantan: this is where it helps to have seperate shell.nix and default.nix files, shell.nix contains test-environment, default.nix contains myScript
<clever> karantan: its myScript that you want in systemPackages, not test-environment
<clever> karantan: but test-environment itself, cant never be built
<clever> karantan: nix-shell is creating a shell suitable for "building" test-environment (aka, using myScript)
<clever> karantan: you just want `in myScript` and nothing else
<clever> karantan: you probably want to delete lines 5, 6, 9, and most of 8
<clever> karantan: your derivation in https://pastebin.com/F0SJDd3H lacks a src to actually build
<clever> enamax: and confirm its using the new path
<clever> enamax: you can also use `nixos-rebuild test` and `modinfo` to check if the new module is present, before you make it permanent
<clever> enamax: thats what extraModulePackages does
<clever> enamax: ah, so youll need to somehow pick the ena from outside, rather then the one within linux
<clever> evanjs: also double-check where 0,1,2 lead, in `ls -l /proc/self/fd/`
<clever> evanjs: `exec > /dev/console` will change stdout for the entire shell script, so you dont have to redir everything
<clever> enamax: try running realpath on the ena.ko.gz, and see which storepath it came from
<clever> enamax: should be, but cant hurt to do things well, incase any other overlays are at play
<clever> enamax: line 22 should be config.boot.kernelPackages.ena, and 3-12 should be on 19
<clever> enamax: how is this getting a reference to ena?
<clever> enamax: boot.extraModulePackages = [ ena ];
<clever> enamax: just read that path, within the nixpkgs repo
<clever> enamax: what did you set extraModulePackages to?