[Reproducible-commits] [blog] 01/01: Reprotest week 2 draft blog post

[Ceridwen]

This is an automated email from the git hooks/post-receive script.

ceridwen-guest pushed a commit to branch master
in repository blog.

commit e3aff0d9c0c689b1835ea492b6be16328c0397fd
Author: Ceridwen <ceridwenv at gmail.com>
Date:   Mon Jun 6 17:48:21 2016 -0400

    Reprotest week 2 draft blog post
---
 drafts/people/ceridwen/reprotest_week2.mdwn | 104 ++++++++++++++++++++++++++++
 1 file changed, 104 insertions(+)

diff --git a/drafts/people/ceridwen/reprotest_week2.mdwn b/drafts/people/ceridwen/reprotest_week2.mdwn
new file mode 100644
index 0000000..4fd129f
--- /dev/null
+++ b/drafts/people/ceridwen/reprotest_week2.mdwn
@@ -0,0 +1,104 @@
+[[!meta title="Reprotest has a basic CLI and basic configuration file handling"]]
+[[!meta date="Mon Jun  6 15:08:30 2016 +0000"]]
+[[!tag reproducible_builds Debian reprotest Outreachy]]
+Author: ceridwen
+
+Reprotest's CLI takes two mandatory arguments, the build command to
+run and the build artifact file to test after running the build.  If
+the build command or build artifact have spaces, they have to be
+passed as strings, e.g. "debuild -b -uc -us."  For optional arguments,
+it has --variations, which accepts a list of possible build variations
+to test, one or more of 'captures_environment', 'cpu', 'domain',
+'filesystem', 'group', 'home', 'host', 'kernel', 'locales',
+'namespace', 'path', 'shell', 'time', 'timezone', 'umask', and 'user'
+(see
+[variations](https://tests.reproducible-builds.org/index_variations.html)
+for more information); --dont_vary, which makes reprotest *not* test
+any variations in its list (the default is to run all variations);
+--source_root, which accepts a directory to run the build command in
+and defaults to the current working directory; and --verbose, which
+will eventually enable more detailed logging.  To get help for the
+CLI, run reprotest -h or reprotest --help.
+
+The config file has one section, basics, and the same options as the
+CLI, except there's no dont_vary option, and there are build_command
+and artifact options.  If build_command and/or artifact are set in the
+config file, reprotest can be run without passing those as
+command-line arguments.  Command-line arguments always override config
+file options.  Reprotest currently searches the working directory for
+the config file, but it will also eventually search the user's home
+directory.  A sample config file is below.
+
+```
+[basics]
+build_command = setup.py build
+artifact = build/
+source_root = reprotest/
+variations =
+  captures_environment
+  cpu
+  domain
+  filesystem
+  group
+  home
+  host
+  kernel
+  locales
+  namespace
+  path
+  shell
+  time
+  timezone
+  umask
+  user
+```
+
+At the moment, the only build variations that reprotest actually tests
+are the environment variable variations: captures_environment, home,
+locales, and timezone.  Over the next week, I plan to add the rest of
+the basic variations and accompanying tests.  I also need to write
+tests for the CLI and the configuration file.  After that, I intend to
+work on getting (s)chroot communication working, which will involve
+integrating autopkgtest code.
+
+Some of the variations require specific other packages to be
+installed: for instance, the locales variation currently requires the
+fr_CH.UTF-8 locale.  Locales are a particular problem because I don't
+know of a way in Debian to specify that a given locale must be
+installed.  For other packages, it's unclear to me whether I should
+specify them as depends or recommends: they aren't dependencies in a
+strict sense, but marking them as dependencies will make it easier to
+install a fully-functional reprotest.  When reprotest runs with
+variations enabled that it can't test because it doesn't have the
+correct packages installed, I intend to have it print a warning but
+continue to run.
+
+[tests.reproducible-builds.org](https://tests.reproducible-builds.org/)
+also has different settings, such as different locales, for different
+architectures.  I'm not clear on why this is.  I'd prefer to avoid
+having to generate a giant list of variations based on architecture,
+but if necessary, I can do that.  The
+[prebuilder](https://anonscm.debian.org/cgit/reproducible/misc.git/tree/prebuilder)
+script contains variations specific to Linux, to Debian, and to
+pbuilder/cowbuilder.  I'm not including Debian-specific variations
+until I get much more of the basic functionality implemented, and I'm
+not sure I'm going to include pbuilder-specific variations ever,
+because it's probably better for extensibility to other OSes,
+e.g. BSD, to add support for plugins or more complicated
+configurations.
+
+I implemented the variations by creating a function for each
+variation.  Each function takes as input two build commands, two
+source trees, and two sets of environment variables and returns the
+same.  At the moment, I'm using dictionaries for the environment
+variables, mutating them in-place and passing the references forward.
+I'm probably going to replace those at some point with an immutable
+mapping.  While at the moment, reprotest only builds on the existing
+system, when I start extending it to other build environments, this
+will require double-dispatch, because the code that needs to be
+executed will depend on both the variation to be tested and the
+environment being built on.  At the moment, I'm probably going to
+implement this with a dictionary with tuple keys of
+(build_environment, variation) or nested dictionaries.  If it's
+necessary for code to depend on OS or architecture, too, this could
+end up becoming a triple or quadruple dispatch.

-- 
Alioth's /usr/local/bin/git-commit-notice on /srv/git.debian.org/git/reproducible/blog.git