Hi Santiago, * Santiago Vila <[email protected]> [2026-06-24 01:29]:
On Wed, Jun 24, 2026 at 12:18:39AM +0200, Jochen Sprickerhof wrote:Please say if you disagree and I can work on a patch to recover the old behaviour.I disagree with the premise that the package needs to be changed because of the way reproduce.debian.net is currently implemented. Let me answer one thing at a time:The problem is that it uses Rules-Requires-Root: binary-targets and with that fakeroot and that influences the build result. As the fakeroot package is not recorded in the buildinfo file,Well, maybe it should and the bug is somewhere else (for example, whatever program is creating the buildinfo file).
That would be dpkg-genbuildinfo from dpkg-dev. Back when we started with reproduce.d.n I discussed this and similar options with others and we agreed that fakeroot is an implementation detail and not a build dependency of the package. Also there is ongoing work to remove the fakeroot usage in the archive completely.
we can't use it during the rebuildWell, maybe you should use it during the rebuild even if it's not in the buildinfo file. It looks like this should be done in general for every package having a Rules-Requires-Root different than no.
The problem is that we don't know which version of the fakeroot package was used during the build. There where proposals to guess the likely version by the build date or scrape it from the buildd log but it would mean more hacks. And looking at #1114644 that a bookworm fakeroot does not work on a trixie kernel that may not even be enough...
The package was built using sbuild, and sbuild installs fakeroot when building the package, so it could be argued that you are not really trying to reproduce the package correctly if you omit fakeroot.
Note that a newer sbuild only installs fakeroot when R³: binary-targets is set. Looking at
https://codesearch.debian.net/search?q=Rules-Requires-Root%3A+binary-targets+path%3Adebian%2FcontrolThere are less then 250 packages left with R³: binary-targets and up to now I only found three where it is likely the cause of being not reproducible (investigating right now). Around 15 do not reproduce due to other reasons, like timestamps in manpages, and the rest reproduces just fine.
and the generated binaries differ. binary-targets is only needed for dh_fixperms in debian/ruleswhich I believe it's a completely legitimate usage of it.and a better way is to use debputy to adopt the owner and permissions in the generated package.Well, "better" depending on how you look at it. Instead of a simple debian/rules now I am supposed to include a fully structured file with a lot more lines to do essentially the same.
Not sure I understand the "a lot more lines" argument but the patch itself is 4 lines more then the old code. Do you mean that you also gain a dependency on dh-debputy? If so please note that there was an implicitly dependency on fakeroot before and that it carries way more complexity. For example it shadows the filesystem to track the chown and chmod calls. Also fakeroot has quiet a history of needing adoptions for new kernel releases, so I think debputy is better then fakeroot here.
Cheers Jochen
signature.asc
Description: PGP signature
