On Fri, Dec 06, 2024 at 02:32:30PM +0100, Jochen Sprickerhof wrote: > > about 10% of packages failing to reproduce on reproduce.d.n show a > > peculiar issue: some (not all) of the timestamps of the packaged files > > are exactly 1-second in the future compared to the reference package.
> > --rw-r--r-- […] 743 2024-10-20 17:14:00 ./u/l/sd/s/vip-manager.service > > +-rw-r--r-- […] 743 2024-10-20 17:14:01 ./u/l/sd/s/vip-manager.service >From the examples in this bug, it looks like this only affects files that are patched in the Debian package. My theory is that during the original build sbuild calculates the timestamp from the current time after dpkg-source has patched the input files [1]. When these happen on different sides of a full second boundary, the patched files (or just some of them) are one second older than SOURCE_DATE_EPOCH. Then all newer files are clamped to SOURCE_DATE_EPOCH, but the ones with an older timestamp stay untouched. OTOH, when debrebuild tries to reproduce the package it's firmly in the future, so the patched files are always newer than SOURCE_DATE_EPOCH and get clamped with all the others. [1] dpkg-source: info: extracting vip-manager in /<<PKGBUILDDIR>> dpkg-source: info: unpacking vip-manager_1.0.2.orig.tar.gz dpkg-source: info: unpacking vip-manager_1.0.2-9.debian.tar.xz dpkg-source: info: using patch list from debian/patches/series dpkg-source: info: applying service_file.patch dpkg-source: info: applying disable_windows_build.patch dpkg-source: info: applying behaviour_test.patch dpkg-source: info: applying get_dev dpkg-source: info: applying disable-consul dpkg-source: info: applying netip-port.patch dpkg-source: info: applying etcd-3.5-build-fixes.patch Check disk space ---------------- Sufficient free space for build Hack binNMU version ------------------- Created changelog entry for binNMU version 1.0.2-9+b2 Hope this helps, -- Niko Tyni nt...@debian.org
