Hi Chris, On 02/01/2020 00:57, Chris Lamb wrote: > [Keeping you in CC; like not subscribed to this "old" Alioth list but let me > know if you are ]
Thanks. I'm not subscribed. > Indeed, this appears to rule out a reprotest-specific issue and believe I can > reproduce this test failure by exporting: > > TZ="/usr/share/zoneinfo/Etc/GMT-14" Excellent. Thanks for pointing that out. I hadn't found the environment settings required to provoke the test failure. Specifically, the following: TZ="/usr/share/zoneinfo/Etc/GMT-14" convert rose: test.tif && tiff2pdf -o test.pdf -e 20181231120000 test.tif && pdfinfo test.pdf Produces the following output (I am in CET): CreationDate: Mon Dec 31 13:00:00 2018 CET ModDate: Mon Dec 31 13:00:00 2018 CET Is this a bug, then, that tiff2pdf is ignoring the TZ environmental variable? > Does this help? Absolutely. > I'm missing a little bit of clarity though as gscan2pdf 2.6.2-1 in > unstable/amd64 still FTBFS, but you seem to have added code to this > version (or an older one) to skip precisely this failing test: Yes. I added the code to get it to pass the test on the first build, but obviously, it wasn't enough to pass the second build. > Assuming by "run the second build first" you mean re-ordering the > builds, I'm not sure how this would/could help? Like the above query > about the version skip, I think I'm missing something obvious here. It wasn't obvious to me what environment settings were provoking the test failure. I was trying to debug the problem, not patient enough to wait for reprotest to run both builds for each debug iteration. If it had been possible to run the second build first, it would have made for faster debugging iterations. Regards Jeff
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Reproducible-builds mailing list Reproducible-builds@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
