more spelling fixes from the master "Olly Betts" <olly@survex.com>

webtools/tinderbox2/ChangeLog

@@ -70,7 +70,7 @@ this an important feature.
 Allow Tinderbox to run via suid wrappers.  This is needed for some
 times of mail delivery systems
 	
-No longer exclude 'priviledged id's from running Tinderbox. 
+No longer exclude 'privileged id's from running Tinderbox. 
 Now we require tinderbox to run as the id which the user specifies 
 is the tinderbox id.
 

webtools/tinderbox2/Goals

@@ -61,7 +61,7 @@ display should work on many different browsers.
 popup windows should not be netscape specific.
 
 Permanent data should be stored via datadumper so that the data and
-data strucutres are easy to read and debug. Currently this is a
+data structures are easy to read and debug. Currently this is a
 performance bottle neck with a large percentage of our cpu time during
 testing being spent in Data::Dumper::Dump.  The perl module Storable
 is much faster.  I wish to not add additional module requirements at

webtools/tinderbox2/Overview

@@ -40,9 +40,9 @@ difference the two.  As an example you might need to change the
 BuildStatus - I assume that you have the following possible build
 outcomes (Build in progress, Build failed, Build succeded but tests
 failed, Build and all tests were successful) You may have additional
-outcomes to specifiy which kind of tests failed (unit test failed, not
+outcomes to specify which kind of tests failed (unit test failed, not
 enough unit test coverage, performance tests failed).  Similarly you
-may have unusual requirements for how the filesystem should be laied
+may have unusual requirements for how the filesystem should be laid
 out.  I provide a outcomes to specify which kind of tests failed (unit
 test failed, not enough unit test coverage, performance tests failed).
 Similarly you may have unusual requirements for how the filesystem

webtools/tinderbox2/src/bin/addnote.cgi

@@ -3,11 +3,11 @@
 #
 
 # addnote.cgi - the webform via which users enter notices to be 
-#		 on the tinderbox status page.
+#		 displayed on the tinderbox status page.
 
 
-# $Revision: 1.22 $ 
+# $Revision: 1.23 $ 
-# $Date: 2003-08-04 17:14:56 $ 
+# $Date: 2003-08-16 18:31:03 $ 
 # $Author: kestes%walrus.com $ 
 # $Source: /home/jrmuizel/cvs-mirror/mozilla/webtools/tinderbox2/src/bin/addnote.cgi,v $ 
 # $Name:  $ 

webtools/tinderbox2/src/bin/processmail_builds

@@ -12,8 +12,8 @@
 # server.  No locks are used by the mail processes, data is passed to
 # the tinderbox server in a maildir like format.
 
-# $Revision: 1.32 $ 
+# $Revision: 1.33 $ 
-# $Date: 2003-08-04 17:14:58 $ 
+# $Date: 2003-08-16 18:31:03 $ 
 # $Author: kestes%walrus.com $ 
 # $Source: /home/jrmuizel/cvs-mirror/mozilla/webtools/tinderbox2/src/bin/processmail_builds,v $ 
 # $Name:  $ 
@@ -117,7 +117,7 @@ Mail is expected to consist of
 	2) The build/test log as output by the tool which was run to
 	generate the build.
 
-	3) The binary which results form the build, if desired.
+	3) The binary which results from the build, if desired.
 
 Mail messages are parsed to extract the tinderbox variables and
 database update files are written for the tinderbox server to pickup
@@ -131,27 +131,27 @@ information extracted from the mail message and any new variables
 derived while parsing the log file.
 
 The build logs are converted into HTML and are split into full and
-summary form and stored on the disk.  Both logs basenames are the same
+summary form and stored on the disk.  Both logs' basenames are the
-unique id which is found by using the time this program was stared and
+same unique id which is found by using the time this program was
-its pid.  The logs are stored in separate directories and compressed.
+started and its pid.  The logs are stored in separate directories and
-The server knows how to contruct URLS to the log files because that
+compressed.  The server knows how to contruct URLS to the log files
-information is passed in the database update files.  There may be
+because that information is passed in the database update files.
-serveral instances of this program running so each database update
+There may be serveral instances of this program running so each
-file is written to the disk with a unique name.  No locks are held by
+database update file is written to the disk with a unique name.  No
-this code.
+locks are held by this code.
 
 Builds which take a long time to complete can send multiple status
