2018-07-28

<clever> > "hello" == "hello"
<clever> and you would need IFD to read them
<clever> vaibhavsagar: some of them are only known at buildtime, via $out/nix-support
<clever> adelbertc: oh, i think @1 in mtime, says its a raw unix timestamp, and to not try to parse it as a date/time
<clever> ah, that makes sense
<clever> Lears: i have heard of it, but havent tried it yet
<clever> you can select which ones it needs
<clever> i would make it such that you dont have to do EVERYTHING in one
<clever> elvishjerricco: the summed cabal file will have all of the cabal projects in one shell, and `cabal build` will just treat it as one massive blob for incremental building
<clever> djtyml: i'm not that familiar with what reflex-platform is doing with all of its nix files, they seem to be trying to automate a lot of the tricky stuff, but that also makes it harder to debug anything
<clever> elvishjerricco: so you can nix-shell into that summed.cabal, and it will have all src and executables
<clever> elvishjerricco: i have plans for a tool that will just sum together several cabal files
<clever> elvishjerricco: and i properly define all modules in nix :P
<clever> and just dont use new-build at all
<clever> elvishjerricco: i prefer using the cabal library nix-shell provides, via Setup.hs
<clever> djtyml: reflex platform is running callCabal2nix on every source directory you give it, to auto-generate nix files for each
<clever> elvishjerricco: cabal shouldnt be installed on nixos, it tends to cause version conflicts down the road
<clever> djtyml: oops, ^^^
<clever> elvishjerricco: outside of nix-shell, what does `type cabal` print?
<clever> elvishjerricco: aha, system() is to blame
<clever> djtyml: you also shouldnt run the cabal binary, but Setup.hs
<clever> all haskell must be done in nix-shell, and it will then have the same versions
<clever> djtyml: in general, you shouldnt be installing any haskell things with nix-env
<clever> djtyml: cabal2nix likely doesnt like being ran against a zip file, try just not listing heist in packages?
<clever> and remove the jailbreak
<clever> so you need to give it pkgs.haskellPackages.heist.src i think
<clever> djtyml: but pkgs.haskellPackages.heist is a derivation, which contains the already compiled heist library
<clever> djtyml: i think the problem is that reflex-platform expects packages.heist to be a path, and for the heist directory to contain a cabal file
<clever> ah, differs from the one in the repo
<clever> djtyml: its not clear yet where heist is coming from, the string doesnt appear in your repo
<clever> builder for '/nix/store/04s6cca0b5q00n0qqp8h1kwzqrbiz1f5-cabal2nix-heist.drv' failed with exit code 1
<clever> djtyml: you also generally want to add result to .gitignore after you remove it from git
<clever> djtyml: can you also gist the full output from the error?
<clever> djtyml: can you gist the nix expression?
<clever> will the next process be 0?
<clever> what if you just unset it entirely?
<clever> wasnt sure if it would or not
<clever> gui terminals then increment it once more in their shell, resulting in 3 for gui terminals
<clever> xsession runs xinitrc (from xfce4), and the xinitrc bash script incremented it to 2, which is where all gui programs run
<clever> elvishjerricco: so maybe SHLVL=-1 ?
<clever> elvishjerricco: the problem, is that it gets incremented after this point, twice
<clever> elvishjerricco: this is the xsession script from above, it has an SHLVL of 1, its child (xinitrc in xfce) is 2, and then the gui terminals are 3
<clever> so the gui terminals start at 1
<clever> i'm thinking maybe patch the xinitrc stuff to reset it to zero?
<clever> $SHLVL will read the current value and insert that into the export command, \$SHLVL will insert a literal $SHLVL into PS1, and then re-eval it again on each cmd
<clever> it will dynamically read the current value on every printing
<clever> elvishjerricco: yeah, just a \$SHLVL in PS1 is enough
<clever> hmmm
<clever> ive only noticed those when git-bash on windows hangs for 30 seconds after every cmd, because ntfs doesnt like `git status`
<clever> there are also hooks to just run a command between every command
<clever> SHLVL
<clever> elvishjerricco: does PS1 have a flag for it, or will i need to run a command?
<clever> nix-shell is too heavy, but nix run is too light and i dont even notice it
<clever> i can see SHLVL being handy though, o keep nesting `nix run` by accident or just entirely forgetting to exit it
<clever> so, several proccesses in the xorg startup are bumping SHLVL
<clever> and since i manually launch screen on the laptop, its shells are 4
<clever> and shell inside gui terminals being 3
<clever> leading to all gui apps being in level 2
<clever> so when xinitrc inside xfce ran xfce4-session, it got bumped again
<clever> and 5065 is SHLVL=2!
<clever> so xsession ran xinitrc, which bumped the level
<clever> 5053 is SHLVL=1!
<clever> 5065 ? Sl 2:15 xfce4-session
<clever> 5053 ? S 0:00 /nix/store/8zkg9ac4s4alzyf4a8kfrig1j73z66dw-bash-4.4-p23/bin/bash /nix/store/kqrl910lkvn8q1ybkmhv5x3834hj0mia-xfce4-session-4.12.1/etc/xdg/xfce4/xinitrc
<clever> 4957 ? S 0:00 /nix/store/8zkg9ac4s4alzyf4a8kfrig1j73z66dw-bash-4.4-p23/bin/bash /nix/store/qwa6a62r78mq0pnfad9q12pd0jzl414n-xsession xfce
<clever> which is still 0
<clever> which ran this after logging in
<clever> 4913 ? S 0:00 /nix/store/8zkg9ac4s4alzyf4a8kfrig1j73z66dw-bash-4.4-p23/bin/bash /nix/store/qwa6a62r78mq0pnfad9q12pd0jzl414n-xsession xfce
<clever> it was 0 for the actual display manager
<clever> sudo strings /proc/3268/environ | grep SHLVL
<clever> SHLVL=0
<clever> 3268 ? Ssl 0:00 /run/current-system/sw/bin/sddm
<clever> oh, hmmm
<clever> SHLVL=2
<clever> strings /proc/$(pidof xfce4-panel)/environ | grep SHLVL
<clever> the xfce4-terminal is already at 2, and it was directly launched by xfce-panel
<clever> strings /proc/$(pidof xfce4-terminal)/environ | grep SHLVL
<clever> SHLVL=2
<clever> note that you can peek at env vars of any process in /proc
<clever> its already 3 on a bare xfce-terminal
<clever> elvishjerricco: strange, i'm seeing 4 on a shell inside screen, hmmm

