| 14 May 2026 |
hexa | https://github.com/NixOS/infra/pull/1033 | 15:33:55 |
hexa | at least the git* secrets look clean | 15:45:48 |
hexa | they're not random pats | 15:46:00 |
hexa | https://meet.cccda.de/nix-osin-fra | 15:53:25 |
hexa | We enabled Intelligent Tiering on the cache.nixos.org S3 bucket. The idea is that we'll save money by moving older objects to lower storing tiers "intelligently". We'll check back in a month to evaluate the update cost structure. | 16:47:51 |
hexa | Redacted or Malformed Event | 16:48:01 |
hexa | $ git remote update origin >&2
Fetching origin
From https://github.com/NixOS/nixpkgs
* [new branch] backport-518430-to-release-25.11 -> origin/backport-518430-to-release-25.11
7f1371b3a6db..3054723ea2b1 master -> origin/master
625b14ada4b3..aa8faea6d577 python-updates -> origin/python-updates
fbc1b6e6d1ad..503504ad2d36 release-25.11 -> origin/release-25.11
997d0d965a30..0b1741a3bf36 staging -> origin/staging
e81ce22cc447..2a7e5c6f1f46 staging-next -> origin/staging-next
ec5490bc79b6..2a49f0d42ca9 staging-nixos -> origin/staging-nixos
$ git push origin 54a8ef403e0b27e1eed0298f92e8d3cb863c968a:refs/heads/nixos-25.11-small >&2
fatal: could not read Username for 'https://github.com': No such device or address
Command failed with code (128) errno (0).
| 22:38:38 |
hexa | welp | 22:38:45 |
hexa | https://seashells.io/v/TrBcrEvC | 22:40:30 |
hexa | ok, we're good | 22:41:36 |
| 15 May 2026 |
hexa | in 2 minutes | 10:22:54 |
hexa | gabyx doesn't look like it reproduces | 10:26:44 |
hexa | https://photon.codes/blog/we-found-a-ticking-time-bomb-in-macos-tcp-networking 🤷 | 10:27:29 |
hexa | yeah, no. it does repro. | 10:29:22 |
hexa | rebooting | 10:31:32 |
hexa |  Download excessive swapping fixed | 10:36:26 |
hexa |  Download and disk space recovery too | 10:37:26 |
hexa | the outliers are the ofborg macs, which provide a good comparison | 10:37:36 |
| 16 May 2026 |
VladimÃr ÄŒunát | 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 |
VladimÃr ÄŒunát | 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 |
VladimÃr ÄŒunát | 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 |
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 |