wiki:BuildingDebianPackages

Version 30 (modified by dclark, 8 years ago) (diff)

--

Building Debian Packages

Bcfg2 Packaging

The Bcfg2 project provides a debian subdirectory with the project's source that enables users to create their own Debian/Ubuntu? compatible packages (.deb files). The steps to do this, assuming that you are running on a Debian/Ubuntu? system, are as follows:

Build deps

If the distribution you are building on already has packaged bcfg2 (even an older version), the following command will likely install the necessary packages to enable it to be built:

apt-get build-dep bcfg2 bcfg2-server

Or, if the available repositories do not have any version of bcfg2, try something like:

apt-get install cdbs docbook-xsl libxslt1.1 python-dev python2.4-dev sgml-base xml-core xsltproc fakeroot

Install source code

Depending on which version of bcfg2 you want build, you can obtain the source code from Download or from the project's Subversion repository. To create a local anonymous working copy of the latest version of the bcfg2 source code, use a command like the following:

svn co https://svn.mcs.anl.gov/repos/bcfg/trunk/bcfg2 bcfg2-trunk

Configure for python version

This step is only needed in Bcfg2 1.0.0rc1 and earlier.

Once you have a copy of the source code, there are a couple of final steps.

First, Bcfg2 as packaged for Debian supports several different versions of Python. To select the appropriate version you will need to run the buildsys-select.sh script from within the debian subdirectory. You must pass it an argument <PYTHON_VERSION> that is one of the following values:

2.3
for Debian sarge.
2.4
for Ubuntu breezy, dapper, and Nexenta <= Alpha 6.
pycentral
for Debian etch or newer; Ubuntu edgy, feisty, gutsy, and hardy or newer.

As Debian and other related distributions have matured, many of these are fading from use and the correct choice for <PYTHON_VERSION> is almost always pycentral.

Once you have figured out the correct value for <PYTHON_VERSION>, run the following command:

cd bcfg2-trunk/debian
./buildsys-select.sh <PYTHON_VERSION>

Update the changelog

The next step is to update the Debian changelog file with an appropriate package version string. Debian packages contain a version that is extracted from the latest entry in the changelog file. An appropriate version will help you distinguish your locally built package from one provided by your distribution. It also helps the packaging system know when a newer version of the package is available to install.

It is possible to skip this step, but the packages you build will have the same version as the source distribution and will be easy to confuse with other similarly named (but maybe not equivalent) packages.

The basic format of the package version string to use is this:

<UPSTREAM VER>~<UPSTREAM PRE-VER>+r<UPSTREAM SVN REV>-0.1+<LOCAL VER>

NOTE: The '~', '+', and '-' characters have significance in determining when one package is newer than another. The following format is believed to do the right thing in all common situations.

The components of the package version string are explained below:

