On 2021-08-30, Christopher Talbot wrote: > Debian Salsa seems to fail reprotest due to different compile times. ... > 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): > > -drwxr-xr-x 0 root (0) root (0) 0 2021-08-30 > 22:22:16.000000 ./ > │ │ │ -drwxr-xr-x 0 root (0) root (0) 0 2021- > 08-30 22:22:15.000000 ./usr/ > │ │ │ -drwxr-xr-x 0 root (0) root (0) 0 2021- > 08-30 22:22:16.000000 ./usr/bin/ > │ │ │ --rwxr-xr-x 0 root (0) root (0) 119928 2021- > 08-30 22:22:16.000000 ./usr/bin/vvmd ... > 08-30 22:22:24.000000 ./usr/ > │ │ │ +drwxr-xr-x 0 root (0) root (0) 0 2021- > 08-30 22:22:25.000000 ./usr/bin/ > │ │ │ +-rwxr-xr-x 0 root (0) root (0) 119928 2021- > 08-30 22:22:25.000000 ./usr/bin/vvmd
> In osk-sdl, it seemed to be fixed by running it a day later. > https://salsa.debian.org/DebianOnMobile-team/osk-sdl/-/jobs/1821885 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
signature.asc
Description: PGP signature
