Bug#978499: fop: reproducible builds: Support using SOURCE_DATE_EPOCH for timestamps in PDF files

[tony mancill]

On Wed, Dec 30, 2020 at 06:23:29PM -0800, Vagrant Cascadian wrote:
> On 2020-12-30, tony mancill wrote:
> > On Tue, Dec 29, 2020 at 11:13:48AM -0800, Vagrant Cascadian wrote:
> >> Thanks for the quick upload! unfortunately...
> >> 
> >> > For example, in xorg-docs:
> >> >
> >> >   https://tests.reproducible-builds.org/debian/rb-pkg/bullseye/amd64/diffoscope-results/xorg-docs.html
> >> >
> >> >   /usr/share/doc/xorg-docs/xlfd/xlfd.pdf.gz
> >> >   
> >> >   CreationDate:·"D:20201225182038-12'00'"
> >> >   vs.
> >> >   CreationDate:·"D:20220129025203+14'00'"
> >> 
> >> I rescheduled various builds after fop landed in unstable, and it
> >> appears to not fully fix the issue...
> >> 
> >> It clearly fixed the issue for me when building xorg-docs with reprotest
> >> locally, which does test time and timezone variations... but it uses
> >> faketime, which often behaves differently than a system with an adjusted
> >> running clock such as the tests.reproducible-builds.org infrastructure.
> >
> > Hrm indeed...
> >
> > For what it's worth, the diffoscope for bullseye (which doesn't have the
> > fix for fop in there yet) and unstable look different to me.  In
> > bullseye, the "CreationDate" in the differs, as expected.  But in
> > unstable, the difference is in CreateDate in the XML metadata about the
> > file.
> >
> > I think it's possible that we are falling into this block of
> > PDFMetadata.java [1]:
> >
> >         //Set creation date if not available, yet
> >         if (info.getCreationDate() == null) {
> >             Date d = new Date();
> >             info.setCreationDate(d);
> >         }
> >
> > That would fit the symptoms.  In any event, in for a penny, in for a pound.  I think we can fix this by checking for null creationDate in PDFInfo.java [2] and once again using SOURCE_DATE_EPOCH if set.
> >
> > [1] https://salsa.debian.org/java-team/fop/-/blob/master/fop-core/src/main/java/org/apache/fop/pdf/PDFMetadata.java#L135-139
> > [2] https://salsa.debian.org/java-team/fop/-/blob/master/fop-core/src/main/java/org/apache/fop/pdf/PDFInfo.java#L190-195
> >
> > I have pushed patch to wrap the original modification to PDFInfo.java in
> > a try/catch but haven't yet uploaded.  I'll amend that and I do a little
> > reprotesting before uploading again.  
> 
> Thanks for continuing to dive into this one! :)
> 
> Maybe this is a red herring, but I also noticed that in PDFInfo.java
> there are two definitions of the modified function with the same name...
> 
> (snip)
> 
> Or is there some java thing to handle functions with the same names?

Yes, it's a common pattern in Java.  The methods vary in their arguments
and so are distinct signatures.  In this case, the method that takes a
TimeZone as an argument is called by the other method of the same name
in PDFInfo *and* in PDFEmbeddedFile.  So... I went looking for all of
the invocations of new Date() in the fop code and found several other
methods where SOURCE_DATE_EPOCH should be checked.

I have an updated patch for fop that addresses the issue with xorg-docs
and probably a few others too.  I'm going to let ratt chew on the build
r-deps before uploading, but expect to upload tomorrow.

Cheers,
tony