Debian Bug report logs - #951216
poppler-utils: pdfinfo incorrectly reports date metadata under reprotest

Reply or subscribe to this bug.

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Jeffrey Ratcliffe <jffry@posteo.net>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: poppler-utils: pdfinfo incorrectly reports date metadata under reprotest

Date: Wed, 12 Feb 2020 18:19:31 +0100

Package: poppler-utils
Version: 0.71.0-6
Severity: normal

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?

Create a PDF with defined date metadata:

convert rose: test.tif && tiff2pdf -o test.pdf -e 20181231120000 test.tif

pdfinfo then correctly reports the metadata:

$ pdfinfo test.pdf
Producer:       libtiff / tiff2pdf - 20191103
CreationDate:   Mon Dec 31 13:00:00 2018 CET

   * What exactly did you do (or not do) that was effective (or
     ineffective)?

From reprotest, however, the output is incorrect.

   * What was the outcome of this action?

$ reprotest -c 'pdfinfo test.pdf' . "*.deb *.changes"
WARNING:reprotest:The control build runs on 1 CPU by default, give --min-cpus
to increase this.
Producer:       libtiff / tiff2pdf - 20191103
CreationDate:   Mon Dec 31 00:00:00 2018 GMT

   * What outcome did you expect instead?

For GMT, I would have expected:

CreationDate:   Mon Dec 31 12:00:00 2018 GMT

Both the isodates and rawdates option work fine:

$ reprotest -c 'pdfinfo -isodates test.pdf' . "*.deb *.changes"
WARNING:reprotest:The control build runs on 1 CPU by default, give --min-cpus
to increase this.
Producer:       libtiff / tiff2pdf - 20191103
CreationDate:   2018-12-31T12:00:00Z

$ reprotest -c 'pdfinfo -rawdates test.pdf' . "*.deb *.changes"
WARNING:reprotest:The control build runs on 1 CPU by default, give --min-cpus
to increase this.
Producer:       libtiff / tiff2pdf - 20191103
CreationDate:   D:20181231120000

This is a problem for programs that rely on pdfinfo to extract metadata from
PDF files, as they then fail reproducibility testing.



