2018-01-02

<clever> palo: run nix-build on the nix file
<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

2018-01-01

<clever> gchristensen: nice
<clever> with import <nixpkgs> {}; { pkg1 = callPackage ./pkg1.nix {}; }
<clever> so it could look something like this
<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> phdoerfler: cat /proc/swaps

2017-12-31

<clever> import <nixpkgs> { overlays = [ ./overlay.nix ]; } i think
<clever> samueldr: you can run that step in the issue comment without any hydra config
<clever> samueldr: if you run something like this on the release.nix file, you will see what hydra does behind the scenes
<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> jtojnar: modules/system/boot/systemd-lib.nix: pkgs.runCommand "${type}-units"
<clever> loke: we can still try this, but it may not help: https://nixos.org/nixos/options.html#drisupport32bit
<clever> yeah, i found the PR when i was filing the issue
<clever> i was just running chrootenv /run/current-system/sw/bin/bash, to try and get a shell inside the steam sandbox
<clever> i also noticed, that chrootenv.c checks if your root and behaves differently
<clever> because strace breaks setuid binaries
<clever> that happened when i ran it as root
<clever> oh yeah, that
<clever> yegortimoshenko: yeah, but the child is where it fails, early in the root setup
<clever> yegortimoshenko: this function is to blame
<clever> void bind_to_cwd(const char *prefix) {
<clever> and i dont think the chrootenv.c was capable of parallism
<clever> yegortimoshenko: i had the problem occur on this version
<clever> yegortimoshenko: nixos-18.03pre123588.ade98dc442e
<clever> loke: yeah, find the android emulator binary, and run "file" on it
<clever> loke: oh, mixing your answers up with another convo
<clever> loke: its nixos, there is no /lib
<clever> lrwxrwxrwx 1 root root 3 Apr 8 2016 lib64 -> lib
<clever> lrwxrwxrwx 1 root root 3 Apr 8 2016 sbin -> bin
<clever> [root@amd-nixos:~]# ls -ltrh /.zfs/snapshot/zfs-auto-snap_monthly-2017-11-01-00h00/
<clever> oh, snapshots
<clever> the /lib64 symlink was from april of several years ago, dont remember why it existed, or why it pointed to nothing
<clever> yegortimoshenko: 8 cores
<clever> loke: is the emulator 32bit or 64bit?
<clever> yegortimoshenko: yeah
<clever> 2017-12-30 21:17:30 < dhess> error: evaluation aborted with the following error message: ‘unsupported system type: armv7l-linux’
<clever> dhess: another tip, it can help to grep all the nix files for the error message: https://github.com/NixOS/nixpkgs/blob/master/pkgs/top-level/release-lib.nix#L37
<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> oh, lol
<clever> it ISNT on your rev!
<clever> it is on master
<clever> jtojnar: i think its the value of $TMP when nix-daemon is ran
<clever> dhess: on to release-lib.nix!
<clever> jtojnar: then dont use a tmpfs for /tmp/
<clever> try taking the overlays out temporarily?
<clever> nothing obvious is visible
<clever> dhess: why is allowBroken set to true on 10 of release.nix?
<clever> so that should be fine
<clever> dhess: that will always be a derivation for the host cpu
<clever> dhess: try to eval it with nix-instantiate --show-trace and see what error it gives?
<clever> now check hello.x86_64-linux.meta.platforms
<clever> check that both of those eval for a given pakage
<clever> dhess: and each of those attributes will have a .x86_64-linux and .armv6l-linux attr
<clever> dhess: line 57 should give an attribute for every single package under pkgs
<clever> dhess: try to eval just one package from the jobs set, before you try the aggregate
<clever> jobs.hello needs to be exposed to test that
<clever> ah, your set at 60-63 filters that out
<clever> and see what that says
<clever> dhess: try something simpler, like hello in the nix-repl first
<clever> which release.nix is this?
<clever> dhess: yeah, the problem is with the nix expressions, not the hydra
<clever> dhess: can you link the hydra page?
<clever> dhess: double-check with nix-instantiate or nix-repl, that the expression even allows it
<clever> jtojnar: the /tmp that nix builds under needs to support xattr then
<clever> patch it to use $TMP
<clever> 60 may also mess with the on-boot
<clever> 58 stops it from running on bootup
<clever> 58 stops it from restarting on deploy
<clever> dhess: i think this turns off the "run on bootup" part of hydra
<clever> dhess: you have it configured to stop itself if it goes under 64gig of space, and you have 700, so that should be fine...
<clever> dhess: also check the hydra-queue-runner logs after it stops
<clever> not sure what the issue is, but keep an eye on that log and see what it says next time
<clever> dhess: how much free space on /nix/store/ ?
<clever> dhess: try without -f, and scroll thru the last day of output
<clever> dhess: what does "journalctl -f -u hydra-check-space" say?
<clever> dhess: one min

2017-12-30

<clever> yeah
<clever> i would expect that to break building of anything
<clever> does*
<clever> after the unpackPhase, and the stdenv goes it for you
<clever> jeaye: yeah
<clever> yikes
<clever> can you update the gist with the nix file, and then i can reproduce the issue
<clever> yeah
<clever> yeah
<clever> jeaye: i want to confirm what path configure is at
<clever> jeaye: can you gist the output of "tar -tvf $src" ?
<clever> jeaye: try instead just runnign genericBuilder, with nothing else, dont even mkdir or cd $out
<clever> but if you manually run the unpackPhase, it wont
<clever> jeaye: when the stdenv has finished unpackPhase, it will cd for you
<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> i tend to just write my own expressions and import <nixpkgs
<clever> the default.nix file in nixpkgs is just a function that needs to have dependencies passed in
<clever> which helps with many things
<clever> if you load it with callPackage from elsewhere, it will share the instance of nixpkgs
<clever> nix-build and nix-shell auto-call things
<clever> you still need to call it with a {}
<clever> the pkgs argument has a default value of import <nixpkgs> {};
<clever> yeah, but you can either make a shell suitable for building foo, or you can make a shell that has the finished foo in $PATH
<clever> do you want to use the result of default.nix in the shell?
<clever> yeah, but they will just become env variables in the shell
<clever> not sure on that
<clever> name = "something";
<clever> you need to give a name to the derivation
<clever> oh
<clever> foo_: can you screenshot the error?
<clever> and the bash script is what gets ran, and handles the runtime stuff
<clever> loke: yeah, a derivation will need to use that when generating a bash script that wraps the lisp binary
<clever> foo_: can you gist the entire shell.nix file and the exact command you ran?
<clever> loke: LD_LIBRARY_PATH=${lib.makeLibraryPath [ openssl ]} i think
<clever> foo_: what is the error?
<clever> foo_: nix-shell will give you an environment suitable to build whatever the derivation would have built
<clever> loke: python has the same problem
<clever> foo_: a derivation
<clever> loke: ah, then you need to set LD_LIBRARY_PATH when running the lisp interpreter, to include the path to the libraries
<clever> loke: why does it need to be available?
<clever> loke: nixos never installs the library component globally, all builds must happen inside nix-build or nix-shell
<clever> yegortimoshenko: maybe --option build-use-sandbox true
<clever> yep
<clever> yeah
<clever> and nix expects you to install everything to $out
<clever> if the configure script cant be found, the default configurePhase does nothing
<clever> pretty much
<clever> loke: yep
<clever> loke: you want to set things like configurePhase, buildPhase, and installPhase to provide commands that do each
<clever> `_: you can also just copy all of them into a directory and refer to that directory in the nix expression
<clever> and bashrc
<clever> the tmux config can also be done the same way
<clever> not sure how to do nvim with that expression
<clever> or just read your vimrc directly with builtins.readFile
<clever> `_: put the vim equivelent of #include into this vim config
<clever> vimrc has nixpkgs support
<clever> is it something you just add to $PATH?
<clever> `_: you want to refer to it at compile time, so nixos embeds a snappshot of those scripts into /nix/store/
<clever> yeah
<clever> fresheyeball: setting a systemd.service option
<clever> fresheyeball: just put the lines i highlighted into configuration.nix
<clever> `_: build-vm doesnt work as well for testing mounting of devices it doesnt emulate
<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)
<clever> marek: i have something very similar
<clever> gilligan_: pkgs.path + "/nixos/tests/make-test.nix"

