~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

Viewing changes to doc/developers/ppa.txt

  • Committer: Danny van Heumen
  • Date: 2010-03-09 16:38:10 UTC
  • mto: (4634.139.5 2.0)
  • mto: This revision was merged to the branch mainline in revision 5160.
  • Revision ID: danny@dannyvanheumen.nl-20100309163810-ujn8hcx08f75nlf1
Refined test to make use of locking hooks and also validate if lock is truly a checkout-lock.

Show diffs side-by-side

added added

removed removed

Lines of Context:
13
13
 
14
14
  __ https://help.launchpad.net/PPAQuickStart
15
15
 
16
 
As of June 2010, there are three PPAs:
 
16
As of June 2008, there are three PPAs:
17
17
 
18
18
<https://launchpad.net/~bzr/+archive>
19
 
    Final released versions and updates.
20
 
 
21
 
<https://launchpad.net/~bzr/+archive/proposed>
22
 
    Proposed uploads to move into ~bzr, awaiting testing.
 
19
    Final released versions.
23
20
 
24
21
<https://launchpad.net/~bzr-beta-ppa/+archive>
25
 
    Beta releases.
 
22
    Releases and release candidates.    
26
23
 
27
24
<https://launchpad.net/~bzr-nightly-ppa/+archive>
28
25
    Automatic nightly builds from trunk.
29
26
 
30
 
We build a distinct package for each distrorelease.  
 
27
We build packages for every supported Ubuntu release
 
28
<https://wiki.ubuntu.com/Releases>.  Packages need no longer be updated
 
29
when the release passes end-of-life because all users should
 
30
have upgraded by then.  (As of May 2008, Edgy Eft is no longer supported.)
 
31
 
 
32
We build a distinct package for each distrorelease.  As of bzr 1.5, Dapper
 
33
uses ``python-support`` and later distributions use ``python-central``.
31
34
If you upload a release-specific version, you should add a suffix to the
32
35
package version, e.g. ``bzr.1.3-1~bazaar1~dapper1``.
33
36
 
34
 
Dapper uses the ``python-support`` framework and later distributions use
35
 
``python-central``.  This has little effect on everyday packaging but does
36
 
mean that some of the control files are quite different.
37
 
 
38
37
Every package is first uploaded into the beta ppa.  For final release
39
38
versions it is also copied to the main PPA.
40
39
 
41
40
The packaging information is kept in branches of bzr on Launchpad, named
42
 
like
43
 
<https://code.launchpad.net/~bzr/ubuntu/hardy/bzr/bzr-ppa>.
 
41
like 
 
42
<https://code.launchpad.net/~bzr/bzr/packaging-hardy>.
44
43
or
45
 
<lp:~bzr/ubuntu/hardy/bzr/bzr-ppa>.  These branches are intended to be used
 
44
<lp:~bzr/bzr/packaging-hardy>.  These branches are intended to be used
46
45
with the ``bzr-builddeb`` plugin.
47
46
 
48
 
**You should almost always upload to the beta ppa first** and then either 
49
 
upload again or copy the packages into the release ppa.  That reduces the 
50
 
risk of breaking the main archive from which people get bzr updates.
51
 
 
52
 
 
53
 
Supported releases
54
 
------------------
55
 
 
56
 
We build packages for every supported Ubuntu release
57
 
<https://wiki.ubuntu.com/Releases>.  Packages need no longer be updated
58
 
when the release passes end-of-life because all users should
59
 
have upgraded by then.  
60
 
 
61
 
As of August 2010, the following releases are supported:
62
 
 
63
 
* Maverick 
64
 
* Lucid LTS
65
 
* Karmic
66
 
* Jaunty (support ends October 2010)
67
 
* Hardy LTS
68
 
* Dapper LTS (supported but no longer updated for new releases)
69
 
 
70
 
 
71
47
Preconditions
72
48
-------------
73
 
 
74
 
* You must have a Launchpad account and be a member of the teams
 
49
  
 
50
* You must have a Launchpad account and be a member of the teams 
75
51
  that own these PPAs (``~bzr``, ``~bzr-beta-ppa``).
76
52
 
77
53
* You must have a GPG key registered to your Launchpad account.
78
54
 
79
 
On reasonably recent versions of Ubuntu you no longer need special dput
80
 
configuration, because you can just say ::
81
 
 
82
 
  dput ppa:bzr/proposed <source.changes
