Merge lp:~stefanor/ubuntu-packaging-guide/program-spelling into lp:ubuntu-packaging-guide

[Stefano Rivera]

As far as I know, the spelling "programme" is rarely used for computer programs in UK english. We use the US "program" instead.

Also, some other bits.

[Andrew Starr-Bochicchio (andrewsomething)]

Looks good. Thanks for fixing this up!

review: Approve

=== modified file 'chroots.rst'
--- chroots.rst	2011-08-31 04:02:50 +0000
+++ chroots.rst	2012-03-04 13:07:19 +0000
@@ -57,7 +57,7 @@
 SBuild is a system similar to PBuilder for creating an environment to run test package builds in.  It closer matches that used by Launchpad for building packages but takes some more setup compared to PBuilder.  See `the Security Team Build Environment wiki page`_ for a full explanation.
 
 Full virtual machines can be useful for packaging and testing
-programmes.  TestDrive is a program to automate syncing and running
+programs.  TestDrive is a program to automate syncing and running
 daily ISO images, see `the TestDrive wiki page`_ for more information.
 
 You can also set up pbuilder to pause when it comes across a build
 
=== modified file 'debian-dir-overview.rst'
--- debian-dir-overview.rst	2012-02-25 16:08:29 +0000
+++ debian-dir-overview.rst	2012-03-04 13:07:19 +0000
@@ -257,7 +257,7 @@
 
 In the first case, the ``install`` file should have one line per file 
 installed, 
-specifying both the the file and the installation directory. For example, the 
+specifying both the file and the installation directory. For example, the 
 following ``install`` file would install the script ``foo`` in the source 
 package's 
 root directory to ``usr/bin`` and a desktop file in the ``debian`` directory to 
 
=== modified file 'getting-set-up.rst'
--- getting-set-up.rst	2011-08-31 04:02:50 +0000
+++ getting-set-up.rst	2012-03-04 13:07:19 +0000
@@ -81,7 +81,7 @@
 
 GPG will first ask you which kind of key you want to generate. Choosing the
 default (RSA and DSA) is fine. Next it will ask you about the keysize. The
-default (currently 2048) is fine, but 4096 is more secure. Afterward, it will
+default (currently 2048) is fine, but 4096 is more secure. Afterwards, it will
 ask you if you want it to expire the key at some stage. It is safe to say "0",
 which means the key will never expire. The last questions will be about your
 name and email address. Just pick the ones you are going to use for Ubuntu
 
=== modified file 'kde.rst'
--- kde.rst	2011-08-31 04:02:50 +0000
+++ kde.rst	2012-03-04 13:07:19 +0000
@@ -2,7 +2,7 @@
 KDE Packaging
 =============
 
-Packaging of KDE programmes in Ubuntu is managed by the Kubuntu and
+Packaging of KDE programs in Ubuntu is managed by the Kubuntu and
 MOTU teams.  You can contact the Kubuntu team on the `Kubuntu mailing
 list`_ and ``#kubuntu-devel`` Freenode IRC channl.  More information
 about Kubuntu development is on the `Kubuntu wiki page`_.
@@ -14,7 +14,7 @@
 Patching Policy
 ---------------
 
-Kubuntu does not add patches to KDE programmes unless they come from
+Kubuntu does not add patches to KDE programs unless they come from
 the upstream authors or submitted upstream with the expectation they
 will be merged soon or we have consulted the issue with the upstream
 authors.
@@ -67,7 +67,7 @@
 these together manually, contact `dpm`_ to do this.
 
 If a package is moved from universe to main it will need to be
-reuploaded before the translations get imported into Launchpad.
+re-uploaded before the translations get imported into Launchpad.
 
 ``.desktop`` files also need translations.  We patch KDELibs to read
 translations out of ``.po`` files which are pointed to by a line
 
=== modified file 'libraries.rst'
--- libraries.rst	2011-10-03 13:31:26 +0000
+++ libraries.rst	2012-03-04 13:07:19 +0000
@@ -3,13 +3,13 @@
 ================
 
 Shared libraries are compiled code which is intended to be shared
-among several different programmes.  They are distributed as ``.so``
+among several different programs.  They are distributed as ``.so``
 files in ``/usr/lib/``.  
 
 A library exports symbols which are the compiled versions of
 functions, classes and variables.  A library has a name called an
 SONAME which includes a version number.  This SONAME version does not
-necessarily match the public release version number.  A programme gets
+necessarily match the public release version number.  A program gets
 compiled against a given SONAME version of the library.  If any of the
 symbols is removed or changes then the version number needs to be
 changed which forces any packages using that library to be recompiled
@@ -19,15 +19,15 @@
 packagers have to keep separate version numbers.
 
 Libraries are usually distributed by upstream as standalone releases. Sometimes
-they are distributed as part of a programme.  In this case they can be included
-in the binary package along with the programme (this is called bundling) if you
-do not expect any other programmes to use the library, more often they should be
+they are distributed as part of a program.  In this case they can be included
+in the binary package along with the program (this is called bundling) if you
+do not expect any other programs to use the library, more often they should be
 split out into separate binary packages.
 
 The libraries themselves are put into a binary package named ``libfoo1`` where
 ``foo`` is the name of the library and ``1`` is the version from the SONAME. 
 Development files from the package, such as header files, needed to compile
