<clever>
palo: try removing the .env at the end, and pointing nix-build at it, what does that do?
<clever>
ebzzry: run execsnoop as root before you start the install
<clever>
palo: can you gist the bitwig.nix file?
<clever>
yeah, that is a strange error
<clever>
ebzzry: what error did it fail with?
<clever>
ebzzry: is nix-daemon running?
<clever>
ebzzry: and make sure nix-daemon isnt running
<clever>
dhess: yeah
<clever>
i feel the only point for overlays, is when you want to use overrides from other users, and you cant bother to compose them into a single file
<clever>
personally, i only use config.nix
<clever>
yeah, the only time to use self is when foo refers to foo, and you have to break the recursion
<clever>
so when you do foo = self.foo.override ...; it wont become recursive
<clever>
and now that i think of it, self doesnt include the current overlay
<clever>
yeah
<clever>
and self is just previous + current
<clever>
i think super is all overlays after as well
<clever>
dhess: except packages are in both sets, and super is after all overlays have been applied
<clever>
pjan_: can you post both of your files into a gist?
<clever>
palo: that gives you a shell suitable for building bitwig, not running it
<clever>
the file will need to return a set of packages
<clever>
/foo + ("/" + "bar") == /foo/bar
<clever>
/foo + "/" + "bar" == /foobar
<clever>
the path type also handles the + operator in weird ways
<clever>
phdoerfler: dont quote the path
<clever>
its relative to the nix file that contains that path
<clever>
so / + "/" + "foo" fails
<clever>
and / + "/foo/" == /foo, it strips the trailing slash
<clever>
and also, toString path behaves very differently from "${path}"
<clever>
but if its already in the store, it just leaves the path as-is
<clever>
phdoerfler: in nix, paths have their own special type, and if you try to treat a path as a string, it will automatically copy the file into the nix store
<clever>
phdoerfler: instead, use src = ./blabla.tar.gz;
<clever>
phdoerfler: the mount namespace blocks all access to the filesystem
<clever>
samueldr: do you have a simple release.nix with a few jobs?
<clever>
samueldr: it starts at whatever commit the branch is on, when the eval started
<clever>
michalrus: make a default.nix that contains that string
<clever>
nixos doesnt support ldconfig
<clever>
ryantrinkle: thats normally solved by ldconfig and its cache
<clever>
try that on the old and new path
<clever>
du -hc --max=0 $(nix-store -qR PATH)
<clever>
by at least a gig
<clever>
the closure size should also be reduced
<clever>
nice
<clever>
ryantrinkle: run haskell.lib.justStaticExecutables over the derivation to make it static
<clever>
ryantrinkle: try using static haskell linking
<clever>
loke: it does that, by running the fucntion on line 63 twice, passing it a different set of pkgs
<clever>
loke: i believe targetPkgs is for executables, and multiPkgs is for libraries, it will install 32bit and 64bit versions of everything in multiPkgs
<clever>
loke: it might be safer to run it in a chrootenv sandbox like steam
<clever>
loke: yeah, android has its own package-manager, to download things at runtime, very anti-nix
<clever>
loke: its also possible that android is setting LD_LIBRARY_PATH again with its own values
<clever>
loke: dang
<clever>
the system handled it surprisingly well, watch was the only casualty, and it otherwise ran normally, lol
<clever>
yegortimoshenko: i happened to have a `watch -d df -h` open in screen, and it broke the instant i ran a chrootenv as root, took longer to figure out why though
<clever>
but you cant generate deps without compiling
<clever>
i think -M and TH only works if you actually compile the file, and the TH specially reports what its reading
<clever>
so you cant auto-generate a dep tree
<clever>
Sonarpulse: ive also found that `ghc -M` cant report files being read by TH
<clever>
Sonarpulse: that would also solve it
<clever>
Sonarpulse: one thing i have thought about, is how `import Foo` needs access to both the x86 version (for TH) and the arm version (for the final result), and that requires ghc building everything twice
<clever>
dhess: in theory, an x86->arm ghc could do the same with qemu-user-arm
<clever>
dhess: in ghcjs, it compiles the TH into a TH daemon, then it runs it under nodejs to execute it
<clever>
jtojnar: sometimes certain tests just have to be turned off
<clever>
dhess: have you heard of the template haskell interpreter?
<clever>
dhess: Sonarpulse in #nixos-dev has been doing a lot of cross-platform stuff lately
<clever>
jeaye: you have to cd into the output directory after unpackPhase
<clever>
jeaye: did you cd into the directory with the configure script?
<clever>
jeaye: have a look at how the xorg stuff already in nixpkgs deals with it
<clever>
jeaye: ah, the permissions inside the tar may be the issue
<clever>
ah, i dont see a setup hook in bzip2
<clever>
jeaye: and if you run the file command on $src ?
<clever>
can you gist my-dv.nix?
<clever>
ah, thats safe to ignore
<clever>
what args are you running nix-shell with?
<clever>
jeaye: nix-shell will fetch it, and point $src to the path that was fetched, unpackPhase copies&unpacks it to the cwd
<clever>
and once you confirm it works, file a PR
<clever>
muji: thats it, fork reflex-platform, bump the revision in there, and fix the sha256, and then use the fork in your expression
<clever>
muji: is there a nixpkgs.json in the reflex repo?
2017-12-29
<clever>
loke: but nix can gc things, and then has to re-download the headers&compiler every time you run it
<clever>
loke: you might be able to do something with the #!/usr/bin/env nix-shell stuff, so the bash wrapper becomes an entire nix-shell wrapper
<clever>
neither does nodejs, but ive seen people "compile" javascript by replacing some variable references with hard-coded strings and other fun stuff
<clever>
and there is no way to compile and run that binary ahead of time, and save the results?
<clever>
though if you try to use glib from lisp, it will have to rely on pkgconfig
<clever>
so all the glib stuff that tries to avoid conflicts and needs -I/usr/include/glib-1.0/ breaks
<clever>
but it only works when foo.h is inside /nix/store/something/include/foo.h
<clever>
so when you try to #include <foo.h> it can still find foo.h
<clever>
it sets some special env variables that adjust the default search path of gcc
<clever>
nope
<clever>
loke: you do all c/c++ development inside a nix-shell
<clever>
can you tell lisp to not suck? :P
<clever>
nix does whatever it can to not keep the headers around at runtime
<clever>
loke: yuck, lol
<clever>
in nixUnstable, it has been moved into nix itself now
<clever>
foo_: i prefer tab-completion in nix-repl
<clever>
foo_: and keeping all of that in ram
<clever>
foo_: the problem is executing the nix expressions for 20,000 seperate packages
<clever>
hyper_ch: dang :(
<clever>
foo_: but nix-env -iA nixos.firefox, will use very little memory, since it knows exactly which package to eval
<clever>
foo_: -qas does similar, and just prints instead of matching anything
<clever>
`nix-env -i firefox` has to evaluate EVERY SINGLE PACKAGE, and check if the .name attribute matches "*firefox*"
<clever>
depends heavily on what the expression is doing
<clever>
yep
<clever>
and then i load each one up with callPackage
<clever>
i also tend to make default.nix contain a set of many related packages
<clever>
fresheyeball: create a one-shot systemd unit
<clever>
samueldr: what did you try in the nixos config?
<clever>
samueldr: hmmm, to start with, try just adding noauto to the mount flags in the fileSystems entry
<clever>
there is a no automount flag you can set for systemd
<clever>
ah that, thats a pain
2017-12-28
<clever>
sound.enable = false; will be the first step in removing alsa
<clever>
and some things like alsa get auto-installed, without having to be present in systemPackages
<clever>
r3s1stanc3: even after you rebuild, a garbage collection wont delete it because of the rollbacks
<clever>
r3s1stanc3: you first need to find out what is depending on alsa, by checking the `nix-store -q --tree /run/current-system`
<clever>
r3s1stanc3: the above command will only include packages installed via nix-env, and wont include parts of nixos
<clever>
pkill9: yeah, that should work fine
<clever>
i believe this is how i had fixed it
<clever>
atomicbeef: set backspace=indent,eol,start
<clever>
yep
<clever>
marek: you then just need to generate a usb image with the justdoit.nix included in the imports
<clever>
marek: this is a nixos module, that pre-installs a bash script called justdoit into the nixos, and running that will just do it (wipe the hdd and install nixos)