2019-09-02

<clever> superbaloo: doing a native build with qemu-user may have better luck
<clever> superbaloo: ive heard that a large portion of nixos doesnt support cross-compiling, and it wont be possible to cross-compile the whole os
<clever> superbaloo: and how are you cross-compiling pango?
<clever> Parabox: this is why you should always validate the backup strat works
<clever> and a native drv adds it to path
<clever> ldd comes from glibc
<clever> superbaloo: can you pastebin your nix expr?
<clever> superbaloo: ldd is part of the stdenv, and is already supplied to you
<clever> superbaloo: libraries always go into buildInputs, while build-time tools like pkgconfig and cmake go into nativeBuildInputs
<clever> superbaloo: when cross-compiling, nativeBuildInputs come from the host, and buildInputs come from the target
<clever> Parabox: my only guess would be the xfs irc channel
<clever> Parabox: you would need somebody that knows the xfs internals heavily, to be able to recover something like this
<clever> kaliumxyz: systemd didnt call waitpid() on its children
<clever> Parabox: possibly, i would also recomend just switching to zfs, since it has backup stuff built into it, that wont have these issues (snapshots, send/recv)
<clever> Parabox: to ensure nothing changes while making the copy
<clever> Parabox: you must run `zfs_freeze` before doing that, and then un-freeze it afterwards
<clever> Parabox: that backup wont be atomic, so the data at the start of the disk wont match up with the data at the end of the disk, which can lead to the entire backup being unusable
<clever> bakakuna: with what arguments?
<clever> bakakuna: pkgs.fetchgit or builtins.fetchGit?
<clever> kaliumxyz: yep
<clever> Parabox: how was the backup made? how was it restored?, do you have the exact commands saved?
<clever> kaliumxyz: that looks like a bug in systemd, try just rebooting?
<clever> Parabox: what does xfs_repair say when ran on centos_jackbox-root?
<clever> Parabox: what is giving the error then?
<clever> kaliumxyz: can you pastebin the output of `ps -eH x`?
<clever> Parabox: and which are you trying to mount?
<clever> Parabox: did you run blkid on the lv or the pv?
<clever> kaliumxyz: `ps -eH x`, what is the parent of firefox-wrapped?
<clever> kaliumxyz: does the cpu usage overall agree?, zombie processes cant consume cpu
<clever> paste that line
<clever> kaliumxyz: where does it say that?
<clever> kaliumxyz: youll also notice, its using 0 ram and 0 cpu
<clever> kaliumxyz: it will disapear when the parent process calls waitpid (or is itself killed)
<clever> kaliumxyz: defunct means the process has already been killed
<clever> Parabox: and vgdisplay -C ?
<clever> kaliumxyz: what does `ps aux` say about it?
<clever> kaliumxyz: what does -9 do to it?
<clever> Parabox: what does `pvscan` say?
<clever> Parabox: does blkid identify the fs correctly?
<clever> ij: working directory is also checked
<clever> ij: on linux, it peeks at /proc to see what files are: open, mmap'd, or in env vars
<clever> ij: if the nix-shell is open, its deps cant be GC'd, thats the simplest option
<clever> hyperfekt: ^^
<clever> ryantrinkle: auto will either read /nix/store directly (if you have write perms) or talk to nix-daemon via a unix socket

2019-09-01

