2017-07-02

<clever> boomshroom: builtins.fetchurl allows you to fetch things in an impure fasion, but it will re-download it every time you eval the nix file
<clever> where you make a nix file that pre-builds everything it will need, before launching the vm
<clever> the build-vm stuff in nix is mostly meant for read-only use of the store
<clever> but when you start doing weird things, you might break it in weird ways
<clever> so it wont delete that closure
<clever> and the host knows thats in use via the cmdline in /proc
<clever> for the normal guests, only stuff that the guest should know about is registered into the db.sqlite
<clever> just make sure you enable kvm, or performance will be horid
<clever> just delete the xen bits
<clever> it will work for your needs
<clever> but if your fine with impure stuff like persisting the disk image, and using nix-copy-closure to import new builds
<clever> exactly
<clever> who would be crazy enough to run a vm inside a vm?
<clever> it only detects xen, so it turns off qemu features
<clever> and the linux is inside xen, inside qemu
<clever> build*
<clever> its all happening inside a nix-buid
<clever> the host lacks root
<clever> say goodbye to your free space :P
<clever> so i need a new 1gig disk image file for every test
<clever> but the critical problem, is that the 9plan/virtio stuff to share /nix/store/ from the host, doesnt work
<clever> so i had to run xen under qemu
<clever> and i wanted the entire test to run without root
<clever> i wanted to test xen unikernels, but they only run under the xen hypervisor
<clever> yes
<clever> and makes use of xen commands inside the guest
<clever> then boots it under qemu
<clever> spinus: this creates a disk image containing a full nixos install, with grub, and xen
<clever> spinus: ive got an example in a gist that does some whacky things
<clever> odd
<clever> catern: does tsnix own everything in the store?
<clever> tests/common.sh.in: export NIX_IGNORE_SYMLINK_STORE=1
<clever> catern: there is an option to allow it to be a symlink
<clever> spinus: you would need to use make-disk-image.nix, and then nix-copy-closure or nixops to keep it up to date
<clever> but the tmpfs its building in might be mounted noexec
<clever> catern: the one you just posted
<clever> catern: can you pastebin the entire output of "mount"?
<clever> causing github to claim the build is pending
<clever> because it took 9 hours, it could say a build was queued, after the build passed
<clever> and that was just a few hours after i fixed a problem in the github status plugin, related to it
<clever> yep
<clever> during which time, it cant do another eval of that jobset
<clever> eelco made a commit recently saying it takes 0.7sec for each, and ~9 hours in total
<clever> but also, the evaluator will run the build-queued perl hook, for every single build
<clever> gchristensen: i have seen it sit on single-threaded curl requests, and not fire new jobs up
<clever> gchristensen: as hydra loads each job from the queue, it will check for subs, before moving to the next job
<clever> gchristensen: i believe hydra checks for subs after the eval, inside the hydra-queue-runner daemon
<clever> curse is trying to kill ftb
<clever> and mcedit
<clever> Infinisil: i do have nix packages for multimc and ftb launcher
<clever> its just a server ran on nixos by one of the guys in here, ive played on it before
<clever> the server is heavily supported by nix
<clever> Baughn runs one
<clever> i play it every now and then, but the computer has trouble getting reasonable perf
<clever> boomshroom: and that java launcher they had?, lets deprecate it!
<clever> tilpner: check the journal
<clever> swflint: you need to add fetchgit to the function arguments on line 1
<clever> tilpner: did you use a revision of nixpkgs that wasnt from a nixos channel?
<clever> nix-prefetch-git might also give a rev
<clever> git will tell you the rev
<clever> nix-prefetch-git will tell you the sha256
<clever> git needs a rev, and nix needs a sha256
<clever> swflint: yes
<clever> otherwise, you would have to compile amd and nvidia versions of every gui app
<clever> so LD_LIBRARY_PATH is required, to sneak those in after things have been made immutable
<clever> and rpath and immutable outputs makes that tricky on nix
<clever> vendors like to make things difficult, and you need the right libGL for your card
<clever> pie_: yeah, thats where nixos puts the gl drivers for your gpu
<clever> src = fetchgit { url = "something"; rev = "something"; sha256 = "something"; };
<clever> swflint: your missing -lX11, check my gist
<clever> or relative to . since the default unpackPhase copies the source to the current dir
<clever> swflint: and then use a path relative to $src in the script
<clever> src = fetchFromGitHub { owner = "foo"; repo = "bar"; sha256 = "baz"; rev = "something"; };
<clever> swflint: https://gist.github.com/4c165e69f08aec185d4b2366e3b62303 another variant if you get stuck
<clever> joepie91: ive moved 10-15mb of strace logs like that before
<clever> joepie91: gist only limits what can be seen on the site, you can still git clone the logs
<clever> swflint: then you can just nix-build '<nixpkgs>' -A x11idle, or nix-env -iA nixos.x11idle
<clever> swflint: in the packageOverrides, do x11idle = pkgs.callPackage ./x11idle.nix {};
<clever> joepie91: gist is also a command in nixpkgs, and it just uploads right to gist
<clever> swflint: from which command?
<clever> swflint: and to make it work without that incanation, add it to either your config.nix, or nixpkgs and open a PR so it works for all
<clever> swflint: oh right, have to add unpackPhase = ":";
<clever> pie_: nixos has to change it at runtime for the gpu driver you need
<clever> pie_: LD_LIBRARY_PATH provides the real libgl
<clever> swflint: oh right, need to add { stdenv, xlibs }: to the start of the file
<clever> eacameron: yes
<clever> swflint: nix-build -E 'with import <nixpkgs> {}; callPackage ./yourfile.nix {}'
<clever> eacameron: --no-out-link
<clever> swflint: what error does it give?
<clever> eacameron: what about the nix-build i gave above?
<clever> pie_: its in glibc
<clever> glibc.out 0 s /nix/store/izxnyg94352qxa4a4783dzgnpy5cwazj-glibc-2.25/lib/libdl.so.2
<clever> [clever@amd-nixos:~]$ ./apps/nix-index/result/bin/nix-locate lib/libdl.so
<clever> pie_: the library that gives you dlopen
<clever> eacameron: nix-build -E 'with import <nixpkgs> {}; callPackage ./. {}'
<clever> joepie91: i have months worth of undo's waiting :P
<clever> joepie91: i prefer zfs snapshots
<clever> eacameron: nix-env -i -E 'with import <nixpkgs> {}; callPackage ./. {}' i think
<clever> just need to scroll up past the error handling logic
<clever> pie_: usualy, it will stop when it fails, so the last thing it did is the important one
<clever> joepie91: reflog?
<clever> dont worry, bash does the same thing with file handles, lol
<clever> ever heard of readdir?
<clever> :D
<clever> start*
<clever> any files its trying to open are a good place to stat
<clever> dlopen is a library function, strace wont find it
<clever> pie_: while you wait, try strace -e open
<clever> but dlopen isnt covered
<clever> i think LD_DEBUG only handles things flagged with DT_NEEDED
<clever> joepie91: mouse/keyboard not working after patchelf i believe
<clever> pie_: what is LD_LIBRARY_PATH set to?
<clever> pie_: ah, is that unity based?
<clever> fresheyeball: do you really want to install something, or just test that it builds and runs?
<clever> joepie91: ah
<clever> swflint: stdenv.mkDerivation { name = "x11idle"; installPhase = "mkdir -p $out/bin; gcc -lXss ${./x11idle.c} -o $out/bin/x11idle"; buildInputs = [ xlibs.libXScrnSaver ]; }
<clever> if it ever hits a black hole, it will know its turned back and hit its own stack trace
<clever> and while running, it will temporarily change the type to black-hole
<clever> joepie91: and if you try to use that value for anything, nix will run it on the spot, and replace the thunk with the return value
<clever> joepie91: basicaly, any time nix parses a non-trivial expression, it just generates a value of type thunk, that basicaly contains a function pointer and some args
<clever> joepie91: it can help to know how thunks work in nix
<clever> pie_: so if you do everything with nix-store, then nix will never delete something in-use
<clever> pie_: nix can only know about things being in-use by other things in /nix/store
<clever> swflint: and also, installing gcc doesnt work, you must nix-shell -p gcc
<clever> pie_: that is why you and swflint should always build things with nix-build, and never try to do things by hand
<clever> swflint: what does "type gcc" say?
<clever> try gcc.cc first
<clever> pie_: gcc.cc.out i think
<clever> can you copy/paste everything in the terminal to a pastebin and link that?
<clever> swflint: try without the --run, and then manualy do the gcc inside of that
<clever> swflint: what is the exact nix-shell commant you ran?
<clever> swflint: -p xlibs.libXScrnSaver
<clever> swflint: you must add that to the nix-shell args
<clever> swflint: xlibs.libXScrnSaver
<clever> it has to go into the RPATH, via makeLibraryPath in my gist
<clever> oh right, and buildInputs is 100% useless when patching things
<clever> it gets the version that is the default in the current nixpkgs
<clever> mesa_noglu
<clever> and typicaly, you use mesanoglu for this part
<clever> pie_: it must be a name without the version
<clever> swflint: what is the new nix-shell command, the command your running inside that, and the error?
<clever> yep
<clever> you must tell nix-shell to include pkgconfig
<clever> swflint: that shell wont have a working pkgconfig in it
<clever> swflint: what nix-shell command did you use?
<clever> pie_: the patchelf one?
<clever> you must nix-shell -p pkgconfig libfoo libbar
<clever> installing libraries wont make them visible to pkg-config either
<clever> and installing pkg-config will never make it work right
<clever> pkg-config only works inside nix-shell and nix-build
<clever> yes
<clever> swflint: are you using nix-shell?
<clever> noobly_: environment.systemPackages = [ (pkgs.callPackage ./racket.nix {}) ];
<clever> eacameron: sounds neat
<clever> hmmm, but that might not work with <nixpkgs/nixos> now that i think of it, would need some experimentation
<clever> example b: { ... }@args: import (builtins.fetchtarball { url=...; sha256=...; }) args
<clever> example a: { ... }@args: import /home/clever/nixpkgs args
<clever> tilpner: something like this
<clever> and by giving both fetches a hash, it will only do the network access once
<clever> it would still need to import 2 nixpkgs, but it would exist within $NIX_PATH, so all tools use it by default
<clever> and as long as that returns a nixpkgs set, and obeys the config arg, it will work
<clever> tilpner: what if you just do NIX_PATH=nixpkgs=/bootstrap.nix
<clever> ah, i think i see what your doing
<clever> what do you keep in $NIX_PATH?
<clever> and some parts like nixos and nix-build cant easily be told to fetch from somewhere dynamicaly
<clever> the version of nixpkgs is typicaly controlled with nix-channel
<clever> why cant you fetch nixpkgs over http?
<clever> yeah
<clever> if you want to fetch a copy of nixpkgs
<clever> (import <nixpkgs>{}).fetchgit
<clever> thats usualy done like this
<clever> but you will need to know the hash of the file
<clever> tilpner: fetchurl
<clever> then systemd-askpass blocked
<clever> so it burns the cpu for 5 minutes, uncompressing all ram
<clever> oh, and it wants to restart the zram service
<clever> tilpner: nixos-rebuild wanted to restart the dhcpcd and wpa_supplicant services, so it shut the network off
<clever> tilpner: yikes, i just lost all network for over 5 minutes from my nixos-rebuild!
<clever> noobly_: what nix-shell command are you using, and what do you want different?
<clever> noobly_: you generally avoid installing things in nix
<clever> just open both nix files it makes, and paste the list of inputs in one into the other
<clever> cabal2nix will generate a nix file, then you could manualy merge the 2 nix files
<clever> you would need to get a list of haskell deps from both, concat them, and make a new env using ghcWithPackages
<clever> luigy: so it might allow building servant, but it may also complicate which servant will be loaded
<clever> luigy: i'm guessing that in addition to providing servant, it will also provide the libs servant uses
<clever> luigy: its not really simple to join the deps of 2 things
<clever> luigy: ah yeah, that would provide servant and servant-server, not their deps
<clever> i think
<clever> luigy: nix-shell -p '(haskellPackages.ghcWithPackages (ps: with ps; [ servant servant-server ]))'
<clever> yeah, the - tells it to read stdin
<clever> noobly_: nix-build -E 'with import <nixpkgs> {}; callPackage ./racket.nix {}'
<clever> also, it sounds like your making that way too complex
<clever> noobly_: you can also nix-build .... 2>&1 | gist -

