!UNVBThoJtlIiVwiDjU:nixos.org

Staging

384 Members
Staging merges | Running staging cycles: https://github.com/NixOS/nixpkgs/pulls?q=is%3Apr+is%3Aopen+head%3Astaging-next+head%3Astaging-next-25.11 | Review Reports: https://malob.github.io/nix-review-tools-reports/125 Servers

You have reached the beginning of time (for this room).


SenderMessageTime
8 May 2026
@jopejoe1:matrix.orgjopejoe1Exception granted ^^07:57:33
@k900:0upti.meK900Thanks07:57:53
@k900:0upti.meK900I'll just send it so it catches this nixos-unstable07:58:05
@vcunat:matrix.orgvcunatNext eval is waiting for https://github.com/NixOS/nixpkgs/pull/51796208:06:41
@k900:0upti.meK900Yeah I know08:09:35
@jopejoe1:matrix.orgjopejoe1Is staging-next too far in for a whole stdenv rebuild, or can we still get this in? 08:16:53
@leona:leona.isleonait will delay staging-next for half a day or so. it's your release cycle so probably you need to know what's best :p08:17:50
@jopejoe1:matrix.orgjopejoe1If not, we would need to change part of our branch-of process, or cause a stdenv rebuild on post branch-of08:17:56
@vcunat:matrix.orgvcunatthe rebuild of darwin stdenv is the more annoying part08:18:13
@vcunat:matrix.orgvcunatAs just building the stdenv takes like 24h.08:18:21
@vcunat:matrix.orgvcunatThere was GDM discussion above, so let me link a PR which hopefully fixes that problem: https://github.com/NixOS/nixpkgs/pull/51777708:22:39
@jopejoe1:matrix.orgjopejoe1Ah, that's annoying. Will do some hacks for this staging-next then, and actually fix it on staging afterward.08:27:21
@jopejoe1:matrix.orgjopejoe1 changed their display name from jopejoe1 (4094@epvpn) to jopejoe1.08:43:17
@emilazy:matrix.orgemily cc @winston:winston.sh 11:13:34
@emilazy:matrix.orgemily(I guess this is still kicking the userdbd can down the road though)11:13:48
@emilazy:matrix.orgemily

@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

Show newer messages


Back to Room ListRoom Version: 6