Hi Santiago,

procmail is currently not reproducible on reproduce.debian.net:

https://reproduce.debian.net/excuses.html?source_name=procmail

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, we can't use it during
the rebuild and the generated binaries differ. binary-targets is only
needed for dh_fixperms in debian/rules and a better way is to use
debputy to adopt the owner and permissions in the generated package.
Please find attached a patch for procmail to do that and make it
reproducible. Note that it also makes three example shell scripts
executable, I think that makes sense:

│ │ │ --rw-r--r--   0 root         (0) root         (0)      404 1996-12-21 03:28:15.000000 ./usr/share/doc/procmail/examples/1rmail
│ │ │ +-rwxr-xr-x   0 root         (0) root         (0)      404 1996-12-21 03:28:15.000000 ./usr/share/doc/procmail/examples/1rmail
│ │ │  -rw-r--r--   0 root         (0) root         (0)     1989 1994-05-26 13:46:40.000000 ./usr/share/doc/procmail/examples/2procmailrc
│ │ │ --rw-r--r--   0 root         (0) root         (0)      396 1996-12-21 03:28:15.000000 ./usr/share/doc/procmail/examples/2rmail
│ │ │ +-rwxr-xr-x   0 root         (0) root         (0)      396 1996-12-21 03:28:15.000000 ./usr/share/doc/procmail/examples/2rmail
│ │ │  -rw-r--r--   0 root         (0) root         (0)     1533 1994-05-26 13:46:41.000000 ./usr/share/doc/procmail/examples/3procmailrc
│ │ │ --rw-r--r--   0 root         (0) root         (0)      761 1996-12-21 03:28:15.000000 ./usr/share/doc/procmail/examples/3rmail
│ │ │ +-rwxr-xr-x   0 root         (0) root         (0)      761 1996-12-21 03:28:15.000000 ./usr/share/doc/procmail/examples/3rmail

Please say if you disagree and I can work on a patch to recover the old
behaviour.

Could you please apply the attached patch and upload a new revision?

Thanks!

Jochen

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:

Well, maybe it should and the bug is somewhere else (for example,
whatever program is creating the buildinfo file).

Well, 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 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.

which I believe it's a completely legitimate usage of it.

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.

Sorry, but I don't like this. I think the problem should be fixed at
its source, not in the individual packages.

Thanks.

Hi Santiago,

* Santiago Vila <sanvila@debian.org> [2026-06-24 01:29]:

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.

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...
is set. Looking at

https://codesearch.debian.net/search?q=Rules-Requires-Root%3A+binary-targets+path%3Adebian%2Fcontrol

There 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.

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

If the presence of fakeroot may affect the end result, it would seem
natural that it should be recorded in the buildinfo file.

I could agree about the fact that it's not a build-dependency in
strict sense, so maybe it's ok that it's not in the
Installed-Build-Depends field of the buildinfo file, but if it's not
there maybe it should be somewhere else.

Even a "Fakeroot-Version:" field would be (or "would have been",
depending on we look at it...) better than nothing.

My feeling is that we are mixing things that should be independent and
handled separately.

For example, the proposed patch (which I will probably accept before
the freeze of forky), says "This makes the package reproducible".

That's probably not a fair way to explain the issue. Most probably the
package was indeed reproducible, but the infrastructure "forgot" to
record essential information to actually reproduce it.

(Side note: Maybe I will just change the comment in the patch to
something like "The package may now be reproduced by
reproduce.debian.net").

Ok, I admit that I did not think about that.

Let's assume that we can't guess the fakeroot version of a package
which was already built.

Could not we at least start recording the fakeroot version so that
from now on packages that rightfully use it may be reproduced?

That way a simple rebuild (which could be even a binNMU) would
suddenly make the package reproducible again.

(I fear that I know what your reply to this could be: We would
be adding such field to be used by only a handful of packages,
which could be switched to debputy anyway. Did I guess right? :-)

Well, as a workaround, we can agree that packages in bookworm should be
built in bookworm.
and sbuild installed fakeroot after detecting that it was required for
the build of this specific package.

Does this mean that getting rid of fakeroot is not really a
pre-requisite for achieving reproducible-builds?

If yes: What special feature does procmail have that makes its usage
of fakeroot troublesome regarding reproducibility, at the same time
other packages using fakeroot are reproducible?

Even if the proposed patch is ok and most probably I will apply for
forky, I'm really curious about this. I would feel better if I know
the reasons we do thing the way we do.

Thanks.

* Santiago Vila <sanvila@debian.org> [2026-06-25 20:03]:

Yes.

I don't know.

Cheers Jochen