| 19 Feb 2026 |
 emily | (it couldn't do it via direct push anyway since we don't allow those) | 17:24:09 |
 toonn | It claims to though. | 17:24:18 |
| toonn | Or at least RFC 39 says it should : ) | 17:24:28 |
| emily | I don't see that in the text. it just says that handles should be updated in general, not that a bot should do it | 17:26:28 |
| toonn | Looks like it was aspirational "Somewhat half-hearted attempt at checking all the handles and IDs, but it doesn't really work right now." | 17:28:23 |
| toonn | For an action to add members to the organization (since that's a requisite for team membership) or a team it'd need a token from an app with the "members: write" permission. I assume the app would be an empty shell to carry the token with the permission. Then the action can do API requests using the token, parse the maintainers list, get nixpkgs-maintainers membership through the API and | 17:33:20 |
| toonn | invite missing maintainers to the org/team using another API request. | 17:33:27 |
| emily | the app for CI already exists and has write access to Nixpkgs (so there would be no further exposure than we already have) | 17:36:47 |
| toonn | I'm not sure why you insist on the Nixpkgs write access. Repository access is not enough, "members: write" is an organization level permission. | 17:39:39 |
| emily | I am explaining that we already have a GitHub App hooked up to our GitHub Actions CI, and it already has write access to Nixpkgs, so the risk that a bot that can manage teams could lead to privilege escalation into Nixpkgs writes isn't any increase in the surface of the risk the app we already have already provides to our automation | 17:40:53 |
| toonn | Least priviledge would suggest having separate apps with strictly necessary permissions but storing multiple tokens in GitHub secrets means actions can access all of the permissions anyway. | 17:41:23 |
| emily | the reason "members: write" is dangerous is because it's equivalent to Nixpkgs commit access, nothing else you can do with it is remotely as risky | 17:41:52 |
| emily | you can offer different secrets to different workflows, but because of ^ I doubt it'd be that worthwhile. anyway, ideally it just uses team maintainership anyway. my point was only that it's not an increase in effective attack surface | 17:42:42 |
| toonn | The equivalence is useful to point out but I never tried to say it's a problem. | 17:45:04 |
| toonn | I'm not sure team maintainership can be passed along through a token. | 17:45:36 |
 gabyx | Is rfc39 running currently? | 17:55:52 |
| toonn | AFAIK it is, new maintainers still get invites. Often they expire but then they come to the org owners room to ask for a new invite. | 17:58:14 |
 hexa | all the time | 18:14:22 |
| hexa | every 30 minutes | 18:14:35 |
| gabyx | it only updates files in nixpkgs right? the maintainers file | 18:17:12 |
| hexa | no, it just issues team invites | 18:17:29 |
| hexa | https://discourse.nixos.org/t/garbage-collecting-cache-nixos-org/74249/10?u=hexa | 18:42:43 |
| hexa | We did the first garbage collection tonight, check the post for details! | 18:43:03 |
 dramforever | i think it's not just me, but the post is completely inscrutable to me | 19:36:03 |
| dramforever | so like, what does it mean? | 19:36:20 |
| dramforever | if i try to get something that hasn't been [???] for 30 days from c.n.o it's ... gone? | 19:36:59 |
 Jeremy Fleischman (jfly) | A bunch of files have been "soft deleted". As far as you as a user of c.n. o is concerned, they're gone. The actual files will be removed from amazon's servers (and we will therefore stop paying for that storage) after 30 days. | 19:46:30 |
| Jeremy Fleischman (jfly) | * | 19:46:39 |
| Jeremy Fleischman (jfly) | (The benefit of doing it this way is we have 30 days to figure out if we did something wrong) | 19:47:16 |
| hexa | # zpool status
pool: zroot
state: DEGRADED
status: One or more devices have been removed.
Sufficient replicas exist for the pool to continue functioning in a
degraded state.
action: Online the device using zpool online' or replace the device with
'zpool replace'.
scan: scrub repaired 0B in 00:03:45 with 0 errors on Sun Feb 1 02:17:51 2026
config:
NAME STATE READ WRITE CKSUM
zroot DEGRADED 0 0 0
mirror-0 DEGRADED 0 0 0
nvme-eui.002538b931005446-part3 ONLINE 0 0 0
nvme-eui.002538b931005449-part3 REMOVED 0 0 0
errors: No known data errors
| 20:12:45 |
