[Reproducible-commits] [blog] 01/01: Reprotest week 10 draft report
Ceridwen
ceridwen-guest at moszumanska.debian.org
Mon Aug 8 14:15:57 UTC 2016
This is an automated email from the git hooks/post-receive script.
ceridwen-guest pushed a commit to branch master
in repository blog.
commit 8ba9153a21361fe90600555f439e8dff62a40196
Author: Ceridwen <ceridwenv at gmail.com>
Date: Mon Aug 8 10:15:51 2016 -0400
Reprotest week 10 draft report
---
drafts/people/ceridwen/reprotest_week10.mdwn | 89 ++++++++++++++++++++++++++++
posts/people/ceridwen/reprotest_week9.mdwn | 2 +-
2 files changed, 90 insertions(+), 1 deletion(-)
diff --git a/drafts/people/ceridwen/reprotest_week10.mdwn b/drafts/people/ceridwen/reprotest_week10.mdwn
new file mode 100644
index 0000000..c9d8fab
--- /dev/null
+++ b/drafts/people/ceridwen/reprotest_week10.mdwn
@@ -0,0 +1,89 @@
+[[!meta title="Finishing the final variations"]]
+[[!meta date=""]]
+[[!tag reproducible_builds Debian reprotest Outreachy]]
+Author: ceridwen
+
+I've been working on getting the last of the variations working. With
+no responses on the mailing list from anyone outside Debian and with
+limited time remaining, with Lunar I've decided to deemphasize it.
+
+1. Build path is done.
+
+2. Host and domain name use `domainname` and `hostname`. This
+ [site](http://www.math.utah.edu/~beebe/unix/unix-commands.html) is
+ old, but it indicates that
+ [`domainname`](http://www.math.utah.edu/~beebe/unix/d/domainname.html)
+ was available on most OSes and
+ [`hostname`](http://www.math.utah.edu/~beebe/unix/h/hostname.html)
+ was available everywhere as of 2004. Prebuilder uses a
+ Linux-specific utility (`unshare --uts`) to run this variation in a
+ chroot, but I'm not doing this for reprotest: if you want this
+ variation, use qemu.
+
+3. User/group will not be portable, because they'll rely on
+ `useradd`/`groupadd` and `su`. `useradd` and `groupadd` work on
+ [many](http://bhami.com/rosetta.html) but not all OSes, notably not
+ including FreeBSD or MacOS X. `su` was
+ [universal](http://www.math.utah.edu/~beebe/unix/s/su.html)
+ in 2004.
+
+4. Time is not done but will probably be portable to some systems,
+ because it will rely on `date -s`. Unfortunately, I haven't been
+ able to find any information on how common `date -s` is across
+ Unix-like OSes, as the `-s` option is not part of the POSIX
+ standard.
+
+5. At the moment, I have no idea how to implement changes for
+ `/bin/sh` and the login shell that will even work across different
+ distributions of Linux, much less different OSes. There are a
+ couple of key problems, starting with the need to find two
+ *different* shells to use, because there's no way to find out what
+ shells are installed. This
+ [blog post](https://utcc.utoronto.ca/~cks/space/blog/unix/EtcShellsUsage)
+ explains why `/etc/shells` doesn't work well for finding what
+ shells are available: not everything in `/etc/shells` is
+ necessarily a shell (Ubuntu has `/usr/bin/screen`) and not all
+ available shells are in `/etc/shells`. Also, there's no good way
+ to find out what shell is the system default because `/bin/sh` can
+ be an arbitrary binary, not a symlink,and no good way to identify
+ what it is if it is a binary. I can hard-code shell choices, but
+ which shells? bash is obvious for Linux, but what's the best
+ second choice?
+
+On other topics:
+
+1. [reprotest fails to build properly on jessie](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=832962):
+ Lunar said, and I agree, that fixing this is not a priority. I
+ need someone with more knowledge of Debian Python packaging to help
+ me. If I'm going to support old versions, I also need some kind of
+ CI server, because I don't have the time or ability to maintain old
+ versions of Debian and Python myself.
+
+2. [libc-bin: ldconfig segfaults when run using "setarch uname26"](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=806911):
+ I don't have a good solution for this, but I don't want to hard-code
+ and
+ maintain an architecture-specific disable. Would changing the
+ argument to setarch work around the segfault? Is there a way to
+ test for the presence of the bug that won't cause a segfault or
+ similar crash?
+
+3. [Please put adt-virt-* binaries back onto PATH](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=833407):
+ reprotest is not affected by this change because I forked the
+ autopkgtest code rather than depending on it, so that reprotest can
+ be installed through PyPi. At the moment, reprotest doesn't make
+ its versions of the programs in `virt/` available on `$PATH`. This
+ is primarily because of the problems with distributing command-line
+ scripts with setuptools. The approach I'm currently using,
+ including the `virt/` programs as non-code data with `include
+ reprotest/virt/*` in MANIFEST.in, doesn't install them to make them
+ available for other programs. Using one of the other approaches
+ potentially could, but it's difficult to make the imports work with
+ those approaches. (I haven't found a way to do it.) I think the
+ best solution to this approach is to split autopkgtest into the
+ Debian-specific components and the general-purpose virtualization
+ components, but I don't have the time to do this myself or to
+ negotiate with Martin Pitt, if he'd even be receptive. I'm also
+ unsure at this point if it wouldn't be better for reprotest to
+ switch from autopkgtest to using something like Ansible to run the
+ virtualization, because Ansible has some solved some of the
+ portability problems already and is not tied to Debian.
diff --git a/posts/people/ceridwen/reprotest_week9.mdwn b/posts/people/ceridwen/reprotest_week9.mdwn
index b472329..78836ce 100644
--- a/posts/people/ceridwen/reprotest_week9.mdwn
+++ b/posts/people/ceridwen/reprotest_week9.mdwn
@@ -1,5 +1,5 @@
[[!meta title="Reprotest 0.2 released, with virtualization support"]]
-[[!meta date="Mon, 25 Jul 2016 14:54:47 -0400"]]
+[[!meta date="Tue, 26 Jul 2016 15:18:23 -0400"]]
[[!tag reproducible_builds Debian reprotest Outreachy]]
Author: ceridwen
--
Alioth's /usr/local/bin/git-commit-notice on /srv/git.debian.org/git/reproducible/blog.git
More information about the Reproducible-commits
mailing list