Control: reassign -1 sbuild 0.87.1
Control: tag -1 patch
On Fri, Dec 06, 2024 at 06:45:47PM +0200, Niko Tyni wrote:
> 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
> 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.
I played around a bit with this, and I'm confident enough now that I'm
reassigning the bug. Obviously feel free to undo if I'm somehow mistaken.
I'm able to reproduce the issue with a trivial example
package: libacme-damn-perl_0.08-3 in current sid patches
Damn.pm, which then gets installed in the binary package as
./usr/lib/x86_64-linux-gnu/perl5/5.40/Acme/Damn.pm .
Building that as a binNMU 50 times in a row with sbuild 0.87.1
got me 8/50 .deb files where the file was one second older than
./usr/share/doc/libacme-damn-perl/changelog.Debian.amd64.gz .
For full disclosure, the exact sbuild invocation I used was
% sbuild --no-apt-update -c sid -d unstable --make-binNMU=test -m"Niko Tyni
<nt...@debian.org>" libacme-damn-perl
I then applied the attached patch to sbuild and repeated the experiment,
getting a full 50/50 builds without the one second timestamp mismatch. I
eyeballed a few of them and they all looked otherwise correct to me.
FWIW, while tools like 'dpkg-deb -c' don't show enough precision in the
timestamps, this does:
% python3 -c 'import sys; from debian import debfile;
debfile.DebFile(sys.argv[1]).data.tgz().list()'
libacme-damn-perl_0.08-3+b1_amd64.deb
and the attached babytalk Python script 'check-deb.py' is what I used to
detect whether the issue was present in each .deb file or not. It could
certainly be improved. Eyeballs on the patch and further test reports
are very welcome of course.
I note that if the patch is deemed acceptable, it will also need to be
deployed on the official buildds. The problem lies with the original
packages built by Debian, not the ones reproduced by debrebuild.
Still hoping some of this helps,
--
Niko Tyni nt...@debian.org
>From 237561fbf3c72ed0b77172c7e44c66f1abedd14e Mon Sep 17 00:00:00 2001
From: Niko Tyni <nt...@debian.org>
Date: Sat, 7 Dec 2024 17:38:27 +0000
Subject: [PATCH] Use build start time when generating binNMU timestamp
This ensures that the mtime of all patched files get clamped to the
same timestamp.
Bug-Debian: https://bugs.debian.org/1089088
---
lib/Sbuild/Build.pm | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/lib/Sbuild/Build.pm b/lib/Sbuild/Build.pm
index e35db3b2..5536e94b 100644
--- a/lib/Sbuild/Build.pm
+++ b/lib/Sbuild/Build.pm
@@ -2417,7 +2417,8 @@ sub build {
$date = $self->get_conf('BIN_NMU_TIMESTAMP');
}
} else {
- $date = strftime_c "%a, %d %b %Y %H:%M:%S +0000", gmtime();
+ $date = strftime_c "%a, %d %b %Y %H:%M:%S +0000",
+ gmtime($self->get('Pkg Start Time'));
}
print $clogpipe " -- " . $self->get_conf('MAINTAINER_NAME') . " $date\n\n";
}
--
2.45.2
#!/usr/bin/python3
import sys
from debian import debfile
deb = debfile.DebFile(sys.argv[1])
data = deb.data
tgz = data.tgz()
members = tgz.getmembers()
reference = None
for m in members:
if m.name.endswith('changelog.Debian.amd64.gz'):
reference = m.mtime
break
if reference is None:
raise RuntimeError('No binNMU changelog found')
for m in members:
if m.mtime == reference - 1:
print('1-second mismatch found')
sys.exit(1)
print('no timestamp mismatch found')
sys.exit(0)
