Debian OpenStack packaging team home


You've reached the packaging team home page. This is the first step to contributing to the packaging of OpenStack in Debian. Feel free to discuss any of this page content with us on IRC: irc.debian.org, aka oftc network, on the #debian-openstack channel. You can also join the mailing list. Register here: http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/openstack-devel. If you don't know how to help, just ask, we'll be happy to explain. There's always a bunch of things to do, OpenStack packaging never stops. Also, there's a todo over here: https://wiki.debian.org/OpenStack/OpenStack/todo.

Packaging workflow

The first time

  1. Clone the repository:
    git clone git+ssh://git.debian.org/git/openstack/glance.git
  2. cd glance
  3. Add the upstream remote (only needed if you need to merge upstream master into the packaging branch):
    ./debian/rules fetch-upstream-remote
    Note that at no point, the upstream "master" bramch should ever be uploaded to Alioth. The upstream tags in the packaging branch are enough to generate the orig.tar.xz.

Get all openstack repositories

  1. Clone the opestack-myrepos repository:
    git clone git+ssh://git.debian.org/git/openstack/openstack-myrepos.git
  2. cd openstack-myrepos
  3. Add .mrconfig to your trust file:
    echo $PWD/.mrconfig >> ~/.mrtrust
  4. Update the repositories:
    mr update

Uploading a new version

  1. Fetch from it, so you'll get new tags:
    ./debian/rules fetch-upstream-remote
  2. If necessary, checkout the Debian branch you need:
    git checkout debian/unstable
  3. Merge upstream changes in the Debian branch by merging the tag you want, for example 2011.3:
    git merge -X theirs 2011.3
  4. If you need, build the orig.tar.xz:
    ./debian/rules gen-orig-xz
  5. Update your packaging if needed, commit as you need. Do small, atomic commits.
    git commit ...
  6. When finished, tag and sign what you uploaded to Debian, for example version 2011.3-1:
    git tag -s debian/2011.3-1 -m 'Debian release 2011.3-1'
  7. Then you can push everything on Alioth:
    git push && git push --tags


If you want a quick way to package a new python module, you can use this script. Note that you will *have* to fix the debian/copyright and the long and short descriptions, plus reviewing all of the packaging is completely mandatory. This is just to make things faster, this doesn't remove completely the packaging work.

debian/rules targets

  1. If you wish to do the above in one command, you can do:
    ./debian/rules get-vcs-source
  2. This will add upstream remote, fetch it, create the orig.tar.xz, and go back to the debian/unstable branch.
    Note that if you aren't working on a new upstream release, you should download the orig.tar.xz from SID, and not used the produced tarball.
    If such rules target isn't present in the package you are working on, please add it (you can take the nova package as example). Note that for non-core packages, like Python modules, you should *not* add openstack-pkg-tools as build-dependency, and use "-include /usr/share/openstack-pkg-tools/pkgos.make" instead of just "include" (note the "-" in front of the include). This way, you will make an eventual backport easier (eg: no need to backport openstack-pkg-tools) if someone needs that python module. Note that this is currently not the case for most Python modules in the team (this is a work in progress to fix this), and if you see a build-depends on openstack-pkgs-tools in such a Python module, just remove it and add the "-" in front of the include.

Managing upstream pre-release tags

In OpenStack, there are pre-releases that you might wish to package. These releases are using tags which are a bit annoying for us. For example, 2013.2.rc1. In this case, we need to make sure that it becomes 2013.2~rc1 once packaged. The issue is that the ~ char is not useable in Git. Therefore, you can use _, and the scripts in openstack-pkg-tools will do the rest (and convert the _ into ~). So you will need to retag: git tag 2013.2_rc1 2013.2.rc1 And don't forget to "git push --tags" so that the new tag is on Alioth. Remember that we do not need the master branch to be hosted in Alioth, and that the packaging branch should be the default one. If you do a mistake, you can always change the default branch by going on the Alioth machine, and inside your Git repository, do:
git symbolic-ref HEAD refs/head/debian/havana

Once your done: uploading to Alioth with correct rights

It is easy to upload a git to Alioth. It isn't to do it correctly. If you don't pay attention, you will be the only one with write access to your Git repository. The below script, to be run on Alioth tells you what you have to do.
set -e


cd /git/${DEST_PROJECT}

echo '===> Activating update-server-info hook'
mv ${PKG_NAME}.git/hooks/post-update.sample ${PKG_NAME}.git/hooks/post-update
cd /git/${DEST_PROJECT}/${PKG_NAME}.git
git --bare update-server-info

echo '===> Fxing g+w unix permissions'
find /git/${DEST_PROJECT}/${PKG_NAME}.git -exec chmod g+w {} \;
find . -type d -exec chmod g+s {} \;
git config core.sharedRepository group
Some of us use this script for uploading a git repository to Alioth. Simply go at the top of your local git repository, and type: "alioth-new-git openstack", and it will make an archive of a bare copy of your local repository, upload that archive to Alioth, uncompress it there in /git/openstack, then fix the access rights correctly. Note that this script is meant to be used by debian developers, so you will need to addapt it if your computer login doesn't match the login on Alioth (eg, add the -guest and so on).

Openstack Jenkins

All of OpenStack building is managed by a Jenkins machine which produces Wheezy backports. After a "git push", it will automatically build the package that you are working on, and put it in a repository. For the moment, there's the following:
deb http://havana.dev-debian.pkgs.enovance.com/debian havana main
deb http://archive.gplhost.com/debian havana-backports main
The 2nd repository is a bunch of backports made in a semi-automated fashion, while the first one contains only the packages maintained within the Debian packaging team for OpenStack.

We also maintain some Ubuntu packages, which are available from:
deb http://havana.dev-ubuntu.pkgs.enovance.com/debian precise-havana-backports main
And there's already work being done for packaging Icehouse:
deb http://icehouse.dev-debian.pkgs.enovance.com/debian icehouse main
deb http://archive.gplhost.com/debian havana-backports main
deb http://archive.gplhost.com/debian icehouse-backports main
For the moment, you need all of the above 3 Debian repositories for Icehouse, though this will change later on. There's also no Icehouse for Ubuntu yet in the above, as this comes usually later on in the development process (as maintaining both Ubuntu and Debian gives more work).

You can join #debian-openstack-commits to see the result of your git push as well. Once the build is completed, please test the resulting packages before uploading to Sid. Also, if you want to see the logs, you can browse the Jenkins:

Debconf handling

In many packages, there are automations to maintain the basic configuration. You can see examples on how to write them with a few Git commits (examples in the Trove and Neutron packages):