.\" DO NOT MODIFY THIS FILE! It was generated by help2man 1.49.3. .TH REPROTEST "1" "December 2025" "reprotest 0.7.32" "User Commands" .SH "نام (NAME)" reprotest \- ساخت بسته‌ها و بررسی آن‌ها از نظر تکرارپذیری .SH "خلاصه دستور (SYNOPSIS)" .nf \fBreprotest\fR \-\-help\ [] \fBreprotest\fR [options] [\-c ] [] \ [-- [ ...]] \fBreprotest\fR [options] [\-s ] [] \ [-- [ ...]] .fi .\" Man page generated from reStructuredText .\" by the Docutils 0.22.3 manpage writer. . . .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 .. "" .SH "توضیحات (DESCRIPTION)" .sp ابزار reprotest همان کد منبع را دو بار در محیط‌های متفاوت می‌سازد، و سپس فایل‌های باینری تولیدشده در هر ساخت را برای یافتن تفاوت‌ها بررسی می‌کند. در صورت یافتن هرگونه تفاوت، از \fBdiffoscope(1)\fP (یا در صورت عدم دسترسی از \fBdiff(1)\fP) برای نمایش باجزئیات آن‌ها جهت تحلیل‌های بعدی استفاده می‌شود. .sp برای شروع کار و همچنین مشاهدهٔ توضیحات دقیق‌تر دربارهٔ همهٔ گزینه‌های خط فرمان، بخش \fBCOMMAND\-LINE EXAMPLES\fP را در ادامه ببینید. همین اطلاعات در \fB/usr/share/doc/reprotest/README.rst\fP یا موارد مشابه نیز در دسترس است. .\" 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 آرگومان نخست بسته به ساختارش، یا به عنوان یک source_root (گزینهٔ \fB\-s\fR را ببینید) یا به عنوان یک build\-command (گزینهٔ \fB\-c\fR را ببینید) تلقی می‌شود. در بیشتر موارد، این سازوکار باید خودبه‌خود و بدون مشکل کار کند؛ اما به‌طور دقیق‌تر: اگر هیچ‌یک از گزینه‌های \fB\-c\fR یا \fB\-s\fR مشخص نشده باشند، در صورتی که این آرگومان به صورت یک فایل یا دایرکتوری وجود داشته باشد و مقدار آن "auto" نباشد، به عنوان source_root در نظر گرفته می‌شود، وگرنه به عنوان build_command شناخته خواهد شد. در غیر این صورت، اگر یکی از گزینه‌های \fB\-c\fR یا \fB\-s\fR داده شده باشد، این آرگومان به عنوان دیگری در نظر گرفته می‌شود. اگر هر دو گزینه داده شده باشند، این یک خطای نحوی است و برنامه با کد وضعیت ۲ خارج می‌شود. .TP artifact_pattern محصول ساخت (build artifact) برای بررسی تکرارپذیری. می‌تواند یک الگوی شل مانند "*.deb *.changes" باشد. .TP virtual_server_args آرگومان‌هایی که باید به virtual_server ارسال شوند، که آرگومان اول نام سرور است. اگر خود این بخش شامل گزینه‌هایی باشد (به فرم \fB\-xxx\fR یا \fB\-\-xxx\fR)، یا اگر هر یک از آرگومان‌های پیشین حذف شده باشند، باید یک "\-\-" میان این آرگومان‌ها و گزینه‌های اختصاصی reprotest قرار دهید. پیش‌فرض: "null"، برای اجرای مستقیم در \fI\,/tmp\/\fP. انتخاب‌ها: chroot, lxc, lxd, null, qemu, schroot, ssh.SS "گزینه‌ها:" .TP \fB\-\-help\fR [VIRTUAL_SERVER_NAME] نمایش این پیام راهنما و خروج. هنگامی که یک آرگومان داده شود، در عوض پیام راهنمای مربوط به آن سرور مجازی را نمایش داده و خارج می‌شود. .TP \fB\-f\fR، \fB\-\-config\-file\fR CONFIG_FILE فایلی که پیکربندی از آن بارگیری می‌شود. (پیش‌فرض: None) .SS "گزینه‌های پایه:" .TP \fB\-\-verbosity\fR VERBOSITY یک عدد صحیح. کنترل پیام‌هایی که نمایش داده می‌شوند (0: ساکت (فقط هشدار/خطا)، 1: اطلاع‌رسانی، 2: اشکال‌زدایی). .TP \fB\-v\fR، \fB\-\-verbose\fR مشابه \fB\-\-verbosity\fR، اما بدون آرگومان و با امکان تکرار چندین‌باره به کار می‌رود. .TP \fB\-\-host\-distro\fR HOST_DISTRO توزیعی که آزمون‌ها را اجرا خواهد کرد (پیش‌فرض: None) .TP \fB\-s\fR، \fB\-\-source\-root\fR PATH ریشه درخت منبع که در سرور مجازی کپی شده و در طول ساخت در دسترس قرار می‌گیرد. اگر یک فایل در اینجا مشخص شود، در عوض دایرکتوری والد آن استفاده خواهد شد. پیش‌فرض: "." (دایرکتوری کاری فعلی). .TP \fB\-\-source\-pattern\fR PATTERNS الگوی عمومی شل (glob pattern) برای محدود کردن فایل‌های موجود در که در طول ساخت در دسترس قرار می‌گیرند. پیش‌فرض: خالی، یعنی کپی کردن کل دایرکتوری بدون هیچ محدودیتی. .TP \fB\-c\fR، \fB\-\-build\-command\fR COMMANDS دستور ساخت برای اجرا. اگر روی "auto" تنظیم شود، reprotest نحوه ساخت source_root داده‌شده را حدس خواهد زد، که در این صورت ممکن است گزینه‌های گوناگون دیگری به‌طور خودکار (در صورت تنظیم نشدن) تعیین شوند. پیش‌فرض: auto .TP \fB\-\-store\-dir\fR DIRECTORY ذخیره دست‌ساخته‌ها در این دایرکتوری، که باید خالی باشد یا وجود نداشته باشد. در غیر این صورت، دست‌ساخته‌ها حذف خواهند شد و شما تنها هش‌های آن‌ها (در صورت تکرارپذیر بودن) یا خروجی diff (در صورت عدم تکرارپذیری) را مشاهده خواهید کرد. همچنین \fB\-\-no\-clean\-on\-error\fR را ببینید. .TP \fB\-\-variations\fR VARIATIONS دگرگونی‌های ساخت جهت آزمودن، به صورت فهرستی از نام‌های دگرگونی که با کاما از هم جدا شده‌اند. مقدار پیش‌فرض "+all" است که معادل است با: "+environment, +build_path, +kernel, +aslr, +num_cpus, +time, +user_group, +fileordering, +domain_host, +home, +locales, +exec_path, +timezone, +umask"، که تمام دگرگونی‌های موجود را می‌آزماید. برای گزینه‌های ساختاری پیشرفته‌تر، از جمله تنظیم دقیق نحوه عملکرد برخی دگرگونی‌ها، بخش VARIATIONS در صفحه راهنما را ببینید. .TP \fB\-\-vary\fR VARIATIONS مشابه \fB\-\-variations\fR، اما به جای بازنویسی، به مقادیر قبلی \fB\-\-vary\fR الحاق می‌شود. آخرین مقدار تنظیم‌شده برای \fB\-\-variations\fR به طور ضمنی به عنوان مقدار صفرم \fB\-\-vary\fR در نظر گرفته می‌شود. .TP \fB\-\-extra\-build\fR VARIATIONS انجام ساختی دیگر با VARIATIONS داده‌شده (که می‌تواند خالی باشد) تا بر روی موارد مشخص‌شده در \fB\-\-variations\fR و \fB\-\-vary\fR اعمال شود. هر بار استفاده از این پرچم، ساخت دیگری را مشخص می‌کند؛ بنابراین به عنوان مثال اگر دو بار داده شود، reprotest در مجموع ۴ ساخت انجام خواهد داد. .TP \fB\-\-auto\-build\fR انجام خودکار ساخت‌ها جهت تلاش برای تعیین اینکه کدام دگرگونی‌های مشخص باعث عدم تکرارپذیری می‌شوند، به طور بالقوه تا و شامل موارد مشخص‌شده توسط \fB\-\-variations\fR و \fB\-\-vary\fR. با \fB\-\-extra\-build\fR تداخل دارد. .TP \fB\-\-env\-build\fR انجام خودکار ساخت‌ها جهت تلاش برای تعیین اینکه کدام متغیرهای محیطی مشخص باعث عدم تکرارپذیری می‌شوند، بر اساس یک فهرست سفید و فهرست سیاه تعبیه‌شده در کد. احتمالاً مایل خواهید بود هنگام استفاده از این پرچم، \fB\-\-vary\fR=\fI\,\-all\/\fR را نیز تنظیم کنید؛ برای جزئیات، صفحه راهنما را ببینید. با \fB\-\-extra\-build\fR و \fB\-\-autobuild\fR تداخل دارد. .TP \fB\-\-min\-cpus\fR NUM حداقل تعداد پردازنده‌ها (CPU) برای استفاده هنگام تثبیت num_cpus. پیش‌فرض: 1..SS "گزینه‌های diff (diff options):" .TP \fB\-\-diffoscope\-arg\fR ARG دادن آرگومان‌های اضافی به diffoscope هنگام اجرای آن. پیش‌فرض: ['\-\-exclude\-directory\-metadata=yes']. آرگومان‌ها با الگوی {}\-format قالب‌بندی می‌شوند: {0} نام هر اجرای آزمایش، و {1} مسیر خروجی آزمایش است. .TP \fB\-\-diffoscope\fR PATH مسیر به diffoscope(1). پیش‌فرض: diffoscope .TP \fB\-\-no\-diffoscope\fR عدم اجرای diffoscope؛ در عوض اجرای diff(1). زمانی مفید است که نمی‌خواهید diffoscope را نصب کنید و/یا فقط یک پاسخ سریع در این مورد می‌خواهید که آیا بازتولید موفقیت‌آمیز بوده است یا خیر، بدون صرف زمان برای محاسبهٔ تمام تفاوت‌های باجزئیات. .SS "گزینه‌های پیشرفته (advanced options):" .TP \fB\-\-testbed\-pre\fR COMMANDS دستورهای پوسته برای اجرا پیش از آغاز بستر آزمون (testbed)، در چارچوب محیط سیستم فعلی. این می‌تواند به عنوان مثال برای محاسبه اطلاعات مورد نیاز ساخت استفاده شود، در جایی که محاسبه نیازمند بسته‌هایی است که نمی‌خواهید در خود بستر آزمون نصب شوند. .TP \fB\-\-testbed\-init\fR COMMANDS دستورهای پوسته برای اجرا پس از آغاز بستر آزمون، پیش از اجرای هر چیز دیگری. به عنوان مثال برای نصب disorderfs در یک chroot استفاده می‌شود. .TP \fB\-\-testbed\-build\-pre\fR COMMANDS دستورهای پوسته برای اجرا پیش از هر ساخت، حتی پیش از اعمال دگرگونی‌ها (variations) برای آن ساخت. به عنوان مثال برای نصب وابستگی‌های ساخت (build\-dependencies) به کار می‌رود. .TP \fB\-\-auto\-preset\-expr\fR PYTHON_EXPRESSION این گزینه می‌تواند برای تغییر پیش‌تنظیم‌های بازگردانده شده توسط قابلیت تشخیص خودکار استفاده شود. مقدار باید یک عبارت پایتون باشد که متغیر _ را که از نوع reprotest.presets.ReprotestPreset است دگرگون کند. برای روش‌های نوشتن این عبارت، مستندات آن کلاس را ببینید. پیش‌فرض: _ .TP \fB\-\-no\-clean\-on\-error\fR در صورت بروز خطا، virtual_server پاک‌سازی نشود. برای اشکال‌زدایی مفید است اما بسته به virtual_server استفاده شده، فایل‌های اضافی روی سیستم شما باقی می‌گذارد؛ ما به برخی اشاره می‌کنیم اما ممکن است موارد دیگری نیز وجود داشته باشد. .TP \fB\-\-dry\-run\fR ساخت‌ها را اجرا نکن، فقط چاپ کن چه اتفاقی خواهد افتاد. .TP \fB\-\-print\-sudoers\fR چاپ یک فایل sudoers برای انجام عملیات بدون گذرواژه با استفاده از \fB\-\-variations\fR داده شده، مفید برای user_group.available و domain_host.use_sudo. .TP \fB\-\-control\-build\fR CONTROL_BUILD بازنویسی ساخت کنترل با دست‌ساخته‌های واقع در این مسیر. امکان استفاده مجدد از ساخت قبلی را به عنوان خط مبنا فراهم می‌کند. .TP \fB\-\-append\-build\-command\fR COMMANDS افزودن آرگومان‌ها به دستور ساخت .SH "مثال‌های خط فرمان (COMMAND-LINE EXAMPLES)" .sp ساده‌ترین راه برای اجرای reprotest استفاده از پیش‌تنظیم‌های ماست: .INDENT 0.0 .INDENT 3.5 .sp .EX # ساخت دایرکتوری جاری در یک سرور null (/tmp) $ reprotest . $ reprotest . \-vv \-\- null \-d # برای خروجی بسیار پرجزئیات # ساخت یک برنامه مبتنی بر make $ reprotest \(dqmake clean && make\(dq 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 \(aqdnf \-y builddep ./*.src.rpm\(aq reprotest\-0.7.16.src.rpm .EE .UNINDENT .UNINDENT .sp در حال حاضر، ما این قابلیت را تنها برای بسته‌های مبتنی بر Debian و RPM پشتیبانی می‌کنیم، اما مشتاق افزودن موارد بیشتری هستیم. اگر ما اطلاعاتی در مورد نحوه ساخت فایل یا دایرکتوری شما نداریم، می‌توانید برای افزودن این هوشمندی وصله‌ای (patch) برای ما بفرستید \- ماژول پایتون reprotest.presets را ببینید و منطق موجود را تطبیق دهید. .sp در این میان، می‌توانید از سایر بخش‌های واسط خط فرمان (CLI) برای ساخت موارد دلخواه استفاده کنید. لازم است دو آرگومان اجباری را وارد کنید: دستور ساختی که باید اجرا شود و فایل/الگوی دست‌ساختهٔ ساخت (build artifact) برای آزمایش پس از اجرای ساخت. برای مثال: .INDENT 0.0 .INDENT 3.5 .sp .EX $ reprotest \(aqpython3 setup.py bdist\(aq \(aqdist/*.tar.gz\(aq .EE .UNINDENT .UNINDENT .sp این کار دستور را روی \fB\&.\fP، یعنی دایرکتوری کاری جاری اجرا می‌کند. برای اجرای آن روی پروژه‌ای واقع در مکانی دیگر: .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 این دو فراخوانی معادل یکدیگر هستند؛ می‌توانید مناسب‌ترین گزینه را برای مورد کاربرد خود انتخاب کنید. هنگام استفاده از این موارد در یک پوسته: .INDENT 0.0 .INDENT 3.5 .INDENT 0.0 .IP \(bu 2 اگر دستور ساخت دارای فاصله است، باید آن را در نقل‌قول قرار دهید، مانند \fBreprotest \(dqdpkg\-buildpackage \-b \-\-no\-sign\(dq [..]\fP\&. .IP \(bu 2 اگر می‌خواهید از چندین الگوی دست‌ساخته ساخت استفاده کنید، یا می‌خواهید از نویسه‌های عام (wildcard) پوسته به عنوان الگو استفاده کنید، باید آن‌ها را نیز در نقل‌قول قرار دهید، مانند \fBreprotest [..] \(dq*.tar.gz *.tar.xz\(dq\fP\&. .IP \(bu 2 اگر دست‌ساخته‌های ساخت شما در نام خود دارای فاصله هستند، باید آن‌ها را دو بار در نقل‌قول قرار دهید، مانند \fB\(aq\(dqa file with spaces.gz\(dq\(aq\fP برای یک دست‌ساخته، یا \fB\(aq\(dqdir 1\(dq/* \(dqdir 2\(dq/*\(aq\fP برای الگوهای چندگانه. .UNINDENT .UNINDENT .UNINDENT .sp برای دریافت راهنمایی بیشتر درباره واسط خط فرمان (CLI)، از جمله مستندات مربوط به آرگومان‌های اختیاری و کارکرد آن‌ها، دستور زیر را اجرا کنید: .INDENT 0.0 .INDENT 3.5 .sp .EX $ reprotest \-\-help .EE .UNINDENT .UNINDENT.SH "اجرا در یک سرور مجازی (RUNNING IN A VIRTUAL SERVER)" .sp همچنین می‌توانید ساخت را درون آنچه \(dqسرور مجازی\(dq نامیده می‌شود اجرا کنید. این سرور می‌تواند یک کانتینر، یک chroot و غیره باشد. آن‌ها را به این صورت اجرا می‌کنید: .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 انواع مختلفی از سرورها در دسترس هستند. برای مشاهدهٔ فهرستی از آن‌ها، به \fB\-\-help\fP مراجعه کنید که در نزدیکی بالا، در بخش \(dqvirtual_server_args\(dq از قسمت \(dqpositional arguments\(dq نمایش داده می‌شود. .sp برای هر سرور مجازی (مانند \(dqschroot\(dq)، می‌توانید بررسی کنید چه آرگومان‌های اضافه‌ای را پشتیبانی می‌کند: .INDENT 0.0 .INDENT 3.5 .sp .EX $ reprotest \-\-help schroot .EE .UNINDENT .UNINDENT .sp هنگام اجرای ساخت‌ها درون یک سرور مجازی، احتمالاً باید دستورهای اضافه‌ای بدهید تا وابستگی‌های ساخت خود را درون سرور مجازی برپا کنید. برای نمونه، جهت بررسی این‌که پیش‌تنظیم \(dqDebian directory\(dq در صورت اجرا با رابط خط فرمان کامل چگونه خواهد بود: .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 آرگومان \fB\-\-testbed\-init\fP برای برپاسازی ابزارهای پایه‌ای مورد نیاز است، ابزارهایی که reprotest در وهلهٔ اول برای اعمال تغییرات به آن‌ها نیاز دارد. این تنظیم صرف‌نظر از بسته‌ای که ساخته می‌شود باید یکسان باشد، اما ممکن است بسته به این‌که از چه virtual_server استفاده می‌شود، تفاوت داشته باشد. .sp سپس، \fB\-\-testbed\-build\-pre\fP و بعد از آن \fB\-\-build\-command\fP (یا \fB\-c\fP) را داریم. برای دایرکتوری دبیان خود، وابستگی‌های ساخت را با استفاده از \fBapt\-get\fP نصب می‌کنیم، سپس خودِ دستور ساخت واقعی را با استفاده از \fBdpkg\-buildpackage(1)\fP اجرا می‌کنیم. .sp سپس، \fBsource_root\fP و \fBartifact_pattern\fP را داریم. برای بازتولیدپذیری، ما تنها به بسته‌های باینری علاقه‌مندیم. .sp در نهایت، مشخص می‌کنیم که این فرایند باید در سرور مجازی \(dqschroot\(dq با آرگومان‌های \(dqunstable\-amd64\-sbuild\(dq انجام شود. .sp البته اگر مجبور باشید یک مورد را بارها اجرا کنید، به خاطر سپردن همهٔ این موارد دشوار است. بنابراین به همین دلیل است که افزودن پیش‌تنظیم‌های جدید برای انواع بسته‌های جدید سودمند خواهد بود. .sp اینجا یک مثال پیچیده‌تر آورده شده است. این دستور به reprotest می‌گوید فرآورده‌های ساخت را برای تحلیل بعدی در \fB\&./artifacts\fP ذخیره کند؛ و همچنین پیش‌تنظیم \(dqDebian dsc\(dq را طوری تنظیم می‌کند که از زنجیره‌ابزار آزمایشی ما در \% استفاده کند: .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 در روشی دیگر، می‌توانید chroot مربوط به unstable\-amd64\-sbuild خود را کلون کرده، مخزن ما را به chroot کلون‌شده اضافه کنید، سپس از این chroot به جای \(dqunstable\-amd64\-sbuild\(dq استفاده کنید. این کار به شما امکان می‌دهد گزینهٔ طولانی \fB\-\-auto\-preset\-expr\fP در بالا را حذف کنید..SH "فایل پیکربندی (CONFIG FILE)" .sp شما همچنین می‌توانید گزینه‌ها را از طریق یک فایل پیکربندی به reprotest بدهید. این یک اقدام صرفه‌جویی در زمان، مشابه پیش‌تنظیم‌های \fBauto\fP است؛ با این تفاوت که این روش برای ساخت‌های محلی متناسب با اهداف شخصی شما مناسب‌تر است. (شما می‌توانید در یک ساخت از هر دوی پیش‌تنظیم‌ها و فایل‌های پیکربندی استفاده کنید.) .sp فایل پیکربندی دقیقاً همان گزینه‌های رابط خط فرمان را می‌پذیرد، اما با این محدودیت اضافه که نام بخش باید با نام‌های ارائه‌شده در خروجی \-\-help مطابقت داشته باشد. نویسه‌های فاصله خالی (Whitespace) فقط و فقط در صورتی مجاز هستند که گزینهٔ معادل در خط فرمان نیز فاصله را مجاز بداند. در نهایت، مشخص کردن آرگومان‌های مکانی از طریق این سازوکار امکان‌پذیر نیست. .sp دستور reprotest به‌طور پیش‌فرض هیچ فایل پیکربندی را بارگذاری نمی‌کند. می‌توانید با گزینه‌های خط فرمان \fB\-\-config\-file\fP یا \fB\-f\fP به آن بگویید که فایلی را بارگذاری کند. اگر یک دایرکتوری مانند \fB\&.\fP به آن بدهید، فایل \fB\&.reprotestrc\fP را در آن دایرکتوری بارگذاری خواهد کرد. .sp یک نمونه فایل پیکربندی در زیر آمده است: .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 "تحلیل خروجی DIFF (ANALYSING DIFF OUTPUT)" .sp به‌طور معمول هنگامی که diffoscope دایرکتوری‌ها را مقایسه می‌کند، متاداده‌های فایل‌های موجود در آن دایرکتوری‌ها \- دسترسی‌های فایل، مالکان و غیره \- را نیز مقایسه می‌کند. .sp با این حال بسته به شرایط، این متاداده در سطح سیستم‌فایل ممکن است برای توزیع به سیستم‌های دیگر در نظر گرفته شده باشد یا خیر. به عنوان مثال: (۱) برای اکثر سازندگان بسته در توزیع‌ها، متادادهٔ فایل‌های بستهٔ خروجی اهمیتی ندارد؛ تنها محتوای فایل به سیستم‌های دیگر توزیع خواهد شد. از سوی دیگر، (۲) هنگام اجرای چیزی مانند \fImake install\fP، متاداده اهمیت \fIدارد\fP، زیرا این همان چیزی است که قرار است روی سیستم دیگر بازسازی شود. .sp در توسعهٔ reprotest، تجربهٔ ما نشان داده است که حالت (۱) رایج‌تر است و بنابراین ما به‌طور پیش‌فرض \fB\-\-exclude\-directory\-metadata=yes\fP را به diffoscope ارسال می‌کنیم. اگر متوجه شدید که از reprotest برای حالت (۲) استفاده می‌کنید، باید \fB\-\-diffoscope\-args=\-\-exclude\-directory\-metadata=no\fP را به reprotest ارسال کنید تا به diffoscope بگوید از متاداده صرف‌نظر نکند، زیرا متاداده توزیع خواهد شد و بنابراین باید بازتولیدپذیر باشد. در غیر این صورت، ممکن است با یک نتیجه مثبت کاذب (false\-positive) مواجه شوید. .SH "تغییرات (VARIATIONS)" .sp پرچم‌های \-\-vary و \-\-variations در شکل سادهٔ خود، فهرستی جداشده با کاما از نام‌های تغییرات هستند که مشخص می‌کنند کدام تغییرات اعمال شوند. فهرست کامل نام‌ها در متن \-\-help برای \-\-variations آمده است. .nf با جزئیات کامل، این پرچم‌ها فهرستی جداشده با کاما از اقدامات هستند، به شرح زیر: +$variation (یا $variation بدون عملگر صریح) \-$variation .in +2 فعال یا غیرفعال کردن یک تغییر .in -2 @$variation .in +2 فعال کردن یک تغییر، و بازنشانی پارامترهای آن (در ادامه را ببینید) به مقادیر پیش‌فرض. .in -2 $variation.$param=$value $variation.$param+=$value $variation.$param\-=$value .in +2 تنظیم/افزودن/حذف $value به عنوان/به/از مقدار فعلی پارامتر $param مربوط به $variation. .in -2 $variation.$param++ $variation.$param\-\- .in +2 افزایش/کاهش مقدار پارامتر $param مربوط به $variation. .in -2 .fi .sp .sp بیشتر تغییرات پارامتری ندارند، و برای آن‌ها تنها عملگرهای + و \- کاربرد دارند. تغییراتی که پارامتر می‌پذیرند عبارتند از: .INDENT 0.0 .TP .B build_path.path مسیری که برای ساخت‌های آزمایشی هنگام فعال بودن تغییرات مسیر ساخت استفاده می‌شود. این مسیر باید در مکانی باشد که برای کاربری که ساخت را اجرا می‌کند، قابل نوشتن باشد. این گزینه (تا حدی طعنه‌آمیز) زمانی مفید است که برای یکسان‌سازی مسیر ساخت همراه با \-\-control\-build جهت مقایسه با یک ساخت موجود که با reprotest انجام نشده است، استفاده شود. .TP .B domain_host.use_sudo یک عدد صحیح، برای تعیین این‌که آیا از sudo(1) همراه با unshare(1) جهت تغییر hostname و domainname سیستم استفاده شود یا خیر. عدد 0 به معنای عدم استفاده از sudo است؛ هر مقدار غیرصِفر به معنای استفاده از sudo است. پیش‌فرض 0 است، هرچند این توصیه نمی‌شود و ممکن است باعث شکست ساخت شما شود؛ برای جزئیات به \(dqVarying the domain and host names\(dq مراجعه کنید. .TP .B environment.variables مجموعه‌ای مرتب و جداشده با نقطه‌ویرگول، که متغیرهای محیطی‌ای را مشخص می‌کند که reprotest باید برای تغییر آن‌ها تلاش کند. مقدار پیش‌فرض \(dqREPROTEST_CAPTURE_ENVIRONMENT\(dq است. از قواعد نگارشی مبتنی بر عبارات باقاعده (regex) پشتیبانی می‌کند، مانند: .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 حالت‌های خاص: .INDENT 7.0 .IP \(bu 2 $VARNAME= (سمت راست خالی) برای اعلان به reprotest جهت حذف متغیر .IP \(bu 2 $VARNAME=.{0} برای اعلان به reprotest جهت تنظیم یک مقدار واقعاً خالی .IP \(bu 2 \ex2c و \ex3b به ترتیب برای تطبیق یا تولید , و ;. .UNINDENT .TP .B user_group.available یک مجموعهٔ مرتب و جداشده با نقطه‌ویرگول، که ترکیب‌های کاربر+گروه در دسترسی را مشخص می‌کند که reprotest می‌تواند به آن‌ها \fBsudo(1)\fP کند. پیش‌فرض خالی است که در این حالت تغییر بی‌اثر خواهد بود و هشداری دربارهٔ آن مشاهده خواهید کرد. هر کاربر+گروه باید به صورت $user:$group مشخص شود که در آن هر یک از اجزا قابل حذف است، یا در صورتی که دونقطه‌ای وجود نداشته باشد تنها به عنوان یک $user بدون تغییر $group تفسیر می‌شود. .TP .B time.faketimes یک مجموعهٔ مرتب و جداشده با نقطه‌ویرگول، که توصیف‌کننده‌های زمان ممکن در \fBfaketime(1)\fP را برای استفاده مشخص می‌کند. پیش‌فرض خالی است، که در این حالت برنامه‌ یک زمان را انتخاب می‌کند: یا زمان کنونی (اگر آخرین زمان تغییر فایل در \fBsource_root\fP قدیمی‌تر از ۳۹۸ روز باشد) یا بیش از ۳۹۸ روز در آینده. .sp توجه داشته باشید که ساعت در طول ساخت به کار خود ادامه می‌دهد. امکان متوقف ساختن آن توسط \fBfaketime(1)\fP وجود دارد، اما این قابلیت هنوز پشتیبانی نمی‌شود؛ زیرا احتمال بالاتری برای ایجاد خطا در ساخت یا رفتارهای غیرمنتظره دارد. .TP .B locales.locale فهرستی جداشده با نقطه‌ویرگول از یک یا چند محلی‌سازی (locale) برای آزمایش در هنگام اعمال تغییرات محلی‌سازی‌ها. اگر چندین محلی‌سازی مشخص شده باشد، یکی به صورت تصادفی انتخاب خواهد شد. محلی‌سازی‌هایی با ویژگی‌های متفاوت از en_US.UTF\-8 عبارتند از fr_CH.UTF\-8، ru_RU.CP1251، kk_KZ.RK1048 یا zh_CN. در صورت عدم تعیین، مقدار پیش‌فرض et_EE.UTF\-8 است. .TP .B num_cpus.cpus فهرستی جداشده با نقطه‌ویرگول از یک یا چند مقدار عددی برای انتخاب تعداد پردازنده‌ها هنگام اعمال تغییرات num_cpus. .UNINDENT .sp تفاوت بین \-\-vary و \-\-variations در این است که اولی به مقادیر قبلی اضافه می‌کند، اما دومی آن‌ها را بازنشانی می‌کند. علاوه بر این، آخرین مقدار تنظیم‌شده برای \-\-variations به عنوان صفرمین آرگومان \-\-vary در نظر گرفته می‌شود. برای مثال: .INDENT 0.0 .INDENT 3.5 .sp .EX reprotest \-\-vary=\-user_group .EE .UNINDENT .UNINDENT.sp به معنای تغییر دادن +all (مقدار پیش‌فرض برای \-\-variations) و \-user_group (مقدار داده‌شده برای \-\-vary) است، در حالی که: .INDENT 0.0 .INDENT 3.5 .sp .EX reprotest \-\-variations=\-all,locales \-\-variations=home,time \-\-vary=timezone \-\-vary=\-time .EE .UNINDENT .UNINDENT .sp به معنای تغییر دادن home،‏ time (آخرین مقدار داده‌شده برای \-\-variations)، timezone و \-time (چندین مقدار داده‌شده برای \-\-vary) است، یعنی home و timezone. .SH "نکات مربوط به تغییرات (NOTES ON VARIATIONS)" .sp دستور reprotest تمام تلاش خود را می‌کند تا تغییرات را بدون فرض داشتن دسترسی کامل ریشه (root) به سیستم اعمال کند. همچنین فرض می‌کند که نرم‌افزارهای دیگری نیز ممکن است روی همان سیستم در حال اجرا باشند، بنابراین تغییراتی در سطح سیستم که فرآیندهای دیگر را تحت تأثیر قرار دهد ایجاد نمی‌کند. با توجه به این مفروضات، برخی از تغییرات با استفاده از ترفندهایی با درجات متفاوتی از غیراصولی بودن پیاده‌سازی شده‌اند که در ادامه مستند شده‌اند. .sp امیدواریم در آینده این فرضیات را برای برخی محیط‌های خاص virtual_server برداریم. این امر احتمالاً امکان اجرای روان‌تر را در آن محیط‌ها فراهم خواهد کرد. با این حال، این فرضیات برای virtual_server از نوع \(dqnull\(dq (پیش‌فرض) پابرجا خواهند ماند. .SS تعداد پردازنده‌ها (Number of CPUs) .sp ساخت شاهد (control build) تنها از ۱ پردازنده (CPU) استفاده می‌کند تا نامعین بودن (nondeterminism) احتمالی ناشی از چندریسمانی (multithreading) یا چندپردازشی (multiprocessing) را کاهش دهد. اگر مطمئن هستید که ساخت شما تحت تأثیر این موضوع قرار نمی‌گیرد (و ساخت‌های استاندارد نباید تحت تأثیر باشند)، می‌توانید \-\-min\-cpus=99999 را مشخص کنید تا از تمام هسته‌های موجود برای هر دو ساخت استفاده شود. .SS دامنه یا میزبان (Domain or host) .sp انجام این کار بدون sudo \fIممکن است\fP منجر به شکست ساخت شما شود. .sp اگر ساخت شما نیازمند انجام کارهای مرتبط با سیستم باشد \- بر خلاف مواردی که تنها به پردازش بیت‌ها و بایت‌ها می‌پردازند \- شکست محتمل است. دلیل این امر این است که فرآیند در یک فضای‌نام (namespace) جداگانه اجرا می‌شود که در آن کاربر غیرممتاز شما به نظر \(dqroot\(dq می‌رسد، اما این مسئله از جمله مانع شناسایی فایل‌های متعلق به کاربر واقعی \(dqroot\(dq توسط سیستم‌فایل می‌شود. این یکی از محدودیت‌های unshare(1) است و امکان دور زدن آن در reprotest بدون تلاشی سنگین وجود ندارد. .sp بنابراین، توصیه می‌شود این تغییر با use_sudo=1 اجرا شود. برای جلوگیری از درخواست‌های گذرواژه، بخش \(dqAvoid sudo(1) password prompts\(dq در زیر را مشاهده کنید. .sp هنگام اجرا درون یک virtual\-server: .sp روش بدون sudo با خطای \(dqOperation not permitted\(dq شکست می‌خورد، حتی اگر \fB/proc/sys/kernel/unprivileged_userns_clone\fP\& را ویرایش کرده باشید. علت این امر در حال حاضر نامشخص است. .sp روش sudo تنها در صورتی کار می‌کند که تدابیری برای جلوگیری از درخواست‌های گذرواژه sudo اتخاذ کرده باشید، زیرا کانتینرها روشی برای ورود این مقدار ندارند. .SS کاربر یا گروه (User or group) .sp اگر ترتیب فایل‌ها (fileordering) را نیز به طور هم‌زمان تغییر می‌دهید (که در حالت پیش‌فرض چنین است)، هر کاربری که استفاده می‌کنید باید عضو گروه \(dqfuse\(dq باشد. این کار را با اجرای دستور \fIusermod \-aG fuse $OTHERUSER\fP به عنوان کاربر ریشه (root) انجام دهید. .sp برای جلوگیری از درخواست گذرواژه sudo(1)، بخش \(dqAvoid sudo(1) password prompts\(dq در زیر را مشاهده کنید. .SS زمان (Time) .sp تغییر \(dqtime\(dq از \fBfaketime(1)\fP استفاده می‌کند که \fIگاهی اوقات\fP باعث بروز مشکلات عجیب و غریب با عیب‌یابی دشوار می‌شود. در گذشته، این موارد شامل موارد زیر بوده است: .INDENT 0.0 .IP \(bu 2 ساخت‌هایی که زمان نامحدودی به طول می‌انجامند؛ اگرچه این مشکل باید در نگارش‌های اخیر reprotest برطرف شده باشد. .IP \(bu 2 ساخت‌هایی با تفاوت‌های غیرقابل‌باور بزرگ ناشی از اسکریپت‌های ./configure که نتایج متفاوتی با و بدون faketime تولید می‌کنند. این مشکل همچنان روی bash و احتمالاً برخی دیگر از بسته‌های مبتنی بر autotools تأثیر می‌گذارد. .IP \(bu 2 ساخت‌هایی که به شبکه دسترسی دارند به دلیل خطاهای انقضای گواهی‌نامه و/یا سایر خطاهای امنیتی مرتبط با زمان شکست می‌خورند. (ساخت‌های شفاف نرم‌افزارهای آزاد و متن‌باز [FOSS] اساساً نباید به شبکه دسترسی داشته باشند، اما نظارت یا جلوگیری از این مورد خارج از حیطه reprotest است.) .UNINDENT .sp اگر تفاوتی را مشاهده کردید که واقعاً فکر می‌کنید نباید وجود داشته باشد، ارسال \fB\-\-variations=\-time\fP به reprotest را امتحان کنید، و/یا نتایج ما را در \% بررسی کنید که از سازوکار متفاوت (و قابل‌اطمینان‌تری) برای تغییر زمان سیستم استفاده می‌کند..SS "هسته (Kernel)" .sp دگرگونی \(dqkernel\(dq در حال حاضر برای بسته‌های مبتنی بر RPM و سایر فرآیندهای ساخت که به \fIldconfig\fP\& نیاز دارند، کار نمی‌کند. هنگام ساخت با فعال بودن این دگرگونی، \fIldconfig\fP با خطای \fIFATAL: kernel too old\fP اعتراض کرده و فرآیند ساخت را لغو می‌کند. .SH "جلوگیری از اعلان‌های گذرواژه SUDO(1) (AVOID SUDO(1) PASSWORD PROMPTS)" .sp در حال حاضر راه مناسبی برای انجام این کار وجود ندارد. روش زیر یک راه‌حل آزمایشی (EXPERIMENTAL) بوده و شکننده و ناپاکیزه است. خودتان باید تصمیم بگیرید که آیا این روش برای مورد کاربرد شما ارزشش را دارد یا خیر: .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 اطمینان حاصل کنید دگرگونی‌هایی را تعیین می‌کنید که واقعاً قصد استفاده از آن‌ها را دارید. بدیهی است که نباید کاربران دارای دسترسی بالا مانند root را برای این هدف انتخاب کنید. .sp (ساده‌سازی خروجی با استفاده از نویسه‌های عمومی (wildcards)، امکان دسترسی بدون گذرواژه برای اجرای chown روی هر چیزی در سیستم شما را فراهم می‌کند، چرا که نویسه‌های عمومی در اینجا با فاصله‌ها مطابقت دارند. مشخص نیست توسعه‌دهندگان sudo به چه چیزی فکر می‌کردند.) .sp خیر، این روش اصلاً جالب نیست \- از پیشنهادها و وصله‌ها استقبال می‌شود. .sp اگر می‌خواهید از این روش در یک سرور مجازی مانند chroot استفاده کنید، باید فایل sudoers حاصل را درون chroot خود کپی (یا سوار/mount، یا به شکلی دیگر نگاشت) کنید. .sp به عنوان مثال، برای یک schroot، باید (۱) به schroot مبدأ وارد شده و یک فایل خالی \fI/etc/sudoers.d/local\-reprotest\fP ایجاد کنید (این نکته مهم است) و سپس (۲) خط زیر را: .INDENT 0.0 .INDENT 3.5 /etc/sudoers.d/local\-reprotest /etc/sudoers.d/local\-reprotest none bind 0 0 .UNINDENT .UNINDENT .sp به fstab مربوط به schroot خود اضافه کنید. .\" End of generated man page.