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
signature.asc
Description: PGP signature
__ This is the maintainer address of Debian's Java team <https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-java-maintainers>. Please use debian-j...@lists.debian.org for discussions and questions.