As a nix-darwin user, I was happy living on unstable for a while, until I started getting more build issues than I liked… so I decided to switch to a release channel for more stability - nixpkgs-24.05-darwin
Things were good for a while, but an issue was introduced into this release channel which affected the swift package, which has prevented me from doing a darwin-rebuild switch for about ~2 months now: Build failure: swift · Issue #327836 · NixOS/nixpkgs · GitHub
On trunk, 3/4 platforms cannot build the swift package:
And this may be fine and expected for a trunk branch (I don’t know), but but what is most concerning for me, is that platforms on the RELEASE branch are affected:
Some people have submitted patches to help try and fix the issue, but the problem remains - builds remain broken on hydra for a long time now. There’s been several calls to the maintainers for help, but as far as I can see they haven’t responded. I know maintainers have lives and may be busy, but it’s a long time for a core package to remain broken imo
So I suppose for me, my gripe is that I switched to a release branch for stability, but I’ve found that it’s not stable. Shouldn’t the goal of release branches be stability, above all else? Should the changes that introduced these build failes have been prevented from being merged? Or am I doing it wrong, and should I be doing something differently?
Swift broke as a downstream result of other changes. It’s not feasible to build all packages before merging widespread changes because it takes a long time and there are always things that break; the latency for our mass‐rebuilds staging branch cycle is measured in weeks because of this. Our backstop against big problems is the Hydra job sets that are required to successfully build before the channel branches advance.
Unfortunately, the constitutents of those job sets are chosen somewhat arbitrarily and could certainly use reworking, especially for Darwin. It would be great to be able to ensure Swift always builds on the channels, but it’s been a perennial problem package on macOS so we would likely need to clean it up some to make it more robust before that’s possible. I believe there has been some talk of that becoming easier with the upcoming macOS SDK rework.
Not sure of the exact changes that went into the master branch over the past few weeks since I last tried to build swift, but I just attempted against the latest commit to master (at the time of this post) and I was able to build it on aarch64-darwin successfully, so perhaps other arches/OSes will have similar positive results.
Edit: nvm, ignore that. It seems not to work again.
swift is now failing to build on Linux. It’s a transitive dependency of deadbeef (an audio player). The direct dependency is swift-corelibs-libdispatch.
The build error occurs when running swig to create Python bindings:
Oh, dear; this is a SWIG 4 regression we didn’t catch during the last staging cycle. There’s patches to LLVM that will fix this, though the Swift derivation scares me. I’ll look into it.