-programmes against the library are put into a package called ``libfoo-dev``.
+programs against the library are put into a package called ``libfoo-dev``.
 
 
 An Example
@@ -64,12 +64,12 @@
 
 The last one is the actual library, complete with minor and point version
 number.  The first one is a symlink which points to the actual library.  The
-symlink is what programmes using the library will look for, the running
-programmes do not care about the minor version number.
+symlink is what programs using the library will look for, the running
+programs do not care about the minor version number.
 
-``libnova-dev.install`` includes all the files needed to compile a programme
+``libnova-dev.install`` includes all the files needed to compile a program
 with this library.  Header files, a config binary, the ``.la`` libtool file and
-``libnova.so`` which is another symlink pointing at the library, programmes
+``libnova.so`` which is another symlink pointing at the library, programs
 compiling against the library do not care about the major version number
 (although the binary they compile into will).
 
@@ -82,11 +82,11 @@
 ----------------
 
 The -dev package also ships ``usr/lib/libnova.a``.  This is a static library,
-an alternative to the shared library.  Any programme compiled against the
+an alternative to the shared library.  Any program compiled against the
 static library will include the code directory into itself.  This gets round
 worrying about binary compatibility of the library.  However it also means that
-any bugs, including security issues, will not be updated along with the libary
-until the programme is recompiled.  For this reason programmes using static
+any bugs, including security issues, will not be updated along with the library
+until the program is recompiled.  For this reason programs using static
 libraries are discouraged.
 
 
@@ -94,11 +94,11 @@
 ------------
 
 When a package builds against a library the ``shlibs`` mechanism will add a
-package dependency on that library.  This is why most programmes will have
+package dependency on that library.  This is why most programs will have
 ``Depends: ${shlibs:Depends}`` in ``debian/control``.  That gets replaced with
 the library dependencies at build time.  However shlibs can only make it depend
 on the major ABI version number, ``2`` in our libnova example, so if new symbols
-get added in libnova 2.1 a programme using these symbols could still be
+get added in libnova 2.1 a program using these symbols could still be
 installed against libnova ABI 2.0 which would then crash.
 
 To make the library dependencies more precise we keep ``.symbols`` files that
 
=== modified file 'packaging-new-software.rst'
--- packaging-new-software.rst	2011-12-02 18:49:07 +0000
+++ packaging-new-software.rst	2012-03-04 13:07:19 +0000
@@ -8,8 +8,8 @@
 creating a package for Ubuntu or a PPA. This guide will take you through the 
 steps of packaging new software.
 
-Checking the Programme
-----------------------
+Checking the Program
+--------------------
 
 The first stage in packaging is to get the released tar from upstream (we call
 the authors of applications "upstream") and check that it compiles and runs.
@@ -52,7 +52,7 @@
     $ sudo apt-get install libqrencode-dev libzbar-dev libzbarqt-dev
     $ make
 
-If the compile completes successfully you can install and run the programme::
+If the compile completes successfully you can install and run the program::
 
     $ sudo make install
     $ kqrcode
@@ -97,7 +97,7 @@
     Build-Depends: debhelper (>= 7.0.50~), cmake, libqt4-dev, kdelibs5-dev,
     libqrencode-dev, libzbar-dev, libzbarqt-dev
 
-You will also need to fill in a description of the programme in the
+You will also need to fill in a description of the program in the
 ``Description:`` field.
 
 ``copyright`` needs to be filled in to follow the licence of the upstream
@@ -204,7 +204,7 @@
 
   - `Debian Developer's Reference, 5.1. New packages`_ - The entire 
     document is invaluable for both Ubuntu and Debian packagers. This
-    section documents processes for sumbitting new packages.
+    section documents processes for submitting new packages.
 
 In some cases, it might make sense to go directly into Ubuntu first. For
 instance, Debian might be in a freeze making it unlikely that you're
 
=== modified file 'patches-to-packages.rst'
--- patches-to-packages.rst	2011-07-25 12:30:46 +0000
+++ patches-to-packages.rst	2012-03-04 13:07:19 +0000
@@ -69,32 +69,32 @@
 To add a new patch you need to tell Quilt to create a new patch, tell it which
 files that patch should change, edit the files then refresh the patch::
 
-    $ quilt new kubuntu_02_programme_description.diff
-    Patch kubuntu_02_programme_description.diff is now on top
+    $ quilt new kubuntu_02_program_description.diff
+    Patch kubuntu_02_program_description.diff is now on top
     $ quilt add src/main.cpp
-    File src/main.cpp added to patch kubuntu_02_programme_description.diff
-    $ sed -i "s,Webcam picture retriever,Webcam snapshot programme,"
+    File src/main.cpp added to patch kubuntu_02_program_description.diff
+    $ sed -i "s,Webcam picture retriever,Webcam snapshot program,"
     src/main.cpp
     $ quilt refresh
