<clever>
NIXOS_LUSTRATE is already in nixpkgs, it was written based on how i manually repaired a machine i had converted from gentoo :P
<clever>
so you basically just `nix-build '<nixpkgs/nixos>' -A system -I nixos-config=/etc/nixos/configuration.nix && touch /etc/NIXOS /etc/NIXOS_LUSTRATE && ./result/bin/switch-to-configuration boot`
<clever>
but basically, if /etc/NIXOS_LUSTRATE exists on bootup nixos will move EVERYTHING in / to /old-root/
<clever>
energizer: ive since made some kexec tools that would work more reliably
<clever>
the only time you can `rm -rf /lib /usr /bin` and the machine runs better after its done!
<clever>
and you simply have to purge all traces of the old distro, lol
<clever>
then upon reboot, its nixos
<clever>
energizer: basically, install single-user nix, use nix-build to build nixos, then tell nixos, "its a nixos machine, trust me, just fix the bootloader"
<clever>
energizer: i have also devised ways to install nixos on any linux machine, without any install media
<clever>
nix has now spread to everything i own
<clever>
prior to catching the nix virus, i used gentoo :P
<clever>
Raito_Bezarius: curl doent follow redirects by default
<clever>
Raito_Bezarius: thats the hash of an empty string
<clever>
elvishjerricco: i believe it will default to /tmp as well
<clever>
but if your using single-user nix on a systemd based machine, $TMPDIR might be a tmpfs in /run/user/1000/
<clever>
elvishjerricco: which is normally /tmp
<clever>
elvishjerricco: oops, ^
<clever>
emily: its in $TMPDIR
<clever>
emily: but then things got more fishy, when other systems, with cpu's from a totally different era, had the same problem, at the same offset in ram
<clever>
emily: and thats when the jokes about a bios malware began to come up (was talking to somebody else as i debugged it)
<clever>
emily: and it still failed the ram test...
<clever>
emily: but after juggling between all the ram sticks, i couldnt confirm which was bad, so i did a whole motherboard swap
<clever>
emily: a few years ago, i got a random segfault out of nowhere, and knowing nix hadnt changed any binaries, i suspected bad ram, and memtest confirmed a problem ~256mb into the ram
<clever>
jumper149: it was `nix-repl`, but got renamed during the nix 2.0 changes
<clever>
Ilya_G: probably
<clever>
jumper149: you can also eval that in `nix repl`
<clever>
Ilya_G: you need to include systemd in the buildInputs
<clever>
Raito_Bezarius: a fixed-output derivation must declare upfront what the hash of the result is, and if it fails to meet that claim, the build fails
<clever>
emily: that one is ldd based, not getting the full graph
<clever>
Lumpio-: ahh, one min
<clever>
emily: you would need to use export reference graph and auto-generate a profile, that includes the closure of a binary, to let it access its own libs
<clever>
Lumpio-: what is in the canvas sub-dir?
<clever>
Lumpio-: yeah, look in there for some binary files
<clever>
Lumpio-: but what about the node_modules it showed while the build was running?
<clever>
Ilya_G: did you try adding systemd to the buildInputs ?
<clever>
Ilya_G: what is the error msg?
<clever>
Lumpio-: what do you ee if you actually build it?
<clever>
Lumpio-: but its often simpler to test if you just nix-build, and then ls result/ and confirm if the contents are right
<clever>
Lumpio-: in this case, `nix-shell -p '(import ./.)'` would be enough to do that
<clever>
Lumpio-: you must point nix-shell to another derivation, that has nixcanvas in the buildInputs
<clever>
Lumpio-: `nix-shell default.nix` would give you a shell suitable for building nixcanvas, not for running nixcanvas
<clever>
Lumpio-: does the file actualy not exist? check the nod_modules dir
<clever>
Lumpio-: some packages try to make the install faster, by just shipping pre-compiled binaries to you
<clever>
Henson: systemd itself does have some isolation options, that can basically just dockerize each service
<clever>
wedens[m]: both the 104 and the 56 say network problems
<clever>
56 Failure in receiving network data.
<clever>
wedens[m]: it looks like its just a network error?
<clever>
OS error code 104: Connection reset by peer
<clever>
wedens[m]: does it fail if you retry?
<clever>
wedens[m]: looks fine at a glance
<clever>
wedens[m]: what url is nix trying to fetch?
<clever>
mcwitt: you would need to override the buildCommand and append to it
<clever>
mcwitt: runCommand uses buildCommand, so it just doesnt run any phase
<clever>
Setzer22__2: the stdenv is part of the stdenv
<clever>
yep, in the nixos manual
<clever>
Avaq: because its part of lib, not builtins
<clever>
Avaq: its part of the module framework, which is most used by nixos
<clever>
Avaq: it should be in the nixos manual
<clever>
pingiun: like, each job is turned into a list of steps, and then it sends N steps to each machine
<clever>
pingiun: steps are also split up
<clever>
pingiun: yep
<clever>
pingiun: yeah
<clever>
if i break things, and it stops booting, i can just do a rollback of the profile
<clever>
jakobrs: so when the rpi tries to netboot, it follows that symlink, and loads whatever is in the custom profile
<clever>
evils: the fishy part, is when every single nixos box claimed to have bad ram at the same offset
<clever>
evils: not recently, but i did run into a quirk where it claimed some ram was bad at offset ~256mb, due to gcc hardening flags
<clever>
freeman42x[m]: it usually solves itself after the build is done
<clever>
freeman42x[m]: that can happen when mixing nix versions with your nix.conf version
<clever>
Wulfsta: yeah
<clever>
Wulfsta: wantedby makes your thing start before something else
<clever>
Wulfsta: after just controls the order of starting things, and forces something else to start first
<clever>
Wulfsta: after and wantedby are seperate things
<clever>
Wulfsta: you want enabled = true; and then change wantedBy to control if it auto-starts or not
<clever>
qy[m]: then nix didnt remove it, you never created it to begin with
<clever>
within the same derivation
<clever>
qy[m]: immediately after you build, run ls on the dir where you put the .o file, is it there?
<clever>
qy[m]: what was the full output when building?
<clever>
qy[m]: did you copy it to $out ?
<clever>
qy[m]: can you pastebin the nix expr you have? and the result of building it?
<clever>
,xy qy[m]
<clever>
qy[m]: what exactly are you trying to do?
<clever>
qy[m]: runCommandCC doesnt run the fixupphase
<clever>
qy[m]: add a `set -x` to one of your build phases, and then look at the logs to see which phase/hook is doing it, then change the settings so it doesnt