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

Proposed by Stefano Rivera
Status: Merged
Merged at revision: 79
Proposed branch: lp:~stefanor/ubuntu-packaging-guide/program-spelling
Merge into: lp:ubuntu-packaging-guide
Diff against target: 329 lines (+44/-44)
9 files modified
chroots.rst (+1/-1)
debian-dir-overview.rst (+1/-1)
getting-set-up.rst (+1/-1)
kde.rst (+3/-3)
libraries.rst (+15/-15)
packaging-new-software.rst (+5/-5)
patches-to-packages.rst (+12/-12)
security-and-stable-release-updates.rst (+3/-3)
udd-patchsys.rst (+3/-3)
To merge this branch: bzr merge lp:~stefanor/ubuntu-packaging-guide/program-spelling
Reviewer Review Type Date Requested Status
Andrew Starr-Bochicchio Approve
Review via email: mp+95778@code.launchpad.net

Description of the change

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.

To post a comment you must log in.
Revision history for this message
Andrew Starr-Bochicchio (andrewsomething) wrote :

Looks good. Thanks for fixing this up!

review: Approve

Preview Diff

[H/L] Next/Prev Comment, [J/K] Next/Prev File, [N/P] Next/Prev Hunk
1=== modified file 'chroots.rst'
2--- chroots.rst 2011-08-31 04:02:50 +0000
3+++ chroots.rst 2012-03-04 13:07:19 +0000
4@@ -57,7 +57,7 @@
5 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.
6
7 Full virtual machines can be useful for packaging and testing
8-programmes. TestDrive is a program to automate syncing and running
9+programs. TestDrive is a program to automate syncing and running
10 daily ISO images, see `the TestDrive wiki page`_ for more information.
11
12 You can also set up pbuilder to pause when it comes across a build
13
14=== modified file 'debian-dir-overview.rst'
15--- debian-dir-overview.rst 2012-02-25 16:08:29 +0000
16+++ debian-dir-overview.rst 2012-03-04 13:07:19 +0000
17@@ -257,7 +257,7 @@
18
19 In the first case, the ``install`` file should have one line per file
20 installed,
21-specifying both the the file and the installation directory. For example, the
22+specifying both the file and the installation directory. For example, the
23 following ``install`` file would install the script ``foo`` in the source
24 package's
25 root directory to ``usr/bin`` and a desktop file in the ``debian`` directory to
26
27=== modified file 'getting-set-up.rst'
28--- getting-set-up.rst 2011-08-31 04:02:50 +0000
29+++ getting-set-up.rst 2012-03-04 13:07:19 +0000
30@@ -81,7 +81,7 @@
31
32 GPG will first ask you which kind of key you want to generate. Choosing the
33 default (RSA and DSA) is fine. Next it will ask you about the keysize. The
34-default (currently 2048) is fine, but 4096 is more secure. Afterward, it will
35+default (currently 2048) is fine, but 4096 is more secure. Afterwards, it will
36 ask you if you want it to expire the key at some stage. It is safe to say "0",
37 which means the key will never expire. The last questions will be about your
38 name and email address. Just pick the ones you are going to use for Ubuntu
39
40=== modified file 'kde.rst'
41--- kde.rst 2011-08-31 04:02:50 +0000
42+++ kde.rst 2012-03-04 13:07:19 +0000
43@@ -2,7 +2,7 @@
44 KDE Packaging
45 =============
46
47-Packaging of KDE programmes in Ubuntu is managed by the Kubuntu and
48+Packaging of KDE programs in Ubuntu is managed by the Kubuntu and
49 MOTU teams. You can contact the Kubuntu team on the `Kubuntu mailing
50 list`_ and ``#kubuntu-devel`` Freenode IRC channl. More information
51 about Kubuntu development is on the `Kubuntu wiki page`_.
52@@ -14,7 +14,7 @@
53 Patching Policy
54 ---------------
55
56-Kubuntu does not add patches to KDE programmes unless they come from
57+Kubuntu does not add patches to KDE programs unless they come from
58 the upstream authors or submitted upstream with the expectation they
59 will be merged soon or we have consulted the issue with the upstream
60 authors.
61@@ -67,7 +67,7 @@
62 these together manually, contact `dpm`_ to do this.
63
64 If a package is moved from universe to main it will need to be
65-reuploaded before the translations get imported into Launchpad.
66+re-uploaded before the translations get imported into Launchpad.
67
68 ``.desktop`` files also need translations. We patch KDELibs to read
69 translations out of ``.po`` files which are pointed to by a line
70
71=== modified file 'libraries.rst'
72--- libraries.rst 2011-10-03 13:31:26 +0000
73+++ libraries.rst 2012-03-04 13:07:19 +0000
74@@ -3,13 +3,13 @@
75 ================
76
77 Shared libraries are compiled code which is intended to be shared
78-among several different programmes. They are distributed as ``.so``
79+among several different programs. They are distributed as ``.so``
80 files in ``/usr/lib/``.
81
82 A library exports symbols which are the compiled versions of
83 functions, classes and variables. A library has a name called an
84 SONAME which includes a version number. This SONAME version does not
85-necessarily match the public release version number. A programme gets
86+necessarily match the public release version number. A program gets
87 compiled against a given SONAME version of the library. If any of the
88 symbols is removed or changes then the version number needs to be
89 changed which forces any packages using that library to be recompiled
90@@ -19,15 +19,15 @@
91 packagers have to keep separate version numbers.
92
93 Libraries are usually distributed by upstream as standalone releases. Sometimes
94-they are distributed as part of a programme. In this case they can be included
95-in the binary package along with the programme (this is called bundling) if you
96-do not expect any other programmes to use the library, more often they should be
97+they are distributed as part of a program. In this case they can be included
98+in the binary package along with the program (this is called bundling) if you
99+do not expect any other programs to use the library, more often they should be
100 split out into separate binary packages.
101
102 The libraries themselves are put into a binary package named ``libfoo1`` where
103 ``foo`` is the name of the library and ``1`` is the version from the SONAME.
104 Development files from the package, such as header files, needed to compile
105-programmes against the library are put into a package called ``libfoo-dev``.
106+programs against the library are put into a package called ``libfoo-dev``.
107
108
109 An Example
110@@ -64,12 +64,12 @@
111
112 The last one is the actual library, complete with minor and point version
113 number. The first one is a symlink which points to the actual library. The
114-symlink is what programmes using the library will look for, the running
115-programmes do not care about the minor version number.
116+symlink is what programs using the library will look for, the running
117+programs do not care about the minor version number.
118
119-``libnova-dev.install`` includes all the files needed to compile a programme
120+``libnova-dev.install`` includes all the files needed to compile a program
121 with this library. Header files, a config binary, the ``.la`` libtool file and
122-``libnova.so`` which is another symlink pointing at the library, programmes
123+``libnova.so`` which is another symlink pointing at the library, programs
124 compiling against the library do not care about the major version number
125 (although the binary they compile into will).
126
127@@ -82,11 +82,11 @@
128 ----------------
129
130 The -dev package also ships ``usr/lib/libnova.a``. This is a static library,
131-an alternative to the shared library. Any programme compiled against the
132+an alternative to the shared library. Any program compiled against the
133 static library will include the code directory into itself. This gets round
134 worrying about binary compatibility of the library. However it also means that
135-any bugs, including security issues, will not be updated along with the libary
136-until the programme is recompiled. For this reason programmes using static
137+any bugs, including security issues, will not be updated along with the library
138+until the program is recompiled. For this reason programs using static
139 libraries are discouraged.
140
141
142@@ -94,11 +94,11 @@
143 ------------
144
145 When a package builds against a library the ``shlibs`` mechanism will add a
146-package dependency on that library. This is why most programmes will have
147+package dependency on that library. This is why most programs will have
148 ``Depends: ${shlibs:Depends}`` in ``debian/control``. That gets replaced with
149 the library dependencies at build time. However shlibs can only make it depend
150 on the major ABI version number, ``2`` in our libnova example, so if new symbols
151-get added in libnova 2.1 a programme using these symbols could still be
152+get added in libnova 2.1 a program using these symbols could still be
153 installed against libnova ABI 2.0 which would then crash.
154
155 To make the library dependencies more precise we keep ``.symbols`` files that
156
157=== modified file 'packaging-new-software.rst'
158--- packaging-new-software.rst 2011-12-02 18:49:07 +0000
159+++ packaging-new-software.rst 2012-03-04 13:07:19 +0000
160@@ -8,8 +8,8 @@
161 creating a package for Ubuntu or a PPA. This guide will take you through the
162 steps of packaging new software.
163
164-Checking the Programme
165-----------------------
166+Checking the Program
167+--------------------
168
169 The first stage in packaging is to get the released tar from upstream (we call
170 the authors of applications "upstream") and check that it compiles and runs.
171@@ -52,7 +52,7 @@
172 $ sudo apt-get install libqrencode-dev libzbar-dev libzbarqt-dev
173 $ make
174
175-If the compile completes successfully you can install and run the programme::
176+If the compile completes successfully you can install and run the program::
177
178 $ sudo make install
179 $ kqrcode
180@@ -97,7 +97,7 @@
181 Build-Depends: debhelper (>= 7.0.50~), cmake, libqt4-dev, kdelibs5-dev,
182 libqrencode-dev, libzbar-dev, libzbarqt-dev
183
184-You will also need to fill in a description of the programme in the
185+You will also need to fill in a description of the program in the
186 ``Description:`` field.
187
188 ``copyright`` needs to be filled in to follow the licence of the upstream
189@@ -204,7 +204,7 @@
190
191 - `Debian Developer's Reference, 5.1. New packages`_ - The entire
192 document is invaluable for both Ubuntu and Debian packagers. This
193- section documents processes for sumbitting new packages.
194+ section documents processes for submitting new packages.
195
196 In some cases, it might make sense to go directly into Ubuntu first. For
197 instance, Debian might be in a freeze making it unlikely that you're
198
199=== modified file 'patches-to-packages.rst'
200--- patches-to-packages.rst 2011-07-25 12:30:46 +0000
201+++ patches-to-packages.rst 2012-03-04 13:07:19 +0000
202@@ -69,32 +69,32 @@
203 To add a new patch you need to tell Quilt to create a new patch, tell it which
204 files that patch should change, edit the files then refresh the patch::
205
206- $ quilt new kubuntu_02_programme_description.diff
207- Patch kubuntu_02_programme_description.diff is now on top
208+ $ quilt new kubuntu_02_program_description.diff
209+ Patch kubuntu_02_program_description.diff is now on top
210 $ quilt add src/main.cpp
211- File src/main.cpp added to patch kubuntu_02_programme_description.diff
212- $ sed -i "s,Webcam picture retriever,Webcam snapshot programme,"
213+ File src/main.cpp added to patch kubuntu_02_program_description.diff
214+ $ sed -i "s,Webcam picture retriever,Webcam snapshot program,"
215 src/main.cpp
216 $ quilt refresh
217- Refreshed patch kubuntu_02_programme_description.diff
218+ Refreshed patch kubuntu_02_program_description.diff
219
220 The ``quilt add`` step is important, if you forget it the files will not end up
221 in the patch.
222
223 The change will now be in
224-``debian/patches/kubuntu_02_programme_description.diff`` and the ``series``
225+``debian/patches/kubuntu_02_program_description.diff`` and the ``series``
226 file will have had the new patch added to it. You should add the new file to
227 the packaging::
228
229- $ bzr add debian/patches/kubuntu_02_programme_description.diff
230+ $ bzr add debian/patches/kubuntu_02_program_description.diff
231 $ bzr add .pc/*
232- $ dch -i "Add patch kubuntu_02_programme_description.diff to improve the programme description"
233+ $ dch -i "Add patch kubuntu_02_program_description.diff to improve the program description"
234 $ bzr commit
235
236 Quilt keeps its metadata in the ``.pc/`` directory, so currently you need to
237 add that to the packaging too. This should be improved in future.
238
239-As a general rule you should be careful adding patches to programmes unless
240+As a general rule you should be careful adding patches to programs unless
241 they come from upstream, there is often a good reason why that change has not
242 already been made. The above example changes a user interface string for
243 example, so it would break all translations. If in doubt, do ask the upstream
244@@ -135,13 +135,13 @@
245 Then carry on::
246
247 $ quilt push
248- Applied kubuntu_02_programme_description.diff
249+ Applied kubuntu_02_program_description.diff
250
251 It is a good idea to run refresh, this will update the patch relative to the
252 changed upstream source::
253
254 $ quilt refresh
255- Refreshed patch kubuntu_02_programme_description.diff
256+ Refreshed patch kubuntu_02_program_description.diff
257
258 Then commit as usual::
259
260@@ -164,7 +164,7 @@
261
262 Other patch systems used by packages include ``dpatch`` and ``cdbs
263 simple-patchsys``, these work similarly to Quilt by keeping patches in
264-debian/patches but have different commands to apply, unapply or create patches.
265+debian/patches but have different commands to apply, un-apply or create patches.
266 You can use ``edit-patch``, shown in previous chapters, as a reliable way to
267 work with all systems.
268
269
270=== modified file 'security-and-stable-release-updates.rst'
271--- security-and-stable-release-updates.rst 2011-08-31 04:02:50 +0000
272+++ security-and-stable-release-updates.rst 2012-03-04 13:07:19 +0000
273@@ -54,7 +54,7 @@
274
275 $ patch -p1 < /home/user/dbus-vulnerability.diff
276
277-Aftering making the necessary changes, you just hit Ctrl-D or type exit to
278+After making the necessary changes, you just hit Ctrl-D or type exit to
279 leave the temporary shell.
280
281 Formatting the changelog and patches
282@@ -62,7 +62,7 @@
283
284 After applying your patches you will want to update the changelog. The ``dch``
285 command is used to edit the ``debian/changelog`` file and ``edit-patch`` will
286-launch ``dch`` automatically after unapplying all the patches. If you are not
287+launch ``dch`` automatically after un-applying all the patches. If you are not
288 using ``edit-patch``, you can launch ``dch -i`` manually. Unlike with regular
289 patches, you should use the following format (note the distribution name uses
290 lucid-security since this is a security update for Lucid) for security
291@@ -127,7 +127,7 @@
292 loss. Due to the potential for such updates to themselves introduce bugs we
293 only allow this where the change can be easily understood and verified.
294
295-The process for Stable Release Updates is just the same as the proccess for
296+The process for Stable Release Updates is just the same as the process for
297 security bugs except you should subscribe ``ubuntu-sru`` to the bug.
298
299 The update will go into the ``proposed`` archive (for example
300
301=== modified file 'udd-patchsys.rst'
302--- udd-patchsys.rst 2012-01-31 23:04:43 +0000
303+++ udd-patchsys.rst 2012-03-04 13:07:19 +0000
304@@ -47,7 +47,7 @@
305 With newer versions of Bazaar as mentioned above, merging new Debian versions
306 to Ubuntu versions should be quite easy now, even when one or both packages
307 have quilt patches. Just use ``bzr merge`` as you normally would. Under the
308-hood, Bazaar will first unapply all the patches, then do the merge, then if
309+hood, Bazaar will first un-apply all the patches, then do the merge, then if
310 there are no conflicts, it will re-apply the patches leaving you again with a
311 source branch in the ``quilt push -a`` state.
312
313@@ -61,7 +61,7 @@
314 $ cd precise
315 $ bzr merge ../wheezy
316
317-If there are merge conflicts, the quilt patches will remain unapplied so that
318+If there are merge conflicts, the quilt patches will remain un-applied so that
319 you can resolve the conflicts more easily. You would use a combination of bzr
320 and quilt commands to resolve the conflicts, until all the quilt patches are
321 applied again. Then you're ready to commit, push, and build as you normally
322@@ -147,7 +147,7 @@
323 the UDD source branch importer `currently includes any existing .pc
324 directory`_ in the imported branch. This can cause conflicts, or other
325 unwanted or unknown changes because you've essentially got two conflicting
326-version control systems competing for the same thing (i.e. bzr and quilt3).
327+version control systems competing for the same thing (i.e. bzr and quilt).
328 For now, the best recommendation is to revert any changes to the ``.pc``
329 directory in your branch.
330

Subscribers

People subscribed via source and target branches