| 11 Nov 2025 |
 Wolfgang Walther | fyi: I had already merged https://github.com/NixOS/nixpkgs/pull/460645 into staging-next, assuming the only question would be around the PR currently targeting master. | 12:37:51 |
 hexa | not a problem | 12:39:14 |
| Wolfgang Walther | Is anybody working on fixing that / aware of the problem already? I posted it in the haskell channel as a starter. | 12:48:15 |
 ivy | it looks like very odd error | 12:49:18 |
| ivy | like it’s failing to link its own compiled haskell modules | 12:49:42 |
| ivy | because the symbols its looking for are internal it seems | 12:50:25 |
| ivy | unless someone forgot to expose a c output or c import right | 12:51:00 |
| Wolfgang Walther | That doesn't look like loading haskell modules to me: dlopen(/nix/store/anfq16cq9qki033324cl26w80ngn0ska-nix-2.28.5/lib/libnixexpr.dylib, 0x0005): Symbol not found: | 12:51:59 |
 Sergei Zimmerman (xokdvium) | In reply to @wolfgangwalther:matrix.org
That doesn't look like loading haskell modules to me: dlopen(/nix/store/anfq16cq9qki033324cl26w80ngn0ska-nix-2.28.5/lib/libnixexpr.dylib, 0x0005): Symbol not found: Oh, it’s Darwin libc++ bananza? | 12:53:17 |
 winston | it builds successfully when the grpc dependency is overridden to use the same version of protobuf, i.e. grpc.override { protobuf = protobuf_31; } 🤔 | 12:54:27 |
| winston | protobuf_33 came from there | 12:54:42 |
 vcunat | O | 13:13:38 |
| vcunat | * I'm not aware. | 13:13:44 |
| vcunat | I just mentioned Domen, as the maintainer. (who has business built around cachix, I think) | 13:14:25 |
 Grimmauld (any/all) | why do we make peoples for-profit business stuff channel blockers anyways? If they want it, they need to get their crap together themselves. Unless they pay us, i see no good reason to carry their stuff and make it slow down the rest of the ecosystem | 13:35:24 |
| vcunat | As long as they fix it fast, etc. I don't mind. (and this case seems reasonable to me) | 13:40:19 |
| vcunat | I rather have issues with blockers that have no .meta.maintainers. | 13:40:35 |
| vcunat | Because... what do I do with them? Like, fix them myself always? | 13:40:48 |
| Wolfgang Walther | Well, that for-profit stuff also provides free caching for open source projects. And Nixpkgs CI is using it as well - it even does on darwin runners for the build jobs. | 13:40:54 |
| Wolfgang Walther | So with the state outlined above, what's the conclusion to draw?
PR is ready now. Merge to master or re-target? | 14:44:01 |
| hexa | depends on how quick staging-next lands, because then unstable evals will get cancelled | 14:44:42 |
| hexa | I'd say staging-next is probably the safe choice right now | 14:45:07 |
| Wolfgang Walther | OK, will do. | 14:45:16 |
| hexa | except | 14:45:22 |
| hexa | unstable-small could benefit early 😄 | 14:45:30 |
| hexa | * unstable-small could benefit early if merged to master 😄 | 14:45:34 |
 ElvishJerricco | oh sick I'm in https://git.kernel.org/pub/scm/libs/libcap/libcap.git/commit/?id=d628b3bfe40338d4efff6b0ae50f250a0eb884c7 | 14:47:17 |
| Wolfgang Walther | You tell me! I don't really care about how fast down to the day this is, as long as it doesn't land in the next staging-next cycle ;) | 14:49:03 |
| Grimmauld (any/all) | We also seem to have some regressions in sdl2. https://github.com/NixOS/nixpkgs/pull/460677 fixes those. So far only dwarf-fortress and pygame is affected (and pygame has a fix already). This is an ffmpeg rebuild and impact currently seems low-ish, so i voted to drag this through the next cycle instead of throwing away already-built ffmpeg on -next. Just a heads-up. | 14:51:08 |
| Grimmauld (any/all) | * We also seem to have some regressions in sdl2. https://github.com/NixOS/nixpkgs/pull/460677 fixes those. So far only dwarf-fortress and pygame is affected (and pygame has a fix already). This is an ffmpeg rebuild and impact currently seems low-ish (ffplay still works), so i voted to drag this through the next cycle instead of throwing away already-built ffmpeg on -next. Just a heads-up. | 14:51:29 |
