| 19 Feb 2026 |
 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 |
| hexa | on pluto | 20:12:47 |
| hexa | collected debug logs, deconfigured the faulty disk and rebooted | 20:25:33 |
| hexa | sent a ticket for a replacement disk | 20:29:58 |
| hexa | the machine is back up and the disk was not enumerated | 20:30:17 |
| hexa | we got a new disk and resilvering is in progress | 22:20:08 |
| hexa | will finish in a minute or so | 22:21:43 |
| hexa | and a final reboot to check if everything comes up correctly | 22:29:52 |
| hexa | ok, looks good to me | 22:33:36 |
