<LnL>
or something like that to avoid sending unsupported options to remote stores
<LnL>
things like sandbox-paths and plugin-files only make sense locally
philr has quit [Ping timeout: 248 seconds]
elasticdog has quit [Ping timeout: 264 seconds]
elasticdog has joined #nix-darwin
<shlevy>
LnL: I feel like "overridden" is the wrong concept here
<shlevy>
Can you add an additional field to BaseSetting or similar to mark whether it should be forwarded?
peacememories has joined #nix-darwin
<LnL>
right, I guess for most cases the setting itself is enough to determine that
<shlevy>
Are there exceptions?
jtojnar has quit [Remote host closed the connection]
<LnL>
well, I'm not sure what the most logical behaviour is for build-use-sandbox
<LnL>
not forwarding and disallowing it with --option store?
<shlevy>
If untrusted users are allowed ot disable it, then it should be forwarded. If they aren't, it should be enabled if it's enabled on either end of the pipe.
<LnL>
only trusted users can enable/disable that
<LnL>
but if you forward it from linux -> darwin builds won't work because we don't have sandboxing there
<LnL>
(with build-remote)
<shlevy>
Hmm... I guess if people want sandboxing on the remote they can explicitly ask for it with a query param right?
<shlevy>
Or, if they can't, they should be able to. So don't forward the setting by default, but allow administrators to say "we must have sandboxing regardless of the policy on the other end of the connection"
<LnL>
can we configure settings with query parameters?
zzamboni1 has joined #nix-darwin
zzamboni1 has quit [Ping timeout: 256 seconds]
<LnL>
I feel like it would make sense that nix-build —store ssh-ng://foo —option ... would behave the same way as ssh foo nix-build —option ...
<shlevy>
ssh-ng://foo?whatever will set *store* parameters, not settings
<shlevy>
I'm thinking most settings should go by --option
<shlevy>
But sandboxing specifically should also be a store parameter, and not forwarded from settings
peacememories has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zzamboni has joined #nix-darwin
peacememories has joined #nix-darwin
peacememories has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zzamboni has quit [Remote host closed the connection]
peacememories has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<shlevy>
Oof, coworker both a) has a second libiconv in /usr/local/lib for some reason and b) somehow has nix binaries linked to it???
<shlevy>
(and it's missing _locale_charset)
<shlevy>
Uuugh libHSbase sets an @executable_path relative rpath :o
<johnw>
ooh, ouch
<johnw>
libiconv is really the bane of darwin
<shlevy>
(for ghc binary at least)
<shlevy>
So it works for GHC binaries, but not for HSColour
<shlevy>
Not sure why HSColour is needed to build a real ghc though...
<johnw>
it's needed to build the base haddocks
<johnw>
if you build without docs, it shouldn't be necessary
<shlevy>
But this is hscolour linked to ghc-binary
<shlevy>
Presumably we don't need those docs :D
<johnw>
interesting
<johnw>
dunno then
<johnw>
ask in #ghc?
<johnw>
my High Sierra upgrade is still underway
<johnw>
still at the "imaging the hard drive" stage
<johnw>
well, currently doing a checksum validation of the image I took last night
<ldlework>
godspeed
<johnw>
thanks :)
<acowley>
Anyone have any thoughts for a buildFHSEnv type thing on darwin for dumping a lot of packages into one store path? I'm finding working with packages with several hundred dependencies quite clunky, and I'd be open to trying something granular.
<acowley>
something *less* granular.
<johnw>
acowley: conversely, I've run into issues with single store paths that are too large. Bundling SageMath into my storage (~2GB but nearly 150k files) causes nix-store to stall
<johnw>
and it stalls all night long too, it never comes back
<johnw>
removing SageMath from the store fixes it
<acowley>
johnw: Shoot, I'd almost certainly hit that if I consolidated paths
<acowley>
johnw: What do you use to manage that installation then?
<johnw>
i don't :(
<johnw>
i run SageMath from within a .dmg
<johnw>
which is my usual approach to solving "too many i-nodes" type problems
<acowley>
Yeah, I'm leaning towards not using nix for really big (in some sense) builds, but it's frustrating because it feels like that's where there's the most to gain.
<johnw>
well, we could double-down and find the problem
<johnw>
it's just hard to reproduce
<johnw>
I only discovered it because my nix builds wouldn't finish even until the next morning
<johnw>
but nobody was taking any CPU
<acowley>
I'm not familiar enough with nix-store to even know why it'd be inspecting a path in the store
<johnw>
well, doens't it register all the sub-paths in SQLite?
<johnw>
what I noticed is that my sqlite was HUGE
<johnw>
after deleting the SageMath store path
<johnw>
I went in and did a VACUUM; on the db
<johnw>
and it dropped to like 30% of its size
<acowley>
Is the sqlite db of paths for a user-convenience feature or something critical?
<johnw>
I don't even know that it does store them
<johnw>
it was a guess
<johnw>
shlevy would know
<shlevy>
Critical
<LnL>
euh, don't touch that :p
<shlevy>
Used for atomicity, reference tracking, etc.
<acowley>
I had thought only the hash in the /nix/store directory was used for tracking! TIL
<acowley>
I guess the other approach would be to manually break a big build into a bunch of layers where no layer is too big to bump into the problem johnw has nor too small to bump into the issues I hit with command line lengths, environment sizes, etc.
<shlevy>
acowley: The hash is scanned once at build time
<shlevy>
And saved in the db
<johnw>
shlevy: can the db be rebuilt from scratch?
<shlevy>
It'd be very slow to scan every path every time you do gc collection
<johnw>
i guess so
<shlevy>
johnw: No
<johnw>
just move all the files away, and then nix copy them into the store
<shlevy>
Well... You could probably do it if you assume every file is valid and generate a validity registration yourself
<johnw>
acowley: as an aside, the number of paths in my store is also huge
<shlevy>
And re-run the scans
<johnw>
so maybe it was a combinatoric issue
<johnw>
ls -l | wc -l reports 38388 paths in /nix/store after doing a nix-collect-garbage -d last night
<johnw>
53G in size
<acowley>
That is big!
<johnw>
yeah, Nix has been pretty amazing at managing a huge set of environments for me
<acowley>
I only have 14k paths occupying 20G
<johnw>
some of it is because I have 3 flavors of GHC, 4 flavors of Coq, 4 flavors of Emacs, and hundreds of packages associated with each
<johnw>
which thanks to the beauty of functions is easy to express, but multiplies quickly
<acowley>
I've not encountered problems with nix-store, so I have no complaints about it!
<johnw>
until we get shlevy's formally grounded nix-store NG :)
<acowley>
Then I will have lots of problems? :P
<shlevy>
:)
<johnw>
you'll know what your problems are
<acowley>
Ahh the priorities of typed functional programmers
<johnw>
yeah, those pesky things like correctness, blah
<shlevy>
The problem with telling people about your ideas is now they expect you to execute on them :o
<johnw>
shlevy: nah, I expected you to execute on them before you even told me :)