-    Refreshed patch kubuntu_02_programme_description.diff
+    Refreshed patch kubuntu_02_program_description.diff
 
 The ``quilt add`` step is important, if you forget it the files will not end up
 in the patch.
 
 The change will now be in
-``debian/patches/kubuntu_02_programme_description.diff`` and the ``series``
+``debian/patches/kubuntu_02_program_description.diff`` and the ``series``
 file will have had the new patch added to it.  You should add the new file to
 the packaging::
 
-    $ bzr add debian/patches/kubuntu_02_programme_description.diff
+    $ bzr add debian/patches/kubuntu_02_program_description.diff
     $ bzr add .pc/*
-    $ dch -i "Add patch kubuntu_02_programme_description.diff to improve the programme description"
+    $ dch -i "Add patch kubuntu_02_program_description.diff to improve the program description"
     $ bzr commit
 
 Quilt keeps its metadata in the ``.pc/`` directory, so currently you need to
 add that to the packaging too.  This should be improved in future.
 
-As a general rule you should be careful adding patches to programmes unless
+As a general rule you should be careful adding patches to programs unless
 they come from upstream, there is often a good reason why that change has not
 already been made.  The above example changes a user interface string for
 example, so it would break all translations.  If in doubt, do ask the upstream
@@ -135,13 +135,13 @@
 Then carry on::
 
     $ quilt push
-    Applied kubuntu_02_programme_description.diff
+    Applied kubuntu_02_program_description.diff
 
 It is a good idea to run refresh, this will update the patch relative to the
 changed upstream source::
 
     $ quilt refresh
-    Refreshed patch kubuntu_02_programme_description.diff
+    Refreshed patch kubuntu_02_program_description.diff
 
 Then commit as usual::
 
@@ -164,7 +164,7 @@
 
 Other patch systems used by packages include ``dpatch`` and ``cdbs
 simple-patchsys``, these work similarly to Quilt by keeping patches in
-debian/patches but have different commands to apply, unapply or create patches.
+debian/patches but have different commands to apply, un-apply or create patches.
 You can use ``edit-patch``, shown in previous chapters, as a reliable way to
 work with all systems.
 
 
=== modified file 'security-and-stable-release-updates.rst'
--- security-and-stable-release-updates.rst	2011-08-31 04:02:50 +0000
+++ security-and-stable-release-updates.rst	2012-03-04 13:07:19 +0000
@@ -54,7 +54,7 @@
 
     $ patch -p1 < /home/user/dbus-vulnerability.diff
 
-Aftering making the necessary changes, you just hit Ctrl-D or type exit to
+After making the necessary changes, you just hit Ctrl-D or type exit to
 leave the temporary shell.
 
 Formatting the changelog and patches
@@ -62,7 +62,7 @@
 
 After applying your patches you will want to update the changelog. The ``dch``
 command is used to edit the ``debian/changelog`` file and ``edit-patch`` will
-launch ``dch`` automatically after unapplying all the patches. If you are not
+launch ``dch`` automatically after un-applying all the patches. If you are not
 using ``edit-patch``, you can launch ``dch -i`` manually. Unlike with regular
 patches, you should use the following format (note the distribution name uses
 lucid-security since this is a security update for Lucid) for security
@@ -127,7 +127,7 @@
 loss.  Due to the potential for such updates to themselves introduce bugs we
 only allow this where the change can be easily understood and verified.
 
-The process for Stable Release Updates is just the same as the proccess for
+The process for Stable Release Updates is just the same as the process for
 security bugs except you should subscribe ``ubuntu-sru`` to the bug.
 
 The update will go into the ``proposed`` archive (for example
 
=== modified file 'udd-patchsys.rst'
--- udd-patchsys.rst	2012-01-31 23:04:43 +0000
+++ udd-patchsys.rst	2012-03-04 13:07:19 +0000
@@ -47,7 +47,7 @@
 With newer versions of Bazaar as mentioned above, merging new Debian versions
 to Ubuntu versions should be quite easy now, even when one or both packages
 have quilt patches.  Just use ``bzr merge`` as you normally would.  Under the
-hood, Bazaar will first unapply all the patches, then do the merge, then if
+hood, Bazaar will first un-apply all the patches, then do the merge, then if
 there are no conflicts, it will re-apply the patches leaving you again with a
 source branch in the ``quilt push -a`` state.
 
@@ -61,7 +61,7 @@
     $ cd precise
     $ bzr merge ../wheezy
 
-If there are merge conflicts, the quilt patches will remain unapplied so that
+If there are merge conflicts, the quilt patches will remain un-applied so that
 you can resolve the conflicts more easily.  You would use a combination of bzr
 and quilt commands to resolve the conflicts, until all the quilt patches are
 applied again.  Then you're ready to commit, push, and build as you normally
@@ -147,7 +147,7 @@
 the UDD source branch importer `currently includes any existing .pc
 directory`_ in the imported branch.  This can cause conflicts, or other
 unwanted or unknown changes because you've essentially got two conflicting
-version control systems competing for the same thing (i.e. bzr and quilt3).
+version control systems competing for the same thing (i.e. bzr and quilt).
 For now, the best recommendation is to revert any changes to the ``.pc``
 directory in your branch.