main branch build failure due to SHA256 failure

[akrherz]

Comment:

I noticed the most recent main branch build failed with

Fetching source from url: https://download.libsodium.org/libsodium/releases/libsodium-1.0.21-stable.tar.gz
│ │ Downloaded file from https://download.libsodium.org/libsodium/releases/libsodium-1.0.21-stable.tar.gz
│ │ × error SHA256 values of downloaded file not matching!
│ │ × error Downloaded = d02af97c64aa878a4ce7b7c711af3555a7ffcceef6d62c05c19d6a7890c51c65, should be 2c7c0083a3d4151634b4237139a6bc216ae3c5cd95ad9c04fc16551021e28a0b
│ │ × error Checksum validation failed!

I am unsure what the truth is as I currently get:

$ wget https://download.libsodium.org/libsodium/releases/libsodium-1.0.21-stable.tar.gz
$ sha256sum libsodium-1.0.21-stable.tar.gz
c0c937ed24cc3cdae094af91e029abebbaeaee74f48f62e0524b39b60a6e4ceb libsodium-1.0.21-stable.tar.gz

[minrk]

Yeah, there's a comment in the recipe explaining this. libsodium updates its 'stable' tarball with patches. It does not have deterministic tagged versions of the stable version. So we have to choose between a URL whose hash will change, or an unversioned URL that won't get bot updates.

I'm not sure what will turn out to be the best!

[akrherz]

Thank you and I sincerely apologize if this wastes your time, but does the github artifact work?

https://github.com/jedisct1/libsodium/releases/download/1.0.21-RELEASE/libsodium-1.0.21.tar.gz

The tags look stable and from what I can tell, the tar.gz payload mostly matches. A diff between the content

$ diff /tmp/github /tmp/libsodium
287a288,290
> /src/libsodium/crypto_core/keccak1600/armsha3
> /src/libsodium/crypto_core/keccak1600/armsha3/keccak1600_armsha3.c
> /src/libsodium/crypto_core/keccak1600/armsha3/keccak1600_armsha3.h
365a369
> /src/libsodium/crypto_pwhash/argon2/argon2-fill-block-wasm32.c
373a378
> /src/libsodium/crypto_pwhash/argon2/blamka-round-wasm32.h

[minrk]

yes, the tags are stable, but the 'stable' tarball is what we actually want, which is the current stable version, carrying patches from the stable branch.

So what we could do is use the 1.0.21 tag and manually carry all the 'stable' patches from the stable branch. That would be deterministic, but we wouldn't ever get automated bugfixes. Maybe that's better than the current sha failiure, which indicates there are bugfixes we don't have yet, but should.

[minrk]

(for example, 1.0.21-release doesn't build on arm)

[akrherz]

Thank you. I don't see your suggested practice used anywhere else in conda-forge? I don't wish to raise a stink, I was looking into dep issues and found libsodium build troubles. btw, libsodium is now in conda-forge/conda-forge-pinning-feedstock/pull/8279 , so to help downstream package deps...

So feel free to ignore my whining :)

[minrk]

No worries at all! I also haven't seen any package like libsodium that publishes a moving-target 'stable' version without tagging versions like this.

[minrk]

#28 solves the same problem in a different way that should work better. It still builds from the stable branch, but instead of tracking the branch in source, which would cause problems, the release tarball is used and a snapshot of the patches in the stable branch is carried in this recipe. That way any update is purely explicit and manual, but the patch list is updated manually, so the download sha won't change and we'll still get bot PRs for updated versions.