<UPSTREAM VER>
This is the version of the Bcfg source code you are working from. It will likely be something like 0.9.6 or 1.0.
~<UPSTREAM PRE-VER>
If you are using a published pre-release of Bcfg2, it will have a name like pre1 or rc1. Use that string here, otherwise drop this component and the preceding tilde (~) character from the package version string.
+<UPSTREAM SVN REV>
If you are building from a local working copy of the Subversion repository, it is useful to include the repository revision in the package version. It will be a number like '5464'. If you are building from a downloaded copy of the source, drop this component (including the preceding plus-sign (+) from the package version string.
+<LOCAL VER>
This is a locally relevant name like your last name or your domain name, plus the digit 1. For example, if your family name is Smith, you could use smith1. If you work for Example Inc, you could use example1.

Here are some examples:

  • If you are building packages for revision 5463 of the Subversion trunk, and the latest published version is 1.0pre5, the version string should be 1.0~pre5+r5463-0.1+example1.
  • If you are building packages for the published 1.0 rc1 version, the version string should be 1.0~rc1-0.1+example1.
  • If you are building packages for the published 1.0 version, the version string should be 1.0-0.1+example1.

If you are working on a Subversion working copy of 1.0 pre5 and have the devscripts package installed, the following command is a convenient way to create a well formatted changelog entry:

REV=$(svn info|grep '^Revision' |cut -d' ' -f2)
debchange --force-bad-version --preserve --newversion "1.0~pre5+r${REV}-0.1+example1" SVN revision $REV

Building the package

With the preliminaries out of the way, building the package is simple.

cd ..  # Change into the top level of the source directory
fakeroot dpkg-buildpackage -uc -us

The freshly built packages will be deposited in the parent of the current directory (..). Examine the output of dpkg-buildpackage for details.

Backport Packaging

Bcfg2 uses a lot of newer packages which need to be backported to most debian-based GNU/Linux distributions. In most cases you'll need to have these working before doing the above Bcfg2 packaging.

debhelper

Bcfg2 1.0.0rc2 and later require a very recent debhelper, which in turn requires a very recent po4a.

Versions that work are in:

  • debian: lenny-backports, squeeze, sid
  • ubuntu: karmic

No special steps are needed to do these backports.

python ssl

As of Bcfg2 1.0, Bcfg2 has switched to the in-tree ssl module included with python 2.6. A backport exists for 2.3, 2.4, and 2.5. With this, M2Crypto is not needed, and tlslite is no longer included with bcfg2 sources. The ssl module can be found here. See Authentication? for details.

To build a package of the ssl backport for .deb based distributions that don't ship with python 2.6, you can follow these instructions, which use stdeb. Alternatively if you happen to have .deb packaging skills, it would be great to get policy-complaint .debs into the major deb-based distributions.

NOTE: To build the module on Debian (lenny) and Ubuntu (hardy), I had to apply this patch to remove bluetooth references.

sudo aptitude install python-all-dev fakeroot python-setuptools libssl-dev debhelper python-support
sudo easy_install stdeb
wget http://pypi.python.org/packages/source/s/ssl/ssl-1.15.tar.gz#md5=81ea8a1175e437b4c769ae65b3290e0c
tar xvfz ssl-1.15.tar.gz
cd ssl-1.15
# patch here if necessary
stdeb_run_setup
cd deb_dist/ssl-1.15
dpkg-buildpackage -rfakeroot -uc -us
sudo dpkg -i ../python-ssl_1.15-1_amd64.deb

For complete bcfg2 goodness, you'll also want to package stdeb using stdeb:

sudo aptitude install apt-file
wget http://pypi.python.org/packages/source/s/stdeb/stdeb-0.3.tar.gz#md5=e692f745597dcdd9343ce133e3b910d0
tar xvfz stdeb-0.3.tar.gz
cd stdeb-0.3
stdeb_run_setup
cd deb_dist/stdeb-0.3
dpkg-buildpackage -rfakeroot -uc -us
sudo dpkg -i ../python-stdeb_0.3-1_all.deb

sqlalchemy

For the standard Bcfg2 1.0 Snapshots reporting feature, you need SQLAlchemy 0.5 or later, which in turn requires a recent version of sphinx. No special steps need to be taken to do these backports.

External build systems

This section describes how to build bcfg2 and deps via external build system. Currently only a PPA. Some other possibilities are:

Launchpad PPA

To upload to the PPA you need to be on the active member list of Bcfg2 in Launchpad.

setup debuild

Tell dpkg-buildpackage who you are, for example:

export DEBEMAIL="dclark@pobox.com"
export DEBFULLNAME="Daniel Joseph Barnhart Clark"

setup dput

Make a ~/.dput.cf file:

# ~/.dput.cf

[bcfg2-testing]
fqdn = ppa.launchpad.net
method = ftp
incoming = ~bcfg2/bcfg2-testing/ubuntu
login = anonymous
allow_unsigned_uploads = 0

[bcfg2-testing-force-dapper]
fqdn = ppa.launchpad.net
method = ftp
incoming = ~bcfg2/bcfg2-testing/ubuntu/dapper
login = anonymous
allow_unsigned_uploads = 0

[bcfg2-testing-force-hardy]
fqdn = ppa.launchpad.net
method = ftp
incoming = ~bcfg2/bcfg2-testing/ubuntu/hardy
login = anonymous
allow_unsigned_uploads = 0

[bcfg2-testing-force-intrepid]
fqdn = ppa.launchpad.net
method = ftp
incoming = ~bcfg2/bcfg2-testing/ubuntu/intrepid
login = anonymous
allow_unsigned_uploads = 0

[bcfg2-testing-force-jaunty]
fqdn = ppa.launchpad.net
method = ftp
incoming = ~bcfg2/bcfg2-testing/ubuntu/jaunty
login = anonymous
allow_unsigned_uploads = 0

[bcfg2-testing-force-karmic]
fqdn = ppa.launchpad.net
method = ftp
incoming = ~bcfg2/bcfg2-testing/ubuntu/karmic
login = anonymous
allow_unsigned_uploads = 0

upload po4a

upload debhelper

upload sphinx

Build and upload newer sphinx, which sqlalchemy depends on:

debchange --force-bad-version --preserve --newversion "0.6.2-1~ppa2~jaunty2" \
Backport to jaunty to support more recent sqlalchemy required by new bcfg2 1.0 snapshots reporting feature

# Replace 0xAA95C349 to your GnuPG Key ID
debuild -S -k0xAA95C349
dput bcfg2-force-jaunty sphinx_0.6.2-1~ppa2~jaunty2_source.changes

Also install the .deb locally using dpkg, so the next step works.

upload sqlalchemy

Build and upload newer sqlalchemy:

debchange --force-bad-version --preserve --newversion "0.5.5-1~ppa2~jaunty2" \
Backport to jaunty to support new bcfg2 1.0 snapshots reporting feature

# Replace 0xAA95C349 to your GnuPG Key ID
debuild -S -k0xAA95C349
dput bcfg2-force-jaunty sqlalchemy_0.5.5-1~ppa2~jaunty2_source.changes

upload bcfg2