| 22 Jun 2026 |
emily | (and my vague feeling is that a lot of the test builds are probably sufficiently low-utility that we'd need them to get very cheap for them to be a particularly effective way of spending that slack, though I'm not super confident about that – but I feel like "which of the n perennial 'things we could do if we had more Hydra capacity' should we prioritize?" is a good problem to have rather than just staying right inside the bounds of what circumstances compel) | 16:33:11 |
emily | e.g. if merging the jobsets + reducing tests lets us dial up nixos-unstable eval bump frequency to be more like nixpkgs-unstable that feels like a win that probably dwarfs the value most of the non-blocker tests provide | 16:34:54 |
Vladimír Čunát | There's still ~12k darwin rebuilds per platform, but that's not so much a difference. | 17:41:36 |
emily | yeah. but saves me having to disentangle a few mass rebuild commits, and still avoids having to build another x86_64-darwin stdenv | 17:46:43 |
emily | rebased the core PRs I already had up, and I'll work on getting the immediate "fix stuff that would regress from the drop" things out. Randy Eckenrode: do you want to look over these?
- https://github.com/NixOS/nixpkgs/pull/492105
- https://github.com/NixOS/nixpkgs/pull/492160
- https://github.com/NixOS/nixpkgs/pull/493096
- https://github.com/NixOS/nixpkgs/pull/492189
the first one can land any time, the others will need a bit of a dance to go in sequence to not break CI along the way so I'll self-merge those but want to give a chance to look them over
| 18:04:32 |
emily | vcunat: (I take it current staging will become the cycle after https://github.com/NixOS/nixpkgs/pull/534248?) | 18:05:56 |
Vladimír Čunát | Yes. | 18:12:17 |
Vladimír Čunát | Unless something unexpected happens. | 18:12:38 |
Alyssa Ross | This idea makes sense to me. | 18:13:06 |
emily | should we merge this into staging first then? I guess it'll ride the train back from -next regardless | 18:18:32 |
emily | I guess it'd need double cherry-picking if we did that, so never mind :) | 18:20:59 |
Vladimír Čunát | Sound good in principle | 18:21:14 |
emily | (by "this" I meant the -next, but I'm just going to rebase stuff on the merge of current staging + that proposed -next to avoid any conflicts) | 18:22:18 |
Randy Eckenrode | Left an approval on the first, second is merged already, asked questions on the third, and added yet another approval to the fourth. | 23:51:53 |
Randy Eckenrode | So, to understand, the next staging-next is just staging-next-26.05 but for unstable? The current staging branch won’t get built until the next cycle? | 23:52:36 |
emily | replied :) | 23:55:01 |
emily | AIUI yes except it's not actually staging-next yet. | 23:55:10 |
emily | (but "next cycle" might be in ~a week, luck permitting?) | 23:55:19 |
| 23 Jun 2026 |
Randy Eckenrode | I wish we could make aarch64-darwin tier 2. It feels bad deleting x86_64-darwin from tier 2 while leaving it as tier 3. | 00:35:04 |
Randy Eckenrode | I know tiers are kind of not really a thing anymore, but it’d still be nice. | 00:36:56 |
emily | https://nixos.org/manual/nixpkgs/unstable/#sec-platform-breakdown says tier 2 | 00:46:12 |
emily | fwiw | 00:46:45 |
emily | technically flake-systems.nix doesn't list aarch64-darwin in any tier at all | 00:47:25 |
emily | and i686-linux is definitely not tier 3 | 00:47:33 |
emily | but… not going to mess with that right now :) | 00:47:40 |
emily | guess I'll do the merge dance now :) should be able to have the follow-up fixes ready before staging becomes the next cycle | 00:48:50 |
emily | vcunat: should be able to remove the platforms override from the staging jobset now | 02:20:35 |
Gaétan Lepage | Thanks emily for handling this! | 08:04:16 |
Vladimír Čunát | This hopefully quite quick new staging-next: https://github.com/NixOS/nixpkgs/pull/534570 | 12:30:18 |
hexa | 60k jobs | 15:09:47 |