Source: gdbm
Version: 1.23-3
Severity: normal
User: reproducible-bui...@lists.alioth.debian.org
Usertags: randomness
X-Debbugs-Cc: cjwat...@debian.org, reproducible-b...@lists.alioth.debian.org
Control: affects -1 + mmdebstrap man-db
Hi,
here is a test script that shows the problem:
$ printf "#:len=6\nZm9vYmFy\n#:len=6\nZm9vYmFy\n" > index.dump
$ gdbm_load index.dump index1.db
$ gdbm_load index.dump index2.db
$ md5sum index1.db index2.db
The md5sums of index1.db and index2.db will differ despite both being created
from index.dump. To figure out which architectures are affected by this
problem, we use debvm:
sshcmd="ssh -o NoHostAuthenticationForLocalhost=yes -p 8022 root@127.0.0.1"
failing=
for arch in amd64 arm64 armel armhf i386 mips64el mipsel ppc64el s390x; do
debvm-create -a $arch -k ~/.ssh/id_rsa.pub -- --include=gdbmtool
debvm-run -s 8022 &
pid=$!
debvm-waitssh -t 300 127.0.0.1:8022
printf "#:len=6\nZm9vYmFy\n#:len=6\nZm9vYmFy\n" | $sshcmd tee
/index.dump >/dev/null
$sshcmd gdbm_load /index.dump /index1.db
$sshcmd gdbm_load /index.dump /index2.db
ret=0
$sshcmd cmp /index1.db /index2.db || ret=1
if [ $ret -ne 0 ]; then
failing="$failing $arch"
fi
$sshcmd systemctl poweroff
wait $pid
done
echo $failing
This will output "armel armhf mipsel". Note, that qemu-usermode emulation is
not enough to reproduce the problem. So the following will show the issue when
run on arm64 but not when run on amd64:
mmdebstrap --arch=armhf --variant=essential --include=gdbmtool \
--customize-hook='printf "#:len=6\nZm9vYmFy\n#:len=6\nZm9vYmFy\n" >
"$1/index.dump"' \
--customize-hook='chroot "$1" gdbm_load /index.dump /index1.db' \
--customize-hook='chroot "$1" gdbm_load /index.dump /index2.db' \
--customize-hook='md5sum "$1/index1.db" "$1/index2.db"' \
--customize-hook='cmp "$1/index1.db" "$1/index2.db"' \
unstable /dev/null
I found this problem in an mmdebstrap autopkgtest failure due to different
contents of /var/cache/man/index.db on armel and armhf. When running gdbm_dump
for the two differing index.db files it shows that the contents they store is
actually identical. So this is a gdbm-specific problem and not a problem with
man-db. I'm able to reproduce it by running gdbm_load on a minimal dump file
as shown above.
You can see the diffoscope output of the mmdebstrap test failure in this log:
https://ci.debian.net/data/autopkgtest/unstable/armhf/m/mmdebstrap/31327623/log.gz
grep for /index.db to find the differences.
Somebody familiar with the gdbm format can maybe spot which part of the file it
is that differs.
Thanks!
cheers, josch
