fix spelling mistakes

LICENSE

@@ -22,7 +22,7 @@ SOFTWARE.
 
 ===== qidenticon.py identicon python implementation with QPixmap output by sendiulo <sendiulo@gmx.net>
 
-qidenticon.py is Licesensed under FreeBSD License.
+qidenticon.py is Licensed under FreeBSD License.
 (http://www.freebsd.org/copyright/freebsd-license.html)
 
 Copyright 2013 "Sendiulo". All rights reserved.
@@ -36,7 +36,7 @@ THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDER ``AS IS'' AND ANY EXPRESS OR I
 
 ===== based on identicon.py identicon python implementation.  by Shin Adachi <shn@glucose.jp>
 
-identicon.py is Licesensed under FreeBSD License.
+identicon.py is Licensed under FreeBSD License.
 (http://www.freebsd.org/copyright/freebsd-license.html)
 
 Copyright 1994-2009 Shin Adachi. All rights reserved.

android_instruction.rst

@@ -1,6 +1,6 @@
 PyBitmessage(Android)
 
-This sample aims to be as close to a real world example of a mobile. It has a more refined design and also provides a practical example of how a mobile app would interact and communicate with its adresses.
+This sample aims to be as close to a real world example of a mobile. It has a more refined design and also provides a practical example of how a mobile app would interact and communicate with its addresses.
 
 Steps for trying out this sample:
 
@@ -13,7 +13,7 @@ This sample uses the kivy as Kivy is an open source, cross-platform Python frame
 
 Kivy is written in Python and Cython, supports various input devices and has an extensive widget library. With the same codebase, you can target Windows, OS X, Linux, Android and iOS. All Kivy widgets are built with multitouch support. 
 
-Kivy in support take Buildozer which is a tool that automates the entire build process. It downloads and sets up all the prequisites for python-for-android, including the android SDK and NDK, then builds an apk that can be automatically pushed to the device.
+Kivy in support take Buildozer which is a tool that automates the entire build process. It downloads and sets up all the prerequisite for python-for-android, including the android SDK and NDK, then builds an apk that can be automatically pushed to the device.
 
 Buildozer currently works only in Linux, and is an alpha release, but it already works well and can significantly simplify the apk build.
 

checkdeps.py

@@ -1,6 +1,6 @@
 #!/usr/bin/env python2
 """
-Check dependendies and give recommendations about how to satisfy them
+Check dependencies and give recommendations about how to satisfy them
 
 Limitations:
 

docs/contribute.dir/develop.dir/opsec.rst

@@ -21,12 +21,12 @@ If we are to make bold claims about protecting your privacy we should demonstrat
 - looking to audit
 - warrant canary
 
-Digital foootprint
+Digital footprint
 ------------------
 
 Your internet use can reveal metadata you wouldn't expect. This can be connected with other information about you if you're not careful.
 
- * Use separate addresses for different puprose
+ * Use separate addresses for different purposes
  * Don't make the same mistakes all the time
  * Your language use is unique. The more you type, the more you fingerprint yourself. The words you know and use often vs the words you don't know or use often.
 

docs/contribute.dir/develop.dir/overview.rst

@@ -11,17 +11,17 @@ Bitmessage makes use of fabric_ to define tasks such as building documentation o
 Code style and linters
 ----------------------
 
-We aim to be PEP8 compliant but we recognise that we have a long way still to go. Currently we have style and lint exceptions specified at the most specific place we can. We are ignoring certain issues project-wide in order to avoid alert-blindess, avoid style and lint regressions and to allow continuous integration to hook into the output from the tools. While it is hoped that all new changes pass the checks, fixing some existing violations are mini-projects in themselves. Current thinking on ignorable violations is reflected in the options and comments in setup.cfg. Module and line-level lint warnings represent refactoring opportunities.
+We aim to be PEP8 compliant but we recognize that we have a long way still to go. Currently we have style and lint exceptions specified at the most specific place we can. We are ignoring certain issues project-wide in order to avoid alert-blindness, avoid style and lint regressions and to allow continuous integration to hook into the output from the tools. While it is hoped that all new changes pass the checks, fixing some existing violations are mini-projects in themselves. Current thinking on ignorable violations is reflected in the options and comments in setup.cfg. Module and line-level lint warnings represent refactoring opportunities.
 
 Pull requests
 -------------
 
-There is a template at PULL_REQUEST_TEMPLATE.md that appears in the pull-request description. Please replace this text with something appropriate to your changes based off the ideas in the template.
+There is a template at PULL_REQUEST_TEMPLATE.md that appears in the pull-request description. Please replace this text with something appropriate to your changes based on the ideas in the template.
 
 Bike-shedding
 -------------
 
-Beyond having well-documented, Pythonic code with static analysis tool checks, extensive test coverage and powerful devops tools, what else can we have? Without violating any linters there is room for making arbirary decisions solely for the sake of project consistency. These are the stuff of the pedant's PR comments. Rather than have such conversations in PR comments, we can lay out the result of discussion here.
+Beyond having well-documented, Pythonic code with static analysis tool checks, extensive test coverage and powerful devops tools, what else can we have? Without violating any linters there is room for making arbitrary decisions solely for the sake of project consistency. These are the stuff of the pedant's PR comments. Rather than have such conversations in PR comments, we can lay out the result of discussion here.
 
 I'm putting up a strawman for each topic here, mostly based on my memory of reading related Stack Overflow articles etc. If contributors feel strongly (and we don't have anything better to do) then maybe we can convince each other to update this section.
 
@@ -49,7 +49,7 @@ British vs American spelling
 Dependency graph
 ----------------
 
-These images are not very useful right now but the aim is to tweak the settings of one or more of them to be informative, and/or divide them up into smaller grapghs.
+These images are not very useful right now but the aim is to tweak the settings of one or more of them to be informative, and/or divide them up into smaller graphs.
 
 To re-build them, run `fab build_docs:dep_graphs=true`. Note that the dot graph takes a lot of time.
 

fabfile/README.md

@@ -1,6 +1,6 @@
 # Fabric
 
-[Fabric](https://www.fabfile.org) is a Python library for performing devops tasks. You can thing of it a bit like a
+[Fabric](https://www.fabfile.org) is a Python library for performing devops tasks. You can think of it a bit like a
 makefile on steroids for Python. Its api abstracts away the clunky way you would run shell commands in Python, check
 return values and manage stdio. Tasks may be targetted at particular hosts or group of hosts.
 
@@ -46,7 +46,7 @@ Furthermore, you can use -- to run arbitrary shell commands rather than tasks:
 
 There are a number of advantages that should benefit us:
 
- * Common tasks can be writen in Python and executed consistently
+ * Common tasks can be written in Python and executed consistently
  * Common tasks are now under source control
  * All developers can run the same commands, if the underlying command sequence for a task changes (after review, obv)
    the user does not have to care

packages/README.md

@@ -15,7 +15,7 @@ OSX:
 
 https://github.com/Bitmessage/PyBitmessage/releases
 
-Wors on OSX 10.7.5 or higher
+Works on OSX 10.7.5 or higher
 
 
 Arch linux: