* Andreas Tille <[email protected]> [2026-07-09 19:46]:
Thank you for contacting me. You might like to compare the following logs:https://salsa.debian.org/debian/fairy-stockfish/-/jobs/9891679 - passes and corresponds to 14.0.1.xq-0.2 where reproducible build failed https://salsa.debian.org/debian/fairy-stockfish/-/jobs/9899807 - passes and corresponds to 14.0.1.xq-0.3 where reproducible build failed The only change between the uploaded packages and the Salsa CI tests is that I did some `dch -r`. I pushed with `git push -o ci.skip` the final result to not uselessly stress our hardware. I'm not sure whether the logs of the uploaded 14.0.1.xq-0.2 and 14.0.1.xq-0.3 are kept somewhere or whether you can run diffoscope on the sources from snapshot.d.o. My workflow is to trust Salsa CI and upload if all tests are green and here we have two instances where this strategy did not worked. In general I have to admit that I'm not very educated about reproducibility and can't say much more than to point you to these observations.
Note that reproducibility is not a binary decision. A package can be reproducible in one environment and not in an other one. For fairy-stockfish your commits state that profiled optimization was the cause, thanks for finding that btw. This most likely depends on the exact system the compilation is done on. The salsa-ci runs you linked where all done on the same runner so it makes sense that the profiling resulted in the same optimization. Contrary reproduce.d.n uses different hardware then the Debian buildds. This is why I linked to the release team docs that state that builds should not depend on hardware specifics.
Cheers Jochen
signature.asc
Description: PGP signature
