<thefloweringash>
sorry if I'm a bit insistent, I just would really like to have stdenv ready for when big sur suddenly appears
hedgie_ has quit [Read error: No route to host]
hedgie has joined #nix-darwin
joebobjoe has quit [Ping timeout: 264 seconds]
joebobjoe has joined #nix-darwin
joebobjoe has quit [Ping timeout: 260 seconds]
<LnL>
oh mb, assumed you where offline
<LnL>
thefloweringash: my understanding of how linking like that works but yeah what we do know won't work without the dylib
<LnL>
as for the pr I'm not sure if there's much value in integrating changes until there's something basic that works
<thefloweringash>
the plan was to get a bootstrap tools linker with tbd support, and then swap out libSystem
<thefloweringash>
I could probably make a more conservative version that does it as part of the stdenv bootstrap, would have to try it and see, but it might land up with some duplication of Libsystem
<LnL>
isn't it easier to experiment on a branch?
<LnL>
the bootstrap tools are going to need more changes and then we don't have to worry as much about breaking stuff
<thefloweringash>
I have done some testing of the integrated changes on big sur and it does link `hello` at least
<LnL>
oh?
<LnL>
isn't libsystem still borked
<thefloweringash>
for the purposes of testing, I hacked in the libsystem.tbd from an apple sdk
<thefloweringash>
(I've only got access to a dtk. I'll sort out a big sur x86_64 machine in a few days)
<thefloweringash>
I figured that it was best to send off the PRs that have to go through staging early, so they have a chance to filter through
<thefloweringash>
adding libtapi is one stdenv rebuild, and updating the bootstrap tools would be another
<thefloweringash>
it should be possible to use the existing bootstrap tools just with a little extra care in the stdenv bootstrapping. if that's a more compelling PR to get merged I'm certainly happy to work on that
<thefloweringash>
as for an actual tbd. I'm hoping to run `tapi stubify` on a 10.12 VM, (still wip). Is that something we can reasonably include directly in nixpkgs?
<LnL>
hmm ok, I should take a proper look at this again
<thefloweringash>
it would be very much appreciated :-)
__monty__ has joined #nix-darwin
eraserhd has quit [Quit: WeeChat 2.9]
hedgie_ has joined #nix-darwin
hedgie has quit [Ping timeout: 256 seconds]
hedgie has joined #nix-darwin
hedgie_ has quit [Ping timeout: 244 seconds]
philr has quit [Ping timeout: 260 seconds]
hedgie_ has joined #nix-darwin
hedgie has quit [Ping timeout: 244 seconds]
<abathur>
thefloweringash most of this discussion is over my head or out of my wheelhouse but FWIW I got a 2018 MBA up on a clean install of big sur in the past few days and am picking at Nix installer issues, so if you have any simple "does XYZ" work sorts of questions...; one caveat is that the xcode CLI tools are refusing to install (unavailable) for me
disasm has quit [Ping timeout: 240 seconds]
joebobjoe has joined #nix-darwin
joebobjoe has quit [Ping timeout: 240 seconds]
<abathur>
LnL I was content to let it go when you said it yesterday, but I keep catching my mind wondering what you have in mind when you say "a full on declarative installer project"
disasm has joined #nix-darwin
<LnL>
thefloweringash: I've thought about moving stuff like the symbol list out of nixpkgs before, there's no real value having it in the repo IMHO
<LnL>
it also doesn't really have anything to do with nix directly, having a repo with that metadata could be useful for other things
<LnL>
we could potentially even use it for all the frameworks
<LnL>
as for libSystem, if this works I think we can indeed just replace our shim build which is easier than I was expecting
<LnL>
a good test would be to try and build something that links against a symbol that you removed from the tbd but that's actually present in the dylib
joebobjoe has joined #nix-darwin
<LnL>
I should check why my builder died, that one is still running 10.12.x
<LnL>
abathur: the current installer follows the traditional mutable model, plan + apply like nixos generally makes things easier once conditionals and stuff like that get involved
<LnL>
also updating and reconfiguring an existing installation are valid usecases that are not covered at all
<abathur>
LnL k; I imagined as much, but started to wonder (as I thought about some of the approaches I can imagine in shell) if you had something more specific in mind wrt to what the implementation would look like
joebobjoe has quit [Ping timeout: 265 seconds]
<LnL>
that's the other thing I feel bad about putting too much weird stuf in the nix repo, something separate/dedicated is more flexible including the language
<LnL>
there are a bunch of option that can still compile down to a static binary
<abathur>
it looks like there are technically at least 2 bugs in the logic for whether the installer tells someone to run --darwin-use-unencrypted-nix-store-volume
<abathur>
buuuut, the stars probably align, and I'm not sure anyone actually falls through the cracks? :)