dgit: Option parsing: Fix undefined $suite in some import-dsc.

[dgit.git] / dgit-user.7.pod

diff --git a/dgit-user.7.pod b/dgit-user.7.pod
index ad0cca1da867e3bd19623f0e942723170136627d..d7b610986b4ce15c4dc8d172432c09639035a21d 100644 (file)
--- a/dgit-user.7.pod
+++ b/dgit-user.7.pod
@@ -197,7 +197,7 @@ or upstream's git history.
 But for many packages the real git history
 does not exist,
 or has not been published in a dgitish form.
 But for many packages the real git history
 does not exist,
 or has not been published in a dgitish form.

-So yuu may find that the history is a rather short
+So you may find that the history is a rather short

 history invented by dgit.
 
 dgit histories often contain automatically-generated commits,
 history invented by dgit.
 
 dgit histories often contain automatically-generated commits,


@@ -234,7 +234,7 @@ Debian package builds are often quite messy:
 they may modify files which are also committed to git,
 or leave outputs and teporary files not covered by C<.gitignore>.
 
 they may modify files which are also committed to git,
 or leave outputs and teporary files not covered by C<.gitignore>.
 

-Kf you always commit,
+If you always commit,

 you can use
 
 =over 4
 you can use
 
 =over 4


@@ -349,7 +349,7 @@ The proper solution
 is to build the package for all the architectures you
 have enabled.
 You'll need a chroot for each of the secondary architectures.
 is to build the package for all the architectures you
 have enabled.
 You'll need a chroot for each of the secondary architectures.

-This iw somewhat tiresome,
+This is somewhat tiresome,

 even though Debian has excellent tools for managing chroots.
 C<sbuild-createchroot> from the sbuild package is a
 good starting point.
 even though Debian has excellent tools for managing chroots.
 C<sbuild-createchroot> from the sbuild package is a
 good starting point.


@@ -362,9 +362,9 @@ If neither of those are an option,
 your desperate last resort is to try
 using the same version number
 as the official package for your own package.
 your desperate last resort is to try
 using the same version number
 as the official package for your own package.

-(The verseion is controlled by C<debian/changelog> - see above,)
+(The version is controlled by C<debian/changelog> - see above).

 This is not ideal because it makes it hard to tell what is installed,
 This is not ideal because it makes it hard to tell what is installed,

-because it will mislead and confuse apt.
+and because it will mislead and confuse apt.

 
 With the "same number" approach you may still get errors like
 
 
 With the "same number" approach you may still get errors like