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