نام (NAME)

reprotest - ساخت بسته‌ها و بررسی آن‌ها از نظر تکرارپذیری

خلاصه دستور (SYNOPSIS)

reprotest --help [<virtual_server_name>]
reprotest [options] [-c <build_command>] <source_root> [<artifact_pattern>] [-- <virtual_server_args> [<virtual_server_args> ...]]
reprotest [options] [-s <source_root>] <build_command> [<artifact_pattern>] [-- <virtual_server_args> [<virtual_server_args> ...]]

""

توضیحات (DESCRIPTION)

ابزار reprotest همان کد منبع را دو بار در محیط‌های متفاوت می‌سازد، و سپس فایل‌های باینری تولیدشده در هر ساخت را برای یافتن تفاوت‌ها بررسی می‌کند. در صورت یافتن هرگونه تفاوت، از diffoscope(1) (یا در صورت عدم دسترسی از diff(1)) برای نمایش باجزئیات آن‌ها جهت تحلیل‌های بعدی استفاده می‌شود.

برای شروع کار و همچنین مشاهدهٔ توضیحات دقیق‌تر دربارهٔ همهٔ گزینه‌های خط فرمان، بخش COMMAND-LINE EXAMPLES را در ادامه ببینید. همین اطلاعات در /usr/share/doc/reprotest/README.rst یا موارد مشابه نیز در دسترس است.

source_root|build_command: آرگومان نخست بسته به ساختارش، یا به عنوان یک source_root (گزینهٔ -s را ببینید) یا به عنوان یک build-command (گزینهٔ -c را ببینید) تلقی می‌شود. در بیشتر موارد، این سازوکار باید خودبه‌خود و بدون مشکل کار کند؛ اما به‌طور دقیق‌تر: اگر هیچ‌یک از گزینه‌های -c یا -s مشخص نشده باشند، در صورتی که این آرگومان به صورت یک فایل یا دایرکتوری وجود داشته باشد و مقدار آن "auto" نباشد، به عنوان source_root در نظر گرفته می‌شود، وگرنه به عنوان build_command شناخته خواهد شد. در غیر این صورت، اگر یکی از گزینه‌های -c یا -s داده شده باشد، این آرگومان به عنوان دیگری در نظر گرفته می‌شود. اگر هر دو گزینه داده شده باشند، این یک خطای نحوی است و برنامه با کد وضعیت ۲ خارج می‌شود.
artifact_pattern: محصول ساخت (build artifact) برای بررسی تکرارپذیری. می‌تواند یک الگوی شل مانند "*.deb *.changes" باشد.
virtual_server_args: آرگومان‌هایی که باید به virtual_server ارسال شوند، که آرگومان اول نام سرور است. اگر خود این بخش شامل گزینه‌هایی باشد (به فرم -xxx یا --xxx)، یا اگر هر یک از آرگومان‌های پیشین حذف شده باشند، باید یک "--" میان این آرگومان‌ها و گزینه‌های اختصاصی reprotest قرار دهید. پیش‌فرض: "null"، برای اجرای مستقیم در /tmp. انتخاب‌ها: chroot, lxc, lxd, null, qemu, schroot, ssh.SS "گزینه‌ها:"
--help [VIRTUAL_SERVER_NAME]: نمایش این پیام راهنما و خروج. هنگامی که یک آرگومان داده شود، در عوض پیام راهنمای مربوط به آن سرور مجازی را نمایش داده و خارج می‌شود.
-f، --config-file CONFIG_FILE: فایلی که پیکربندی از آن بارگیری می‌شود. (پیش‌فرض: None)

گزینه‌های پایه:

