Rust packages are not reproducible

> Hello!

>

> Rust packages, which are essentially empty, are not bit-reproducible:

>

> --8<---------------cut here---------------start------------->8---

> $ ./pre-inst-env guix challenge rust-rocket-codegen --substitute-urls='https://ci.guix.gnu.org https://bordeaux.guix.gnu.org'

> /gnu/store/09hlac18bwl1kcnhdig7z1v2j8ly1czw-rust-rocket-codegen-0.4.7 contents differ:

> no local build for '/gnu/store/09hlac18bwl1kcnhdig7z1v2j8ly1czw-rust-rocket-codegen-0.4.7'

> https://ci.guix.gnu.org/nar/lzip/09hlac18bwl1kcnhdig7z1v2j8ly1czw-rust-rocket-codegen-0.4.7: 0j6zf2afvc49jnp7i6z7yvbxm0bmw8yc65hz3lncgvw5lc6z1bc1

> https://bordeaux.guix.gnu.org/nar/lzip/09hlac18bwl1kcnhdig7z1v2j8ly1czw-rust-rocket-codegen-0.4.7: 015kb637b56mqcsg3f6x1qggm2bybiszji2069gb913wxbj6rs7w

> differing file:

> /share/cargo/registry/rocket_codegen-0.4.7.crate

>

> 1 store items were analyzed:

> - 0 (0.0%) were identical

> - 1 (100.0%) differed

> - 0 (0.0%) were inconclusive

> ludo@ribbon ~/src/guix$ ./pre-inst-env guix challenge rust-rocket-codegen

> /gnu/store/09hlac18bwl1kcnhdig7z1v2j8ly1czw-rust-rocket-codegen-0.4.7 contents differ:

> no local build for '/gnu/store/09hlac18bwl1kcnhdig7z1v2j8ly1czw-rust-rocket-codegen-0.4.7'

> https://ci.guix.gnu.org/nar/lzip/09hlac18bwl1kcnhdig7z1v2j8ly1czw-rust-rocket-codegen-0.4.7: 0j6zf2afvc49jnp7i6z7yvbxm0bmw8yc65hz3lncgvw5lc6z1bc1

> https://bordeaux.guix.gnu.org/nar/lzip/09hlac18bwl1kcnhdig7z1v2j8ly1czw-rust-rocket-codegen-0.4.7: 015kb637b56mqcsg3f6x1qggm2bybiszji2069gb913wxbj6rs7w

> differing file:

> /share/cargo/registry/rocket_codegen-0.4.7.crate

>

> 1 store items were analyzed:

> - 0 (0.0%) were identical

> - 1 (100.0%) differed

> - 0 (0.0%) were inconclusive

> $ git log |head -1

> commit 973842acbc2d0dc1ab41738a534d4abda6d9efa7

> --8<---------------cut here---------------end--------------->8---

>

> The diffoscope output suggests it’s about timestamps on one file in the

> .crate archive:

>

> --8<---------------cut here---------------start------------->8---

> ? ? ? ? --- /tmp/guix-directory.ii5wmv/share/cargo/registry/rocket_codegen-0.4.7.crate

> ? ? ? ??? +++ /tmp/guix-directory.uTTKSw/share/cargo/registry/rocket_codegen-0.4.7.crate

> ? ? ? ? ??? rocket_codegen-0.4.7.crate-content

> ? ? ? ? ? ??? file list

> ? ? ? ? ? ? @@ -1,67 +1,67 @@

> ? ? ? ? ? ? --rw-r--r-- 0 0 0 1293 2021-07-27 15:22:18.000000 rocket_codegen-0.4.7/Cargo.toml

> […]

> ? ? ? ? ? ? +-rw-r--r-- 0 0 0 1293 2021-07-27 22:01:49.000000 rocket_codegen-0.4.7/Cargo.toml

> --8<---------------cut here---------------end--------------->8---

>

> Does that ring a bell?

>

> Thanks,

> Ludo’.

>

> PS: I noticed this via

> <http://data.guix.gnu.org/revision/973842acbc2d0dc1ab41738a534d4abda6d9efa7/package-reproducibility>

> with help from Chris. Fixing this could noticeably improve our

> stats. :-)

>

> I tried patching this a couple of ways, but it looks like the best

> option is going to be a 'patch-and-repack phase after 'install. the

> .crate file is really a gzip tarball, and I suspect that each time we

> run 'cargo <something>' the timestamp gets updated.

> Hello!

>

> Efraim Flashner <efraim@flashner.co.il> skribis:

>

>> I tried patching this a couple of ways, but it looks like the best

>> option is going to be a 'patch-and-repack phase after 'install. the

>> .crate file is really a gzip tarball, and I suspect that each time we

>> run 'cargo <something>' the timestamp gets updated.

>

> So that ‘Cargo.toml’ file is not something taken from the build tree?

> In that case we could reset the timestamp before the tarball is

> created. But otherwise yeah, patch’n’repack.

> Hello,

>

> Ludovic Courtès <ludo@gnu.org> writes:

>

> > Hello!

> >

> > Efraim Flashner <efraim@flashner.co.il> skribis:

> >

> >> I tried patching this a couple of ways, but it looks like the best

> >> option is going to be a 'patch-and-repack phase after 'install. the

> >> .crate file is really a gzip tarball, and I suspect that each time we

> >> run 'cargo <something>' the timestamp gets updated.

> >

> > So that ‘Cargo.toml’ file is not something taken from the build tree?

> > In that case we could reset the timestamp before the tarball is

> > created. But otherwise yeah, patch’n’repack.

>

> A better solution would be to have cargo honor SOURCE_DATE_EPOCH,

> perhaps? They'd probably accept such an improvement upstream.

> On Tue, Oct 03, 2023 at 11:30:15PM -0400, Maxim Cournoyer wrote:

>> Hello,

>>

>> Ludovic Courtès <ludo@gnu.org> writes:

>>

>> > Hello!

>> >

>> > Efraim Flashner <efraim@flashner.co.il> skribis:

>> >

>> >> I tried patching this a couple of ways, but it looks like the best

>> >> option is going to be a 'patch-and-repack phase after 'install. the

>> >> .crate file is really a gzip tarball, and I suspect that each time we

>> >> run 'cargo <something>' the timestamp gets updated.

>> >

>> > So that ‘Cargo.toml’ file is not something taken from the build tree?

>> > In that case we could reset the timestamp before the tarball is

>> > created. But otherwise yeah, patch’n’repack.

>>

>> A better solution would be to have cargo honor SOURCE_DATE_EPOCH,

>> perhaps? They'd probably accept such an improvement upstream.

>

> That'd be an interesting idea, having 'cargo package' set the timestamp

> of all the files to SOURCE_DATE_EPOCH. I guess I can look into how

> feasible that would be and if they'd be likely to accept a change like

> that.

>

> I have a local patch which unpacks, resets the timestamp and repacks the

> crate. I'll definitely push it to the rust-team branch before the next

> merge.

>

> With it I introduced an issue where the 'package phase would repack all

> the crates, not just the current one, and ran into our

> underscore-to-dash naming convention causing issues with how I'm reusing

> the filename to work on the crate. I'll fix that, probably by only

> repacking the current crate instead of all crates in the environment.