| 24 May 2026 |
 hexa | Can we commit on what the next staging cycle will be? | 18:03:18 |
| hexa | 25.11 because it is the oldest at this point? | 18:03:38 |
| hexa | Unstable? In which case we need the x86-64-darwin drop changes | 18:04:12 |
| hexa | Time until 25.11 eol is just above 5 weeks | 18:08:22 |
 Vladimír Čunát | I don't know what to choose. | 18:08:29 |
| hexa | Best case it gets two more staging cycles | 18:08:42 |
| hexa | 4 cycles at just under 10 days | 18:09:48 |
| Vladimír Čunát | Theoretically we could do 26.05 and then merge the same set of commits to master. They were almost all cherry-picks. | 18:10:14 |
 emily | 25.11 seems like a good idea given all the security stuff recently? | 18:10:17 |
| hexa | 3 cycles at 12.3 days | 18:10:19 |
| emily | and also because it's slightly awkward timing for me wrt x86_64-darwin :P (though I can make it work whenever it happens still) | 18:10:47 |
| emily | how long ago was the last 25.11 cycle? | 18:10:54 |
| emily | I'd sort of guess that if we do 25.11 it's the last cycle it'll get. conversely I'd guess that if we don't do 25.11 its last cycle will land security updates post-EOL. just a hunch though | 18:11:26 |
| hexa | May 5th 😯 | 18:11:38 |
| emily | so about 2,000 CVEs ago | 18:11:51 |
| hexa | Yeah +/- 1500 | 18:12:13 |
| Vladimír Čunát | In reply to @vcunat:matrix.org
Theoretically we could do 26.05 and then merge the same set of commits to master. They were almost all cherry-picks. Or this after 25.11 cycle. | 18:20:26 |
| emily | that would mean including x86_64-darwin for that cycle I suppose? | 18:20:56 |
| Vladimír Čunát | I guess. | 18:21:45 |
| emily | well, can't skip it on 26.05 😅 | 18:22:35 |
| emily | we seem to end up reliably doing those hybrid cycles lately; | 18:22:49 |
| emily | * we seem to end up reliably doing those hybrid cycles lately… | 18:22:51 |
| Vladimír Čunát | I took a liking to the associated savings. | 18:25:57 |
 matthewcroughan | ┃ error: build of resolved derivation '/nix/store/afvbgibsc9hqg244db0g4nh1av0sjnmk-914871b20a901e3e1e981c92bc42b1c93b7ab81b.patch.drv' failed
┃ error: hash mismatch in fixed-output derivation '/nix/store/afvbgibsc9hqg244db0g4nh1av0sjnmk-914871b20a901e3e1e981c92bc42b1c93b7ab81b.patch.drv':
┃ specified: sha256-UsLE14P50Ell0xo3PESk5tIHH2HLalsaWiEubO9KdPE=
┃ got: sha256-6hqu5npSUN8I7XLZRiCl+b60Sweb1n2ZZz5LroIzkvA=
| 22:44:31 |
| matthewcroughan | ANyone been getting this? | 22:44:33 |
| matthewcroughan | for a patch to fuse | 22:44:46 |
| matthewcroughan | * Anyone been getting this? | 22:44:49 |
 Ryan Burns | Confirmed, looks like this broke in https://github.com/NixOS/nixpkgs/pull/516786, rebasing onto master (and applying the patch unconditionally, since it's gated on aarch64) reveals the same mismatch for me. I think that patch should be unconditional anyway, would avoid this issue for future bumps that aren't tested on aarch64. | 23:00:21 |
 ElvishJerricco | I guess that patch got struck by the full_index thing? | 23:25:29 |
| ElvishJerricco | or is that fetchpatch2? | 23:25:41 |
