| 8 Dec 2025 |
 tiferrei | Fixed: Nuked the nix-darwin installation, then the whole nix installation. reinstalled nix and reapplied nix-darwin. | 12:31:58 |
 Ihar Hrachyshka | Is there a policy / rule / expectation that would not allow to merge breaking changes for darwin to bump a version of a package? context: https://github.com/NixOS/nixpkgs/pull/463817#issuecomment-3627032203
I'd think we shouldn't KNOWINGLY merge breaking changes, except in situations like security issues; and instead invest time in fixing problems before merge. But apparently there are alternative views. What's acceptable? | 15:16:04 |
 Randy Eckenrode | RFC-46 is about it. Darwin is not a tier 1 platform, so while not ideal, Darwin probably shouldn’t be blocking updates for Linux. | 15:18:34 |
| Ihar Hrachyshka | I don't understand why the rush. it's been 3 weeks total since the issue was even detected. | 15:22:29 |
 toonn | What is agreed upon is that breaking Darwin is OK after notifying darwin-maintainers and giving them a reasonable period to act. | 16:44:43 |
| Ihar Hrachyshka | reasonable does some heavy lifting here :) | 17:01:18 |
| toonn | Well in this case there wasn't even a ping to darwin-maintainers, no? | 17:03:49 |
| Ihar Hrachyshka | indeed. it was probably assumed I'll just take care of it since I "know" about the issue. | 17:11:08 |
| Ihar Hrachyshka | btw wonder if core team has opinions on way forward there. Looks like linker on darwin doesn't handle patch versions above a (high) number: https://github.com/ggml-org/llama.cpp/issues/17258
there are some hacks in the issue - splitting the "high" version number into pieces, overriding... - I wonder what would be acceptable in nixpkgs. | 17:13:56 |
| toonn | I don't see an elegant solution honestly. | 17:30:39 |
| Ihar Hrachyshka | right. ideally upstream takes it seriously and bumps their minor to 0.1.XXXX and do the minor bump periodically to accommodate darwin. | 17:31:45 |
 emily | one week without meaningful progress has been our general rubric | 17:31:58 |
| Ihar Hrachyshka | otherwise we have to fake our own version numbers (just for darwin?) and risk divergence | 17:32:10 |
| emily | I think 3 weeks is more than enough notice on unstable | 17:32:26 |
| emily | (ofc the more load-bearing a package is the longer a period is reasonable, e.g. a default LLVM version bump that breaks Darwin is certainly not acceptable, but this is not a channel blocker etc.) | 17:32:49 |
| emily | they say it doesn't reproduce in CI. are we sure this is their problem? | 17:33:04 |
| Ihar Hrachyshka | one part of the equation is this package "versions" are really just trunk bumps | 17:33:07 |
| emily | if it's to do with the linker, perhaps it is because of us using the abandoned ld64? | 17:33:13 |
| Randy Eckenrode | Looks like a Mach-O limitation. | 17:33:32 |
| Ihar Hrachyshka | if that would be some real release process, it would look differently. the way it is, I'm asked to track their trunk at week notice. | 17:33:35 |
| emily | the person reporting the bug says they are using "a Mac 11", which implies probably pre-ld-prime Xcode | 17:33:43 |
| Ihar Hrachyshka | I triggered the build failure on my own mac, not some old version (15 or 26, can't remember) | 17:34:15 |
| emily | with Nixpkgs toolchain or Xcode? | 17:34:35 |
| emily | I think we need to understand why upstream's CI has no failure before we expect them to debug it as their issue: https://github.com/ggml-org/llama.cpp/actions/runs/20029229634/job/57433899126 | 17:34:56 |
| Ihar Hrachyshka | nixpkgs. yes it may be nix-specific, all others in the issue seem to talk about nix package | 17:35:14 |
| emily | well, we use a linker that is not the official default linker for macOS, that is deprecated upstream, and that has been more or less abandoned. | 17:36:09 |
| Randy Eckenrode | Source releases were updated. | 17:36:26 |
| emily | so if the build is failing because of ld64 not handling something that the Xcode linker can handle, it's our problem to solve, not llama.cpp's. | 17:36:29 |
| emily | ld64's? yeah, I saw it got some changes | 17:37:03 |
| emily | but it's certainly marked as deprecated, I'm assuming it's only getting very minimal maintenance before it goes away | 17:37:17 |