--verbosity VERBOSITY: یک عدد صحیح. کنترل پیام‌هایی که نمایش داده می‌شوند (0: ساکت (فقط هشدار/خطا)، 1: اطلاع‌رسانی، 2: اشکال‌زدایی).
-v، --verbose: مشابه --verbosity، اما بدون آرگومان و با امکان تکرار چندین‌باره به کار می‌رود.
--host-distro HOST_DISTRO: توزیعی که آزمون‌ها را اجرا خواهد کرد (پیش‌فرض: None)
-s، --source-root PATH: ریشه درخت منبع که در سرور مجازی کپی شده و در طول ساخت در دسترس قرار می‌گیرد. اگر یک فایل در اینجا مشخص شود، در عوض دایرکتوری والد آن استفاده خواهد شد. پیش‌فرض: "." (دایرکتوری کاری فعلی).
--source-pattern PATTERNS: الگوی عمومی شل (glob pattern) برای محدود کردن فایل‌های موجود در <source_root> که در طول ساخت در دسترس قرار می‌گیرند. پیش‌فرض: خالی، یعنی کپی کردن کل دایرکتوری <source_root> بدون هیچ محدودیتی.
-c، --build-command COMMANDS: دستور ساخت برای اجرا. اگر روی "auto" تنظیم شود، reprotest نحوه ساخت source_root داده‌شده را حدس خواهد زد، که در این صورت ممکن است گزینه‌های گوناگون دیگری به‌طور خودکار (در صورت تنظیم نشدن) تعیین شوند. پیش‌فرض: auto
--store-dir DIRECTORY: ذخیره دست‌ساخته‌ها در این دایرکتوری، که باید خالی باشد یا وجود نداشته باشد. در غیر این صورت، دست‌ساخته‌ها حذف خواهند شد و شما تنها هش‌های آن‌ها (در صورت تکرارپذیر بودن) یا خروجی diff (در صورت عدم تکرارپذیری) را مشاهده خواهید کرد. همچنین --no-clean-on-error را ببینید.
--variations VARIATIONS: دگرگونی‌های ساخت جهت آزمودن، به صورت فهرستی از نام‌های دگرگونی که با کاما از هم جدا شده‌اند. مقدار پیش‌فرض "+all" است که معادل است با: "+environment, +build_path, +kernel, +aslr, +num_cpus, +time, +user_group, +fileordering, +domain_host, +home, +locales, +exec_path, +timezone, +umask"، که تمام دگرگونی‌های موجود را می‌آزماید. برای گزینه‌های ساختاری پیشرفته‌تر، از جمله تنظیم دقیق نحوه عملکرد برخی دگرگونی‌ها، بخش VARIATIONS در صفحه راهنما را ببینید.
--vary VARIATIONS: مشابه --variations، اما به جای بازنویسی، به مقادیر قبلی --vary الحاق می‌شود. آخرین مقدار تنظیم‌شده برای --variations به طور ضمنی به عنوان مقدار صفرم --vary در نظر گرفته می‌شود.
--extra-build VARIATIONS: انجام ساختی دیگر با VARIATIONS داده‌شده (که می‌تواند خالی باشد) تا بر روی موارد مشخص‌شده در --variations و --vary اعمال شود. هر بار استفاده از این پرچم، ساخت دیگری را مشخص می‌کند؛ بنابراین به عنوان مثال اگر دو بار داده شود، reprotest در مجموع ۴ ساخت انجام خواهد داد.
--auto-build: انجام خودکار ساخت‌ها جهت تلاش برای تعیین اینکه کدام دگرگونی‌های مشخص باعث عدم تکرارپذیری می‌شوند، به طور بالقوه تا و شامل موارد مشخص‌شده توسط --variations و --vary. با --extra-build تداخل دارد.
--env-build: انجام خودکار ساخت‌ها جهت تلاش برای تعیین اینکه کدام متغیرهای محیطی مشخص باعث عدم تکرارپذیری می‌شوند، بر اساس یک فهرست سفید و فهرست سیاه تعبیه‌شده در کد. احتمالاً مایل خواهید بود هنگام استفاده از این پرچم، --vary=-all را نیز تنظیم کنید؛ برای جزئیات، صفحه راهنما را ببینید. با --extra-build و --autobuild تداخل دارد.
--min-cpus NUM: حداقل تعداد پردازنده‌ها (CPU) برای استفاده هنگام تثبیت num_cpus. پیش‌فرض: 1..SS "گزینه‌های diff (diff options):"
--diffoscope-arg ARG: دادن آرگومان‌های اضافی به diffoscope هنگام اجرای آن. پیش‌فرض: ['--exclude-directory-metadata=yes']. آرگومان‌ها با الگوی {}-format قالب‌بندی می‌شوند: {0} نام هر اجرای آزمایش، و {1} مسیر خروجی آزمایش است.
--diffoscope PATH: مسیر به diffoscope(1). پیش‌فرض: diffoscope
--no-diffoscope: عدم اجرای diffoscope؛ در عوض اجرای diff(1). زمانی مفید است که نمی‌خواهید diffoscope را نصب کنید و/یا فقط یک پاسخ سریع در این مورد می‌خواهید که آیا بازتولید موفقیت‌آمیز بوده است یا خیر، بدون صرف زمان برای محاسبهٔ تمام تفاوت‌های باجزئیات.

گزینه‌های پیشرفته (advanced options):

