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

[tony mancill]

On Fri, Jan 01, 2021 at 11:17:46AM -0800, Vagrant Cascadian wrote:
> 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...

In case it helps point out a hole in my testing strategy, I did my local
testing by extracting the xorg-docs source package into 4 different
directories and then building with sbuild, either against "pure" sid or
as below to test fop 2.5-3 before the upload, and then running
diffoscope against the resulting changes files:

sbuild --chroot=sid-amd64-sbuild --extra-package=/path/to/fop_2.5-3_all.deb --extra-package=/path/to/libfop-java_2.5-3_all.deb

For my pre-2.5-3 builds and when comparing 2.5-2 and 2.5-3 builds, I saw
differences like those on reproducible-builds.org.  The 'c' and 'd'
builds are both with fop 2.5-3, but several minutes apart, and only
show:

diffoscope c/xorg-docs_1.7.1-1.2_amd64.changes d/xorg-docs_1.7.1-1.2_amd64.changes
--- c/xorg-docs_1.7.1-1.2_amd64.changes
+++ d/xorg-docs_1.7.1-1.2_amd64.changes
├── Files
│ @@ -1,6 +1,6 @@
│  
│   c3c9468c8de1825668386eb1c8131e4f 1132 doc optional xorg-docs_1.7.1-1.2.dsc
│   f6a6ecca98d411d73492303db3190bca 13250 doc optional xorg-docs_1.7.1-1.2.diff.gz
│   6939769b47ecad2875ae10674ed4db03 84224 doc optional xorg-docs-core_1.7.1-1.2_all.deb
│   9baa141ec6258704be08b8873f8892c9 1160544 doc optional xorg-docs_1.7.1-1.2_all.deb
│ - a09f88c06107005935ff6664eccfe306 7625 doc optional xorg-docs_1.7.1-1.2_amd64.buildinfo
│ + 6664227d398e6954e41b5c4fc468448c 7625 doc optional xorg-docs_1.7.1-1.2_amd64.buildinfo
├── xorg-docs_1.7.1-1.2_amd64.buildinfo
│ ├── Build-Date
│ │ @@ -1 +1 @@
│ │ -Thu, 31 Dec 2020 06:40:14 +0000
│ │ +Thu, 31 Dec 2020 06:42:37 +0000
│ ├── Build-Path
│ │ @@ -1 +1 @@
│ │ -/build/xorg-docs-By7U5v/xorg-docs-1.7.1
│ │ +/build/xorg-docs-kFh9qq/xorg-docs-1.7.1
 

By comparing two separate 2.5-2 builds, I was able to confirm that 2.5-2
only partially addressed the embedded timestamps in the PDFs, but the
diff above looks like what we want, right?

Cheers,
tony
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-java-maintainers/attachments/20210101/aed9713d/attachment-0001.sig>