<laduke-132>
hiya, I'm just using nix-env to install stuff on my mac, for now, and I'm trying to build something with clang+llvm, and it says to use like -DCMAKE_PREFIX_PATH=/path/to/clang+llvm-xxx, but I don't know where that path would be
<laduke-132>
wait, also when I try to build stuff with cmake, I get like "iostream not found", so I think I need to fix my env first
<abathur>
antifuchs emily and probably others; I've opened a draft PR wrt encrypting the Nix volume if FV is enabled at nix#4181
<emily>
abathur: you probably want to add the UUID to the two fields that macOS adds it by default when storing a disk encryption password in the keyring
<emily>
I forget exactly which fields it is though
<emily>
shelling out to ruby from expect tcl sure is beautiful :)
<emily>
do we really want to skip /etc/fstab entirely? AIUI diskutil will pick up things like `nobrowse` from there
<emily>
also I'd be surprised if login keychain actually works since I think it's meant to be encrypted with user password?
daGrevis has quit [Remote host closed the connection]
daGrevis has joined #nix-darwin
Chiliparrot has joined #nix-darwin
<emily>
oh, and: should at least consider case-sensitive apfs
hmpffff has joined #nix-darwin
hmpffff has quit [Ping timeout: 256 seconds]
hmpffff has joined #nix-darwin
Chiliparrot has quit [Ping timeout: 260 seconds]
Chiliparrot has joined #nix-darwin
emily has quit [Quit: killed]
aterius has quit [Quit: killed]
domenkozar[m] has quit [Quit: killed]
siraben has quit [Quit: killed]
thefloweringash has quit [Quit: killed]
Chiliparrot has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
aterius has joined #nix-darwin
hmpffff has quit [Ping timeout: 272 seconds]
hmpffff has joined #nix-darwin
siraben has joined #nix-darwin
emily has joined #nix-darwin
domenkozar[m] has joined #nix-darwin
thefloweringash has joined #nix-darwin
hmpffff has quit [Ping timeout: 260 seconds]
hmpffff has joined #nix-darwin
hmpffff has quit [Ping timeout: 240 seconds]
hmpffff has joined #nix-darwin
mitchellh has quit [Ping timeout: 260 seconds]
qyliss has quit [Remote host closed the connection]
qyliss has joined #nix-darwin
mitchellh has joined #nix-darwin
<abathur>
emily: do you know where you might understand diskutil picking up fstab mount options from?
<abathur>
emily a test does suggest it's true, and I did find an SE answer (https://apple.stackexchange.com/a/240317/271161) asserting it, but I'm curious if this means there's a good doc I haven't seen yet
Chiliparrot has joined #nix-darwin
<abathur>
anyways, my reasoning on fstab isn't terribly deep; at the first level, I didn't realize diskutil would respect it; at the 2nd level I see lopping off an uninstall step as having some value; I may look at whether it's possible to just follow the diskutil mount command with a mount -u command; if that doesn't work I'll restore the fstab section
Chiliparrot has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
disasm has quit [Read error: Connection reset by peer]
disasm has joined #nix-darwin
<abathur>
mount -u does ~work, though I was deceived by an example I saw into thinking I could skip specifying the device file and just specify the path if it was already mounted; fstab is probably better than making the daemon complex enough to look up the correct special file
philr has quit [Ping timeout: 246 seconds]
__monty__ has joined #nix-darwin
gleber_ has joined #nix-darwin
hamishmack_ has joined #nix-darwin
rizary_ has joined #nix-darwin
aminechikhaoui has quit [Ping timeout: 240 seconds]
domenkozar[m] has quit [*.net *.split]
gleber has quit [*.net *.split]
hamishmack has quit [*.net *.split]
rizary has quit [*.net *.split]
gleber_ is now known as gleber
rizary_ is now known as rizary
hamishmack_ is now known as hamishmack
<emily>
abathur: the nobrowse shows up in `mount` after diskutil mounts it, at least
domenkozar[m] has joined #nix-darwin
<abathur>
nod, I'm pretty sure it picks them up, I did a test with readonly to make it painfully obvious if it was
<abathur>
but I haven't seen any official documentation of it :)
<abathur>
the documentation and command support situation in this area is a bit of a cluster
<emily>
technically diskarbitrationd is open source but I couldn't manage to find useful parts of the code
aminechikhaoui has joined #nix-darwin
<abathur>
ah, that makes sense; `strings /usr/libexec/diskarbitrationd | grep /etc/fstab` does at least match
hmpffff has quit [Ping timeout: 272 seconds]
hmpffff has joined #nix-darwin
hmpffff has quit [Ping timeout: 272 seconds]
hmpffff has joined #nix-darwin
<LnL>
abathur: very cool
<LnL>
I do have concerns with installing daemons in the single user installer however
<abathur>
(my posted installer is broken atm; haven't had a chance to fix and re-build; I can roll it back to use a previous tarball in a pinch but hopefully will have it fixed and up in the next hour)
<antifuchs>
hm, I wonder if that could be a setting, like `nix.darwin.encrypted-store-volume-name = "Nix"`, and let that manage the launchdaemon? IIUC it should get installed when people apply their config the first time, right?
<abathur>
can you elaborate on those concerns? :)
<LnL>
the line is already a bit blurred, but the main argument for the single user variant is the simplicity
<__monty__>
Shouldn't single-user also work for non-admins? I could be wrong but don't daemons always require privileges beyond what regular users have?
<abathur>
unfortunately, apple forced our hand on that one
<abathur>
you can't edit synthetic.conf, fstab, or mount a volume there w/o sudo I don't think
<LnL>
if I know something installs a bunch of active stuff on my system I'd be weary to try it out
<LnL>
we already need a few global things like fstab and synthetic.conf but those don't really matter once I remove the volume
<abathur>
(responding to __monty__ re: working for non-admins)
<LnL>
and the installer (neither variant) manages the daemons so having a third variant in that regard doesn't seem like a good idea either
<LnL>
yeah setup needs root, and it's sadly not just mkdir /nix anymore
<__monty__>
abathur: But you could just use a custom store location, right?
<abathur>
anyways; I think it boils down to: if we don't do the daemon, we don't get to cut out the filevault-without-T2 corner case and just have to live with misunderstandings and complaints until apple gives us a firmlink, Nix can run from some other location, or everyone vaguely interested in Nix has moved on to T2 hardware
<__monty__>
It sure as hell isn't convenient. But the installer *requiring* root access seems like a step back.
<abathur>
nix requiring a root directory isn't convenient, either
<abathur>
the unstoppable force and the immovable object
<LnL>
antifuchs: these changes are for the nix installer itself, which doesn't have a config file or any other kind of management of the existing installation
<__monty__>
I agree it's not convenient. But there are actual reasons for requiring so.
<__monty__>
If it solves a problem I'm 100% for including at least an option in the installer.
<LnL>
nix has support for running in different prefixes, but that's all based on linux namespace features
<abathur>
that conversation is above my paygrade; as I understand it the powers that be are unwilling to move the store globally, and otherwise we need a sugar daddy to sponsor nix caching infra (or put up a masochists-only sign and go cacheless)
<__monty__>
abathur: Afaict the real problem is you can't patch paths in binaries with arbitrarily long paths. If that were to change then nix would no longer have a need for a short store path.
<abathur>
I don't really understand the world of binary patching, but I've gotten the impression that that the path length thing is a fairly intrinsic fact of patching a binary; you can pad up shorter paths but not run over
<LnL>
yeah, you can find paths in a binary blob and replace them with something else
<abathur>
someone iirc suggested using like /opt/nix/s in place of /nix/store, but I don't recall off the top of my head why that was shot down
<LnL>
but you don't have context on what to change if the size changes
<__monty__>
Yes. But I don't have a hard time imagining a way of encoding paths in binaries that would allow for replacing them with arbitrary length strings.
<LnL>
that route also means nix needs to patch every substituted file however
<LnL>
nah I don't think you really can
<LnL>
linker paths can be changed, since tools like install_name_tool know more about the data
<LnL>
but if a binary compiles in the path to it's own docs for help or whatever you have no idea
<LnL>
and changing the size might mean other things like pointers break later in the binary
<__monty__>
I'm sure a binary format could be designed to allow easy patching of paths. Not talking about strings used in the interface or something but actual paths accessed.
<LnL>
just changing the prefix (ie. also for the builders) is a much more straightforward option, but I'm not inclined to look in that direction if it's only for darwin
<LnL>
the same arguments for a different prefix are valid for nix on linux IMHO
<LnL>
and I'd really prefer not to introduce more darwin weirdness into nix/nixpkgs from the nixos perspective
<gchristensen>
LnL: how do I use that redirected store thing on linux again? I can neverremember
<LnL>
just plain --store <path>
<gchristensen>
huh
<gchristensen>
sure enough :D
jhuizy3 has joined #nix-darwin
<gchristensen>
thanks!
<LnL>
the other cases are more complicated to specify since you need to pass a bunch of parameters
<gchristensen>
gotcha
aminechikhaoui has quit [*.net *.split]
cransom has quit [*.net *.split]
jhuizy has quit [*.net *.split]
clever has quit [*.net *.split]
andremedeiros has quit [*.net *.split]
jhuizy3 is now known as jhuizy
clever has joined #nix-darwin
andremedeiros has joined #nix-darwin
cransom has joined #nix-darwin
aminechikhaoui has joined #nix-darwin
<abathur>
I'm a little perplexed at how I convinced myself that the login keychain was viable here as long as a daemon was doing the mounting; I guess I must be mis-remembering the test I did with the password in a flat file :/
<antifuchs>
It does work with the system keychain, I can confirm that. Will that work for you?
<abathur>
yes, it does (and I have that part working for multi-user install already), I just got myself turned around and wasted some time trying to make user keychain work