| 8 Dec 2025 |
 Randy Eckenrode | https://www.swift.org/documentation/articles/wrapping-c-cpp-library-in-swift.html#cmake | 02:17:14 |
| Randy Eckenrode | I wonder if Nix could (ab)use VFS overlays with Clang instead of doing the hacks we do today to make Nix stuff play nicely with unwrapped compilers. | 02:18:38 |
| Randy Eckenrode | Like just magically have the libc++ headers of your choice appear as if they were in the sysroot. | 02:19:06 |
| Randy Eckenrode | https://forums.swift.org/t/relationship-if-any-between-import-underlying-module-and-emit-objc-header/61287/4 | 02:21:47 |
 tiferrei | Hi folks, I seem to have corrupted my nix db somehow, I keep getting warning: error: SQLite database '/nix/var/nix/db/db.sqlite' is busy in most operations. What is the best way to sort this out? (Lix, nix-darwin) Thanks! | 10:23:49 |
| 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 |
