<clever>
jsgrant: have you ran memtest86 on the hardware recently?
<clever>
when ran as root
<clever>
jsgrant: what does nix-channel --list say?
<clever>
jsgrant: what kind of weirdness is it doing?
<clever>
cant think of anything else at the moment
<clever>
and thats breaking everything
<clever>
its possible that idea is trying to clean the env up before running gradle
<clever>
not sure then
<clever>
was idea started from inside the nix-shell?
<clever>
nix goes out of its way to not include headers and such when you install a package
<clever>
installing the libraries wont help anything
<clever>
not sure what gradle would be doing differently to mess things up
<clever>
with import <nixpkgs>{}; stdenv.mkDerivation { ...
<clever>
you need to just run "nix-shell default.nix"
<clever>
mellowmaroon: -p doesnt load default.nix
<clever>
mellowmaroon: can you gist the exact contents, and the command you ran?
<clever>
mellowmaroon: it has to go into buildInputs
<clever>
but that will likely behave differently if the host lacks systemd
<clever>
and breaks the host
<clever>
also, every time i try to stop the systemd, it stops the wrong systemd
<clever>
then*
<clever>
jake_: you would need to setup sshd before you make the tarball, and they it might work
<clever>
jake_: systemd starts, but i cant get nsenter to work, so no shells
<clever>
jake_: its on my github now
<clever>
jake_: taking a break right now, but i can commit what i have if you want to play with it
<clever>
but nox will cache the package list
<clever>
all nix tools will read it on start, no need to refresh them
<clever>
once enabled, nox will probably find it
<clever>
if you try to build something unfree, it will tell you: nix-build '<nixpkgs>' -A google-chrome
<clever>
you need to set it in ~/.config/nixpkgs/config.nix
<clever>
you also need to enabled it in the config.nix
<clever>
that doesnt effect nix-env and nox
<clever>
mellowmaroon: have you already enabled unfree packages in config.nix?
<clever>
yep
<clever>
yeah
<clever>
but nix-shell -p firefox, will give a shell with firefox pre-compiled
<clever>
nix-shell '<nixpkgs>' -A firefox, will give you a shell suitable for compiling firefox from source
<clever>
-p or -A?
<clever>
yeah
<clever>
and if your re-building the same package 200 times to work out a bug, no spam in your generation list
<clever>
no generations, no firefox "installed" in anything
<clever>
and when your done, delete the result symlink
<clever>
so you can then ./result/bin/firefox to run it
<clever>
this will create a symlink called result, pointing to the firefox storepath
<clever>
nix-build '<nixpkgs>' -A firefox
<clever>
and for testing normal programs, i prefer nix-build over nix-env
<clever>
which will build and activate, but not create a generation, and the changes are undone upon reboot
<clever>
for nixos, there is "nixos-rebuild test"
<clever>
ways*
<clever>
mellowmaroon: you can also avoid creating generations in a few days
<clever>
mellowmaroon: no proper way to do it, only by manualy messing with key symlinks
<clever>
digitalmentat: if --roots says that the only roots are in your profile, you can safely delete the unused generations (make sure not to delete the active one)
<clever>
and dont force --delete
<clever>
digitalmentat: next thing id check is nix-store --query --roots and nix-store --delete, see if you can delete any of the corrupt things
<clever>
digitalmentat: yeah, it will only be able to repair things that are on the nixos cache
<clever>
thats just not how nix is meant to be used
<clever>
you shouldnt ever install libraries like that
<clever>
ah, it might be that the presense of mesa_noglu is breaking the runtime stuff
<clever>
mellowmaroon: maybe, the mesa_noglu package should also let you compile/link against opengl
<clever>
sphalerite: i think a lack of ipc namespacing is what caused the crosstalk in the poweroff command
<clever>
Dezgeg: yeah, just need to make the guest not mess with the network stack any
<clever>
but that would complicate getting internet
<clever>
the container firewall also failed to come up right, because i didnt give it a network namespace
<clever>
probably needs an ipc namespace also
<clever>
yeah, it borked dbus
<clever>
[16401:16451:0615/142845.850724:ERROR:bus.cc(427)] Failed to connect to the bus: Failed to connect to socket /tmp/dbus-0MkGeEjdoV: Connection refused
<clever>
which defeats the entire point of containers!
<clever>
this is why i only ever play with containers in vm's
<clever>
sphalerite: and *boom*, "systemctl poweroff" killed the host networking, and ctrl+c to systemd killed display-manager, lol
<clever>
yeah, -r definitely did something good
<clever>
oh, maybe i also need -r
<clever>
sphalerite: cant seem to get nsenter to work right
<clever>
sphalerite: ah, i see, "unshare --fork --pid --mount-proc" will create a mount namespace, and mount a new proc over /proc, but / is still the host
<clever>
playing with it a bit more...
<clever>
sphalerite: rm -rf --one-file-system !!
<clever>
sphalerite: but then i will need to be available on the host, hmmm
<clever>
sphalerite: i may want to run the unshare before the chroot then
<clever>
sphalerite: i see, unshare is trying to access /proc from inside the chroot
<clever>
catern: yeah, then it probably cant auto-detect the binary cache
<clever>
the channel should be a directory, containing nixexprs.tar.gz, and binary-cache-url
<clever>
LnL: the nix-channel man page explains it
<clever>
nope
<clever>
sphalerite: i'm guessing it may need some mkdir
<clever>
sphalerite: the register script in this derivation will add it to binfmt-misc, and the nix patch will convince nix-daemon that the host can run arm binaries