2017-12-23

<clever> but nix still counts that as a runtime dependency
<clever> Lisanna3: behind the scenes, it just gets written to a file that nothing ever reads
<clever> Lisanna: this makes the entire stdenv present in the nixos install ISO
<clever> also, let me find it
<clever> if you build the same expression on the other end, you can get them
<clever> id just use stdenv.mkDerivation
<clever> and you likely dont want that
<clever> buildEnv will drag perl in as well
<clever> ah
<clever> it wont actually build the env
<clever> why are you running nix-shell on a buildEnv?
<clever> why not just make an override that sets buildInputs = []; ?
<clever> ah, not sure how you would go about that
<clever> Lisanna: you can run nix-shell on a .drv file

2017-12-22

<clever> gchristensen: pong
<clever> kuznero: nix-store -qR
<clever> yeah

2017-12-21

<clever> the xfce gui is great
<clever> srhb: lol
<clever> and if i unplug without turning it off, it crashes xorg hard
<clever> but if i plug one in, it auto-enables
<clever> if i turn a monitor off in the config, it safely shuts off, and can be unplugged
<clever> gchristensen: i use xfce and it supports it, but my GPU drivers like to hard-crash the machine if the gpu state changes
<clever> then /run/current-system/sw/bin/ in $PATH
<clever> Fare: you need a tmpfs at /run and a symlink from /run/current-system to the latest build of nixos in the store
<clever_> Fare: there ix a nixos-install --chroot, but its only present on another nixos
<clever> yay
<clever> thanks
<clever> asymmetric: i try to avoid using it as well
<clever> asymmetric: they will propogate into the buildInputs of other things that depend on your package
<clever> which form a storepath