| 3 Oct 2025 |
 Vladimír Čunát | libxml2 wouldn't be affected by the tomorrow's deadline. But I do think it best to include it in the next staging-next. | 09:02:08 |
| Vladimír Čunát | 2025-10-18 applies to libxml2. | 09:02:36 |
 Grimmauld (any/all) | okay alright, makes sense | 09:03:17 |
| Grimmauld (any/all) | i lost track a little | 09:03:36 |
| Grimmauld (any/all) | actually are you sure? | 09:04:23 |
| Grimmauld (any/all) | libxml is quite far down, its even a dep into cmake and obviously docbook... How are critical packages defined? | 09:04:51 |
| Vladimír Čunát | Pretty narrow list:
https://nixos.github.io/release-wiki/Release-Critical-Packages.html | 09:05:09 |
| Grimmauld (any/all) | ah ty | 09:06:05 |
| Grimmauld (any/all) | then i guess its not cutting it as close as systemd 258 | 09:06:49 |
| Vladimír Čunát | I just went to remind them: https://github.com/NixOS/nixpkgs/pull/427968#issuecomment-3364889517 | 09:08:23 |
| Vladimír Čunát | There's also glibc open: https://github.com/NixOS/nixpkgs/pull/379542 | 09:08:59 |
| Grimmauld (any/all) | oh yeah no we are aware | 09:08:59 |
| Vladimír Čunát | And nothing else, I hope. | 09:09:04 |
| Grimmauld (any/all) | glibc is not my pain to deal with | 09:09:31 |
| Grimmauld (any/all) | systemd is though, i was stupid enough to add myself to that team XD | 09:09:55 |
 ma27 | going to leave a comment there in a moment, but I think it's sensible to skip it for 25.11 and merge pretty soon after branch-off (or whenever staging is unrestricted again) | 09:10:37 |
| Grimmauld (any/all) | does glibc 2.40 still get patches? | 09:11:38 |
| Grimmauld (any/all) | we can't have it go EOL before 26-06 | 09:11:53 |
| Vladimír Čunát | I'm not aware of this being official/binary. The best I know is to glance at
https://sourceware.org/git/?p=glibc.git;a=heads | 09:15:21 |
| Vladimír Čunát | I do think that at least the worst issues (e.g. significant security problems) will keep getting fixed on the 2.40 branch for at least another year. | 09:18:44 |
| ma27 | upstream patches "down" pretty far. last commit is from 2025-09-19 btw.
fwiw if that would've been a concern, I would've pushed harder (though my main issue is the dlopen()-breakage that can effectively induce ABI problems on both prebuilt stuff and even on source-builds from us).
while I'm confident that we're pretty good on the branch already, I wouldn't have a good feeling pushing this last-minute into new stable. | 09:23:04 |
| Vladimír Čunát | I think the problem with last-minute big updates is that 25.05 will get out of support in a couple months, so you wouldn't have any alternative in case of unexpected incompatibilities. | 09:24:37 |
| Vladimír Čunát | (only the new glibc 2.42 in this case) | 09:25:12 |
| Grimmauld (any/all) | but also, supporting too-different setups gets painful too | 09:25:48 |
| ma27 | I'd argue that this doesn't really apply to glibc though: it's IMHO relatively slow moving, the painful parts around updates are
- ABI incompatibility when wrongly mixing stable/unstable (inherently no way around that, we have to continue teaching people to be careful)
- a lot of breakage around C-API changes (e.g. header changes, removal of deprecated APIs). usually requires patching in affected packages
- hardening changes like the dlopen part
also, considering we skip gcc15-by-default, we're not really ready for C23 anyways. | 09:29:31 |
| ma27 | (not sure if I misread what you were replying to though) | 09:29:40 |
| ma27 | * I'd argue that this doesn't really apply to glibc though: it's IMHO relatively slow moving, the painful parts around updates are
- ABI incompatibility when wrongly mixing stable/unstable (inherently no way around that, we have to continue teaching people to be careful)
- a lot of breakage around C-API changes (e.g. header changes, removal of deprecated APIs). usually requires patching in affected packages
- hardening changes like the dlopen part (EDIT: essentially one or two deep rabbithole(s) for me per upgrade, but that's upgrade-pain not maintenance-pain after that IMHO)
also, considering we skip gcc15-by-default, we're not really ready for C23 anyways. | 09:32:56 |
| Vladimír Čunát | Honestly, I don't know what to do around the current staging-next. Apart from regressing roughly 9k jobs, several different channel blockers remain. (and I'm not aware of anyone working on these) | 09:45:00 |
| Vladimír Čunát | Thousands of regressing jobs might be OK-ish. Though overall it makes me feel like cmake 4 might've been premature to adopt by us (but it's not like I suggest reverting at this point). | 09:46:22 |
| Vladimír Čunát | I mean the pros/cons ratio. | 09:46:39 |
