andremedeiros has quit [Quit: ZNC 1.8.2 - https://znc.in]
andremedeiros has joined #nix-darwin
cransom has quit [Ping timeout: 265 seconds]
__monty__ has joined #nix-darwin
cransom has joined #nix-darwin
dhess has joined #nix-darwin
<dhess>
thefloweringash: around?
<thefloweringash>
Yep
<dhess>
thefloweringash: thank you SO MUCH for all of the macOS work you've been doing this year!
<thefloweringash>
Thanks :-)
<dhess>
thefloweringash: curious what's the story with code signing? There was talk this summer that it would be required (even if ad hoc) and I know you were/are working on that signing tool, but it doesn't appear to be in the new stdenv.
<dhess>
So is it not actually required on Big Sur?
<thefloweringash>
Code signing is required on the aarch64 macOS
<dhess>
ahh I see
<dhess>
so I take it that's in your apple-silicon tree?
<dhess>
right I see now
<thefloweringash>
Yeah. There’s a hook that signs everything after the end of the build, and an extra step in the linker wrapper to sign everything that’s linked.
<dhess>
thefloweringash: I wonder if it would be possible or advisable, until Apple Silicon support is merged into nixpkgs trunk, to modify the macOS stdenv to return x86_64-darwin when evaluated on Apple Silicon so that at least we can run nixpkgs in Rosetta 2? What do you think?
<thefloweringash>
I agree we should use Rosetta for now. But I don’t think we to do anything to achieve that. Nix built for x86_64-darwin will return that for the current system.
<dhess>
thefloweringash: I was under the impression from an issue somewhere that running x86_64-darwin nix-build etc on the DTKs was complaining that there was no nixpkgs for the platform. Was that only for the installer?
<{^_^}>
nix#4243 (by abathur, 6 days ago, merged): enable Darwin.arm64 to install x86_64 binary
<dhess>
oh excellent!
<thefloweringash>
I don’t know if that’s in the current release version
<dhess>
thefloweringash: so basically, just install nix on Apple Silicon machines as usual, it will install the x86_64-darwin binaries, and then everything should more or less work under Rosetta?
<thefloweringash>
Yeah, that’s the idea at least. Most things seemed to work ok on the dtk, but I guess we’ll see how well it works when people start getting their new Macs
<LnL>
thefloweringash: did you see the patch I posed a few days ago for bootstrapping on 11.0?
<dhess>
thefloweringash: amazing!
<dhess>
I've got an M1 13" MacBook Pro on the way. Looking forward to seeing how it deals with GHC in Rosetta 2 :)
<thefloweringash>
LnL: it’s on my todo list. Seems reasonable to me, though I suspect core foundation might bite you
<thefloweringash>
I’m waiting on a Mac mini myself, last I heard it was in Shanghai
<LnL>
hmm, in what way?
<thefloweringash>
IIRC, core foundation is required, but only present because of the dependencies using { outPath = bootstrapTools; }. Should only be a minor hiccup though
<LnL>
ah like that
<LnL>
in principle we don't need to mess with the stuff I did there if libSystem isn't in the bootstrap tarball anymore but breaking stuff up seems a bit cleaner
<LnL>
as for darwin-stubs I think we should add a tarball build which we can upload to a github release or tarballs.nixos.org
<LnL>
that way it doesn't need to hash after unpacking which is really tricky that early on
<LnL>
currently we get fetchFromGitHub -> fetchzip -> curl, perl, cacert, ...
<LnL>
and from what I can tell builtin:fetchurl only supports unpacking nars
<thefloweringash>
I approve of making the stdenv bootstrapping cleaner
<thefloweringash>
I don’t know what the future holds for that darwin-stubs repo, but if we were to get a lot of versions it’d make sense build some kind of CI (github actions) that uploaded a tarball per version
<LnL>
nice thing about having all the versioned stubs together is discoverability
<LnL>
if we generate everything up to 11.0 it can be used to easily find when symbols where added, etc.
<antifuchs>
uh, is dhh just stringing together arbitrary statements about system configuration software? I don't quite understand how a homebrew delay puts cold water on nix dev?
<gchristensen>
I don't think he's talking about Nix
<antifuchs>
oh, i guess "*nix"
<antifuchs>
that makes more sense
<abathur>
yeah
<LnL>
weird
<LnL>
is that homebrew statement about M1 hardware or aarch64 binaries?
<domenkozar[m]>
dhh is part of mentorship of earnest capital that invested into cachix
<domenkozar[m]>
so we can get some big PR with this
<domenkozar[m]>
LnL: binaries
<domenkozar[m]>
or just the general lack of arm support