| 15 Feb 2026 |
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 |
K900 | Yep | 11:25:54 |
Yureka (she/her) | except when bumping the lockfile version | 11:25:56 |
K900 | That's the connection I made | 11:26:03 |
dish [Fox/It/She] | gods i hate the need for this patch | 15:39:26 |
emily | violates https://github.com/NixOS/nixpkgs/blob/629c1974f38a329330ada72abacb85b239b495df/pkgs/README.md#overrideattrs-and-overridepythonattrs? | 15:46:51 |
K900 | I mean | 15:47:24 |
K900 | I don't want to uplift this patch into zlib-ng | 15:47:32 |
Alyssa Ross | Why not? | 15:48:53 |
emily | if this fixes a nondeterminism issue then it seems dodgy to just revert it. presumably the yarn hashes are deterministic in practice but in a different way and we should match that? | 15:49:42 |
emily | maybe upstream would even be amenable to that as it would increase compatibility of the fix? | 15:50:00 |
Alyssa Ross | Oh it's a revert | 15:50:56 |
K900 | I think it fixes a determinism issue if you hold the API wrong | 15:51:25 |
emily | that said it seems unlikely that zlib-ng will guarantee bit-reproducible compression outfit forever right | 15:51:30 |
K900 | Which yarn doesn't seem to be doing | 15:51:35 |
K900 | Oh no it won't | 15:51:37 |
K900 | Yarn vendors it | 15:51:39 |
emily | so pinning a version seems unavoidable in the long run | 15:51:40 |
K900 | We may have to do that long term anyway | 15:51:46 |
Alyssa Ross | In which case we should not overrideAttrs and should just make a separate expression for yarn's zlib-ng. | 15:52:00 |
emily | so adding a patch revert that violates the guidelines from the checklist doesn't seem acceptable | 15:52:07 |
K900 | Or we slap upstream with a fish until they concede that this was a terrible idea | 15:52:08 |
dish [Fox/It/She] | well its more an issue of having to regenerate all hashes of every dependency for every yarn package, no? unless im misunderstanding this | 15:52:15 |
K900 | Well we can just have a separate zlib-ng-yarn | 15:52:29 |
K900 | That's pinned to the exact version of whatever the fuck | 15:52:49 |
emily | why do we need to do this hash in the FOD btw? | 15:53:12 |