Nix on macOS | 1147 Members | |
| “There are still many issues with the Darwin platform but most of it is quite usable.” — http://yves.gnu-darwin.org | 182 Servers |
| Sender | Message | Time |
|---|---|---|
| 27 Nov 2025 | ||
it looks in $DEVELOPER_DIR/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/share/man | 20:37:48 | |
| which doesn't exist in our current SDKs, but feels like it pretty easily could, since we download manpages as part of the SDK | 20:40:06 | |
| unless what's downloaded still needs to be built and that build requires llvm-manpages | 20:40:31 | |
| * unless what's downloaded still needs to be built and that build requires llvm-manpages? | 20:40:33 | |
| No, they’re removed to limit what we’re distributing from the SDK to headers and stubs since those are arguably necessary for interoperability. Most of those man pages should be obtainable from the source releases. | 20:41:31 | |
We could possibly smuggle them in via the empty darwin.libSystem derivation. | 20:41:59 | |
| 28 Nov 2025 | ||
| I’ve picked my Swift work back up. I’m trying to make the versioning of the LLVM fork more accurate to what Apple uses. The source is LLVM 19.1.5, but the version reported is 17.0.0. That’s probably going to make dealing with the overrides a lot of fun. | 16:27:47 | |
| The new, scope-based LLVM is so much nicer to override. There’s still jank, but I don’t have to do anything to handle build vs. host vs. target packages.
| 17:26:02 | |
| * The new, scope-based LLVM is so much nicer to override. There’s still jank, but I don’t have to do anything to handle build vs. host vs. target packages.
| 17:30:48 | |
| The weird version overrides are because of the way LLVM captures the version. | 17:31:14 | |
| I want the package version to match the one advertised by Swift. Ideally, I could it to build LLVM, but that would really break the patches. | 17:32:44 | |
| * | 17:32:52 | |
| * | 17:33:15 | |
(This means the Swift clang will print 19.1.5 for its version instead of 17.0.0.) | 17:34:26 | |
| exciting! | 20:44:08 | |
| do let me know if i can help at all | 20:44:12 | |
I have a weird build error that I'm trying to fix. python3Packages.torchtune crashes in importsCheckPhase when it imports python3Packages.sentencepiece on Darwin. I've confirmed that other python packages that depend on sentencepiece fail in the same way, but not if it's only used as a check dependency. The final weirdness: nix-build of sentencepiece picks up a prebuilt package, but calling it with --check shows a non-deterministic build. | 21:05:19 | |
| Console.app is how I first depetermined its sentencepiece | 21:05:51 | |
| * Console.app is how I first determined it's sentencepiece that's failing | 21:07:08 | |
| 21:12:23 | |
| * error: derivation 'rj3n6mm11f90ssv0az0aplkiy9b2s48l-python3.13-sentencepiece-0.2.1.drv' may not be deterministic: outputs differ output '/nix/store/cpjk1gyzyz6j18jxfpsswdd0rggyzjah-python3.13-sentencepiece-0.2.1' differs | 21:12:29 | |
*
| 21:24:35 | |
| That’s expected on Darwin. | 21:48:53 | |
| The non-deterministic build? | 22:03:27 | |
| Or the sentencepiece crash? (In which case I would mark Darwin as a bad platform) | 22:03:52 | |
| This. | 22:08:35 | |
| OK, so it's non-causal. | 22:09:25 | |
| Here's the import crash:
| 22:09:42 | |
| Looking through sentencepiece's issues, they finger SWIG as the culprit (potentially fixed in SWIG 4.4.0). There may be a patch to apply in the meantime without bumping SWIG. | 23:20:51 | |
| 29 Nov 2025 | ||
| I'll just link the ongoing saga here https://github.com/NixOS/nixpkgs/issues/466092 | 00:41:37 | |