2017-07-01

<clever> you would need a recursive function that checks the string length and prepends a "0"
<clever> ah, yeah, nothing to do that
<clever> spinus: not really, but you can just do "foo ${bar} baz" most of the time
<clever> hodapp: so you can then setup the container on the same port, and give it a unique ip
<clever> hodapp: nixos containers get their own instance of the networking stack
<clever> :D
<clever> that will kill performance, but it only happens once
<clever> hodapp: oh fun, lol, it reads the php-fpm config one byte at a time!
<clever> and if your running php-fpm manualy, you can copy the php.ini, edit the copy, then point php-fpm to the new php.ini
<clever> hodapp: we may also want to change display_errors = on in the php.ini
<clever> so gettingn the entire trace, from startup to first request, will give more details
<clever> and line 14 of the last paste is just confirming the file hasnt changed
<clever> and one theory, is that the first time it loaded the php file, it cached the contents, and possibly the error
<clever> it might also be doing other weird things at startup
<clever> hodapp: no real change, but i dont see the initialization from running php directly under strace
<clever> hodapp: lets see...
<clever> brb
<clever> ah, i suspected that, but didnt see anything in the module i previously linked
<clever> hodapp: can you gist the entire strace output when you manually run it?, i can check it for odd errors that explain the 502
<clever> ok, go back to tracing the nginx process, what does that show?
<clever> what is the full command you ran?
<clever> what about the strace for php-fpm?
<clever> anything new in the logs?
<clever> what is an example url?
<clever> did you stop phpfpm-main first?
<clever> hodapp: did you use strace -f?
<clever> hodapp: ah, read the phpfpm-main.service then
<clever> hodapp: and then run the thing in ExecStart with strace -f
<clever> hodapp: read the systemd unit file in /etc/systemd/system/phpfpm.service
<clever> hodapp: what does the strace look like if you stop the systemd unit, and run the full php-fpm command under strace?
<clever> id have to cross-reference the php source to see whats going on
<clever> yeah, it doesnt really make much sense
<clever> a nixos container would have nearly identical config
<clever> then you can see what its doing on startup
<clever> hodapp: it may also help to set it to 1 worker, then stop the systemd unit, and manualy run the command defined in /etc/systemd/system/phpfpm.service under strace -f
<clever> they should land in the journal for the phpfpm service
<clever> hodapp: ah, i think the 2 lines gchristensen linked will help a lot
<clever> hodapp: i saw this in another irc room about an hour ago
<clever> 2017-07-01 18:15:54 < mst> PHP isn't a language, it's a malignant perl templating engine that metastasised
<clever> hodapp: all i can think of is to mess with the error_log option in the php-fpm config file, via the nixos config
<clever> nothing special
<clever> let me double-check what i had done
<clever> yeah, that aint working
<clever> and the strace output when you add "-s 5000" ?
<clever> thats how nixos handles it 80% of the time
<clever> its usualy on the commandline passed to the daemon
<clever> ps aux | grep php-fpm
<clever> can you do that again with "-s 5000" and also pastebin the php-fpm config file?
<clever> that is odd
<clever> what does the fpm-worker strace look like now?
<clever> hodapp: it may also help to add "-s 5000" to the strace args
<clever> so now repeat the same thing agaist the php-fpm workers
<clever> which is the php-fpm socket
<clever> hodapp: it read a 404 from fd 12
<clever> [pid 281] recvfrom(12, "\1\6\0\1\0Z\6\0Status: 404 Not Found\r\nX"..., 4096, 0, NULL, NULL) = 120
<clever> 323 enableDebugging = pkg: pkg.override { stdenv = stdenvAdapters.keepDebugInfo pkg.stdenv; };
<clever> 322 # intended to be used like nix-build -E 'with <nixpkgs> {}; enableDebugging fooPackage'
<clever> boomshroom: read the code for stdenvAdapters, that shows one way to mutate a stdenv and modify its args
<clever> 323 enableDebugging = pkg: pkg.override { stdenv = stdenvAdapters.keepDebugInfo pkg.stdenv; };
<clever> 322 # intended to be used like nix-build -E 'with <nixpkgs> {}; enableDebugging fooPackage'
<clever> hodapp: try passing all of the nginx processes to strace, with strace -p <pid1> -p <pid2>
<clever> hodapp: what pid's do you see in "ps aux | grep nginx" ?
<clever> boomshroom: nix goes out of its way to remove march=native from the flags
<clever> hodapp: throw it all in a pasetbin
<clever> hodapp: i would throw strace at the nginx process, and then see what it says
<clever> boomshroom: you would need to make an override to stdenv.mkDerivation
<clever> containers/user_ns would give good performance without needing root
<clever> yeah, lol
<clever> and once you have root, you could just install full nixos, even remotely
<clever> boomshroom: give what Mic92 linked and see what error it says
<clever> its possible that they just didnt install the tools
<clever> ah, then you cant fire up your own container
<clever> boomshroom: is nsenter in $PATH?
<clever> Mic92: he wants to use nix, but lacks root
<clever> yeah
<clever> if storedir isnt set to /nix/store/, you loose all binary cache help
<clever> boomshroom: there is a builtins.storeDir, that could detect it
<clever> yeah, i think using NIX_STORE_DIR, you can force a nix to build into a dir other then where it lives itself
<clever> and the stateDir as well
<clever> so you will want to set nix.storeDir in config.nix, to enforce it staying right
<clever> i only looked at nix/default.nix
<clever> yeah
<clever> boomshroom: so you will need a config.nix that overrides it back to the right value, or the next time oh, one sec
<clever> boomshroom: the store directory for the expression defaults to /nix/store/
<clever> so that never actually works
<clever> tilpner: the root default.nix in nixpkgs has a version check, which stops you from building the new nix
<clever> tilpner: ah, ive found that that thing has never really worked
<clever> tilpner: --fast will skip that step
<clever> bbl
<clever> then copy the result over
<clever> you just need to use a machine where you have write to both /nix/store and /home/foo/.nix/store/
<clever> if you use nix to build nix, it will handle that for you
<clever> but i forget the details of how it was done
<clever> so that nix was built by nix, on a machine that did have /nix/store/
<clever> boomshroom-away: i showed osmebody how to build nix with .override before, to change the storepath
<clever> boomshroom-away: one last thing before you go
<clever> yeah, that would require building it from scratch
<clever> the curl script will skip sudo if you can write to /nix
<clever> all you need, is ownership of /nix/
<clever> you dont technicaly need root to install nix
<clever> anything you set in _module.args gets passed to all modules