<clever> simpson: avahi could also be used to do it
<clever> then you just need to advertise your arch and core-count over a udp broadcast packet, at regular intervals
<clever> and if the machine stops sending beacons, remove it from the pool
<clever> simpson: ive had plans before, on making a custom daemon, that will listen for beacons from netbooting build slaves, and dynamically add them to such a file
<clever> simpson: and hydra-provisioner just edits a secondary file, not managed by nixos
<clever> simpson: hydra can take a list of files, that behave the same as /etc/nix/machines
<clever> simpson: have you seen how the hydra auto-scale stuff works?
<clever> nix-darwin manual
<clever> simpson: so i currently have a netboot not-os image, that i use to turn rpi's into build slaves
<clever> simpson: ive not had much sucess yet with cross-compiling not-os, but it should be possible
<clever> infinisil: i would do something like that with either haskell-init, or a bare unikernel
<clever> infinisil: overkill much? :P
<clever> simpson: so it depends on if you want it as a general purpose system, or a specialized system that just does 1 thing and never changes
<clever> simpson: not-os currently lacks any kind of nixos-rebuild style command, so you have to reflash the boot media, and reboot, any time you want to change things
<clever> ryantm: firmware is device-side code, that some hardware needs to do anything
<clever> ryantm: modules are kernel side code to add features to linux
<clever> enteee: thats a limitation of qemu user networking
<clever> ryantm: drivers are not part of the firmware, if you go back to the working system, run `modinfo r8822be` and figure out which derivation the file is in
<clever> Kernel driver in use: iwlwifi
<clever> ryantm: then check if that module is present in lsmod when broken, try loading it with modprobe
<clever> ryantm: `lspci -v` will tell you what driver is using a given card, check that on the working version
<clever> kandinski: find your own function to convert a float to a string, then <<, that string
<clever> kandinski: the c++ stdlib should supply a << operator, for ostream and double, but does it do what you expect?
<clever> with a double
<clever> kandinski: the problem would be the operator to apply << to whatever str is
<clever> it tests after it has built everything
<clever> the nixos tests work in a similar way
<clever> ris: you could run the test in a 2nd derivation, that you optionally depend on
<clever> i think it would only require the .drv to eval, and return the outPath
<clever> DariusTh`: yeah
<clever> DariusTh`: what happens if you `export home=/homeless-shelter` ?
<clever> text editors tend to save config in $HOME
<clever> DariusTh`: if its set to empty, it will likely break things
<clever> DariusTh`: --pure doesnt touch $HOME, i believe, you can confirm with `echo $HOME`
<clever> DariusTh`: try setting HOME to an empty dir, after you nix-shell
<clever> vvbb[m]: in your case, python3Packages.callPackage
<clever> ,callPackage vvbb[m]
<clever> it should fail at build time, and not put bad input into the json
<clever> i can see how that might mess up
<clever> oh, which is true if absent
<clever> then it would be the systemd default...
<clever> ivan: what about DynamicUser?
<clever> ivan: what rev of nixpkgs are you on?
<clever> ivan: that shouldnt do it...., what did the jq find?
<clever> ivan: something like this maybe
<clever> [root@system76:~]# jq < /nix/store/3kpqr704gifc7dgsfifpiqcknkngllqw-users-groups.json '.users | map(select(.name == ""))'
<clever> [root@system76:~]# nix-store -qR /run/current-system | grep users-groups
<clever> ivan: check the user-groups.json file in your closure
<clever> ivan: you may need to just manually delete that line to fix the issue

2019-08-31

<clever> _zincy: you can probably add overlays around line 1-4, to accept it along with the json
<clever> _zincy: line 13, where it does import src {}, you want to do `import src { overlays = something; }
<clever> _zincy: depends on what pkgs-from-json.nix is doing
<clever> _zincy: or you need to use several haskell overlays, perhaps isolate the haskell-overridez one from the other thing thats using beam-core
<clever> _zincy: it has to go into the default.nix, within haskell-overridez
<clever> _zincy: no, fetchTarball doesnt accept patchFlags
<clever> _zincy: you could also do it with the overrides, but those are in haskell-overridez.nix which you havent pasted
<clever> visrelic: where you had `import ./default.nix`
<clever> _zincy: thats passing patchFlags to all of haskellPackages, not to a single package
<clever> visrelic: pkgs.callPackage ./. {}
<clever> visrelic: now you need to use callPackage instead of import
<clever> visrelic: you need to swap the comment on lines 1/2 of default.nix, then callPackage will work
<clever> visrelic: can you put both files into a gist
<clever> visrelic: the callPackage in the overlay, takes the path to your default.nix
<clever> Miyu-saki: we could also try using the libQt5WebEngineCore from nixpkgs, rather then the one the appimage ships
<clever> visrelic: or you make your own module, in the same dir as default.nix, use ./default.nix, and then put that module into imports, imports = [ /path/to/module.nix ];
<clever> visrelic: the path has to be relative to configuration.nix
<clever> Miyu-saki: thats where lddtree comes into play
<clever> > glib.outputs
<clever> > glib.output
<clever> ah
<clever> > "${glib.out} vs ${glib.lib}"
<clever> trevthedev: not sure why its not finding it
<clever> oh wait, there it is
<clever> trevthedev: i dont see glib in the 2nd rpath
<clever> trevthedev: had the lddtree output changed?
<clever> trevthedev: so it must be in libQt5WebEngineCore.so.5's rpath, which the for loop is doing
<clever> trevthedev: if you look at the lddtree, youll see that glib was used by libQt5WebEngineCore.so.5
<clever> trevthedev: both rpath's
<clever> trevthedev: you need to add glib to the rpath
<clever> ,locate libglib-2.0.so.0
<clever> trevthedev: you commented out the line that fixes mcpelauncher-ui-qt's rpath
<clever> trevthedev: and the latest copy of the nix file?
<clever> trevthedev: can you pastebin the output of lddtree on the binary?
<clever> trevthedev: try changing it to $out/usr/lib/*.so*
<clever> trevthedev: try running lddtree on mcpelauncher-ui-qt
<clever> trevthedev: which you omited in the question
<clever> 2019-08-31 17:58:28 < trevthedev> so i just put for $lib in $out/usr/lib/*.so; do patchelf --set-rpath .... $lib;?
<clever> trevthedev: the last word in this line
<clever> 2019-08-31 17:57:40 < clever> trevthedev: 2019-08-31 17:48:24 < clever> trevthedev: for $lib in $out/usr/lib/*.so; do patchelf --set-rpath .... $lib; done
<clever> trevthedev: compare what i gave to your code
<clever> trevthedev: is the ;done present?
<clever> trevthedev: yes
<clever> trevthedev: the same thing your using for the other --set-rpath
<clever> trevthedev: did you replace the .... with the ${lib.makeLibraryPath ...} ?
<clever> trevthedev: yeah
<clever> 2019-08-31 17:47:57 < clever> trevthedev: so you need to set the rpath on all of the libraries in $out/usr/lib/
<clever> 2019-08-31 17:47:45 < clever> trevthedev: when binary a loads library b, and b needs a c, it uses the rpath on library b
<clever> trevthedev: 2019-08-31 17:48:24 < clever> trevthedev: for $lib in $out/usr/lib/*.so; do patchelf --set-rpath .... $lib; done
<clever> trevthedev: did you try setting the rpath on everything in $out/usr/lib/ yet?
<clever> visrelic: nixpkgs.overlays = [ (self: super: { clarissa = pkgs.callPackage ./clarissa.nix {}; }) ]; is a basic overlay to solve this problem
<clever> visrelic: overlays just enable you to do pkgs.clarissa instead of what i gave
<clever> visrelic: then do ExecStart = "${import /path/to/default.nix}/bin/clarissa -p";
<clever> visrelic: how did you generate that store path?
<clever> visrelic: you can use import or callPackage to load the other nix file, and then put that into systemd.packages
<clever> visrelic: you can use import or callPackage to load the other nix file, and then put that into systemd.packages
<clever> trevthedev: for $lib in $out/usr/lib/*.so; do patchelf --set-rpath .... $lib; done
<clever> trevthedev: so you need to set the rpath on all of the libraries in $out/usr/lib/
<clever> trevthedev: when binary a loads library b, and b needs a c, it uses the rpath on library b
<clever> trevthedev: no such file or directory means the interpreter isnt set
<clever> Orbstheorem: look at linuxPackagesFor in all-packages.nix, and the nix files it refers to
<clever> mc-bedrock/usr/bin/mcpelauncher-ui-qt: error while loading shared libraries: libglib-2.0.so.0: cannot open shared object file: No such file or directory
<clever> trevthedev: also, you dont need to be in nix-shell when testing this
<clever> did you save the file?
<clever> the screenshot shows otherwise
<clever> it says no such file or directory, because its trying to patch /run/opengl-driver/lib
<clever> trevthedev: the : is missing still
<clever> thats more of a bug with the gpu drivers
<clever> trevthedev: try adding mesa to makeLibraryPath then?
<clever> trevthedev: does libEGL.so exist in /run/opengl-driver/lib ?
<clever> you have a space there, which is giving patchelf too many args
<clever> trevthedev: the rpath is seperated with :'s
<clever> trevthedev: can you paste the rpath line here?
<clever> trevthedev: after $out/usr/lib
<clever> trevthedev: just /run/opengl-driver/lib
<clever> trevthedev: add it to the rpath, the same way i added $out/usr/lib/
<clever> trevthedev: libEGL.so is in /run/opengl-driver/lib
<clever> trevthedev: for the 32bit binaries, yes
<clever> trevthedev: i updated the gist again
<clever> yeah
<clever> it must be done in a nix file, not a normal shell
<clever> oops, --no-preserve=mode did a -x to everything!
<clever> --set-interpreter $(cat ${pkgsi686Linux.gcc}/nix-support/dynamic-linker), for the 32bit interpreter
<clever> trevthedev: in the nix file i gave, look at line 14
<clever> and for the 32bit interpreter
<clever> trevthedev: patchelf --set-rpath ${lib.makeLibraryPath [ pkgsi686Linux.zlib ]} usr/bin/some-32bit-binary
<clever> trevthedev: this will generate an rpath that uses the 32bit zlib
<clever> > lib.makeLibraryPath [ pkgsi686Linux.zlib ]
<clever> for 32bit binaries, it will need to be slightly different
<clever> trevthedev: just keep adding patchelf commands as normal until it works
<clever> trevthedev: same gist url as before, just refresh
<clever> [clever@amd-nixos:~/apps]$ nix-build mc-bedrock.nix -o mc-bedrock -A patchedBedrock
<clever> trevthedev: yeah, let me update the gist once more
<clever> [--set-rpath RPATH]
<clever> [--set-interpreter FILENAME]
<clever> [nix-shell:~/apps]$ cat $NIX_CC/nix-support/dynamic-linker
<clever> /nix/store/xqs95fqkjb1kd102yjv5h5q57gcsafb3-glibc-2.27/lib/ld-linux-x86-64.so.2
<clever> trevthedev: https://gist.github.com/5af745e591765f082e1a41a10ac20889 is enough to extract it
<clever> tilpner: i already packaged multimc, which uses the java edition
<clever> ah, extract rather then wrap
<clever> and ignore the entire appimage stuff
<clever> trevthedev: at this point, it would be simpler to just forcibly extract the files, and then patchelf it like any other nix package
<clever> https://gist.github.com/5af745e591765f082e1a41a10ac20889 makes the build process entirely 32bit, so it cant unpack the appimage
<clever> trevthedev: oh, or not, its a 64bit appimage, containing a 32bit program
<clever> trevthedev: oh, you ran file on the wrong thing when i asked you earlier, that makes the solution a bit simpler, one min
<clever> trevthedev: let me see what happens if i try to reproduce it, ive got an account
<clever> tilpner: do you see 2 zlibs on your end?
<clever> trevthedev: the problem is likely due to the 2nd zlib that is 32bit, but its not clear how it got into the mix
<clever> trevthedev: what about `nix-instantiate --eval -E builtins.currentSystem` ?
<clever> trevthedev: `file -L` to make it follow links
<clever> trevthedev: what about `nix-instantiate --eval -E builtins.currentSystem` ?
<clever> is one a 32bit?
<clever> trevthedev: for both of the non-dev ones, run `file <thatpath>/lib/libz.so.1` ?
<clever> trevthedev: nix-store -qR ./result | grep zlib ?
<clever> trevthedev: run `file` on it
<clever> trevthedev: is mcpelauncher-client a 32bit or 64bit binary?
<clever> freeman42x[NixOS: your not really supposed to be using pip on nixos
<clever> ivan: the whole point of nix-shell is to handle that kind of thing for you
<clever> freeman42x[NixOS: anything you add to systemPackages will appear within PATH
<clever> TallerGhostWalt_: you need to clone yarn2nix from github
<clever> vvbb[m]: because thats how you load a file that starts with { lib, buildPythonPackage, fetchPypi }:
<clever> vvbb[m]: then use python3Packages.callPackage
<clever> vvbb[m]: yep, use nix-build -E '(import <nixpkgs> {}).pythonPackages.callPackage ./foo.nix {}'
<clever> vvbb[m]: pythonPackages.callPackage then
<clever> vvbb[m]: 2019-08-31 14:01:58 < Orbstheorem> vvbb[m]: As clever suggested, you can try `nix-build -E '(import <nixpkgs> {}).pythonPackages.callPackage ./foo.nix {}'`
<clever> ,callPackage vvbb[m]
<clever> vvbb[m]: you need to use callPackage
<clever> vvbb[m]: its usually easy to go from a nix-shell to a nix-build
<clever> vvbb[m]: what part are you stuck at?
<clever> i keep having to refer to lib/types.nix
<clever> rycee: :D, i can never remember which one is the right one to use
<clever> vvbb[m]: and if you write a proper package, and nix-build the thing, it will remain built, and you can just run it directly
<clever> vvbb[m]: nix will cache the results of the build, so if you re-run nix-shell again in the future, it will be faster
<clever> vvbb[m]: any error above that?
<clever> vvbb[m]: which one exited with a non-zero status?
<clever> vvbb[m]: which dependency?
<clever> pythonPackages.callPackage then
<clever> ,callPackage
<clever> Orbstheorem: yep
<clever> vvbb[m]: nix-build
<clever> let cmake make a mess, then clean up after it :P
<clever> Orbstheorem: a postInstall on the nix side, to just `mv $out/include $dev/include` would be simplest
<clever> Orbstheorem: personally, i just write my cmake files to use the $dev env var, and dont bother with making it work outside of nix
<clever> vvbb[m]: write a nix package for it
<clever> Orbstheorem: or have a postInstall that does `mv $out/include $dev/include`
<clever> Orbstheorem: you would have to modify the cmake file to copy headers to $dev/include/
<clever> vvbb[m]: the nixpkgs manual explains that
<clever> vvbb[m]: i would package the python script properly with nix, so you can run it without python being in $PATH
<clever> vvbb[m]: probably better to just let nix do everything, and not install pip
<clever> wrapping the string in parans forces it to be treated as an expr
<clever> and its completely non-obvious
<clever> Orbstheorem: it does some fancy logic to detect if the string is a path or an expr
<clever> nix build '(with import <nixpkgs> {}; pkgs.hello)'
<clever> Orbstheorem: nix build can also take an expr
<clever> Orbstheorem: nix-build -E can take the whole string, without having to write it to a temp file
<clever> Orbstheorem: dont use =( then?
<clever> maralorn: it was in #nixos-dev, 2019-08-31 11:10:03 < clever> https://github.com/cleverca22/nix-tests/tree/master/ip-magic
<clever> Orbstheorem: :r is supposed to do it
<clever> Orbstheorem: you dont need the $PWD, just ./liblms7002m.nix will do it
<clever> maralorn: there is the ip-magic stuff i linked earlier, i wrote it for fun, then never got around to actually using it
<clever> maralorn: seemed a bit odd for the same question to pop up twice in the same day
<clever> ah, heh
<clever> andi-: ^^
<clever> you can also change nix-shell to nix-build on the above cmd, to just build it
<clever> thats another way to open the shell, and its a new process each time, so it cant cache things
<clever> nix-shell -E 'with import <nixpkgs> {}; callPackage ./foo.nix {}'
<clever> and wont reload them on its own
<clever> nix repl caches the files it parses
<clever> Orbstheorem: quit out of nix repl and try again, something is fishy with https://paste.gnugen.ch/raw/xalN
<clever> Orbstheorem: what about `echo $PYTHONPATH` ?
<clever> Orbstheorem: definitely not the wrapper from withPackages
<clever> Orbstheorem: `file -L` ?
<clever> Orbstheorem: that doesnt look like a wrapper, what does `file` say it is?
<clever> Orbstheorem: you previously used python2 to test it, but the pastebin is using python, try python2 as well?
<clever> 2019-08-31 12:48:10 < Orbstheorem> And running `:s callPackage ./package {}` in the repl and then `python2 -c 'import Cheetah.Template' confirms that the python package is not in the derivation's build env.
<clever> Orbstheorem: what error does it give?, what does `which --all python2` give in the shell?
<clever> too many python questions at once!
<clever> possible
<clever> jollyjester: then replace 27 with 3
<clever> jollyjester: try just nativeBuildInputs = [ python27 python27Packages.cheetah ]; ?
<clever> jollyjester: the python setuphook should add inputs to the PYTHONPATH
<clever> nixops just hasnt been updated to deal with multi-user on darwin
<clever> yeah, multi-user has better stability and reproducability
<clever> if its setup in single-user mode, nixops just works
<clever> yosemitesam: of note, the bug only occurs if your using a multi-user install of nix
<clever> yeah, adding it to the wiki may also help
<clever> `sudo NIX_PATH=$NIX_PATH` just undoes sudo breaking things, so the whole value is used
<clever> so it would be `-I nixpkgs=/nix/var/nix/profiles/per-user/root/channels/nixpkgs`
<clever> but `sudo NIX_PATH=$NIX_PATH` is probably simpler
<clever> yosemitesam: you need to look for the nixpkgs=/something in the echo output, and copy that part
<clever> yosemitesam: and what msg did it give when saying it ignored it?
<clever> yosemitesam: what -I did you use?
<clever> yosemitesam: sudo messes with the env vars and unsets $NIX_PATH, try using `-I nixpkgs=/path/to/nixpkgs`, find that via `echo $NIX_PATH`
<clever> yeah
<clever> FRidh: but the module isnt looking at python.qtile, so that still wont have any difference
<clever> ,callPackage visrelic
<clever> cjpbirkbeck: the module is using pkgs.qtile, not pkgs.python.qtile, so that override has zero effect
<clever> ,pastebin cjpbirkbeck
<clever> visrelic: callPackage assumes your file begins with the { stdenv }: style
<clever> yosemitesam: i think sudo may fix that, https://github.com/NixOS/nixops/issues/984 is the issue about it
<clever> visrelic: an overlay or packageOverride just puts it into pkgs, so you can instead do: systemd.packages = [ pkgs.thing ];