Re: [Reproducible-builds] Remaining reprotest variations
> > 1. user_group. The POSIX standard includes the notion of > > user/group > > ids, but the only ways it defines to change the uid/gid of > > processes > > are C functions. Unfortunately, there's also nothing in the POSIX > > standard for creating users, though at least `chown` is. At the > > moment, my plan is to use `useradd`, `groupadd`, `userdel`, > > `groupdel`, and `su`. (Using 'sudo' like prebuilder does is more > > complicated and less likely to be supported everywhere.) I'm going > > to > > set the ids to something like 2. This page, > > http://bhami.com/rosetta.html, indicates that this won't work on > > FreeBSD or MacOS X, and thatis supported by these pages, > > http://www.math.utah.edu/~beebe/unix/g/groupadd.html and > > http://www.math.utah.edu/~beebe/unix/u/useradd.html. > > - What works on FreeBSD/MacOS X? > > - Are there any other problems I'm likely to encounter using > > `su`? > If the code abstract user creation/removal depending on the system of > the execution environment, we could implement (more) specific > behaviors > when required. Maybe that could be an answer: make it so experts in > other operation system can easily add support? This is already done: which context managers get executed depends on whether a variation is implemented, which build it is (first or second), whether reprotest has root on the given testbed, and what the testbed's OS is. I haven't written documentation for it yet, but it's straightforward-ish to write a new Python context manager for a specific case. I'm going to go ahead and implement the time variation and a flag for the possibly-system-breaking variations. Ceridwen ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
[Reproducible-builds] Remaining reprotest variations
For most of the variations I've done so far, I've been either depending on external utilities or had POSIX-compliant ways to execute them. The rest of the variations pose more problems. 1. user_group. The POSIX standard includes the notion of user/group ids, but the only ways it defines to change the uid/gid of processes are C functions. Unfortunately, there's also nothing in the POSIX standard for creating users, though at least `chown` is. At the moment, my plan is to use `useradd`, `groupadd`, `userdel`, `groupdel`, and `su`. (Using 'sudo' like prebuilder does is more complicated and less likely to be supported everywhere.) I'm going to set the ids to something like 2. This page, http://bhami.com/rosetta.html, indicates that this won't work on FreeBSD or MacOS X, and thatis supported by these pages, http://www.math.utah.edu/~beebe/unix/g/groupadd.html and http://www.math.utah.edu/~beebe/unix/u/useradd.html. - What works on FreeBSD/MacOS X? - Are there any other problems I'm likely to encounter using `su`? 2. host and domain. Host name is only only mentioned in the POSIX standard in the context of uname and some C functions for getting information about it, and domain name isn't mentioned at all in the standard, AFAICT. However, according to http://www.math.utah.edu/~beebe/unix/h/hostname.html and http://www.math.utah.edu/~beebe/unix/d/domainname.html, `hostname` is universal enough, and since Linux now has `domainname`, it is too. The prebuilder script also modifies `/etc/hosts`. - Is modifying /etc/hosts necessary in general? - If so, is it portable? - If not, what modifications are necessary on other distros and OSes? 3. bin_sh. prebuilder uses dpkg-reconfigure here, which doesn't work for reprotest. - Is it safe to assume that /bin/sh is a symlink? - What shells should be available on most POSIX systems? - Does this variation need to search for available shells? - If so, Is there a portable way to determine what shells are available? 4. user_shell: prebuilder uses `usermod`, but there's also `chsh`. `chsh` looks a little more common: http://www.math.utah.edu/~beebe/unix/c/chsh.html vs. http://www.math.utah.edu/~beebe/unix/u/usermod.html. I also don't know if all versions of `usermod` support the -s option. - Will `chsh` work here? - If not, has `usermod`'s portability improved? 5. kernel: While `uname` is in the POSIX standard, mechanisms for altering its output aren't. `setarch`, what prebuilder uses and what reprotest uses at the moment, is Linux-specific. - What methods of changing `uname` will work on other OSes? 5. locales: Is there a portable way to figure out what locales are available? 6. time: tests.reproducible-builds.org sets the system clock into the future for some machines, which doesn't work here. I can try to use libfaketime for non-qemu environments and make the VM clock independent for qemu, but this is likely to get very tricky. How much time should I spend on this? Beyond the specific variations, I have some questions about reversion that apply to several variations. I'm trying to have reprotest revert all the changes it makes on its own, to make it more useful for simpler execution environments, but guaranteeing this under all conditions is tricky. * If reprotest is called as root without any virtualization (i.e. null), should it attempt to run the variations that require root privileges on the host system? These are host, domain, bin_sh, and user_group. I'm reluctant to disable this functionality altogether, because I can see someone wanting it, but it definitely has the potential to cause undesirable side effects if something goes wrong. * Along the same line, `chsh` affects all user shells. This doesn't require root privileges, but should it be tested without virtualization? * Are there any other variations which shouldn't be tested in some of the execution environments without full reversion capabilities? Ceridwen ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
[Reproducible-builds] Should reprotest set $HOME to an existent or nonexistent directory?
It came up in discussion of this bug that setting $HOME to a nonexistent directory causes a build to generate errors: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=829113 At the moment, reprotest sets $HOME to '/nonexistent/first-build' and '/nonexistent/second-build', following the prebuilder script in this. (Neither prebuilder nor reprotest guarantee that those directories don't exist.) As Lunar said, one possible alternate fix for that specific bug is to create two different temporary directories and set $HOME to those directories instead. Is this a good idea? Ceridwen ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
Re: [Reproducible-builds] Reprotest week 59 blog comments
On Fri, 2016-06-17 at 19:13 +0200, Ximin Luo wrote: > > 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. > > You should specify these as Recommends, the definition matches what > you just described [1]. Also see how diffoscope does things. > > [1] https://www.debian.org/doc/debian-policy/ch-relationships.html#s- > binarydeps starting from "The meaning of the five dependency fields > is as follows:" autopkgtest has these as Suggests rather than Recommends, and I followed its example. On Lunar's suggestion, for the first alpha release I'm removing them altogether since the functionality that requires them isn't working yet. When I get the functionality, I will put them back as Recommends if everyone agrees about that. > I'd say it's better to fail fast. Warnings can easily be missed. If > the user really doesn't want to test a variation, they can disable it > using the mechanisms you already mentioned. I will make it so that if a variation *is* available for a particular environment/container but can't be executed because something is missing, reprotest will error out. Since not all environments/containers can test all variations, I don't think it will be useful to force users to go through and disable all the variations that can't be tested on the environment/container they want to run it on. For instance, I'm not going to have reprotest complain that when building on an existing system, the variations that require superuser privileges aren't available. > > Locales are a particular problem because I don't know of a way in > > Debian to specify that a given locale must be installed. > > All locales are installed by default (unless you install the > "localepurge" package, which is an unsupported hack that you don't > need to worry about), so you just need to reconfigure the locales > package to "generate" the fr locale. I'm not sure how this works > exactly, but you can look into it. You can do it manually via `sudo > dpkg-reconfigure locales` but you might be able to script this within > reprotest. The bigger problem here is that since I'm designing reprotest not to be useful just for Debian-based systems, as far as I know there's no general way to control which locales are available. What about BSD and MacOS? The prebuilder script hard-codes certain locales, which vary by architecture on tests.reproducible-builds.org. From asking in IRC, as far as I know different locales were chosen for different architectures simply to test more different locales on t.rb.o. Some accompanying questions about locales: * Should reprotest also hard-code certain locales? * If more than one locale is hard-coded, how does it pick which locales to test with? * Given the behavior above, where it errors out if something it needs to test a variation isn't available, should it error out if a hard -coded locale is missing, or should it fall back on some other locale? If it falls back, how should it pick which locale to fall back too? * Should it be able to test more than two different locales? Should this be the default? This makes things more complicated and potentially a lot slower. * How do I communicate to the users all of this locale handling in a transparent and simple way? I'm a little averse to hard-coding specific locales, but I don't have great solutions for any of these problems. > > 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. "Double-dispatch" in this case just means that there are two parameters that determine what code needs to be run, in this case the variation and the environment. Ceridwen ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
[Reproducible-builds] Bug#826894: diffoscope --help isn't clear that it operates on directories as well as files
Source: diffoscope Version: 54 Severity: minor User: reproducible-builds@lists.alioth.debian.org Dear Maintainer, The --help text for diffoscope gives no indication that it operates on directories as well as files: usage: diffoscope [-h] [--version] [--list-tools [LIST_TOOLS]] [--debug] [--debugger] [--html output] [--html-dir output] [--text output] [--max-report-size BYTES] [--separate-file-diff-size BYTES] [--max-diff-block-lines MAX_DIFF_BLOCK_LINES] [--max-diff-input-lines MAX_DIFF_INPUT_LINES] [--fuzzy-threshold FUZZY_THRESHOLD] [--new-file] [--css url] [--jquery url] file1 file2 Highlight differences between two builds of Debian packages positional arguments: file1 first file to compare file2 second file to compare This should give some indication that diffoscope can compare directories as well as files. -- System Information: Debian Release: jessie/sid APT prefers wily-updates APT policy: (500, 'wily-updates'), (500, 'wily-security'), (500, 'wily'), (100, 'wily-backports') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.2.0-36-generic (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
