<clever>
Lisanna: can you gist the full output of nixos-rebuild and "env" ?
<clever>
Lisanna: those should already be in $NIX_PATH by default, did you get that shell via strange means?
<clever>
Lisanna: if you unset NIX_REMOTE, then commands running as root will just bypass the nix-daemon, and obey the normal env
2017-11-09
<clever>
at that point, your better off writing a nix expression for it
<clever>
and you need to escape the $( so it runs inside the shell, not outside
<clever>
yeah
<clever>
pkgconfig will also need to be added to the -p list
<clever>
it only works when loaded properly by nix-shell or nix-build
<clever>
slack1256: the gcc you installed with nix-env/systemPackages is broken and wont be able to find any libraries
<clever>
slack1256: you may also need "-p gmp gcc"
<clever>
i had to "type qmake" inside the nix-shell, then point creator to that binary
<clever>
strange, mine wasnt able to find any library when i did that
<clever>
that would probably do CPU rendering
<clever>
yeah
<clever>
WilliamHamilton: `nix-store -qR /run/current-system` will return all of the storepaths involved in the current nixos, which should help reduce the search space
<clever>
WilliamHamilton: and thats also going to find a lot of old versions that may cause more problems
<clever>
WilliamHamilton: some of those are buildEnv's merging many together
<clever>
dlopen() isnt tested by ldd
<clever>
does it say its looking for libEGL?
<clever>
you should be able to
<clever>
what does ldd say?
<clever>
does it keep trying that filename in other locations?
<clever>
once it fails, it will print an error and stop
<clever>
usually the last page or 2
<clever>
then the threads wont interleave in the logs
<clever>
it also helps to use "-ff -o logfile"
<clever>
WilliamHamilton: and what directory are you pointing LD_LIBRARY_PATH at?
<clever>
WilliamHamilton: 32bit or 64bit?
<clever>
you can boot back into an installer like env, and do whatever repair you want
<clever>
the rescue method in grub is more for repairing nixos later on
<clever>
ldlework: maybe you want to use impureEnvVariables
<clever>
iqubic: yeah, i dont know whats up with that
<clever>
iqubic: id say it looks good like that, and just keep going
<clever>
ldlework: your telling nix what the hash of the output is ahead of time, and nix enforces that you always produce that value
<clever>
ldlework: fetchgitprivate is special, because its a fixed-output derivation
<clever>
whole*
<clever>
ldlework: the would point of nix and nix-build, is that every env variable gets hashed, and any changes to them re-start the build
<clever>
iqubic: what if you instead try "blkid /dev/sda /dev/sda*" ?
<clever>
but it will only work under nix-shell
<clever>
ldlework: if its just an env variable, it should be safe
<clever>
that says sda2 is now formated with zfs
<clever>
iqubic: imgur.com
<clever>
then anybody that can access /tmp/hax (its best to chmod it right) can use the agent
<clever>
ldlework: so now ssh-agent can only detect socat, running as root, and it trusts root
<clever>
ldlework: so socat has to enter the mix and act as a proxy running as root
<clever>
ldlework: the real hack, is that ssh-agent detects the "wrong" user (nixbld1) is connecting to your agent, and kicks them out for security reasons
<clever>
BlessJah: QT breaks that, ive opened an issue for just this problem
<clever>
ldlework: your running the buildPhase function, which is the default, but there is also $buildPhase, with your override
<clever>
ldlework: ah, thats a odd quirk in bash
<clever>
BlessJah: i think so
<clever>
BlessJah: try upgrading both wireshark and virtualbox, and look for any other QT programs in nix-env
<clever>
BlessJah: you have different QT programs in nix-env, of different versions, all of them have to be installed at once
<clever>
ldlework: setup is what ran buildPhase, and now buildPhase is recursviely running setup, which runs buildPhase, which runs setup
<clever>
ldlework: line 8 is the problem
<clever>
ldlework: can you gist the shell.nix?
<clever>
2017-11-09 14:06:24 < iqubic> Currently the way I have it set up is /dev/sda1 is /boot. /dev/sda2 is Windows FS. /dev/sda3 is a 20GB partition that I can Read and Write to from both OSes and /dev/sda4 is going
<clever>
2017-11-09 14:07:21 < iqubic> So I only need to take /dev/sda4 and partition that.
<clever>
ldlework: its best to instead set the right phases
<clever>
ldlework: i dont think nix-shell supports builder
<clever>
iqubic: i think so
<clever>
ah, then its not configured well
<clever>
iqubic: you may want to run wipefs on /dev/sda4 to remove traces of the old FS
<clever>
ldlework: yeah
<clever>
adelbertc: yeah, you can probably replace it with an override over nix
<clever>
iqubic: yeah
<clever>
ldlework: none of the steps run, it just drops you into a shell with the build deps, and a genericBuild bash function
<clever>
adelbertc: editing anything in /nix will break things
<clever>
adelbertc: is it a symlink?
<clever>
-o for pool wide properties, -O for properties on the root dataset
<clever>
-O atime=off
<clever>
this one is mostly video files
<clever>
naspool/nas 1.07x 1.20T 1.27T lz4
<clever>
NAME RATIO USED LUSED COMPRESS
<clever>
iqubic: this dataset is a mix of lz4 and gzip, and also takes up less then half the space
<clever>
amd/nix 2.16x 69.0G 135G gzip-9
<clever>
NAME RATIO USED LUSED COMPRESS
<clever>
just /nix alone is compressed to half its size
<clever>
tank/nix 2.04x 10.8G 20.2G lz4
<clever>
NAME RATIO USED LUSED COMPRESS
<clever>
iqubic: its nothing like the c64 days where they messed with bit-rate of the drive to squeeze in more bits
<clever>
iqubic: nope
<clever>
then every time chrome had a segfault, it would lockup for nearly a minute, while the 2gig coredump was written to disk
<clever>
one day, i set my desktop to use gzip-9, while systemd-coredump was enabled
<clever>
gzip-9 saves more, and has a noticable hit on performance
<clever>
iqubic: lz4 uses less cpu
<clever>
adelbertc: it probably wont
<clever>
iqubic: i name mine after the hostname
<clever>
adelbertc: but you can just try setting up /etc/nix/machines first, and see if it works, it may already be configured
<clever>
adelbertc: not sure if darwin has an easy way to read the env
<clever>
hyper_ch: i'm getting a 4x ratio on docker
<clever>
i also made a dedicated /var/lib/docker pool, with dedup enabled
<clever>
dedup is for heavy VM use, it will merge identical blocks
<clever>
it can almost double your usable space, depending on data
<clever>
so anything you write before turnign on compression, remain uncompressed
<clever>
but some like compression only take effect for writes happening after its set
<clever>
iqubic: most of the options can also be changed at a later time
<clever>
adelbertc: and it may already be fully configured to use /etc/nix/machines
<clever>
adelbertc: for darwin, those have to be set in the environment of the nix-daemon process
<clever>
iqubic: you also need to add /dev/sda4 at the end
<clever>
hyper_ch: afternoon
<clever>
iqubic: its all inside an if statement on line 45
<clever>
iqubic: encrypted root filesystem, its optional
<clever>
yeah
<clever>
then just nixos-generate-config and nixos-install
<clever>
then 84 to mount the rootfs, and 87-88 to mount everything else (change the type on 88)
<clever>
line 78-81 of justdoit will format $ROOT_DEVICE with zfs, you can skip 76
<clever>
UEFI?
<clever>
kk
<clever>
and then adjust what partition names you pass to the rest of the commands
<clever>
youll want to partition it differently then, either using gparted or normal fdisk
<clever>
iqubic: that bash script will try to wipe the entire disk, so your dual-boot would go away
<clever>
ocharles: can you put a censored copy of the default.nix up on gist?
<clever>
ocharles: can you link your project on github?
<clever>
ocharles: and then default.nix will return json with a list of objects like spec.json
<clever>
ocharles: you point hydra to spec.json, and it will then run default.nix with the inputs defined on lines 12-17 of spec.json
<clever>
ocharles: it also relies on spec.json in the same directory
<clever>
ocharles: the one you linked has a dummy input defined on line 1, just run "nix-build jobsets/default.nix -A jobsets" and you can test it locally
<clever>
ocharles: that file handles declarative jobset management, it must return a set with just .jobsets (line 86) which contains a json file describing all jobsets in the project