Future of reprotest and alternatives (sbuild wrapper)?

[Marek Marczykowski-Górecki]

On Mon, Feb 27, 2023 at 06:11:16PM -0800, Vagrant Cascadian wrote:
> I have managed to make some changes to reprotest now and again, but as a
> whole, cannot say I can wrap my head around the code enough to maintain
> it.
> 
> It also contains forks of some autopkgtest code, last updated in 2017,
> if I am reading the git logs correctly. It is apparently no longer
> working with current versions of qemu with the qemu backends:
> 
>   https://bugs.debian.org/1001250
> 
> I think it was forked largely to remove Debian-isms in the autopkgtest
> code, which looks to be only packaged on Debian derivatives:
> 
>   https://repology.org/project/autopkgtest/versions
> 
> I am not sure how widespread reprotest is used outside of Debian, though
> it has support for Debian, Arch, Fedora and Guix.

FWIW We use it in our CI to test Debian and Fedora packages.
Frédéric maintains Fedora package for it: https://src.fedoraproject.org/rpms/reprotest

> Without a maintainer, reprotest can limp along, occasionally gaining a
> feature or fixing a bug... but it could really use someone actively
> working on it! Not sure what the future looks like with the status
> quo...
> 
> Are there other tools used on other distros to do similar sorts of
> things? Basically reproducibility fuzz-testing... I know Bernard uses
> some tooling for openSUSE...

Indeed it would be interesting to learn what others use.

> The last few days I have been taking a look at using sbuild (which is
> very specific to .deb package building) to implement some of the
> functionality that reprotest does. I am certainly not the first person
> to have explored or toyed around with this idea:
> 
>   https://bugs.debian.org/847805
>   https://bugs.debian.org/875445
> 
> ... and the builds at https://tests.reproducible-builds.org/debian do
> something similar with pbuilder instead of sbuild.
> 
> Some new developments in sbuild, namely using the "unshare" mode, make
> it a little more compelling to me than before, as it is possible to
> build without requiring root access on modern Debian systems, blocking
> network access to the build, and is fairly easy to set up a working
> environment (e.g. mmdebstrap can create a tarball without root
> privledges). I know for some distros, these sorts of features are just
> integrated into standard build tooling, but this is Debian!
> 
> Basically, one needs to generate an sbuild.conf that implements a few
> variations, as some options are not possible from the commandline
> (although many are!):
> 
>   $chroot_mode = 'unshare';
>   $run_lintian = 0;
>   $build_env_cmnd = '/usr/local/bin/unreproducibility';
>   $manual_depends = ['faketime'];
>   $external_commands = {
>       "chroot-setup-commands" => [
>           # /bin/sh -> /bin/bash or /bin/dash
>           ['ln', '-svf', '/bin/bash', '/bin/sh'],
>           # /usr/share/zoneinfo/Etc/GMT-14 vs. GMT+12
>           ['ln', '-svf', '/usr/share/zoneinfo/Etc/GMT-14', '/etc/localtime'],
>           # create /usr/local/bin/unreproducibility
>           [ 'printf "#!/bin/sh -x\nsetarch linux32 --uname-2.6 faketime \'+397 days\' \$@" > /usr/local/bin/unreproducibility' ],
>           [ 'chmod', '+x', '/usr/local/bin/unreproducibility' ],
>           [ 'cat', '/usr/local/bin/unreproducibility' ],
>     ],
>   };
>   $build_path = '/build/firstbuild/';
>   # first build user, blocked by: https://bugs.debian.org/1032046
>   #$build_user = 'user7777';
> 
> And then a second build with a different sbuild.conf with different
> variations, as needed... and then fire up diffoscope and compare the
> two. A wrapper around sbuild like this seems fairly maintainable to me,
> at least in theory, but maybe I am just naive and unimaginative... :)

That's interesting approach, I guess similar could also be done with
other build tools (like mock under Fedora). But personally, I find main
value in reprotest that it already has many variations implemented (so,
I don't need to re-invent that list), and allows easily enable/disable
them individually, including automatically looking which one affects
reproducibility (--auto-build).


-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.reproducible-builds.org/pipermail/rb-general/attachments/20230228/5a6d1070/attachment.sig>