@mrobbetts, thanks for your PR! By analyzing the history of the files in this pull request, we identified @wkennington, @globin and @Krofek to be potential reviewers.

At least one of the hashes seems to be wrong:

output path ‘/nix/store/ibdifh4g0nwp1g4cnjal9qch613dvngd-?id=0d42179e1246f996d334c8bd18deca469fdb1add’ has sha256 hash ‘1d7ki0hmmxpj4qnc0svz0m6rx8s5yj39d1khcx8hjw8hvhqmhz3w’ when ‘0w5n3ypwavq5zlyfxpcyvbaf96g59xkwbw9xwpjyzb7h5j264615’ was expected

I... really? It builds fine on my machine :/

I just re-did a quick nix-prefetch-url on the three patch paths and get the same sha256 results as in the PR. Is there any mechanism (geography?) by which we could get different hashes?

The commit pages have links to a direct patch page (which is what I'm linking to now), but also to .zip and .tar versions. Might those be better?

Ah, fetchpach does some normalization of the patches before hashing the content. It is intended for urls where patches can change slightly. If you provide the hash you got from nix-prefetch-url, the file has already been put into the nix store and due to the fact that fetchpatch (and also fetchurl) is a fixed output derivation, the content for the hash in the nix store is used instead of fetching and normalizing the patch. It fails on my machine because I didn't run nix-prefetch-url before.

Two solutions:

1. Change the hash slightly and rebuild to get an error with the correct hash
2. Use fetchurl instead of fetchpatch (preferred, hashes will stay the same and the patch shouldn't change because it comes from git)

Oh! I had no idea. There are a lot of different fetchers :)

I've pushed the change to use fetchurl (and by adding a temporary a = "blah"; line to the package, verified that it still builds for me).

(just squashed the commits together)

Tested build with openssl & libressl. Thanks! 🍻