-- System Information:
Debian Release: bullseye/sid
  APT prefers testing-debug
  APT policy: (500, 'testing-debug'), (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 5.4.0-3-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages poppler-utils depends on:
ii  libc6         2.29-9
ii  libcairo2     1.16.0-4
ii  libfreetype6  2.10.1-2
ii  liblcms2-2    2.9-3+b1
ii  libpoppler82  0.71.0-6
ii  libstdc++6    9.2.1-25

poppler-utils recommends no packages.

poppler-utils suggests no packages.

-- no debconf information

Message #10 received at 951216@bugs.debian.org (full text, mbox, reply):

From: "Chris Lamb" <lamby@debian.org>

To: 951216@bugs.debian.org

Cc: "Jeffrey Ratcliffe" <jffry@posteo.net>

Subject: Re: poppler-utils: pdfinfo incorrectly reports date metadata under reprotest

Date: Thu, 13 Feb 2020 15:27:09 +0000

user reproducible-builds@lists.alioth.debian.org
usertag 951216 + toolchain timestamps
thanks

> poppler-utils: pdfinfo incorrectly reports date metadata under reprotest

It's unclear to me whether this is a bug in Poppler or reprotest. When
I try and reproduce this outside of reprotest, for example with something
like:

  $ TZ="/usr/share/zoneinfo/Etc/GMT-14" pdfinfo foo.pdf

… and:

  $ TZ="/usr/share/zoneinfo/Etc/GMT+12" pdfinfo foo.pdf

… I get the expected results. Saying that, poppler has the following
"smoking gun"-like comment:

    // TODO do something with the timezone info

… but that curiously is then followed by code that appears to do
something with the timezone info:

    s = obj.getString()->c_str();
    // TODO do something with the timezone info
    if ( parseDateString( s, &year, &mon, &day, &hour, &min, &sec, &tz, &tz_hour, &tz_minute ) ) {
      tmStruct.tm_year = year - 1900;
      tmStruct.tm_mon = mon - 1;
      tmStruct.tm_mday = day;
      tmStruct.tm_hour = hour;
      tmStruct.tm_min = min;
      tmStruct.tm_sec = sec;
      tmStruct.tm_wday = -1;
      tmStruct.tm_yday = -1;
      tmStruct.tm_isdst = -1;
      // compute the tm_wday and tm_yday fields
      time = timegm(&tmStruct);
      if (time != (time_t)-1) {
	int offset = (tz_hour*60 + tz_minute)*60;
	if (tz == '-')
	  offset *= -1;
	time -= offset;
	localtime_r(&time, &tmStruct);
	strftime(buf, sizeof(buf), "%c %Z", &tmStruct);
	fputs(buf, stdout);

But I might be missing something.

Can I suggest two things at this point? First, could you attach your
generated test.pdf to this bug so that we are completely on the same
page and using the exactly the same file? Secondly, perhaps you could
systematically alter the settings of reprotest in order to identify
which is the variation employed that is causing this to happen?


Regards,

-- 
      ,''`.
     : :'  :     Chris Lamb
     `. `'`      lamby@debian.org / chris-lamb.co.uk
       `-

Message #15 received at 951216@bugs.debian.org (full text, mbox, reply):

From: Jeff <jffry@posteo.net>

To: 951216@bugs.debian.org

Subject: Re: poppler-utils: pdfinfo incorrectly reports date metadata under reprotest

Date: Fri, 14 Feb 2020 09:41:56 +0100

[Message part 1 (text/plain, inline)]

> Can I suggest two things at this point? First, could you attach your
> generated test.pdf to this bug so that we are completely on the same
> page and using the exactly the same file? Secondly, perhaps you could
> systematically alter the settings of reprotest in order to identify
> which is the variation employed that is causing this to happen?

I've attached test.pdf as requested.

I've also tried to create a dummy package (attached) to reproduce the
problem. Unfortunately

reprotest .

fails with:

unshare: echec de unshare: �������� �� ���������
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/reprotest/__init__.py", line 843,
in run
    return 0 if check_func(*check_args) else 1
  File "/usr/lib/python3/dist-packages/reprotest/__init__.py", line 369,
in check
    local_dists += [proc.send(nv) for nv in zip(bnames[1:],
build_variations[1:])]
  File "/usr/lib/python3/dist-packages/reprotest/__init__.py", line 369,
in <listcomp>
    local_dists += [proc.send(nv) for nv in zip(bnames[1:],
build_variations[1:])]
  File "/usr/lib/python3/dist-packages/reprotest/__init__.py", line 329,
in corun_builds
    bctx.run_build(testbed, build, os.environ, artifact_pattern,
testbed_build_pre, no_clean_on_error)
  File "/usr/lib/python3/dist-packages/reprotest/__init__.py", line 220,
in run_build
    kind='build')
  File "/usr/lib/python3/dist-packages/reprotest/__init__.py", line 64,
in check_exec2
    adtlog.AutopkgtestError)
  File "/usr/lib/python3/dist-packages/reprotest/__init__.py", line 70,
in bomb
    raise _type(m)
reprotest.lib.adtlog.AutopkgtestError: "sh -ec run_build() {
    mkdir -p /tmp/reprotest.pyacok/build-experiment-1-aux && \
    SETARCH_ARCH=$(setarch --list | grep -vF "$(uname -m)" | shuf | head
-n1) && \
    KERNEL_VERSION=$(uname -r) && \
    if [ ${KERNEL_VERSION#2.6} = $KERNEL_VERSION ]; then
SETARCH_OPTS=--uname-2.6; fi && \
    CPU_MAX=$(nproc) && \
    CPU_MIN=$({ echo $CPU_MAX; echo 1; } | sort -n | head -n1) && \
    CPU_NUM=$(if [ $CPU_MIN = $CPU_MAX ];             then echo
$CPU_MIN; echo >&2 "only 1 CPU is available; num_cpus is ineffective";
           else shuf -i$((CPU_MIN + 1))-$CPU_MAX -n1; fi) && \
    mv /tmp/reprotest.pyacok/build-experiment-1/
/tmp/reprotest.pyacok/build-experiment-1-before-disorderfs/ && \
    mkdir -p /tmp/reprotest.pyacok/build-experiment-1/ && \
    disorderfs -q --shuffle-dirents=yes
/tmp/reprotest.pyacok/build-experiment-1-before-disorderfs/
/tmp/reprotest.pyacok/build-experiment-1/ && \
    umask 0002 && \
    export
REPROTEST_BUILD_PATH=/tmp/reprotest.pyacok/build-experiment-1/ && \
    export REPROTEST_UMASK=$(umask) && \
    unshare -r --uts sh -ec '
            hostname reprotest-capture-hostname
            domainname "reprotest-capture-domainname"
            "$@"' - \
    faketime +294days+15hours+41minutes \
    taskset -a -c $(echo $(shuf -i0-$((CPU_MAX - 1)) -n$CPU_NUM) | tr '
' ,) \
    setarch $SETARCH_ARCH $SETARCH_OPTS \
    sh -ec 'cd "$REPROTEST_BUILD_PATH"; unset REPROTEST_BUILD_PATH;
umask "$REPROTEST_UMASK"; unset REPROTEST_UMASK; dpkg-buildpackage
--no-sign -b'
}

cleanup() {
    __c=0; \
    export PATH="/tmp/reprotest.pyacok/bin:$PATH" || __c=$?; \
    fusermount -u /tmp/reprotest.pyacok/build-experiment-1/ || __c=$?; \
    rmdir /tmp/reprotest.pyacok/build-experiment-1/ || __c=$?; \
    mv /tmp/reprotest.pyacok/build-experiment-1-before-disorderfs/
/tmp/reprotest.pyacok/build-experiment-1/ || __c=$?; \
    rm -rf /tmp/reprotest.pyacok/build-experiment-1-aux || __c=$?; \
    exit $__c
}

trap '( cleanup )' HUP INT QUIT ABRT TERM PIPE # FIXME doesn't quite
work reliably yet

if ( run_build ); then ( cleanup ); else
    __x=$?; # save the exit code of run_build
    if ( ! false ); then
        if ( cleanup ); then :; else echo >&2 "cleanup failed with exit
code $?"; fi;
    fi
    exit $__x
fi" failed with status 1

[test.pdf (application/pdf, attachment)]

[reprotest-pdfinfo_1-1.dsc (text/plain, attachment)]

[reprotest-pdfinfo_1-1.tar.gz (application/gzip, attachment)]

[reprotest-pdfinfo_1.orig.tar.xz (application/x-xz, attachment)]

[signature.asc (application/pgp-signature, attachment)]

Message #20 received at 951216@bugs.debian.org (full text, mbox, reply):

From: Jeff <jffry@posteo.net>

To: 951216@bugs.debian.org

Subject: Re: poppler-utils: pdfinfo incorrectly reports date metadata under reprotest

Date: Wed, 19 Feb 2020 17:46:09 +0100

[Message part 1 (text/plain, inline)]

Strangely, the dummy package built fine (i.e. only reproducibility
problems, not build-chain problems) on a Mint 19.3-based machine,
which allowed me to try out Vagrant's suggestions[1]:

> This *should* vary only time:

>  reprotest --variations=-all,+time

> and and only timezome:

>  reprotest --variations=-all,+timezone

 reprotest --variations=-all,+time .

built fine. But

 reprotest --variations=-all,+timezone .

did not:

 -CreationDate:   Mon Dec 31 00:00:00 2018 GMT
 -ModDate:        Mon Dec 31 00:00:00 2018 GMT
 +CreationDate:   Tue Jan  1 02:00:00 2019 GMT
 +ModDate:        Tue Jan  1 02:00:00 2019 GMT

But given that Chris couldn't reproduce the problem outside reprotest,
my suggestion would be for someone with knowledge of the internals of
reprotest to take a look and understand what is going on.

[1]
https://alioth-lists.debian.net/pipermail/reproducible-builds/Week-of-Mon-20200203/012103.html

[signature.asc (application/pgp-signature, attachment)]

Send a report that this bug log contains spam.