Hello,

Debian Salsa seems to fail reprotest due to different compile times.
This has been tested on multiple different packages that use the
following CIs:

https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/salsa-ci.yml
https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/pipeline-jobs.yml

One recent example is here:
https://salsa.debian.org/DebianOnMobile-team/vvmd/-/pipelines/283265

When looking at the debs with diffoscope, I get example output like
below (it happens with several files, I only included one for brevity):

...
...

Hrm. That sounds suspicious...

I'm unable to reproduce this locally with reprotest against a vvmd or
osk-sdl git checkout. Maybe this has something to do with how salsaci is
setting up the directory... ? Maybe it unpacks the .orig.tar.* in some
way that alters the timestamps?

But that *should* be fixed by dpkg's SOURCE_DATE_EPOCH handling when it
generates the .deb ... hrm.

Maybe when the job was first run, SOURCE_DATE_EPOCH was set to a date
later than the file unpack times (e.g. maybe due to timezone?)... and
thus wouldn't clamp the timestamps ... that might explain re-running the
job later suceeding.


live well,
  vagrant

Hello!

Thank you for responding so fast.

Unfortunately, I do not know enough about reprotest to know what causes
it.

On a hunch, I also decided to rerun reprotest, and it worked this time:

https://salsa.debian.org/DebianOnMobile-team/vvmd/-/pipelines/283265

So it seems to be some sort of time/date dependent bug?

Respectfully,
Chris Talbot

Hi Chris,

thanks for your bugreport, but it seems to me that reprotest is not failing
but rather producing failure results when rebuilding your package. Is that
correct? If so, it's not a bug in reprotest... :)

Vagrant suggested a possible explaination... see above :)

Hello!

It is producing failure results when I am updating the package, i.e. I
have a new version and I update the Debian packaging. It fails the first
time, but it seems that if I rerun reprotest later, it will pass.

Hi,

I'm having a similar issue. Not sure if it is exactly identical. I can
open a new issue if required.

Basically, reprotest fails during a Salsa CI job on the Printrun
package [1] and I believe this is a false negative.

[1]: https://salsa.debian.org/3dprinting-team/printrun/-/jobs/2790747

An excerpt of the diffoscope output is copied below. Briefly, the
offending files are only different because of the date they were
created. For some reason one of the files creation/modification time is
set as it happened in 1971. Content wise, there's no difference between
them.

One thing that seems suspicious is that the offending files among some
of those modified by quilt patches. Does that ring any bells?

Might also be worth mentioning this package uses upstream and pristine-
tar branches. Could that have any implications?


│ │ ├── data.tar.xz
│ │ │ ├── data.tar
│ │ │ │ ├── file list
│ │ │ │ │ @@ -23,23 +23,23 @@
│ │ │ │ │  -rw-r--r--   0 root         (0) root         (0)    48911 2021-02-02 17:37:41.000000 ./usr/lib/python3/dist-packages/printrun/gl/libtatlin/actors.py
│ │ │ │ │  -rw-r--r--   0 root         (0) root         (0)    17289 2021-02-02 17:37:41.000000 ./usr/lib/python3/dist-packages/printrun/gl/panel.py
│ │ │ │ │  -rw-r--r--   0 root         (0) root         (0)     2724 2021-02-02 17:37:41.000000 ./usr/lib/python3/dist-packages/printrun/gl/trackball.py
│ │ │ │ │  drwxr-xr-x   0 root         (0) root         (0)        0 2022-04-30 17:32:34.000000 ./usr/lib/python3/dist-packages/printrun/gui/
│ │ │ │ │  -rw-r--r--   0 root         (0) root         (0)    13721 2021-02-02 17:37:41.000000 ./usr/lib/python3/dist-packages/printrun/gui/__init__.py
│ │ │ │ │  -rw-r--r--   0 root         (0) root         (0)     3276 2021-02-02 17:37:41.000000 ./usr/lib/python3/dist-packages/printrun/gui/bufferedcanvas.py
│ │ │ │ │  -rw-r--r--   0 root         (0) root         (0)    20859 2021-02-02 17:37:41.000000 ./usr/lib/python3/dist-packages/printrun/gui/controls.py
│ │ │ │ │ +-rw-r--r--   0 root         (0) root         (0)    21262 1971-06-21 19:14:00.000000 ./usr/lib/python3/dist-packages/printrun/gui/graph.py
│ │ │ │ │ --rw-r--r--   0 root         (0) root         (0)    21262 2022-04-30 17:32:34.000000 ./usr/lib/python3/dist-packages/printrun/gui/graph.py
│ │ │ │ │  -rw-r--r--   0 root         (0) root         (0)     2236 2021-02-02 17:37:41.000000 ./usr/lib/python3/dist-packages/printrun/gui/log.py
│ │ │ │ │  -rw-r--r--   0 root         (0) root         (0)     4251 2021-02-02 17:37:41.000000 ./usr/lib/python3/dist-packages/printrun/gui/toolbar.py
│ │ │ │ │  -rw-r--r--   0 root         (0) root         (0)     1466 2021-02-02 17:37:41.000000 ./usr/lib/python3/dist-packages/printrun/gui/utils.py
│ │ │ │ │  -rw-r--r--   0 root         (0) root         (0)     4990 2021-02-02 17:37:41.000000 ./usr/lib/python3/dist-packages/printrun/gui/viz.py
│ │ │ │ │  -rw-r--r--   0 root         (0) root         (0)    16728 2021-02-02 17:37:41.000000 ./usr/lib/python3/dist-packages/printrun/gui/widgets.py
│ │ │ │ │ +-rw-r--r--   0 root         (0) root         (0)    19964 1971-06-21 19:14:00.000000 ./usr/lib/python3/dist-packages/printrun/gui/xybuttons.py
│ │ │ │ │ --rw-r--r--   0 root         (0) root         (0)    19964 2022-04-30 17:32:34.000000 ./usr/lib/python3/dist-packages/printrun/gui/xybuttons.py
│ │ │ │ │  -rw-r--r--   0 root         (0) root         (0)     6048 2021-02-02 17:37:41.000000 ./usr/lib/python3/dist-packages/printrun/gui/zbuttons.py
│ │ │ │ │ +-rw-r--r--   0 root         (0) root         (0)    22401 1971-06-21 19:14:00.000000 ./usr/lib/python3/dist-packages/printrun/gviz.py
│ │ │ │ │ --rw-r--r--   0 root         (0) root         (0)    22401 2022-04-30 17:32:34.000000 ./usr/lib/python3/dist-packages/printrun/gviz.py


Please let me know if there's anything I can do to debug this any
further.

Christoph, I'm CCing you here both because you created the salsa CI
configuration file back in the day and because you are the latest
sponsor for this package, in case you feel this should be a blocker for
Printrun updates.

Regards,

Re: Rock Storm

Since this seems to be a toolchain issue rather than in the package,
don't treat it as a problem. (And even then, it's "only"
reproducibility which should be fixed, but doesn't have to.)

If it's getting too annoying, you could also make failures non-fatal:

reprotest:
  allow_failure: true

Christoph

Greetings.

I'm writing to you because I have a humanitarian request that I believe
could be incredibly impactful. I'm reaching out about the recent
devastating storm that tragically claimed many lives and affected numerous
individuals in Libya, including one of my clients. I would like to discuss
a proposal with you that could enable us to extend a helping hand to these
victims.

Looking forward to discussing this further with you.

Warm regards,
Mrs. Nathalie Herolds