Comment 9 for bug 2003201

Confirmed this is due to changes in the output of libzstd1. The current variant of libzstd1 in lunar (1.5.4) produces entirely different output in the diffoscope diff of the generated deb. Compare the diffoscope output in [1] to [2]. I reproduced these differences in an otherwise up to date lunar VM by downgrading the libzstd1 package from 1.5.4+dfsg2-4 to 1.5.2+dfsg-1.

[1]: https://autopkgtest.ubuntu.com/results/autopkgtest-lunar/lunar/arm64/s/sbuild/20230204_040321_7a8f5@/log.gz

[2]: https://autopkgtest.ubuntu.com/results/autopkgtest-lunar/lunar/arm64/s/sbuild/20230320_055722_83889@/log.gz

I theorize, that the last successful version was 1.4.8+dfsg-3build1 (last seen in kinetic and current in jammy). However I can't currently test with that as dpkg has depended on libzstd1 >= 1.5.2 for a while now.

Anyway, the crux of the problem is that the unshare test is checking for binary reproducibility of output, and zstd doesn't guarantee that (does any compressor guarantee that, or have we just got lucky so far?). Solutions:

1) Drop the diffoscope part of the unshare test

2) Update the diffoscope part of the unshare test to the "current zstd output" (and presumably keep doing this with each new zstd version)

3) Find some way of beating zstd into producing the same output as before (if that's possible)

The first is easiest and quickest but nasty, the second still fairly quick'n'easy but potentially painful in future (and seems somewhat against the spirit of the test anyway). The third is potentially impossible and if possible, potentially hard.

Incidentally, all of the above presumably apply to Debian too now zstd deb support has made its way upstream.

Comments?