--testbed-pre COMMANDS: دستورهای پوسته برای اجرا پیش از آغاز بستر آزمون (testbed)، در چارچوب محیط سیستم فعلی. این می‌تواند به عنوان مثال برای محاسبه اطلاعات مورد نیاز ساخت استفاده شود، در جایی که محاسبه نیازمند بسته‌هایی است که نمی‌خواهید در خود بستر آزمون نصب شوند.
--testbed-init COMMANDS: دستورهای پوسته برای اجرا پس از آغاز بستر آزمون، پیش از اجرای هر چیز دیگری. به عنوان مثال برای نصب disorderfs در یک chroot استفاده می‌شود.
--testbed-build-pre COMMANDS: دستورهای پوسته برای اجرا پیش از هر ساخت، حتی پیش از اعمال دگرگونی‌ها (variations) برای آن ساخت. به عنوان مثال برای نصب وابستگی‌های ساخت (build-dependencies) به کار می‌رود.
--auto-preset-expr PYTHON_EXPRESSION: این گزینه می‌تواند برای تغییر پیش‌تنظیم‌های بازگردانده شده توسط قابلیت تشخیص خودکار استفاده شود. مقدار باید یک عبارت پایتون باشد که متغیر _ را که از نوع reprotest.presets.ReprotestPreset است دگرگون کند. برای روش‌های نوشتن این عبارت، مستندات آن کلاس را ببینید. پیش‌فرض: _
--no-clean-on-error: در صورت بروز خطا، virtual_server پاک‌سازی نشود. برای اشکال‌زدایی مفید است اما بسته به virtual_server استفاده شده، فایل‌های اضافی روی سیستم شما باقی می‌گذارد؛ ما به برخی اشاره می‌کنیم اما ممکن است موارد دیگری نیز وجود داشته باشد.
--dry-run: ساخت‌ها را اجرا نکن، فقط چاپ کن چه اتفاقی خواهد افتاد.
--print-sudoers: چاپ یک فایل sudoers برای انجام عملیات بدون گذرواژه با استفاده از --variations داده شده، مفید برای user_group.available و domain_host.use_sudo.
--control-build CONTROL_BUILD: بازنویسی ساخت کنترل با دست‌ساخته‌های واقع در این مسیر. امکان استفاده مجدد از ساخت قبلی را به عنوان خط مبنا فراهم می‌کند.
--append-build-command COMMANDS: افزودن آرگومان‌ها به دستور ساخت

مثال‌های خط فرمان (COMMAND-LINE EXAMPLES)

ساده‌ترین راه برای اجرای reprotest استفاده از پیش‌تنظیم‌های ماست:

# ساخت دایرکتوری جاری در یک سرور null (/tmp)
$ reprotest .
$ reprotest . -vv -- null -d # برای خروجی بسیار پرجزئیات
# ساخت یک برنامه مبتنی بر make
$ reprotest "make clean && make" mybinary
# ساخت یک بسته Debian
$ apt-get source hello && cd hello-2.10
$ reprotest  auto -- null
# ساخت یک بسته Debian و غیرفعال کردن برخی دگرگونی‌ها
$ reprotest --vary=-user_group,-domain_host,-fileordering auto -- null
# ساخت بسته سورس Debian داده شده در یک schroot
# برای دستورالعمل‌های راه‌اندازی، https://wiki.debian.org/sbuild را ببینید.
$ reprotest reprotest_0.3.3.dsc -- schroot unstable-amd64-sbuild
# ساخت بسته سورس RPM داده شده
# در حال حاضر تنها سرور null (/tmp) پشتیبانی می‌شود.
$ reprotest reprotest-0.7.16.src.rpm
# ساخت بسته سورس RPM داده شده و نصب خودکار وابستگی‌ها
$ reprotest --testbed-build-pre 'dnf -y builddep ./*.src.rpm' reprotest-0.7.16.src.rpm

در حال حاضر، ما این قابلیت را تنها برای بسته‌های مبتنی بر Debian و RPM پشتیبانی می‌کنیم، اما مشتاق افزودن موارد بیشتری هستیم. اگر ما اطلاعاتی در مورد نحوه ساخت فایل یا دایرکتوری شما نداریم، می‌توانید برای افزودن این هوشمندی وصله‌ای (patch) برای ما بفرستید - ماژول پایتون reprotest.presets را ببینید و منطق موجود را تطبیق دهید.

در این میان، می‌توانید از سایر بخش‌های واسط خط فرمان (CLI) برای ساخت موارد دلخواه استفاده کنید. لازم است دو آرگومان اجباری را وارد کنید: دستور ساختی که باید اجرا شود و فایل/الگوی دست‌ساختهٔ ساخت (build artifact) برای آزمایش پس از اجرای ساخت. برای مثال:

$ reprotest 'python3 setup.py bdist' 'dist/*.tar.gz'

این کار دستور را روی .، یعنی دایرکتوری کاری جاری اجرا می‌کند. برای اجرای آن روی پروژه‌ای واقع در مکانی دیگر:

$ reprotest -s ../path/to/other/project 'python3 setup.py bdist' 'dist/*.tar.gz'
$ reprotest -c 'python3 setup.py bdist' ../path/to/other/project 'dist/*.tar.gz'