83
 
  
84
 
 
85
 
However, you may still want to add these lines to ``~/.dput.cf`` prevent 
86
 
inadvertently attempting to upload into Ubuntu or Debian, which will
87
 
give a somewhat unclear error::
 
55
* Configure ``dput`` to upload to our PPA with this section in your
 
56
  ``~/.dput.cf``::
 
57
 
 
58
    [bzr-beta-ppa]
 
59
    fqdn = ppa.launchpad.net
 
60
    method = ftp
 
61
    incoming = ~bzr-beta-ppa/ubuntu
 
62
    login = anonymous
 
63
    allow_unsigned_uploads = 0
 
64
 
 
65
    [bzr-ppa]
 
66
    fqdn = ppa.launchpad.net
 
67
    method = ftp
 
68
    incoming = ~bzr/ubuntu
 
69
    login = anonymous
 
70
    allow_unsigned_uploads = 0
 
71
 
 
72
  You may also want to add these lines to prevent inadvertently attempting
 
73
  to upload into Ubuntu or Debian, which will give a somewhat unclear
 
74
  error::
88
75
 
89
76
    [DEFAULT]
90
77
    default_host_main = notspecified
91
 
 
 
78
  
92
79
* Configure ``bzr-builddeb`` to sign the package, which is required for
93
80
  Launchpad to build it.  Put this in ``~/.bazaar/builddeb.conf`` ::
94
81
 
113
100
Packaging Bazaar
114
101
----------------
115
102
 
116
 
Overview of packaging with builddeb
117
 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
118
 
 
119
 
* First update the oldest supported branch, using ``bzr merge-upstream``.
120
 
 
121
 
* Run ``bzr builddeb -S -- -sa`` to build a source package, then put 
122
 
  that into the ppa.  
123
 
  
124
 
  (``-S`` says to make a source-only upload, which is
125
 
  required for Launchpad's builders.  ``--sa`` says to include the
126
 
  ``.orig.tgz`` even if this doesn't seem to be the first upload for an
127
 
  upstream release: this is often needed when rebuilding something that's
128
 
  previously been uploaded to Debian or Ubuntu or into a different PPA.)
129
 
 
130
 
* Now merge across that change into each supported branch with a 
131
 
  simple ``bzr merge``.
132
 
  
133
 
Locally testing builds
134
 
~~~~~~~~~~~~~~~~~~~~~~
135
 
 
136
 
It may be useful to locally test builds inside pbuilder.  You may want to 
137
 
use the script from <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=255165> 
138
 
to wrap it.
139
 
 
140
 
Update all packages in proposed before copping the main ppa
141
 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
142
 
 
143
 
If one updates bzr, and there are plugins that are not compatible with the
144
 
new version of bzr, this can cause pain for users using the ppa. In order to
145
 
avoid this, we first get all packages up to date in the proposed ppa, and then
146
 
copy them to the main ppa.
147
 
 
148
 
 
149
103
Short form
150
104
~~~~~~~~~~
151
105
 
153
107
release packages is as simple as::
154
108
 
155
109
  cd ~/dev/bzr/releases/packaging
156
 
  export VERSION="1.17~rc1-1~bazaar1"
157
 
  export PACKAGE="bzr"
158
 
  export UBUNTU_RELEASES="dapper hardy intrepid jaunty karmic"
 
110
  ln ~/dev/bzr/releases/bzr-1.6.tar.gz ./bzr_1.6.orig.tar.gz
 
111
  export UBUNTU_RELEASES="dapper feisty gutsy hardy intrepid"
159
112
  ~/dev/bzr/bzr.dev/tools/packaging/update-packaging-branches.sh
160
 
  * Optionaly merge debian unstable. 
161
 
  ~/dev/bzr/bzr.dev/tools/packaging/update-changelogs.sh
162
 
  ~/dev/bzr/bzr.dev/tools/packaging/update-control.sh 1.16 1.17 1.18
163
 
  ~/dev/bzr/bzr.dev/tools/packaging/build-packages.sh
164
 
  dput ppa:bzr/proposed ${PACKAGE}_$VERSION*.changes
165
 
 
166
 
Rinse and repeat for all the plugins by changing VERSION and PACKAGE.
 
113
  ~/dev/bzr/bzr.dev/tools/packaging/update-changelogs.sh 1.6~beta3-1~bazaar1
 
