<clever>
you somehow lost the context on those tar files
<clever>
while yours just keeps going
<clever>
so mine fails the moment it does something bad
<clever>
which forces you to declare inputs properly
<clever>
i have sandboxing enabled
2018-04-08
<clever>
how is it getting these paths...
<clever>
builder for '/nix/store/0givz1pbazsywgi5388rsd3qa72v78hy-node-hello-1.0.0-modules.drv' failed with exit code 15
<clever>
let me have a closer look
<clever>
not really
<clever>
and thats how nix builds the build-time dependency tree
<clever>
and when you pass that string into any new builtins.derivation call, it collects all of the context, and uses that to know what the inputs are
<clever>
and if you do any string manipulation with that magic string, the context spreads like an infection, and all strings based on it have the same context
<clever>
any time you call builtins.derivation {a set} in nix, it will generate a magic string, that points to the output, and it has some extra "context" attached to the string, to say which derivations it depends on
<clever>
do you know how the string context works?
<clever>
i think part of the problem here, is that the context is too invisible
<clever>
so you must never use readFile on something that refers to store paths
<clever>
readFile has the sameproblem
<clever>
not with nix
<clever>
you must pass the whole json file to the derivation, and parse it at build-time
<clever>
that will have the same problem
<clever>
yeah, no signs of context tracking there
<clever>
i think
<clever>
so you can never read a json file with storepaths
<clever>
fromJSON doesnt support dependency tracking
<clever>
it must also be a build-time dependency, for it to even look for that hash
<clever>
let me check something...
<clever>
how are you passing those values into this derivation?
<clever>
so nix doesnt consider them as inputs anymore
<clever>
but you somehow broke the dependency tracking on the strings
<clever>
inputs can be in any attribute
<clever>
this derivation doesnt depend on its inputs, so the build fails here
<clever>
tar: /nix/store/if4n5zak610pxxd6j43i4kv0zha6xsya-node-ansi-styles-3.2.1.tgz: Cannot open: No such file or directory
<clever>
building '/nix/store/0givz1pbazsywgi5388rsd3qa72v78hy-node-hello-1.0.0-modules.drv'...
<clever>
try doing it in its own derivation with just writeText to make things simpler
<clever>
it should depend on the things its refering to
<clever>
kreisys: to start with, use pkgs.writeText to just make a file that contains a single string from selfAndNoDev, and then `nix-store -qR` that result
<clever>
yeah, i'm starting to get lost, lol :P
<clever>
kreisys: where does mapPackages come from?
<clever>
kreisys: which file generates nix.json?
<clever>
the linux kernel has its fair share of curse words :P
<clever>
can you gist it?
<clever>
what is the derivation that made that file?
<clever>
you have to pass the whole path to the json into a derivation, which reads it without nix
<clever>
also, i think buildins.readFile looses the dependency info
<clever>
run nix-store -qR on the output json and see what it says
<clever>
if you are given storepaths as inputs, and include those in the output, it should know you depend on them
<clever>
lol
<clever>
which in your case, would produce several gig
<clever>
yarn2nix avoids circular issues by just doing the entire `npm install` inside a single derivation
<clever>
i also got yarn2nix tweaked to not rebuild things on every minor change
<clever>
yarn2nix works by generating a .nix file, and then importing it using import-from-derivtion
<clever>
the other users wont have those paths, and it will fail
<clever>
and it wont work to commit anything with storepaths
<clever>
you need to use just raw string manip to make the nix file
<clever>
yeah
<clever>
kreisys: or just use nix to pass the derivations into it directly?
<clever>
kreisys: what if you generate a nix file, not a json file?
<clever>
ow!
<clever>
kreisys: how big is your finished node_modules?
<clever>
kreisys: i recently worked on a project using yarn2nix, and it works great
<clever>
kreisys: why are you giving it a storepath in json?
<clever>
it wont run under windows, but most tools that can read an exe can work with it
<clever>
infinisil: if you then use dd to extract a section of the bios, starting at offset 0x47EBAC, you get a perfectly valid .exe file, which can be read by tools like objdump
<clever>
its like ELF for linux or mach-o for darwin
<clever>
it doesnt use the windows api's, but it uses the PE file format
<clever>
infinisil: yeah, efi is entirely based around that file format
<clever>
if your not, its a paper weight!
<clever>
if your lucky, it works
<clever>
and then reflash the chip with flashrom
<clever>
infinisil: so you could just insert another into the list
<clever>
infinisil: uefi firmware is much more standardized, its basically a giant array of .exe files, which get initialized on bootup, before it looks for the boot media
<clever>
infinisil: and then my efi system partition can be ext3 on nvme, lol
<clever>
infinisil: in theory, i could unpack the bios, insert an extra PE32/PE64 binary that provides drivers for ext3 or nvme, and then repack the bios
<clever>
infinisil: there is, but this problem was during partition creation
<clever>
lejonet: yeah
<clever>
tos9: your welcome :)
<clever>
and without the p, the partition creation tool saw /dev/nvme0n1p11 and created partition 11, then failed to find 1
<clever>
but nvme, is /dev/nvme0n1 and /dev/nvme0n1p1
<clever>
so /dev/sda + 1 is /dev/sda1
<clever>
the script assumes ${device}${partition} for partitions, and ${device} for the device
<clever>
infinisil: that also broke my justdoit script
<clever>
the uefi firmware has been modified to support that
<clever>
apple also tends to use HPFS+ for their /boot's
<clever>
and also, just guess, and ls to see if it looks nixos-y
<clever>
tos9: blkid /dev/sd*
<clever>
Lisanna: and cmake if the project is a bit more complex
<clever>
tos9: you still need to mount your rootfs to /mnt, your store to /mnt/nix and your boot to /mnt/boot, the same as when you initially installed
<clever>
so there is no point in checking the size of things
<clever>
the makefile assumes its being used inside nix, and that the compiler is sane