| 3 Jun 2026 |
 Randy Eckenrode | I’m still waiting on the tessellation MR before trying it again with FFXIV. | 11:24:35 |
 Sarah Clark | Excellent question. The aarch64-linux failures are happening on Hydra; I don't know which filesystem it's using. | 17:23:43 |
| Randy Eckenrode | If it’s Hydra, I’d assume the builders are set up similarly between architectures and sensibly. Otherwise, they would fail building Git. | 17:24:59 |
| Sarah Clark | Just so. My next step is to compile a list of affected packages to look for similarities. I may also run a bisection. | 17:27:59 |
| Randy Eckenrode | Looks like it should be landing in the next day or two. They’ve made some good progress on KosmicKrisp. Maybe we can make it the default for 27.11. | 23:54:33 |
| 4 Jun 2026 |
|  Katalin 🔪 changed their profile picture. | 02:06:23 |
|  Echo changed their profile picture. | 04:23:53 |
 lcenchew | Redacted or Malformed Event | 04:30:15 |
| lcenchew | Hi, I’m trying out nix-darwin. Any suggestions on where to learn more about how nix-darwin handles installation of .app.
From what looking at the folder, it seems to put a copy in /Applications/Nix Apps/
How to handle updates from with the app? Check should be turned?
Can Nix Apps/ points to an external storage? | 05:50:09 |
 samasaur | Looking at the source (and the PR for reasoning) is the only authoritative answer. The short version is that we copy apps because every other option is worse.
In general apps packaged with Nix try to turn off auto-updates, though I suppose auto-updates would work since the apps are copied out of the store.
| 05:56:37 |
| samasaur | as for external storage, you'd have to expand on what your question is | 05:57:09 |
| lcenchew | For example, I like to have app pkgs be placed at /Volumes/ssd/nix/Applications/Nix Apps/
Is this configurable? | 06:37:49 |
|  tim joined the room. | 07:23:08 |
| samasaur | In reply to @lcenchew:matrix.org
For example, I like to have app pkgs be placed at /Volumes/ssd/nix/Applications/Nix Apps/
Is this configurable? There isn't a built-in option for this, though you could of course replace the activation script with a custom one that uses that location | 16:46:35 |
|  @logn:zirco.dev left the room. | 21:34:49 |
| 7 Jun 2026 |
| samasaur | release branch has been cut; apologies for the delay. lmk if you run into any issues | 06:13:30 |
 niklaskorz | For zed-editor we've run into the linker error "ld: b(l) ARM64 branch out of range (-157637180 max is +/-128MB)" during an update (https://github.com/NixOS/nixpkgs/pull/527683) and a suggested working fix is -C code-model=large, but I found LLVM discussions mentioning that code-model large is unmaintained or incomplete for aarch64-darwin. Does anyone know if code-model large is fine to use as a workaround here or if there is a better approach? | 08:49:09 |
| Randy Eckenrode | What does upstream do? | 11:57:15 |
| Randy Eckenrode | Can we use ld64? It should be at the latest version now. | 11:58:08 |
| Randy Eckenrode | I’m also surprised that code-model=large worked. Darwin is always PIE. Absolute address instructions are supposed to be rejected by the linker. | 12:01:29 |
|  richarddodd joined the room. | 14:16:38 |
| niklaskorz | Hm I can't actually see any custom darwin linker settings upstream... | 15:55:26 |
| 8 Jun 2026 |
| niklaskorz | We're not overriding the linker, upstream isn't either, so my assumption is we are already linking with ld64 and upstream might be linking with Apple's proprietary linker (ld-prime) although I have no insight in what macOS and Xcode version their Github actions runner is using. | 09:26:25 |
| niklaskorz | They have a custom runner from namespace.so and it's only referenced as "namespace-profile-mac-large" | 09:27:29 |
| niklaskorz | but I now see their own in-repo nix derivation explicitly sets lld as linker on darwin because of the same error 🙃 | 09:29:17 |
| niklaskorz | https://github.com/zed-industries/zed/blob/88e5c6d2faad2a556deb3250357df6f720b7fb3c/nix/build.nix#L253-L257 | 09:29:24 |
| Randy Eckenrode | If upstream is using LLD, that seems the way to go. We're matching how they build on Darwin, and we’re not doing something LLVM says is not supported very well. | 10:32:07 |
| niklaskorz | Understood, thank you! | 11:04:57 |
| Randy Eckenrode | Boo. Apple almost announced macOS 27 would have no name. I wish that were true. | 17:06:00 |
| samasaur | ooh they've "rebuilt search" including how spotlight works | 17:14:53 |
