Merge lp:~jr/ubuntu-packaging-guide/fixes into lp:ubuntu-packaging-guide
- fixes
- Merge into trunk
Status: | Merged |
---|---|
Approved by: | Barry Warsaw |
Approved revision: | 61 |
Merged at revision: | 42 |
Proposed branch: | lp:~jr/ubuntu-packaging-guide/fixes |
Merge into: | lp:ubuntu-packaging-guide |
Diff against target: |
900 lines (+182/-227) 13 files modified
debian-dir-overview.rst (+13/-7) fixing-a-bug.rst (+9/-20) getting-set-up.rst (+24/-18) index.rst (+22/-4) introduction-to-ubuntu-development.rst (+5/-5) knowledge-base.rst (+0/-27) udd-intro.rst (+35/-58) udd-latest.rst (+2/-2) udd-merging.rst (+9/-10) udd-patchsys.rst (+9/-10) udd-sponsorship.rst (+9/-9) udd-uploading.rst (+28/-25) udd-working.rst (+17/-32) |
To merge this branch: | bzr merge lp:~jr/ubuntu-packaging-guide/fixes |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Barry Warsaw (community) | Approve | ||
Daniel Holbach (community) | Needs Information | ||
Review via email: mp+67951@code.launchpad.net |
Commit message
Description of the change
A bunch of fixes to tidy up parts of the packaging guide
Jonathan Riddell (jr) wrote : | # |
- Why do you remove the section about libvigraimpex?
- the section following "Then determine the source package corresponding to this binary package::" seems to have been correct before.
apt-cache show <package> gives different results if the binary package has the same or a different name than the source package. So I replaced it with apt-cache showsrc <package> which acts the same in both cases, so the libvigraimpex case is no longer needed.
- bzr commit instead of debcommit? (debcommit does much more than just 'bzr commit')
From bzr 2.4 and bzr-builddeb 2.7.5 bzr commit now magically takes the commit message from debian/changelog too, the feeling among UDD developers is it's better to use bzr commands to keep things consistent.
- Do you think it makes sense to have two copies of the knowledge base article index?
No, I'll remove that
- Why do you leave the link to intrepid and remove the link to natty? (line 419)
Intrepid is used in the doc as an example of a past release. I removed references to Natty as an example of a current development release because it's confusing since it not a current development release.
I don't think the links to release wiki pages are very important either way.
- Is "bzr tag" necessary nowadays?
Yes it tags with the current release version. bzr mark-uploaded is now no longer needed.
- Why do you remove the "update-maintainer" bits?
As agreed with barry this isn't a good place to include it, I'll file a bug to add it back elsewhere such as the debian/ directory introduction page.
- 61. By Jonathan Riddell
-
remove duplicate knowledge base index
Barry Warsaw (barry) wrote : | # |
On the libvigraimpex thing, I think you should show two examples, one where the source and binary package names are the same, and one where they're different, e.g.
$ apt-cache showsrc tomboy | grep ^Package:
Package: tomboy
$ apt-cache showsrc python-vigra | grep ^Package:
Package: libvigraimpex
BTW, there's also now a packaging-dev package which gets you most (but I think not all, e.g. cdbs) packages you'll need to do basic package management. We should recommend people install that if we don't already.
s/every day CD images/every day, CD images/
Are you sure this recommendation will always work:
$ bzr log ubuntu:sysvinit | grep ^tags | head -n 1
IOW no possibility of subsequent tags confusing things, even in the face of user error?
Everything else looks good to me. I think you can merge once those changes are made.
Morten Kjeldgaard (mok0) wrote : | # |
> - Why do you leave the link to intrepid and remove the link to
> natty? (line 419)
>
> Intrepid is used in the doc as an example of a past release. I
> removed references to Natty as an example of a current development
> release because it's confusing since it not a current development
> release.
For documentation purposes such as this it would actually be useful if
Ubuntu releases had a constant code name during the development phase
(like Debians "Sid")... for example "Developing Dodo" :-)
-- Morten
Daniel Holbach (dholbach) wrote : | # |
Could it be that a result of this merge there's a couple of warnings now?
daniel@
sphinx-build -b html -d _build/doctrees . _build/html
Making output directory...
Running Sphinx v1.1pre
loading pickled environment... not yet created
building [html]: targets for 15 source files that are out of date
updating environment: 15 added, 0 changed, 0 removed
reading sources... [100%] udd-working
/home/daniel/
looking for now-outdated files... none found
pickling environment... done
checking consistency... done
preparing documents... done
writing output... [100%] udd-working
/home/daniel/
/home/daniel/
writing additional files... genindex search
copying images... [100%] images/
copying static files... done
dumping search index... done
dumping object inventory... done
build succeeded, 3 warnings.
Build finished. The HTML pages are in _build/html.
daniel@
Shall I file a bug?
Jonathan Riddell (jr) wrote : | # |
index.rst warning fixed
I also fixed the incorrect link in the unrelated fixing-
I've no idea how to fix the indentation in the fixing-
Daniel Holbach (dholbach) wrote : | # |
After a paragraph ending with "::" (indicating a following paragraph in preformatted text), it needs a newline. I fixed that bit in fixing-
daniel@
sphinx-build -b html -d _build/doctrees . _build/html
Making output directory...
Running Sphinx v1.1pre
loading pickled environment... not yet created
building [html]: targets for 15 source files that are out of date
updating environment: 15 added, 0 changed, 0 removed
reading sources... [100%] udd-working
looking for now-outdated files... none found
pickling environment... done
checking consistency... done
preparing documents... done
writing output... [100%] udd-working
writing additional files... genindex search
copying images... [100%] images/
copying static files... done
dumping search index... done
dumping object inventory... done
build succeeded.
Build finished. The HTML pages are in _build/html.
daniel@
Preview Diff
1 | === modified file 'debian-dir-overview.rst' | |||
2 | --- debian-dir-overview.rst 2011-06-01 08:05:03 +0000 | |||
3 | +++ debian-dir-overview.rst 2011-07-15 09:23:07 +0000 | |||
4 | @@ -59,7 +59,7 @@ | |||
5 | 59 | number) appended to the end of the Debian version. So if the Debian hello | 59 | number) appended to the end of the Debian version. So if the Debian hello |
6 | 60 | ``2.6-1`` package was changed by Ubuntu, the version string would be | 60 | ``2.6-1`` package was changed by Ubuntu, the version string would be |
7 | 61 | ``2.6-1ubuntu1``. If a package for the application does not exist in Debian, | 61 | ``2.6-1ubuntu1``. If a package for the application does not exist in Debian, |
9 | 62 | then the Debian revision is ``0`` (e.g., ``2.6-0ubuntu1``). | 62 | then the Debian revision is ``0`` (e.g. ``2.6-0ubuntu1``). |
10 | 63 | 63 | ||
11 | 64 | For further information, see the `changelog section (Section 4.4) | 64 | For further information, see the `changelog section (Section 4.4) |
12 | 65 | <http://www.debian.org/doc/debian-policy/ch-source.html#s-dpkgchangelog>`_ of | 65 | <http://www.debian.org/doc/debian-policy/ch-source.html#s-dpkgchangelog>`_ of |
13 | @@ -115,7 +115,7 @@ | |||
14 | 115 | Maintainer Field spec <https://wiki.ubuntu.com/DebianMaintainerField>`_ on the | 115 | Maintainer Field spec <https://wiki.ubuntu.com/DebianMaintainerField>`_ on the |
15 | 116 | Ubuntu wiki. | 116 | Ubuntu wiki. |
16 | 117 | 117 | ||
18 | 118 | Each additional paragraph describes a binary package built. | 118 | Each additional paragraph describes a binary package to be built. |
19 | 119 | 119 | ||
20 | 120 | For further information, see the `control file section (Chapter 5) | 120 | For further information, see the `control file section (Chapter 5) |
21 | 121 | <http://www.debian.org/doc/debian-policy/ch-controlfields.html>`_ of the Debian | 121 | <http://www.debian.org/doc/debian-policy/ch-controlfields.html>`_ of the Debian |
22 | @@ -264,10 +264,12 @@ | |||
23 | 264 | foo usr/bin | 264 | foo usr/bin |
24 | 265 | debian/bar.desktop usr/share/applications | 265 | debian/bar.desktop usr/share/applications |
25 | 266 | 266 | ||
30 | 267 | In the second case, files installed into ``debian/tmp`` can then be moved into | 267 | When a source package is producing multiple binary packages ``dh`` will |
31 | 268 | separate binary packages using multiple ``$package_name.install`` files. This | 268 | install the files into ``debian/tmp`` rather than directly into |
32 | 269 | is often done to split large amounts of architecture independent data out of | 269 | ``debian/<package>``. Files installed into ``debian/tmp`` can then be moved |
33 | 270 | architecture dependent packages and into ``Architecture: all`` packages. In | 270 | into separate binary packages using multiple ``$package_name.install`` files. |
34 | 271 | This is often done to split large amounts of architecture independent data out | ||
35 | 272 | of architecture dependent packages and into ``Architecture: all`` packages. In | ||
36 | 271 | this case, only the name of the files (or directories) to be installed are | 273 | this case, only the name of the files (or directories) to be installed are |
37 | 272 | needed without the installation directory. For example, ``foo.install`` | 274 | needed without the installation directory. For example, ``foo.install`` |
38 | 273 | containing only the architecture dependent files might look like:: | 275 | containing only the architecture dependent files might look like:: |
39 | @@ -319,6 +321,10 @@ | |||
40 | 319 | 4.11) <http://www.debian.org/doc/debian-policy/ch-source.html#s-debianwatch>`_ | 321 | 4.11) <http://www.debian.org/doc/debian-policy/ch-source.html#s-debianwatch>`_ |
41 | 320 | of the Debian Policy Manual. | 322 | of the Debian Policy Manual. |
42 | 321 | 323 | ||
43 | 324 | For a list of packages where the ``watch`` file reports they are not in sync | ||
44 | 325 | with upstream see `Ubuntu External Health Status | ||
45 | 326 | <http://qa.ubuntuwire.org/uehs/no_updated.html>`_. | ||
46 | 327 | |||
47 | 322 | The source/format file | 328 | The source/format file |
48 | 323 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | 329 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |
49 | 324 | 330 | ||
50 | @@ -327,7 +333,7 @@ | |||
51 | 327 | to use the newer 3.0 source format. In this case, the file should contain a | 333 | to use the newer 3.0 source format. In this case, the file should contain a |
52 | 328 | single line indicating the desired format: | 334 | single line indicating the desired format: |
53 | 329 | 335 | ||
55 | 330 | * ``3.0 (native)`` for Debian native packages or | 336 | * ``3.0 (native)`` for Debian native packages (no upstream version) or |
56 | 331 | 337 | ||
57 | 332 | * ``3.0 (quilt)`` for packages with a separate upstream tarball | 338 | * ``3.0 (quilt)`` for packages with a separate upstream tarball |
58 | 333 | 339 | ||
59 | 334 | 340 | ||
60 | === modified file 'fixing-a-bug.rst' | |||
61 | --- fixing-a-bug.rst 2011-06-03 21:23:43 +0000 | |||
62 | +++ fixing-a-bug.rst 2011-07-15 09:23:07 +0000 | |||
63 | @@ -19,7 +19,7 @@ | |||
64 | 19 | Finding the problem | 19 | Finding the problem |
65 | 20 | =================== | 20 | =================== |
66 | 21 | 21 | ||
68 | 22 | There is a lot of different ways to find things to work on. It might be a bug | 22 | There are a lot of different ways to find things to work on. It might be a bug |
69 | 23 | report you are encountering yourself (which gives you a good opportunity to | 23 | report you are encountering yourself (which gives you a good opportunity to |
70 | 24 | test the fix), or a problem you noted elsewhere, maybe in a bug report. | 24 | test the fix), or a problem you noted elsewhere, maybe in a bug report. |
71 | 25 | 25 | ||
72 | @@ -55,28 +55,16 @@ | |||
73 | 55 | different binary packages. To find the source package for a particular binary | 55 | different binary packages. To find the source package for a particular binary |
74 | 56 | package, type:: | 56 | package, type:: |
75 | 57 | 57 | ||
89 | 58 | $ apt-cache show tomboy | grep ^Source: | 58 | $ apt-cache showsrc tomboy | grep ^Package: |
77 | 59 | |||
78 | 60 | In this case, nothing is printed, meaning that ``tomboy`` is also the name of | ||
79 | 61 | the binary package. An example where the source and binary package names | ||
80 | 62 | differ is ``python-vigra``. While that is the binary package name, the source | ||
81 | 63 | package is actually ``libvigraimpex`` and can be found with this command (and | ||
82 | 64 | its output):: | ||
83 | 65 | |||
84 | 66 | $ apt-cache show python-vigra | grep ^Source: | ||
85 | 67 | Source: libvigraimpex | ||
86 | 68 | |||
87 | 69 | .. XXX: Link to SRU article. | ||
88 | 70 | |||
90 | 71 | 59 | ||
91 | 72 | Getting the code | 60 | Getting the code |
92 | 73 | ================ | 61 | ================ |
93 | 74 | 62 | ||
94 | 75 | Once you know the source package to work on, you will want to get a copy of | 63 | Once you know the source package to work on, you will want to get a copy of |
99 | 76 | the code on your system, so that you can debug it. This is done by | 64 | the code on your system, so that you can debug it. In Ubuntu Distributed |
100 | 77 | :ref:`*branching* the source package <branching>` branch corresponding to the | 65 | Development this is done by :ref:`*branching* the source package <branching>` |
101 | 78 | source package. Launchpad maintains source package branches for all the | 66 | branch corresponding to the source package. Launchpad maintains source package |
102 | 79 | packages in Ubuntu. | 67 | branches for all the packages in Ubuntu. |
103 | 80 | 68 | ||
104 | 81 | Once you've got a local branch of the source package, you can investigate the | 69 | Once you've got a local branch of the source package, you can investigate the |
105 | 82 | bug, create a fix, and upload your proposed fix to Launchpad, in the form of a | 70 | bug, create a fix, and upload your proposed fix to Launchpad, in the form of a |
106 | @@ -84,7 +72,7 @@ | |||
107 | 84 | *merge proposal* <merge-proposal>`, which asks other Ubuntu developers to | 72 | *merge proposal* <merge-proposal>`, which asks other Ubuntu developers to |
108 | 85 | review and approve your change. If they agree with your changes, an Ubuntu | 73 | review and approve your change. If they agree with your changes, an Ubuntu |
109 | 86 | developer will upload the new version of the package to Ubuntu so that | 74 | developer will upload the new version of the package to Ubuntu so that |
111 | 87 | everyone gets the benefit or your excellent fix - and you get a little bit of | 75 | everyone gets the benefit of your excellent fix - and you get a little bit of |
112 | 88 | credit. You're now on your way to becoming an Ubuntu developer! | 76 | credit. You're now on your way to becoming an Ubuntu developer! |
113 | 89 | 77 | ||
114 | 90 | We'll describe specifics on how to branch the code, push your fix, and request | 78 | We'll describe specifics on how to branch the code, push your fix, and request |
115 | @@ -182,7 +170,7 @@ | |||
116 | 182 | 170 | ||
117 | 183 | With the changelog entry written and saved, you can just run:: | 171 | With the changelog entry written and saved, you can just run:: |
118 | 184 | 172 | ||
120 | 185 | debcommit | 173 | bzr commit |
121 | 186 | 174 | ||
122 | 187 | and the change will be committed (locally) with your changelog entry as a | 175 | and the change will be committed (locally) with your changelog entry as a |
123 | 188 | commit message. | 176 | commit message. |
124 | @@ -206,3 +194,4 @@ | |||
125 | 206 | browser. There find the "(+) Propose for merging" link, click it to get the | 194 | browser. There find the "(+) Propose for merging" link, click it to get the |
126 | 207 | change reviewed by somebody and included in Ubuntu. | 195 | change reviewed by somebody and included in Ubuntu. |
127 | 208 | 196 | ||
128 | 197 | .. XXX: Link to SRU article. | ||
129 | 209 | 198 | ||
130 | === modified file 'getting-set-up.rst' | |||
131 | --- getting-set-up.rst 2011-07-12 16:11:03 +0000 | |||
132 | +++ getting-set-up.rst 2011-07-15 09:23:07 +0000 | |||
133 | @@ -4,8 +4,8 @@ | |||
134 | 4 | 4 | ||
135 | 5 | There are a number of things you need to do to get started developing for Ubuntu. | 5 | There are a number of things you need to do to get started developing for Ubuntu. |
136 | 6 | This article is designed to get your computer set up so that you can start | 6 | This article is designed to get your computer set up so that you can start |
139 | 7 | working with packages, and upload your packages to Launchpad. Here's what we'll | 7 | working with packages, and upload your packages to Ubuntu's hosting |
140 | 8 | cover: | 8 | platform, Launchpad. Here's what we'll cover: |
141 | 9 | 9 | ||
142 | 10 | * Installing packaging-related software. This includes: | 10 | * Installing packaging-related software. This includes: |
143 | 11 | 11 | ||
144 | @@ -33,7 +33,7 @@ | |||
145 | 33 | 33 | ||
146 | 34 | There are a number of tools that will make your life as an Ubuntu developer | 34 | There are a number of tools that will make your life as an Ubuntu developer |
147 | 35 | much easier. You will encounter these tools later in this guide. To install | 35 | much easier. You will encounter these tools later in this guide. To install |
149 | 36 | most of the tools you will need, run this command:: | 36 | most of the tools you will need run this command:: |
150 | 37 | 37 | ||
151 | 38 | $ sudo apt-get install gnupg pbuilder ubuntu-dev-tools bzr-builddeb apt-file | 38 | $ sudo apt-get install gnupg pbuilder ubuntu-dev-tools bzr-builddeb apt-file |
152 | 39 | 39 | ||
153 | @@ -55,8 +55,9 @@ | |||
154 | 55 | * ``ubuntu-dev-tools`` (and ``devscripts``, a direct dependency) -- a | 55 | * ``ubuntu-dev-tools`` (and ``devscripts``, a direct dependency) -- a |
155 | 56 | collection of tools that make many packaging tasks easier. | 56 | collection of tools that make many packaging tasks easier. |
156 | 57 | * ``bzr-builddeb`` (and ``bzr``, a dependency) -- distributed version control | 57 | * ``bzr-builddeb`` (and ``bzr``, a dependency) -- distributed version control |
159 | 58 | tools that makes it easy for many developers to collaborate and work on the | 58 | with Bazaar, a new way of working with packages for Ubuntu that will make it |
160 | 59 | same code while keeping it trivial to merge each others work. | 59 | easy for many developers to collaborate and work on the same code while |
161 | 60 | keeping it trivial to merge each others work. | ||
162 | 60 | * ``apt-file`` provides an easy way to find the binary package that contains a | 61 | * ``apt-file`` provides an easy way to find the binary package that contains a |
163 | 61 | given file. | 62 | given file. |
164 | 62 | * ``apt-cache`` (part of the ``apt`` package) provides even more information | 63 | * ``apt-cache`` (part of the ``apt`` package) provides even more information |
165 | @@ -84,12 +85,13 @@ | |||
166 | 84 | which means the key will never expire. The last questions will be about your | 85 | which means the key will never expire. The last questions will be about your |
167 | 85 | name and email address. Just pick the ones you are going to use for Ubuntu | 86 | name and email address. Just pick the ones you are going to use for Ubuntu |
168 | 86 | development here, you can add additional email addresses later on. Adding a | 87 | development here, you can add additional email addresses later on. Adding a |
171 | 87 | comment is not necessary. Then you will have to set a passphrase. Choose a | 88 | comment is not necessary. Then you will have to set a passphrase, choose a |
172 | 88 | safe one. | 89 | safe one (a passphrase is just a password which is allowed to include spaces). |
173 | 89 | 90 | ||
174 | 90 | Now GPG will create a key for you, which can take a little bit of time; it | 91 | Now GPG will create a key for you, which can take a little bit of time; it |
175 | 91 | needs random bytes, so if you give the system some work to do it will be | 92 | needs random bytes, so if you give the system some work to do it will be |
177 | 92 | just fine. Move the cursor around! | 93 | just fine. Move the cursor around, type some paragraphs of random text, load |
178 | 94 | some web page. | ||
179 | 93 | 95 | ||
180 | 94 | Once this is done, you will get a message similar to this one:: | 96 | Once this is done, you will get a message similar to this one:: |
181 | 95 | 97 | ||
182 | @@ -107,8 +109,8 @@ | |||
183 | 107 | 109 | ||
184 | 108 | This will send your key to one keyserver, but a network of keyservers will | 110 | This will send your key to one keyserver, but a network of keyservers will |
185 | 109 | automatically sync the key between themselves. Once this syncing is complete, | 111 | automatically sync the key between themselves. Once this syncing is complete, |
188 | 110 | your signed public key will be ready to verify your your contributions | 112 | your signed public key will be ready to verify your contributions around the |
189 | 111 | around the world. | 113 | world. |
190 | 112 | 114 | ||
191 | 113 | 115 | ||
192 | 114 | Create your SSH key | 116 | Create your SSH key |
193 | @@ -117,10 +119,10 @@ | |||
194 | 117 | SSH_ stands for *Secure Shell*, and it is a protocol that allows you to | 119 | SSH_ stands for *Secure Shell*, and it is a protocol that allows you to |
195 | 118 | exchange data in a secure way over a network. It is common to use SSH to access | 120 | exchange data in a secure way over a network. It is common to use SSH to access |
196 | 119 | and open a shell on another computer, and to use it to securely transfer files. | 121 | and open a shell on another computer, and to use it to securely transfer files. |
199 | 120 | For our purposes, we will mainly be using SSH to securely communicate with | 122 | For our purposes, we will mainly be using SSH to securely upload source packages |
200 | 121 | Launchpad. | 123 | to Launchpad. |
201 | 122 | 124 | ||
203 | 123 | To generate a SSH key, enter:: | 125 | To generate an SSH key, enter:: |
204 | 124 | 126 | ||
205 | 125 | $ ssh-keygen -t rsa | 127 | $ ssh-keygen -t rsa |
206 | 126 | 128 | ||
207 | @@ -156,7 +158,7 @@ | |||
208 | 156 | configure your system to work with Launchpad. This section will focus | 158 | configure your system to work with Launchpad. This section will focus |
209 | 157 | on the following topics: | 159 | on the following topics: |
210 | 158 | 160 | ||
212 | 159 | * What Launchpad is, and creating a Launchpad account | 161 | * What Launchpad is and creating a Launchpad account |
213 | 160 | * Uploading your GPG and SSH keys to Launchpad | 162 | * Uploading your GPG and SSH keys to Launchpad |
214 | 161 | * Configuring Bazaar to work with Launchpad | 163 | * Configuring Bazaar to work with Launchpad |
215 | 162 | * Configuring Bash to work with Bazaar | 164 | * Configuring Bash to work with Bazaar |
216 | @@ -175,6 +177,9 @@ | |||
217 | 175 | information. This will allow you to download and upload code, submit bug | 177 | information. This will allow you to download and upload code, submit bug |
218 | 176 | reports, and more. | 178 | reports, and more. |
219 | 177 | 179 | ||
220 | 180 | Besides hosting Ubuntu, Launchpad can host any Free Software project. For more | ||
221 | 181 | information see the `Launchpad Help wiki <https://help.launchpad.net/>`_. | ||
222 | 182 | |||
223 | 178 | 183 | ||
224 | 179 | Get a Launchpad account | 184 | Get a Launchpad account |
225 | 180 | -------------------------- | 185 | -------------------------- |
226 | @@ -212,8 +217,8 @@ | |||
227 | 212 | sub 4096R/51FBE68C 2010-12-06 | 217 | sub 4096R/51FBE68C 2010-12-06 |
228 | 213 | 218 | ||
229 | 214 | 219 | ||
232 | 215 | Head to https://launchpad.net/people/+me/+editpgpkeys and copy the part about | 220 | Head to https://launchpad.net/people/+me/+editpgpkeys and copy the "Key |
233 | 216 | your "Key fingerprint" into the text box. In the case above this would be | 221 | fingerprint" into the text box. In the case above this would be |
234 | 217 | ``5C28 0144 FB08 91C0 2CF3 37AC 6F0B F90F 43CD E61D``. Now click on "Import | 222 | ``5C28 0144 FB08 91C0 2CF3 37AC 6F0B F90F 43CD E61D``. Now click on "Import |
235 | 218 | Key". | 223 | Key". |
236 | 219 | 224 | ||
237 | @@ -253,7 +258,9 @@ | |||
238 | 253 | ---------------- | 258 | ---------------- |
239 | 254 | 259 | ||
240 | 255 | Bazaar is the tool we use to store code changes in a logical way, to exchange | 260 | Bazaar is the tool we use to store code changes in a logical way, to exchange |
242 | 256 | proposed changes and merge them, even if development is done concurrently. | 261 | proposed changes and merge them, even if development is done concurrently. It |
243 | 262 | is used for the new Ubuntu Distributed Development method of working with | ||
244 | 263 | Ubuntu packages. | ||
245 | 257 | 264 | ||
246 | 258 | To tell Bazaar who you are, simply run:: | 265 | To tell Bazaar who you are, simply run:: |
247 | 259 | 266 | ||
248 | @@ -278,7 +285,6 @@ | |||
249 | 278 | $ export DEBFULLNAME="Bob Dobbs" | 285 | $ export DEBFULLNAME="Bob Dobbs" |
250 | 279 | $ export DEBEMAIL="subgenius@example.com" | 286 | $ export DEBEMAIL="subgenius@example.com" |
251 | 280 | 287 | ||
252 | 281 | |||
253 | 282 | Now save the file and either restart your terminal or run:: | 288 | Now save the file and either restart your terminal or run:: |
254 | 283 | 289 | ||
255 | 284 | $ source ~/.bashrc | 290 | $ source ~/.bashrc |
256 | 285 | 291 | ||
257 | === modified file 'index.rst' | |||
258 | --- index.rst 2011-04-21 14:53:48 +0000 | |||
259 | +++ index.rst 2011-07-15 09:23:07 +0000 | |||
260 | @@ -3,27 +3,45 @@ | |||
261 | 3 | You can adapt this file completely to your liking, but it should at least | 3 | You can adapt this file completely to your liking, but it should at least |
262 | 4 | contain the root `toctree` directive. | 4 | contain the root `toctree` directive. |
263 | 5 | 5 | ||
265 | 6 | Welcome to ubuntu-packaging-guide's documentation! | 6 | Ubuntu Packaging Guide |
266 | 7 | ================================================== | 7 | ================================================== |
267 | 8 | 8 | ||
268 | 9 | The guide is split up into two sections: | 9 | The guide is split up into two sections: |
269 | 10 | 10 | ||
271 | 11 | * A list of articles based on tasks, so things you want to get done. | 11 | * A list of articles based on tasks, things you want to get done. |
272 | 12 | * A set of :doc:`knowledge base</knowledge-base>` articles that dig deeper | 12 | * A set of :doc:`knowledge base</knowledge-base>` articles that dig deeper |
273 | 13 | into specific bits of our tools and workflows. | 13 | into specific bits of our tools and workflows. |
274 | 14 | 14 | ||
275 | 15 | Articles | ||
276 | 16 | -------- | ||
277 | 17 | |||
278 | 15 | .. toctree:: | 18 | .. toctree:: |
279 | 16 | :maxdepth: 1 | 19 | :maxdepth: 1 |
280 | 17 | 20 | ||
281 | 18 | introduction-to-ubuntu-development | 21 | introduction-to-ubuntu-development |
282 | 19 | getting-set-up | 22 | getting-set-up |
283 | 20 | fixing-a-bug | 23 | fixing-a-bug |
285 | 21 | knowledge-base | 24 | |
286 | 25 | Knowledge Base | ||
287 | 26 | -------------- | ||
288 | 27 | |||
289 | 28 | .. toctree:: | ||
290 | 29 | :maxdepth: 1 | ||
291 | 30 | |||
292 | 31 | debian-dir-overview | ||
293 | 32 | testing | ||
294 | 33 | udd-intro | ||
295 | 34 | udd-working | ||
296 | 35 | udd-sponsorship | ||
297 | 36 | udd-uploading | ||
298 | 37 | udd-latest | ||
299 | 38 | udd-merging | ||
300 | 39 | udd-patchsys | ||
301 | 40 | udd-newpackage | ||
302 | 22 | 41 | ||
303 | 23 | 42 | ||
304 | 24 | Indices and tables | 43 | Indices and tables |
305 | 25 | ================== | 44 | ================== |
306 | 26 | 45 | ||
307 | 27 | * :ref:`genindex` | 46 | * :ref:`genindex` |
308 | 28 | * :ref:`modindex` | ||
309 | 29 | * :ref:`search` | 47 | * :ref:`search` |
310 | 30 | 48 | ||
311 | === modified file 'introduction-to-ubuntu-development.rst' | |||
312 | --- introduction-to-ubuntu-development.rst 2011-02-04 16:44:21 +0000 | |||
313 | +++ introduction-to-ubuntu-development.rst 2011-07-15 09:23:07 +0000 | |||
314 | @@ -13,11 +13,11 @@ | |||
315 | 13 | 13 | ||
316 | 14 | Every time a new version of an application is released, or when someone makes | 14 | Every time a new version of an application is released, or when someone makes |
317 | 15 | a change to the source code that goes into Ubuntu, the source package must be | 15 | a change to the source code that goes into Ubuntu, the source package must be |
323 | 16 | uploaded to the build machines to be compiled. The resulting binary packages | 16 | uploaded to Launchpad's build machines to be compiled. The resulting binary |
324 | 17 | then are distributed to the archive and its mirrors in different countries. | 17 | packages then are distributed to the archive and its mirrors in different |
325 | 18 | The URLs in ``/etc/apt/sources.list`` point to an archive or mirror. Every | 18 | countries. The URLs in ``/etc/apt/sources.list`` point to an archive or mirror. |
326 | 19 | day CD images are built for a selection of different Ubuntu flavours. Ubuntu | 19 | Every day CD images are built for a selection of different Ubuntu flavours. |
327 | 20 | Desktop, Ubuntu Server, Kubuntu and others specify a list of required | 20 | Ubuntu Desktop, Ubuntu Server, Kubuntu and others specify a list of required |
328 | 21 | packages that get on the CD. These CD images are then used for installation | 21 | packages that get on the CD. These CD images are then used for installation |
329 | 22 | tests and provide the feedback for further release planning. | 22 | tests and provide the feedback for further release planning. |
330 | 23 | 23 | ||
331 | 24 | 24 | ||
332 | === removed file 'knowledge-base.rst' | |||
333 | --- knowledge-base.rst 2011-06-03 09:49:34 +0000 | |||
334 | +++ knowledge-base.rst 1970-01-01 00:00:00 +0000 | |||
335 | @@ -1,27 +0,0 @@ | |||
336 | 1 | ============================================ | ||
337 | 2 | Knowledge base of the Ubuntu Packaging Guide | ||
338 | 3 | ============================================ | ||
339 | 4 | |||
340 | 5 | Table of Contents: | ||
341 | 6 | |||
342 | 7 | * General | ||
343 | 8 | |||
344 | 9 | .. toctree:: | ||
345 | 10 | :maxdepth: 1 | ||
346 | 11 | |||
347 | 12 | debian-dir-overview | ||
348 | 13 | testing | ||
349 | 14 | |||
350 | 15 | * Development Processes | ||
351 | 16 | |||
352 | 17 | .. toctree:: | ||
353 | 18 | :maxdepth: 1 | ||
354 | 19 | |||
355 | 20 | udd-intro | ||
356 | 21 | udd-working | ||
357 | 22 | udd-sponsorship | ||
358 | 23 | udd-uploading | ||
359 | 24 | udd-latest | ||
360 | 25 | udd-merging | ||
361 | 26 | udd-patchsys | ||
362 | 27 | udd-newpackage | ||
363 | 28 | 0 | ||
364 | === modified file 'udd-intro.rst' | |||
365 | --- udd-intro.rst 2011-06-03 20:17:00 +0000 | |||
366 | +++ udd-intro.rst 2011-07-15 09:23:07 +0000 | |||
367 | @@ -1,43 +1,36 @@ | |||
371 | 1 | ============================== | 1 | =================================================== |
372 | 2 | Ubuntu Distributed Development | 2 | Ubuntu Distributed Development - Getting the Source |
373 | 3 | ============================== | 3 | =================================================== |
374 | 4 | 4 | ||
375 | 5 | *Ubuntu Distributed Development* (UDD) is a technique for developing Ubuntu | 5 | *Ubuntu Distributed Development* (UDD) is a technique for developing Ubuntu |
376 | 6 | packages that uses tools, processes, and workflows similar to generic | 6 | packages that uses tools, processes, and workflows similar to generic |
379 | 7 | distributed version control (dVCS) system-based software development. The | 7 | distributed version control system (DVCS) based software development. The |
380 | 8 | dVCS used for UDD is Bazaar_. | 8 | DVCS used for UDD is Bazaar_. |
381 | 9 | 9 | ||
384 | 10 | You should already be familiar with basic Bazaar usage and workflow. Ubuntu | 10 | You should already be familiar with basic Bazaar usage and workflow. For an |
385 | 11 | Intrepid_ or later is required for these instructions to work. | 11 | introduction to Bazaar see the `Bazaar Five Minute Tutorial |
386 | 12 | <http://doc.bazaar.canonical.com/bzr.dev/en/mini-tutorial/index.html>`_ and the | ||
387 | 13 | `Bazaar Users Guide | ||
388 | 14 | <http://doc.bazaar.canonical.com/bzr.dev/en/user-guide/index.html>`_. | ||
389 | 12 | 15 | ||
390 | 13 | 16 | ||
391 | 14 | Source package URLs | 17 | Source package URLs |
392 | 15 | =================== | 18 | =================== |
393 | 16 | 19 | ||
404 | 17 | Bazaar provides some very nice shortcuts for accessing the source branches of | 20 | Bazaar provides some very nice shortcuts for accessing Launchpad's source |
405 | 18 | packages in both Ubuntu and Debian (on Launchpad). These shortcuts are | 21 | branches of packages in both Ubuntu and Debian. |
396 | 19 | available in Bazaar version 2.3 or newer. You can still access source | ||
397 | 20 | branches in older versions of Bazaar, using a slightly more verbose syntax. | ||
398 | 21 | |||
399 | 22 | The examples in this guide always use the ``ubuntu:`` prefix. | ||
400 | 23 | |||
401 | 24 | |||
402 | 25 | Source branch shortcuts | ||
403 | 26 | ----------------------- | ||
406 | 27 | 22 | ||
407 | 28 | To refer to source branches use:: | 23 | To refer to source branches use:: |
408 | 29 | 24 | ||
409 | 30 | ubuntu:package | 25 | ubuntu:package |
410 | 31 | 26 | ||
411 | 32 | where *package* refers to the package name you're interested in. This URL | 27 | where *package* refers to the package name you're interested in. This URL |
416 | 33 | refers to the package in the current development version of Ubuntu. As of | 28 | refers to the package in the current development version of Ubuntu. To |
417 | 34 | this writing (2011-02-04) that version is Natty_ which will be released as | 29 | refer to the branch of Tomboy in the development version, you would use:: |
414 | 35 | Ubuntu 11.04. Thus, to refer to the branch of Tomboy in Natty, you would | ||
415 | 36 | use:: | ||
418 | 37 | 30 | ||
419 | 38 | ubuntu:tomboy | 31 | ubuntu:tomboy |
420 | 39 | 32 | ||
422 | 40 | To refer to the version of a source package in an older release of ubuntu, | 33 | To refer to the version of a source package in an older release of Ubuntu, |
423 | 41 | just prefix the package name with the release's code name. E.g. to refer to | 34 | just prefix the package name with the release's code name. E.g. to refer to |
424 | 42 | Tomboy's source package in Maverick_ use:: | 35 | Tomboy's source package in Maverick_ use:: |
425 | 43 | 36 | ||
426 | @@ -58,28 +51,8 @@ | |||
427 | 58 | debianlp:lenny/tomboy | 51 | debianlp:lenny/tomboy |
428 | 59 | 52 | ||
429 | 60 | 53 | ||
430 | 61 | Explicit source branches | ||
431 | 62 | ------------------------ | ||
432 | 63 | |||
433 | 64 | If you're using an older version of Bazaar, the ``ubuntu:`` and ``debianlp:`` | ||
434 | 65 | prefixes won't be available to you. Instead use the ``lp:`` prefix to access | ||
435 | 66 | the source branch. For example, Tomboy in the latest Ubuntu development | ||
436 | 67 | release is available at:: | ||
437 | 68 | |||
438 | 69 | lp:ubuntu/tomboy | ||
439 | 70 | |||
440 | 71 | while the Maverick version is available at:: | ||
441 | 72 | |||
442 | 73 | lp:ubuntu/maverick/tomboy | ||
443 | 74 | |||
444 | 75 | and the Debian Lenny version is available at:: | ||
445 | 76 | |||
446 | 77 | lp:debian/lenny/tomboy | ||
447 | 78 | |||
448 | 79 | |||
449 | 80 | .. _`Bazaar`: http://bazaar.canonical.com/en/ | 54 | .. _`Bazaar`: http://bazaar.canonical.com/en/ |
450 | 81 | .. _`Intrepid`: https://wiki.ubuntu.com/IntrepidIbex | 55 | .. _`Intrepid`: https://wiki.ubuntu.com/IntrepidIbex |
451 | 82 | .. _Natty: https://wiki.ubuntu.com/NattyNarwhal | ||
452 | 83 | .. _Maverick: https://wiki.ubuntu.com/MaverickMeerkat | 56 | .. _Maverick: https://wiki.ubuntu.com/MaverickMeerkat |
453 | 84 | .. _Lenny: http://debian.org/releases/stable/ | 57 | .. _Lenny: http://debian.org/releases/stable/ |
454 | 85 | 58 | ||
455 | @@ -123,7 +96,7 @@ | |||
456 | 123 | ensure that the import is up-to-date. To find the tag of the last revision | 96 | ensure that the import is up-to-date. To find the tag of the last revision |
457 | 124 | committed by the package importer, do:: | 97 | committed by the package importer, do:: |
458 | 125 | 98 | ||
460 | 126 | $ bzr log -l 1 ubuntu:tomboy | grep ^tags: | 99 | $ bzr log ubuntu:tomboy | grep ^tags | head -n 1 |
461 | 127 | tags: 1.5.2-1ubuntu4 | 100 | tags: 1.5.2-1ubuntu4 |
462 | 128 | 101 | ||
463 | 129 | By comparing the version number returned by ``rmadison`` and the tag added by | 102 | By comparing the version number returned by ``rmadison`` and the tag added by |
464 | @@ -131,20 +104,20 @@ | |||
465 | 131 | is up-to-date. | 104 | is up-to-date. |
466 | 132 | 105 | ||
467 | 133 | Here's an example of a package that is out-of-date. Let's say you want to fix | 106 | Here's an example of a package that is out-of-date. Let's say you want to fix |
469 | 134 | a problem in the ``initscripts`` binary package on Natty_. First find out the | 107 | a problem in the ``initscripts`` binary package. First find out the |
470 | 135 | latest binary package versions that are available:: | 108 | latest binary package versions that are available:: |
471 | 136 | 109 | ||
474 | 137 | $ rmadison initscripts | grep natty | 110 | $ rmadison initscripts | tail -n 1 |
475 | 138 | initscripts | 2.87dsf-4ubuntu19 | natty | amd64, i386 | 111 | initscripts | 2.87dsf-4ubuntu25 | oneiric | amd64, i386 |
476 | 139 | 112 | ||
477 | 140 | Then determine the source package corresponding to this binary package:: | 113 | Then determine the source package corresponding to this binary package:: |
478 | 141 | 114 | ||
481 | 142 | $ apt-cache show initscripts | grep ^Source: | 115 | $ apt-cache showsrc initscripts | grep ^Package: |
482 | 143 | Source: sysvinit | 116 | Package: sysvinit |
483 | 144 | 117 | ||
484 | 145 | Find the latest tag added by the package importer:: | 118 | Find the latest tag added by the package importer:: |
485 | 146 | 119 | ||
487 | 147 | $ bzr log -l 1 ubuntu:sysvinit | grep ^tags: | 120 | $ bzr log ubuntu:sysvinit | grep ^tags | head -n 1 |
488 | 148 | tags: 2.86.ds1-61ubuntu13 | 121 | tags: 2.86.ds1-61ubuntu13 |
489 | 149 | 122 | ||
490 | 150 | Here we can see that ``2.86.ds1-61ubuntu13`` is older than | 123 | Here we can see that ``2.86.ds1-61ubuntu13`` is older than |
491 | @@ -155,6 +128,9 @@ | |||
492 | 155 | When you find such out-of-date packages, be sure to `file a bug on the UDD | 128 | When you find such out-of-date packages, be sure to `file a bug on the UDD |
493 | 156 | project`_ to get the issue resolved. | 129 | project`_ to get the issue resolved. |
494 | 157 | 130 | ||
495 | 131 | A feature in progress is for a warning to be automatically printed when | ||
496 | 132 | branching an out of date import, this will make the above obsolete. | ||
497 | 133 | |||
498 | 158 | .. _branching: | 134 | .. _branching: |
499 | 159 | 135 | ||
500 | 160 | Creating a shared repository | 136 | Creating a shared repository |
501 | @@ -173,20 +149,21 @@ | |||
502 | 173 | You will see that a `tomboy` directory is created in your current working | 149 | You will see that a `tomboy` directory is created in your current working |
503 | 174 | area. Change to this new directory for the rest of your work:: | 150 | area. Change to this new directory for the rest of your work:: |
504 | 175 | 151 | ||
506 | 176 | $ cd foobar | 152 | $ cd tomboy |
507 | 177 | 153 | ||
508 | 178 | 154 | ||
509 | 179 | Getting the trunk branch | 155 | Getting the trunk branch |
510 | 180 | ------------------------ | 156 | ------------------------ |
511 | 181 | 157 | ||
512 | 182 | We use the `bzr branch` command to create a local branch of the package. | 158 | We use the `bzr branch` command to create a local branch of the package. |
520 | 183 | We'll name the target directory `natty` just to keep things easy to remember:: | 159 | We'll name the target directory `tomboy.dev` just to keep things easy to |
521 | 184 | 160 | remember:: | |
522 | 185 | $ bzr branch ubuntu:tomboy natty | 161 | |
523 | 186 | 162 | $ bzr branch ubuntu:tomboy tomboy.dev | |
524 | 187 | The `natty` directory represents the version of Tomboy in Natty, and you can | 163 | |
525 | 188 | always ``cd`` into this directory and do a `bzr pull` to get any future | 164 | The tomboy.dev directory represents the version of Tomboy in the development |
526 | 189 | updates. | 165 | version of Ubuntu, and you can always ``cd`` into this directory and do a `bzr |
527 | 166 | pull` to get any future updates. | ||
528 | 190 | 167 | ||
529 | 191 | 168 | ||
530 | 192 | Getting a branch for a particular release | 169 | Getting a branch for a particular release |
531 | @@ -211,7 +188,7 @@ | |||
532 | 211 | `tomboy` directory created above):: | 188 | `tomboy` directory created above):: |
533 | 212 | 189 | ||
534 | 213 | $ bzr init-repo newpackage | 190 | $ bzr init-repo newpackage |
536 | 214 | $ cd new-package | 191 | $ cd newpackage |
537 | 215 | $ bzr init debian | 192 | $ bzr init debian |
538 | 216 | $ cd debian | 193 | $ cd debian |
539 | 217 | $ bzr import-dsc http://ftp.de.debian.org/debian/pool/main/n/newpackage/newpackage_1.0-1.dsc | 194 | $ bzr import-dsc http://ftp.de.debian.org/debian/pool/main/n/newpackage/newpackage_1.0-1.dsc |
540 | 218 | 195 | ||
541 | === modified file 'udd-latest.rst' | |||
542 | --- udd-latest.rst 2011-05-20 15:26:22 +0000 | |||
543 | +++ udd-latest.rst 2011-07-15 09:23:07 +0000 | |||
544 | @@ -12,7 +12,7 @@ | |||
545 | 12 | Updating your copy of a branch that corresponds to the package in a particular | 12 | Updating your copy of a branch that corresponds to the package in a particular |
546 | 13 | release is very simple, simply use `bzr pull` from the appropriate directory:: | 13 | release is very simple, simply use `bzr pull` from the appropriate directory:: |
547 | 14 | 14 | ||
549 | 15 | $ cd tomboy/natty | 15 | $ cd tomboy/tomboy.dev |
550 | 16 | $ bzr pull | 16 | $ bzr pull |
551 | 17 | 17 | ||
552 | 18 | This works wherever you have a checkout of a branch, so it will work for | 18 | This works wherever you have a checkout of a branch, so it will work for |
553 | @@ -39,7 +39,7 @@ | |||
554 | 39 | have committed your current work first:: | 39 | have committed your current work first:: |
555 | 40 | 40 | ||
556 | 41 | $ cd tomboy/bug-12345 | 41 | $ cd tomboy/bug-12345 |
558 | 42 | $ bzr merge-package ../natty | 42 | $ bzr merge-package ../tomboy.dev |
559 | 43 | 43 | ||
560 | 44 | Any conflicts will be reported, and you can fix them up. To review the | 44 | Any conflicts will be reported, and you can fix them up. To review the |
561 | 45 | changes that you just merged use `bzr diff`. To undo the merge use `bzr | 45 | changes that you just merged use `bzr diff`. To undo the merge use `bzr |
562 | 46 | 46 | ||
563 | === modified file 'udd-merging.rst' | |||
564 | --- udd-merging.rst 2011-05-27 18:02:49 +0000 | |||
565 | +++ udd-merging.rst 2011-07-15 09:23:07 +0000 | |||
566 | @@ -1,6 +1,6 @@ | |||
570 | 1 | ======= | 1 | =========================================== |
571 | 2 | Merging | 2 | Merging - Updating from Debian and Upstream |
572 | 3 | ======= | 3 | =========================================== |
573 | 4 | 4 | ||
574 | 5 | Merging is one of the strengths of Bazaar, and something we do often in Ubuntu | 5 | Merging is one of the strengths of Bazaar, and something we do often in Ubuntu |
575 | 6 | development. Updates can be merged from Debian, from a new upstream release, | 6 | development. Updates can be merged from Debian, from a new upstream release, |
576 | @@ -47,7 +47,7 @@ | |||
577 | 47 | need, you will add a new changelog entry, and commit:: | 47 | need, you will add a new changelog entry, and commit:: |
578 | 48 | 48 | ||
579 | 49 | $ dch -i | 49 | $ dch -i |
581 | 50 | $ debcommit | 50 | $ bzr commit |
582 | 51 | 51 | ||
583 | 52 | as described earlier. | 52 | as described earlier. |
584 | 53 | 53 | ||
585 | @@ -68,8 +68,8 @@ | |||
586 | 68 | If you are going to build the source package from this merged branch, you | 68 | If you are going to build the source package from this merged branch, you |
587 | 69 | would use the ``-S`` option to the ``bd`` command. One other thing you'll | 69 | would use the ``-S`` option to the ``bd`` command. One other thing you'll |
588 | 70 | want to consider is also using the ``--package-merge`` option. This will add | 70 | want to consider is also using the ``--package-merge`` option. This will add |
591 | 71 | the appropriate ``-v`` and ``-sa`` options to the source package so that all | 71 | the appropriate ``-v`` and ``-sa`` options to the source package so that all the |
592 | 72 | the changelog entries since the last Ubuntu change will be included in your | 72 | changelog entries since the last Ubuntu change will be included in your |
593 | 73 | ``_source.changes`` file. For example:: | 73 | ``_source.changes`` file. For example:: |
594 | 74 | 74 | ||
595 | 75 | $ bzr bd -S --package-merge | 75 | $ bzr bd -S --package-merge |
596 | @@ -101,9 +101,8 @@ | |||
597 | 101 | 101 | ||
598 | 102 | The last parameter is the location of the tarball that you are upgrading to; | 102 | The last parameter is the location of the tarball that you are upgrading to; |
599 | 103 | this can either be a local filesystem path, or a http, ftp, sftp, etc. URI as | 103 | this can either be a local filesystem path, or a http, ftp, sftp, etc. URI as |
603 | 104 | shown. The command will automatically download the tarball for you. If you | 104 | shown. The command will automatically download the tarball for you. The |
604 | 105 | point to a `.tar.bz2` or similar tarball then it will recompress it as needed, | 105 | tarball will be renamed appropriately and, if required, converted to .gz. |
602 | 106 | or convert it if you pass it a `.zip` or similar. | ||
605 | 107 | 106 | ||
606 | 108 | The `merge-upstream` command will either tell you that it completed | 107 | The `merge-upstream` command will either tell you that it completed |
607 | 109 | successfully, or that there were conflicts. Either way you will be able to | 108 | successfully, or that there were conflicts. Either way you will be able to |
608 | @@ -113,7 +112,7 @@ | |||
609 | 113 | not previously used the UDD layout, `bzr merge-upstream` will fail with an | 112 | not previously used the UDD layout, `bzr merge-upstream` will fail with an |
610 | 114 | error that the tag for the previous upstream version is not available; the | 113 | error that the tag for the previous upstream version is not available; the |
611 | 115 | merge can't be completed without knowing what base version to merge against. | 114 | merge can't be completed without knowing what base version to merge against. |
613 | 116 | To work around this, create a tag in your existing existing repo for the last | 115 | To work around this, create a tag in your existing repository for the last |
614 | 117 | upstream version present there; e.g., if the last Ubuntu release was | 116 | upstream version present there; e.g., if the last Ubuntu release was |
615 | 118 | *1.1-0ubuntu3*, create the tag *upstream-1.1* pointing to the bzr revision you | 117 | *1.1-0ubuntu3*, create the tag *upstream-1.1* pointing to the bzr revision you |
616 | 119 | want to use as the tip of the upstream branch. | 118 | want to use as the tip of the upstream branch. |
617 | 120 | 119 | ||
618 | === modified file 'udd-patchsys.rst' | |||
619 | --- udd-patchsys.rst 2011-02-05 01:02:31 +0000 | |||
620 | +++ udd-patchsys.rst 2011-07-15 09:23:07 +0000 | |||
621 | @@ -1,9 +1,14 @@ | |||
625 | 1 | =========================== | 1 | ============================================================== |
626 | 2 | Working with a patch system | 2 | Ubuntu Distributed Development - Working with Patches via Loom |
627 | 3 | =========================== | 3 | ============================================================== |
628 | 4 | |||
629 | 5 | Here are some guidelines for working with Quilt_ patches using the Bazaar Loom | ||
630 | 6 | plugin. A loom allows the development of multiple patches at once, while still | ||
631 | 7 | giving each patch a branch of its own. This is a work in progress for the UDD | ||
632 | 8 | developers who will be working on improving this workflow. | ||
633 | 4 | 9 | ||
634 | 5 | Many existing packages that have changes from upstream express those changes | 10 | Many existing packages that have changes from upstream express those changes |
636 | 6 | using a `patch system`_, of which there are several to choose from. Usually, | 11 | using a patch system, of which there are several to choose from. Usually, |
637 | 7 | when you make an additional change to a package, you'll want to add a patch | 12 | when you make an additional change to a package, you'll want to add a patch |
638 | 8 | file to the patch system being used, rather than editing the source code in | 13 | file to the patch system being used, rather than editing the source code in |
639 | 9 | place. Note however that it is considered bad practice to add a patch system | 14 | place. Note however that it is considered bad practice to add a patch system |
640 | @@ -19,11 +24,6 @@ | |||
641 | 19 | problems pushing and pulling your threads to Launchpad.* Do ``bzr plugins`` to | 24 | problems pushing and pulling your threads to Launchpad.* Do ``bzr plugins`` to |
642 | 20 | find the version you're using. | 25 | find the version you're using. |
643 | 21 | 26 | ||
644 | 22 | Here are some guidelines that I've found helpful. Clearly the existing tools | ||
645 | 23 | can be improved, but for now this seems to work well enough. This assumes | ||
646 | 24 | you're using looms to develop your patch, and that the package itself uses the | ||
647 | 25 | quilt_ patch system. | ||
648 | 26 | |||
649 | 27 | One important thing to know: all source branches reflect the tree after a | 27 | One important thing to know: all source branches reflect the tree after a |
650 | 28 | ``quilt push -a``. In other words, when you branch a source branch, you get | 28 | ``quilt push -a``. In other words, when you branch a source branch, you get |
651 | 29 | the tree with all patches applied, ready for you to jump right into hacking. | 29 | the tree with all patches applied, ready for you to jump right into hacking. |
652 | @@ -182,7 +182,6 @@ | |||
653 | 182 | There's now `a bug` that tracks this. | 182 | There's now `a bug` that tracks this. |
654 | 183 | 183 | ||
655 | 184 | 184 | ||
656 | 185 | .. _`patch system`: https://wiki.ubuntu.com/DistributedDevelopment/Documentation/PatchSystem/PackagingGuide/PatchSystems | ||
657 | 186 | .. _`Bazaar looms`: https://launchpad.net/bzr-loom | 185 | .. _`Bazaar looms`: https://launchpad.net/bzr-loom |
658 | 187 | .. _quilt: http://www.wzdftpd.net/blog/index.php?2008/02/05/3-quilt-a-patch-management-system-how-to-survive-with-many-patches | 186 | .. _quilt: http://www.wzdftpd.net/blog/index.php?2008/02/05/3-quilt-a-patch-management-system-how-to-survive-with-many-patches |
659 | 188 | .. _`currently includes any existing .pc directory`: https://bugs.launchpad.net/udd/+bug/672740 | 187 | .. _`currently includes any existing .pc directory`: https://bugs.launchpad.net/udd/+bug/672740 |
660 | 189 | 188 | ||
661 | === modified file 'udd-sponsorship.rst' | |||
662 | --- udd-sponsorship.rst 2011-02-07 15:34:46 +0000 | |||
663 | +++ udd-sponsorship.rst 2011-07-15 09:23:07 +0000 | |||
664 | @@ -1,6 +1,6 @@ | |||
668 | 1 | ============================== | 1 | =============================================================== |
669 | 2 | Seeking Review and Sponsorship | 2 | Ubuntu Distributed Development - Seeking Review and Sponsorship |
670 | 3 | ============================== | 3 | =============================================================== |
671 | 4 | 4 | ||
672 | 5 | One of the biggest advantages to using the UDD workflow is to improve quality | 5 | One of the biggest advantages to using the UDD workflow is to improve quality |
673 | 6 | by seeking review of changes by your peers. This is true whether or not you | 6 | by seeking review of changes by your peers. This is true whether or not you |
674 | @@ -18,8 +18,8 @@ | |||
675 | 18 | Pushing to Launchpad | 18 | Pushing to Launchpad |
676 | 19 | ==================== | 19 | ==================== |
677 | 20 | 20 | ||
680 | 21 | We previously showed you how to :ref:`link your branch to the bug | 21 | We previously showed you how to :ref:`associate your branch to the bug |
681 | 22 | <link-via-changelog>` using ``dch`` and ``debcommit``. However, the branch | 22 | <link-via-changelog>` using ``dch`` and ``bzr commit``. However, the branch |
682 | 23 | and bug don't actually get linked until you push the branch to Launchpad. | 23 | and bug don't actually get linked until you push the branch to Launchpad. |
683 | 24 | 24 | ||
684 | 25 | It is not critical to have a link to a bug for every change you make, | 25 | It is not critical to have a link to a bug for every change you make, |
685 | @@ -27,14 +27,14 @@ | |||
686 | 27 | 27 | ||
687 | 28 | The general form of the URL you should push your branch to is:: | 28 | The general form of the URL you should push your branch to is:: |
688 | 29 | 29 | ||
690 | 30 | lp:~<user-id>/ubuntu/<distroseries>/<package>/bug-12345 | 30 | lp:~<user-id>/ubuntu/<distroseries>/<package>/<branch-name> |
691 | 31 | 31 | ||
692 | 32 | For example, to push your fix for bug 12345 in the Tomboy package for Natty, | 32 | For example, to push your fix for bug 12345 in the Tomboy package for Natty, |
693 | 33 | you'd use:: | 33 | you'd use:: |
694 | 34 | 34 | ||
695 | 35 | $ bzr push lp:~subgenius/ubuntu/natty/tomboy/bug-12345 | 35 | $ bzr push lp:~subgenius/ubuntu/natty/tomboy/bug-12345 |
696 | 36 | 36 | ||
698 | 37 | The last component of the path is actually arbitrary; it's up to you to pick | 37 | The last component of the path is arbitrary; it's up to you to pick |
699 | 38 | something meaningful. | 38 | something meaningful. |
700 | 39 | 39 | ||
701 | 40 | However, this usually isn't enough to get Ubuntu developers to review and | 40 | However, this usually isn't enough to get Ubuntu developers to review and |
702 | @@ -66,7 +66,7 @@ | |||
703 | 66 | debdiff, you can generate one like this (from inside your `bug-12345` | 66 | debdiff, you can generate one like this (from inside your `bug-12345` |
704 | 67 | branch):: | 67 | branch):: |
705 | 68 | 68 | ||
707 | 69 | $ bzr diff -rbranch:../natty | 69 | $ bzr diff -rbranch:../tomboy.dev |
708 | 70 | 70 | ||
709 | 71 | Another way is to is to open the merge proposal and download the diff. | 71 | Another way is to is to open the merge proposal and download the diff. |
710 | 72 | 72 | ||
711 | @@ -94,6 +94,6 @@ | |||
712 | 94 | and asking for re-review, or you can reply on the merge proposal page in | 94 | and asking for re-review, or you can reply on the merge proposal page in |
713 | 95 | Launchpad. | 95 | Launchpad. |
714 | 96 | 96 | ||
716 | 97 | Note that if you are sponsored via debdiff attached to a bug report you need | 97 | Note that if you are sponsored via a debdiff attached to a bug report you need |
717 | 98 | to manually update by generating a new diff and attaching that to the bug | 98 | to manually update by generating a new diff and attaching that to the bug |
718 | 99 | report. | 99 | report. |
719 | 100 | 100 | ||
720 | === modified file 'udd-uploading.rst' | |||
721 | --- udd-uploading.rst 2011-05-25 14:08:46 +0000 | |||
722 | +++ udd-uploading.rst 2011-07-15 09:23:07 +0000 | |||
723 | @@ -4,7 +4,7 @@ | |||
724 | 4 | 4 | ||
725 | 5 | Once your merge proposal is reviewed and approved, you will want to upload | 5 | Once your merge proposal is reviewed and approved, you will want to upload |
726 | 6 | your package, either to the archive (if you have permission) or to your | 6 | your package, either to the archive (if you have permission) or to your |
728 | 7 | *`Personal Package Archive`_* (PPA). You might also want to do an upload if | 7 | `Personal Package Archive`_ (PPA). You might also want to do an upload if |
729 | 8 | you are sponsoring someone else's changes. | 8 | you are sponsoring someone else's changes. |
730 | 9 | 9 | ||
731 | 10 | 10 | ||
732 | @@ -16,17 +16,18 @@ | |||
733 | 16 | then upload it. | 16 | then upload it. |
734 | 17 | 17 | ||
735 | 18 | First, you need to check that you have the latest version of the package in | 18 | First, you need to check that you have the latest version of the package in |
737 | 19 | your checkout of the development package:: | 19 | your checkout of the development package trunk:: |
738 | 20 | 20 | ||
740 | 21 | $ cd tomboy/natty | 21 | $ cd tomboy/tomboy.dev |
741 | 22 | $ bzr pull | 22 | $ bzr pull |
742 | 23 | 23 | ||
743 | 24 | This pulls in any changes that may have been committed while you were working | 24 | This pulls in any changes that may have been committed while you were working |
744 | 25 | on your fix. From here, you have several options. If the changes on the | 25 | on your fix. From here, you have several options. If the changes on the |
749 | 26 | trunk are large, and it will take a while to merge them and test the package, | 26 | trunk are large and you feel should be tested along with your change you can |
750 | 27 | then you can merge them back into your working branch to do this. If not, | 27 | merge them into your bug fix branch and test there. If not, |
751 | 28 | then you can carry on merging your working branch to the main one. You'll | 28 | then you can carry on merging your bug fix branch into the development trunk |
752 | 29 | want to use the Bazaar ``merge-package`` command rather than just ``merge``:: | 29 | branch. You'll want to use the Bazaar ``merge-package`` command rather than just |
753 | 30 | ``merge``:: | ||
754 | 30 | 31 | ||
755 | 31 | $ bzr merge-package ../bug-12345 | 32 | $ bzr merge-package ../bug-12345 |
756 | 32 | 33 | ||
757 | @@ -41,26 +42,18 @@ | |||
758 | 41 | before you upload the source package. | 42 | before you upload the source package. |
759 | 42 | 43 | ||
760 | 43 | The next step is to build and test the modified source package as you normally | 44 | The next step is to build and test the modified source package as you normally |
773 | 44 | would. Once you are happy with the upload then you should `dput` the | 45 | would:: |
774 | 45 | source package. For example, if you want to upload your changes to your PPA, | 46 | |
775 | 46 | then you'd do:: | 47 | $ bzr bd -S |
764 | 47 | |||
765 | 48 | $ dput ppa:imasponsor/myppa tomboy_1.5.2-1ubuntu5_source.changes | ||
766 | 49 | |||
767 | 50 | or, if you have permission to upload to the primary archive:: | ||
768 | 51 | |||
769 | 52 | $ dput tomboy_1.5.2-1ubuntu5_source.changes | ||
770 | 53 | |||
771 | 54 | You might want to do one more `debcommit` to make sure all your changes are | ||
772 | 55 | committed in your working tree. | ||
776 | 56 | 48 | ||
777 | 57 | The last step is to mark the change as being the same as the source package | 49 | The last step is to mark the change as being the same as the source package |
784 | 58 | that was uploaded, so run:: | 50 | that was uploaded, bzr-builddeb will override the `tag` command to |
785 | 59 | 51 | automatically tag with the version number in debian/changelog so run:: | |
786 | 60 | $ bzr mark-uploaded | 52 | |
787 | 61 | 53 | $ bzr tag | |
788 | 62 | This also tells the package importer that what is in the Bazaar branch is the | 54 | |
789 | 63 | same as in the archive. | 55 | This tag will tell the package importer that what is in the Bazaar branch |
790 | 56 | is the same as in the archive. | ||
791 | 64 | 57 | ||
792 | 65 | Now you can push the changes back to Launchpad:: | 58 | Now you can push the changes back to Launchpad:: |
793 | 66 | 59 | ||
794 | @@ -68,6 +61,16 @@ | |||
795 | 68 | 61 | ||
796 | 69 | (Change the destination if you are uploading an SRU or similar.) | 62 | (Change the destination if you are uploading an SRU or similar.) |
797 | 70 | 63 | ||
798 | 64 | Once you are happy with the upload then you should use `dput` to upload the | ||
799 | 65 | built source package to Launchpad. For example, if you want to upload your | ||
800 | 66 | changes to your PPA, then you'd do:: | ||
801 | 67 | |||
802 | 68 | $ dput ppa:imasponsor/myppa tomboy_1.5.2-1ubuntu5_source.changes | ||
803 | 69 | |||
804 | 70 | or, if you have permission to upload to the primary archive:: | ||
805 | 71 | |||
806 | 72 | $ dput ubuntu tomboy_1.5.2-1ubuntu5_source.changes | ||
807 | 73 | |||
808 | 71 | You are now free to delete your feature branch, as it is merged, and can | 74 | You are now free to delete your feature branch, as it is merged, and can |
809 | 72 | be re-downloaded from Launchpad if needed. | 75 | be re-downloaded from Launchpad if needed. |
810 | 73 | 76 | ||
811 | 74 | 77 | ||
812 | === modified file 'udd-working.rst' | |||
813 | --- udd-working.rst 2011-02-05 01:02:31 +0000 | |||
814 | +++ udd-working.rst 2011-07-15 09:23:07 +0000 | |||
815 | @@ -1,6 +1,6 @@ | |||
819 | 1 | ==================== | 1 | ===================================================== |
820 | 2 | Working on a Package | 2 | Ubuntu Distributed Development - Working on a Package |
821 | 3 | ==================== | 3 | ===================================================== |
822 | 4 | 4 | ||
823 | 5 | Once you have the source package branch in a shared repository, you'll want to | 5 | Once you have the source package branch in a shared repository, you'll want to |
824 | 6 | create additional branches for the fixes or other work you plan to do. You'll | 6 | create additional branches for the fixes or other work you plan to do. You'll |
825 | @@ -15,7 +15,7 @@ | |||
826 | 15 | The first thing to do is to make sure your source package branch is | 15 | The first thing to do is to make sure your source package branch is |
827 | 16 | up-to-date. It will be if you just checked it out, otherwise do this:: | 16 | up-to-date. It will be if you just checked it out, otherwise do this:: |
828 | 17 | 17 | ||
830 | 18 | $ cd natty | 18 | $ cd tomboy.dev |
831 | 19 | $ bzr pull | 19 | $ bzr pull |
832 | 20 | 20 | ||
833 | 21 | Any updates to the package that have uploaded since your checkout will now be | 21 | Any updates to the package that have uploaded since your checkout will now be |
834 | @@ -25,7 +25,7 @@ | |||
835 | 25 | repository you previously created for Tomboy, you can create your bug fix | 25 | repository you previously created for Tomboy, you can create your bug fix |
836 | 26 | branch like this:: | 26 | branch like this:: |
837 | 27 | 27 | ||
839 | 28 | $ bzr branch natty bug-12345 | 28 | $ bzr branch tomboy.dev bug-12345 |
840 | 29 | $ cd bug-12345 | 29 | $ cd bug-12345 |
841 | 30 | 30 | ||
842 | 31 | Now you can do all my work in the `bug-12345` directory. You make changes | 31 | Now you can do all my work in the `bug-12345` directory. You make changes |
843 | @@ -41,9 +41,8 @@ | |||
844 | 41 | 41 | ||
845 | 42 | .. _link-via-changelog: | 42 | .. _link-via-changelog: |
846 | 43 | 43 | ||
850 | 44 | Here's where things diverge a little from typical Bazaar usage. When you | 44 | When you added your `debian/changelog` entry, you should have included a bug fix |
851 | 45 | added your `debian/changelog` entry, you should have included a bug fix tag | 45 | tag that indicated which Launchpad bug issue you're fixing. The format of this |
849 | 46 | that indicated which Launchpad bug issue you're fixing. The format of this | ||
852 | 47 | textual tag is pretty strict: ``LP: #12345``. The space between the ``:`` and | 46 | textual tag is pretty strict: ``LP: #12345``. The space between the ``:`` and |
853 | 48 | the ``#`` is required and of course the number will be replaced by the actual | 47 | the ``#`` is required and of course the number will be replaced by the actual |
854 | 49 | bug number you're fixing. Your `debian/changelog` entry might look something | 48 | bug number you're fixing. Your `debian/changelog` entry might look something |
855 | @@ -55,18 +54,15 @@ | |||
856 | 55 | 54 | ||
857 | 56 | -- Bob Dobbs <subgenius@example.com> Mon, 10 Jan 2011 16:10:01 -0500 | 55 | -- Bob Dobbs <subgenius@example.com> Mon, 10 Jan 2011 16:10:01 -0500 |
858 | 57 | 56 | ||
871 | 58 | Normally, when you want to commit changes to your branch, you just use ``bzr | 57 | Commit with the normal:: |
872 | 59 | commit``, but in the case where you've made a change to ``debian/changelog``, | 58 | |
873 | 60 | you'll want to use the ``debcommit`` command instead:: | 59 | bzr commit |
874 | 61 | 60 | ||
875 | 62 | $ debcommit | 61 | A hook in bzr-builddeb will use the debian/changelog text as the commit |
876 | 63 | 62 | message and set the tag to mark bug #12345 as fixed. | |
877 | 64 | The reason to use ``debcommit`` instead is that it automatically includes your | 63 | |
878 | 65 | ``debian/changelog`` entry in the commit message, and it also adds the | 64 | This only works with bzr-builddeb 2.7.5 and bzr 2.4, for older versions use |
879 | 66 | necessary metadata to link your branch to the bug report when you push your | 65 | `debcommit`. |
868 | 67 | branch to Launchpad. You can do that manually with ``bzr commit`` (and | ||
869 | 68 | eventually, ``bzr commit`` may get smart enough to do it for you), but for now | ||
870 | 69 | ``debcommit`` is the most convenient way to do it. | ||
880 | 70 | 66 | ||
881 | 71 | 67 | ||
882 | 72 | Building the package | 68 | Building the package |
883 | @@ -95,16 +91,5 @@ | |||
884 | 95 | Note that while `bzr bd` has a `--native` switch, it does not have a | 91 | Note that while `bzr bd` has a `--native` switch, it does not have a |
885 | 96 | `--no-native` switch. | 92 | `--no-native` switch. |
886 | 97 | 93 | ||
887 | 98 | You might also see an error that looks something like this: | ||
888 | 99 | |||
889 | 100 | dpkg-source: error: Version number suggests Ubuntu changes, but | ||
890 | 101 | Maintainer: does not have Ubuntu address | ||
891 | 102 | |||
892 | 103 | In a sense, this is a safeguard to ensure that ``update-maintainer`` is run | ||
893 | 104 | when necessary. However in this case, you can just temporarily set the | ||
894 | 105 | ``$DEBEMAIL`` environment variable to a non-@ubuntu.com address:: | ||
895 | 106 | |||
896 | 107 | $ DEBEMAIL='me@example.com' bzr bd -S | ||
897 | 108 | |||
898 | 109 | Once you've got the source package, you can build it as normal with | 94 | Once you've got the source package, you can build it as normal with |
900 | 110 | ``pbuilder`` or ``sbuild``. | 95 | ``pbuilder-dist`` (or ``pbuilder`` or ``sbuild``). |
Thanks a lot for your fixes and your attention to detail.
I have a few quick questions though:
- Why do you remove the section about libvigraimpex?
- bzr commit instead of debcommit? (debcommit does much more than just 'bzr commit')
- Do you think it makes sense to have two copies of the knowledge base article index?
- the section following "Then determine the source package corresponding to this binary package::" seems to have been correct before.
- Why do you leave the link to intrepid and remove the link to natty? (line 419)
- Is "bzr tag" necessary nowadays?
- Why do you remove the "update-maintainer" bits?