| 16 May 2026 |
 emily | especially in a world where we'd like to be shipping kernel updates faster... | 13:44:06 |
 Vladimír Čunát | Maybe the new queue-runner will change that significantly. No idea, maybe I'm just too optimistic.
| 13:44:12 |
| Vladimír Čunát | * Maybe the new queue-runner will change the price significantly. No idea, maybe I'm just too optimistic.
| 13:44:20 |
| emily | I'd guess it's a lot of raw CPU time for the actual tests too? 🤔 | 13:46:31 |
| emily | I'll try to at least work on the "no separate NixOS and Nixpkgs jobset" thing after branch off, which might alleviate the "duplicate scheduling or build work between the two" problem... maybe we can cut out non-blocking tests for now at the same time | 13:48:08 |
| Vladimír Čunát | The raw CPU time is minority here. I'm quite sure. | 13:51:36 |
| Vladimír Čunát | It's mainly building loads of tiny .drv (for /etc), loads of cheap huge .drv (disk-image whatever), etc. Moving them there and back, compressing, to S3. Lots of delays which you will not notice when running a NixOS test locally. | 13:53:02 |
| emily | right | 13:53:20 |
| Vladimír Čunát | At least that's what it looks like from my years-long observation of what Hydra is doing. | 13:53:23 |
| emily | ...the disk images probably aren't great for cache growth either though :) | 13:53:36 |
| Vladimír Čunát | With a good GC strategy that might not be a problem (in future). | 13:53:58 |
| Vladimír Čunát | * With a good GC strategy for S3 that might not be a problem (in future). | 13:54:09 |
| emily | yeah.... mostly I'm just sceptical that non-blocking tests get much consumption from Hydra anyway. package bumps, spot-checking if functionality is working, people including them in their configs for bonus assurance - Hydra building them is pretty extraneous | 13:57:01 |
| emily | the main case I can imagine them providing value is notification when they break. but uh, haven't seen much evidence that any maintainer is proactively checking when their stuff breaks, so probably a bigger deal to establish that norm for packages first. and anyone going to the trouble of setting up a notification system can probably spare the cycles to build the test | 13:58:16 |
| Vladimír Čunát | A nice way to follow failures for particular jobs (packages/tests) would be a useful improvement, though that's tangential here. | 14:02:06 |
| emily | yeah, I agree. I'm very much in favour of better notifications and delegating work to maintainers | 14:04:50 |
| emily | but I'm guessing that even adding "every test anyone active is interested in following" back in would be relatively little 😅 | 14:05:12 |
| emily | I mean, it would be really nice if we could cut staging-nixos out of the process again. | 14:06:00 |
| Vladimír Čunát | Oh right, I didn't realize that implication. | 14:24:31 |
| 17 May 2026 |
 Mic92 | we can move those here: https://github.com/NixOS/images | 06:05:12 |
| Mic92 | and not have them build at all by hydra | 06:05:24 |
| Mic92 | in the nix repo we already have some oidc set up to authenticate against s3 | 06:05:42 |
| Mic92 | * in the nix repo we already have some oidc set up to authenticate against s3 without having any secrets in the repo. | 06:06:21 |
| Vladimír Čunát | These are specific images for individual VM tests, I think, not the ISO and stuff that you think. | 06:37:12 |
|  Tomas Rivera joined the room. | 12:30:47 |
 sinan | cache.nixos.org down ?
this is from hetzner, https://termbin.com/6kho | 17:22:09 |
| sinan |
curl -I -6 https://cache.nixos.org/
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
curl: (7) Failed to connect to cache.nixos.org port 443 after 0 ms: Could not connect to server
Exit: 0
| 17:22:37 |
 Bart | bart@bart-pc ~ $ curl -I -6 https://cache.nixos.org/
HTTP/2 200
| 17:22:46 |
 hexa | hetzner where | 17:23:11 |
| hexa | and in general, no. the cache is never down. | 17:23:43 |
