rustc: not reproducible

[raboof]

Building this package twice does not produce the bit-by-bit identical result each time, making it harder to detect CI breaches. You can read more about this at https://reproducible-builds.org/ .

Fixing bit-by-bit reproducibility also has additional advantages, such as avoiding hard-to-reproduce bugs, making content-addressed storage more effective and reducing rebuilds in such systems.

Steps To Reproduce

nix-build '<nixpkgs>' -A rustc --check --keep-failed

You can use diffoscope to analyze the differences in the output of the two builds.

To view the build log of the build that produced the artifact in the binary cache:

nix-store --read-log $(nix-instantiate '<nixpkgs>' -A rustc)

Additional context

This unreproducibility seems to be sporadic, but was observed in: https://delroth.net/report-iso_minimal/diff/a0aa598dfe85be4a554c1ed73eb217db8b5f7faeea62b5d8cd5996d8b509550f-80e6fbc77b1d0b38d3dcf1c27ccdea5e1b2906aa2189e24d3a1d24fdfe2406bf.html

Upstream intends to be reproducible: rust-lang/rust#34902

[06kellyjac]

Looks reproducible on arch and guix (not sure if this is consistent or luck)
https://tests.reproducible-builds.org/archlinux/extra/rust/rust-1:1.69.0-2-x86_64.pkg.tar.zst.html
https://data.guix.gnu.org/gnu/store/3xxcmfvyfl5q6rfdmys8vlm18sf899rr-rust-1.60.0
Not on debian
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/rustc.html

[ivan770]

Might be related: rust-lang/rust#112098

[bachp]

I tried to reproduce this with:

nix-build '<nixpkgs>' -A  rustPackages.rustc-unwrapped --check --keep-failed

But I got 3 times the same derivation /nix/store/praqicbhpa137gq0mb9ygg9c7wyripnk-rustc-1.74.0 accros 2 different machines (1 NixOS, 1 Arch).

I used the following commit on nixpkgs 3a360cf which was latest master at the time.

Did I do something wrong or is the reproducibility better with 1.74.0?

[raboof]

I also failed to reproduce this problem, even when it was first reported. Of course this only means the problem is hard to reproduce, not that it does not exist.

So it's hard to say whether it improved with 1.74.0, but perhaps we should close it for now and reopen when we verify the problem still exist?