<clever>
jasom: have you been deleting things to silence warnings about collisions?
<clever>
jasom: does channels_root exist in .nix-defexpr?
<clever>
jasom: --add must always be followed by --update to apply the additions
<clever>
jasom: you need to run nix-channel --update as root
<clever>
jasom: and what about ls -ltrh ~/.nix-defexpr/*/*
<clever>
jasom: what does "nix-channel --list" and "sudo nix-channel --list" say?
<clever>
jasom: just name the channel as always, nix-env -iA unstable.hello
<clever>
jasom: yeah
<clever>
jasom: and --remove every channel from all non-root users
<clever>
jasom: same way you manage them as a normal user, nix-channel --add
<clever>
jasom: even as root, only the channel called "nixos" is special, so you can add custom channels to root without harm
<clever>
jasom: its usually better to just never have a channel on the users, and manage all channels by root
<clever>
gchristensen: but that can make things like propagated inputs and other stuff harder to deal with
<clever>
gchristensen: rather then appending 200 -L's to ld and letting it search
<clever>
gchristensen: it will buildEnv all deps into a single dir, acting as an index in one spot
<clever>
gchristensen: i have found that ghcWithPackages looks better then buildInputs
<clever>
hodapp: what override did you add to opencv, and what attribute path?
<clever>
because the eval is supposed to be pure
<clever>
and hydra doesnt support using build slaves at eval time
<clever>
Infinisil: import from derivation
<clever>
hodapp: python was off, no contrib option visible
<clever>
hodapp: *looks*
<clever>
Infinisil: its a case of where IFD is bad
<clever>
it does a native darwin build, on a darwin slave
<clever>
but import <nixpkgs> { system = "x86_64-darwin"; } doesnt cross-compile
<clever>
nativeBuildInputs is for when you cross-compile
<clever>
and at this point, is simpler to just pre-run cabal2nix and commit the result
<clever>
to fix that, i would have to import 2 instances of nixpkgs (host and darwin), use the host nixpkgs to build and run cabal2nix, then the darwin nixpkgs to import the resulting nix file
<clever>
Infinisil: hydra cant do that
<clever>
Infinisil: so if i import a darwin nixpkgs, and do haskellPackages.callCabal2nix, it wants to generate the .nix file on a darwin machine
<clever>
Infinisil: IFD uses the target arch for building the derivation
<clever>
hodapp: i dont see QT in the closure of my opencv
<clever>
hodapp: run "nix-store -q --tree" on the .drv file for the build
<clever>
yeah, i could put such a derivation into the top-level assertions of nixos
<clever>
taktoa: just the fact that its valid
<clever>
Infinisil: just an email address
<clever>
Infinisil: i suspect hydra and the module have zero validation on the field i linked, and will insert whatever string you give it into the emails
<clever>
correction, what email to include in the from: field
<clever_>
nix-store -r /nix/store/foo --add-root result --indirect
<clever_>
gchristensen: try eval'ing this in nix-repl
<clever_>
nix-repl> hello // { type = "dummy"; }
<clever_>
that can also cast to a string
<clever_>
derivations are special attribute sets
<clever_>
you can just .name
<clever_>
gchristensen: do you just have that string, or a derivation that evals to that string?
<clever_>
3gig of ram
<clever_>
so lvm splits the luks up, into a swap, and a zfs pool
<clever_>
sphalerite[m]: i wanted a single luks volume, and swap, but swap on zfs is bad
<clever_>
but i would avoid zfs on zfs when possible
<clever_>
my laptop is zfs on lvm on luks
<clever_>
LnL: ahhh, nice
<clever_>
i dont think you can directly reserve it, but a quota on everything else would do that
<clever_>
sphalerite[m]: zfs shares the free space of every filesystem in the pool, and each filesystem can optionaly have a quota setting the upper limit on usage
<clever_>
look near that, it may check many places
<clever>
bennofs: or set hardeningDisable = "all" i think
<clever>
bennofs: nix-shell -p gcc.cc
<clever>
seequ: this example is also in the man page
<clever>
$ nix-env -e '.*' (remove everything)
<clever>
so hello will be the only installed thing
<clever>
will remove everything, and install hello
<clever>
in the man page, i see that nix-env -riA nixos.hello
<clever>
seequ: nix-env -e i think
<clever_>
serougjserg: you need to use attribute names in -p
<clever>
avn: i have a PR being tested, that will add split outputs to all haskellPackages
<clever_>
killing the ssh will probably lead to an unexpected eof, and then it will try the build again
<clever>
copumpkin: the abort button just hides it, and stops any further proccessing
<clever>
copumpkin: there is no way to stop an in-progress build
<clever>
i could also give that user write to his "own" directory, and pre-install malware into his profile
<clever>
looks like it
<clever_>
sphalerite[m]: and something nixos sets up in /etc/profile auto-creates it
<clever_>
sphalerite[m]: ah yeah, i think it defaults to the default profile
<clever>
copumpkin: i have noticed a lot of arm builds, and even a few x86 builds hanging within make, make had a zombie process as a child, and wasnt calling waitpid
<clever_>
64bit x86 has more registers, so its faster/cheaper to pass more arguments in registers
<clever_>
the calling convention is based on the cpu mainly
<clever_>
so overloaded functions have different symbols
<clever_>
there is also symbol mangling, the c++ names (namespace, types, return value) get flattened down to a c level symbol name
<clever_>
and also who cleans the stack up, the caller or callee
<clever_>
the calling convention sets things like where arguments go (in certain registers, on the stack?)
<clever_>
it is capable of building everything, for every PR
<clever_>
hydra can check them in future
<clever_>
travis has a lot of false negatives, so people ignore it
<clever_>
and in future, hydra can test everything, and just tell you what you broke
<clever_>
travis runs that automatically when you open a PR
<clever_>
nox has a review-pr thing that tests it
<clever_>
and then each one of those will update to the latest within that api
<clever_>
nixpkgs is currently in the area where you only keep a minimal number of versions (major api changes)
<clever>
*waves*
<clever_>
currently on the road
<clever_>
thats the desktop at my house, let me ssh to it
<clever_>
i made a push yesterday, let me see if peti left a comment
<clever_>
gchristensen: sure
<clever_>
not sure then
<clever_>
everything you list in -p gets added to the buildInputs of a dummy derivation
<clever_>
pie_: nix-shell -p libwebp
<clever_>
pie_: nix doenst care what you have installed, you must put it in the buildInputs
<clever_>
gchristensen: the other goes into the initrd, so the boot filesystems can make use of the fs
<clever_>
gchristensen: one goes into only the rootfs, so you can use it after stage-2 has loaded (like nfs for media)
<clever_>
libwebp.out 23,160 x /nix/store/afsmdas1gzdx3zv2csqwggvh629cidk6-libwebp-0.4.3/include/webp/decode.h
<clever_>
yeah
<clever_>
maybe the wrong version
<clever_>
sounds like openssl
<clever_>
rather then using that dir as nixpkgs
<clever_>
without the nixpkgs=, it will search for nixpkgs inside of that directory
<clever_>
copumpkin: ehh, i had worse, i was ssh'd into screen+irssi yesterday, and there was 2 minute latency at times
<clever_>
copumpkin: fixing that would have greatly increased the speed of that bash based parser, making it entirely userland, rather then context switching for every string concat
<clever>
copumpkin: it was hammering the brk() syscall, increasing the heap by a few kb, then shrinking it asap, then increasing it again
<clever>
copumpkin: i noticed a bug in bash when it was running the old RSP parser
2017-07-25
<clever>
dang, irc is unreadable in this app, i'll be back later
<clever>
ec2 classic?
<clever>
sphalerite[m]: that hydra is a bit slow, just try again
<clever>
heading off for the night
<clever>
gchristensen: but if /nix doesnt exist, nix-daemon better not be running!
<clever>
gchristensen: so the daemon was running, but the store was kaput
<clever>
gchristensen: i'm guessing it was a previous multi-user install, that had been "rm -rf /nix"'d
<clever>
gchristensen: maybe just a killall nix-daemon near the start
<clever>
gchristensen: i think the entire /nix was deleted, with the daemon running, so launchd didnt start a new one
<clever>
gchristensen: might want to add a command to ensure it kills any old nix-daemon upon install
<clever>
did launchd start a replacement?
<clever>
ps aux | grep nix-daemon
<clever>
mightybyte: the directory should exist now
<clever>
mightybyte: ls -ltrh /nix/var/nix/daemon-socket/
<clever>
gchristensen: what was it?
<clever>
there is a launchctl command for that
<clever>
the launchd unit has to be restarted
<clever>
that daemon pre-dates everything being deleted, including the directory it cant get into
<clever>
thats what i was thinking
<clever>
and you also reinstalled nix 2 hours ago?
<clever>
mightybyte: does it say when nix started?
<clever>
mightybyte: ps aux | grep nix-daemon
<clever>
mightybyte: is nix-daemon running?
<clever>
mightybyte: what user owns the /nix/store dir?
<clever>
i think one is on matrix
2017-07-24
<clever>
it was chatty the whole 48 hours, lol
<clever>
LnL: ah, my arm build of llvm didnt go silent for that long
<clever>
catern: using this, you can turn a set into a series of shell commands