package piuparts
tag 603873 + patch
thanks

Attached is both my original patch updated after reviewing Mr. Anderson's previous, and a short patch including only those items which I pulled from his effort:

Two occurrences where pbuilder args were missing --
minimized was misspelled
custom scripts env var PIUPARTS_OBJECTS was missing final S

# HG changeset patch
# Parent 821110b2a6a99b5366a8647b3217a7c597b53236

diff --git a/README.txt b/README.txt
--- a/README.txt
+++ b/README.txt
@@ -66,13 +66,13 @@
 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:
@@ -144,7 +144,7 @@
 The scripts are run *inside* the piuparts chroot and only can be
 shell scripts, if you want to run Python or Perl scripts, you
 have to install Python or Perl. The chroot where piuparts is run
-is minized and does not include Perl.
+is minimized and does not include Perl.
 
 The variable PIUPARTS_OBJECTS is set to the packages currently
 being tested (seperated by spaces, if applicable) or the .changes
@@ -193,7 +193,7 @@
 ----
 #!/bin/sh
 
-echo "$PIUPARTS_OBJECT will now get tested."
+echo "$PIUPARTS_OBJECTS will now get tested."
 exit 0
 ----
 
@@ -212,18 +212,29 @@
 
 To set this up for yourself, the following steps should suffice:
 
-. Pick a machine to run the master. It cannot be a chroot, but basically any real (or properly virtualized) Debian system is good enough.
+. Pick a machine to run the master. It cannot be a chroot, but 
+  basically any real (or properly virtualized) Debian 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.
+. 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.
+. 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.
+. 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
@@ -355,43 +366,105 @@
 These settings are used for all sections. Except for the first
 two they are all mandatory:
 
-* "sections" defaults to sid and defines which sections should be processed in master-slave mode. Each section defined here has to have a section with the section specific settings explained below. The first section defined should always be sid, because the data from first section a package is in is used for the source package html report.
+* "sections" defaults to sid and defines which sections should be 
+  processed in master-slave mode. Each section defined here has to 
+  have a section with the section specific settings explained below. 
+  The first section defined should always be sid, because the data 
+  from first section a package is in is used for the source package
+  html report.
 
-* "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. The default is 300 seconds.
+* "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. The default is 300 seconds.
   
-* "master-host" is the host where the master exists. The slave will give this host to ssh.
+* "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-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-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'.
+* "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'.
  
-* "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.
 
 ==== section specific configuration 
 
-* "packages-url" is a URL to the Packages.bz2 file specifying what packages should be tested. This needs to be a Packages.bz2 file, other compression methods are not supported. 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.
+* "packages-url" is a URL to the Packages.bz2 file specifying what 
+  packages should be tested. This needs to be a Packages.bz2 file, 
+  other compression methods are not supported. 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.
  
-* "sources-url" is a URL to the Sources.bz2 file for your mirror. "sources-url" must match "packages-url", if it is not defined, piuparts-reports will not generate source centric html pages.
+* "sources-url" is a URL to the Sources.bz2 file for your mirror. 
+  "sources-url" must match "packages-url", if it is not defined, 
+  piuparts-reports will not generate source centric html pages.
 
-* "mirror" tells the slave which mirror it is to use. The slave gives this to piuparts when it runs it. Components must not be used here. "packages-url" defines which component to use. This setting is redundant and should go away.
+* "mirror" tells the slave which mirror it is to use. The slave gives 
+  this to piuparts when it runs it. Components must not be used here. 
+  "packages-url" defines which component to use.
+  This setting is redundant and should go away.
   
-* "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).
+* "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. This can be left empty if only upgrade tests should be run.
+* "distro" is the distribution the slave should tell piuparts to use 
+  for basic install/purge testing. This can be left empty if only upgrade 
+  tests should be run.
   
-* "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. This can be left empty if only upgrade tests should be run.
+* "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. 
+  This can be left empty if only upgrade tests should be run.
 
-* "upgrade-test-distros" is the space delimited list of distributions the slave should use for testing upgrades between distributions (i.e., Debian versions). Currently, "lenny squeeze sid" is a good choice.  Leave this unset if you do not want to run upgrade tests.
+* "upgrade-test-distros" is the space delimited list of distributions 
+  the slave should use for testing upgrades between distributions 
+  (i.e., Debian versions). Currently, "lenny squeeze sid" is a good choice.
+  Leave this unset if you do not want to run upgrade tests.
 
-* "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. This can be left empty if only basic tests should be run.
+* "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. 
+  This can be left empty if only basic tests should be run.
 
-* "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.
+* "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.
 
-* "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".
+* "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".
 
-* "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.
+* "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.
diff --git a/README.txt b/README.txt
--- a/README.txt
+++ b/README.txt
@@ -66,13 +66,13 @@
 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:
@@ -144,7 +144,7 @@
 The scripts are run *inside* the piuparts chroot and only can be
 shell scripts, if you want to run Python or Perl scripts, you
 have to install Python or Perl. The chroot where piuparts is run
-is minized and does not include Perl.
+is minimized and does not include Perl.
 
 The variable PIUPARTS_OBJECTS is set to the packages currently
 being tested (seperated by spaces, if applicable) or the .changes
@@ -193,7 +193,7 @@
 ----
 #!/bin/sh
 
-echo "$PIUPARTS_OBJECT will now get tested."
+echo "$PIUPARTS_OBJECTS will now get tested."
 exit 0
 ----

Reply via email to