[Reproducible-builds] reproducible build examples

Christian T. Steigies cts at debian.org
Thu Mar 31 09:07:27 UTC 2016


Moin!
On Thu, Mar 31, 2016 at 12:57:27AM +0200, Reiner Herrmann wrote:
> > 
> > I have seen one which simply removed the timestamp from the executable. I do
> > not consider that as a solution, it is just a quick and dirty workaround.
> 
> I think it depends on the timestamp. In most cases they have no real
> meaning/use to the user and there is no harm in removing them. So I
> would say removing them where possible is actually a solution.
> SOURCE_DATE_EPOCH can then be used as a "workaround" when upstream
> insists on keeping timestamps or there are other reasons to keep it.

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?

> > https://tests.reproducible-builds.org/rb-pkg/unstable/amd64/gle-graphics.html
> 
> Thanks for fixing the issue mentioned there!
> We are reviewing the issues mostly manually. The note in your example
> was a bit outdated. We might also not always see _all_ issues in the diff.
> Sometimes it is just too large and hides other issues. Perhaps this
> was the reason why the PDF issue was not mentioned in the note.
> But I just updated it. :)

Thanks, I am not sure if this is correct (maybe because of the FTBFS you are
comparing the previous try?).

> Yes, we don't recommend the usage of faketime.

Ok, but should its use cause an FTBFS instead?

> 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...

> We have a script called prebuilder, which can be used locally to build
> packages twice with different variations [1] [2].
> This detects already a lot of issues.

Thanks, I will check it out.

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.

thanks,
Christian



More information about the Reproducible-builds mailing list