Fix typos.

Thanks Adam!

2 files changed, 20 insertions, 19 deletions

diff --git a/lib/spack/docs/basic_usage.rst b/lib/spack/docs/basic_usage.rst
index f7f74a1623..71f3da8610 100644
--- a/lib/spack/docs/basic_usage.rst
+++ b/lib/spack/docs/basic_usage.rst
@@ -281,7 +281,7 @@ of its dependencies, simply run ``spack install <package>``:
    spack install mpileaks
 
 Spack will fetch the tarball for ``mpileaks``, expand it, verify that
-it was donwloaded without errors, build it, and install it in its own
+it was downloaded without errors, build it, and install it in its own
 directory under ``$SPACK_HOME/opt``.  If the requested package depends
 on other packages in order to build, Spack fetches them as well, and
 installs them before it installs the requested package. Like the main
@@ -380,12 +380,12 @@ More formally, a spec consists of the following pieces:
 * ``=`` Optional architecture specifier (``bgqos_0``)
 * ``^`` Dependency specs (``^callpath@1.1``)
 
-There are two things to notice here.  One is that specs are
+There are two things to notice here.  The first is that specs are
 recursively defined.  That is, each dependency after ``^`` is a spec
-itself.  The second is that Notice that everything is optional
-*except* for the initial package name identifier.  Users can be as
-vague or as specific as they want about the details of building
-packages, and this makes spack good for beginners and experts alike.
+itself.  The second is that everything is optional *except* for the
+initial package name identifier.  Users can be as vague or as specific
+as they want about the details of building packages, and this makes
+spack good for beginners and experts alike.
 
 To really understand what's going on above, we need to think about how
 software is structured.  An executable or a library (these are
@@ -605,12 +605,12 @@ getting info on it:
 Spack is unique in that its virtual packages can be versioned, just
 like regular packages.  A particular version of a package may provide
 a particular version of a virtual package, and we can see above that
-``mpich`` versions ``1`` and above provide all interfaces up to ``1``,
-and ``mpich`` versions ``3`` and above provide ``mpi`` versions up to
-``3``.  A package can *depend on* a particular version of a virtual
-package, e.g. if an application needs MPI-2 functions, it can depend
-on ``mpi@2:`` to indicate that it needs some implementation that
-provides MPI-2 functions.
+``mpich`` versions ``1`` and above provide all ``mpi`` interface
+versions up to ``1``, and ``mpich`` versions ``3`` and above provide
+``mpi`` versions up to ``3``.  A package can *depend on* a particular
+version of a virtual package, e.g. if an application needs MPI-2
+functions, it can depend on ``mpi@2:`` to indicate that it needs some
+implementation that provides MPI-2 functions.
 
 
 Constraining virtual packages
diff --git a/lib/spack/docs/packaging_guide.rst b/lib/spack/docs/packaging_guide.rst
index 023896b6c0..13785e25b7 100644
--- a/lib/spack/docs/packaging_guide.rst
+++ b/lib/spack/docs/packaging_guide.rst
@@ -636,7 +636,7 @@ Spack parses the command line and builds a spec from the description.
 The spec says that ``mpileaks`` should be built with the ``callpath``
 library at 1.0 and with the debug option enabled, and with ``libelf``
 version 0.8.11.  Spack will also look at the ``depends_on`` calls in
-all of these packags, and it will build a spec from that.  The specs
+all of these packages, and it will build a spec from that.  The specs
 from the command line and the specs built from package descriptions
 are then combined, and the constraints are checked against each other
 to make sure they're satisfiable.
@@ -871,9 +871,10 @@ directories that ``diff`` compared when it created the patch file.
 This is git's default behavior when creating patch files, but other
 programs may behave differently.
 
-``-p1`` strings off the first level of prefix in both paths, allowing
-the patch to be applied from the root of an expanded mvapich2 archive.
-If you set level to ``2``, it would strip off ``src``, and so on.
+``-p1`` strips off the first level of the prefix in both paths,
+allowing the patch to be applied from the root of an expanded mvapich2
+archive.  If you set level to ``2``, it would strip off ``src``, and
+so on.
 
 It's generally easier to just structure your patch file so that it
 applies cleanly with ``-p1``, but if you're using a URL to a patch you
@@ -996,8 +997,8 @@ Testing spec constraints
 
 You can test whether your spec is configured a certain way by using
 the ``satisfies`` method.  For example, if you want to check whether
-the pcakage is at a particular version range, you can use specs to do
-that, e.g.:
+the package's version is in a particular range, you can use specs to
+do that, e.g.:
 
 .. code-block:: python
 
@@ -1287,7 +1288,7 @@ already been expanded,  ``stage`` is idempotent.
 
 After staging, Spack applies patches to downloaded packages, if any
 have been specified in the package file.  This command will run the
-install process throught he fetch, stage, and patch phases.  Spack
+install process through the fetch, stage, and patch phases.  Spack
 keeps track of whether patches have already been applied and skips
 this step if they have been.  If Spack discovers that patches didn't
 apply cleanly on some previous run, then it will restage the entire