<dhess>
LnL: that would be great if the Darwin project had a column for Big Sur, yeah.
<dhess>
What's the general status at the moment? Looking back at the last week or so of chat log, it looks like we can't link on Big Sur at the moment and the installer is broken?
<dhess>
Installer is one thing; not being able to link is a showstopper
<abathur>
ah, yeah; I think installer will be OK once my PR gets merged, but I don't understand the link/compile/stdenv level well enough to glean how dire the situation is from the back-and-forth between LnL and thefloweringash
<LnL>
take this with a grain of salt, I don't have a machine to upgrade, but it's no as bad as I initially thought
<LnL>
if I understand correctly our libSystem didn't break so prebuilt binaries still work
<LnL>
as for building stuff libSystem will completely change, but my impression is that the tbd approach actually avoids all the problems we try to avoid with the wrapper
<LnL>
thefloweringash: I forgot did you try linking something while removing existing symbols from the tdb file?
<abathur>
the version check in releases and master will fail on big sur unless you set a compatibility flag (which causes sw_vers to report 10.16)
<abathur>
not certain that answers the question :)
<LnL>
yeah so not 100% correct but the version check does guard against it currently
<LnL>
I think it's probably a good idea to keep that until nixpkgs at least has initial support
<abathur>
mmm
<abathur>
open to whatever wrt to the best course, but I have two main "concerns"
<LnL>
also did a link test and that works exactly like we want :D
<LnL>
"_printf", referenced from: _main in hello-b4c2a0.o
<abathur>
1. there are changes already in master that break all macOS installs to some degree; if there's any chance of a release getting cut before this PR lands, there's going to either need to be an effort to cherry-pick those parts of this, or an effort to clean up the mess when the release breaks macOS installs for the Nth time in a calendar year
<abathur>
2. I don't have much interest in wasting a lot of effort swimming against further installer changes; I'd much rather add something that guards us from naive big-sur installs without a flag or env for now and remove it later than have to carefully tend against upstream changes
<abathur>
if that's the main concern?
<LnL>
yeah I forgot about the regressions
<LnL>
so in that case I'd say let's push for it if you're somewhat confident about the current changes
<LnL>
but still with a check for <11.0.0
<abathur>
it'd be nice to get broader testing, but I gather that's already part of the normal full release cycle?
<LnL>
no there's nothing
<LnL>
gchristensen made a valiant attempt at an install matrix at some point, but that's not actively used AFAIK
<abathur>
do you think it makes sense to have a workaround for letting people testing on big sur bypass the check?
<abathur>
ah, yeah
<abathur>
I can test at least on travis-ci for linux and macOS versions, with an asterisk on having a process for building release tarballs for each platform, so I've only bothered testing that for macOS
<LnL>
it's pretty easy to edit and disable o so I wouldn't spend time on extra options
<LnL>
ideally we remove the guard is removed before the next release
<LnL>
hrr
<abathur>
also, should the restriction apply equally to 10.16 and 11.0? at least in beta sw_vers reports 11.0 but I've been under the impression that, post-beta, older devices will report 10.16 and arm devices will report 11.0?
<abathur>
yeah
<abathur>
ideally :]
<abathur>
so I assume the actual restriction should bounce both 11.0 and 10.16, for now?
<LnL>
well arm is a completely different story, that will take more time
<abathur>
I guess arm would fail anyways, though, until there's an os+arch release tarball for it?
<LnL>
presumably that fails even earlier since we only have a x86_64-darwin tarball
<abathur>
nod
__monty__ has joined #nix-darwin
<LnL>
thefloweringash: do you have any thoughts on the file layout for the tbd files? thinking of writing something that looks for all system libraries and creates a mirror with all the stubs
<LnL>
then I can make a snapshot of 10.12 and we can pull stuff from there
<abathur>
I've got a tentative check added and I'm rebuilding a darwin release on a spare system so that I can test it later this afternoon
<LnL>
man, this is making me excited for reproducible frameworks
<antifuchs>
oof, I'm still reading "10.12" as "10.2" and wondering what we're doing with Jaguar
<abathur>
hehe
<LnL>
I wonder if the impure stdenv ever ran on power pc
<LnL>
whoa, I guess it did
<LnL>
ohno! error: cannot convert '/usr/lib/libSystem.B.dylib' to a text-based stub file
<abathur>
LnL: pushed a check for big sur to nix#3996
<thefloweringash>
which has a list of things that nixpkgs uses
<thefloweringash>
I'm assuming that doing a tabi stubify ourselves is less problematic than using apple's sdk directly, otherwise we could save some effort and go straight to upstream