| 27 Mar 2026 |
 vcunat | And we would be breaking people who referenced the removed jobsets on Hydra. (e.g. with the recent renaming, Hydra is still providing http redirects, but we wouldn't get that here) | 11:54:24 |
| vcunat | * And we would be breaking people who referenced the removed/stopped jobsets on Hydra. (e.g. with the recent renaming, Hydra is still providing http redirects, but we wouldn't get that here) | 11:54:40 |
 emily | I was thinking just leaving that as-is. it doesn't seem to be a big problem for nixpkgs-unstable(?)
(Darwin stuff blocking the bump because of failures can be)
| 11:55:30 |
| emily | or I'd at least hope it won't be a problem by 26.11 | 11:55:49 |
| emily | if I have to start telling people an even more complicated story about when the channel bumps I'll go nuts :) | 11:56:44 |
| vcunat | I'm not fond of making nixos-unstable dependent on darwin builds. | 11:56:45 |
| emily | regardless of success/fail blocking, because of the infra capacity problems? I know there's been issues with -next recently, has it held back nixpkgs-unstable bumps though? | 11:58:04 |
| vcunat | I could certainly come with some scenarios, e.g. some security rebuilds do get way more expensive for darwin than linux. | 11:58:06 |
| emily | those should be conditionalized anyway right? | 11:58:35 |
| emily | because nixpkgs-unstable is used on Linux too | 11:58:42 |
| emily | e.g. by all users on other distros by default | 11:58:50 |
| emily | so status quo doesn't change there | 11:59:06 |
| vcunat | Flakes also default to nixpkgs-unstable, IIRC. | 11:59:17 |
| emily | yeah, and the channel in the installers I believe | 11:59:36 |
| vcunat | But users can easily override this. Verification of blocker NixOS tests does have benefits. | 12:09:30 |
| emily | right. well I was thinking nixpkgs-unstable should probably just gate on those too | 12:19:58 |
| emily | I don't see much reason not to since they get fixed reasonably promptly for obvious reasons | 12:20:20 |
| vcunat | So no difference between nixos-unstable and nixpkgs-unstable then? | 12:25:27 |
| vcunat | (same for the stable pair which is differently split, confusingly) | 12:25:57 |
| vcunat | There's some risk from this jobset getting significantly bigger than either. As it is now, performing an eval can stall progress of builds for about 20 minutes, apparently because of dependencies between postgresql transactions. (doing an eval as one huge transaction is tough) | 12:32:30 |
| vcunat | But maybe the reduction in overall job count (summed together over jobsets) would even help this aspect. | 12:33:21 |
| vcunat | * There's some risk from the merged jobset getting significantly bigger than either. As it is now, performing an eval can stall progress of builds for about 20 minutes, apparently because of dependencies between postgresql transactions. (doing an eval as one huge transaction is tough) | 12:33:43 |
| emily | well, latter would block on Darwin as now | 12:35:12 |
| emily | but right, no difference for Linux specifically | 12:35:26 |
| vcunat | Looks good: https://hydra.nixos.org/build/325215479#tabs-constituents | 13:15:41 |
 Mic92 | hexa (signing key rotation when): so amaan got some s390x builder vm from the IBM opensource program that he wants to play with. I suggested that this would be a good workload for staging hydra. Basically he could figure out how much he could build and we get some real-world testing at the same time. Thoughts? | 22:09:19 |
|  amaan joined the room. | 22:12:17 |
 hexa (signing key rotation when) | I'm not opposed to playing with s390x | 23:30:37 |
| hexa (signing key rotation when) | the real world use is still questionable | 23:30:47 |
| hexa (signing key rotation when) | and without a community builder there is little chance for it to gain enough traction for anyone to test fixes | 23:31:36 |
