| 16 Feb 2026 |
 Picnoir | Right, likely unrelated. It was working fine yesterday. | 17:47:18 |
 Vladimír Čunát |
Right, it's definitely on my side. Sorry for the false alarm.
It might be a problem specific to your region. If a prefix is fast and then it slows down a lot, it might be just filling from S3 to Fastly being slow for some reason (at that location).
| 18:18:41 |
| 17 Feb 2026 |
|  Sergei Zimmerman (xokdvium) joined the room. | 14:45:00 |
| Sergei Zimmerman (xokdvium) | Something ate up all the space on builders? https://hydra.nixos.org/build/321929731/nixlog/1 | 14:46:09 |
 hexa | plausible | 15:33:59 |
| hexa | [https://grafana.nixos.org/d/rYdddlPWk/node-exporter-full?orgId=1&from=now-7d&to=now&timezone=browser&var-datasource=default&var-job=node&var-node=elated-minsky.builder.nixos.org:9100&var-diskdevices=%5Ba-z%5D%2B%7Cnvme%5B0-9%5D%2Bn%5B0-9%5D%2B%7Cmmcblk%5B0-9%5D%2B&refresh=1m&viewPanel=panel-152](disk usage) sometimes jumps and then boom | 15:35:26 |
| hexa | disk usage sometimes jumps and then boom | 15:35:39 |
| hexa | restarted | 15:37:36 |
| Vladimír Čunát | The tmpfs space isn't that huge. | 17:51:54 |
 Julien | Hello hello | 20:27:24 |
| Julien | Would it cause any issue to the infra team if the nixos project took ownership of nixpkgs-update ? | 20:27:55 |
| Julien | If I understand correctly, short term that would involve just transfering the server(s) to our hetzner account | 20:28:44 |
| Julien | Maybe some context here: with potential unstability in the short-term future of nix-community, SC had been contacted to recommend nixpkgs-update migrates to the NixOS org. | 20:39:02 |
| hexa | https://github.com/orgs/nix-community/discussions/2132 is the related discussion at nix-community | 23:16:44 |
| hexa | We certainly need to make sure nix-update keeps working | 23:17:10 |
| hexa | There is no Haskell knowledge in the infra team from what I know. | 23:17:34 |
| hexa | But maintaining another machine should not be a problem | 23:18:28 |
| hexa | We will stop building into nixpkgs/{unstable,staging-next} for x86_64-darwin after 26.05 is branched off. This is in agreement with the relevant people who maintain Darwin support. | 23:43:49 |
 Winter | exciting! | 23:44:43 |
| hexa | We'll still keep building x86_64-darwin for 25.11 and 26.05 until their relevant EOL dates. | 23:45:25 |
| 18 Feb 2026 |
| Julien | hexa (signing key rotation when): I am interpreting your answer as: no short term blockage to take ownership of the deployment. I agree that take ownership of the maintenance of the software is something else. | 10:01:22 |
| Julien | Great thanks! | 10:03:17 |
| hexa | We need someone to update the RFC39 tooling. GitHub has deprecated the API we use to manage team members and the GitHub bindings (hubcaps) are unmaintained since 2020. | 16:22:33 |
| hexa | https://github.com/NixOS/rfc39 | 16:22:41 |
| hexa | also all of the dependencies are stuck in like 2018 | 16:23:58 |
 emily | I have some thoughts on the RFC 39 things I plan to post soon | 16:24:13 |
| hexa | You mean the process? | 16:24:38 |
| emily | it is probably a bad idea to have a long-lived token that powerful lying around. it probably makes sense to do it from within GHA or to move to a more self-service model where any committer can invite people to the maintainers team and merging new maintainers blocks on that | 16:25:16 |
| emily | (I believe that the rfc39 bot could most likely arbitrarily make any GitHub user committer right now?) | 16:26:01 |
| hexa | No idea, I never looked at that token | 16:27:30 |
