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

[Vagrant Cascadian]

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

    /**
     * Formats a date/time according to the PDF specification
    (D:YYYYMMDDHHmmSSOHH'mm').
     * @param time date/time value to format
     * @param tz the time zone
     * @return the requested String representation
     */
    protected static String formatDateTime(final Date time, TimeZone tz)
    {
        return DateFormatUtil.formatPDFDate(time, tz);
    }

    /**
     * Formats a date/time according to the PDF
    specification. (D:YYYYMMDDHHmmSSOHH'mm').
     * @param time date/time value to format
     * @return the requested String representation
     */
    protected static String formatDateTime(final Date time) {
        return formatDateTime(time, TimeZone.getDefault());
    }


Or is there some java thing to handle functions with the same names?



live well,
  vagrant
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-java-maintainers/attachments/20201230/31bb0c2a/attachment.sig>