xxhash: bump to v2.1.2

[geissonator]

There is a known issue in v2.1.1:

cespare/xxhash#54

Fix that issue by bumping to the version with the fix.

This has been fixed in the main branch of etcd via the following:

f0f77fc

But it was a pretty major upgrade so just take the one piece we need for the etcd v3.5 release tag.

The OpenBMC project (https://github.com/openbmc) utilizes yocto/bitbake to build custom Linux images for embedded servers. I've been attempting to get an etcd bitbake recipe into yocto over in openembedded/meta-openembedded#616. When cross compiling etcd for an arm based BMC, we ran into this xxhash issue. Bitbake recipes tend to only point to tagged and released versions of code so that is why I'd like to get this fix backported into the 3.5 branch. For now, I've added this change as a patch to my etcd bitbake PR, but it's always preferred by the openembedded community that the fix be in the source project.

[jmhbnz]

Thanks for raising this @geissonator.

The code change itself looks ok, though it would be helpful if you could give a bit more context on why this should meet the bar to be backported to previous etcd releases, i.e. how does the -buildmode=plugin issue impact etcd specifically?

I had a quick look through some build code and I can't see us using that flag, I could easily be wrong though as still learning, perhaps downstream consumers are doing so.

[geissonator]

The code change itself looks ok, though it would be helpful if you could give a bit more context on why this should meet the bar to be backported to previous etcd releases, i.e. how does the -buildmode=plugin issue impact etcd specifically?

Sure, let me add a few more details to the original message above.

[ahrtr]

Thanks @geissonator for the PR.

The concern is that github.com/cespare/xxhash/v2 is just a indirect dependency in all places. So I think we should bump the direct dependency (github.com/prometheus/client_golang in this example?) firstly, which depends on github.com/cespare/xxhash/v2, then execute ./scripts/fix.sh to automatically update all related indirect dependencies.

Please update this PR per suggestion above. But I am not sure it can pass the pipeline tests. Anyway, please try it out.

[geissonator]

I did what you asked above, and noticed that in the end, my diff looks pretty much like if we just pulled in f0f77fc from the main branch of this repo. My goal with this PR was to just pull the bare minimum in to get xxhash updated and building in my scenario.

I have very minimal knowledge of go and it's modules. I also have very little understanding on where your 3.5 release branch is (i.e. only critical fixes?). If others have not reported this issue, then I'm ok if we just close out this PR so it's here for others if they run into the issue and I'll just carry the patch in our bitbake recipe and wait for 3.6.

I also could change this PR to pull in f0f77fc if you think that would be acceptable to backport to the 3.5 release.

[geissonator]

Looks like we'll just wait for 3.6 and carry the patch in meta-openembedded.