Fix some typos discovered during casual reading

CHANGELOG.md

@@ -10,7 +10,7 @@ Highlighted new features:
 * (DOCS PENDING) sudo: True/False and sudo_user: True/False can set at include and role level
 * added changed_when: (expression) which allows overriding whether a result is changed or not, can work with registered expressions.
 * --extra-vars can now take a file as input "-e @filename"
-* external inventory scripts may now return host variables in one pass, which allows them to be much for efficient for large numbers of hosts
+* external inventory scripts may now return host variables in one pass, which allows them to be much more efficient for large numbers of hosts
 
 New modules:
 

CONTRIBUTING.md

@@ -67,7 +67,7 @@ Contributors License Agreement
 ==============================
 
 By contributing you agree that these contributions are your own (or approved by your employer) and you grant a full, complete, irrevocable
-copyright license to all users and developers of the project, present and future, persusant to the license of the project.
+copyright license to all users and developers of the project, present and future, pursuant to the license of the project.
 
 
 

docsite/latest/rst/playbooks.rst

@@ -157,7 +157,7 @@ To learn more about Jinja2, you can optionally see the `Jinja2 docs <http://jinj
 
 If there are discovered variables about the system, called 'facts', these variables bubble up back into the
 playbook, and can be used on each system just like explicitly set variables.  Ansible provides several
-of these, prefixed with 'ansible', and are documented under 'setup' in the module documentation.  Additionally,
+of these, prefixed with 'ansible', which are documented under 'setup' in the module documentation.  Additionally,
 facts can be gathered by ohai and facter if they are installed.  Facter variables are prefixed with ``facter_`` and Ohai variables are prefixed with ``ohai_``.  These add extra dependencies and are only there for ease of users
 porting over from those other configuration systems.
 
@@ -188,7 +188,7 @@ The goal of each task is to execute a module, with very specific arguments.
 Variables, as mentioned above, can be used in arguments to modules.
 
 Modules are 'idempotent', meaning if you run them
-again, they will make the changes they are told to make to bring the
+again, they will make only the changes they must in order to bring the
 system to the desired state.  This makes it very safe to rerun
 the same playbook multiple times.  They won't change things
 unless they have to change things.
@@ -225,7 +225,7 @@ them work just like you would expect. Simple::
        command: /sbin/setenforce 0
 
 The command and shell module care about return codes, so if you have a command
-who's successful exit code is not zero, you may wish to do this::
+whose successful exit code is not zero, you may wish to do this::
 
    tasks:
      - name: run this command and ignore the result
@@ -320,7 +320,7 @@ won't need them for much else.
 .. note::
    Notify handlers are always run in the order written.
 
-Roles are described later on.  It's worth while to point out that handlers are
+Roles are described later on.  It's worthwhile to point out that handlers are
 automatically processed between 'pre_tasks', 'roles', 'tasks', and 'post_tasks'
 sections.  If you ever want to flush all the handler commands immediately though,
 in 1.2 and later, you can::
@@ -370,7 +370,7 @@ Variables passed in can then be used in the included files.  You can reference t
 
    {{ user }}
 
-(In addition to the explicitly passed in parameters, all variables from
+(In addition to the explicitly passed-in parameters, all variables from
 the vars section are also available for use here as well.)
 
 Starting in 1.0, variables can also be passed to include files using an alternative syntax,
@@ -554,7 +554,7 @@ Let's run a playbook using a parallelism level of 10::
 Tips and Tricks
 ```````````````
 
-Look at the bottom of the playbook execution for a summary of the nodes that were executed
+Look at the bottom of the playbook execution for a summary of the nodes that were targeted
 and how they performed.   General failures and fatal "unreachable" communication attempts are
 kept separate in the counts.
 

docsite/latest/rst/playbooks2.rst

@@ -2,7 +2,7 @@ Advanced Playbooks
 ==================
 
 Here are some advanced features of the playbooks language.  Using all of these features
-are not necessary, but many of them will prove useful.  If a feature doesn't seem immediately
+is not necessary, but many of them will prove useful.  If a feature doesn't seem immediately
 relevant, feel free to skip it.  For many people, the features documented in `playbooks` will
 be 90% or more of what they use in Ansible.
 
@@ -105,7 +105,7 @@ Similarly, this is how we access the first element of an array::
 Magic Variables, and How To Access Information About Other Hosts
 ````````````````````````````````````````````````````````````````
 
