.\" DO NOT MODIFY THIS FILE! It was generated by help2man 1.49.3. .TH REPROTEST "1" "April 2024" "reprotest 0.7.27" "User Commands" .SH NAME reprotest \- Build packages and check them for reproducibility. .SH SYNOPSIS .nf \fBreprotest\fR \-\-help\ [] \fBreprotest\fR [options] [\-c ] [] \ [-- [ ...]] \fBreprotest\fR [options] [\-s ] [] \ [-- [ ...]] .fi .\" Man page generated from reStructuredText. . . .nr rst2man-indent-level 0 . .de1 rstReportMargin \\$1 \\n[an-margin] level \\n[rst2man-indent-level] level margin: \\n[rst2man-indent\\n[rst2man-indent-level]] - \\n[rst2man-indent0] \\n[rst2man-indent1] \\n[rst2man-indent2] .. .de1 INDENT .\" .rstReportMargin pre: . RS \\$1 . nr rst2man-indent\\n[rst2man-indent-level] \\n[an-margin] . nr rst2man-indent-level +1 .\" .rstReportMargin post: .. .de UNINDENT . RE .\" indent \\n[an-margin] .\" old: \\n[rst2man-indent\\n[rst2man-indent-level]] .nr rst2man-indent-level -1 .\" new: \\n[rst2man-indent\\n[rst2man-indent-level]] .in \\n[rst2man-indent\\n[rst2man-indent-level]]u .. .TH "" "" "" .SH DESCRIPTION .sp reprotest builds the same source code twice in different environments, and then checks the binaries produced by each build for differences. If any are found, then \fBdiffoscope(1)\fP (or if unavailable then \fBdiff(1)\fP) is used to display them in detail for later analysis. .sp See the \fBCOMMAND\-LINE EXAMPLES\fP section further below to get you started, as well as more detailed explanations of all the command\-line options. The same information is also available in \fB/usr/share/doc/reprotest/README.rst\fP or similar. .\" the below hack gets rid of the python "usage" message in favour of the .\" the synopsis we manually defined in doc/$(PACKAGE).h2m.0 .\" .SS positional arguments: .TP source_root|build_command The first argument is treated either as a source_root (see the \fB\-s\fR option) or as a build\-command (see the \fB\-c\fR option) depending on what it looks like. Most of the time, this should "just work"; but specifically: if neither \fB\-c\fR nor \fB\-s\fR are given, then: if this exists as a file or directory and is not "auto", then this is treated as a source_root, else as a build_command. Otherwise, if one of \fB\-c\fR or \fB\-s\fR is given, then this is treated as the other one. If both are given, then this is a syntax error and we exit code 2. .TP artifact_pattern Build artifact to test for reproducibility. May be a shell pattern such as "*.deb *.changes". .TP virtual_server_args Arguments to pass to the virtual_server, the first argument being the name of the server. If this itself contains options (of the form \fB\-xxx\fR or \fB\-\-xxx\fR), or if any of the previous arguments are omitted, you should put a "\-\-" between these arguments and reprotest's own options. Default: "null", to run directly in \fI\,/tmp\/\fP. Choices: chroot, lxc, lxd, null, qemu, schroot, ssh .SS "options:" .TP \fB\-\-help\fR [VIRTUAL_SERVER_NAME] Show this help message and exit. When given an argument, show instead the help message for that virtual server and exit. .TP \fB\-f\fR CONFIG_FILE, \fB\-\-config\-file\fR CONFIG_FILE File to load configuration from. (Default: None) .SS "basic options:" .TP \fB\-\-verbosity\fR VERBOSITY An integer. Control which messages are displayed (0: quiet (warning/error only), 1: info, 2: debug). .TP \fB\-v\fR, \fB\-\-verbose\fR Like \fB\-\-verbosity\fR, but given multiple times without arguments. .TP \fB\-\-host\-distro\fR HOST_DISTRO The distribution that will run the tests (Default: None) .TP \fB\-s\fR PATH, \fB\-\-source\-root\fR PATH Root of the source tree, that is copied to the virtual server and made available during the build. If a file is given here, then its parent directory is used instead. Default: "." (current working directory). .TP \fB\-\-source\-pattern\fR PATTERNS Shell glob pattern to restrict the files in that are made available during the build. Default: empty, i.e. copy the whole directory with no restrictions. .TP \fB\-c\fR COMMANDS, \fB\-\-build\-command\fR COMMANDS Build command to execute. If this is "auto" then reprotest will guess how to build the given source_root, in which case various other options may be automatically set\-if\-unset. Default: auto .TP \fB\-\-store\-dir\fR DIRECTORY Save the artifacts in this directory, which must be empty or non\-existent. Otherwise, the artifacts will be deleted and you only see their hashes (if reproducible) or the diff output (if not). See also \fB\-\-no\-clean\-on\-error\fR. .TP \fB\-\-variations\fR VARIATIONS Build variations to test as a comma\-separated list of variation names. Default is "+all", equivalent to "+environment, +build_path, +kernel, +aslr, +num_cpus, +time, +user_group, +fileordering, +domain_host, +home, +locales, +exec_path, +timezone, +umask", testing all available variations. See the man page section on VARIATIONS for more advanced syntax options, including tweaking how certain variations work. .TP \fB\-\-vary\fR VARIATIONS Like \fB\-\-variations\fR, but appends to previous \fB\-\-vary\fR values instead of overwriting them. The last value set for \fB\-\-variations\fR is treated implicitly as the zeroth \fB\-\-vary\fR value. .TP \fB\-\-extra\-build\fR VARIATIONS Perform another build with the given VARIATIONS (which may be empty) to be applied on top of what was given for \fB\-\-variations\fR and \fB\-\-vary\fR. Each occurrence of this flag specifies another build, so e.g. given twice this will make reprotest perform 4 builds in total. .TP \fB\-\-auto\-build\fR Automatically perform builds to try to determine which specific variations cause unreproducibility, potentially up to and including the ones specified by \fB\-\-variations\fR and \fB\-\-vary\fR. Conflicts with \fB\-\-extra\-build\fR. .TP \fB\-\-env\-build\fR Automatically perform builds to try to determine which specific environment variables cause unreproducibility, based on a hard\-coded whitelist and blacklist. You probably want to set \fB\-\-vary\fR=\fI\,\-all\/\fR as well when setting this flag; see the man page for details. Conflicts with \fB\-\-extra\-build\fR and \fB\-\-autobuild\fR. .TP \fB\-\-min\-cpus\fR NUM Minimum CPUs to use when fixing num_cpus. Default: 1. .SS "diff options:" .TP \fB\-\-diffoscope\-arg\fR ARG Give extra arguments to diffoscope when running it. Default: ['\-\-exclude\-directory\-metadata=yes']. Arguments are {}\-formatted with: {0} the name of each experiment run, and {1} the path of the experiment output. .TP \fB\-\-diffoscope\fR PATH Path to diffoscope(1). Default: diffoscope .TP \fB\-\-no\-diffoscope\fR Don't run diffoscope; instead run diff(1). Useful if you don't want to install diffoscope and/or just want a quick answer on whether the reproduction was successful or not, without spending time to compute all the detailed differences. .SS "advanced options:" .TP \fB\-\-testbed\-pre\fR COMMANDS Shell commands to run before starting the test bed, in the context of the current system environment. This may be used to e.g. compute information needed by the build, where the computation needs packages you don't want installed in the testbed itself. .TP \fB\-\-testbed\-init\fR COMMANDS Shell commands to run after starting the test bed, before running anything else. Used to e.g. install disorderfs in a chroot. .TP \fB\-\-testbed\-build\-pre\fR COMMANDS Shell commands to run before each build, even before applying variations for that build. Used to e.g. install build\-dependencies. .TP \fB\-\-auto\-preset\-expr\fR PYTHON_EXPRESSION This may be used to transform the presets returned by the auto\-detection feature. The value should be a python expression that transforms the _ variable, which is of type reprotest.presets.ReprotestPreset. See that class's documentation for ways you can write this expression. Default: _ .TP \fB\-\-no\-clean\-on\-error\fR Don't clean the virtual_server if there was an error. Useful for debugging but will leave cruft on your system depending on the virtual_server used; we hint about some but there may be others. .TP \fB\-\-dry\-run\fR Don't run the builds, just print what would happen. .TP \fB\-\-print\-sudoers\fR Print a sudoers file for passwordless operation using the given \fB\-\-variations\fR, useful for user_group.available, domain_host.use_sudo. .TP \fB\-\-control\-build\fR CONTROL_BUILD Override control build with artifacts located on this path. Allows reusing previous build as baseline. .TP \fB\-\-append\-build\-command\fR COMMANDS Append arguments to the build command .SH "COMMAND-LINE EXAMPLES" .sp The easiest way to run reprotest is via our presets: .INDENT 0.0 .INDENT 3.5 .sp .EX # Build the current directory in a null server (/tmp) $ reprotest . $ reprotest . \-vv \-\- null \-d # for very verbose output # Build a make\-based program $ reprotest \(dqmake clean && make\(dq mybinary # Build a Debian package $ apt\-get source hello && cd hello\-2.10 $ reprotest auto \-\- null # Build a Debian package and disable some variations $ reprotest \-\-vary=\-user_group,\-domain_host,\-fileordering auto \-\- null # Build the given Debian source package in an schroot # See https://wiki.debian.org/sbuild for instructions on setting that up. $ reprotest reprotest_0.3.3.dsc \-\- schroot unstable\-amd64\-sbuild # Build the given RPM source package # Only null server (/tmp) is currently supported. $ reprotest reprotest\-0.7.16.src.rpm # Build the given RPM source package and automatically install dependencies $ reprotest \-\-testbed\-build\-pre \(aqdnf \-y builddep ./*.src.rpm\(aq reprotest\-0.7.16.src.rpm .EE .UNINDENT .UNINDENT .sp Currently, we only support this for Debian and RPM based packages, but are keen on adding more. If we don\(aqt have knowledge on how to build your file or directory, you can send a patch to us on adding this intelligence \- see the reprotest.presets python module, and adapt the existing logic. .sp In the meantime, you can use other parts of the CLI to build arbitrary things. You\(aqll need to give two mandatory arguments, the build command to run and the build artifact file/pattern to test after running the build. For example: .INDENT 0.0 .INDENT 3.5 .sp .EX $ reprotest \(aqpython3 setup.py bdist\(aq \(aqdist/*.tar.gz\(aq .EE .UNINDENT .UNINDENT .sp This runs the command on \fB\&.\fP, the current working directory. To run it on a project located elsewhere: .INDENT 0.0 .INDENT 3.5 .sp .EX $ reprotest \-s ../path/to/other/project \(aqpython3 setup.py bdist\(aq \(aqdist/*.tar.gz\(aq $ reprotest \-c \(aqpython3 setup.py bdist\(aq ../path/to/other/project \(aqdist/*.tar.gz\(aq .EE .UNINDENT .UNINDENT .sp These two invocations are equivalent; you can pick the most convenient one for your use\-case. When using these from a shell: .INDENT 0.0 .INDENT 3.5 .INDENT 0.0 .IP \(bu 2 If the build command has spaces, you will need to quote them, e.g. \fBreprotest \(dqdpkg\-buildpackage \-b \-\-no\-sign\(dq [..]\fP\&. .IP \(bu 2 If you want to use several build artifact patterns, or if you want to use shell wildcards as a pattern, you will also need to quote them, e.g. \fBreprotest [..] \(dq*.tar.gz *.tar.xz\(dq\fP\&. .IP \(bu 2 If your build artifacts have spaces in their names, you will need to quote these twice, e.g. \fB\(aq\(dqa file with spaces.gz\(dq\(aq\fP for a single artifact or \fB\(aq\(dqdir 1\(dq/* \(dqdir 2\(dq/*\(aq\fP for multiple patterns. .UNINDENT .UNINDENT .UNINDENT .sp To get more help for the CLI, including documentation on optional arguments and what they do, run: .INDENT 0.0 .INDENT 3.5 .sp .EX $ reprotest \-\-help .EE .UNINDENT .UNINDENT .SH "RUNNING IN A VIRTUAL SERVER" .sp You can also run the build inside what is called a \(dqvirtual server\(dq. This could be a container, a chroot, etc. You run them like this: .INDENT 0.0 .INDENT 3.5 .sp .EX $ reprotest \(aqpython3 setup.py bdist_wheel\(aq \(aqdist/*.whl\(aq \-\- qemu /path/to/qemu.img $ reprotest \(aqdpkg\-buildpackage \-b \-\-no\-sign\(aq \(aq../*.deb\(aq \-\- schroot unstable\-amd64 .EE .UNINDENT .UNINDENT .sp There are different server types available. See \fB\-\-help\fP for a list of them, which appears near the top, in the \(dqvirtual_server_args\(dq part of the \(dqpositional arguments\(dq section. .sp For each virtual server (e.g. \(dqschroot\(dq), you see which extra arguments it supports: .INDENT 0.0 .INDENT 3.5 .sp .EX $ reprotest \-\-help schroot .EE .UNINDENT .UNINDENT .sp When running builds inside a virtual server, you will probably have to give extra commands, in order to set up your build dependencies inside the virtual server. For example, to take you through what the \(dqDebian directory\(dq preset would look like, if we ran it using the full CLI: .INDENT 0.0 .INDENT 3.5 .sp .EX # \(dqDebian directory\(dq preset $ reprotest . \-\- schroot unstable\-amd64\-sbuild # This is exactly equivalent to this: $ reprotest \-c auto . \-\- schroot unstable\-amd64\-sbuild # In the non\-preset full CLI, this is roughly similar to: $ reprotest \e \-\-testbed\-init \(aqapt\-get \-y \-\-no\-install\-recommends install \e disorderfs faketime locales\-all sudo util\-linux; \e test \-c /dev/fuse || mknod \-m 666 /dev/fuse c 10 229; \e test \-f /etc/mtab || ln \-s ../proc/self/mounts /etc/mtab\(aq \e \-\-testbed\-build\-pre \(aqapt\-get \-y \-\-no\-install\-recommends build\-dep ./\(aq \e \-\-build\-command \(aqdpkg\-buildpackage \-\-no\-sign \-b\(aq \e . \e \(aq../*.deb\(aq \e \-\- \e schroot unstable\-amd64\-sbuild .EE .UNINDENT .UNINDENT .sp The \fB\-\-testbed\-init\fP argument is needed to set up basic tools, which reprotest needs in order to make the variations in the first place. This should be the same regardless of what package is being built, but might differ depending on what virtual_server is being used. .sp Next, we have \fB\-\-testbed\-build\-pre\fP, then \fB\-\-build\-command\fP (or \fB\-c\fP). For our Debian directory, we install build\-dependencies using \fBapt\-get\fP, then we run the actual build command itself using \fBdpkg\-buildpackage(1)\fP\&. .sp Then, we have the \fBsource_root\fP and the \fBartifact_pattern\fP\&. For reproducibility, we\(aqre only interested in the binary packages. .sp Finally, we specify that this is to take place in the \(dqschroot\(dq virtual_server with arguments \(dqunstable\-amd64\-sbuild\(dq. .sp Of course, all of this is a burden to remember, if you must run the same thing many times. So that is why adding new presets for new package types would be good. .sp Here is a more complex example. It tells reprotest to store the build products into \fB\&./artifacts\fP to analyse later; and also tweaks the \(dqDebian dsc\(dq preset so that it uses our \fI\%experimental toolchain\fP: .INDENT 0.0 .INDENT 3.5 .sp .EX $ reprotest \-\-store\-dir=artifacts \e \-\-auto\-preset\-expr \(aq_.prepend.testbed_init(\(dqapt\-get install \-y wget; \e echo deb http://reproducible.alioth.debian.org/debian/ ./ >> /etc/apt/sources.list; \e wget \-q \-O\- https://reproducible.alioth.debian.org/reproducible.asc | apt\-key add \-; \e apt\-get update; apt\-get upgrade \-y; \(dq)\(aq \e ./bash_4.4\-4.0~reproducible1.dsc \e \-\- \e schroot unstable\-amd64\-sbuild .EE .UNINDENT .UNINDENT .sp Alternatively, you can clone your unstable\-amd64\-sbuild chroot, add our repo to the cloned chroot, then use this chroot in place of \(dqunstable\-amd64\-sbuild\(dq. That would allow you to omit the long \fB\-\-auto\-preset\-expr\fP flag above. .SH "CONFIG FILE" .sp You can also give options to reprotest via a config file. This is a time\-saving measure similar to \fBauto\fP presets; the difference is that these are more suited for local builds that are suited to your personal purposes. (You may use both presets and config files in the same build.) .sp The config file takes exactly the same options as the command\-line interface, but with the additional restriction that the section name must match the ones given in the \-\-help output. Whitespace is allowed if and only if the same command\-line option allows whitespace. Finally, it is not possible to give positional arguments via this mechanism. .sp Reprotest by default does not load any config file. You can tell it to load one with the \fB\-\-config\-file\fP or \fB\-f\fP command line options. If you give it a directory such as \fB\&.\fP, it will load \fB\&.reprotestrc\fP within that directory. .sp A sample config file is below: .INDENT 0.0 .INDENT 3.5 .sp .EX \[char91]basics] verbosity = 1 variations = environment build_path user_group.available+=builduser:builduser fileordering home kernel locales exec_path time timezone umask store_dir = /home/foo/build/reprotest\-artifacts \[char91]diff] diffoscope_arg = \-\-debug .EE .UNINDENT .UNINDENT .SH "ANALYSING DIFF OUTPUT" .sp Normally when diffoscope compares directories, it also compares the metadata of files in those directories \- file permissions, owners, and so on. .sp However depending on the circumstance, this filesystem\-level metadata may or may not be intended to be distributed to other systems. For example: (1) for most distros\(aq package builders, we don\(aqt care about the metadata of the output package files; only the file contents will be distributed to other systems. On the other hand, (2) when running something like \fImake install\fP, we \fIdo\fP care about the metadata, because this is what will be recreated on another system. .sp In developing reprotest, our experience has been that case (1) is more common and so we pass \fB\-\-exclude\-directory\-metadata=yes\fP by default to diffoscope. If you find that you are using reprotest for case (2) then you should pass \fB\-\-diffoscope\-args=\-\-exclude\-directory\-metadata=no\fP to reprotest, to tell diffoscope to not ignore the metadata since it will be distributed and should therefore be reproducible. Otherwise, you may get a false\-positive result. .SH VARIATIONS .sp The \-\-vary and \-\-variations flags in their simple forms, are a comma\-separated list of variation names that indicate which variations to apply. The full list of names is given in the \-\-help text for \-\-variations. .nf In full detail, the flags are a comma\-separated list of actions, as follows: +$variation (or $variation with no explicit operator) \-$variation .in +2 Enable or disable a variation .in -2 @$variation .in +2 Enable a variation, resetting its parameters (see below) to default values. .in -2 $variation.$param=$value $variation.$param+=$value $variation.$param\-=$value .in +2 Set/add/remove $value as/to/from the current value of the $param parameter of the $variation. .in -2 $variation.$param++ $variation.$param\-\- .in +2 Increment/decrement the value of the $param parameter of the $variation. .in -2 .fi .sp .sp Most variations do not have parameters, and for them only the + and \- operators are relevant. The variations that accept parameters are: .INDENT 0.0 .TP .B build_path.path The path to use for the experiment builds when build path variations are enabled. This needs to be in a location writeable to the user used for running the build. This is (somewhat ironically) useful to normalize the build path when used in conjunction with \-\-control\-build to compare against an existing build not performed with reprotest. .TP .B domain_host.use_sudo An integer, whether to use sudo(1) together with unshare(1) to change the system hostname and domainname. 0 means don\(aqt use sudo; any non\-zero value means to use sudo. Default is 0, however this is not recommended and make may your build fail, see \(dqVarying the domain and host names\(dq for details. .TP .B environment.variables A semicolon\-separated ordered set, specifying environment variables that reprotest should try to vary. Default is \(dqREPROTEST_CAPTURE_ENVIRONMENT\(dq. Supports regex\-based syntax e.g. .INDENT 7.0 .IP \(bu 2 PID=\ed{1,6} .IP \(bu 2 HOME=(/\ew{3,12}){1,4} .IP \(bu 2 (GO|PYTHON|)PATH=(/\ew{3,12}){1,4}(:(/\ew{3,12}){1,4}){0,4} .UNINDENT .sp Special cases: .INDENT 7.0 .IP \(bu 2 $VARNAME= (empty RHS) to tell reprotest to delete the variable .IP \(bu 2 $VARNAME=.{0} to tell reprotest to actually set an empty value .IP \(bu 2 \ex2c and \ex3b to match or generate , and ; respectively. .UNINDENT .TP .B user_group.available A semicolon\-separated ordered set, specifying the available user+group combinations that reprotest can \fBsudo(1)\fP to. Default is empty, in which case the variation is a no\-op, and you\(aqll see a warning about this. Each user+group should be given in the form $user:$group where either component can be omitted, or else if there is no colon then it is interpreted as only a $user, with no $group variation. .TP .B time.faketimes A semicolon\-separated ordered set, specifying possible \fBfaketime(1)\fP time descriptors to use. Default is empty, in which case we choose a time: either now (if the latest file\-modtime in \fBsource_root\fP is older than 398 days) or more than 398 days in the future. .sp Note that the clock continues to run during the build. It is possible for \fBfaketime(1)\fP to freeze it, but we don\(aqt yet support that yet; it has a higher chance of causing your build to fail or misbehave. .TP .B locales.locale A semicolon\-separated list one or more locales to test when performing locales variations. If multiple locales are specified, one will be chosen at random. Locales with different properties than en_US.UTF\-8 are fr_CH.UTF\-8, ru_RU.CP1251, kk_KZ.RK1048 or zh_CN. Default is et_EE.UTF\-8 if unspecified. .TP .B num_cpus.cpus A semicolon\-separated list of one or more numeric values to select the number of cpus used when performing num_cpus variations. .UNINDENT .sp The difference between \-\-vary and \-\-variations is that the former appends onto previous values but the latter resets them. Furthermore, the last value set for \-\-variations is treated as the zeroth \-\-vary argument. For example: .INDENT 0.0 .INDENT 3.5 .sp .EX reprotest \-\-vary=\-user_group .EE .UNINDENT .UNINDENT .sp means to vary +all (the default value for \-\-variations) and \-user_group (the given value for \-\-vary), whereas: .INDENT 0.0 .INDENT 3.5 .sp .EX reprotest \-\-variations=\-all,locales \-\-variations=home,time \-\-vary=timezone \-\-vary=\-time .EE .UNINDENT .UNINDENT .sp means to vary home, time (the last given value for \-\-variations), timezone, and \-time (the given multiple values for \-\-vary), i.e. home and timezone. .SH "NOTES ON VARIATIONS" .sp reprotest tries hard to perform variations without assuming it has full root access to the system. It also assumes other software may be running on the same system, so it does not perform system\-level modifications that would affect other processes. Due to these assumptions, some variations are implemented using hacks at various levels of dirtiness, which are documented below. .sp We will hopefully lift these assumptions for certain virtual_server contexts, in future. That would likely allow for smoother operation in those contexts. The assumptions will remain for the \(dqnull\(dq (default) virtual_server however. .SS Number of CPUs .sp The control build uses only 1 CPU in order to try to reduce nondeterminism that might exist due to multithreading or multiprocessing. If you are sure your build is not affected by this (and good builds ought not to be), you can give \-\-min\-cpus=99999 to use all available cores for both builds. .SS Domain or host .sp Doing this without sudo \fImay\fP result in your build failing. .sp Failure is likely if your build must do system\-related things \- as opposed to only processing bits and bytes. This is because it runs in a separate namespace where your non\-privileged user looks like it is \(dqroot\(dq, but this prevents the filesystem from recognising files owned by the real \(dqroot\(dq user, amongst other things. This is a limitation of unshare(1) and it is not possible work around this in reprotest without heavy effort. .sp Therefore, it is recommended to run this variation with use_sudo=1. To avoid password prompts, see the section \(dqAvoid sudo(1) password prompts\(dq below. .sp When running inside a virtual\-server: .sp The non\-sudo method fails with \(dqOperation not permitted\(dq, even if you edited \fB/proc/sys/kernel/unprivileged_userns_clone\fP\&. The cause is currently unknown. .sp The sudo method works only if you take measures to avoid sudo password prompts, since containers don\(aqt have a method to input this. .SS User or group .sp If you also vary fileordering at the same time (this is the case by default), each user you use needs to be in the \(dqfuse\(dq group. Do that by running \fIusermod \-aG fuse $OTHERUSER\fP as root. .sp To avoid sudo(1) password prompts, see the section \(dqAvoid sudo(1) password prompts\(dq below. .SS Time .sp The \(dqtime\(dq variation uses \fBfaketime(1)\fP which \fIsometimes\fP causes weird and hard\-to\-diagnose problems. In the past, this has included: .INDENT 0.0 .IP \(bu 2 builds taking an infinite amount of time; though this should be fixed in recent versions of reprotest. .IP \(bu 2 builds with implausibly huge differences caused by ./configure scripts producing different results with and without faketime. This still affects bash and probably certain other packages using autotools. .IP \(bu 2 builds accessing the network failing due to certificate expiration errors and/or other time\-related security errors. (Transparent builds of FOSS should not access the network in the first place, but it\(aqs outside of reprotest\(aqs scope to audit or prevent this.) .UNINDENT .sp If you see a difference that you really think should not be there, try passing \fB\-\-variations=\-time\fP to reprotest, and/or check our results on \fI\%https://tests.reproducible\-builds.org/\fP which use a different (more reliable) mechanism to vary the system time. .SS Kernel .sp The \(dqkernel\(dq variation is currently not working for RPM based packages and other build process requiring \fIldconfig\fP\&. While building with this variation enabled, \fIldconfig\fP complains about \fIFATAL: kernel too old\fP and aborts the build. .SH "AVOID SUDO(1) PASSWORD PROMPTS" .sp There is currently no good way to do this. The following is an EXPERIMENTAL solution and is brittle and unclean. You will have to decide for yourself if it\(aqs worth it for your use\-case: .INDENT 0.0 .INDENT 3.5 .sp .EX $ reprotest \-\-print\-sudoers \e \-\-variations=user_group.available+=guest\-builder,domain_host.use_sudo=1 \e | sudo EDITOR=tee visudo \-f /etc/sudoers.d/local\-reprotest .EE .UNINDENT .UNINDENT .sp Make sure you set the variations you actually want to use. Obviously, don\(aqt pick privileged users for this purpose, such as root. .sp (Simplifying the output using wildcards, would open up passwordless access to chown anything on your system, because wildcards here match whitespace. I don\(aqt know what the sudo authors were thinking.) .sp No, this is not nice at all \- suggestions and patches welcome. .sp If you want to use this in a virtual server such as a chroot, you\(aqll need to copy (or mount or otherwise map) the resulting sudoers file into your chroot. .sp For example, for an schroot, you should (1) login to the source schroot and create an empty file \fI/etc/sudoers.d/local\-reprotest\fP (this is important) and then (2) add the line: .INDENT 0.0 .INDENT 3.5 /etc/sudoers.d/local\-reprotest /etc/sudoers.d/local\-reprotest none bind 0 0 .UNINDENT .UNINDENT .sp to your schroot\(aqs fstab. .\" Generated by docutils manpage writer. .