<clever>
jakob_rs: its deep in the source for `class LocalStore` i think
<clever>
infinite recursion
<clever>
pkgs depends on config.nixpkgs.overlays
<clever>
config= depends on pkgs.lib.mkIf
<clever>
because nix needs to know what your config= on line 11 returns, before it knows what the value of pkgs is
<clever>
and then `with lib;`
<clever>
ldlework: try using `{ config, pkgs, lib, ... }:`
<clever>
thats not infinite recursion
<clever>
anonymous function at /nix/store/lcnb1m4f4h3zm8v3b287l5sysqwh33w9-nixos-20.09pre226148.0f5ce2fac0c/nixos/pkgs/build-support/build-fhs-userenv/env.nix:3:1 called with unexpected argument 'version', at /nix/store/lcnb1m4f4h3zm8v3b287l5sysqwh33w9-nixos-20.09pre226148.0f5ce2fac0c/nixos/pkgs/build-support/build-fhs-userenv/default.nix:8:9
<clever>
reading the trace now
<clever>
ah
<clever>
ldlework: can you pastebin that code?
<clever>
ldlework: where does this file then get into imports?
<clever>
ldlework: does it fail the same way if you use a local path in imports?
<clever>
remote nix*
<clever>
but also tells that remote ssh, to act on /mnt/nix/store/
<clever>
so `ssh://root@target?remote-store=local?root=/mnt` tells the local nix to talk to a remote nix over ssh
<clever>
the ssh://user@host style, also supports taking the same uri as remote-store=
<clever>
i'm not sure if its been fully documented, but the above gist shows a bunch of examples
<clever>
?root= will tell it to prefix paths before it opens them
<clever>
local means that nix should just open /nix/store directly, instead of asking nix-daemon via a unix socket
<clever>
hpfr[m]: but when keys collide, it will just overwrite, not merge
<clever>
hpfr[m]: lib.recursiveUpdate or lib.mkMerge depending on context
2020-06-04
<clever>
Henson: yeah
<clever>
Henson: youll need to modify what was adding it
<clever>
Henson: you cant map over a nixos option like that, you need to set it without depending on the current value
<clever>
nix-env sometimes eats error messages
<clever>
dkjii: try `nix-build -E '....'` ?
<clever>
dkjii: its possible that that had no impact on the build, so nix didnt need to do anything
<clever>
dkjii: the nix sandbox heavily enforces what a package can see while building, to ensure it builds the same way on any machine
<clever>
dkjii: any compile errors that would occur would have happened on the cache as well, but you can build with `--option substituters ""` to ignore the cache anyways
<clever>
if everything is working properly, your just wasting cpu time to produce the identical result
<clever>
dkjii: why?
<clever>
dkjii: if any inputs to a build change, it will be rebuilt, no need to force a rebuild from source
<clever>
dkjii: nix cant use distcc, but has its own remote builder logic
<clever>
dkjii: why do you want to build from source?
<clever>
dkjii: add it inside the {} for configuration=
<clever>
fps: -I takes the same thing that goes into $NIX_PATH
<clever>
ritchan: zfs uses hostId to figure out if a pool is being imported on 2 machines at once (via network blocks), vs improper reboot (same hostid)
<clever>
ritchan: you only get kernel modules if you set boot.supportedFilesystems = [ "zfs" ];
<clever>
fragamus_: `nix repl '<emu>'` and use tab completion to figure out the attr name
<clever>
fragamus_: -iA stack
<clever>
,-A
<clever>
,-iA
<clever>
imports is just a list of those
<clever>
almost anywhere you can put a module, you can have either a naked module (function or set), or a path to a file containing the same
<clever>
evanjs: you could change line 22 into a module, configuration = { imports = [ ./configuration.nix ]; other.config = true; };
<clever>
evanjs: and how are you building it?
<clever>
evanjs: what you can do with --arg, depends on what the default.nix can accept, so i would have to see that file first
<clever>
evanjs: that is basically the only thing --arg/--argstr can do
<clever>
ohhaimark[m]: and you already have one commented out on 75
<clever>
ohhaimark[m]: i believe home-manager's pkgs tree is isolated, and respects the nixpkgs.config.allowUnfree in the home-manager modules
<clever>
ohhaimark[m]: and in which file did you install dropbox?
<clever>
ohhaimark[m]: which package is causing the error?
<clever>
evanjs: and thats the same as just `imports = [ path ]; virtualbox.params = value; }`
<clever>
energizer: only if your running nixos-install inside docker or another namespace
<clever>
energizer: i'm out of ideas then
<clever>
energizer: try ext4 just to see if it behaves any different
<clever>
energizer: try ext4?
<clever>
energizer: i think its filesystem related, not physical
<clever>
or try the install ISO, or kexec
<clever>
wait for somebody else to know more
<clever>
i wouldnt expect formatting to fix it
<clever>
check lsof
<clever>
not sure what else to do then
<clever>
and did `nix copy` get ran first?
<clever>
what cmd gave that error?
<clever>
and `nix copy` will copy from host to chroot
<clever>
the `nix build` builds it on the host store
<clever>
its just the output path from building the derivation
<clever>
energizer: the product that `nix build` created
<clever>
local?root= basically makes nix chroot
<clever>
ah
<clever>
?
<clever>
yeah
<clever>
you would have to build with the new names it will have, when you plan for it to boot
<clever>
the initrd may have trouble finding things
<clever>
energizer: maybe, it also depends on if the values for things like fileSystems."/".device are going to still be correct after you do that
<clever>
it shouldnt have to build anything, and complete much more quickly
<clever>
and once thats done, try the nixos-install again
<clever>
energizer: then when its done, `nix copy --to local?root=/mnt/dev/fsroot/ /nix/store/product` to copy it to the new hdd
<clever>
energizer: that should build the target, in the host /nix/store
<clever>
energizer: to work around it, first try doing `nix build -f '<nixpkgs/nixos>' system --arg configuration /mnt/dev/fsroot/etc/nixos/configuration.nix`
<clever>
energizer: thats weird
<clever>
energizer: can you pastebin the entire output, including the cmd you ran?
<clever>
energizer: was nixos-install ran as root?
<clever>
dkjii: ah, why are you trying to build nix from source?
<clever>
dkjii: and then run autoreconfPhase i think it was
<clever>
dkjii: nix-shell -p autoreconfHook
<clever>
dkjii: add autoreconfHook to nativeBuildInputs and it will do that step for you
<clever>
dkjii: anything you dont update, keeps using the old glibc, that it was last built against
<clever>
dkjii: but only firefox will use the new glibc
<clever>
jgerhardt: id do it as an attribute, libpcap_bluez = libpcap.override { withBluez = true; };
2020-06-03
<clever>
infinisil: oh, thats new
<clever>
you can get it there with nix-instantiate or nix-copy-closure
<clever>
lovesegfault: you need the .drv on your local machine first
<clever>
lovesegfault: run `nix-store -r` on it
<clever>
ph88^: build-time is whatever you passed to the derivation, runtime is whatever your output still contains the paths to
<clever>
energizer: yeah, ssh also pokes a hole automatically as well
<clever>
energizer: INPUT says packets have to first go thru nixos-fw, and nixos-fw then defines the primary rules, ultimately ending in `-j nixos-fw-log-refuse`
<clever>
energizer: nixos-fw-accept is a special chain used to accept packets, and things only go there if another rule in INPUT related chains decides to allow it
<clever>
energizer: i find it much easier to read the output of `iptables-save`
<clever>
jlv[m]: ^
<clever>
> pkgs.steam-run
<clever>
yeah, thats basically to handle the FHS layer, to make it look more like debian
<clever>
that also makes it very difficult to diagnose compatability problems
<clever>
jlv[m]: some games have some DRM in place, which makes it very difficult to launch outside of steam
2020-06-02
<clever>
betaboon: if you flag it as readonly in the tgt config, that cant happen
<clever>
betaboon: thats because it assumes that each client will be writing, and they will corrupt the fs
<clever>
joehh1: look up disabledModules in the nixos manual
<clever>
so they cant clone anything
<clever>
also, activation scripts run before the network is up
2020-06-01
<clever>
hazel: watch how it reacts when you try to use some ram though
<clever>
hazel: `arcstat -v` explains what each field is
<clever>
hazel: run this, and you can see zfs stats
<clever>
gchristensen: ive tried removing that, and making one systemd service per block-dev, but its got some bugs, and your wireguard changes kind of fit the same style i was aiming for
<clever>
betaboon: instead, tgt-admin (a perl script) will parse the config file, and run tgtadm to change the daemon state to match the config
<clever>
betaboon: but neither tgtadm not tgtd support its own config file!
<clever>
betaboon: tgt is a bit of a confusing package, tgtadm is the c binary to control tgtd (the daemon)