| 8 May 2026 |
vcunat | yaya: I think we should at least correct the live schedule table? Because "staging branch-off" effectively happened today and we surely don't have time for "second staging-next" (if the one starting now is considered the first one). | 07:15:56 |
vcunat | I mean, better let people know late than even later. | 07:18:23 |
vcunat | I must admit that in the past couple of weeks I somehow forgot that 26.05 is so close already. | 07:18:58 |
yaya | it happens so fast! 😅 | 07:20:44 |
yaya | I will update the schedule accordingly | 07:20:54 |
K900 | @yaya can have freeze exception https://github.com/NixOS/nixpkgs/pull/513691 | 07:27:42 |
yaya | jopejoe1 (4094@epvpn)could you take a look if you've got some time. I am currently traveling | 07:28:45 |
jopejoe1 | Just realized that we missed merging https://github.com/NixOS/nixpkgs/pull/490979 branch-of is gone be annoying without that. :( | 07:28:52 |
yaya | * @jopejoe1:matrix.orgcould you take a look if you've got some time? I am currently traveling | 07:29:02 |
jopejoe1 | Looking at it currently | 07:32:37 |
jopejoe1 | Exception granted ^^ | 07:57:33 |
K900 | Thanks | 07:57:53 |
K900 | I'll just send it so it catches this nixos-unstable | 07:58:05 |
vcunat | Next eval is waiting for https://github.com/NixOS/nixpkgs/pull/517962 | 08:06:41 |
K900 | Yeah I know | 08:09:35 |
jopejoe1 | Is staging-next too far in for a whole stdenv rebuild, or can we still get this in?
| 08:16:53 |
leona | it will delay staging-next for half a day or so. it's your release cycle so probably you need to know what's best :p | 08:17:50 |
jopejoe1 | If not, we would need to change part of our branch-of process, or cause a stdenv rebuild on post branch-of | 08:17:56 |
vcunat | the rebuild of darwin stdenv is the more annoying part | 08:18:13 |
vcunat | As just building the stdenv takes like 24h. | 08:18:21 |
vcunat | There was GDM discussion above, so let me link a PR which hopefully fixes that problem:
https://github.com/NixOS/nixpkgs/pull/517777 | 08:22:39 |
jopejoe1 | Ah, that's annoying. Will do some hacks for this staging-next then, and actually fix it on staging afterward. | 08:27:21 |
| jopejoe1 changed their display name from jopejoe1 (4094@epvpn) to jopejoe1. | 08:43:17 |
emily | cc @winston:winston.sh | 11:13:34 |
emily | (I guess this is still kicking the userdbd can down the road though) | 11:13:48 |
emily | @vcunat:matrix.org do you think you could ping me a few days in advance of the first post-branch-off staging cycle? I would like to coordinate around x86_64-darwin drop.
I think we should skip building x86_64-darwin starting on the first staging cycle and land the "no longer supported" error with it, because it will be bad UX if things stop being cached before the error (or if trying to override the error "seemingly just works" because we haven't had a world rebuild yet - and then goes kaput on the next staging cycle).
the basic support drop PRs are ~ready but there are some other important PRs on top I need to clean up and push out (e.g. update scripts that will break if x86_64-darwin dies).
| 11:18:25 |
emily | (I'm not sure how close we are to that cycle because what's a release schedule 😅) | 11:18:55 |
emily | relatedly, maybe <half the Darwin will help make this more feasible... | 11:19:32 |
leona | and hopefully at some time in the future more builders 😅😉 | 11:20:11 |
emily | something something queue runner? | 11:20:23 |