| 15 Jun 2026 |
 ElvishJerricco | We already removed the kernelPackages setting from the module since we know it'll be fine on LTS going forward. The un-fine-ness was why it wasn't in the LTS specialisation of the ISO originally. So yea it would make sense to give it the ZFS treatment and have it in the LTS specialisation but not the latest kernel one for the ISO | 14:08:55 |
| ElvishJerricco | well, other than the fact that kent has said he intends to have bcachefs releases for new kernels before new kernels release, so it should be fine on the latest kernel specialisation as long as nixpkgs updates bcachefs before the kernel | 14:10:34 |
 hexa | Most of these are version bumps of home-assistant itself, that cause package tests to be rebuilt. I hope new queue-runner will cause some relief here. | 17:00:49 |
 Grimmauld (any/all) | Also: All the failing jobs we have, those are rebuilt each time hydra loops over, right? So marking more shit as broken means less load on hydra? Or am i misunderstanding something? | 17:02:30 |
 whispers [& it/fae] | no, hydra caches build failures | 17:03:35 |
| whispers [& it/fae] | * | 17:03:58 |
 K900 | Sometimes | 17:04:18 |
| K900 | But it does mean rebuilds every staging cycle | 17:04:31 |
| hexa | they get rebuilt when we restart failed builds though | 17:04:39 |
| hexa | so marking broken things as broken does help hydra | 17:04:46 |
| K900 | But also how many things can you mark broken out of 150k | 17:04:46 |
| K900 | To make a relevant difference | 17:04:53 |
| hexa | start at glibc and then go down the stdenv | 17:05:01 |
| hexa | you don't need many that way | 17:05:05 |
| Grimmauld (any/all) | Assuming all packages are roughly equal cost for hydra, we have 2% broken packages, and hydra takes a day for an eval, that'd be half an hour speedup marking everything broken that is broken. These assumptions are certainly not at all accurate, but the order of magnitude should be around there, in the minutes to an hour of gain per hydra eval | 17:10:37 |
| K900 | Staging takes way more than a day | 17:11:11 |
| K900 | Just the eval takes like two hours | 17:11:18 |
| K900 | We have like 4-5k broken jobs usually | 17:12:18 |
| K900 | So we're saving 1% of time maybe | 17:12:31 |
| hexa | still, getting the long term failures disabled would be good | 17:20:41 |
| hexa | but would need some scraping to find them | 17:20:50 |
| hexa | or db sleuthing | 17:20:52 |
 Nick | Probably then a tracking issue once the list is out to go through them... Slightly new to keeping an eye on Hydra page for my stuff but isn't there an API query for historical build data? | 19:01:25 |
| 16 Jun 2026 |
 Vladimír Čunát | Just a few days and nixos/unstable jobset got roughly 30k rebuilds... | 06:50:48 |
| Vladimír Čunát | (out of ~160k) | 06:51:12 |
| hexa | 7580 of which are nixos tests, where half are duplicated with the allDrivers attribute | 11:07:59 |
| hexa | https://github.com/NixOS/nixpkgs/pull/176099 | 11:09:21 |
| hexa | do we really need to build that? | 11:09:58 |
| hexa | Robert Hensing (roberth)? | 11:10:10 |
 Robert Hensing (roberth) | the allDrivers set has all the configs, testScript, etc, but is already part of nixosTests proper. They don't add extra build work, but may add extra eval work given that multiple batches of evaluation are needed for the tests, and it seems unlikely that the allDrivers vs tests run in the same batch (unless someone has added a workaround specifically for this - I assume the batches are cut lexicographically) | 11:13:41 |
