Bug#978499: #978499: fop: reproducible builds: Support using SOURCE_DATE_EPOCH for timestamps in PDF files
Vagrant Cascadian
vagrant at reproducible-builds.org
Fri Jan 1 19:17:46 GMT 2021
On 2020-12-31, Debian Bug Tracking System wrote:
> fop (1:2.5-3) unstable; urgency=medium
> .
> * Team upload
> * Update SOURCE_DATE_EPOCH patch (Closes: #978499)
> - Conditionally use SOURCE_DATA_EPOCH in PDFInfo, PDFMetadata,
> PDFRenderingUtil, and FileIDGenerator classes.
> - Add try/catch logic for unparsable SOURCE_DATE_EPOCH
Thanks for the follow-up!
It seems so very, very close, xorg-docs now is only varying on the
timezone, but otherwise respecting SOURCE_DATE_EPOCH:
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/xorg-docs.html
But what really confuses me is that "treeview" is still ignoring
SOURCE_DATE_EPOCH entirely (e.g. timestamps showing up from 2022):
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/treeview.html
From the output, it looks like both packages are embedding the same type
of values...
I confirmed that both builds actually were using fop version 2.5-3,
according to the build logs. Almost makes me wonder if treeview somehow
has an invalid date in the changelog entry...
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/20210101/8d467c6c/attachment.sig>
More information about the pkg-java-maintainers
mailing list