| 16 Apr 2026 |
 EsperLily [she/her] | but if you got it accessing packages.aarch64-darwin.foo then that means your mkIf condition was wrong | 19:49:28 |
| EsperLily [she/her] | because that error should only show up when the mkIf condition evaluates to false | 19:49:43 |
| EsperLily [she/her] | but again i'm recommending you do the dynamic attribute approach rather than the mkIf so that way it's simply not defined in non-darwin package sets | 19:50:14 |
| EsperLily [she/her] | you only need mkIf if you're relying on other parts of the config. it looks like for perSystem, the argument system is a specialArgs so you can use that strictly. actually I suggested before writing ${if stdenv.hostPlatform.isDarwin then … } but you can't actually do that as stdenv comes from pkgs which is presumably not a special arg. you can refer to the system arg safely this way though | 19:52:37 |
 xored | EsperLily [she/her] Randy Eckenrode that seems to have worked, thank you both | 20:09:41 |
| xored | now i just need to figure out the hellhole that is packagesFromDirectoryRecursive to make the auto packages exclude a platform somehow | 20:10:55 |
| xored | but for manual packages seems to have done the trick | 20:11:06 |
| EsperLily [she/her] | in the general case it may be better to just use meta.platforms to mark platform-specific packages, so that way the attribute path itself exists on other platforms, which interacts better with callPackage (it's generally simpler for a package to declare the argument and then just conditionally use it, than to mark the argument as nullable and assert that it has a value on the expected platform) | 20:12:39 |
| xored | right, but I remember reading something about not having to eval | 20:13:53 |
| xored | so what i'm thinking is to have a directory with the platform name and somehow filter these out, so you'd have packages/x86_64-linux/foo for platform-specific packages | 20:14:31 |
| xored | only if you're curious: https://github.com/drupol/pkgs-by-name-for-flake-parts/blob/main/flake-module.nix | 20:16:32 |
| xored | I'd have access to system | 20:16:52 |
| xored | i just need to find a way to have them filtered out from packages and legacyPackages, nix flake show:_ | 20:17:24 |
| xored | └───x86_64-linux
├───nvim omitted (use '--all-systems' to show)
├───prometheus-opnsense-exporter omitted (use '--all-systems' to show)
├───write-flake omitted (use '--all-systems' to show)
├───write-inputs omitted (use '--all-systems' to show)
├───write-lock omitted (use '--all-systems' to show)
├───x86_64-linux/arrs/prowlarr omitted (use '--all-systems' to show)
├───x86_64-linux/arrs/radarr omitted (use '--all-systems' to show)
├───x86_64-linux/arrs/seerr omitted (use '--all-systems' to show)
└───x86_64-linux/arrs/sonarr omitted (use '--all-systems' to show)_
| 20:17:58 |
| 17 Apr 2026 |
|  LogN changed their display name from LogN [unavailable @ CinemaCon -> 4/18] to LogN. | 01:24:09 |
 Randy Eckenrode | Got network_cmds building finally. It ended up being easier to restore the XNU headers build than to try to keep scraping structs out of files. Unfortunately, the XNU headers still have to be copied because some conflict with the SDK. | 04:03:48 |
 viraptor | @reckenrode:matrix.org i finally got to compile your swift-update-mk2 branch to play with hammerspoon, but even with your settings.json and the posted command for swbuild, it still tries to run xcodebuild -dumpPIF almost immediately. I tried a few different things and playing with DEVELOPER_DIR to get to where you were but no luck. Have you got a branch from your experiments? It could save me some head-desk time 😀 | 12:03:14 |
| viraptor | * @reckenrode:matrix.org i finally got to compile your swift-update-mk2 branch to play with hammerspoon, but even with your settings.json and the posted command for swbuild, it still tries to run xcodebuild -dumpPIF almost immediately. I tried a few different things with the build service location and playing with DEVELOPER_DIR to get to where you were but no luck yet. Have you got a branch from your experiments? It could save me some head-desk time 😀 | 12:13:48 |
| viraptor | * @reckenrode:matrix.org i finally got to compile your swift-update-mk2 branch to play with hammerspoon, but even with your settings.json and the posted command for swbuild, it still tries to run xcodebuild -dumpPIF almost immediately. I tried a few different things with the build service location and playing with DEVELOPER_DIR to get to where you were but no luck yet. Have you got a branch from your experiments? It could save me some head-desk time 😀
Edit: just having a bad feeling - you didn't shim the whole xcbbuildservice for this, right?... | 12:17:18 |
| viraptor | * @reckenrode:matrix.org i finally got to compile your swift-update-mk2 branch to play with hammerspoon, but even with your settings.json and the posted command for swbuild, it still tries to run xcodebuild -dumpPIF almost immediately. I tried a few different things with the build service location and playing with DEVELOPER_DIR to get to where you were but no luck yet. Have you got a branch from your experiments? It could save me some head-desk time 😀
Edit: just having a bad feeling - you didn't custom shim the whole xcbbuildservice for this, right?... | 12:17:43 |
| Randy Eckenrode | I was using my branch without any changes, the provided settings.json, and the command-line as posted. I don’t think I’ve changed anything in how Swift Build is built in the meantime. I’m also pretty sure I tried building it in a derivation and not locally where it might pick up the installed xcodebuild by accident, but I can’t recall exactly. | 12:59:52 |
| Randy Eckenrode | Unrelated, but autoreconfHook is turning into autoBreakDarwinHook. | 13:00:30 |
| Randy Eckenrode | Anything that uses libiconv is getting broken because it has questionable ideas about how libiconv should behave. (While this issue is technically a behavioral difference and possibly a bug in Apple’s implementation, it’s not clear how likely it is a problem in practice.) | 13:01:20 |
| Randy Eckenrode | I wonder if we should apply the UTF-8-MAC patch to GNU libiconv and just use that. The ABI compatibility stuff should still be there in our derivation. | 13:06:16 |
| Randy Eckenrode | I’m currently doing a rebuild with the patch applied. I’m rebuilding all Darwin source releases plus .NET plus vulkan-caps-viewer, which involves building GJC, node, etc. | 16:01:05 |
 axw | system.defaults.customUserPreferences really should be a homemanager setting. | 20:08:18 |
| axw | Or how can that be set with different values for different users? | 20:09:17 |
| viraptor | I'm digging into this and I don't think we can actually use just swbuild. Here's my messy hammerspoon on your branch https://github.com/viraptor/nixpkgs/commit/ec6761783b0a57ed786bfc14df90c5a1ebb69b03 but in a sandbox it still fails on trying to access xcodebuild. It seems to be an unconditional thing in https://github.com/swiftlang/swift-build/blob/22b0c927248b2b4a4217fc0c72aed293b2c68df1/Sources/SWBBuildService/Messages.swift#L211
There's also no .pbxproj parser linked anywhere in that project that I can find. I think swbuild still relies on xcodebuild in the end, so I'll need to fix up the old facebook one 😢 | 20:56:46 |
| Randy Eckenrode | What does -dumpPIF do? Is there a compromise where the Facebook one gains the ability to do that? | 21:21:33 |
| Randy Eckenrode | This just makes me hate Swift more. It’s fake open. | 21:23:46 |
