| 15 May 2026 |
 hexa (signing key rotation when) | https://photon.codes/blog/we-found-a-ticking-time-bomb-in-macos-tcp-networking 🤷 | 10:27:29 |
| hexa (signing key rotation when) | yeah, no. it does repro. | 10:29:22 |
| hexa (signing key rotation when) | rebooting | 10:31:32 |
| hexa (signing key rotation when) | 
Download excessive swapping fixed | 10:36:26 |
| hexa (signing key rotation when) | 
Download and disk space recovery too | 10:37:26 |
| hexa (signing key rotation when) | the outliers are the ofborg macs, which provide a good comparison | 10:37:36 |
| 16 May 2026 |
 vcunat | I now canceled the rest of the last nixos-unstable eval in order to make that channel move. Again.
The critical set has passed and all packages get cached via a nixpkgs eval on the exactly same commit. The problem is that those thousands of other jobs would probably take Hydra lots of time to complete (I'd estimate a day or two of work), slowing other important stuff - like the NixOS 26.05 release consequently, probably. And completing them wouldn't bring singificant value, I believe.
| 13:38:33 |
 emily | non-channel-blocking NixOS tests? | 13:41:58 |
| vcunat | Yes, that's the main part which will be missing on that eval. | 13:42:28 |
| emily | IMO, we should consider if building all of those on Hydra really makes sense. there's no notification when they regress. if they're for package maintainers they can be passthru.tests that Hydra ignores | 13:42:57 |
| emily | some of them should probably be blocking, but spending a lot of time building the rest seems questionable? | 13:43:21 |
| vcunat | The current price/value ratio isn't great. I agree with that. | 13:43:57 |
| emily | especially in a world where we'd like to be shipping kernel updates faster... | 13:44:06 |
| vcunat | Maybe the new queue-runner will change that significantly. No idea, maybe I'm just too optimistic.
| 13:44:12 |
| vcunat | * 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 |
| vcunat | The raw CPU time is minority here. I'm quite sure. | 13:51:36 |
| vcunat | 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 |
| vcunat | 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 |
| vcunat | With a good GC strategy that might not be a problem (in future). | 13:53:58 |
| vcunat | * 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 |
| vcunat | 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 |
