<abathur>
since the installer isn't looking for them on another disk, it won't see or care about them; it'll happily create a new volume and set everything up to use it (exception: I do have it set up to clean up volume encryption credentials that appear to be orphaned...))
supersandro2000 has quit [Disconnected by services]
supersandro2000 has joined #nix-darwin
hedgie has joined #nix-darwin
<abathur>
I imagine it would break a custom install using a different disk and need manual repair; it could search all disks for the volume and ask for clarification, but I'm not sure what it should do in that case if run headlessly (and the default doc recommendation is to run it headlessly)
<abathur>
(I'm ignoring/resisting some obvious answers, like "abort if run headlessly, force the user to use flags or run normally to disambiguate the volumes" because I feel like the UX around the installer aborting and forcing you to re-curl sucks and is over-used. I'm trying to only use them as a last resort.)
<gchristensen>
+1
<abathur>
2. A similar issue is that people can technically have multiple volumes with the same name/label (on a single disk, or on multiple disks). As it stands it'll just single out whichever diskutil returns first. I guess: "is it likely enough that someone will have N identically-named volumes that we should care enough to further complicate the installer to handle those cases gracefully or feel bad
<abathur>
if it does something dumb on their system?"
<abathur>
gchristensen: +1 to which? avoiding abort abuse? :)
<gchristensen>
y
<abathur>
someone left you in terse mode :)
<abathur>
we could mitigate both #1 and #2 here would be picking a longer/more-obtuse volume label
<abathur>
the live installer uses "Nix Store"; emily pointed out that it has more than the store in it, so I changed it to "Nix Volume", but then lilyball pointed out that was like an ATM Machine, so now it's just "Nix"
<emily>
+1 for the Nix name
<emily>
means you don't have to deal with escaping in the label too
<emily>
did case-(in)sensitive get decided on?
<emily>
I have plans to remake my personal /nix as case sensitive next time I do an upgrade
<emily>
would be nice if you could change after the fact :(
<abathur>
I have made the FS a variable, so you can override it by setting an env
supersandro2000 has quit [Disconnected by services]
supersandro2000 has joined #nix-darwin
<thefloweringash>
hyiltiz: it's something that should be fixed in nixpkgs, I've opened a pr (#103651)
<abathur>
emily: kinda, but I still have the escaping code in place in case someone sets the label to something with a space
<abathur>
not sure I have any brighter ideas there, but I guess I'm a bit uneasy about clashes because of how often it seems like some people use "*nix" and "'nix" and "nix" as shorthand
<emily>
the current installer just looks for nix which I agree is overly broad
<emily>
I think "Nix" itself, especially capitalized and as its own word, is a really unlikely to clash with much though
<emily>
re FS being configurable: sure, but what's the default? :) i think it would be bad to have people massively split between the two settings since it's basically twice the opportunity for issues
<abathur>
I mean something like: I made it configurable so that people can experiment with it to see if they run into trouble and inform a better decision later
<emily>
right
<abathur>
I agree a massive split would be bad
<abathur>
but it doesn't ask you to pick or anything, you'd have to read the code or a thread or ask to find out
<abathur>
*unless we choose to document it
<hyiltiz>
thefloweringash: thx! I understand that it is a nixpkgs PR but it would make things easier for the users with prompts as I described, and I'd also be able to report back what I did to fix it (if prompt was supplied) so fix or PR can be made faster
<hyiltiz>
Doesn't need to wait for Nix ninjas like u
<abathur>
grumble; has anyone seen the "could not set permissions on '/nix/var/nix/profiles/per-user' to 755: Operation not permitted" issue when it seems like nix-daemon is running? something done by my curing process for darwin volume state/cruft is triggering it
<abathur>
it'll work fine again if I launchctl kickstart -k it, but otherwise it just keeps throwing that error on any nix invocations
<abathur>
but I'm doing a lot of weird things, so I'm not really sure which one :P
<abathur>
I'll just change the installer to use kickstart -k as well and see if that fixes it
<abathur>
emily what do you think the installer should do if it's run on a system that already has a "Nix Store" volume?
<abathur>
my current WIP will basically ignore it since the names don't match; it'll make a new volume, and set up synthetic/fstab/launchdaemon
<abathur>
it could certainly look for it, and try to take some actions, but I'm not sure what; renaming it would be simple; making them remove and replace it would be simple (for the installer) but perhaps annoying for them
<abathur>
by "making them", I mean, prompting them to delete it, and re-creating it
<abathur>
but I get squeamish when I start to think about what it should do if they've encrypted the volume themselves, for example--or if they are using filevault+T2 and technically the consistent action would be encrypting their volume
<emily>
abathur: I guess it depends on how likely a Nix install is to survive the first upgrade. AIUI the current installer flags up if you have any volumes matching *nix* or something
<emily>
I think it'd be reasonable to at least barf out and say "hey you need to manually address this somehow" if one specifically called Nix Store exists
<abathur>
"first upgrade" == catalina -> big sur?
kalbasit has quit [Ping timeout: 272 seconds]
<emily>
er, yes, sorry, no idea where first came from there
<emily>
I guess since there's no actual /nix and it's just a synthetic.conf entry things will hopefully just work as long as that isn't blown away
<abathur>
nod
<abathur>
guess that's an interesting question though
<abathur>
thefloweringash: if someone on Catalina upgrades to Big Sur, how use(ful|less) would their store contents be?
<thefloweringash>
should be entirely useful, along with the current cache contents, the main problem is linking new things
<abathur>
k
<abathur>
wonder how long it takes to just make a new volume and copy over
<abathur>
though I guess that comes with the added complexity of figuring out if there's room
<Gaelan>
Has anyone who uses nix-darwin tried upgrading to Big Sur? If so, how did it go?
eraserhd has joined #nix-darwin
<abathur>
no one's said anything here yet, at least
philr has quit [Ping timeout: 256 seconds]
<LnL>
I haven't tried anything myself, but from what I understand apple didn't break anything with binary compatibility so you should be able to use the cache for current builds
<LnL>
building anything locally that needs the linker will probably break however, until the changes from staging land
kalbasit has joined #nix-darwin
<domenkozar[m]>
thefloweringash: btw do you have access to macos machine with arm?
<domenkozar[m]>
if not, would access to one help?
<thefloweringash>
domenkozar: thanks for the offer, but I’m pretty well covered there. I’ve been doing a bunch of iteration on a dtk, and my personal mini should arrive in about a week
<domenkozar[m]>
perfect :)
<cransom>
I have x86 big sur machine with a nix 2.4pre20201110, nixpkgs from staging (includes the tbd based stdenv commit), but if i go to build ruby, it bails with a 'configure: error: C compiler cannot create executables" for /private/tmp/nix-build-ICU-osx-10.10.5.drv-4/ICU-531.48/build . am i missing some pieces?
__monty__ has joined #nix-darwin
<LnL>
cransom: yeah bootstrapping doesn't entirely work yet, you'll need caches from an older machine to kickstart the stdenv itself
<LnL>
there might also be more issues around in nixpkgs, the hydra job only validated that there are no big regressions for current os versions
<cransom>
when it makes it to nixpkgs-unstable, the bootstrapping will be cached then i assume?
<LnL>
yeah, wouldn't be very nice if channels updated without even building the stdenv :D
<LnL>
btw can you check the log? I'm not sure if anybody is aware of specific issues so might be easy to fix
<LnL>
those instructions don't help? especially the modprobe stuff
<gchristensen>
it boots off an external disk, which isn't great
<LnL>
ah so booting works now just not from the internal drive
<gchristensen>
yea
<LnL>
based on the details there sounds like you'd have to repartition the main os, keeping at least the macos recovery stuff, instead of replacing everything
<LnL>
cransom: think I found it, a bunch of stuff is replaced by bootstrapTools (which still includes libSystem) in the first stage
<LnL>
I was testing with ld before which knows about less stuff unless invoked by clang indirectly
<cransom>
hrm, definitely chugging farther along. looks more promising.
<cransom>
maybe in the future i'll be a bit less conservative and spend on something bigger than an air for work. poor little cpu.
<cransom>
woot. successful build of ICU. now back to the regularly scheduled program and build a ruby.
<LnL>
ICU isn't all that special, all the llvms and whatever you're about to queue now that's going to take a while :D
<LnL>
I'll see about getting this into a pr
<LnL>
we'll need a stable tarball for the stubs tho or some other alternative that doesn't pull in unzip, etc. since this is needed too early
<LnL>
thefloweringash: ^ FYI
<laduke-132>
hi, i did something and `nix-env -i emacs-mac` doesn't put a .app in ~/.nix-profile/Applications ... i think it did last time i messed with it
<LnL>
not sure, that looks right alltho I'd recommend installing stuff through attributes instead, eg. nix-env -iA nixpkgs.emacsMacport
<LnL>
but that should be the same, just not as slow :)
<laduke-132>
Thanks. yeah I still get confused about the different ways to refer to things, but that didn't do it either. I can't find whatever website I used in the first place.
<LnL>
yeah, it's a confusing situation
<LnL>
but installing doesn't fail and nix-env -q lists emacs?
<laduke-132>
yeah and emacs is there in bin, but not the .app
<LnL>
well I'm not sure what's going on, both emacs and emacsMacport have an app from what I can tell
<laduke-132>
dang it, computer
<laduke-132>
what's another package that makes an app? hmm
<laduke-132>
iterm2 worked...
<LnL>
maybe you're on a revision where the app broke or was disabled for some reason
<laduke-132>
maybe i used unstable before. anyways, i have an editor again!
taylor1791 has joined #nix-darwin
<taylor1791>
I am trying to run `nix run nixpkgs.darwin.xcode`, but it tells me to `nix-store --add-fixed --recursive sha256 Xcode.app`. However, I have already done it. Can anyone give me some debugging pointers?
__monty__ has quit [Quit: leaving]
<LnL>
abathur: btw, did you see the trustd stuff that happened recently?
<abathur>
the big slowdown yesterday?
<LnL>
apparently you could add 0.0.0.0 ocsp.apple.com to /etc/hosts to bypass the checks
<LnL>
(at least for now, who knows when they'll also bypass that)