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 _______________________________________________ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds