[Piuparts-commits] rev 306 - in trunk: . debian
Holger Levsen
holger at alioth.debian.org
Wed Apr 1 09:57:28 UTC 2009
Author: holger
Date: 2009-04-01 09:57:28 +0000 (Wed, 01 Apr 2009)
New Revision: 306
Removed:
trunk/piuparts.css
Modified:
trunk/README.txt
trunk/TODO
trunk/debian/changelog
trunk/debian/control
trunk/piuparts-slave.py
trunk/piuparts.py
Log:
- add advice how to read the logfile to the top of the logfiles produced.
- convert README.txt to asciidoc
* Remove unused file piuparts.css.
Modified: trunk/README.txt
===================================================================
--- trunk/README.txt 2009-03-31 17:31:24 UTC (rev 305)
+++ trunk/README.txt 2009-04-01 09:57:28 UTC (rev 306)
@@ -8,22 +8,23 @@
Introduction
~~~~~~~~~~~~
- This is a tool for testing that .deb packages can be
- installed, upgraded, and removed without problems. The
- name, a variant of something suggested by Tollef Fog
- Heen, is short for "package installation, upgrading, and
- removal testing suite".
+This is a tool for testing that .deb packages can be
+installed, upgraded, and removed without problems. The
+name, a variant of something suggested by Tollef Fog
+Heen, is short for "package installation, upgrading, and
+removal testing suite".
+
+See the manual page for more information about using
+the program.
+
+You need at least Python 2.3 and debootstrap. The
+version of debootstrap in the Debian 3.1 release
+(codename sarge) is too old.
+
+piuparts is licensed under the GNU General Public
+License, version 2, or (at your option) any later version.
+
- See the manual page for more information about using
- the program.
-
- You need at least Python 2.3 and debootstrap. The
- version of debootstrap in the Debian 3.1 release
- (codename sarge) is too old.
-
- piuparts is licensed under the GNU General Public
- License, version 2.
-
How to use piuparts in 5 minutes
--------------------------------
@@ -34,11 +35,11 @@
Testing your packages with piuparts is as easy as typing at the console prompt:
----
- # piuparts sm_0.6-1_i386.deb
+# piuparts sm_0.6-1_i386.deb
----
Note that in order to work, piuparts has to be executed as user root, so you
-need to be logged as root or use sudo.
+need to be logged as root or use 'sudo'.
This will create a sid chroot with debootstrap, where it'll test your package.
@@ -46,7 +47,7 @@
do so with:
----
- # piuparts sm_0.6-1_i386.deb -d lenny
+# piuparts sm_0.6-1_i386.deb -d lenny
----
By default, this will read the first mirror from your '/etc/apt/sources.list '
@@ -54,7 +55,7 @@
'-m':
----
- # piuparts sm_0.6-1_i386.deb -m http://ftp.de.debian.org/debian
+# piuparts sm_0.6-1_i386.deb -m http://ftp.de.debian.org/debian
----
@@ -71,41 +72,42 @@
create this tarball with the command (again, as root):
----
- # pbuilder create
+# pbuilder create
----
then you only have to remember to update this tarball with:
----
- # pbuilder update.
+# pbuilder update
----
To run piuparts using this tarball:
----
- # piuparts -p sm_0.6-1_i386.deb
+# piuparts -p sm_0.6-1_i386.deb
----
If you want to use your own pre-made tarball:
----
- # piuparts --basetgz=/path/to/my/tarball.tgz sm_0.6-1_i386.deb
+# piuparts --basetgz=/path/to/my/tarball.tgz sm_0.6-1_i386.deb
----
Piuparts also has the option of using a tarball as the contents of the initial
chroot, instead of building a new one with pbuilder. You can save a tarball
-for later use with the -s (--save) piuparts option. Some people like this,
+for later use with the '-s' ('--save') piuparts option. Some people like this,
others prefer to only have to maintain one tarball. Read the piuparts manpage
-about the -p, -b and -s options
+about the '-p', '-b' and '-s' options
-* Piuparts tests
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Piuparts tests
+~~~~~~~~~~~~~~
By default, piuparts does two tests:
-1 - Installation and purging test.
-2 - Installation, upgrade and purging tests.
+. Installation and purging test.
+. Installation, upgrade and purging tests.
+
The first test installs the package in a minimal chroot, removes it and purges
it. The second test installs the current version in the archive of the given
packages, then upgrades to the new version (deb files given to piuparts in the
@@ -115,15 +117,15 @@
'--no-upgrade-test'
-* Analyzing piuparts results
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Analyzing piuparts results
+~~~~~~~~~~~~~~~~~~~~~~~~~~
When piuparts finishes all the tests satisfactorily, you will get these lines
as final output:
----
- 0m39.5s INFO: PASS: All tests.
- 0m39.5s INFO: piuparts run ends.
+0m39.5s INFO: PASS: All tests.
+0m39.5s INFO: piuparts run ends.
----
Anyway, it is a good idea to read the whole log in order to discover possible
@@ -141,30 +143,36 @@
The scripts can be run:
- Before *installing* your package. The name of the script must
- start with:
- 'pre_install_'
+Before *installing* your package. The name of the script must
+start with:
- After *installing* your package and its deps. In the case of the
- upgrade test, it is after install and upgrade. The name of the
- script must start with:
- 'post_install_'
+'pre_install_'
- After *removing* your package, The name of the script must start with:
- 'post_remove_'
+After *installing* your package and its deps. In the case of the
+upgrade test, it is after install and upgrade. The name of the
+script must start with:
- After *purging* your package, The name of the script must start with:
- 'post_purge_'
+'post_install_'
- Before *upgrading* your package, once the current version in the archive
- has been installed (this is done in the second test, "Installation,
- upgrade and purging test"). The name of the script must start with:
- 'pre_upgrade_'
+After *removing* your package, The name of the script must start with:
- Before upgrading the chroot to another distro and after upgrading:
- 'pre_distupgrade_'
- 'post_distupgrade_'
+'post_remove_'
+After *purging* your package, The name of the script must start with:
+
+'post_purge_'
+
+Before *upgrading* your package, once the current version in the archive
+has been installed (this is done in the second test, "Installation,
+upgrade and purging test"). The name of the script must start with:
+
+'pre_upgrade_'
+
+Before upgrading the chroot to another distro and after upgrading:
+
+'pre_distupgrade_'
+'post_distupgrade_'
+
You can run several scripts in every step, they are run in alphabetical
order.
@@ -181,7 +189,7 @@
Example custom script:
~~~~~~~~~~~~~~~~~~~~~~
-'$cat post_install_number.sh'
+'$ cat post_install_number.sh'
----
#!/bin/bash
@@ -194,175 +202,158 @@
Distrubuted testing
-------------------
- As part of the quality assurance effort of Debian,
- piuparts is run on the Debian package archive. This requires a
- lot of processing power, and so the work can be distributed
- over several hosts.
+As part of the quality assurance effort of Debian,
+piuparts is run on the Debian package archive. This requires a
+lot of processing power, and so the work can be distributed
+over several hosts.
- There is one central machine, the master, and any number
- of slave machines. Each slave machine connects to the
- master, via ssh, and runs the piuparts-master program to
- report results of packages it has tested already, and to
- get more work.
-
- To set this up for yourself, the following steps should
- suffice:
-
- 1. Pick a machine to run the master. It cannot be a chroot,
- but a etch system is good enough.
- 2. Install piuparts on it.
- 3. Create an account for the master.
- 4. Configure '/etc/piuparts/piuparts.conf' appropriately.
-
- 5. Pick one or more slaves to run the slave. You can use
- the machine running the master also as a slave. Etch is
- fine, it can even be in a chroot.
- 6. Install piuparts on it.
- 7. Configure '/etc/piuparts/piuparts.conf' appropriately -
- if master and slave share the machine, they also share
- the config file.
- 8. Create an account for the slave. This must be different
- from the master account.
- 9. Create an ssh keypair for the slave. No passphrase.
- 10. Add the slave's public key to the master's
- '.ssh/authorized_keys'
- 11. Configure sudo on the slave machine to allow the slave
- account run '/usr/sbin/piuparts' as root without password
- (otherwise you'll be typing in a password all the time).
+There is one central machine, the master, and any number
+of slave machines. Each slave machine connects to the
+master, via ssh, and runs the piuparts-master program to
+report results of packages it has tested already, and to
+get more work.
- 12. Run '/usr/share/piuparts/piuparts-slave' on the slave
- accounts. Packages that are installed want to use
- '/dev/tty', so you can't do this from cron. Also, you'll
- want to keep an eye on what is happening, to catch
- runaway processes and stuff.
+To set this up for yourself, the following steps should
+suffice:
- 13. The logs go into the master account, into
- subdirectories.
+. Pick a machine to run the master. It cannot be a chroot, but a etch system is good enough.
+. Install piuparts on it.
+. Create an account for the master.
+. Configure '/etc/piuparts/piuparts.conf' appropriately.
+. Pick one or more slaves to run the slave. You can use the machine running the master also as a slave. Etch is fine, it can even be in a chroot.
+. Install piuparts on it.
+. Configure '/etc/piuparts/piuparts.conf' appropriately - if master and slave share the machine, they also share the config file.
+. Create an account for the slave. This must be different from the master account.
+. Create an ssh keypair for the slave. No passphrase.
+. Add the slave's public key to the master's '.ssh/authorized_keys'
+. Configure sudo on the slave machine to allow the slave account run '/usr/sbin/piuparts' as root without password (otherwise you'll be typing in a password all the time).
+. Run '/usr/share/piuparts/piuparts-slave' on the slave accounts. Packages that are installed want to use '/dev/tty', so you can't do this from cron. Also, you'll want to keep an eye on what is happening, to catch runaway processes and stuff.
+. The logs go into the master account, into subdirectories.
- Please note that running piuparts this way is somewhat
- risky, to say the least. There are security implications
- that you want to consider. It's best to do it on
- machines that you don't mind wiping clean at a moment's
- notice, and preferably so that they don't have direct
- network access.
+Please note that running piuparts this way is somewhat
+risky, to say the least. There are security implications
+that you want to consider. It's best to do it on
+machines that you don't mind wiping clean at a moment's
+notice, and preferably so that they don't have direct
+network access.
Distributed piuparts testing protocol
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
- The slave machine and the piuparts-master program
- communicate using a simplistic line based protocol. SSH
- takes care of authentication, so there is nothing in the
- protocol for that. The protocol is transaction based:
- the slave gives a command, the master program responds.
- Commands and responses can be simple (a single line) or
- long (a status line plus additional data lines). Simple
- commands and responses are of the following format:
-
- 'keyword arg1 arg2 arg3 ... argN'
-
- The keyword is a command or status code ("ok"), and it
- and the arguments are separated by spaces. An argument
- may not contain a space.
-
- A long command or response is deduced from the context:
- certain commands always include additional data, and
- certain commands always get a long response, if
- successful (error responses are always simple). The
- first line of a long command or response is the same as
- for a simple one, the additional lines are prefixed with
- a space, and followed by a line containing only a
- period.
-
- A sample session (">>" indicates what the slave sends,
- "<<" what the master responds with):
+The slave machine and the piuparts-master program
+communicate using a simplistic line based protocol. SSH
+takes care of authentication, so there is nothing in the
+protocol for that. The protocol is transaction based:
+the slave gives a command, the master program responds.
+Commands and responses can be simple (a single line) or
+long (a status line plus additional data lines). Simple
+commands and responses are of the following format:
+ 'keyword arg1 arg2 arg3 ... argN'
+
+The keyword is a command or status code ("ok"), and it
+and the arguments are separated by spaces. An argument
+may not contain a space.
+
+A long command or response is deduced from the context:
+certain commands always include additional data, and
+certain commands always get a long response, if
+successful (error responses are always simple). The
+first line of a long command or response is the same as
+for a simple one, the additional lines are prefixed with
+a space, and followed by a line containing only a
+period.
+
+A sample session (">>" indicates what the slave sends,
+"<<" what the master responds with):
+
----
- << hello
- >> pass liwc 1.2.3-4
- >> The piuparts
- >> log file comes
- >> here
- >> .
- << ok
- >> reserve
- << ok vorbisgain 2.3-4
+<< hello
+>> pass liwc 1.2.3-4
+>> The piuparts
+>> log file comes
+>> here
+>> .
+<< ok
+>> reserve
+<< ok vorbisgain 2.3-4
----
- Here the slave first reports a successful test of
- package liwc, version 1.2.3-4, and sends the piuparts
- log file for it. Then it reserves a new package to test
- and the master gives it vorbisgain, version 2.3-4.
-
- The communication always starts with the master saying
- "hello". The slave shall not speak until the master has
- spoken.
-
- Commands and responses in this protocol:
+Here the slave first reports a successful test of
+package liwc, version 1.2.3-4, and sends the piuparts
+log file for it. Then it reserves a new package to test
+and the master gives it vorbisgain, version 2.3-4.
+The communication always starts with the master saying
+"hello". The slave shall not speak until the master has
+spoken.
+
+Commands and responses in this protocol:
+
----
- Command: reserve
- Success: ok <packagename> <packageversion>
- Failure: error
+Command: reserve
+Success: ok <packagename> <packageversion>
+Failure: error
----
- Slave asks master to reserve a package (a
- particular version of it) for the slave to test.
- The slave may reserve any number of packages to
- test. If the transaction fails, there are no
- more packages to test, and the slave should
- disconnect, wait some time and try again.
+Slave asks master to reserve a package (a
+particular version of it) for the slave to test.
+The slave may reserve any number of packages to
+test. If the transaction fails, there are no
+more packages to test, and the slave should
+disconnect, wait some time and try again.
----
- Command: unreserve <packagename> <packageversion>
- Success: ok
+Command: unreserve <packagename> <packageversion>
+Success: ok
----
-
- Slave informs master it cannot test the desired
- version of a package (perhaps it went away from
- the mirror?).
-
+
+Slave informs master it cannot test the desired
+version of a package (perhaps it went away from
+the mirror?).
+
----
- Command: pass <packagename> <packageversion>
- log file contents
- .
- Success: ok
+Command: pass <packagename> <packageversion>
+ log file contents
+ .
+Success: ok
----
-
- Slave reports that it has tested a particular
- version of a package and that the package passed
- all tests. Master records this and stores the
- log file somewhere suitable.
-
+
+Slave reports that it has tested a particular
+version of a package and that the package passed
+all tests. Master records this and stores the
+log file somewhere suitable.
+
----
- Command: fail <packagename> <packageversion>
- log file contents
- .
- Success: ok
+Command: fail <packagename> <packageversion>
+ log file contents
+ .
+Success: ok
----
- Same as "pass", but package failed one or more tests.
+Same as "pass", but package failed one or more tests.
----
- Command: untestable <packagename> <packageversion>
- log file contents
- .
- Success: ok
+Command: untestable <packagename> <packageversion>
+ log file contents
+ .
+Success: ok
----
- Slave reports that a particular package is
- untestable, possibly because it insists on
- interacting with the user.
-
- In all cases, if the master cannot respond with "ok"
- (e.g., because of a disk error storing a log file), it
- aborts and the connection fails. The slave may only
- assume the command has succeeded if the master responds
- with "ok".
-
- The master may likewise abort, without an error message,
- if the slave sends garbage, or sends too much data.
+Slave reports that a particular package is
+untestable, possibly because it insists on
+interacting with the user.
+In all cases, if the master cannot respond with "ok"
+(e.g., because of a disk error storing a log file), it
+aborts and the connection fails. The slave may only
+assume the command has succeeded if the master responds
+with "ok".
+The master may likewise abort, without an error message,
+if the slave sends garbage, or sends too much data.
+
+
piuparts.conf configuration file
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -370,10 +361,10 @@
'/etc/piuparts/piuparts.conf'. The syntax is defined
by the Python ConfigParser class, and is, briefly, like
this:
-
+----
[master]
foo = bar
-
+----
FIXME:
#where "master" is the name of a section. By default,
#piuparts-master.py uses the "master" section in the master
@@ -394,113 +385,48 @@
the following settings are only useful for piuparts-master:
-* "log-file" is the name of a file to where the master should
- write its log messages. In the default configuration file
- it is "/dev/null", that is, log messages are not put in a
- file.
+* "log-file" is the name of a file to where the master should write its log messages. In the default configuration file it is "/dev/null", that is, log messages are not put in a file.
-* "packages-url" is a URL to the Packages.bz2 file for your
- mirror. It is usually best to use the Packages.bz2 for
- sid (unstable), unless you know what you're doing. For
- example, you might use
-
- http://ftp.debian.org/debian/dists/sid/main/
- binary-i386/Packages.bz2
+* "packages-url" is a URL to the Packages.bz2 file for your mirror. It is usually best to use the Packages.bz2 for sid (unstable), unless you know what you're doing. For example, you might use 'http://ftp.debian.org/debian/dists/sid/main/binary-i386/Packages.bz2' but you really do want to replace "ftp.debian.org" with the name of your local mirror.
- (all on one line, of course), but you really do want
- to replace "ftp.debian.org" with the name of your local
- mirror.
+Both configuration items must be in the configuration file, or master will refuse to run.
-Both configuration items must be in the configuration file,
-or master will refuse to run.
-
slave configuration
^^^^^^^^^^^^^^^^^^^
the following settings are only useful for piuparts-slave:
- * "idle-sleep" is the length of time the slave should wait
- before querying the master again if the master didn't have
- any new packages to test. In seconds, so a value of 300
- would mean five minutes, and that seems to be a good
- value when there are fairly few slaves per master.
-
- * "master-host" is the host where the master exists. The
- slave will give this host to ssh.
-
- * "master-user" is the username of the master. The slave will
- log in using this username.
-
- * "master-directory" is the directory where the master keeps
- its files. Can be relative to the master's home directory.
-
- * "master-command" is the command to run on master-host to
- start the master. When the master has been installed from
- the Debian package, the command is
- "python /usr/share/piuparts/piuparts-master.py". If you
- want to use a section in the master configuration file
- other than "master", append the section name to this
- command. For example, if the master configuration file has
- a "sid-ia64" section that you want to use, the command
- should be
- "python /usr/share/piuparts/piuparts-master.py sid-ia64".
-
- * "mirror" tells the slave which mirror it is to use. The
- slave gives this to piuparts when it runs it.
-
- * "piuparts-cmd" is the command the slave uses to start
- piuparts. It should include "sudo" if necessary so that
- piuparts runs with sufficient priviledges to do its testing
- (and that means root priviledges).
-
- * "distro" is the distribution the slave should tell piuparts
- to use for basic install/purge testing.
-
- * "chroot-tgz" is the name of the file the slave should
- use for the tarball to keep the chroot for the basic
- install/purge testing. If the tarball doesn't exist, the
- slave creates it.
+* "idle-sleep" is the length of time the slave should wait before querying the master again if the master didn't have any new packages to test. In seconds, so a value of 300 would mean five minutes, and that seems to be a good value when there are fairly few slaves per master.
+
+* "master-host" is the host where the master exists. The slave will give this host to ssh.
+
+* "master-user" is the username of the master. The slave will log in using this username.
- * "upgrade-test-distros" is the space delimited list of
- distributions the slave should use for testing upgrades
- between distributions (i.e., Debian versions). Currently,
- "etch lenny sid" is a good choice. Make this empty if you
- do not want to run upgrade tests.
+* "master-directory" is the directory where the master keeps its files. Can be relative to the master's home directory.
+
+* "master-command" is the command to run on master-host to start the master. When the master has been installed from the Debian package, the command is 'python /usr/share/piuparts/piuparts-master'. If you want to use a section in the master configuration file other than "master", append the section name to this command. For example, if the master configuration file has a "sid-ia64" section that you want to use, the command should be 'python /usr/share/piuparts/piuparts-master sid-ia64'.
+
+* "mirror" tells the slave which mirror it is to use. The slave gives this to piuparts when it runs it.
+
+* "piuparts-cmd" is the command the slave uses to start piuparts. It should include 'sudo' if necessary so that piuparts runs with sufficient priviledges to do its testing (and that means root priviledges).
+
+* "distro" is the distribution the slave should tell piuparts to use for basic install/purge testing.
+
+* "chroot-tgz" is the name of the file the slave should use for the tarball to keep the chroot for the basic install/purge testing. If the tarball doesn't exist, the slave creates it.
- * "upgrade-test-chroot-tgz" is the name of the file the slave
- should use for the tarball to keep the chroot for the
- first distribution in upgrade-test-distros. If the file
- does not exist, the slave creates it.
+* "upgrade-test-distros" is the space delimited list of distributions the slave should use for testing upgrades between distributions (i.e., Debian versions). Currently, "etch lenny sid" is a good choice. Make this empty if you do not want to run upgrade tests.
- * "max-reserved" is the maximum number of packages the
- slave will reserve at once. It should be large enough
- that the host that runs master is not unduly stressed by
- frequent ssh logins and running master (both of which
- take quite a bit of CPU cycles), yet at the same time it
- should not be so large that one slave grabs so many
- packages all other slaves just sit idle. The number
- obviously depends on the speed of the slave. A good
- value seems to be enough to let the slave test packages
- for about an hour before reporting results and reserving
- more. For a contemporary AMD64 machine with a reasonably
- fast disk subsystem the value 50 seems to work fine.
+* "upgrade-test-chroot-tgz" is the name of the file the slave should use for the tarball to keep the chroot for the first distribution in upgrade-test-distros. If the file does not exist, the slave creates it.
- * "keep-sources-list" controls whether the slave runs
- piuparts with the "--keep-sources-list" option. This
- option does not apply to upgrade tests. The value should
- be "yes" or "no", with the default being "no". Use this
- option for dists that you need a custom sources.list for,
- such as "stable-proposed-updates".
+* "max-reserved" is the maximum number of packages the slave will reserve at once. It should be large enough that the host that runs master is not unduly stressed by frequent ssh logins and running master (both of which take quite a bit of CPU cycles), yet at the same time it should not be so large that one slave grabs so many packages all other slaves just sit idle. The number obviously depends on the speed of the slave. A good value seems to be enough to let the slave test packages for about an hour before reporting results and reserving more. For a contemporary AMD64 machine with a reasonably fast disk subsystem the value 50 seems to work fine.
- * "debug" tells the slave whether to log debug level
- messages. The value should be "yes" or "no", with the
- default being "no".
+* "keep-sources-list" controls whether the slave runs piuparts with the '--keep-sources-list' option. This option does not apply to upgrade tests. The value should be "yes" or "no", with the default being "no". Use this option for dists that you need a custom sources.list for, such as "stable-proposed-updates".
- Some of the configuration items are not required, but it
- is best to set them all to be sure what the configuration
- actually is.
+* "debug" tells the slave whether to log debug level messages. The value should be "yes" or "no", with the default being "no". piuparts itself currently always produces debug output and there is no way to disable that.
+Some of the configuration items are not required, but it is best to set them all to be sure what the configuration actually is.
+
report configuration
^^^^^^^^^^^^^^^^^^^^^
Modified: trunk/TODO
===================================================================
--- trunk/TODO 2009-03-31 17:31:24 UTC (rev 305)
+++ trunk/TODO 2009-04-01 09:57:28 UTC (rev 306)
@@ -3,21 +3,14 @@
must for 0.36
-- document globalised config variables this in README
+- document globalised config variables in README
- better counts.txt:
-- factorize st used in write_counts_summary() and in generate_html_output()
- create $section_packages.txt with into about all packages
-- write_packages_summary() is not used atm
- then R
-- better header (link to FAQ, point out to read the bottom first..) for piuparts-logs
-- master.log is hardcoded in p-master.py?!
- take care of old conf files on upgrades
- take care of old pyc files from python-central
-- scripts in /usr/share/piuparts/ probably a FHS violation
-- make sure README.* gets included in the package
-- document the feature that you cannot turn off debug for piuparts.py ;-) or fix it (its possible to workaround it..)
-- same for piuparts-reports.py
-- rm piuparts.css?
- the templates used by update-reports.py should be taken from /etc/piuparts/templates/
and not be included in the python source
@@ -47,6 +40,9 @@
- RSS feeds of logs
+- not sure if it's a sensible thing to to, but provide a way to turn of debugging
+ output for piuparts.py
+
- piuparts can't currently test postfix, since installing postfix removes
exim and removing postfix would require re-installing exim, and that
doesn't happen; there's other packages like that, too
Modified: trunk/debian/changelog
===================================================================
--- trunk/debian/changelog 2009-03-31 17:31:24 UTC (rev 305)
+++ trunk/debian/changelog 2009-04-01 09:57:28 UTC (rev 306)
@@ -12,7 +12,8 @@
- change some methods from using 'args' to 'package_list'. This more
accurately represents what is being passed into these methods now.
- add an optional parameter to panic() method to specify what exit status
- to use. Also thanks to Andres.
+ to use. Also thanks to Andres.
+ - add advice how to read the logfile to the top of the logfiles produced.
* piupartslib/packagesdb.py:
- change the test whether a package is testable to check whether the
package is of priority "required", and not whether it's "Essential".
@@ -54,12 +55,13 @@
unversioned and add build-dependencies for debhelper and asciidoc.
* Rewrite debian/rules using debhelper.
* Merge README, how-to-use-piuparts.txt and custom-scripts.txt into
- README.txt and build pdf and html versions of it. The README also has been
- restructured and updated to reflect the configuration changes in
+ README.txt, convert it to asciidoc and build pdf and html versions of it.
+ * Restructure and update README.txt to reflect the configuration changes in
master-slave mode.
* Add NEWS file.
* Update debian/copyright to reflect that piuparts is licenced under GPL2+.
* Update FSF address in all files referencing the GPL.
+ * Remove unused file piuparts.css.
-- Holger Levsen <holger at debian.org> Tue, 10 Mar 2009 15:23:59 +0100
Modified: trunk/debian/control
===================================================================
--- trunk/debian/control 2009-03-31 17:31:24 UTC (rev 305)
+++ trunk/debian/control 2009-04-01 09:57:28 UTC (rev 306)
@@ -10,7 +10,7 @@
Section: devel
Priority: extra
Standards-Version: 3.8.0
-Build-Depends: debhelper (>=5.0.42), dpkg-dev
+Build-Depends: debhelper (>=5.0.42), dpkg-dev (>=1.13.26)
Build-Depends-Indep: docbook2x, python-support, docbook-xml, asciidoc
Vcs-Svn: svn://svn.debian.org/svn/piuparts/trunk/
Vcs-Browser: http://svn.debian.org/wsvn/piuparts/trunk/
Modified: trunk/piuparts-slave.py
===================================================================
--- trunk/piuparts-slave.py 2009-03-31 17:31:24 UTC (rev 305)
+++ trunk/piuparts-slave.py 2009-04-01 09:57:28 UTC (rev 306)
@@ -67,6 +67,7 @@
"master-user": None,
"master-directory": ".",
"master-command": None,
+ "log-file": "piuparts-master.log",
"mirror": None,
"piuparts-cmd": "sudo piuparts",
"distro": "sid",
@@ -142,11 +143,14 @@
else:
user = ""
(self._to_master, self._from_master) = \
- os.popen2("ssh %s %s 'cd %s; %s 2> master.log.$$ && rm master.log.$$'" %
+ os.popen2("ssh %s %s 'cd %s; %s 2> %s.$$ && rm %s.$$'" %
(self._master_host,
user,
self._master_directory or ".",
- self._master_command))
+ self._master_command,
+ self._config["log-file"],
+ self._config["log-file"]))
+
line = self._readline()
if line != "hello\n":
raise MasterDidNotGreet()
@@ -240,13 +244,13 @@
dir = os.path.join(self._slave_directory, dir)
if not os.path.exists(os.path.join(self._slave_directory, dir)):
os.mkdir(dir)
-
+
self._slave = Slave()
self._slave.set_master_host(master_host)
self._slave.set_master_user(master_user)
self._slave.set_master_directory(master_directory)
self._slave.set_master_command(self._config["master-command"])
-
+
for dir in ["pass", "fail", "untestable", "reserved"]:
dir = os.path.join(self._slave_directory, dir)
if not os.path.exists(dir):
Deleted: trunk/piuparts.css
Modified: trunk/piuparts.py
===================================================================
--- trunk/piuparts.py 2009-03-31 17:31:24 UTC (rev 305)
+++ trunk/piuparts.py 2009-04-01 09:57:28 UTC (rev 306)
@@ -1980,6 +1980,9 @@
args = parse_command_line()
logging.info("-" * 78)
+ logging.info("To quickly glance what went wrong, scroll down to the bottom of this logfile.")
+ logging.info("FAQ available at http://wiki.debian.org/piuparts/FAQ")
+ logging.info("-" * 78)
logging.info("piuparts version %s starting up." % VERSION)
logging.info("Command line arguments: %s" % " ".join(sys.argv))
logging.info("Running on: %s %s %s %s %s" % os.uname())
More information about the Piuparts-commits
mailing list