| 27 Nov 2025 |
 Randy Eckenrode | If there’s a way we can make it available automatically in dev shells, we can do that to improve the UX. Otherwise, it can be in the stdenv because it would pull a bunch of Python deps into the bootstrap. | 20:12:56 |
 samasaur | isn't llvm-manpages just an issue for cctools? | 20:20:50 |
| samasaur | like the API manpages are from the SDK an dseem like they were just rm'd | 20:21:04 |
| Randy Eckenrode | If any of the source releases have them, they’re usually included in the build. | 20:33:51 |
| samasaur | but for like. man write in a dev shell | 20:36:49 |
| samasaur | it looks in $DEVELOPER_DIR/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/share/man | 20:37:48 |
| samasaur | 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 |
| samasaur | unless what's downloaded still needs to be built and that build requires llvm-manpages | 20:40:31 |
| samasaur | * unless what's downloaded still needs to be built and that build requires llvm-manpages? | 20:40:33 |
| Randy Eckenrode | 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 |
| Randy Eckenrode | We could possibly smuggle them in via the empty darwin.libSystem derivation. | 20:41:59 |
| 28 Nov 2025 |
| Randy Eckenrode | 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 |
| Randy Eckenrode | 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.
(llvmPackages_19.override {
officialRelease = {
version = "19.1.5"; # From https://github.com/swiftlang/llvm-project/blob/swift-$swiftVersion-RELEASE/cmake/Modules/LLVMVersion.cmake
};
monorepoSrc = fetchFromGitHub {
owner = "swiftlang";
repo = "llvm-project";
tag = "swift-${lib.getVersion swift}-RELEASE";
hash = "sha256-DahdGT8VMBOXuwfhtXIJGFJmmhzzoQ6NdpU2CDs5B/s=";
};
otherSplices = generateSplicesForMkScope [
"swiftPackages"
"llvmPackages"
];
}).overrideScope
(
_: prev: {
version = "17.0.0"; # From https://github.com/swiftlang/swift/blob/swift-$swiftVersion-RELEASE/utils/build_swift/build_swift/defaults.py#L51
}
)
| 17:26:02 |
| Randy Eckenrode | * 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.
let
swiftlangLlvmVersion = "17.0.0"; # From https://github.com/swiftlang/swift/blob/swift-$swiftVersion-RELEASE/utils/build_swift/build_swift/defaults.py#L51
llvmVersion = "19.1.5"; # From https://github.com/swiftlang/llvm-project/blob/swift-$swiftVersion-RELEASE/cmake/Modules/LLVMVersion.cmake
in
(llvmPackages_19.override {
officialRelease = { version = llvmVersion; };
monorepoSrc = fetchFromGitHub {
owner = "swiftlang";
repo = "llvm-project";
tag = "swift-${lib.getVersion swift}-RELEASE";
hash = "sha256-DahdGT8VMBOXuwfhtXIJGFJmmhzzoQ6NdpU2CDs5B/s=";
};
otherSplices = generateSplicesForMkScope [
"swiftPackages"
"llvmPackages"
];
}).overrideScope
(
_: prev: {
version = swiftlangLlvmVersion;
release_version = llvmVersion;
}
)
| 17:30:48 |
| Randy Eckenrode | The weird version overrides are because of the way LLVM captures the version. | 17:31:14 |
| Randy Eckenrode | 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 |
| Randy Eckenrode | * | 17:32:52 |
| Randy Eckenrode | * | 17:33:15 |
| Randy Eckenrode | (This means the Swift clang will print 19.1.5 for its version instead of 17.0.0.) | 17:34:26 |
| samasaur | exciting! | 20:44:08 |
| samasaur | do let me know if i can help at all | 20:44:12 |
 Sarah Clark | 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 |
| Sarah Clark | Console.app is how I first depetermined its sentencepiece | 21:05:51 |
| Sarah Clark | * Console.app is how I first determined it's sentencepiece that's failing | 21:07:08 |
| Sarah Clark |
| 21:12:23 |
| Sarah Clark | * 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 |
| Sarah Clark | * 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:24:35 |
| Randy Eckenrode | That’s expected on Darwin. | 21:48:53 |
| Sarah Clark | The non-deterministic build? | 22:03:27 |
| Sarah Clark | Or the sentencepiece crash? (In which case I would mark Darwin as a bad platform) | 22:03:52 |
