chiark / gitweb /
dgit: Fix trailing whitespace
[dgit.git] / dgit-user.7.pod
index 08647c61bbd3e80f5c2a41ecfbe06cb7e37294a7..c33cf300e36b096c7b9bd0717f6374b81ba91ef0 100644 (file)
@@ -32,7 +32,7 @@ or L<dgit(1)> and L<dgit(7)>.
 
     % dgit clone glibc jessie,-security
     % cd glibc
 
     % dgit clone glibc jessie,-security
     % cd glibc
-    % wget 'https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=28250;mbox=yes;msg=89' | patch -p1 -u
+    % curl 'https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=28250;mbox=yes;msg=89' | patch -p1 -u
     % git commit -a -m 'Fix libc lost output bug'
     % gbp dch -S --since=dgit/dgit/sid --ignore-branch --commit
     % sudo apt-get build-dep glibc
     % git commit -a -m 'Fix libc lost output bug'
     % gbp dch -S --since=dgit/dgit/sid --ignore-branch --commit
     % sudo apt-get build-dep glibc
@@ -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,
@@ -232,7 +232,7 @@ that are in debian/patches before you do anything else!
 
 Debian package builds are often quite messy:
 they may modify files which are also committed to git,
 
 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>.
+or leave outputs and temporary files not covered by C<.gitignore>.
 
 If you always commit,
 you can use
 
 If you always commit,
 you can use
@@ -303,6 +303,26 @@ C<-uc> means not to pgp-sign the results.
 C<-b> means build all binary packages,
 but not to build a source package.
 
 C<-b> means build all binary packages,
 but not to build a source package.
 
+=head2 Using sbuild
+
+You can build in an schroot chroot, with sbuild, instead of in your
+main environment.  (sbuild is used by the Debian build daemons.)
+
+=over 4
+
+    % git clean -xdf
+    % sbuild -c jessie -A --no-clean-source \
+             --dpkg-source-opts='-Zgzip -z1 --format=1.0 -sn'
+
+=back
+
+Note that this will seem to leave a "source package"
+(.dsc and .tar.gz)
+in the parent directory,
+but that source package should not be used.
+It is likely to be broken.
+For more information see Debian bug #868527.
+
 =head1 INSTALLING
 
 =head2 Debian Jessie or older
 =head1 INSTALLING
 
 =head2 Debian Jessie or older
@@ -349,7 +369,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,7 +382,7 @@ 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,
 and because it will mislead and confuse apt.
 
 This is not ideal because it makes it hard to tell what is installed,
 and because it will mislead and confuse apt.