[Reproducible-commits] [blog] 01/01: Add a brief intro about autopkgtest and a brief conclusion

[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 764c8119124bf76ca000ea493a4db2f3e0ee8231
Author: Ceridwen <ceridwenv at gmail.com>
Date:   Tue Jun 21 09:48:33 2016 -0400

    Add a brief intro about autopkgtest and a brief conclusion
---
 drafts/people/ceridwen/reprotest_week4.mdwn | 47 +++++++++++++++++++----------
 1 file changed, 31 insertions(+), 16 deletions(-)

diff --git a/drafts/people/ceridwen/reprotest_week4.mdwn b/drafts/people/ceridwen/reprotest_week4.mdwn
index cb22c3e..373fb57 100644
--- a/drafts/people/ceridwen/reprotest_week4.mdwn
+++ b/drafts/people/ceridwen/reprotest_week4.mdwn
@@ -3,11 +3,19 @@
 [[!tag reproducible_builds Debian reprotest Outreachy]]
 Author: ceridwen
 
+reprotest is now in Debian's NEW package queue, so it should soon be
+available for install through apt.
+
 I've spent most of the past week reverse-engineering autopkgtest, with
 some help from the maintainer, [Martin
-Pitt](https://www.piware.de/tag/autopkgtest/).
-
-TODO: give a brief overview of why I'm using autopkgtest's code.
+Pitt](https://www.piware.de/tag/autopkgtest/).  As its name suggests,
+[autopkgtest](https://people.debian.org/~mpitt/autopkgtest/README.running-tests.html)
+is a tool for running Debian/Ubuntu package tests.  The key overlap
+with reprotest is that it can create containers (what the autopkgtest
+documentation calls "virtualization servers" or "virt-servers") and
+then run tests in them.  While reprotest builds packages and diffs
+binaries instead, the process of copying source trees and executing
+commands is much the same, so I can reuse a lot of the code.
 
 As I outlined [last
 week](https://reproducible.alioth.debian.org/blog/posts/people/ceridwen/reprotest_week3/),
@@ -77,19 +85,22 @@ directory layouts for Python packages, so an absolute path like
 The main code of reprotest at the moment lives in its `__init__.py`.
 The autopkgtest CLI of the main runner is specific to running tests,
 so my entry point is going to be `adt_testbed`.  My first attempt to
-refactor this involved putting an empty `__init__.py` in `lib/` to turn
-into a package so that I could import the modules in the files in `lib/`
-using code like `from reprotest.lib import adtlog`.  This works fine
-for the files in `lib/` and makes `adt_testbed` importable in the main
-`__init__.py`.  However, the executables in `virt/`, which are invoked
-by `subprocess` calls in adt_testbed.py, *also* need to import modules
-from `lib/` for the various `adtlog` functions and the timeout functions
-in `VirtSubproc`.  I haven't been able to find a simple modification
-of `sys.path` that allows the new Python processes launched from `virt/`
-to properly import `reprotest.lib` as a package, which means I'm
-looking at some kind of larger refactoring, either changing all the
-`subprocess` calls in `adt_testbed` so they work with `reprotest.virt`
-as a subpackage or reorganizing the rest of the code somehow.
+refactor this involved putting an empty `__init__.py` in `lib/` to
+turn into a package so that I could import the modules in the files in
+`lib/` using code like `from reprotest.lib import adtlog`.  This works
+fine for the files in `lib/` and makes `adt_testbed` importable in the
+main `__init__.py`.  However, the executables in `virt/`, which are
+invoked by `subprocess` calls in adt_testbed.py, *also* need to import
+modules from `lib/` for the various `adtlog` functions and the timeout
+functions in `VirtSubproc`.  After some trial-and-error, by replacing
+the `sys.path` mutations in `virt/` with `sys.path.insert(0,
+os.path.dirname(os.path.dirname(os.path.dirname(os.path.abspath(__file__)))))`,
+I managed to get the executables to run, though I still need to verify
+that this works for both PyPi and apt.  I'm not sure if this is the
+best solution, so I may end up doing some kind of larger refactoring,
+either changing all the `subprocess` calls in `adt_testbed` so they
+work with `reprotest.virt` as a subpackage or reorganizing the rest of
+the code somehow.
 
 It's still not clear to me why autopkgtest uses its own special logging
 module rather than the standard library's `logging` module.  I thought
@@ -100,3 +111,7 @@ case.  Another problem related to logging and debugging is that the
 programs in `virt/` interact through stdin and stdout, which means that
 I haven't been able to use simple prints to help work out their state
 during execution.
+
+Now that I have `adt_testbed` working, my next step is to change the
+code I've already written so that instead of executing commands
+directly, it executes them through the autopkgtest interface.
\ No newline at end of file

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