~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

Viewing changes to doc/developers/ppa.txt

  • Committer: Robert Collins
  • Date: 2005-10-14 04:54:03 UTC
  • mto: This revision was merged to the branch mainline in revision 1456.
  • Revision ID: robertc@lifelesslap.robertcollins.net-20051014045403-321deeebf084406f
allow global overriding of signature policy to force checking, or (pointless but allowed) to set auto checking

Show diffs side-by-side

added added

removed removed

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