| 11 Nov 2025 |
winston | protobuf_33 came from there | 12:54:42 |
Vladimír Čunát | O | 13:13:38 |
Vladimír Čunát | * I'm not aware. | 13:13:44 |
Vladimír Čunát | 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 |
Vladimír Čunát | As long as they fix it fast, etc. I don't mind. (and this case seems reasonable to me) | 13:40:19 |
Vladimír Čunát | I rather have issues with blockers that have no .meta.maintainers. | 13:40:35 |
Vladimír Čunát | 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 |
hexa | staging-next | 15:03:43 |
Vladimír Čunát | As tested succeeded already, canceling the eval would cause nixos-unstable to immediately bump to that commit. | 15:29:38 |
Vladimír Čunát | So staging-next stuff is bumped currently and the other jobs are just waiting for opportunity afterwards. | 15:30:47 |
| 12 Nov 2025 |
Grimmauld (any/all) | Uhm. We might have a problem. | 11:06:04 |
Grimmauld (any/all) | Software decoding is broken on librewolf on this staging-next cycle, it lost h264/hevc/aac | 11:06:37 |
Grimmauld (any/all) | i suspect the same applies to firefox, though hydra did not build that yet | 11:06:55 |
Grimmauld (any/all) | I'll poke a ff build on staging-next, but this is a bit of a yikes | 11:07:16 |
Grimmauld (any/all) | Oh wait hydra did actually build 145 on staging-next already, that is convenient | 11:09:50 |
Grimmauld (any/all) | Yep! Applies to firefox too! cc @hex | 11:11:15 |
Grimmauld (any/all) |  Download image.png | 11:11:15 |