<clever>
mbrock: hydra has a config option where you just give it the accesskeys
<clever>
apostolis: --show-trace will spit out the path of the nix expression that is giving the error
<clever>
apostolis: do it again with --show-trace, and then look at the path its pointing to
<clever>
taaperotassu: yay
<clever>
have you tried the above command yet?
<clever>
akamaus: one trick is to run this: phases=unpackPhase genericBuild
<clever>
akamaus: but bash allows functions and variables by the same name, so "unpackPhase" and "eval $unpackPhase" can potentialy do different things
<clever>
akamaus: every variable in the derivation becomes an environment variable
<clever>
sounds like the usb key just came uplugged for a moment
<clever>
yeah, that should fix it
<clever>
maybe you bumped it by mistake?
<clever>
did anything happen to the cd/usb your booting from?
<clever>
one does it via wpa_supplicant, the other does it via network manager
<clever>
yeah
<clever>
though in my case, i have brought the network up manually (no services to help) on a display-less laptop (blindly typing into the shell)
<clever>
but that still needs network
<clever>
one of the first things i do is enable sshd and then ssh in from another more capable machine
<clever>
LainuxUser: it just expects you to boot it normally, but you could also chroot it
<clever>
LainuxUser: thats what nixos-install does
<clever>
sphalerite: convicing the entire userbase to move is a an even bigger issue :P
<clever>
sphalerite: that reminds me, teamspeak is non-free, and depends on a special build of the chrome source (via a qt library), and hydra doesnt pre-build that
<clever>
LainuxUser: what things is it building?
<clever>
jasom: every new install i have done in the last ~2 years has been nixos
<clever>
jasom: same, i cant even be bothered to upgrade that last gentoo machine
<clever>
Ralith: only time ive ever seen the undo button fail, is when people ran nixpkgs-unstable, and it happened to break the grub config
<clever>
ah
<clever>
i only ever ran into that because my mp3 player was "full" at only ~5% usage
<clever>
Dezgeg: ive had it happen on a 4gig SD card before, dont think fat16 cant go that big
<clever>
hmmm, that usually took minutes, maybe the extra 16gig of ram i gave the machine has helped
<clever>
934243
<clever>
real 0m5.470s
<clever>
$ time ls -U /nix/store/.links/ | wc -l
<clever>
FAT is even worse in some areas, the root directory has a hard upper limit on the number of files in the root directory
<clever>
they dont expect you to put 1000's of files in a single directory
<clever>
splitting it up into 255 smaller directories makes it faster, even if you read all of them, just due to poorly designed FS's
<clever>
Dezgeg: but if you want to iterate over the entire directory, it can be abnormally slow
<clever>
Dezgeg: when you want to read a file of a known name, the FS can use things like b-tree's to instantly find it
<clever>
Dezgeg: weird quirks in the filesystem layer
<clever>
vs not linking small-ish files
<clever>
but making more subdirs under .links would give more disk savings and make it faster
<clever>
ah yeah, that would help some
<clever>
doing the same thing git does may help
<clever>
sphalerite: ive found that the biggest performance cost is just the readdir on large directories, like .links and the store itself
<clever>
yep
<clever>
and how often do you actually want to share high-scores with another user on the same box?
<clever>
and nixos makes it worse, then you need a nixos module to handle the set gid bit
<clever>
so only that game can write to it, and users cant just cheat in their own scores, or put malicious data into a file another user will load into the game
<clever>
to set things like this up "properly", it has to have the set gid bit set, and then a group that has write to the shared location
<clever>
sphalerite: yeah, so its trying to write to the store
<clever>
nwuensche: oh right, there is also a steam-run package, which i believe gives a shell inside the same chroot used for steam
<clever>
silver_hook: to nixpkgs, it has to be patched to save to an area under $HOME rather then --prefix
<clever>
switch does its best to reload things, but kde cant be reloaded
<clever>
only for some stuff in the kde launcher
<clever>
silver_hook: you can also just logout and log back in
<clever>
and the sh part refused to just unpack and not run the ELF
<clever>
the tar contained an ELF that handled the custom archive format
<clever>
another problem i have ran into, the .sh was both a tar, and a custom package
<clever>
yeah, that sounds right
<clever>
sphalerite: the problem is when people assume your PATH is wrong and do /bin/bash
<clever>
and only things using myHaskellPackages will get the override
<clever>
mpickering: instead of setting haskellPackages in the override, set myHaskellPackages
<clever>
mpickering: you can name your override something else
<clever>
mpickering: no real way that i know of to do it recursively, other then just making a second haskellPackages set
<clever>
mbrock: the name of the .drv file is based on a hash of its contents
2017-09-07
<clever>
tnks: "nix-store -r /nix/store/foo" downloads from the binary cache, nix-copy-closure can copy between machines, and you can "nix-env -i /nix/store/foo" to download from a binary cache and add it to your profile
<clever>
and if you set the type correctly in the nixos config, it properly configures any software you need
<clever>
systemd units dont have access to the systemPackages
<clever>
woffs: { pkgs, config, ... }: let foo = config.boot.kernelPackages.tp_smapi.overrideAttrs ...; { merge the two - then reboot.
<clever>
woffs: you can move that value into a let block near the top of the file
<clever>
for most OS's, it only causes a lack of kernel upgrades
<clever>
its a common problem, ive seen it 5+ times in here
<clever>
and confirming its configured to mount on bootup
<clever>
yonk42: it should be as simple as mounting /boot correctly and re-running nixos-rebuild, which will re-poppulate /boot
<clever>
woffs: what about boot.extraModulePackages = [ (config.boot.kernelPackages.tp_smapi.overrideAttrs .... ) ]; and ignore the rest
<clever>
woffs: oh right, you need to actually depend on tp_smapi, one second
<clever>
peterhoeg: also keep in mind, the last person i asked "is /boot mounted" said yes, when it wasnt, confirm everything with df -h or mount output
<clever>
so the user services are still global, and available to every user
<clever>
only nixos modules can be used to create systemd-user services
<clever>
its getting late here, i should head to bed
<clever>
rotaerk: stack2nix is also an option, but that generates a lot of stuff, so its not much different from cabal2nix
<clever>
use wildcards in the bash that happens in the next derivation
<clever>
ah, not sure there
<clever>
so you need to know that name in advance
<clever>
the issue, is that the nix expressions run before the build has even started
<clever>
ah
<clever>
"
<clever>
"${mySymptoms}/bin/foo
<clever>
rotaerk: haskellPackages.callCabal2nix
<clever>
sounds good, and you could probably further optimize it, re-do the previous du to see what the fattest package is now
<clever>
fresheyeball: ah, i was thinking of haskell.lib.justStaticExecutables
<clever>
let me double-check some things
<clever>
run haskell.lib.enableStaticLibraries over the derivation i believe
<clever>
yeah, thats a problem with the dynamic linking
<clever>
fresheyeball: line 10, your build directly depends on ghc at runtime, likely dynamic linking, what does "grep -r --color mqcmpgd6i0hggx7mvlvx7gvi6cx124c4 /nix/store/f3zyazp6ddx3bcqmi7j6vm8k0xccl2wc-mysymptoms-web-dashboard-0.1.0.0" say?
<clever>
fresheyeball: and throw it in a pastebin this time
<clever>
fresheyeball: now check nix-store --query --tree /nix/store/f3zyazp6ddx3bcqmi7j6vm8k0xccl2wc-mysymptoms-web-dashboard-0.1.0.0
<clever>
the problem is that your build depends on ghc, so the entire 1gig of ghc is present in the docker
<clever>
lol
<clever>
your spam is going strong, lol
<clever>
you will want to use a pastebin
<clever>
what is the output of this?
<clever>
du -ch $(nix-store -qR /nix/store/f3zyazp6ddx3bcqmi7j6vm8k0xccl2wc-mysymptoms-web-dashboard-0.1.0.0) --max=0 | sort -h
<clever>
fresheyeball: what is the path to the haskell binary?
<clever>
fresheyeball: run a command like this on the storepath for that haskell binary: du -ch $(nix-store -qR /run/current-system) --max=0 | sort -h
<clever>
tnks: you will also want to nix-store --query --roots on the storepath, to confirm its detecting the root
<clever>
ah, maybe
<clever>
only nix-env as far as i know
<clever>
--no-outlink stops that i believe
<clever>
thats all it does
<clever>
tnks: nix-build -o foo
<clever>
you probably have something odd in your .bashrc or .bash_profile
<clever>
thats not normal, and it causes the libraries you nix-env to have priority
<clever>
/home/cole/.nix-profile/lib probably broke it
<clever>
hmmm, and if you "unset LD_LIBRARY_PATH" does that fix nix-env?
<clever>
colescott: env | grep LD_LIBRARY gives what output?
<clever>
colescott: nixos or another distro?
2017-09-05
<clever>
though nix doesnt save the log of failing builds, as far as i know
<clever>
enableParallelBuilding just allows derivations to obey build-cores
<clever>
-j1 will prevent derivations from being interleaved, the 2nd part will pass -j1 to make inside each
<clever>
and maybe nix-build -j 1 --option build-cores 1
<clever>
nix-build -j 1
<clever>
every nixos-rebuild you have done, that it undid
<clever>
so it fails in the future, rather then silently claiming it worked