Merge lp:~colin-king/ecryptfs/ecryptfs-spelling-fixes into lp:ecryptfs

[Colin Ian King]

Some minor spelling mistake fixes. Nothing too exciting really.

[Tyler Hicks (tyhicks)]

Looks good. Please push it to trunk. Thanks!

review: Approve

[Colin Ian King (colin-king)]

On 22/11/13 17:32, Tyler Hicks wrote:
> Review: Approve
>
> Looks good. Please push it to trunk. Thanks!
>

My bzr foo is lame, in fact I've never done that before (I mainly use
git). How do I do that w/o messing up the world?

Colin

[Tyler Hicks (tyhicks)]

On 2013-11-22 17:48:15, Colin King wrote:
> On 22/11/13 17:32, Tyler Hicks wrote:
> > Review: Approve
> >
> > Looks good. Please push it to trunk. Thanks!
> >
>
> My bzr foo is lame, in fact I've never done that before (I mainly use
> git). How do I do that w/o messing up the world?

If your bzr branch is simply trunk + your patches, then
`bzr push lp:ecryptfs` will do.

If your bzr branch is an older version of trunk + your patches, I really
don't know what the best way is (this is where I miss my git workflow).
You can checkout trunk in a new branch, `bzr branch lp:ecryptfs`, and
then cd into the new branch and merge in your feature branch with
`bzr merge ../path/to/feature/branch`. I don't really like doing that
because it ends up hiding all of the commits behind a single merge
commit. If my feature branch is behind trunk, I usually manually
cherry-pick the commits in my feature branch to a fresh checkout of
trunk.

Hopefully paragraph 1 describes your situation. Don't mess with it for
too long, though. If you're having any trouble at all, kick it back over
to me and I'll pull in your changes.

[Colin Ian King (colin-king)]

On 22/11/13 18:03, Tyler Hicks wrote:
> On 2013-11-22 17:48:15, Colin King wrote:
>> On 22/11/13 17:32, Tyler Hicks wrote:
>>> Review: Approve
>>>
>>> Looks good. Please push it to trunk. Thanks!
>>>
>>
>> My bzr foo is lame, in fact I've never done that before (I mainly use
>> git). How do I do that w/o messing up the world?
>
> If your bzr branch is simply trunk + your patches, then
> `bzr push lp:ecryptfs` will do.

Thanks, done.
>
> If your bzr branch is an older version of trunk + your patches, I really
> don't know what the best way is (this is where I miss my git workflow).
> You can checkout trunk in a new branch, `bzr branch lp:ecryptfs`, and
> then cd into the new branch and merge in your feature branch with
> `bzr merge ../path/to/feature/branch`. I don't really like doing that
> because it ends up hiding all of the commits behind a single merge
> commit. If my feature branch is behind trunk, I usually manually
> cherry-pick the commits in my feature branch to a fresh checkout of
> trunk.
>
> Hopefully paragraph 1 describes your situation. Don't mess with it for
> too long, though. If you're having any trouble at all, kick it back over
> to me and I'll pull in your changes.
>

=== modified file 'doc/beginners_guide/ecryptfs_beginners_guide.tex'
--- doc/beginners_guide/ecryptfs_beginners_guide.tex	2009-02-03 08:50:36 +0000
+++ doc/beginners_guide/ecryptfs_beginners_guide.tex	2013-11-22 17:26:11 +0000
@@ -35,7 +35,7 @@
 \section*{Mounting eCryptfs}
 
 eCryptfs is currently under development, with future versions being
-backwards compatable. Currently, eCryptfs is in version 0.1, and you can
+backwards compatible. Currently, eCryptfs is in version 0.1, and you can
 read about the various ways eCryptfs can be mounted in the appropriate
 subsection.
 

=== modified file 'doc/design_doc/ecryptfs_design_doc_v0_1.tex'
--- doc/design_doc/ecryptfs_design_doc_v0_1.tex	2009-02-03 08:50:36 +0000
+++ doc/design_doc/ecryptfs_design_doc_v0_1.tex	2013-11-22 17:26:11 +0000
@@ -243,7 +243,7 @@
 after the file is initially created. When a file is no longer being
 accessed, the kernel VFS frees its associated file, dentry, and inode
 objects according to the standard resource deallocation process in the