-mails each one containing the log file which has been completed so far.
+mails each one containing the log file which has been completed so
-All mails sent before the build is finished should have the status
+far.  All mails sent before the build is finished should have the
-'building'.  The last mail must contain the results of the build.  The
+status 'building'.  The last mail must contain the results of the
-website will make each build log available so that everyone can see
+build.  The website will make each build log available so that
-the log file and get a feel for how far into the compilation the build
+everyone can see the log file and get a feel for how far into the
-machine has progressed.
+compilation the build machine has progressed.
 
 
 Mail Format
 
-The mail has a very simple format and is not MIME encoded and has not
+The mail has a very simple format and is not MIME encoded and has no
 attachments. 
 
 The tinderbox variables must be at the top of the mail and the last
@@ -397,7 +397,7 @@ sub set_filenames {
 
 
 # If the field is a date prefer the output of fix_time_format to what
-# is passed into the program.  We may recieve human readable strings
+# is passed into the program.  We may receive human readable strings
 # and these need to be converted to time() format.
 
 
@@ -477,7 +477,7 @@ current time on client within 10 minutes.
 need to check that this update either 
 
   1) has the same starttime as the last update of this tree/build
-  2) has a starttime greater then min time between builds.
+  2) has a starttime greater than min time between builds.
 
 =cut
   ;
