setarch is exercised unconditionally whether kernel variation is enabled or disabled

We are trying to add Reproducible builds to our .deb and .rpm packages on Apache Arrow. We already use reprotest for our source code distribution.

We build our packages using a Docker container and when trying to use reprotest I get the following issue:

setarch: failed to set personality to x86_64: Operation not permitted

I understand that this is related to the following issue on Docker itself: https://github.com/moby/moby/issues/43011#issuecomment-979172601

The problem is that even if I try to disable the kernel variation vary=-kernel I get the error. This is due to setarch being exercised unconditionally whether the kernel variation is enabled or disabled here: https://salsa.debian.org/reproducible-builds/reprotest/-/blob/master/reprotest/build.py#L304-307

In order to bypass the issue and being able to run reprotest and continue with the build I am temporarily patching reprotest for our tests with:

diff --git a/reprotest/build.py b/reprotest/build.py
index 52eff03..fa5140c 100644
--- a/reprotest/build.py
+++ b/reprotest/build.py
@@ -302,7 +302,7 @@ def home(ctx, build, vary):
 def kernel(ctx, build, vary):
     _ = build
     if not vary:
-        _ = _.append_setup_exec_raw('SETARCH_ARCH=$(uname -m)')
+        return _
     else:
         _ = _.append_setup_exec_raw('SETARCH_ARCH=$(for a in $(setarch --list); do setarch $a true && echo $a || true; done)')
         # Perform realistic shuffling of architectures depending

Could there be a possibility to make reprotest not try to unconditionally call setarch if the kernel variation is disabled? Either an option to completely disable the setarch call (via env or flag) or something like what we are doing on the patch, if kernel is disabled do not call setarch.

I am new to the project so I might be missing context on why this is exercised if the kernel variation is disabled. I am happy to help provide a PR if this could help but I would appreciate some feedback on what would be the approach preferred by the project maintainers.

Thanks for the work you are doing.