<clever>
mishac: objects/symlinks, is a set of derivations to copy into the /nix/store of the tar (including deps) and add to the registration-path file, and create symlinks (within the tar) so you can figure out the hash
<clever>
mishac: so, sources/targets is just a list of things to blindly copy, from source to target, and target is a path that will exist within the tar
<clever>
mishac: and the closure info, is based purely on the list of objects you give it
<clever>
mishac: you want object to contain that expr, and symlink to be a quoted path, and it has to go into storeContents, not contents
<clever>
mishac: that
<clever>
2019-10-05 23:54:58 < clever> mishac: you would want to use (import <nixpkgs> {}).pkgsCross.armv7l-hf-multiplatform.nix in the expr that is building the tar
<clever>
mishac: its just blindly copying a single directory, not a nix build and the things it depends on
<clever>
mishac: yeah, theres the problem, you must put a nix expr in line 8
<clever>
mishac: something is not right with that, can you pastebin the nix file you used to build it?
<clever>
mishac: can you pastebin the output of `tar -tvf /path/to/tar` ?
<clever>
mishac: what files are in the tar?
<clever>
jersey[m]: nope, i just happened to find the failure in docker
<clever>
jersey[m]: thats a recent bug i discovered in docker, that i still need to report
<clever>
jersey[m]: can you paste the entire output of nix-shell, including the failure?
<clever>
jersey[m]: that command works perfectly here
<clever>
jersey[m]: can you paste the full command you used?
<clever>
jersey[m]: correct
<clever>
so, you must declare the hash of the output, that ensures you always produce the same source
<clever>
also, network access is impure, so you could do naughty things that make a different build, defying the hash
<clever>
evils: so a fixed-output drv puts a halt to that, and says "this tar always has this hash", and it wont care what the hash of curl is
<clever>
evils: and you dont want to re-fetch (and re-build) EVERYTHING, when curl changes
<clever>
evils: nix hashes all inputs, but a drv to fetch something, has curl as an input
<clever>
80gig mechanical sata in my router, it runs an entire hydra instance
<clever>
but my router is a dual-socket rack-mount machine, with several gig of ECC ram....
<clever>
and there is #nixos-on-your-router
<clever>
evils: i run full nixos on my router...
<clever>
you can always do nix-build on arch or ubuntu :P
<clever>
i basically just dont support other distros :P
<clever>
evils: put it into its own derivation, with the 3 attrs i mentioned before
<clever>
correct
<clever>
the src = fetchFromGitHub is also a derivation, that is downloading source
<clever>
evils: the script doing the download needs to be in a seperate derivation from the compile
<clever>
so thats not really possible
<clever>
evils: each derivation is hashed seperately
<clever>
philr: already on unstable here
<clever>
and looks like i'm outa luck too
<clever>
Sep 30 15:34:05 amd-nixos kernel: amdgpu 0000:01:00.0: kfd not supported on this ASIC
<clever>
and it wont use the "wrong" build from another machine, on your current one
<clever>
philr: but if you specify which gpu in the nix config, it can build for that gpu, even on the "wrong" machine
<clever>
philr: that kind of thing makes it imposible to reproduce the builds, or use build slaves
<clever>
philr: yuck!
<clever>
philr: what was the solution?
<clever>
but that did
<clever>
mishac: also, @clever doesnt light up on this end
<clever>
mishac: you would want to use (import <nixpkgs> {}).pkgsCross.armv7l-hf-multiplatform.nix in the expr that is building the tar
<clever>
mishac: then use nix-env -i /nix/store/hash-nix, to install nix on the arm device
<clever>
mishac: make a tar, that contains the arm build of nix, then unpack that tar on the arm device, and run `nix-store --load-db < /nix/store/nix-path-registration`
<clever>
so it turns things into failures you can clearly see
<clever>
philr: nix-build already enforces not touching things you shouldnt touch
<clever>
philr: can be hard to know exactly what its doing (when it shouldnt), without running the whole thing under strace, and going over 1000's of lines of logs
<clever>
philr: nix-shell --pure doesnt stop you from peeking into /sys
<clever>
you should investigate why its trying to run lsmod, and tell it to stop
<clever>
philr: ah, nix-daemon is already correctly blocking you from using lsmod
<clever>
philr: what error did it have with kmod?
<clever>
philr: sounds like it has multiple problems
<clever>
but you probably shouldnt be adding kmod to the inputs
<clever>
,locate bin/lsmod
<clever>
philr: it may also just be failing because of lsmod not being in PATH
<clever>
philr: and the error is complaining that gfx000 is not valid
<clever>
philr: i think line 170 is saying what the valid targets are
<clever>
philr: and cmake lists
<clever>
philr: can you pastebin or link the nix file?
<clever>
philr: you must specify a flag like -amdgpu-target to tell it what gpu you want
<clever>
philr: its trying to dynamically query what kernel modules you have, which is horid-impure!
<clever>
and this site shows the tests each channel waits for
<clever>
,howoldis notgne2
<clever>
notgne2: when all of the tests on master pass, nixos-unstable updates
<clever>
notgne2: that will only load whatever the unstable channel is poining to
<clever>
in my example, a local clone, where i would have to first `git checkout master && git pull`
<clever>
you can then use whatever you want to fetch "master"
<clever>
notgne2: if you want something more dynamic, nix-env -iA foo.nim will use whatever nixpkgs this file loads
<clever>
and if it exists, it will execute ~/.xsession (causing the chosen session manager to not activate)
<clever>
it will then source ~/.xprofile
<clever>
pittma: nixos will first run the code in services.xserver.displayManager.sessionCommands (which lets you do that stuff from configuration.nix)
<clever>
erba: when you import <nixpkgs>, you can pass it the contents of a config.nix, import <nixpkgs> { config = { android_sdk.accept_license = true; }; }
<clever>
evils: then you can just do "source ${./script.sh}" or similar, maybe write it to create an oui.txt in the current dir, then "source ${./script.sh} ; mv oui.txt $out"
<clever>
so you can put the shell script right into the nix file
<clever>
evils: the string at the end, "curl http://example.com > $out" is a chunk of bash code
<clever>
and you can then just shove that into a let block, and get a path back out
<clever>
in either case, nix will tell you the right hash, if it is wrong
<clever>
if outputHashMode == "recursive", then $out can be anything (file, directory, symlink), and outputHash is the hash of the output from `nix-store --dump $out`
<clever>
if outputHashMode == "flat", then $out must be a single file, and outputHash is the raw hash of that file
<clever>
the output must have a hash of outputHash, which is of type outputHashAlgo
<clever>
evils: any derivation that has those 3 attributes, gains network access
<clever>
> hello.src.outputHashAlgo
<clever>
> hello.src.outputHashMode
<clever>
> hello.src.outputHash
<clever>
evils: > hello.src.outputHash
<clever>
evils: and if the script fails to meet that declaration, the build fails
<clever>
evils: you can, but you must declare what the hash of the product will be
<clever>
astrall33: for the impure way, just `nix-shell -p nodejs` and then continue as usual
<clever>
you probably still want nix to build the sqlite+lua thing, and then provide an environment that has a finished copy of it
<clever>
but you can then just point HOME to any dir you make
<clever>
and by default, $HOME=/homeless-shelter (which doesnt exist)
<clever>
it builds in a unique dir under /tmp, that is mapped to /build
<clever>
nix-build can run things with a private $HOME easily
<clever>
gyroninja: sounds like you should be using nix-build to build this
<clever>
gyroninja: and how do you give it a config file?
<clever>
and then echo $FOO
<clever>
gyroninja: so you can just add FOO = "${sqlite.dev}/include/";
<clever>
gyroninja: and every attr you pass to mkShell becomes an env var
<clever>
if you put that expression into the shell.nix file, nix will give you the path
<clever>
> "${sqlite.dev}/include/"
<clever>
youll need to somehow tell luarocks to use ${sqlite.dev}/include/ then
<clever>
gyroninja: what happens if you add pkgconfig to the buildInputs?
<clever>
it should be under ${sqlite.dev}/include/
<clever>
but if its parsing the file itself, you need to tell it where to look
<clever>
if luarocks is running gcc, then it will find the header
<clever>
why does luarocks need the header file?
<clever>
dont look for headers, just try to use them
<clever>
if you just blindly #include <sqlite3.h>, gcc should still find it
<clever>
ah, nix will never have headers in those locations
<clever>
i would expect that to work, how is luarocks searching for sqlite headers?
<clever>
gyroninja: are you using nix-shell?
<clever>
gyroninja: in what context are you using that?
<clever>
gyroninja: can you paste your code?
<clever>
gyroninja: you can likely skip that map in most cases, since those will cast to strings for oyu
<clever>
> :p map (x: "${x}") zlib.all
<clever>
> map (x: "${x}") zlib.all
<clever>
> zlib.all
<clever>
> zlib.outputs
<clever>
no idea
<clever>
which may be why most projects ship their own copy, in the src
<clever>
so you need to host a copy somewhere, and fetchurl that copy
<clever>
but, its not versioned, so nix will break every time they update it
<clever>
evils: all network is disabled by default, so you must clearly define (in nix) what you want fetched from the network, and defining those details has an impact on the hash
<clever>
evils: ensures that everything you can use, will impact the hash of your drv
<clever>
evils: nix will disable the network, so you cant download it yourself
<clever>
evils: pkgs.fetchurl can be used to download it
<clever>
a command
<clever>
pulseaudio breaks horribly if you dont set those things right
<clever>
`sudo -u $SUDO_USER foo` can do most of that for you, but only in a child proc, not the current process
<clever>
you loose those when dropping back to non-root
<clever>
freeman42x: also, there are some special groups that you are in, but /etc/group says you shouldnt be in
<clever>
have fun!
<clever>
this is why i omited that fact before :P
<clever>
so it will take effect at different times in different threads
<clever>
but glibc emulates it being process wide
<clever>
and setuid is per-thread
<clever>
then setgroups, setgid, and setuid
<clever>
but now you have to lookup that user in /etc/passwd, then lookup his groups in /etc/group
<clever>
freeman42x: $SUDO_USER tells you what user ran sudo
<clever>
[root@amd-nixos:~]# env | grep clever
<clever>
SUDO_USER=clever
<clever>
freeman42x: or just chown configuration.nix
<clever>
freeman42x: it may be best to just use imports, to point nixos towards a file you can edit
<clever>
freeman42x: but that wont try to edit the file as root
<clever>
freeman42x: that will run nixos-rebuild as root
<clever>
freeman42x: then you didnt prefix the right thing with sudo
<clever>
leo_: line 13 and 17 of the file i just linked