14
14
__ https://help.launchpad.net/PPAQuickStart
16
As of June 2010, there are three PPAs:
16
As of June 2008, there are three PPAs:
18
18
<https://launchpad.net/~bzr/+archive>
19
Final released versions and updates.
19
Final released versions.
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.
30
have upgraded by then. (As of May 2008, Edgy Eft is no longer supported.)
32
We build a distinct package for each distrorelease.
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``.
33
34
If you upload a release-specific version, you should add a suffix to the
34
35
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.
40
37
Every package is first uploaded into the beta ppa. For final release
41
38
versions it is also copied to the main PPA.
43
40
The packaging information is kept in branches of bzr on Launchpad, named
45
42
<https://code.launchpad.net/~bzr/bzr/packaging-hardy>.
47
44
<lp:~bzr/bzr/packaging-hardy>. These branches are intended to be used
53
* You must have a Launchpad account and be a member of the teams
50
* You must have a Launchpad account and be a member of the teams
54
51
that own these PPAs (``~bzr``, ``~bzr-beta-ppa``).
56
53
* You must have a GPG key registered to your Launchpad account.
110
107
release packages is as simple as::
112
109
cd ~/dev/bzr/releases/packaging
113
export VERSION="1.17~rc1-1~bazaar1"
115
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"
116
112
~/dev/bzr/bzr.dev/tools/packaging/update-packaging-branches.sh
117
~/dev/bzr/bzr.dev/tools/packaging/update-changelogs.sh
118
~/dev/bzr/bzr.dev/tools/packaging/update-control.sh 1.16 1.17 1.18
119
~/dev/bzr/bzr.dev/tools/packaging/build-packages.sh
120
dput bzr-beta-ppa ${PACKAGE}_$VERSION*.changes
122
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
128
121
release. Such as ``~/dev/bzr/releases/packaging/hardy``. In each of these
129
122
branches, you will produce the package for the release.
131
The scripts will also create the branches and produce packages for
132
bzrtools and bzr-svn.
134
124
#. Decide on the final version number. It should be of this form::
136
bzr-1.17~rc1-1~bazaar1~hardy1
126
bzr-1.6~beta3-1~bazaar1~hardy1
138
128
**Note:** There are three hyphen-separated parts: the *package name*,
139
129
the *upstream version*, and the *packaging version*.
141
131
**Caution:** Upstream betas or release candidates must insert a tilde
142
132
to make them sort before the final release, like this:
143
``bzr-1.17~rc1-1~bazaar1~hardy1``.
133
``bzr-1.6~beta3-1~bazaar1~hardy1``.
145
135
Final releases will use a release string of the form:
146
``bzr-1.17-1~bazaar1~hardy1``
148
Set this base of this up as a usable environment variable::
150
export VERSION="1.17~rc1-1~bazaar1"
136
``bzr-1.6-1~bazaar1~hardy1``
152
138
#. Export the distroreleases that you will be packaging for::
154
export UBUNTU_RELEASES="dapper hardy intrepid jaunty karmic"
156
#. Export the program you are packaging::
140
export UBUNTU_RELEASES="dapper feisty gutsy hardy intrepid jaunty"
160
142
#. Checkout (or update) the packaging branch for each supported release::
174
156
For bzrtools this is typically::
176
Build-Depends-Indep: bzr (>= 1.17~), rsync
177
Depends: ${python:Depends}, bzr (>= 1.17~), bzr (<< 1.18~), patch
179
There is a helper script which will update the control file and commit it
180
for all of your ``$UBUNTU_RELEASES``. It is available as::
182
tools/packaging/update-control.sh
184
You must supply the versions as arguments as follows
185
OLD_VERSION CURRENT_VERSION NEXT_VERSION, such as::
187
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
189
161
#. Make a new ``debian/changelog`` entry for the new release,
190
162
either by using ``dch`` or just editing the file::
192
dch -v '1.17~rc1-1~bazaar1~hardy1' -D hardy
164
dch -v '1.6~beta3-1~bazaar1~hardy1' -D hardy
194
166
dch will default to the distro you're working in and this isn't checked
195
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
198
170
Make sure you have the correct email address for yourself (you may need
199
171
export DEBEMAIL=`bzr whoami` if it isn't already set), version number, and
200
172
distribution. It should look something like this::
202
bzr (1.17~rc1-1~bazaar1~hardy1) hardy; urgency=low
174
bzr (1.6~beta3-1~bazaar1~hardy1) hardy; urgency=low
204
176
* New upstream release.
206
178
-- John Sample <sample@example.com> Mon, 31 Mar 2008 12:36:27 +1100
208
180
If you need to upload the package again to fix a problem, normally you
214
186
You will also want to commit these changes into the packaging branch.
216
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
217
189
for all of your ``$UBUNTU_RELEASES``. It is available as::
219
191
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.
221
199
#. Build the source packages::
223
201
cd packaging-$DISTRO; bzr builddeb -S
230
208
where ``$UID`` is the gpg key you want to use to sign the changes.
232
There is a helper script which will build the package
233
for all of your ``$UBUNTU_RELEASES``. It is available as::
235
tools/packaging/build-packages.sh
237
210
#. Upload into the beta PPA for each release::
239
dput bzr-beta-ppa bzr*1.17-1*.changes
212
dput bzr-beta-ppa bzr_1.6-1*.changes
241
214
#. For final release versions, also copy it into the ``~bzr`` PPA::
243
dput bzr-ppa ../bzr_1.17-1\~bazaar1\~hardy1\_source.changes
216
dput bzr-ppa ../bzr_1.6-1\~bazaar1\~hardy1\_source.changes
245
218
Alternatively, you can use Launchpad's "copy" feature to copy the
246
219
packages between repositories.
254
227
Packaging bzr-svn
255
228
~~~~~~~~~~~~~~~~~
257
bzr-svn uses a packaging branch that contains both the source
230
bzr-svn uses a packaging branch that contains both the source
258
231
(including any changes against upstream) and the ``debian/`` directory.
260
233
To build bzr-svn:
262
235
#. Get a checkout of ``lp:~bzr/bzr-svn/hardy-ppa/``
264
#. Merge from ``http://bzr.debian.org/pkg-bazaar/bzr-svn/unstable/``
237
#. Merge from ``http://bzr.debian.org/pkg-bazaar/bzr-svn/experimental/``
266
239
This should bring in both upstream and packaging changes for the new
267
240
release, and it's updated as part of the bzr-svn release process.
269
It's quite possible you will need to resolve some conflicts.
271
242
#. Run ``dch -v 0.4.15-1~bazaar1-hardy1 -D hardy`` or similar
273
244
#. Run ``bzr builddeb --source``
added
removed
doc/developers/ppa.txt
