Merge lp:~stefanor/ubuntu-packaging-guide/program-spelling into lp:ubuntu-packaging-guide
- program-spelling
- Merge into trunk
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 |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Andrew Starr-Bochicchio | Approve | ||
Review via email:
|
Commit message
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
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Andrew Starr-Bochicchio (andrewsomething) wrote : | # |
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 |
Looks good. Thanks for fixing this up!