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
50
* You must have a Launchpad account and be a member of the teams
53
* You must have a Launchpad account and be a member of the teams
51
54
that own these PPAs (``~bzr``, ``~bzr-beta-ppa``).
53
56
* You must have a GPG key registered to your Launchpad account.
107
110
release packages is as simple as::
109
112
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"
113
export VERSION="1.17~rc1-1~bazaar1"
115
export UBUNTU_RELEASES="dapper hardy intrepid jaunty karmic"
112
116
~/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
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.
121
128
release. Such as ``~/dev/bzr/releases/packaging/hardy``. In each of these
122
129
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.
124
134
#. Decide on the final version number. It should be of this form::
126
bzr-1.6~beta3-1~bazaar1~hardy1
136
bzr-1.17~rc1-1~bazaar1~hardy1
128
138
**Note:** There are three hyphen-separated parts: the *package name*,
129
139
the *upstream version*, and the *packaging version*.
131
141
**Caution:** Upstream betas or release candidates must insert a tilde
132
142
to make them sort before the final release, like this:
133
``bzr-1.6~beta3-1~bazaar1~hardy1``.
143
``bzr-1.17~rc1-1~bazaar1~hardy1``.
135
145
Final releases will use a release string of the form:
136
``bzr-1.6-1~bazaar1~hardy1``
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"
138
152
#. Export the distroreleases that you will be packaging for::
140
export UBUNTU_RELEASES="dapper feisty gutsy hardy intrepid jaunty"
154
export UBUNTU_RELEASES="dapper hardy intrepid jaunty karmic"
156
#. Export the program you are packaging::
142
160
#. Checkout (or update) the packaging branch for each supported release::
156
174
For bzrtools this is typically::
158
Build-Depends-Indep: bzr (>= 1.6~), rsync
159
Depends: ${python:Depends}, bzr (>= 1.6~), bzr (<< 1.7~), patch
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
161
189
#. Make a new ``debian/changelog`` entry for the new release,
162
190
either by using ``dch`` or just editing the file::
164
dch -v '1.6~beta3-1~bazaar1~hardy1' -D hardy
192
dch -v '1.17~rc1-1~bazaar1~hardy1' -D hardy
166
194
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
195
against the version number (which is just our convention), so make sure
170
198
Make sure you have the correct email address for yourself (you may need
171
199
export DEBEMAIL=`bzr whoami` if it isn't already set), version number, and
172
200
distribution. It should look something like this::
174
bzr (1.6~beta3-1~bazaar1~hardy1) hardy; urgency=low
202
bzr (1.17~rc1-1~bazaar1~hardy1) hardy; urgency=low
176
204
* New upstream release.
178
206
-- John Sample <sample@example.com> Mon, 31 Mar 2008 12:36:27 +1100
180
208
If you need to upload the package again to fix a problem, normally you
186
214
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
216
There is a helper script which will build all the packages
189
217
for all of your ``$UBUNTU_RELEASES``. It is available as::
191
219
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
221
#. Build the source packages::
201
223
cd packaging-$DISTRO; bzr builddeb -S
208
230
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
210
237
#. Upload into the beta PPA for each release::
212
dput bzr-beta-ppa bzr_1.6-1*.changes
239
dput bzr-beta-ppa bzr*1.17-1*.changes
214
241
#. For final release versions, also copy it into the ``~bzr`` PPA::
216
dput bzr-ppa ../bzr_1.6-1\~bazaar1\~hardy1\_source.changes
243
dput bzr-ppa ../bzr_1.17-1\~bazaar1\~hardy1\_source.changes
218
245
Alternatively, you can use Launchpad's "copy" feature to copy the
219
246
packages between repositories.
227
254
Packaging bzr-svn
228
255
~~~~~~~~~~~~~~~~~
230
bzr-svn uses a packaging branch that contains both the source
257
bzr-svn uses a packaging branch that contains both the source
231
258
(including any changes against upstream) and the ``debian/`` directory.
233
260
To build bzr-svn:
235
262
#. Get a checkout of ``lp:~bzr/bzr-svn/hardy-ppa/``
237
#. Merge from ``http://bzr.debian.org/pkg-bazaar/bzr-svn/experimental/``
264
#. Merge from ``http://bzr.debian.org/pkg-bazaar/bzr-svn/unstable/``
239
266
This should bring in both upstream and packaging changes for the new
240
267
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.
242
271
#. Run ``dch -v 0.4.15-1~bazaar1-hardy1 -D hardy`` or similar
244
273
#. Run ``bzr builddeb --source``
added
removed
doc/developers/ppa.txt