-VFS; eCryptfs does not perform any futher cryptographic operations on
+VFS; eCryptfs does not perform any further cryptographic operations on
 the file.
 
 \section{Cryptographic Properties}
@@ -474,4 +474,4 @@
 
 (End of Document.)
 
-\end{document}
\ No newline at end of file
+\end{document}

=== modified file 'doc/design_doc/ecryptfs_design_doc_v0_2.tex'
--- doc/design_doc/ecryptfs_design_doc_v0_2.tex	2012-11-02 14:31:32 +0000
+++ doc/design_doc/ecryptfs_design_doc_v0_2.tex	2013-11-22 17:26:11 +0000
@@ -274,7 +274,7 @@
 kernel crypto API, and the encrypted page is written out to the lower
 file.
 
-If HMAC verification was enabled as a mount paramter, then... TODO
+If HMAC verification was enabled as a mount parameter, then... TODO
 
 \subsubsection{File Truncation}
 
@@ -471,7 +471,7 @@
 maintain their own policy, and are unaffected by this mount option.
 
 eCryptfs calculates HMAC values over a fixed number $L$ of extents
-and stores those values in headers preceeding the groups of extents; these
+and stores those values in headers preceding the groups of extents; these
 are the the 2nd level HMAC headers. eCryptfs also calculates HMAC values
 over the 2nd level HMAC headers and stores them in the 1st level HMAC
 headers. Finally, eCryptfs calculates a root HMAC value over all of

=== modified file 'doc/ecryptfs-pkcs11-helper-doc.txt'
--- doc/ecryptfs-pkcs11-helper-doc.txt	2009-02-03 08:50:36 +0000
+++ doc/ecryptfs-pkcs11-helper-doc.txt	2013-11-22 17:26:11 +0000
@@ -53,7 +53,7 @@
 	key Attributes:
 		id (String)
 			PKCS#11 serialized object id, this object id can be
-			aquired using ecryptfs-manager, the default value of
+			acquired using ecryptfs-manager, the default value of
 			this field is a list of "DN (serial) [serialized id]".
 
 		x509file (String)

=== modified file 'doc/manpage/ecryptfs.7'
--- doc/manpage/ecryptfs.7	2013-03-11 05:54:36 +0000
+++ doc/manpage/ecryptfs.7	2013-11-22 17:26:11 +0000
@@ -67,7 +67,7 @@
 The actual password is passphrase. Since the password is visible to utilities (like ps under Unix) this form should only be used where security is not important.
 .TP
 .B passphrase_passwd_file=(filename)
-The password should be specified in a file with passwd=(passphrase). It is highly reccomended that the file be stored on a secure medium such as a personal usb key.
+The password should be specified in a file with passwd=(passphrase). It is highly recommended that the file be stored on a secure medium such as a personal usb key.
 .TP
 .B passphrase_passwd_fd=(file descriptor)
 The password is specified through the specified file descriptor.
@@ -79,7 +79,7 @@
 The filename should be the filename of a file containing an RSA SSL key.
 .TP
 .B openssl_passwd_file=(filename)
-The password should be specified in a file with openssl_passwd=(openssl-password). It is highly reccomended that the file be stored on a secure medium such as a personal usb key.
+The password should be specified in a file with openssl_passwd=(openssl-password). It is highly recommended that the file be stored on a secure medium such as a personal usb key.
 .TP
 .B openssl_passwd_fd=(file descriptor)
 The password is specified through the specified file descriptor.

=== modified file 'tests/README'
--- tests/README	2012-11-02 23:20:18 +0000
+++ tests/README	2013-11-22 17:26:11 +0000
@@ -99,7 +99,7 @@
 
  8) Create a new file, inside that directory, called test.c and implement the
     test case in the new file. Be sure to add a header, including the GPLv2
-    text, similiar to what is in the example test script that was modified in
+    text, similar to what is in the example test script that was modified in
     step 3).
 
  9) Update the test script (mmap-close.sh) to call the test binary after the