114
  ~/dev/bzr/bzr.dev/tools/packaging/build-packages
 
115
  dput bzr-beta-ppa bzr_1.6~beta3-1~bazaar1*.changes
167
116
 
168
117
Long Form
169
118
~~~~~~~~~
172
121
   release. Such as ``~/dev/bzr/releases/packaging/hardy``. In each of these
173
122
   branches, you will produce the package for the release.
174
123
 
175
 
   The scripts will also create the branches and produce packages for
176
 
   bzrtools and bzr-svn.
177
 
 
178
124
#. Decide on the final version number.  It should be of this form::
179
125
 
180
 
     bzr-1.17~rc1-1~bazaar1~hardy1
 
126
     bzr-1.6~beta3-1~bazaar1~hardy1
181
127
 
182
128
   **Note:** There are three hyphen-separated parts: the *package name*,
183
129
   the *upstream version*, and the *packaging version*.
184
130
 
185
131
   **Caution:** Upstream betas or release candidates must insert a tilde
186
132
   to make them sort before the final release, like this:
187
 
   ``bzr-1.17~rc1-1~bazaar1~hardy1``.
 
133
   ``bzr-1.6~beta3-1~bazaar1~hardy1``.
188
134
 
189
135
   Final releases will use a release string of the form:
190
 
   ``bzr-1.17-1~bazaar1~hardy1``
191
 
 
192
 
   Set this base of this up as a usable environment variable::
193
 
 
194
 
      export VERSION="1.17~rc1-1~bazaar1"
 
136
   ``bzr-1.6-1~bazaar1~hardy1``
195
137
 
196
138
#. Export the distroreleases that you will be packaging for::
197
139
 
198
 
      export UBUNTU_RELEASES="dapper hardy intrepid jaunty karmic"
199
 
 
200
 
#. Export the program you are packaging::
201
 
 
202
 
      export PACKAGE="bzr"
 
140
      export UBUNTU_RELEASES="dapper feisty gutsy hardy intrepid jaunty"
203
141
 
204
142
#. Checkout (or update) the packaging branch for each supported release::
205
143
 
206
 
      bzr co lp:~bzr/ubuntu/hardy/bzr/bzr-ppa
 
144
      bzr co lp:~bzr/bzr/packaging-hardy
207
145
 
208
146
   There is a script available to help::
209
147
 
210
148
      tools/packaging/update-packaging-branches.sh
211
149
 
212
 
#. Optionaly, merge the Debian unstable branch into each of the packaging
213
 
   branches. You can find the Debian unstable branch here:
214
 
   http://bzr.debian.org/pkg-bazaar/
215
 
 
216
150
#. The ``bzr-builddeb`` step will download the original tarball if you do
217
151
   not already have it, putting it into a ``tarballs`` directory.
218
152
 
221
155
 
222
156
   For bzrtools this is typically::
223
157
 
224
 
      Build-Depends-Indep: bzr (>= 1.17~), rsync
225
 
      Depends: ${python:Depends}, bzr (>= 1.17~), bzr (<< 1.18~), patch
226
 
 
227
 
   There is a helper script which will update the control file and commit it
228
 
   for all of your ``$UBUNTU_RELEASES``. It is available as::
229
 
 
230
 
    tools/packaging/update-control.sh
231
 
 
232
 
   You must supply the versions as arguments as follows
233
 
   OLD_VERSION CURRENT_VERSION NEXT_VERSION, such as::
234
 
 
235
 
    tools/packaging/update-control.sh 1.16 1.17 1.18
 
158
      Build-Depends-Indep: bzr (>= 1.6~), rsync
 
159
      Depends: ${python:Depends}, bzr (>= 1.6~), bzr (<< 1.7~), patch
236
160
 
237
161
#. Make a new ``debian/changelog`` entry for the new release,
238
162
   either by using ``dch`` or just editing the file::
239
163
 
240
 
      dch -v '1.17~rc1-1~bazaar1~hardy1' -D hardy
 
164
      dch -v '1.6~beta3-1~bazaar1~hardy1' -D hardy
241
165
 
242
166
   dch will default to the distro you're working in and this isn't checked
243
 
   against the version number (which is just our convention), so make sure
 
167
   against the version number (which is just our convention), so make sure 
244
168
   to specify it.
245
169
 
