| 17 Feb 2026 |
 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 |
| hexa | But given that no bot account has the maintainer role on the maintainers team, probably | 16:27:54 |
| hexa | hm, it's an app apparently | 16:30:31 |
| 19 Feb 2026 |
 toonn | This comment does claim that the app only needs `Members: Read and Write` permissions, https://github.com/NixOS/rfc39/blob/master/src/main.rs#L42-L46. | 14:08:00 |
| toonn | emily: I think that at least addresses your concern about permissions? | 14:08:29 |
| emily | I'm pretty sure "Members: Write" is the permission that lets you make anyone a Nixpkgs committer. | 14:11:04 |
| toonn | Ah, it's org-level, not team-level permissions? That makes sense, I guess. Wouldn't GHA require the same privilege level though? | 14:14:54 |
| emily | yeah, but all changes to our GHA machinery go through our normal review, and if tokens leak unexpectedly from GHA then GitHub has bigger problems | 14:39:40 |
| hexa | I' | 14:45:05 |
| hexa | * I'm super fine with giving it up | 14:45:09 |
