<clever>
energizer: but once you format the disk, there is no hope of it booting on its own until you complete the nixos-install without any mistakes
<clever>
energizer: kexec itself is relatively low risk, it rarely crashes, and even if you lock yourself out, the default config will reboot the machine at the end of the hour, restoring the original OS
<clever>
morgrimm: then just search nixpkgs for that name
<clever>
morgrimm: if you run ls -lh on the firmware from an old generation, youll get the derivation name
<clever>
morgrimm: if you know which file you need, you can also add it to hardware.firmware with the right pkg
<clever>
morgrimm: try one of these options like enableAllFirmware and see what happens
<clever>
spinlock[m]: the nixos module for the app should be doing it
<clever>
hexa-: usually, anything that is offering some kind of service via dbus
<clever>
yeah
<clever>
exarkun: what does `nix-store --verify --check-contents` say?
<clever>
exarkun: every time you run nix-build, it will hash ./. and copy it into /nix/store/
<clever>
exarkun: everything points towards you just having not ran nix-build...
<clever>
exarkun: in postCheck in your expr, try to cat the .py file, do you see the right version?
<clever>
exarkun: are the tests actually being ran by nix?
<clever>
exarkun: try adding postUnpack = "exit 1"; to the derivation, then build it with --keep-failed, and diff the src in the /tmp dir to the original
<clever>
exarkun: how are you checking that its older?
<clever>
monokrome: the motherboard also came with hdmi out onboard, so its also acting as a plex frontend
<clever>
monokrome: my nas is just a random x86 motherboard in a case, with a heap of sata disks in it
<clever>
monokrome: if using a backend, you basically just set `deployment.targetEnv = "ec2";` and then give nixops some keys (many ways), and your done
<clever>
monokrome: but if you use another backend like ec2, it can launch machines for you
<clever>
monokrome: this is the "none" backend that uses pre-existing hw
<clever>
if you want to keep things simple, just treat nas.nix like a configuration.nix file, and your done
<clever>
monokrome: nixops will ssh into every machine (IP's on lines 12 and 16), and force it to run a new build of nixos, which comes from nas.nix and router.nix
<clever>
monokrome: run `nixops create -d house deployments/house.nix` to make a deployment, then `nixops deploy -d house` to deploy it
<clever>
monokrome: so it will always double in disk usage on the first deploy, and likely need a reboot to update the kernel
<clever>
monokrome: my problem with the official nixos AMI, is that it is never the same nixpkgs rev that i am deploying with nixops
<clever>
monokrome: slightly modified to get ssh keys from the aws api
<clever>
monokrome: for aws, i was thinking you just generate an AMI with the same kernel/initrd and grub
<clever>
monokrome: in this case, the kexec tar contains the entire os, and a single shell command will reboot into it
<clever>
monokrome: it could be modified to do that
<clever>
monokrome: the entire config is baked into the tar file
<clever>
monokrome: my kexec script also includes the justdoit script, which can install your entire os in 1 command, once configured right
<clever>
monokrome: kexec doesnt need kvm
<clever>
monokrome: yeah
<clever>
monokrome: kexec can be tricky to use when the server cant dhcp, and if you make any mistakes during the install, it can leave the server unable to boot
<clever>
monokrome: and once your in that nixos ramdisk, you can just format the disk and install as normal
<clever>
monokrome: correct
<clever>
monokrome: but with kexec, you just upload a tar, and run 2 shell commands, and boom, its now running nixos from a ramdisk
<clever>
ex-parrot: simplest option then is to edit the module
<clever>
dxtr: use a different sha256
<clever>
dxtr: if you claim the sha256 is the same, it will believe you, and not bother to re-download the file
<clever>
dxtr: how did it fail?
<clever>
cole-h: :D
<clever>
,tofu
<clever>
dxtr: simplest option is to just have nix generate it
2020-05-08
<clever>
T0pH4t: you can then use cp on that to put it at a more normal place, or just set an env var to it
<clever>
T0pH4t: so youll wind up with a `/nix/store/hash-foo.bin` in the string where you did that
<clever>
T0pH4t: when you do `${./foo.bin}` in a nix expr, nix will copy it to /nix/store for you, and replace it with a storepath
<clever>
but requireFile will at least give a nice error if you dont
<clever>
the last 2 options require you to manually download it before the build
<clever>
T0pH4t: or perhaps use pkgs.requireFile to give an error msg saying to dl it manually, like oracle java does
<clever>
T0pH4t: the only other option, is to pre-download the thing, and then just do `cp ${./foo.bin} foo.bin` in your nix expression
<clever>
with world-read permissions
<clever>
T0pH4t: for a private bucket, you would need to use a custom fixed-output derivation, and your keys would wind up in /nix/store/
<clever>
Raito_Bezarius: shouldnt be any issue
<clever>
Raito_Bezarius: yeah
<clever>
Raito_Bezarius: you would need to enable the initrd ssh stuff
<clever>
T0pH4t: only the inputs you declared in the nix file can be used and nothing else
<clever>
T0pH4t: nix also chroot's the whole build
<clever>
T0pH4t: it ensures that the package rebuilds properly when inputs change
<clever>
T0pH4t: the correct solution is to have nix download things for you, using things like pkgs.fetchurl, and to copy it to the right place
<clever>
T0pH4t: nix always disables all network access at build time
<clever>
Raito_Bezarius: possibly
<clever>
Raito_Bezarius: get your stdenv from pkgsi686Linux too
<clever>
then everything will be 32bit
<clever>
Raito_Bezarius: use pkgs.pkgsi686Linux instead of plain pkgs
<clever>
Raito_Bezarius: you need to use a 32bit stdenv and kgs tree
<clever>
energizer: you can just use import and one of the fetch functions
<clever>
Raito_Bezarius: thats a 64bit ld-linux
<clever>
Raito_Bezarius: what does file say about the binary?
<clever>
simpson: that would fetch a tar, import the default.nix within it, then shove it into the buildInputs of another dummy drv, and shell into that dummy
<clever>
Henson: either irc or a PR, check `git blame` to see who has been touching most of it
<clever>
Henson: but having it in nixpkgs natively would be nicer for others
<clever>
Henson: you could use mkMerge, mkBefore, and mkAfter, to add your own nixo-fw-output, and flush it before all other rules, then append after others
<clever>
Henson: nothing in OUTPUT for mine, i only filter incoming
2020-05-07
<clever>
Henson: i do use nixos-fw for my stuff
<clever>
Raito_Bezarius: justdoit is in the same dir as a kexec script, which gives you a kernel from nixpkgs
<clever>
armin: i dont think /sys allows chgrp
<clever>
then you can just `hello` directly
<clever>
charukiewicz: `nix repl '<nixpkgs>'`
<clever>
charukiewicz: or stdenv.lib
<clever>
charukiewicz: pkgs.lib
2020-05-06
<clever>
cab404[m]: ah, its probably the home-manager in imports, then the docs want to refer to it
<clever>
maralorn: its just a key name, doesnt do anything special
<clever>
> { _ = "foo"; }
<clever>
cab404[m]: and does the error go away if you comment out the 2 custom options?
<clever>
cab404[m]: what is line 89 of /nix/store/rfk5j99kh4ny0jfi0m88yapv3pbw19nr-nixos-20.03.1619.ab3adfe1c76/nixos/nixos/lib/make-options-doc/default.nix ?
<clever>
infinisil: no real way, because the passthru can contain anything that cant be serialized, and the drv path must always be a hash of its own contents
<clever>
manveru: i had patched rust/default.nix to rename it back, but i can try undoing that...
<clever>
niksnut: having some issues with rust cross-compiling, do you know about the area where it gets x86_64-pc-windows-gnu and x86_64-w64-windows-gnu mixed up?
<clever>
DamienCassou: so pw prompts just silently "hang" because they opened in an ssh window on another box
<clever>
DamienCassou: it then asks for the pw prompt on the ssh session, even if i'm back at the local keyboard
<clever>
DamienCassou: ive also found that the gnupg module in nixos is much worse, it re-binds gpg to the "active" tty every time i ssh into the machine
<clever>
tobi_: i think you want .override, not .overrideAttrs
<clever>
turion: it also moves that build dir, breaking more things
<clever>
turion: it would mess with permissions and also require the entire build dir (potentially several gig) to be put into the store and kept long-term
<clever>
nix-build wipes that dir every time
<clever>
but if your reusing the build dir, with the state from before, you dont have to re-run it
<clever>
turion: the other 2 should work fine though
<clever>
turion: installPhase will never work right in nix-shell, since you lack access to /nix/store
<clever>
turion: what does the buildPhase actually do? what is the 1st line of it?
<clever>
turion: thats why i recommend using genericBuild with the phases var
<clever>
turion: if buildPhase hasnt been overridden, you need to use bare buildPhase instead
<clever>
turion: yeah, you usually only need to configure once
<clever>
cole-h: default.nix should just contain: with import (builtins.fetchTarball ...) {}; callPackage ./app.nix {}
<clever>
cole-h: and i try to fetchTarball nixpkgs, so it is reproducable
<clever>
cole-h: i tend to add a default.nix that loads program.nix in that case