| 15 Feb 2026 |
 K900 | https://github.com/zlib-ng/zlib-ng/commit/be819413be8a284b1827437006c0859644d0c367 | 11:13:07 |
| K900 | OK that feels like it could be it | 11:13:11 |
| K900 | Reverting it on 2.3.3 does make things work | 11:16:35 |
| K900 | @Yureka (she/her) any ideas? | 11:17:05 |
 Yureka (she/her) | yeah | 11:17:36 |
| Yureka (she/her) | this is just how yarn works 💩 | 11:17:45 |
| K900 | ...oh wait | 11:18:17 |
| K900 | I just saw your comment | 11:18:23 |
| Yureka (she/her) | the hashes specified in the yarn.lock file (which we the downloads check against) are hashes of zip files | 11:18:25 |
| Yureka (she/her) | not the tars downloaded from the npm registry, but re-packed re-compressed | 11:18:38 |
| K900 | And yarn is what makes the zip fi-- | 11:18:42 |
| K900 | WHAT | 11:18:45 |
| Yureka (she/her) | * | 11:18:46 |
| Yureka (she/her) | yeah | 11:18:47 |
| Yureka (she/her) | in yarn-berry-fetcher we recompress to bit-identically match the hash in the yarn.lock. | 11:19:17 |
| Yureka (she/her) | * | 11:19:23 |
| Yureka (she/her) | So pinning to an old zlib-ng version is sane | 11:19:53 |
| Yureka (she/her) | and there's no way to work around this really | 11:20:07 |
| Yureka (she/her) | (except not using/supporting yarn v2 / berry) | 11:20:14 |
| Yureka (she/her) | (or generating and saving our own hash mappings inside nixpkgs) | 11:20:47 |
| Yureka (she/her) | * | 11:21:00 |
| Yureka (she/her) | * | 11:21:05 |
| K900 | https://github.com/NixOS/nixpkgs/pull/490634 ? | 11:21:13 |
| K900 | And I guess we drop the revert when Yarn updates? | 11:22:35 |
| K900 | ...wait | 11:22:38 |
| K900 | W A I T | 11:22:40 |
| K900 | Oh no | 11:22:44 |
| K900 | OH NO | 11:22:52 |
 ma27 | good to know, I was already wondering why my attempt to reproduce the mismatch (or even one of the hashes) was unsuccessful last night :DDD | 11:24:44 |
| Yureka (she/her) | yarn can never update | 11:25:46 |
