14
14
__ https://help.launchpad.net/PPAQuickStart
16
As of June 2008, there are three PPAs:
16
As of June 2010, there are three PPAs:
18
18
<https://launchpad.net/~bzr/+archive>
19
Final released versions.
19
Final released versions and updates.
21
21
<https://launchpad.net/~bzr-beta-ppa/+archive>
22
Releases and release candidates.
24
24
<https://launchpad.net/~bzr-nightly-ppa/+archive>
25
25
Automatic nightly builds from trunk.
27
27
We build packages for every supported Ubuntu release
28
28
<https://wiki.ubuntu.com/Releases>. Packages need no longer be updated
29
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.)
30
have upgraded by then.
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``.
32
We build a distinct package for each distrorelease.
34
33
If you upload a release-specific version, you should add a suffix to the
35
34
package version, e.g. ``bzr.1.3-1~bazaar1~dapper1``.
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.
37
40
Every package is first uploaded into the beta ppa. For final release
38
41
versions it is also copied to the main PPA.
40
43
The packaging information is kept in branches of bzr on Launchpad, named
42
45
<https://code.launchpad.net/~bzr/bzr/packaging-hardy>.
44
47
<lp:~bzr/bzr/packaging-hardy>. These branches are intended to be used
45
48
with the ``bzr-builddeb`` plugin.
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.
50
* You must have a Launchpad account and be a member of the teams
57
* You must have a Launchpad account and be a member of the teams
51
58
that own these PPAs (``~bzr``, ``~bzr-beta-ppa``).
53
60
* You must have a GPG key registered to your Launchpad account.
55
* Configure ``dput`` to upload to our PPA with this section in your
59
fqdn = ppa.launchpad.net
61
incoming = ~bzr-beta-ppa/ubuntu
63
allow_unsigned_uploads = 0
66
fqdn = ppa.launchpad.net
68
incoming = ~bzr/ubuntu
70
allow_unsigned_uploads = 0
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
62
On reasonably recent versions of Ubuntu you no longer need special dput
63
configuration, because you can just say ::
65
dput ppa:bzr/2.1-proposed <source.changes
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::
77
73
default_host_main = notspecified
79
75
* Configure ``bzr-builddeb`` to sign the package, which is required for
80
76
Launchpad to build it. Put this in ``~/.bazaar/builddeb.conf`` ::
99
Overview of packaging with builddeb
100
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
102
* First update the oldest supported branch, using ``bzr merge-upstream``.
104
* Run ``bzr builddeb -S -- -sa`` to build a source package, then put
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.)
113
* Now merge across that change into each supported branch with a
114
simple ``bzr merge``.
116
Locally testing builds
117
~~~~~~~~~~~~~~~~~~~~~~
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>
107
128
release packages is as simple as::
109
130
cd ~/dev/bzr/releases/packaging
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"
131
export VERSION="1.17~rc1-1~bazaar1"
133
export UBUNTU_RELEASES="dapper hardy intrepid jaunty karmic"
112
134
~/dev/bzr/bzr.dev/tools/packaging/update-packaging-branches.sh
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
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
140
Rinse and repeat for all the plugins by changing VERSION and PACKAGE.
121
146
release. Such as ``~/dev/bzr/releases/packaging/hardy``. In each of these
122
147
branches, you will produce the package for the release.
149
The scripts will also create the branches and produce packages for
150
bzrtools and bzr-svn.
124
152
#. Decide on the final version number. It should be of this form::
126
bzr-1.6~beta3-1~bazaar1~hardy1
154
bzr-1.17~rc1-1~bazaar1~hardy1
128
156
**Note:** There are three hyphen-separated parts: the *package name*,
129
157
the *upstream version*, and the *packaging version*.
131
159
**Caution:** Upstream betas or release candidates must insert a tilde
132
160
to make them sort before the final release, like this:
133
``bzr-1.6~beta3-1~bazaar1~hardy1``.
161
``bzr-1.17~rc1-1~bazaar1~hardy1``.
135
163
Final releases will use a release string of the form:
136
``bzr-1.6-1~bazaar1~hardy1``
164
``bzr-1.17-1~bazaar1~hardy1``
166
Set this base of this up as a usable environment variable::
168
export VERSION="1.17~rc1-1~bazaar1"
138
170
#. Export the distroreleases that you will be packaging for::
140
export UBUNTU_RELEASES="dapper feisty gutsy hardy intrepid jaunty"
172
export UBUNTU_RELEASES="dapper hardy intrepid jaunty karmic"
174
#. Export the program you are packaging::
142
178
#. Checkout (or update) the packaging branch for each supported release::
156
192
For bzrtools this is typically::
158
Build-Depends-Indep: bzr (>= 1.6~), rsync
159
Depends: ${python:Depends}, bzr (>= 1.6~), bzr (<< 1.7~), patch
194
Build-Depends-Indep: bzr (>= 1.17~), rsync
195
Depends: ${python:Depends}, bzr (>= 1.17~), bzr (<< 1.18~), patch
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::
200
tools/packaging/update-control.sh
202
You must supply the versions as arguments as follows
203
OLD_VERSION CURRENT_VERSION NEXT_VERSION, such as::
205
tools/packaging/update-control.sh 1.16 1.17 1.18
161
207
#. Make a new ``debian/changelog`` entry for the new release,
162
208
either by using ``dch`` or just editing the file::
164
dch -v '1.6~beta3-1~bazaar1~hardy1' -D hardy
210
dch -v '1.17~rc1-1~bazaar1~hardy1' -D hardy
166
212
dch will default to the distro you're working in and this isn't checked
167
against the version number (which is just our convention), so make sure
213
against the version number (which is just our convention), so make sure
170
216
Make sure you have the correct email address for yourself (you may need
171
217
export DEBEMAIL=`bzr whoami` if it isn't already set), version number, and
172
218
distribution. It should look something like this::
174
bzr (1.6~beta3-1~bazaar1~hardy1) hardy; urgency=low
220
bzr (1.17~rc1-1~bazaar1~hardy1) hardy; urgency=low
176
222
* New upstream release.
178
224
-- John Sample <sample@example.com> Mon, 31 Mar 2008 12:36:27 +1100
180
226
If you need to upload the package again to fix a problem, normally you
186
232
You will also want to commit these changes into the packaging branch.
188
There is a helper script which will update the changelog and commit it
234
There is a helper script which will build all the packages
189
235
for all of your ``$UBUNTU_RELEASES``. It is available as::
191
237
tools/packaging/update-changelogs.sh
193
You must supply the release string, such as::
195
tools/packaging/update-changelogs.sh 1.6~beta3-1~bazaar1
197
It will automatically append the distro numbering on the end.
199
239
#. Build the source packages::
201
241
cd packaging-$DISTRO; bzr builddeb -S
208
248
where ``$UID`` is the gpg key you want to use to sign the changes.
250
There is a helper script which will build the package
251
for all of your ``$UBUNTU_RELEASES``. It is available as::
253
tools/packaging/build-packages.sh
210
255
#. Upload into the beta PPA for each release::
212
dput bzr-beta-ppa bzr_1.6-1*.changes
257
dput bzr-beta-ppa bzr*1.17-1*.changes
214
259
#. For final release versions, also copy it into the ``~bzr`` PPA::
216
dput bzr-ppa ../bzr_1.6-1\~bazaar1\~hardy1\_source.changes
261
dput bzr-ppa ../bzr_1.17-1\~bazaar1\~hardy1\_source.changes
218
263
Alternatively, you can use Launchpad's "copy" feature to copy the
219
264
packages between repositories.
227
272
Packaging bzr-svn
228
273
~~~~~~~~~~~~~~~~~
230
bzr-svn uses a packaging branch that contains both the source
275
bzr-svn uses a packaging branch that contains both the source
231
276
(including any changes against upstream) and the ``debian/`` directory.
233
278
To build bzr-svn:
235
280
#. Get a checkout of ``lp:~bzr/bzr-svn/hardy-ppa/``
237
#. Merge from ``http://bzr.debian.org/pkg-bazaar/bzr-svn/experimental/``
282
#. Merge from ``http://bzr.debian.org/pkg-bazaar/bzr-svn/unstable/``
239
284
This should bring in both upstream and packaging changes for the new
240
285
release, and it's updated as part of the bzr-svn release process.
287
It's quite possible you will need to resolve some conflicts.
242
289
#. Run ``dch -v 0.4.15-1~bazaar1-hardy1 -D hardy`` or similar
244
291
#. Run ``bzr builddeb --source``
added
removed
doc/developers/ppa.txt
