| 20 Dec 2025 |
Randy Eckenrode | What I’d like to do is build Swift Syntax separately and relink the compiler against it (or actually copy the dylibs out of the compiler and relink it). | 01:26:43 |
Randy Eckenrode | * | 01:26:51 |
Randy Eckenrode | The goal is to have everything in its own package. | 01:27:10 |
Nadia | is there a way to get rid of all the warning: unhandled Platform key FamilyDisplayName spam from nixpkgs's compilers? (Or is it some weird issue with my setup that's causing those?) | 17:52:53 |
samasaur | I think Randy has a PR up that fixes that issue | 17:53:14 |
Nadia | ah alright | 17:54:30 |
emily | just merged it, sorry for the delay :) | 18:26:39 |
emily | but staging, so… | 18:26:45 |
emily | Randy Eckenrode: did a review pass on your open PRs, lmk if I missed any important pending Darwin thing from someone else | 18:47:15 |
Randy Eckenrode | Thanks. I left a few comments. I’ll respond more fully to the Darwin stdenv cleanup later tonight. I think we’re going to have to decide what trade-off we want to make because that’s just the nature of the overlay-based approach to bootstrapping we use. | 21:59:08 |
Randy Eckenrode | Maybe if we overlaid the previous stage as the buildPackages, it would be cleaner. That’s way outside the scope of this PR. | 21:59:53 |
Randy Eckenrode | I also want to land ‘Darwin is useLLVM’ first. | 22:00:13 |
| 21 Dec 2025 |
Randy Eckenrode | I pushed a commit using the second approach you suggested. The first one didn’t work. | 01:40:14 |
Randy Eckenrode | Darwin appears to be very broken on staging. | 18:36:59 |
K900 | staging or next? | 18:38:27 |
Randy Eckenrode | Staging, though it appears pkgconf got bit by the code signature bug. | 18:38:53 |
Randy Eckenrode | sigtool is failing to build, but I don’t know whether that’s related. I’m going to fix the signature and see if those things build. | 18:39:30 |
Randy Eckenrode | $ /usr/bin/codesign -vv -f /nix/store/wval0a2ldkb3vxahmpydaqbvsmsxshzj-pkgconf-2.4.3/bin/pkgconf
/nix/store/wval0a2ldkb3vxahmpydaqbvsmsxshzj-pkgconf-2.4.3/bin/pkgconf: invalid signature (code or signature have been modified)
In architecture: arm64
| 18:40:46 |
Randy Eckenrode | Yeah, fixing the signature worked. That’s really annoying. | 18:41:28 |
Randy Eckenrode | I hope switching to LLD will fix that, but switching is non-trivial. | 18:41:44 |
crushing-smite | Copying from main nixos channel:
| 18:47:01 |
crushing-smite | There's targets.darwin.linkApps which is enabled by default - yet I see no shortcuts created in app menu on mac Does that mean I should use targets.darwin.copyApps instead? Or am I holding it wrong (it used to generate the shortcuts in the past) | 18:47:17 |
crushing-smite | Reading this https://github.com/nix-darwin/nix-darwin/pull/1396 and this https://github.com/nix-community/home-manager/pull/8031 - my usecase is only app launcher, no spotlight, and I am okay with apps showing twice in dock/launcher - I can launch both and see which version is the newest, or I can garbage-collect in advance. With that said, what would be my preferred way to "install" the GUI apps then? | 18:59:02 |
crushing-smite | I am also okay with manually re-assigning the apple security permissions. But I really want the apps to show the latest version in launcher. | 18:59:55 |
crushing-smite | * I am also okay with manually re-toggling the apple security permissions. But I really want the apps to show the latest version in launcher. | 19:00:03 |
crushing-smite | * I am also okay with manually re-toggling the apple security permissions. But I really want the apps to show the latest version in launcher upon a darwin-rebuild. | 19:00:12 |
samasaur | linkApps should still create symlinks. Spotlight (and thus the app launcher in Tahoe onwards) don't pick up symlinks, so you probably want to use copyApps instead | 19:07:45 |
samasaur | The general consensus is that copying apps is better in pretty much every metric | 19:08:14 |
crushing-smite | Is app launcher = spotlight? | 19:08:48 |
crushing-smite | like, same """app"""? | 19:09:11 |