<clever>
Thra11: nixos will "repair" it the next time you nixos-rebuild or boot
<clever>
Thra11: simplest thing that will persist for a while is to just `rm /etc/nix/machines`
<clever>
,tofu
<clever>
xidica: either nix-prefetch-url --unpack, or
<clever>
gchristensen: try echoing one of l, t, or w to /proc/sysrq-trigger (LTW, incase your fonts arent good)
<clever>
gchristensen: oh, have you seen how to backtrace all kernel threads?
<clever>
DigitalKiwi: some thread sits at 100% cpu usage
<clever>
DigitalKiwi: a kernel bug that happens on some motherboards
<clever>
but, you can use the nixos options to solve that
<clever>
_module.args.secrets = import secrets.nix; will allow you to do { pkgs, config, secrets, ... }: in any module
<clever>
normally, each file would have to load its own copy of secrets.nix
<clever>
coderobe: nodes around the middle of the tree would then be groups of stuff, like laptop.nix, that configures laptop specific stuff, and pulls in both core.nix and wifi.nix
<clever>
coderobe: something that you usually set on every single machine, like creating your user, configuring timezones
<clever>
and at the top, you may want a single node like core.nix, that everything eventually leads to
<clever>
at the bottom, you have a different root node for each machine, which may overlap at some nodes
<clever>
the way to visualize it, is multiple overlapping tree structures
<clever>
so that would have caused infinite recursion
<clever>
also, the value of imports cant depend on any config param
<clever>
vs what you wanted, which would be: imports = [ ./something.nix ]; networking.hostName = "device1";
<clever>
coderobe: your setup will involve just setting imports = [ ./something/device1.nix ];
<clever>
then you put either device1.nix or device2.nix into configuration.nix, and device1.nix itself is what sets the hostname
<clever>
coderobe: and both of those have imports = [ ./common.nix ];
<clever>
coderobe: the simplest way is to create a device1.nix and device2.nix
<clever>
the main difference vs what coderobe did, is that i cant test coderobe's config locally, it will fail due to a missing secrets.nix
<clever>
if its missing, some non-secret dummy values are used, so CI can still pass
<clever>
if secrets.nix (which is in gitignore) exists, that is used
<clever>
xidica: all of my nixos modules will import load-secrets.nix, and use attributes within that to get secret data
<clever>
and i'm currently using 2 cross-compilers at once to do that
<clever>
on this end, ive been focusing on custom rpi firmware
<clever>
i did some armv6/v7 stuff on the nixos community box at one point
<clever>
coderobe: none that i'm aware of
<clever>
but i could hook my pi back up, ive been messsing with it lately, and it wouldnt take much to boot
<clever>
coderobe: somewhat, my hydra is currently building under qemu-user, but coreutils is failing tests, so a large chunk of it isnt built
<clever>
up to a the defined size limit of the image
<clever>
yep
<clever>
oscarvarto: if the disk is already loaded into virtualbox and you want to keep the contents, just use the normal virtualbox tooling to resize the disk, then use gparted within the guest to expand the partition
<clever>
boogiewoogie: this will show you what the bash script is doing
<clever>
superbaloo: when cross-compiling, you must run nix-shell on a cross stdenv, mkShell likely uses a native stdenv
<clever>
dansho: gcc is in the nix-shell by default
2019-11-29
<clever>
lassulus: he is involved, but isnt the primary culprit this time! lol
<clever>
o1lo01ol1o: and it strips the hash off of store paths
<clever>
o1lo01ol1o: the unpackPhase function already handles everything for you, and deals with $src being a tar or zip
<clever>
o1lo01ol1o: that will also undo +x, potentially breaking scripts
<clever>
o1lo01ol1o: when you copy $src, it inherit the read-only perms, you want to use `unpackPhase` to copy it for you, it will land at $sourceRoot
<clever>
gyroninja: why do you need --check?
<clever>
enteee: oops, ^^
<clever>
evanjs: i also think the buildEnv there is pointless
<clever>
but i would instead have used -z, which tests that it has been set to anything
<clever>
-x tests if the file is executable, and its just "vim" so it looks in the current dir
<clever>
it should be -z, not -x
<clever>
so you need EDITOR=/run/current-system/sw/bin/vim
<clever>
Stuck_: the script wrongly assumes that $EDITOR is an absolute path
<clever>
Stuck_: if you `touch vim ; chmod +x vim` does it then work?
<clever>
Stuck_: why is it lowercase? is there other lowercase editor's present?
<clever>
what does it check for when giving an error?
<clever>
Stuck_: is /run/current-system/sw/bin/vimdot a shell script?
<clever>
evanjs: there might have been another process downloading the same tarball
<clever>
immae: yeah, that can add an extra root, but nixos wont include it as an option in grub
<clever>
boogiewoogie: correct, -d just nukes all, and --older-than nukes all older than x, then collects garbage
<clever>
boogiewoogie: there is also `nix-collect-garbage --max-freed 10g` to limit how much it deletes, but that only applies after the roots are somehow cleaned up
<clever>
rasmusm: in this case, just copy my default.nix to your project, run nix-build, and see what happens
<clever>
rasmusm: compilers and libraries should never be installed when using nix
<clever>
,libraries rasmusm
<clever>
it asumes that `make` is enough to build your project
<clever>
rasmusm: you could try dropping my default.nix into your project, and then just nix-build it with zero changes, and see what happens
<clever>
rasmusm: you can use `nix-build --arg nixpkgs '<nixpkgs>'` to bypass the pin on line 1 for testing, and if that rev works, grab the rev from `nix eval nixpkgs.lib.version` and update the pin
<clever>
rasmusm: they can also be accessed under pkgsCross
<clever>
deni: yeah, it assumes you have a config.yaml file, that describes which cardano nodes to deploy, and how they are inter-connected
<clever>
that whole system is being redone now
<clever>
so we often have to `io modify` to re-sync the state, then use bare `nixops deploy`
<clever>
sadly, `io deploy -o foo` maps to `nixops deploy --include foo`, but lacks support for multiple hosts
<clever>
deni: yeah, you use `io deploy` and `io modify` instead
<clever>
iohk/common/NixOps.hs: nixops o c "modify" $ Arg <$> cFiles
<clever>
deni: yep, and its in that same repo
<clever>
that complexity has just been moved into nix/sources.nix, and is now managed by niv
<clever>
it used to be more complex, pre-niv, since it had to deal with the json files and fetchTarball
<clever>
and thats the contents
<clever>
(import ./nix/sources.nix).nixpkgs
<clever>
deni: there is a haskell util that will build `fetch-nixpkgs.nix`, and then run `nixops modify` on that path
<clever>
deni: since darwin cant build linux
<clever>
deni: nixops on single-user darwin, will also automate doing that for you
<clever>
deni: if you have /etc/nix/machines setup, it can also take advantage of those, as it builds the local copy
<clever>
deni: nix-build itself, will then read whatever foo is, which could be a symlink on your machine
<clever>
deni: and every time you try to deploy, it will `nix-build -I nixpkgs=foo <something>`
<clever>
deni: it just bakes the `-I nixpkgs=foo` into the sqlite file
<clever>
for my personal stuff, ive mostly just been installing nixops system wide, using modify -I, and running it from any dir
<clever>
deni: if your using direnv, thats likely the simplest
<clever>
deni: oh, one other option, just change $NIX_PATH before you run any nixops commands!
<clever>
deni: instead, you `nix-build nix/sources.nix -A nixpkgs -o nixpkgs` to replace the symlink nixops looks at
<clever>
deni: one variation to that idea, you can `nixops modify -I nixpkgs=/path/to/some/nixpkgs` and then never modify again
<clever>
and `mymachine/configuration.nix` entirely ignores niv
<clever>
but the version of nixos used by `mymachine` wont obey niv
<clever>
so if you do `hello` anywhere after line 3, it will obey niv
<clever>
modify just changes which nix files it reads
<clever>
every call to `nixops deploy` and `nixops info` will re-read the nix files
<clever>
only when you want to change which deployment files you use, or the -I nixpkgs=
<clever>
deni: there is a thing using scopedImport to mutate <nixpkgs> after its too late to change, but it harms performance
<clever>
deni: i dont think its possible to properly tell nixops to obey niv right now, you would need a shell script that pulls the path out of niv, and does `nixops modify`
<clever>
deni: that line will bake a `-I foo=bar` into the sqlite state, and then `nixops deploy` will always obey that `-I foo=bar` automatically
<clever>
tgt-admin (a perl script) will read the config file, and then use tgtadm (an ELF binary) to remotely modify tgtd (the ELF daemon), and make the state match the config
<clever>
the ELF binary, doesnt even support the tgtd config file, and has no way to persist state
<clever>
jgt: you need to figure out how nixops is copying that file to /usr/bin/nixos-generate-config, and make sure nixops patches in a #!/usr/bin/perl automatically
<clever>
jgt: the kexec stuff makefu just used above, prevents this kind of issue and more
<clever>
if bash is told to run a +x'd file with an invalid #! line, bash just blindly runs itself on the "script"
<clever>
jgt: the #! hasnt been patched to perl, so bash is trying to parse the perl code
<clever>
c2d ~ # umask(0022);
<clever>
-bash: syntax error near unexpected token `0022'
<clever>
jgt: look at line 1 on github
<clever>
jgt: what do you see on line 11?
<clever>
makefu: ah, yeah, i still need to fix that typo
2019-11-28
<clever>
in my case, i also had a non-obvious crash when i switched from slim to lightdm, which cost me an hour of time to recover from
<clever>
edef: not sure, it also depends on which desktop manager your using, and if its that fragile
<clever>
gyroninja: nixos will go out of its way to not restart display-manager, but some things like dbus arent flagged as such, and your desktop manager may crash, which effectively behaves the same as logging out
<clever>
alexarice[m]: but callCabal2nix may be better, to obey the new deps
<clever>
alexarice[m]: with haskell.lib.overrideCabal, yes
<clever>
while evaluating the attribute 'config.services.cardano-exporter.pgpass' at undefined position:
<clever>
so the entire block should be a no-op
<clever>
but the mkIf isnt set as far as i can see
<clever>
the option doesnt exist, because its module wasnt in imports
<clever>
The option `services.byron-proxy' defined in `/nix/store/jn9mvgfaj1j3698j0y6mvz3bcksdq45p-source/nix/nixos/cardano-cluster-service.nix' does not exist.