[reprotest] 03/04: Improve the wording in some parts of the README
Ximin Luo
infinity0 at debian.org
Tue Jan 24 15:41:05 UTC 2017
This is an automated email from the git hooks/post-receive script.
infinity0 pushed a commit to branch master
in repository reprotest.
commit bd0315ac29c052bb9d9bf7ed99923d8286745acb
Author: Ximin Luo <infinity0 at debian.org>
Date: Tue Jan 24 16:12:44 2017 +0100
Improve the wording in some parts of the README
---
README.md | 113 +++++++++++++++++++++++++++++++++++---------------------------
TODO | 2 ++
2 files changed, 65 insertions(+), 50 deletions(-)
diff --git a/README.md b/README.md
index d67d1c9..d85a592 100644
--- a/README.md
+++ b/README.md
@@ -16,51 +16,57 @@ more. If we don't have knowledge on how to build your file or directory, you
can send a patch to us on adding this intelligence - see the reprotest.presets
python module, and adapt the existing logic.
-Before that happens, you can use the more advanced CLI to build arbitrary
-things. This takes two mandatory arguments, the build command to run and the
-build artifact file/pattern to test after running the build. For example:
+In the meantime, you can use the more advanced CLI to build arbitrary things.
+This takes two mandatory arguments, the build command to run and the build
+artifact file/pattern to test after running the build. For example:
reprotest 'python3 setup.py bdist' 'dist/*.tar.gz'
When using this from a shell:
-If the build command has spaces, you will need to quote them, e.g.
-`reprotest "debuild -b -uc -us" [..]`.
+If the build command has spaces, you will need to quote them, e.g. `reprotest
+"debuild -b -uc -us" [..]`.
-If you want to use several build artifact patterns, you will also
-need to quote them, e.g. `reprotest [..] "*.tar.gz *.tar.xz"`.
+If you want to use several build artifact patterns, or if you want to use shell
+wildcards as a pattern, you will also need to quote them, e.g. `reprotest [..]
+"*.tar.gz *.tar.xz"`.
-If your build artifacts have spaces in their names, you will need to
-quote these twice, e.g. `'"a file with spaces.gz"'` for a single
-artifact or `'"dir 1"/* "dir 2"/*'` for multiple patterns.
+If your build artifacts have spaces in their names, you will need to quote
+these twice, e.g. `'"a file with spaces.gz"'` for a single artifact or `'"dir
+1"/* "dir 2"/*'` for multiple patterns.
-To get more help for the CLI, including documentation on optional
-arguments and what they do, run:
+To get more help for the CLI, including documentation on optional arguments and
+what they do, run:
reprotest --help
- reprotest --help schroot
Running in a virtual server
===========================
You can also run the build inside what is called a "virtual server". This could
-be a container, a chroot, etc. There are different ones available, see `--help`
-full list. You run them like this:
+be a container, a chroot, etc. You run them like this:
+
+ reprotest 'python3 setup.py bdist_wheel' 'dist/*.whl' qemu /path/to/qemu.img
+ reprotest 'debuild -b -uc -us' '../*.deb' schroot unstable-amd64
- reprotest 'python3 setup.py bdist_wheel' 'dist/*.whl' qemu /path/to/qemu.img
- reprotest 'debuild -b -uc -us' '../*.deb' schroot unstable-amd64
+There are different server types available. See `--help` for a list of them,
+which appears near the top, in the "virtual_server_args" part of the
+"positional arguments" section.
-You can also run `reprotest --help <virtual_server_name>` for a full list of
-options for that particular virtual server.
+For each virtual server (e.g. "schroot"), you see which extra arguments it
+supports:
+
+ reprotest --help schroot
-You will probably have to give extra commands to reprotest, in order to set up
-your build dependencies inside the virtual server. For example, to take you
-through what the "Debian directory" preset would look like, if we ran it via
-the advanced CLI:
+When running builds inside a virtual server, you will probably have to give
+extra commands, in order to set up your build dependencies inside the virtual
+server. For example, to take you through what the "Debian directory" preset
+would look like, if we ran it via the advanced CLI:
+ # "Debian directory" preset
reprotest auto . -- schroot unstable-amd64-sbuild
- # equivalent to:
+ # In the advanced CLI, this is equivalent to roughly:
reprotest \
--testbed-init 'apt-get -y --no-install-recommends install \
util-linux disorderfs 2>/dev/null; \
@@ -86,18 +92,26 @@ in the binary packages.
Finally, we specify that this is to take place in the "schroot" virtual_server
with arguments "unstable-amd64-sbuild".
+Of course, all of this is a burden to remember, if you must run the same thing
+many times. So that is why adding new presets for new files would be good.
+
Config File
===========
-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` fields. 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.
+You can also give options to reprotest via a config file. This is a time-saving
+measure similar to `auto` presets; the difference is that these are more suited
+for local builds that are suited to your personal purposes. (You may use both
+presets and config files in the same build.)
+
+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` fields. 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 searches the working directory for `.reprotestrc`; other locations
+will be supported in the future. A sample config file is below.
[basics]
build_command = setup.py sdist
@@ -115,31 +129,29 @@ directory. A sample config file is below.
umask
-
Running the Tests
=================
-The easiest way to run the tests is with
-[Tox](https://pypi.python.org/pypi/tox). Install it,
-[Coverage](https://pypi.python.org/pypi/coverage), and
-[pytest](https://pypi.python.org/pypi/pytest). (On Debian, this can
-be done with `apt-get install python3-coverage tox python3-pytest`.)
+Tests are run with [Tox](https://pypi.python.org/pypi/tox),
+[pytest](https://pypi.python.org/pypi/pytest) and
+[Coverage](https://pypi.python.org/pypi/coverage). On Debian, this can be done
+with `apt-get install python3-coverage python3-pytest tox`.
-To run the tests, go to the root of the repository, where `tox.ini` is
-and run `tox`. For more verbose output, run `tox -- -s`.
+To run the tests, go to the root of the repository, where `tox.ini` is and run
+`tox`. For more verbose output, run `tox -- -s`.
-However, this runs the tests with no virtualization. To test that
-reprotest works correctly with virtualization, you'll need to setup
-the virtualization servers schroot and qemu.
+This runs the tests with no virtualization. To test that reprotest works
+correctly with virtualization, you'll need to setup the virtualization servers
+schroot and qemu.
-Some of the following instructions rely on Debian utilities. For
-schroot, run `mk-sbuild --debootstrap-include=devscripts stable`. (If
-you aren't on `amd64`, you'll have to include `--arch`.) For qemu,
-first `apt-get install autopkgtest vmdebootstrap qemu`, then run:
+Some of the following instructions rely on Debian utilities. For schroot, run
+`mk-sbuild --debootstrap-include=devscripts stable`. (If you aren't on
+`amd64`, you'll have to include `--arch`.) For qemu, first `apt-get install
+autopkgtest vmdebootstrap qemu`, then run:
vmdebootstrap --verbose --serial-console --distribution=sid \
- --customize=/usr/share/autopkgtest/setup-commands/setup-testbed \
- --user=adt/adt --size=10000000000 --grub --image=adt-sid.raw
+ --customize=/usr/share/autopkgtest/setup-commands/setup-testbed \
+ --user=adt/adt --size=10000000000 --grub --image=adt-sid.raw
qemu-img convert -O qcow2 adt-sid.raw adt-sid.img
rm adt-sid.raw
@@ -149,7 +161,8 @@ necessary. Move `adt-sid.img` to `linux/` under your home directory.
To log into the schroot and qemu containers, respectively, run:
sudo schroot -c source:stable-amd64
- qemu-system-x86_64 -enable-kvm -drive file=~/linux/adt-sid.img,if=virtio -net user -net nic,model=virtio -m 1024
+ qemu-system-x86_64 -enable-kvm -drive file=~/linux/adt-sid.img,if=virtio \
+ -net user -net nic,model=virtio -m 1024
After replacing `~` with your home directory.
diff --git a/TODO b/TODO
new file mode 100644
index 0000000..7cd2d21
--- /dev/null
+++ b/TODO
@@ -0,0 +1,2 @@
+- reprotest man page, reprotest -c config argument
+- make mock_build capture more stuff and test it in tests.py:test_variations
--
Alioth's /usr/local/bin/git-commit-notice on /srv/git.debian.org/git/reproducible/reprotest.git
More information about the Reproducible-commits
mailing list