From: Michael R. Crusoe <michael.crusoe@gmail.com>
Subject: Lintian-inspired spelling fixes
--- toil.orig/docs/running/cloud/amazon.rst
+++ toil/docs/running/cloud/amazon.rst
@@ -165,7 +165,7 @@
 
     When using the Toil provisioner, the appliance image will be automatically chosen
     based on the pip-installed version of Toil on your system. That choice can be
-    overriden by setting the environment variables ``TOIL_DOCKER_REGISTRY`` and ``TOIL_DOCKER_NAME`` or
+    overridden by setting the environment variables ``TOIL_DOCKER_REGISTRY`` and ``TOIL_DOCKER_NAME`` or
     ``TOIL_APPLIANCE_SELF``. See :ref:`envars` for more information on these variables. If
     you are developing with autoscaling and want to test and build your own
     appliance have a look at :ref:`appliance_dev`.
--- toil.orig/docs/running/cloud/gce.rst
+++ toil/docs/running/cloud/gce.rst
@@ -32,7 +32,7 @@
 
        $ chmod 400 ~/.ssh/id_rsa ~/.ssh/id_rsa.pub
 
-#. Add your newly formated public key to Google. To do this, log into your Google Cloud account
+#. Add your newly formatted public key to Google. To do this, log into your Google Cloud account
    and go to `metadata`_ section under the Compute tab.
 
    .. image:: googleScreenShot.png
--- toil.orig/docs/running/cwl.rst
+++ toil/docs/running/cwl.rst
@@ -33,7 +33,7 @@
 ------------------------------------
 
 A CWL workflow can be run indirectly in a native Toil script. However, this is not the :ref:`standard <cwl>` way to run
-CWL workflows with Toil and doing so comes at the cost of job efficency. For some use cases, such as running one process on
+CWL workflows with Toil and doing so comes at the cost of job efficiency. For some use cases, such as running one process on
 multiple files, it may be useful. For example, if you want to run a CWL workflow with 3 YML files specifying different
 samples inputs, it could look something like::
 
--- toil.orig/docs/running/wdl.rst
+++ toil/docs/running/wdl.rst
@@ -117,7 +117,7 @@
         A cromwell.jar file is needed in order to run a WDL workflow.
 
 A WDL workflow can be run indirectly in a native Toil script. However, this is not the :ref:`standard <wdl>` way to run
-WDL workflows with Toil and doing so comes at the cost of job efficency. For some use cases, such as running one process on
+WDL workflows with Toil and doing so comes at the cost of job efficiency. For some use cases, such as running one process on
 multiple files, it may be useful. For example, if you want to run a WDL workflow with 3 JSON files specifying different
 samples inputs, it could look something like::
 
--- toil.orig/src/toil/jobStores/abstractJobStore.py
+++ toil/src/toil/jobStores/abstractJobStore.py
@@ -758,7 +758,7 @@
     def jobs(self):
         """
         Best effort attempt to return iterator on all jobs in the store. The iterator may not
-        return all jobs and may also contain orphaned jobs that have already finished succesfully
+        return all jobs and may also contain orphaned jobs that have already finished successfully
         and should not be rerun. To guarantee you get any and all jobs that can be run instead
         construct a more expensive ToilState object
 
--- toil.orig/src/toil/lib/threading.py
+++ toil/src/toil/lib/threading.py
@@ -39,7 +39,7 @@
 class ExceptionalThread(threading.Thread):
     """
     A thread whose join() method re-raises exceptions raised during run(). While join() is
-    idempotent, the exception is only during the first invocation of join() that succesfully
+    idempotent, the exception is only during the first invocation of join() that successfully
     joined the thread. If join() times out, no exception will be re reraised even though an
     exception might already have occured in run().
 
--- toil.orig/src/toil/job.py
+++ toil/src/toil/job.py
@@ -273,11 +273,11 @@
             exhausting all their retries, remove any successor jobs and rerun this job to restart the
             subtree. Job must be a leaf vertex in the job graph when initially defined, see
             :func:`toil.job.Job.checkNewCheckpointsAreCutVertices`.
-        :type cores: int or string convertable by toil.lib.humanize.human2bytes to an int
-        :type disk: int or string convertable by toil.lib.humanize.human2bytes to an int
+        :type cores: int or string convertible by toil.lib.humanize.human2bytes to an int
+        :type disk: int or string convertible by toil.lib.humanize.human2bytes to an int
         :type preemptable: bool
-        :type cache: int or string convertable by toil.lib.humanize.human2bytes to an int
-        :type memory: int or string convertable by toil.lib.humanize.human2bytes to an int
+        :type cache: int or string convertible by toil.lib.humanize.human2bytes to an int
+        :type memory: int or string convertible by toil.lib.humanize.human2bytes to an int
         """
         requirements = {'memory': memory, 'cores': cores, 'disk': disk,
                         'preemptable': preemptable}
--- toil.orig/docs/appendices/environment_vars.rst
+++ toil/docs/appendices/environment_vars.rst
@@ -28,7 +28,7 @@
 | TOIL_DOCKER_REGISTRY   | The URL of the registry of the Toil Appliance      |
 |                        | image you wish to use. Docker will use Dockerhub   |
 |                        | by default, but the quay.io registry is also       |
-|                        | very popular and easily specifiable by settting    |
+|                        | very popular and easily specifiable by setting     |
 |                        | this option to ``quay.io``.                        |
 +------------------------+----------------------------------------------------+
 | TOIL_DOCKER_NAME       | The name of the Toil Appliance image you           |
--- toil.orig/docs/developingWorkflows/developing.rst
+++ toil/docs/developingWorkflows/developing.rst
@@ -559,7 +559,7 @@
 
     Just like regular promises, the return value must be determined prior to
     scheduling any job that depends on the return value. In our example above, notice
-    how the dependant jobs were follow ons to the parent while promising jobs are
+    how the dependent jobs were follow ons to the parent while promising jobs are
     children of the parent. This ordering ensures that all promises are
     properly fulfilled.
 