2018-07-27

<clever> nixos doesnt directly support those, but it could probably be hacked in if you needed it
<clever> dhess: vde also has options to introduce packet loss and packet corruption, and throttling
<clever> dhess: its using vde switch to emulate a switch with vlan support
<clever> dhess: yeah
<clever> all one network though for the 2nd
<clever> yep, gotta make sure the NAT works in the torrent clients
<clever> dhess: this creates a test with 4 machines, a tracker, router, and 2 clients
<clever> dhess: yes
<clever> iqubic: nix does auto-detect the runtime and buildtime deps for all packages
<clever> ah, that makes things a bit more tricky
<clever> and a default.nix in the same folder, for the game itself
<clever> maybe games/gamename/editor.nix ?
<clever> causing some false errors
<clever> that weird way it works also means that when nixos-rebuild tries to build nix, it will not support those options
<clever> yeah, it has to be manually documented
<clever> so its missing when the docs scan things
<clever> samueldr: the whole qemu-vm.nix is optionally added by the build-vm flag
<clever> samueldr: its never in the manual
<clever> samueldr: yep, that will work, and it will give some false errors that you can safely ignore
<clever> kamme: ah
<clever> kamme: when using nixos in virtualbox, you use `nixos-rebuild switch` as normal
<clever> the -small channels omit the zero queued jobs check, and therefor have worse binary cache coverage, but update faster
<clever> tenten8401[m]: oh right, the channel wont update until everything in tested passes, AND there are zero queued jobs for that eval
<clever> Denommus: systems.services.gitlab.preStart = lib.mkForce "...";
<clever> Denommus: just set the value again using mkForce
<clever> worldofpeace: nix-store --query --roots
<clever> Denommus: overlays can only change pkgs, you need nixos modules to change services
<clever> angerman: nixops deploy --build-only, then check nix-store -qR and nix why-depends, then look up what option turns it off
<clever> Denommus: builtins.readFile
<clever> for initial testing of the testing, you can just run nix-build on it
<clever> yep
<clever> what you do in there is up to you
<clever> the script at the end is ran in bash, and must produce a $out and exit with status 0
<clever> runCommand "name" { buildInputs = [ nodejs ]; ''nodejs runtests.js''
<clever> iqubic: as long as you can make a nix file with derivations that run each test, yes
<clever> > lib.makeLibraryPath [ glibc ]
<clever> > lib.makeLibraryPath [ libc ]
<clever> > lib.makeLibraruPath [ libc ]
<clever> > lib.makeLibPath [ libc ]
<clever> it should be a path pointing to the lib dir that contains the missing libraries
<clever> then youll want to use the postFixup phase to either wrapProgram LD_LIBRARY_PATH, or patchelf some extra things into the rpath
<clever> check the image magick source code for dlopen
<clever> is it trying to open things with dlopen?
<clever> kiloreux: i dont see anything obviously wrong though, nor an error
<clever> kiloreux: line 13 is baiscally useless
<clever> can you pastebin an error and the nix file?
<clever> ah
<clever> what part of it is not working?
<clever> ah
<clever> > imagemagick
<clever> kiloreux: imagemagick is already packages
<clever> just run tar -xf ${src2}, maybe in the postUnpack
<clever> angerman: so they can be tested fully on hydra without blocking master
<clever> angerman: staging is mainly where experimental things go, that are likely to break nixpkgs entirely
<clever> tertle||eltret: sudo nix-channel --update
<clever> tertle||eltret: ls -l /nix/var/nix/profiles/per-user/root/channels/
<clever> tertle||eltret: sudo nix-channel --list
<clever> what does `echo $NIX_PATH` say?
<clever> $NIX_PATH is broken
<clever> then you need to modify your program to be able to use rtkit
<clever> tertle||eltret: if you set security.rtkit.enable = true; then pulseaudio is able to elevate itself to RT without having root
<clever> tertle||eltret: what error does it fail with?
<clever> tertle||eltret: run `id` and confirm your in the audio group
<clever> sophiag: that could be inside the file you load with callPackage
<clever> iqubic: efi booting requires GPT
<clever> iqubic: also, do you want to boot with legacy or efi?
<clever> iqubic: gpt tables have no limit
<clever> iqubic: for dos partition tables, 4 primary, one of which can then contain many extended, but you should never really use dos partition tables anymore
<clever> stdenv and requireFile are not in that set
<clever> but configuration.nix ix a nixos module, and it has a different set of args it can accept
<clever> so if you run callPackage on { stdenv }:, then it will pass you the value of pkgs.stdenv
<clever> sophiag: for packages, pkgs.callPackage will inspect the arguments the file is asking for, and get defaults from pkgs.defaults
<clever> but that was a single file in my imports section, so it was trivial to just comment out that, and downgrade the machine
<clever> when i was testing 17.09 to check for the bug i previously mentioned with pie_, i ran into an issue where binfmt-misc didnt exist yet
<clever> its easier to organize and manage if you have a new file for each thing and feature
<clever> yes
<clever> just let opam2nix = pkgs.callPackage ./path/to/default.nix {}; in ...
<clever> but you are also free to just callPackage everything in a let block
<clever> the main thing you gain from using packageOverrides is that it winds up inside the pkgs used by nixos, so you can just do pkgs.thing elsewhere, and you can overwrite the pkgs that other nixos modules is using
<clever> you can then put it into either a let block, or packageOverrides
<clever> and then load it with pkgs.callPackage ./path {}
<clever> its better to keep that default.nix as its own default.nix file
<clever> stdenv can only be used like that in a file being opened with callPackage
<clever> that looks like you took a default.nix and a configuration.nix and jammed them together
<clever> same for stdenv and requireFile, which should not be on line 1 of configuration.nix
<clever> so you want pkgs.fetchFromGitHub
<clever> that is an attribute of pkgs
<clever> what error is it currently giving?
<clever> sophiag: and then just import that into configuration.nix later, when it works
<clever> sophiag: you can also use import to load other nix files, so you could make a simple nix file that just builds with nix-build
<clever> sophiag: gist supports multiple files, which makes things easier to read
<clever> iqubic: if your using EFI, it must be fat32 and tagged as the efi system partition
<clever> and its getting a bit off topic so i'll switch rooms
<clever> and after further research, those symptoms are how the hardware is supposed to work
<clever> but that also confirmed, 17.09 was exibiting the same symptoms
<clever> surprisingly, it was trivial to downgrade from nixos-unstable to 18.03, and then even 17.09
<clever> so i had to rebuild the old versions from nixpkgs
<clever> but i had GC'd everything :P
<clever> just last week, i had the need to do a rollback of several months to test something
<clever> but you can also just let nix-collect-garbage --delete-older-than nuke em all
<clever> pie_: i prefer to manually delete certain system generations, based on the results of --query --roots
<clever> and i prefer to avoid using -d, it can make it difficult to undo other mistakes later
<clever> if ran with zero args, that doesnt matter
<clever> pie_: run --query --roots on each, and pastebin all of the results
<clever> if there are roots, what you do will depend on where the roots are
<clever> and if there are no roots, nix-store --delete it
<clever> pie_: once you find a ghc you dont like the look of, nix-store --query --roots it
<clever> pie_: run this, and tell me what some of the fatter things are, that you want to get rid of: du -h --max=1 -c /nix/store | sort -h
<clever> pie_: one sec
<clever> pie_: how much space is available?, how much is used in /nix/store/?
<clever> nix-instantiate --find-file nixpkgs
<clever> your <nixpkgs> is too old
<clever> it doesnt
<clever> nix-build '<nixpkgs>' -A libGL
<clever> does the version from <nixpkgs> contain a libGL?
<clever> nixpkgs contains a reference to itself, called pkgs
<clever> > pkgs.pkgs.pkgs.pkgs.hello
<clever> pie_: it should just be stb.libGL
<clever> iqubic: i'm guessing you previously used sdb1, and the partition table was messed up
<clever> pie_: you have to pass nixpkgs a set of overrides when loading it, for it to impact everything within that set of packages
<clever> pie_: that wont work when callPackage comes into play
<clever> kalbasit: patchelf --set-interpreter "$(cat $NIX_CC/nix-support/dynamic-linker)" while inside nix-shell or nix-build
<clever> pie_: import <unstable> { config.packageOverrides = pkgs: { libGL = std.libGL; }; };

2018-07-26

<clever> _d0t: so just make a derivation that unpacks this tar, copies some things to $out/share/whalebird, and then generates a bash script under $out/bin
<clever> _d0t: i now have a UI of some kind!
<clever> [clever@amd-nixos:~/Downloads]$ ./result/bin/electron Whalebird-1.5.3-linux-x64/resources/app.asar
<clever> [clever@amd-nixos:~/Downloads]$ nix-build ~/nixpkgs/ -A electron
<clever> _d0t: one option is to grab the .tar.bz2 from the release page, and unpack that, then check it for a package.json
<clever> the file it refers to is missing, so it has to be compiled first
<clever> if you point electron to a directory with a package.json, it will run whatever main points to
<clever> _d0t: look at the package.json, in the main field
<clever> but yarn2nix has since been added, and now the JS is "compiled" directly in nix
<clever> _d0t: originally, this nix expression was unpacking a darwin package, ripping the JS out of it, then running it with the nixpkgs electron
<clever> and getting the JS for rawapp is a different matter, and will depend on the package
<clever> _d0t: only lines 19,20, and 27 are really needed, the rest is specific to this app
<clever> _d0t: you can write a package that will generate a bash script to do that
<clever> _d0t: if you can get just the JS from it, you can just run ${pkgs.electron}/bin/electron against it to start things
<clever> pie_: cant see anything that would break it
<clever> pie_: link?
<clever> pie_: i dont think ghc can put line-numbers that gdb can use into files
<clever> pie_: this will apply an override to enable debug symbols
<clever> > pkgs.enableDebugging pkgs.hello
<clever> pie_: not sure then
<clever> pie_: does file say the program has debug info?
<clever> ${openexr}
<clever> joebobjoe: the link above explains that
<clever> -iA is faster, but there is no way to make --upgrade use -iA
<clever> and -i is already slow
<clever> --upgrade is just applying -i to every currently installed package
<clever> ,-A
<clever> nek0: then do what symphorien said, dont put cmake in the inputs
<clever> nek0: nix itself, or a derivation being built with nix?
<clever> das_j: look at /proc/<pid>/root with `ls -l`
<clever> check `alsamixer -c 0` and see if something is simply muted
<clever> _d0t: try with this instead
<clever> hardware.pulseaudio.configFile = pkgs.runCommand "new-default.pa" "cat ${getBin pkgs.pulseaudioLight}/etc/pulse/default.pa | grep -v module-suspend-on-idle > $out";
<clever> oh, need to replace overriddenPackage
<clever> _d0t: i think the above will work to just delete that line
<clever> hardware.pulseaudio.configFile = pkgs.runCommand "new-default.pa" "cat ${getBin overriddenPackage}/etc/pulse/default.pa | grep -v module-suspend-on-idle > $out";
<clever> you could even make a derivation, for example...
<clever> that will entirely replace the one that is being .include'd
<clever> ah, you can also set hardware.pulseaudio.configFile to the path of your own default.pa file
<clever> hardware.pulseaudio.configFile = mkDefault "${getBin overriddenPackage}/etc/pulse/default.pa";
<clever> unload-module is simpler
<clever> so you will either need an override on pulseaudio, or hardware.pulseaudio.extraConfig = "unload-module module-suspend-on-idle"; maybe
<clever> that default.pa is part of the pulseaudio package
<clever> which line?
<clever> line 39 inserts the string from the option tilpner gave
<clever> _d0t: the one in /etc/ ?
<clever> nixos-rebuild for every single test is going to get anoying fast, and spam your grub config
<clever> for testing, you probably want to use nix-build on a stand-alone file
<clever> i was trying to see if the docker image build process correctly forced linux when being ran on darwin
<clever> but then IFD tries to run a mach-o binary on linux, and everything explodes
<clever> infinisil: ive used it to change the value of builtins.currentSystem with nix-instantiate :P
<clever> this tricks a darwin machine into thinking it is a linux box, so nix tries to run an ELF file...
<clever> infinisil: you can also override things that dont make sense to change, and cause problems, --option system x86_64-linux
<clever> infinisil: if you are a trusted user (which root is), then i believe you can override everything
<clever> symphorien: added a comment
<clever> you can override most nix.conf things with --option
<clever> tenten8401: nixos-rebuild switch --option build-cores 8
<clever> tenten8401: nix.buildCores only takes effect after nixos-rebuild finishes
<clever> tenten8401: can you pastebin the contents of your nix.conf ?
<clever> tenten8401: does your nix.conf specify how many cores to use?
<clever> symphorien: sure
<clever> the ssh protocol will use ssh key pairs, and those dont have total control over your account, and can easily be revoked
<clever> i'm not sure if git:// even supports auth?
<clever> the http protocol just uses basic-auth, so your name/pw must be saved somewhere, and those should never be saved in a readable form
<clever> ssh, not git
<clever> clever git@github.com:cleverca22/nixpkgs.git (fetch)
<clever> [clever@amd-nixos:~/nixpkgs]$ git remote -v
<clever> growpotkin: you want to use the ssh url, not the http url
<clever> symphorien: it looks like nix-daemon is deleting $out...
<clever> 4212 rmdir("/nix/store/1ik81mhahb31ly75x4np0njf42rk47x6-a.drv.chroot/nix/store/f2vpwzxhh4a13qwaynr6sjs8kv3i8giw-a") = 0
<clever> 4205 lstat("/nix/store/1ik81mhahb31ly75x4np0njf42rk47x6-a.drv.chroot/nix/store/f2vpwzxhh4a13qwaynr6sjs8kv3i8giw-a", {st_mode=S_IFDIR|0755, st_size=2, ...}) = 0
<clever> this is prior to the build starting
<clever> ah wait
<clever> the path is missing
<clever> 3486 lstat("/nix/store/f2vpwzxhh4a13qwaynr6sjs8kv3i8giw-a", 0x7fff9fdd3a20) = -1 ENOENT (No such file or directory)
<clever> symphorien: thats the pid of nix-daemon
<clever> symphorien: checking the logs this made: strace -s 5000 -ff -o logfiles -p 27568
<clever> python -m cv2 reports a different error
<clever> gchristensen: i dont see any opencv3.py files in there, i dont even see any py files
<clever> gchristensen: -r-xr-xr-x 1 root root 5.0M Dec 31 1969 /nix/store/wj6bbdpd3bn5v4aajpk7z90lqm2np1zx-opencv-3.4.1/lib/python3.6/site-packages/cv2.cpython-36m-x86_64-linux-gnu.so
<clever> das_j: buildEnv
<clever> symphorien: trying with strace to confirm where the problem is
<clever> but $out is missing...
<clever> symphorien: and php is leaving $dev around
<clever> symphorien: the weird part, is that when any build fails, the outputs are left around, but not flagged as invalid
<clever> qyliss: mkForce
<clever> symphorien: it should report this error if it ever refers to somethng it shouldnt, and i dont see that error
<clever> throw BuildError(format("output '%1%' is not allowed to refer to the following paths:%2%") % actualPath % badPathsStr);