reprotest: use a virtual server backend other than null

Currently, reprotest uses the default null backend, that seems OK for unstable. However, for other releases, specially old stable releases, this causes issues, especially with dependencies and incompatibilities. See for example this in the LTS Team's pipeline fork: https://salsa.debian.org/lts-team/pipeline/-/jobs/5694530#L2141

There are probably similar issues with packages from bookworm or bullseye.

mentioned in commit lts-team/pipeline@d148c8c1

mentioned in commit lts-team/pipeline@b64b59be

added Accepting MRs label

mentioned in commit santiago/pipeline@12338328

mentioned in issue #57

mentioned in commit lts-team/pipeline@d3af9c75

mentioned in commit lts-team/pipeline@5f6c05e3

@holger, @vagrant, may I ask you if you have any advice about what reprotest virtualization backend to switch to? Salsa CI currently relies on null, and it is causing issues. From the supported virtualization backends I can read in reprotest(1), I would say that chroot, lxc and schroot could be valid options for Salsa CI. My first choice would be schroot, but I wonder if that is too complex, and a simpler chroot would be enough. I would also dismiss lxc at a first time, since I don't think we need that complexity either.

Anyway, your thoughts are welcome.

I will admit the only reprotest backend I ever use is the null backend as a non-root user(or as a user-namespaced root user), which limits some of the functionality. I typically have to use something like:

reprotest --vary=-user_group,-hostname,-fileordering

If I am remembering correctly...

Really, we have to re-sync reprotest with current autopkgtest code and get it up to date to be able to work with modern backends:

https://bugs.debian.org/836520

Which just goes to show how barely maintained reprotest is. :(

I wrote an sbuild configuration that uses the unshare mode as non-root that calls reprotest from sbuild --finished-build-commands and works around some of those limitations:

https://salsa.debian.org/reproducible-builds/sbuild-unshare-reprotest

But it is pretty much just a proof of concept that could use a lot of polish(e.g. to be able to dynamically enable/disable variations and such; right now it is just hardcoded). It works well enough it has been the primary way I do reproducibility tests on my local machines.

Not sure how useful it would be to adapt for salsa-ci.

It might be feasible to switch the reprotest build to compare against the artifacts produced in other salsa-ci phases(?), and only run a single build from reprotest, using the other artifacts as a reference. There are some other features in current reprotest that might make that more feasible than in the past, such as being able to specify the build path.

Well, hopefully something is useful in all that rambling, I know I veered perhaps a little off topic. :)

Thanks for the feedback!

I think I will give schroot a try :-). If I remember correctly, unshare won't work correctly on top of the salsa runners.

It might be feasible to switch the reprotest build to compare against the artifacts produced in other salsa-ci phases(?)...

That would be awesome, and there is actually a related issue: #118. Please note that salsa ci has disable the build_path variation by default.

mentioned in issue #399