این دو فراخوانی معادل یکدیگر هستند؛ می‌توانید مناسب‌ترین گزینه را برای مورد کاربرد خود انتخاب کنید. هنگام استفاده از این موارد در یک پوسته:

اگر دستور ساخت دارای فاصله است، باید آن را در نقل‌قول قرار دهید، مانند reprotest "dpkg-buildpackage -b --no-sign" [..].
اگر می‌خواهید از چندین الگوی دست‌ساخته ساخت استفاده کنید، یا می‌خواهید از نویسه‌های عام (wildcard) پوسته به عنوان الگو استفاده کنید، باید آن‌ها را نیز در نقل‌قول قرار دهید، مانند reprotest [..] "*.tar.gz *.tar.xz".
اگر دست‌ساخته‌های ساخت شما در نام خود دارای فاصله هستند، باید آن‌ها را دو بار در نقل‌قول قرار دهید، مانند '"a file with spaces.gz"' برای یک دست‌ساخته، یا '"dir 1"/* "dir 2"/*' برای الگوهای چندگانه.

برای دریافت راهنمایی بیشتر درباره واسط خط فرمان (CLI)، از جمله مستندات مربوط به آرگومان‌های اختیاری و کارکرد آن‌ها، دستور زیر را اجرا کنید:

$ reprotest --help

همچنین می‌توانید ساخت را درون آنچه "سرور مجازی" نامیده می‌شود اجرا کنید. این سرور می‌تواند یک کانتینر، یک chroot و غیره باشد. آن‌ها را به این صورت اجرا می‌کنید:

$ reprotest 'python3 setup.py bdist_wheel'   'dist/*.whl' -- qemu    /path/to/qemu.img
$ reprotest 'dpkg-buildpackage -b --no-sign' '../*.deb'   -- schroot unstable-amd64

انواع مختلفی از سرورها در دسترس هستند. برای مشاهدهٔ فهرستی از آن‌ها، به --help مراجعه کنید که در نزدیکی بالا، در بخش "virtual_server_args" از قسمت "positional arguments" نمایش داده می‌شود.

برای هر سرور مجازی (مانند "schroot")، می‌توانید بررسی کنید چه آرگومان‌های اضافه‌ای را پشتیبانی می‌کند:

$ reprotest --help schroot

هنگام اجرای ساخت‌ها درون یک سرور مجازی، احتمالاً باید دستورهای اضافه‌ای بدهید تا وابستگی‌های ساخت خود را درون سرور مجازی برپا کنید. برای نمونه، جهت بررسی این‌که پیش‌تنظیم "Debian directory" در صورت اجرا با رابط خط فرمان کامل چگونه خواهد بود:

# "Debian directory" 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 \
    --testbed-init 'apt-get -y --no-install-recommends install \
                    disorderfs faketime locales-all sudo util-linux; \
                    test -c /dev/fuse || mknod -m 666 /dev/fuse c 10 229; \
                    test -f /etc/mtab || ln -s ../proc/self/mounts /etc/mtab' \
    --testbed-build-pre 'apt-get -y --no-install-recommends build-dep ./' \
    --build-command 'dpkg-buildpackage --no-sign -b' \
    . \
    '../*.deb' \
    -- \
    schroot unstable-amd64-sbuild

آرگومان --testbed-init برای برپاسازی ابزارهای پایه‌ای مورد نیاز است، ابزارهایی که reprotest در وهلهٔ اول برای اعمال تغییرات به آن‌ها نیاز دارد. این تنظیم صرف‌نظر از بسته‌ای که ساخته می‌شود باید یکسان باشد، اما ممکن است بسته به این‌که از چه virtual_server استفاده می‌شود، تفاوت داشته باشد.

سپس، --testbed-build-pre و بعد از آن --build-command (یا -c) را داریم. برای دایرکتوری دبیان خود، وابستگی‌های ساخت را با استفاده از apt-get نصب می‌کنیم، سپس خودِ دستور ساخت واقعی را با استفاده از dpkg-buildpackage(1) اجرا می‌کنیم.

سپس، source_root و artifact_pattern را داریم. برای بازتولیدپذیری، ما تنها به بسته‌های باینری علاقه‌مندیم.

در نهایت، مشخص می‌کنیم که این فرایند باید در سرور مجازی "schroot" با آرگومان‌های "unstable-amd64-sbuild" انجام شود.

البته اگر مجبور باشید یک مورد را بارها اجرا کنید، به خاطر سپردن همهٔ این موارد دشوار است. بنابراین به همین دلیل است که افزودن پیش‌تنظیم‌های جدید برای انواع بسته‌های جدید سودمند خواهد بود.

