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

[tony mancill]

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.  

> Ah well, if anyone has a suggestion for how to really fix it, that would
> be nice, since it would fix several packages...

I should have something up tomorrow. 

Cheers,
tony
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-java-maintainers/attachments/20201230/c354ee0d/attachment.sig>