| 2 Oct 2025 |
 Randy Eckenrode | My Darwin stuff still needs reviewed and merged …. | 11:06:18 |
| Randy Eckenrode | Is upping the minimum and SDK version in that first freeze? | 11:10:11 |
| 3 Oct 2025 |
 Grimmauld (migrated to @grimmauld:m.grimmauld.de) | https://github.com/NixOS/nixpkgs/pull/444599
I am done with libxml2, the failing test in librsvg is NOT a security regression. And we should merge this before the next cycle so it gets into 25.11 | 08:57:35 |
| Grimmauld (migrated to @grimmauld:m.grimmauld.de) | i did all the testing that is reasonable, but i'd still appreciate some more eyes on this. I don't expect it to break super hard, but you never know with libxml | 08:58:21 |
| Grimmauld (migrated to @grimmauld:m.grimmauld.de) | (if noone wants to take a look, i'll send it some time tomorrow so it goes into the next cycle (before breaking changes freeze) | 08:59:32 |
 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 (migrated to @grimmauld:m.grimmauld.de) | okay alright, makes sense | 09:03:17 |
| Grimmauld (migrated to @grimmauld:m.grimmauld.de) | i lost track a little | 09:03:36 |
| Grimmauld (migrated to @grimmauld:m.grimmauld.de) | actually are you sure? | 09:04:23 |
| Grimmauld (migrated to @grimmauld:m.grimmauld.de) | 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 (migrated to @grimmauld:m.grimmauld.de) | ah ty | 09:06:05 |
| Grimmauld (migrated to @grimmauld:m.grimmauld.de) | 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 (migrated to @grimmauld:m.grimmauld.de) | oh yeah no we are aware | 09:08:59 |
| Vladimír Čunát | And nothing else, I hope. | 09:09:04 |
| Grimmauld (migrated to @grimmauld:m.grimmauld.de) | glibc is not my pain to deal with | 09:09:31 |
| Grimmauld (migrated to @grimmauld:m.grimmauld.de) | 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 (migrated to @grimmauld:m.grimmauld.de) | does glibc 2.40 still get patches? | 09:11:38 |
| Grimmauld (migrated to @grimmauld:m.grimmauld.de) | 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 (migrated to @grimmauld:m.grimmauld.de) | 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 |