اینجا یک مثال پیچیده‌تر آورده شده است. این دستور به reprotest می‌گوید فرآورده‌های ساخت را برای تحلیل بعدی در ./artifacts ذخیره کند؛ و همچنین پیش‌تنظیم "Debian dsc" را طوری تنظیم می‌کند که از زنجیره‌ابزار آزمایشی ما در https://wiki.debian.org/ReproducibleBuilds/ExperimentalToolchain استفاده کند:

$ reprotest --store-dir=artifacts \
    --auto-preset-expr '_.prepend.testbed_init("apt-get install -y wget; \
        echo deb http://reproducible.alioth.debian.org/debian ./ >> /etc/apt/sources.list; \
        wget -q -O- https://reproducible.alioth.debian.org/reproducible.asc | apt-key add -; \
        apt-get update; apt-get upgrade -y; ")' \
    ./bash_4.4-4.0~reproducible1.dsc \
    -- \
    schroot unstable-amd64-sbuild

در روشی دیگر، می‌توانید chroot مربوط به unstable-amd64-sbuild خود را کلون کرده، مخزن ما را به chroot کلون‌شده اضافه کنید، سپس از این chroot به جای "unstable-amd64-sbuild" استفاده کنید. این کار به شما امکان می‌دهد گزینهٔ طولانی --auto-preset-expr در بالا را حذف کنید..SH "فایل پیکربندی (CONFIG FILE)"

شما همچنین می‌توانید گزینه‌ها را از طریق یک فایل پیکربندی به reprotest بدهید. این یک اقدام صرفه‌جویی در زمان، مشابه پیش‌تنظیم‌های auto است؛ با این تفاوت که این روش برای ساخت‌های محلی متناسب با اهداف شخصی شما مناسب‌تر است. (شما می‌توانید در یک ساخت از هر دوی پیش‌تنظیم‌ها و فایل‌های پیکربندی استفاده کنید.)

فایل پیکربندی دقیقاً همان گزینه‌های رابط خط فرمان را می‌پذیرد، اما با این محدودیت اضافه که نام بخش باید با نام‌های ارائه‌شده در خروجی --help مطابقت داشته باشد. نویسه‌های فاصله خالی (Whitespace) فقط و فقط در صورتی مجاز هستند که گزینهٔ معادل در خط فرمان نیز فاصله را مجاز بداند. در نهایت، مشخص کردن آرگومان‌های مکانی از طریق این سازوکار امکان‌پذیر نیست.

دستور reprotest به‌طور پیش‌فرض هیچ فایل پیکربندی را بارگذاری نمی‌کند. می‌توانید با گزینه‌های خط فرمان --config-file یا -f به آن بگویید که فایلی را بارگذاری کند. اگر یک دایرکتوری مانند . به آن بدهید، فایل .reprotestrc را در آن دایرکتوری بارگذاری خواهد کرد.

یک نمونه فایل پیکربندی در زیر آمده است:

