<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: $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>
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>
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>
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>
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>
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