<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>
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>
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?