Future of reprotest and alternatives (sbuild wrapper)?

[Vagrant Cascadian]

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.

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


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... :)


live well,
  vagrant
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <http://lists.reproducible-builds.org/pipermail/rb-general/attachments/20230227/a77bf922/attachment.sig>