-Even if you didn't define them yourself, Ansible provides a few variables for you, automatically.
+Even if you didn't define them yourself, Ansible provides a few variables for you automatically.
 The most important of these are 'hostvars', 'group_names', and 'groups'.  Users should not use
 these names themselves as they are reserved.  'environment' is also reserved.
 
@@ -437,7 +437,7 @@ As a reminder, the various YAML files contain just keys and values::
     somethingelse: 42
 
 How does this work?  If the operating system was 'CentOS', the first file Ansible would try to import
-would be 'vars/CentOS.yml', followed up by '/vars/os_defaults.yml' if that file
+would be 'vars/CentOS.yml', followed by '/vars/os_defaults.yml' if that file
 did not exist.   If no files in the list were found, an error would be raised.
 On Debian, it would instead first look towards 'vars/Debian.yml' instead of 'vars/CentOS.yml', before
 falling back on 'vars/os_defaults.yml'. Pretty simple.
@@ -614,7 +614,7 @@ Negative numbers are not supported.  This works as follows::
 .. versionadded: 1.1
 
 ``with_password`` and associated lookup macro generate a random plaintext password and store it in
-a file at a given filepath.  Support for crypted save modes (as with vars_prompt) are pending.  If the
+a file at a given filepath.  Support for crypted save modes (as with vars_prompt) is pending.  If the
 file exists previously, it will retrieve its contents, behaving just like with_file. Usage of variables like "{{ inventory_hostname }}" in the filepath can be used to set
 up random passwords per host (what simplifies password management in 'host_vars' variables).
 
@@ -1093,7 +1093,7 @@ If using local_action, you can do this::
         arg1: 1234
         arg2: 'asdf'
 
-Which of course means, though more verbose, this is also technically legal syntax::
+Which of course means that, though more verbose, this is also legal syntax::
 
     - name: foo
       template: { src: '/templates/motd.j2', dest: '/etc/motd' }

lib/ansible/runner/lookup_plugins/together.py

@@ -60,7 +60,7 @@ class LookupModule(object):
 
         my_list = terms[:]
         if len(my_list) == 0:
-            raise errors.AnsibleError("with_transpose requires at least one element in each list")
+            raise errors.AnsibleError("with_together requires at least one element in each list")
         return [flatten(x) for x in izip_longest(*my_list, fillvalue=None)]
 
 

lib/ansible/utils/__init__.py

@@ -353,7 +353,7 @@ def parse_kv(args):
 
 def merge_hash(a, b):
     ''' recursively merges hash b into a
-    keys from b take precedende over keys from a '''
+    keys from b take precedence over keys from a '''
 
     result = copy.deepcopy(a)
 
@@ -785,7 +785,7 @@ def safe_eval(str):
 def listify_lookup_plugin_terms(terms, basedir, inject):
 
     if isinstance(terms, basestring):
-        # somewhat did:
+        # someone did:
         #    with_items: alist
         # OR
         #    with_items: {{ alist }}

library/packaging/apt_repository

@@ -44,9 +44,9 @@ options:
     choices: [ "present", "absent" ]
 notes:
    - If the repository is added, C(apt-get update) is invoked.
-   - This module works on Debian and Ubuntu only and requires C(apt-add-repository) be available on the destination server. To ensure this package is available use the M(apt) module and install the C(python-software-properties) package (or C(software-properties-common) in Ubuntu 13.04 or newer) before using this module.
+   - This module works on Debian and Ubuntu only and requires C(add-apt-repository) be available on the destination server. To ensure this package is available use the M(apt) module and install the C(python-software-properties) package (or C(software-properties-common) in Ubuntu 13.04 or newer) before using this module.
    - This module cannot be used on Debian Squeeze (Version 6) as there is no C(add-apt-repository) in C(python-software-properties)
-   - A bug in C(apt-add-repository) always adds C(deb) and C(deb-src) types for repositories (see the issue on Launchpad U(https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/987264)), if a repo doesn't have source information (eg MongoDB repo from 10gen) the system will fail while updating repositories.
+   - A bug in C(add-apt-repository) always adds C(deb) and C(deb-src) types for repositories (see the issue on Launchpad U(https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/987264)), if a repo doesn't have source information (eg MongoDB repo from 10gen) the system will fail while updating repositories.
 author: Matt Wright
 requirements: [ python-apt ]
 '''