@@ -542,7 +542,7 @@ sub check_required_vars {
   
   # Note at this point we could have sourced only the implementation
   # of the error parser that we need.  I think programs which use an
-  # autoload for libraraies are messy since they cause variable run
+  # autoload for libraries are messy since they cause variable run
   # time requirements.
 
   $TINDERBOX{'timenow'} = main::extract_digits($TINDERBOX{'timenow'});
@@ -843,7 +843,7 @@ sub parse_mail_body {
 
   # it is a bug in processing should this function be called before
   # the tinderbox variables are set. We intentionally leave off the \n
-  # on some of thed die's to get tracebacks of internal errors.
+  # on some of the die's to get tracebacks of internal errors.
 
   # We must use HTMLPopUp::escapeHTML to clean up any embedded HTML in the
   # mail messege to prevent attacks.  Though it may be more friendly

webtools/tinderbox2/src/bin/tinder.cgi

@@ -2,8 +2,8 @@
 # -*- Mode: perl; indent-tabs-mode: nil -*-
 #
 
-# $Revision: 1.33 $ 
+# $Revision: 1.34 $ 
-# $Date: 2003-08-04 17:14:59 $ 
+# $Date: 2003-08-16 18:31:03 $ 
 # $Author: kestes%walrus.com $ 
 # $Source: /home/jrmuizel/cvs-mirror/mozilla/webtools/tinderbox2/src/bin/tinder.cgi,v $ 
 # $Name:  $ 
@@ -133,10 +133,11 @@ databases.  This requires the user to specify a single tree which the
 page will represent and pass in any additional arguments which the
 user wishes to be different from the defaults.
 
-New data is pushed into the system via administrative web forms and 
+New data is pushed into the system via administrative web forms and
-specified format.  Additional data is gathed by having the program
+via mail which is delivered to the helper program processmail and has
-query the Version Control Software to find any updates which have
+the specified format.  Additional data is gathered by having the
-happend recently.
+program query the Version Control Software to find any updates which
+have happended recently.
 
 Errors are logged to the logfile: $ERROR_LOG
 

webtools/tinderbox2/src/clientbin/build_shellscript

@@ -5,7 +5,7 @@
 # This script does not need to run under taint perl.
 
 # A generic build script for tinderbox.  This script will run any
-# sequence of shell command for building or testing an application.
+# sequence of shell commands for building or testing an application.
 # Users create a configuration file which defines the steps needed to
 # build, the build environmental variables and other information which
 # tinderbox will need.
@@ -32,8 +32,8 @@
 # complete rewrite by Ken Estes, Mail.com (kestes@staff.mail.com).
 # Contributor(s): 
 
-# $Revision: 1.15 $
+# $Revision: 1.16 $
-# $Date: 2003-08-04 17:15:02 $
+# $Date: 2003-08-16 18:31:05 $
 # $Author: kestes%walrus.com $
 # $Name:  $
 
@@ -131,7 +131,7 @@ Developers are responsible for ensuring that they keep their project
 related build scripts up to date so that the build interface does not
 change too rapidly.  Then for a given project the build should always
 be performed using the same commands and any complex build processing
-should be performed inside developer maintained scripts (shell, perl
+should be performed inside developer maintained scripts (shell, perl,
 Makefile).
 
 Different sequences of build instructions have different 'build

webtools/tinderbox2/src/clientbin/generic.sample.buildcf

@@ -5,7 +5,7 @@
 # especially if you are running builds on many different OS and platforms
 # which require different command sequences.  Each build type
 # (construct, test, lint) defines a sequence of commands which is the
-# same on all build machines.  They types each have different commands
+# same on all build machines.  The types each have different commands
 # to run but the commands are simple because all the difficult work is
 # performed inside makefiles and shell scripts.  There is one parser
 # on the tinderbox server for each type of build.  This cf file will
@@ -24,8 +24,8 @@
 # variables substituted.
 
 
-# $Revision: 1.8 $ 
+# $Revision: 1.9 $ 
-# $Date: 2003-08-04 17:15:02 $ 
+# $Date: 2003-08-16 18:31:05 $ 
 # $Author: kestes%walrus.com $ 
 # $Source: /home/jrmuizel/cvs-mirror/mozilla/webtools/tinderbox2/src/clientbin/generic.sample.buildcf,v $ 
 # $Name:  $ 
@@ -196,7 +196,7 @@ sub build_scripts {
   }
 
     # pass these variables to the Makefile.orig so that the
-    # buildid can contain this information.
+    # build id can contain this information.
 
     $ENV{'BUILD_CVS_D_TIME'} = $filename_time_str;
     $ENV{'BUILD_BRANCH'} = $branch;
@@ -397,7 +397,7 @@ sub mail_from {
 
 
 # Tell the tinderbox webserver what page to display the build
-# information.  In our case we use the same build instructions for
+# information on.  In our case we use the same build instructions for
 # several different products so this information must be passed in on
 # the command line.  We must have this information or the build can
 # not be displayed on the webserver, so it is a fatal error not to

webtools/tinderbox2/src/clientbin/mozilla.unix.buildcf

@@ -10,8 +10,8 @@
 # substituted.
 
 
-# $Revision: 1.4 $ 
+# $Revision: 1.5 $ 
-# $Date: 2003-08-04 17:15:02 $ 
+# $Date: 2003-08-16 18:31:05 $ 
 # $Author: kestes%walrus.com $ 
 # $Source: /home/jrmuizel/cvs-mirror/mozilla/webtools/tinderbox2/src/clientbin/mozilla.unix.buildcf,v $ 
 # $Name:  $ 
@@ -302,12 +302,12 @@ sub build_scripts {
 
 # Each phase must have the following entries:
 
-#	 phase_name: discribes what the phase is.
+#	 phase_name: describes what the phase is.
 
 #	 error_status: the tinderbox status which should be returned
 #	 if the phase fails.
 
-#	 script: a list of shell commands to be exected in order
+#	 script: a list of shell commands to be executed in order
 #	 until one fails (each command in a separate shell, similar to make).
 
 #	 dir: the directory which will be local while the script is

webtools/tinderbox2/src/lib/TinderDB.pm

@@ -19,8 +19,8 @@
 #       notice board display,  build display (colored squares)
 
 
-# $Revision: 1.20 $ 
+# $Revision: 1.21 $ 
-# $Date: 2003-08-04 17:15:10 $ 
+# $Date: 2003-08-16 18:31:07 $ 
 # $Author: kestes%walrus.com $ 
 # $Source: /home/jrmuizel/cvs-mirror/mozilla/webtools/tinderbox2/src/lib/TinderDB.pm,v $ 
 # $Name:  $ 
@@ -644,7 +644,7 @@ evaluated.  Each data update is stored in a file with a known name and
 a unique extension.  The tinderbox server is run periodically in
 daemon_mode and will assimilate all outstanding updates then update
 the static html files which describe the state of the build.  When
-tinderbox runs it looks for files with the known prefix than it reads
+tinderbox runs it looks for files with the known prefix then it reads
 each one in turn, loads it into a common database then deletes the
 file.  To ensure that tinderbox never encounters a partially written
 file each file is written to the disk using a a name with a different
@@ -692,7 +692,7 @@ for loading and saving databases.
 
 
 
-Each function decribed here builds an $out string.  If there are bugs
+Each function described here builds an $out string.  If there are bugs
 in the resulting HTML you can put your perl breakpoint on the return
 statement of any function and look at the completed string before it
 is returned.
@@ -776,7 +776,7 @@ implementation puts into the build table.
 
 =item B<status_table_header>
 
-return a header line appropriate for theset of columns this
+return a header line appropriate for the set of columns this
 implementation puts into the build table.
 
 

webtools/tinderbox2/src/lib/TinderDB/BT_Generic.pm

@@ -37,8 +37,8 @@
 # Contributor(s): 
 
 
-# $Revision: 1.22 $ 
+# $Revision: 1.23 $ 
-# $Date: 2003-08-04 17:15:14 $ 
+# $Date: 2003-08-16 18:31:09 $ 
 # $Author: kestes%walrus.com $ 
 # $Source: /home/jrmuizel/cvs-mirror/mozilla/webtools/tinderbox2/src/lib/TinderDB/BT_Generic.pm,v $ 
 # $Name:  $ 
@@ -52,7 +52,7 @@ package TinderDB::BT_Generic;
 
 #   $DATABASE{$tree}{$timenow}{$status}{$bug_id} = $record;
 
-# Where $rec is an anonymous hash of name vaule pairs from the bug
+# Where $rec is an anonymous hash of name value pairs from the bug
 # tracking system.
 
 # we also store information in the metadata structure
@@ -78,7 +78,7 @@ use VCDisplay;
 use TinderDB::Notice;
 
 
-$VERSION = ( qw $Revision: 1.22 $ )[1];
+$VERSION = ( qw $Revision: 1.23 $ )[1];
 
 @ISA = qw(TinderDB::BasicTxtDB);
 

webtools/tinderbox2/src/lib/TinderDB/BT_Req.pm

@@ -42,8 +42,8 @@
 
 
 
-# $Revision: 1.6 $ 
+# $Revision: 1.7 $ 
-# $Date: 2003-08-04 17:15:14 $ 
+# $Date: 2003-08-16 18:31:09 $ 
 # $Author: kestes%walrus.com $ 
 # $Source: /home/jrmuizel/cvs-mirror/mozilla/webtools/tinderbox2/src/lib/TinderDB/BT_Req.pm,v $ 
 # $Name:  $ 
@@ -57,7 +57,7 @@ package TinderDB::BT_Req;
 
 #   $DATABASE{$tree}{$timenow}{$status}{$bug_id} = $record;
 
-# Where $rec is an anonymous hash of name vaule pairs from the bug
+# Where $rec is an anonymous hash of name value pairs from the bug
 # tracking system.
 
 # we also store information in the metadata structure
@@ -82,7 +82,7 @@ use VCDisplay;
 
 
 
-$VERSION = ( qw $Revision: 1.6 $ )[1];
+$VERSION = ( qw $Revision: 1.7 $ )[1];
 
 @ISA = qw(TinderDB::BasicTxtDB);
 

webtools/tinderbox2/src/lib/TinderDB/Build.pm

@@ -7,8 +7,8 @@
 # the build was and display a link to the build log.
 
 
-# $Revision: 1.64 $ 
+# $Revision: 1.65 $ 
-# $Date: 2003-08-04 17:15:14 $ 
+# $Date: 2003-08-16 18:31:09 $ 
 # $Author: kestes%walrus.com $ 
 # $Source: /home/jrmuizel/cvs-mirror/mozilla/webtools/tinderbox2/src/lib/TinderDB/Build.pm,v $ 
 # $Name:  $ 
@@ -685,7 +685,7 @@ sub debug_database {
 sub status_table_legend {
   my ($out)='';
 
-  # print user defined legend, this is typically all the possible
+  # Print user defined legend, this is typically all the possible
   # links which can be included in a build log.
 
   my $print_legend = BuildStatus::TinderboxPrintLegend();
@@ -1315,7 +1315,7 @@ sub buildcell_links {
     
     # Binary file Link
     my $binary_ref = (
-                      FileStructure::get_filename($tree, build_din_dir) . 
+                      FileStructure::get_filename($tree, build_bin_dir) . 
                       $current_rec->{'binaryname'}
                       );
 

webtools/tinderbox2/src/lib/Utils.pm

@@ -3,8 +3,8 @@
 # Utils.pm - General purpose utility functions.  Every project needs a
 # kludge bucket for common access.
 
-# $Revision: 1.37 $ 
+# $Revision: 1.38 $ 
-# $Date: 2003-08-04 17:15:11 $ 
+# $Date: 2003-08-16 18:31:07 $ 
 # $Author: kestes%walrus.com $ 
 # $Source: /home/jrmuizel/cvs-mirror/mozilla/webtools/tinderbox2/src/lib/Utils.pm,v $ 
 # $Name:  $ 
@@ -211,7 +211,7 @@ sub chk_security {
   # could cause us problems.
 
   # Check effective uid of the process to see if we have
-  # been configured to run with too much privileges.
+  # been configured to run with too many privileges.
 
   # Ideally we do not want the tinderbox application running with the
   # privileges of a restricted user id (like: root, daemon, bin,
@@ -230,7 +230,7 @@ sub chk_security {
   ( $) == $tinderbox_gid) ||
     die("Security Error. ".
         "Must not run this program using effective group id ".
-        "different than tinderbox group id.".
+        "different than the tinderbox group id.".
         "id: $) must be $tinderbox_gid\n");