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