| 30 Jun 2026 |
 Arian | In reply to @arianvp:matrix.org
I found a corrupt gnugrep nar I think?
https://cache.nixos.org/srk76h64a1ja4z7njh5lxcds7m9hnc7y.narinfo
Says file size 248729 bytes
But when i download i get 248412 bytes
The FileHash also doesn't match
Interestingly the NarHash does.. Race condition of uploading the nar + undeterministic compression? | 07:56:04 |
 Vladimír Čunát | Do you still experience it? I now did nix build /nix/store/srk76h64a1ja4z7njh5lxcds7m9hnc7y-gnugrep-3.12 and it passed. | 07:59:00 |
| Vladimír Čunát | * Do you still experience it? I now did nix build /nix/store/srk76h64a1ja4z7njh5lxcds7m9hnc7y-gnugrep-3.12 (the path shown in that .narinfo) and it passed. | 07:59:21 |
 dramforever | possibly had the positive narinfo cache for the old one? | 07:59:40 |
| Arian | So it fetches just fine in nix.
But the FileSize and FileHash in the narinfo are wrong.
I guess nix ignores those fields? | 08:03:50 |
| Arian | But if they're ignored why do we have them. | 08:03:58 |
| Arian | * But if they're ignored (and wrong) why do we have them. | 08:04:16 |
| dramforever | they aren't normally wrong... | 08:05:46 |
| dramforever | oh huh | 08:07:43 |
| dramforever | it really is still wrong | 08:07:47 |
| Vladimír Čunát | zstd should be deterministic, though:
https://github.com/facebook/zstd/issues/2949#issuecomment-999750191 | 08:18:06 |
 Mic92 | vcunat: I think the lengh is not | 08:18:31 |
| Mic92 | * vcunat: I think the length is not | 08:18:38 |
| Mic92 | this is an artifact before I introduced: https://github.com/NixOS/hydra/commit/4e36de08453e62cb850a5c5f70d75afcea711cda | 08:19:34 |
| Mic92 | Fixing that requires going through a week or so worth of narinfo... | 08:19:57 |
| Vladimír Čunát | If fetching by nix doesn't get broken, it's not terrible maybe. Also if no FODs got affected (?), all these NARs would get "outdated" within a few weeks. | 08:23:15 |
| Arian | I wonder if we can fix by constructing by just setting the Content-Encoding header on the nar object as opposed of storing a Compression field in the narinfo file | 08:24:16 |
| Mic92 | Yeah. that's also why I didn't priotize fixing it yet. I rather want to spent the time on getting my hydra commits back into master and than look into gc | 08:24:18 |
| Arian | This makes the whole thing atomic. | 08:24:22 |
| Arian | * I wonder if we can fix by construction by just setting the Content-Encoding header on the nar object as opposed of storing a Compression field in the narinfo file | 08:24:37 |
| Mic92 | * Yeah. that's also why I didn't priotize fixing it yet. I rather want to spent the time on getting my hydra commits back into master and than look into cache.nixos.org gc | 08:25:25 |
| Mic92 | Nix should be able to consume it, maybe some other tooling would need an update to look at Content-Encoding, also the same tooling already needs to do this in other places anyway. | 08:25:49 |
| Arian | Both nix and lix definitely support it. As snix's nar-bridge uses content-encoding and I haven't had any issues pointing lix at it recently | 08:27:17 |
| Arian | (there were some at the beginning) | 08:27:26 |
| Vladimír Čunát | Is perhaps HTTP 416 related?
https://github.com/NixOS/infra/issues/1106 | 08:27:45 |
| Mic92 | One wrinkle is that this idempotent header only exists on AWS, so for general s3 support it would be nice to switch this. | 08:27:50 |
| Mic92 | it's an .xz url, so maybe some older issue? | 08:28:33 |
| Vladimír Čunát | Oh right 🤦 | 08:28:53 |
| Arian | In reply to @joerg:thalheim.io
One wrinkle is that this idempotent header only exists on AWS, so for general s3 support it would be nice to switch this. Im not understanding what you mean by this | 08:33:20 |
| Mic92 | Arian: I haven't seen other s3 implementations that also support 'If-None-Match: *' header | 08:34:18 |
