Hi Santiago, * Santiago Vila <[email protected]> [2025-08-18 00:21]:
The debrebuild tool, used by reproduce.debian.net, is unable to rebuild the smartlist package.https://reproduce.debian.net/amd64/api/v0/builds/315659/log ----------------------------------------------------------------------------------- gcc -g -O2 -Werror=implicit-function-declaration -ffile-prefix-map=/build/reproducible-path/smartlist-3.15=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection -Wdate-time -D_FORTIFY_SOURCE=2 multigram.o sublib.o ecommon.o mcommon.o hsort.o lastdirsep.o -o multigram -Wl,-z,relro -lm -lc make[2]: Leaving directory '/build/reproducible-path/smartlist-3.15/src' Can't access /build/reproducible-path/smartlist-3.15/debian/tmp/var/list, are you sure it's there? ----------------------------------------------------------------------------------- I think the root cause of this is insufficient permissions in some of the directories required to reach /build/reproducible-path/smartlist-3.15/debian/tmp/var/list This is a problem which I found in the past, and there was even a comment in debian/rules about it, which I will quote below: # Important note: Make sure that all directories in # `pwd`/debian/tmp/var/list are world-readable. # Otherwise you may get this strange error: # "Can't access /var/list, are you sure it's there?" # I got this error because my home directory was mode 700. # Simply chmod 755 it and this will work. CC="$(CC)" CFLAGS0="$(CFLAGS0)" LDFLAGS0="$(LDFLAGS0)" \ SmartList/install.sh `pwd`/debian/tmp/var/list /var/list In version 3.15-25 from 2015-08-30, i.e. nearly ten years ago, those comments were removed with this changelog entry: * debian/rules: Drop obsolete comments and set permissions in a more straightforward way. Hopefully the package is reproducible now. So, while it's possible that we could avoid this problem to happen by some minor change in debian/rules, I would consider this as a bug in debrebuild, because this is not a hardware issue and the package builds ok in buildd.debian.org: https://buildd.debian.org/status/package.php?p=smartlist and also in Salsa CI: https://salsa.debian.org/sanvila/smartlist/-/pipelines and the comments in debian/rules were removed when it was clear that they were not needed anymore. In other words, I think debrebuild is breaking some common assumptions, which I would consider reasonable, about the way packages should be built.
Thanks for opening that bug. Let me give some historic context first as I don't think it is written somewhere already.
debrebuild uses the buildinfo files to create a chroot and those do not safe the installed fakeroot version. So initially debrebuild was not able to build any package that had not Rules-Requires-Root: no set. We discussed that back then and one option was to implement an heuristic to find a fitting fakeroot package but no one provided an implementation and it was not clear if it would actually work. At around the same time Niels worked a lot on R³ which resulted in no being the default and fixed those packages that broke by it. So I added a hack to debrebuild to assume Rules-Requires-Root: no when it was not set:
https://salsa.debian.org/debian/devscripts/-/commit/4b297b8bThis allowed us to build a lot more packages but those with Rules-Requires-Root: binary-targets, like smartlist where still failing. Given that fakeroot was an implementation detail and that unshare -U basically provides the same needs I added a patch to sbuild to build those packages as root (inside the unshare chroot):
https://salsa.debian.org/debian/sbuild/-/commit/08b79ae4 And enabled that for debrebuild: https://salsa.debian.org/debian/devscripts/-/commit/bf176207This works for most packages and my list of packages failing in trixie currently is:
openpgp-applet (should be fixed with a new upload #1109426) shellia: tests for fakeroot and fails with unshare root bup: tests for fakeroot and fails with unshare root smartlist permission problemThere are also some packages that do build but produce different results due to using chmod +s:
freesweep, 9mount, asciijump, dodgindiamond2And interestingly this also found a number of packages that encodes the fakeroot LD_LIBRARY_PATH into the package:
https://reproduce.debian.net/amd64/stats/#failed-to-reproduce:-fakeroot-in-LD-path https://reproduce.debian.net/all/stats/#failed-to-reproduce:-fakeroot-in-LD-pathI think those packages with the LD_LIBRARY_PATH should get a bug report like #1104998. For shellia and bup it should be enough to disable the tests and the rest should be patched to use the debputy package which is able to encode file permissions without needing (fake)root during the build. I have Cced Niels who already provided patches to other packages for that. Maybe he could provide patches for smartlist and the other packages as well.
In the long run we want to deprecate the use of fakeroot and requiring root during the build in general. Once that happened and all packages where rebuild we can also remove those hacks in debrebuild and sbuild.
Cheers Jochen
signature.asc
Description: PGP signature
