| 24 May 2026 |
 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 |
 r-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 |
| ElvishJerricco | (that's fetchpatch2) | 23:28:09 |
| ElvishJerricco | so I don't understand how they did update the hash but got the wrong one | 23:28:53 |
| r-burns | Ah, I think that is ordinary fetchpatch, so maybe it is just a full_index thing. | 23:30:57 |
| ElvishJerricco | no like fetchpatch2 is the one where using full_index matters | 23:32:26 |
| ElvishJerricco | fetchpatch removes that stuff | 23:32:38 |
