| 11 May 2026 |
 emily | I think rcodesign is going to be a much better basis than sigtool | 11:57:15 |
| emily | (with all respect to lorne!) | 11:57:21 |
| emily | it is already more compatible and complete in terms of the underlying functionality | 11:57:30 |
| emily | and we have derivations patching codesign into rcodesign because of that | 11:57:37 |
| emily | it just needs a CLI layer | 11:57:49 |
| emily | do you mean https://gregoryszorc.com/blog/2024/03/17/my-shifting-open-source-priorities/ for the post? there has been plenty of activity since then https://github.com/indygreg/apple-platform-rs/commits/main/ | 11:58:49 |
| emily | and it is relied upon by a bunch of orgs to do code signing in CI | 11:59:14 |
| emily | the only obstacle is that there are 2-3 things that use codesign in bootstrap, and we'd rather not have Rust in bootstrap, but all of those can and should be fixed (I have WIP patches) | 11:59:44 |
| emily | * the only obstacle is that there are 2-3 things that use sigtool in bootstrap, and we'd rather not have Rust in bootstrap, but all of those can and should be fixed (I have WIP patches) | 11:59:50 |
| emily | (now that the linker does its own codesigning we need a codesign(1) far less than we used to) | 12:00:11 |
| emily | it would be really unfortunate to keep the ecosystem forked here IMO | 12:00:41 |
 viraptor | In reply to @emilazy:matrix.org
it just needs a CLI layer Yeah, I'm not fully committing to either way really. If we can improve sigtool, that's great. If we can get rcodesign to work, that's great.
I did a quick PR to test the waters and open communication in https://github.com/indygreg/apple-platform-rs/pull/308 but it's been close to 3 weeks without a response.
I'll just continue what I can - worst case we'll have two improved projects 🤷 | 12:18:50 |
| viraptor | But it's a bit more than the CLI layer too - the project itself needs some new features, so the necessary changes can't be done as an external CLI wrapper for example. | 12:20:00 |
 Randy Eckenrode | FWIW, don’t update on my current branch for your Swift Build work. It doesn’t build ATM. | 12:36:08 |
| Randy Eckenrode | The bootstrap situation for Swift is horrible. | 12:36:22 |
| viraptor | Thanks for the heads up. For now I'm mostly waiting for master to be ready post-release to do some more dependency groundwork / land the xcbuild fork. | 12:38:09 |
| Randy Eckenrode |
- We can’t build Swift 5.10.1 using the LLVM derivation because LLVM 16 was dropped from Nixpkgs.
- We can’t build a C++ bootstrap compiler because the only version that supports that is Swift 6.2.
- For a binary bootstrap, upstream expects to find the libc headers in the sysroot. Darwin has one. Linux does not.
| 12:39:05 |
| Randy Eckenrode | I’m currently leaning towards generating an SDK for Linux from libc and libstdc++ derivations. If that works, the wrapper will simply force the SDK and set up hardening flags. | 12:40:04 |
| Randy Eckenrode | * | 12:40:19 |
| Randy Eckenrode | This is like my fourth attempt at the bootstrap. Upstream makes some assumptions that don’t hold for us on Linux. | 12:41:50 |
| viraptor | In reply to @reckenrode:matrix.org
I’m currently leaning towards generating an SDK for Linux from libc and libstdc++ derivations. If that works, the wrapper will simply force the SDK and set up hardening flags. That... doesn't sound that bad overall? Unless I'm missing some serious downsides? | 12:49:54 |
| Randy Eckenrode | Probably not bad, but it’s annoying to have to do it. Darwin has it easy because I switched it to exposing the SDK like native tooling expects, which is exactly what the upstream Swift binaries need. Linux does everything via wrappers, which is horrible. I probably would have been done with this last year if Linux used sysroots like Darwin uses SDKROOT. | 13:09:52 |
| Randy Eckenrode | Whether I make Swift always use this sysroot on Linux, I don’t know. It would be more aligned with native tooling. If we could use a random Swiftly binary in a FHS env with Nixpkgs libc via the sysroot, that would probably make some users happy. | 13:11:03 |
| Randy Eckenrode | Same if we could consume a static SDK from upstream. | 13:11:22 |
 Ihar Hrachyshka | mesa 26.1 timed out for darwin in unstable so now my profiles rebuild a world :) why did it run for 2h+? https://hydra.nixos.org/build/328382105 | 14:16:07 |
 K900 | I believe @[Randy Eckenrode] had some ideas | 14:16:30 |
| K900 | But also Mesa should absolutely not be a world rebuild on Darwin | 14:16:39 |
| K900 | It should be used by like <100 things | 14:16:48 |
| Ihar Hrachyshka | maybe I stretched it. I saw my github runners doing a build for 3h and timed out and looks like most of the output was mesa: https://github.com/booxter/nix/actions/runs/25666597291/job/75341014760?pr=322
but if I enable timestamps I see that it just hanged there for hours before timing out. The last message from mesa is the same as on hydra. | 14:21:13 |
| Randy Eckenrode | Mesa is getting stuck looking for swrast_dri.dylib when it should be swrast_dri.so. I have a hacky workaround that forces it to look for .so even on Darwin. I can open a PR later today. | 14:30:25 |
