Bug#1035704: proj: reproducible-builds: timezone-dependent timestamps in .gsb/.gtx files

Vagrant Cascadian vagrant at reproducible-builds.org
Mon May 8 21:43:31 BST 2023


On 2023-05-08, Sebastiaan Couwenberg wrote:
> On 5/8/23 02:07, Vagrant Cascadian wrote:
>> The attached patch fixes this by not touching these files during the
>> build process.
>
>  From shar(1):
>
> "
>    -m, --no-timestamp
>           do not restore modification times.
>
>           Avoid generating 'touch' commands to restore the file
>           modification dates when unpacking files from the archive.
>
>           When file modification times are not preserved, project build
>           programs like "make" will see built files older than the files
>           they get built from.  This is why, when this option is not
>           used, a special effort is made to restore timestamps.
> "
>
> That should be used when generating the archives instead of your patch 
> to not have the mtimes touched when unpacking the archives.

Is it actually a problem to allow dpkg to normalize the timestamps on
these files rather than forcefully setting them to ... a value from a
shar archive? It is perhaps a naive question; I really do not know.


> But the diffoscope-results only show a few of the files from the shar 
> archives with different mtimes, and all of them get touched when 
> unpacking the archive just before the configure target is executed.

Well, I too was perplexed why other files were not affected, but it is
consistently those .gsb and .gtx files, and the submitted patch allows
to consistently build reproducibly in the dozens of times I've build
it...


> shar actually makes the timestamps reproducible by always using the 
> mtime recorded in the archive instead of the time the files were unpacked.
>
> Something else is likely changing the mtime after the files are 
> unpacked. Some of these grids are used by the testsuite for example.

I will try to look into it further, but without really being familiar
with the proj codebase (or even what proj itself does)... any additional
very specific suggestions where to look next would definitely be
appreciated!  :)


live well,
  vagrant
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-grass-devel/attachments/20230508/175da6dc/attachment.sig>


More information about the Pkg-grass-devel mailing list