[Reproducible-builds] reproducible build examples

[Reiner Herrmann]

On Thu, Mar 31, 2016 at 11:07:27AM +0200, Christian T. Steigies wrote:
> It was not too difficult to replace \today in the tex file with a timestamp
> generated from SOURCE_DATE_EPOCH, so I did that. The date is used on the
> title page, so I think it makes sense to use this date like a version info.
> However, it took me two tries, since month names are not reproducible, so I
> had to use a format with numbers only. Why would I want to use a french
> month name in an english document?

You probably don't want them. But there are people that have different
locales configured, so `date` will have different output on their
systems. If you really want an English month name, you could set
LC_ALL to C before calling date.

> > Yes, we don't recommend the usage of faketime.
> 
> Ok, but should its use cause an FTBFS instead?

Hm, meanwhile on armhf version 4.2.5-4 built successfully.
But the amd64 build failure is probably related to faketime.

> > I would instead remove the first timestamp in the PDF documentation and
> > replace the second one with some dummy value.
> 
> I did replace \today in the tex file with a generated date using SOURCE_DATE_EPOCH
> 
> https://anonscm.debian.org/git/debian-science/packages/gle-graphics.git/diff/?id=dfd125d35679a90931cd1c31314d8745eb806354&id2=e9449eb0a3197b6617d2d1ed29ebf0caab4095fe 
> 
> In the previous try I did replace the second one (if we are talking about
> the same one) with a static string (this was the time$() function in a gle
> example). However, the manual contains a lot of images as PDF files, which
> are generated by gle (after all the manual is the documentation for gle).
> The generated PDF files seem to contain timestamps as metadata also (I
> checked this for the font tables in the appendix, but there are more figures).
> When these PDF images are included in the latex document, it seems the
> timestamps in the metadata make it into the final PDF file. To get these
> consistent, I used faketime to generate the documentation (or just the
> images, but that seems to be more complicated, since I would have to pass
> the EPOCH to secondary Makefiles). Is there a better way to remove the
> timestamp metadata from the PDF images or all PDF files? The metadata also
> seems to include the location where the file is created...

Hmm, are you sure it is caused by metadata from images?
There will also be a lot of noise in PDF files, if somewhere the text
changes (like the embedded date), which can be easily misinterpreted as
unrelated differences.
I would guess that the PDF becomes reproducible when the timestamp
issues are fixed (even without using faketime).

> I have another package which is marked unreproducible:
> 
> https://tests.reproducible-builds.org/rb-pkg/unstable/amd64/moon-buggy.html
> https://tests.reproducible-builds.org/dbd/unstable/amd64/moon-buggy_1.0.51-10.diffoscope.html
> 
> The diff looks huge, but looking at the text output, it seems the date is
> different between the two builds:
> 
> 2	27 December 2004	2	28 December 2004
> 
> As far as I can see, this date is defined as a static value in version.texi:
> 
> @set UPDATED 27 December 2004
> 
> Why and how is this modified in the second build? Is this related to the
> different timezone? But even if the timezone is changed, why is the date
> changed, there is no time defined in version.texi, so why would the date be
> changed? I don't know if that explains the whole difference, though.

I think this is updated during the build from Makefile.in:396, there
version.texi is regenerated.
And yes, the reason for this is the timezone difference:
https://tests.reproducible-builds.org/issues/unstable/timezone_variance_because_of_automake_mdate_issue.html
mdate-sh prints the last modification date of moon-buggy.texi.
The modification time actually has a higher resolution than just day+month+year.
But mdate-sh isn't normalizing the timezone, so the date can actually
vary.
(In Debian's automake this is already fixed, but packages shipping/using
an old mdate-sh are still affected.)

Kind regards,
  Reiner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/reproducible-builds/attachments/20160401/cfcffc39/attachment.sig>