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

[Vagrant Cascadian]

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

You might want to use two different chroots, one with timezone set to
UTC+14 and one with the timezone set to UTC-12. These are the widest
range of timezones actually in use in the real world, although in theory
you could do something crazy like UTC+0 and UTC+26.

Another thing to try would be to do one build in a virtual machine with
the clock adjusted ... e.g. "qemu -rtc 2022-04-01" as well as using a
very different timezone.


> 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?

Yes, a diff like that is what we're hoping for!


From what I've been reading, java date objects are internally encoded in
UTC, but when you use the functions to output the date, it applies the
local timezone unless explicitly asked for a different timezone. /o\

Thanks for sharing the pain!


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/f0e3001b/attachment.sig>