| 15 Jun 2026 |
 kuflierl | * I really should have just merged it into master using the security bypass exception | 01:02:22 |
| kuflierl | Also, I just noticed that the github link in the channel description still points to 25.11 | 01:19:21 |
| kuflierl | * Also, I just noticed that the github link in the channel description still points to 25.11. should probably be updated | 01:19:35 |
 Vladimír Čunát | Oh, so we should delay the thoughts on dropping most nixos.tests.* from the jobsets? | 06:28:43 |
| Vladimír Čunát | * Oh, so we should delay the thoughts on dropping most nixos.tests.* from the jobsets after we try with the new queue runner? | 06:28:56 |
| Vladimír Čunát | We're getting thousands of home-assistant rebuilds on nixpkgs master on daily basis now:
https://hydra.nixos.org/job/nixpkgs/unstable/home-assistant.x86_64-linux | 06:36:42 |
| Vladimír Čunát | That blocked eval, I believe:
https://github.com/NixOS/nixpkgs/pull/531909 | 07:47:31 |
| Vladimír Čunát | We do ship the latest kernel in the ISO. | 07:48:00 |
 K900 | Ughhhhhhhh | 07:48:04 |
| K900 | Yeah probably | 07:48:07 |
| K900 | We might want to demote bcachefs to LTS kernels only tbh | 07:48:30 |
| K900 | Like we already do with zfs | 07:48:31 |
 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 |
