Change:
"8.12.0".sha256     = "18dc7k0piv6v064zgdadpw6mkkxk7j663hb3svgj5236fihjr0cz"; "8.12.1".sha256     = "1rkcyjjrzcqw9xk93hsq0vvji4f8r5iq0f739mghk60bghkpnb7q"; "8.12.2".sha256     = "18gscfm039pqhq4msq01nraig5dm9ab98bjca94zldf8jvdv0x2n"; <del> "8.13.0".sha256     = "0sjbqmz6qcvnz0hv87xha80qbhvmmyd675wyc5z4rgr34j2l1ymd"; "8.13.1".sha256     = "0xx2ns84mlip9bg2mkahy3pmc5zfcgrjxsviq9yijbzy1r95wf0n"; "8.13.2".sha256     = "1884vbmwmqwn9ngibax6dhnqh4cc02l0s2ajc6jb1xgr0i60whjk"; "8.14.0".sha256     = "04y2z0qyvag66zanfyc3f9agvmzbn4lsr0p1l7ck6yjhqx7vbm17"; "8.14.1".sha256     = "0sx78pgx0qw8v7v2r32zzy3l161zipzq95iacda628girim7psnl"; "8.15.0".sha256     = "sha256:1ma76wfrpfsl72yh10w1ys2a0vi0mdc2jc79kdc8nrmxkhpw1nxx"; "8.15.1".sha256     = "sha256:1dsa04jzkx5pw69pmxn0l55q4w88lg6fvz7clbga0bazzsfnsgd6"; "8.15.2".sha256     = "sha256:0gn8dz69scxnxaq6ycb3x34bjfk9wlp1y2xn8w69kg9fm4b6gkc7"; "8.16+rc1".sha256   = "sha256-dU+E0Mz7MVntbQIeG9I59ANBaHaXXSrjCRdoqZ5TO60="; </del> <ins> "8.13.0".sha256     = "1l2c63vskp8kiyxiyi5rpgbmnv67ysn3y4lybd6nj0li5llibifi"; "8.13.1".sha256     = "15drjcqhsgwqnv02bbidyhk316ypyhz1pxfz2gwsalci9svhkz0v"; "8.13.2".sha256     = "14d4alp35hngvga9m7cfp5d1nl62xdj0nm4811f2jjblk86gxxk4"; "8.14.0".sha256     = "0yxjx9kq9bfpk31dc1c6a0pz0827fz7jmrcwwd4n7dc07yi0arq8"; "8.14.1".sha256     = "0xdqiabgm4lrm6d7lw544zd8xwb1cdcavsxvwwlqq6yid2rl2yli"; "8.15.0".sha256     = "sha256:0q7jl3bn0d1v9cwdkxykw4frccww6wbh1p8hdrfqw489mkxmh5jh"; "8.15.1".sha256     = "sha256:1janvmnk3czimp0j5qmnfwx6509vhpjc2q7lcza1bc6dm6kn8n42"; "8.15.2".sha256     = "sha256:0qibbvzrhsvs6w3zpkhyclndp29jnr6bs9i5skjlpp431jdjjfqd"; "8.16+rc1".sha256   = "sha256-hmZQ6rFIOZJwnAh23nKScJ3Nn+xqDRn5q2Tn82igpYE="; </ins> }; releaseRev = v: "V${v}"; fetched = import ../../../../build-support/coq/meta-fetch/default.nix

Discussion:
Hydra fails to fetch when ran on darwin, blocks even linux builds as is a fixed-output derivation: (linux failure: ) I think it's the following suspicious UTF-8 path: darwin and linux should both be able to fetch the same tarball.
The issue with fetching the tarball on macOS was discovered in , and we believe this is a fetchzip bug on macOS. However, until now, it wasn't an actual issue for users because macOS users would use the fixed-output derivation downloaded on Linux and cached by Hydras (see ). Now, it seems like Hydras caches failures as well (it's a new thing, isn't it? Or we were just lucky previously that the Linux fetching would have happened before the macOS one?) and that because of this, a failure to download the source on Darwin is affecting everyone! I don't really have any solution to propose except: as a workaround is it possible to remove the cached failure and retrigger the build on Linux? fetchzip needs to be fixed to handle UTF-8 file names properly. Even if Coq was modified to not include these file names in its source archive anymore, this wouldn't resolve the issue with already released versions. One last workaround idea to the fetchzip issue would be to make the fixed-output derivation not the direct result of fetching the tarball, but something that would fetch it and fix the divergent paths (e.g., by removing the corresponding tests). But I wouldn't even know how to implement this.
I've seen this in a couple other packages already. It's... not nice but fortunately not a very common problem (perhaps partly due to some linux getting it faster or on a retry).
Do you think works correctly on linux? I find -translation as very odd. Is it broken too?
Unpacking is locale-dependent: LANG=C -(bad) LANG=C.UTF-8 -(ok)
My guess the mismatch happens because macos supports UTF-8 locales as is (and mossibly musl as well?). While does not unless is pulled into unzip. I think we have 2 routes: make work on linux (and break a bunch of fixed-output derivations that contain UTF-8), should be a matter of pulling into 's hook (did not test yet). make ASCII-only everywhere by using in 's . It will start consistently mangle non-ASCII for everyone.

Confirmed failure on as well:
WDYT of proposed fix? Once it's in we can fix and friends.
Thanks a lot for digging into and figuring out the cause of this issue! I find your proposed fix as the best (most principled) solution, even if it will require some work to fix past fix-output derivations.