| 19 Apr 2026 |
WeetHet | Randy wanted us to not pull vulkan into the closure by default | 13:45:00 |
K900 | Do we know the closure size impact? | 13:45:28 |
K900 | It should be pretty small, I think | 13:45:35 |
WeetHet | I think vulkan-loader pulls in moltenvk on darwin | 13:45:52 |
WeetHet |  Download Screenshot 2026-04-19 at 15.46.33.png | 13:46:38 |
emily | Qt already pulls it in unconditionally though? | 13:47:06 |
WeetHet | 20mb is quite a lot | 13:47:07 |
WeetHet | I don't have any Qt apps installed so I don't have moltenvk | 13:47:46 |
WeetHet | * I don't have any Qt apps installed so I don't have moltenvk in my system closure | 13:47:53 |
Randy Eckenrode | No, that’s fine for GTK. I just wanted it off by default for now (for the same reasons K900 gave). | 13:48:17 |
WeetHet | The default backend is still GL even if vulkan-support is enabled | 13:48:45 |
WeetHet | I thought you didn't want moltenvk in the closure by default at all | 13:48:57 |
WeetHet | * The default backend is still GL even if vulkanSupport is enabled | 13:49:42 |
Randy Eckenrode | No, that’s fine if it makes using KosmicKrisp easier via setting the correct driver variable in a wrapper. If I gave the impression about not wanting MoltenVK in the closure, that was my mistake. It just shouldn’t be the default renderer. | 13:50:25 |
Randy Eckenrode | emily Let me know if there’s any follow-up to my replies to your questions. Also regarding the 26.4 SDK fix, another reason I wanted to avoid the cctools-port fix is it mentioned decompilation in the PR. I’m not sure how it was used, but I figured it was better to finish my work and independently derive a fix. | 13:51:27 |
WeetHet | You still need to force it with GSK_RENDERER=vulkan | 13:51:43 |
WeetHet | Otherwise it uses GL | 13:51:49 |
emily | yep, will take a look soon (I might have also forgotten about other PRs pending on me if there are any) | 13:52:16 |
Randy Eckenrode |
- https://github.com/NixOS/nixpkgs/pull/511211
- https://github.com/NixOS/nixpkgs/pull/511070
- https://github.com/NixOS/nixpkgs/pull/485980
| 13:53:45 |
Randy Eckenrode | Those are my active ones. The 26.4 SDK one will be coming shortly. | 13:53:53 |
Randy Eckenrode | emily, here’s the 26.4 SDK: https://github.com/NixOS/nixpkgs/pull/511399 | 13:58:46 |
| qwrdd joined the room. | 13:59:56 |
qwrdd | Hello! As the next release will drop x86_64-darwin, what your thoughts about adding rosetta flag into linux-builder? | 14:01:21 |
Randy Eckenrode | https://github.com/NixOS/nixpkgs/pull/511400 fixes Rubberband. It was the only fallout I encountered from the darwin.libcxx update. | 14:02:15 |
emily | we did most of the libc++ 21 fixing already 😅 | 14:05:21 |
Randy Eckenrode | Somehow that got missed. | 14:05:48 |
Randy Eckenrode | Are we going to update to LLVM 22 by default for 26.05, or has the window passed for that? | 14:06:26 |
emily | technically we have a week, pragmatically we don't | 14:09:18 |
emily | https://nixos.github.io/release-wiki/Release-Critical-Packages.html oh actually no | 14:09:27 |
emily | LLVM is on there, it's too late | 14:09:35 |