| 3 Oct 2025 |
 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 |
 K900 | I think everyone who can really look at those is too busy trying to put out the fire | 09:47:47 |
| K900 | I know at least me and @emilazy:matrix.org are | 09:47:57 |
| Vladimír Čunát | Sure, I know. Just trying, maybe someone else than typical contributors will appear 🤷 | 09:49:58 |
| Grimmauld (any/all) | wait how are things broken on x86_64-darwin but not aarch64-darwin? | 09:50:25 |
| Vladimír Čunát | * Sure, I know. I'm just trying, maybe someone else than typical contributors will appear 🤷 | 09:50:21 |
| Grimmauld (any/all) | how do you even build bootstrap tools? stdenv.bootstrapTools builds fine, but that is probably the wrong attr | 09:55:51 |
 Alyssa Ross | From release.nix I I think | 10:01:50 |
| Grimmauld (any/all) | Ah nix-build pkgs/top-level/release.nix --attr stdenvBootstrapTools.x86_64-unknown-linux-gnu seems to do things | 10:03:59 |
| Grimmauld (any/all) | no guarantees, but i might learn something, so i'll give it a casual poke | 10:04:19 |
| Alyssa Ross | Must be bisectable at least | 10:05:11 |
| Alyssa Ross | I just haven't had the time | 10:05:18 |
| Grimmauld (any/all) | i can do the bisect | 10:08:13 |
| Grimmauld (any/all) | that at least isn't hard | 10:08:24 |