246
170
   Make sure you have the correct email address for yourself (you may need
247
171
   export DEBEMAIL=`bzr whoami` if it isn't already set), version number, and
248
172
   distribution.  It should look something like this::
249
173
 
250
 
       bzr (1.17~rc1-1~bazaar1~hardy1) hardy; urgency=low
251
 
 
 
174
       bzr (1.6~beta3-1~bazaar1~hardy1) hardy; urgency=low
 
175
     
252
176
        * New upstream release.
253
 
 
 
177
     
254
178
       -- John Sample <sample@example.com>  Mon, 31 Mar 2008 12:36:27 +1100
255
179
 
256
180
   If you need to upload the package again to fix a problem, normally you
261
185
 
262
186
   You will also want to commit these changes into the packaging branch.
263
187
 
264
 
   There is a helper script which will build all the packages
 
188
   There is a helper script which will update the changelog and commit it
265
189
   for all of your ``$UBUNTU_RELEASES``. It is available as::
266
190
 
267
191
      tools/packaging/update-changelogs.sh
268
192
 
 
193
   You must supply the release string, such as::
 
194
 
 
195
      tools/packaging/update-changelogs.sh 1.6~beta3-1~bazaar1
 
196
 
 
197
   It will automatically append the distro numbering on the end.
 
198
 
269
199
#. Build the source packages::
270
200
 
271
 
      cd bzr-$DISTRO; bzr builddeb -S
 
201
      cd packaging-$DISTRO; bzr builddeb -S
272
202
 
273
203
   This will create a ``.changes`` file.  If you didn't configure builddeb
274
204
   to automatically sign them, you can use ::
277
207
 
278
208
   where ``$UID`` is the gpg key you want to use to sign the changes.
279
209
 
280
 
   There is a helper script which will build the package
281
 
   for all of your ``$UBUNTU_RELEASES``. It is available as::
282
 
 
283
 
      tools/packaging/build-packages.sh
284
 
 
285
 
#. Upload into the PPA for each release::
286
 
 
287
 
     dput dput ppa:bzr/proposed bzr*1.17-1*.changes
 
210
#. Upload into the beta PPA for each release::
 
211
 
 
212
     dput bzr-beta-ppa bzr_1.6-1*.changes
 
213
 
 
214
#. For final release versions, also copy it into the ``~bzr`` PPA::
 
215
 
 
216
     dput bzr-ppa ../bzr_1.6-1\~bazaar1\~hardy1\_source.changes
 
217
 
 
218
   Alternatively, you can use Launchpad's "copy" feature to copy the
 
219
   packages between repositories.
288
220
 
289
221
#. You should soon get an "upload accepted" mail from Launchpad, which
290
222
   means that your package is waiting to be built.  You can then track its
295
227
Packaging bzr-svn
296
228
~~~~~~~~~~~~~~~~~
297
229
 
298
 
bzr-svn uses a packaging branch that contains both the source
 
230
bzr-svn uses a packaging branch that contains both the source 
299
231
(including any changes against upstream) and the ``debian/`` directory.
300
232
 
301
233
To build bzr-svn:
302
234
 
303
235
#. Get a checkout of ``lp:~bzr/bzr-svn/hardy-ppa/``
304
236
 
305
 
#. Merge from ``http://bzr.debian.org/pkg-bazaar/bzr-svn/unstable/``
306
 
 
 
237
#. Merge from ``http://bzr.debian.org/pkg-bazaar/bzr-svn/experimental/``
 
238
  
307
239
   This should bring in both upstream and packaging changes for the new
308
240
   release, and it's updated as part of the bzr-svn release process.
309
241
 
310
 
   It's quite possible you will need to resolve some conflicts.
311
 
 
312
242
#. Run ``dch -v 0.4.15-1~bazaar1-hardy1 -D hardy`` or similar
313
243
 
314
244
#. Run ``bzr builddeb --source``
326
256
summary of current package versions with::
327
257
 
328
258
  apt-cache madison bzr
329
 
  
330
 
  
331
 
  
332
 
Packaging dependencies
333
 
----------------------
334
 
 
335
 
Some of our updates to bzr in previous releases require backports of our
336
 
dependencies.  Specific branches holding these backports:
337
 
 
338
 
 * ``lp:~bzr/ubuntu/dapper/configobj/dapper-backport``
339
259
 
340
260
 
341
261
..