Subject: Re: bug#50015: Rust packages are not reproducible

From: Efraim Flashner <[email-masked]>
Date: Wed, 4 Oct 2023 15:06:45 +0300

On Tue, Oct 03, 2023 at 11:30:15PM -0400, Maxim Cournoyer wrote:
> Hello,
> 
> Ludovic Courtès <[email-masked]> writes:
> 
> > Hello!
> >
> > Efraim Flashner <[email-masked]> 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.

-- 
Efraim Flashner   <[email-masked]>   רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted