| 9 May 2026 |
 Sergei Zimmerman (xokdvium) | Huh, yeah this definitely got retried | 17:41:31 |
 emily | oh, the modification times are different for the NARs themselves? | 17:41:45 |
| Sergei Zimmerman (xokdvium) | How much different are we talking | 17:42:14 |
| emily | shion:~
❭ curl -i https://cache.nixos.org/nar/1fr8fly29yj9q3mznyqgrsrkrvxhh64pqv6s3smkfpwwcnmskj5m.nar.xz
HTTP/2 200
last-modified: Tue, 18 Nov 2025 01:57:28 GMT
shion:~
❭ curl -i https://cache.nixos.org/nar/135ynbv7smphw9a76x9p2849hfv85gqhmywzb5s9402nqs6fggap.nar.xz
HTTP/2 200
last-modified: Tue, 24 Mar 2026 04:32:06 GMT
| 17:42:19 |
| emily | the most differentest it's possible to be | 17:42:23 |
| emily | the old one is the -doc output | 17:42:40 |
 hexa (signing key rotation when) | We are pushing from DE to us-east-1 ... 150ms latency | 17:42:43 |
| emily | which makes sense | 17:42:45 |
| emily | it won't depend on out | 17:42:54 |
 Winter | yes, i know, hence i blame us-east-1 | 17:43:01 |
| emily | and it probably didn't change since November | 17:43:02 |
| emily | so the .narinfo files are much more canonical for this I'd imagine | 17:43:08 |
| emily | since the NARs themselves are content-addressed | 17:43:22 |
| Sergei Zimmerman (xokdvium) | Yeah, narinfo is the one to look out for then | 17:43:40 |
| emily | basically if it's on the download end then we could boost the substitution timeouts or number of attempts. if it's on the upload end then we could boost the upload timeouts or number of attempts. in both cases it'd be quite nice if we could rule out the partial case altogether of course. but that might be hard (e.g. can we make S3 atomically publish multiple .narinfo files? totally unclear to me) | 17:44:57 |
| emily | oh bingo | 17:46:22 |
| emily | for FFmpeg: | 17:46:23 |
| emily | shion:~
❭ curl -si https://cache.nixos.org/g7gwxb7jinbidq6j0h0fd95rf6zc8937.narinfo | rg last-modified
last-modified: Wed, 25 Mar 2026 22:19:57 GMT
shion:~
❭ for hash in lspxkkbmyvzp36jbvjvy3a3d1j979iqb 6a5nr567sb4a36lisa6gydpp3bfij1vv 60hnmkly9hdsn0ajqmqf2lmd3vnf5w94 gpf5ks0x6x2ih4jjasp53cmx0cmk1bbw hn58l3pvn5iwq87p6ddp9wsw8ai9dl93 j6mqv1jx0pvkz3ww8j3mk65pfg5cc4pi; curl -si https://cache.nixos.org/$hash.narinfo | rg last-modified; end
last-modified: Wed, 25 Mar 2026 22:46:24 GMT
last-modified: Wed, 25 Mar 2026 22:46:24 GMT
last-modified: Wed, 25 Mar 2026 22:46:27 GMT
last-modified: Wed, 25 Mar 2026 22:46:33 GMT
last-modified: Wed, 25 Mar 2026 22:46:17 GMT
last-modified: Wed, 25 Mar 2026 22:46:34 GMT
| 17:46:34 |
| emily | that's surely one build for the data output and one build for the rest. as the log attests to of course | 17:46:59 |
| emily | hexa (signing key rotation when): once a given .narinfo is pushed, can it ever be overwritten? i.e. if the same output gets built again | 17:47:19 |
| emily | or would the second write get dropped? | 17:47:24 |
| Sergei Zimmerman (xokdvium) | In the old queue runner I think it was using the nix’s binary cache store so it wouldn’t get pushed over | 17:47:58 |
