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