[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
[diff]
diffoscope_arg =
  --debug

تحلیل خروجی DIFF (ANALYSING DIFF OUTPUT)

به‌طور معمول هنگامی که diffoscope دایرکتوری‌ها را مقایسه می‌کند، متاداده‌های فایل‌های موجود در آن دایرکتوری‌ها - دسترسی‌های فایل، مالکان و غیره - را نیز مقایسه می‌کند.

با این حال بسته به شرایط، این متاداده در سطح سیستم‌فایل ممکن است برای توزیع به سیستم‌های دیگر در نظر گرفته شده باشد یا خیر. به عنوان مثال: (۱) برای اکثر سازندگان بسته در توزیع‌ها، متادادهٔ فایل‌های بستهٔ خروجی اهمیتی ندارد؛ تنها محتوای فایل به سیستم‌های دیگر توزیع خواهد شد. از سوی دیگر، (۲) هنگام اجرای چیزی مانند make install، متاداده اهمیت دارد، زیرا این همان چیزی است که قرار است روی سیستم دیگر بازسازی شود.

در توسعهٔ reprotest، تجربهٔ ما نشان داده است که حالت (۱) رایج‌تر است و بنابراین ما به‌طور پیش‌فرض --exclude-directory-metadata=yes را به diffoscope ارسال می‌کنیم. اگر متوجه شدید که از reprotest برای حالت (۲) استفاده می‌کنید، باید --diffoscope-args=--exclude-directory-metadata=no را به reprotest ارسال کنید تا به diffoscope بگوید از متاداده صرف‌نظر نکند، زیرا متاداده توزیع خواهد شد و بنابراین باید بازتولیدپذیر باشد. در غیر این صورت، ممکن است با یک نتیجه مثبت کاذب (false-positive) مواجه شوید.

تغییرات (VARIATIONS)

پرچم‌های --vary و --variations در شکل سادهٔ خود، فهرستی جداشده با کاما از نام‌های تغییرات هستند که مشخص می‌کنند کدام تغییرات اعمال شوند. فهرست کامل نام‌ها در متن --help برای --variations آمده است.

با جزئیات کامل، این پرچم‌ها فهرستی جداشده با کاما از اقدامات هستند، به شرح زیر:
+$variation (یا $variation بدون عملگر صریح)
-$variation
فعال یا غیرفعال کردن یک تغییر
@$variation
فعال کردن یک تغییر، و بازنشانی پارامترهای آن (در ادامه را ببینید) به مقادیر پیش‌فرض.
$variation.$param=$value
$variation.$param+=$value
$variation.$param-=$value
تنظیم/افزودن/حذف $value به عنوان/به/از مقدار فعلی پارامتر $param مربوط به $variation.
$variation.$param++
$variation.$param--
افزایش/کاهش مقدار پارامتر $param مربوط به $variation.

بیشتر تغییرات پارامتری ندارند، و برای آن‌ها تنها عملگرهای + و - کاربرد دارند. تغییراتی که پارامتر می‌پذیرند عبارتند از:

build_path.path: مسیری که برای ساخت‌های آزمایشی هنگام فعال بودن تغییرات مسیر ساخت استفاده می‌شود. این مسیر باید در مکانی باشد که برای کاربری که ساخت را اجرا می‌کند، قابل نوشتن باشد. این گزینه (تا حدی طعنه‌آمیز) زمانی مفید است که برای یکسان‌سازی مسیر ساخت همراه با --control-build جهت مقایسه با یک ساخت موجود که با reprotest انجام نشده است، استفاده شود.
domain_host.use_sudo: یک عدد صحیح، برای تعیین این‌که آیا از sudo(1) همراه با unshare(1) جهت تغییر hostname و domainname سیستم استفاده شود یا خیر. عدد 0 به معنای عدم استفاده از sudo است؛ هر مقدار غیرصِفر به معنای استفاده از sudo است. پیش‌فرض 0 است، هرچند این توصیه نمی‌شود و ممکن است باعث شکست ساخت شما شود؛ برای جزئیات به "Varying the domain and host names" مراجعه کنید.
environment.variables: مجموعه‌ای مرتب و جداشده با نقطه‌ویرگول، که متغیرهای محیطی‌ای را مشخص می‌کند که reprotest باید برای تغییر آن‌ها تلاش کند. مقدار پیش‌فرض "REPROTEST_CAPTURE_ENVIRONMENT" است. از قواعد نگارشی مبتنی بر عبارات باقاعده (regex) پشتیبانی می‌کند، مانند:

PID=\d{1,6}
HOME=(/\w{3,12}){1,4}
(GO|PYTHON|)PATH=(/\w{3,12}){1,4}(:(/\w{3,12}){1,4}){0,4}

حالت‌های خاص:

$VARNAME= (سمت راست خالی) برای اعلان به reprotest جهت حذف متغیر
$VARNAME=.{0} برای اعلان به reprotest جهت تنظیم یک مقدار واقعاً خالی
\x2c و \x3b به ترتیب برای تطبیق یا تولید , و ;.

user_group.available: یک مجموعهٔ مرتب و جداشده با نقطه‌ویرگول، که ترکیب‌های کاربر+گروه در دسترسی را مشخص می‌کند که reprotest می‌تواند به آن‌ها sudo(1) کند. پیش‌فرض خالی است که در این حالت تغییر بی‌اثر خواهد بود و هشداری دربارهٔ آن مشاهده خواهید کرد. هر کاربر+گروه باید به صورت $user:$group مشخص شود که در آن هر یک از اجزا قابل حذف است، یا در صورتی که دونقطه‌ای وجود نداشته باشد تنها به عنوان یک $user بدون تغییر $group تفسیر می‌شود.
time.faketimes: یک مجموعهٔ مرتب و جداشده با نقطه‌ویرگول، که توصیف‌کننده‌های زمان ممکن در faketime(1) را برای استفاده مشخص می‌کند. پیش‌فرض خالی است، که در این حالت برنامه‌ یک زمان را انتخاب می‌کند: یا زمان کنونی (اگر آخرین زمان تغییر فایل در source_root قدیمی‌تر از ۳۹۸ روز باشد) یا بیش از ۳۹۸ روز در آینده.
توجه داشته باشید که ساعت در طول ساخت به کار خود ادامه می‌دهد. امکان متوقف ساختن آن توسط faketime(1) وجود دارد، اما این قابلیت هنوز پشتیبانی نمی‌شود؛ زیرا احتمال بالاتری برای ایجاد خطا در ساخت یا رفتارهای غیرمنتظره دارد.
locales.locale: فهرستی جداشده با نقطه‌ویرگول از یک یا چند محلی‌سازی (locale) برای آزمایش در هنگام اعمال تغییرات محلی‌سازی‌ها. اگر چندین محلی‌سازی مشخص شده باشد، یکی به صورت تصادفی انتخاب خواهد شد. محلی‌سازی‌هایی با ویژگی‌های متفاوت از en_US.UTF-8 عبارتند از fr_CH.UTF-8، ru_RU.CP1251، kk_KZ.RK1048 یا zh_CN. در صورت عدم تعیین، مقدار پیش‌فرض et_EE.UTF-8 است.
num_cpus.cpus: فهرستی جداشده با نقطه‌ویرگول از یک یا چند مقدار عددی برای انتخاب تعداد پردازنده‌ها هنگام اعمال تغییرات num_cpus.

تفاوت بین --vary و --variations در این است که اولی به مقادیر قبلی اضافه می‌کند، اما دومی آن‌ها را بازنشانی می‌کند. علاوه بر این، آخرین مقدار تنظیم‌شده برای --variations به عنوان صفرمین آرگومان --vary در نظر گرفته می‌شود. برای مثال:

reprotest --vary=-user_group

به معنای تغییر دادن +all (مقدار پیش‌فرض برای --variations) و -user_group (مقدار داده‌شده برای --vary) است، در حالی که:

reprotest --variations=-all,locales --variations=home,time --vary=timezone --vary=-time

به معنای تغییر دادن home،‏ time (آخرین مقدار داده‌شده برای --variations)، timezone و -time (چندین مقدار داده‌شده برای --vary) است، یعنی home و timezone.

نکات مربوط به تغییرات (NOTES ON VARIATIONS)

دستور reprotest تمام تلاش خود را می‌کند تا تغییرات را بدون فرض داشتن دسترسی کامل ریشه (root) به سیستم اعمال کند. همچنین فرض می‌کند که نرم‌افزارهای دیگری نیز ممکن است روی همان سیستم در حال اجرا باشند، بنابراین تغییراتی در سطح سیستم که فرآیندهای دیگر را تحت تأثیر قرار دهد ایجاد نمی‌کند. با توجه به این مفروضات، برخی از تغییرات با استفاده از ترفندهایی با درجات متفاوتی از غیراصولی بودن پیاده‌سازی شده‌اند که در ادامه مستند شده‌اند.

امیدواریم در آینده این فرضیات را برای برخی محیط‌های خاص virtual_server برداریم. این امر احتمالاً امکان اجرای روان‌تر را در آن محیط‌ها فراهم خواهد کرد. با این حال، این فرضیات برای virtual_server از نوع "null" (پیش‌فرض) پابرجا خواهند ماند.

تعداد پردازنده‌ها (Number of CPUs)

ساخت شاهد (control build) تنها از ۱ پردازنده (CPU) استفاده می‌کند تا نامعین بودن (nondeterminism) احتمالی ناشی از چندریسمانی (multithreading) یا چندپردازشی (multiprocessing) را کاهش دهد. اگر مطمئن هستید که ساخت شما تحت تأثیر این موضوع قرار نمی‌گیرد (و ساخت‌های استاندارد نباید تحت تأثیر باشند)، می‌توانید --min-cpus=99999 را مشخص کنید تا از تمام هسته‌های موجود برای هر دو ساخت استفاده شود.

دامنه یا میزبان (Domain or host)

انجام این کار بدون sudo ممکن است منجر به شکست ساخت شما شود.

اگر ساخت شما نیازمند انجام کارهای مرتبط با سیستم باشد - بر خلاف مواردی که تنها به پردازش بیت‌ها و بایت‌ها می‌پردازند - شکست محتمل است. دلیل این امر این است که فرآیند در یک فضای‌نام (namespace) جداگانه اجرا می‌شود که در آن کاربر غیرممتاز شما به نظر "root" می‌رسد، اما این مسئله از جمله مانع شناسایی فایل‌های متعلق به کاربر واقعی "root" توسط سیستم‌فایل می‌شود. این یکی از محدودیت‌های unshare(1) است و امکان دور زدن آن در reprotest بدون تلاشی سنگین وجود ندارد.

بنابراین، توصیه می‌شود این تغییر با use_sudo=1 اجرا شود. برای جلوگیری از درخواست‌های گذرواژه، بخش "Avoid sudo(1) password prompts" در زیر را مشاهده کنید.

هنگام اجرا درون یک virtual-server:

روش بدون sudo با خطای "Operation not permitted" شکست می‌خورد، حتی اگر /proc/sys/kernel/unprivileged_userns_clone را ویرایش کرده باشید. علت این امر در حال حاضر نامشخص است.

روش sudo تنها در صورتی کار می‌کند که تدابیری برای جلوگیری از درخواست‌های گذرواژه sudo اتخاذ کرده باشید، زیرا کانتینرها روشی برای ورود این مقدار ندارند.

کاربر یا گروه (User or group)

اگر ترتیب فایل‌ها (fileordering) را نیز به طور هم‌زمان تغییر می‌دهید (که در حالت پیش‌فرض چنین است)، هر کاربری که استفاده می‌کنید باید عضو گروه "fuse" باشد. این کار را با اجرای دستور usermod -aG fuse $OTHERUSER به عنوان کاربر ریشه (root) انجام دهید.

برای جلوگیری از درخواست گذرواژه sudo(1)، بخش "Avoid sudo(1) password prompts" در زیر را مشاهده کنید.

زمان (Time)

تغییر "time" از faketime(1) استفاده می‌کند که گاهی اوقات باعث بروز مشکلات عجیب و غریب با عیب‌یابی دشوار می‌شود. در گذشته، این موارد شامل موارد زیر بوده است:

ساخت‌هایی که زمان نامحدودی به طول می‌انجامند؛ اگرچه این مشکل باید در نگارش‌های اخیر reprotest برطرف شده باشد.
ساخت‌هایی با تفاوت‌های غیرقابل‌باور بزرگ ناشی از اسکریپت‌های ./configure که نتایج متفاوتی با و بدون faketime تولید می‌کنند. این مشکل همچنان روی bash و احتمالاً برخی دیگر از بسته‌های مبتنی بر autotools تأثیر می‌گذارد.
ساخت‌هایی که به شبکه دسترسی دارند به دلیل خطاهای انقضای گواهی‌نامه و/یا سایر خطاهای امنیتی مرتبط با زمان شکست می‌خورند. (ساخت‌های شفاف نرم‌افزارهای آزاد و متن‌باز [FOSS] اساساً نباید به شبکه دسترسی داشته باشند، اما نظارت یا جلوگیری از این مورد خارج از حیطه reprotest است.)

اگر تفاوتی را مشاهده کردید که واقعاً فکر می‌کنید نباید وجود داشته باشد، ارسال --variations=-time به reprotest را امتحان کنید، و/یا نتایج ما را در https://tests.reproducible-builds.org بررسی کنید که از سازوکار متفاوت (و قابل‌اطمینان‌تری) برای تغییر زمان سیستم استفاده می‌کند..SS "هسته (Kernel)"

دگرگونی "kernel" در حال حاضر برای بسته‌های مبتنی بر RPM و سایر فرآیندهای ساخت که به ldconfig نیاز دارند، کار نمی‌کند. هنگام ساخت با فعال بودن این دگرگونی، ldconfig با خطای FATAL: kernel too old اعتراض کرده و فرآیند ساخت را لغو می‌کند.

جلوگیری از اعلان‌های گذرواژه SUDO(1) (AVOID SUDO(1) PASSWORD PROMPTS)

در حال حاضر راه مناسبی برای انجام این کار وجود ندارد. روش زیر یک راه‌حل آزمایشی (EXPERIMENTAL) بوده و شکننده و ناپاکیزه است. خودتان باید تصمیم بگیرید که آیا این روش برای مورد کاربرد شما ارزشش را دارد یا خیر:

$ reprotest --print-sudoers \
    --variations=user_group.available+=guest-builder,domain_host.use_sudo=1 \
    | sudo EDITOR=tee visudo -f /etc/sudoers.d/local-reprotest

اطمینان حاصل کنید دگرگونی‌هایی را تعیین می‌کنید که واقعاً قصد استفاده از آن‌ها را دارید. بدیهی است که نباید کاربران دارای دسترسی بالا مانند root را برای این هدف انتخاب کنید.

(ساده‌سازی خروجی با استفاده از نویسه‌های عمومی (wildcards)، امکان دسترسی بدون گذرواژه برای اجرای chown روی هر چیزی در سیستم شما را فراهم می‌کند، چرا که نویسه‌های عمومی در اینجا با فاصله‌ها مطابقت دارند. مشخص نیست توسعه‌دهندگان sudo به چه چیزی فکر می‌کردند.)

خیر، این روش اصلاً جالب نیست - از پیشنهادها و وصله‌ها استقبال می‌شود.

اگر می‌خواهید از این روش در یک سرور مجازی مانند chroot استفاده کنید، باید فایل sudoers حاصل را درون chroot خود کپی (یا سوار/mount، یا به شکلی دیگر نگاشت) کنید.

به عنوان مثال، برای یک schroot، باید (۱) به schroot مبدأ وارد شده و یک فایل خالی /etc/sudoers.d/local-reprotest ایجاد کنید (این نکته مهم است) و سپس (۲) خط زیر را:

/etc/sudoers.d/local-reprotest /etc/sudoers.d/local-reprotest none bind 0 0

به fstab مربوط به schroot خود اضافه کنید.