| 3 Oct 2025 |
 vcunat | 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 |
| vcunat | 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 |
| vcunat | 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 |
| vcunat | (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 |
| vcunat | 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 |
| vcunat | 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 |
| vcunat | 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 |
| vcunat | 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 |
| vcunat | * 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 |
| Grimmauld (any/all) | just takes a while because waiting for gcc compiles | 10:08:49 |
| Grimmauld (any/all) | so uh, i just got a gcc build fail on the way to bootstrap tools... | 10:27:26 |
| Grimmauld (any/all) | > /nix/store/mr6bjhlhd966kl6f2wmggsan6mbs5bcj-bootstrap-stage3-stdenv-linux/setup: line 1801: pop_var_context: head of shell_variables not a function context
> /nix/store/mr6bjhlhd966kl6f2wmggsan6mbs5bcj-bootstrap-stage3-stdenv-linux/setup: line 1: pop_var_context: head of shell_variables not a function context
whatever this is
| 10:28:05 |
| K900 | That's a stupid stdenv bug, the real error should be above that | 10:30:09 |
| Grimmauld (any/all) | There is also /nix/store/mr6bjhlhd966kl6f2wmggsan6mbs5bcj-bootstrap-stage3-stdenv-linux/setup: line 297: /nix/store/7xs7kwm3010k16fmgfpypwiy0wxx03fn-binutils-patchelfed-ld-wrapper-2.44/nix-support/libc-ldflags-before: No such file or directory which might be concerning | 10:31:58 |
