Actions

Developer Area/Packaging

From Mahara Wiki

< Developer Area

Here is a description of the work that is involved in maintaining the Mahara packages in Debian and Ubuntu.

If you want to get involved, get in touch with one of the members of the packaging team.

Prerequisites

You need to build packages in the target distribution. So for the most common type of uploads (to Debian unstable), you need to have a Debian unstable virtual machine of some sort.

Then install these packages:

sudo aptitude install git-buildpackage build-essential debhelper dh-make pristine-tar

Then you need to get access to the repo:

  1. Create a new account on Alioth
  2. Request to join the collab-maint group on Alioth

Put the following in your ~/.gbp.conf:

[DEFAULT]
pristine-tar = True

[git-buildpackage]
sign-tags = True
keyid = 0x007C98D1
export-dir = ../build-area/

and something like this in your ~/.bashrc:

export DEBEMAIL="[email protected]"
export DEBFULLNAME="Francois Marier"
export DEBSMTP="localhost"
export GPGKEY="007C98D1"

Getting the code from the packaging repo

All of the packaging is stored in a separate git repository.

Here's how to clone this repo:

gbp-clone ssh://git.debian.org/git/collab-maint/mahara.git

To push back to this repository you will need to get access to Collab-Maint on Alioth when asked why you're wanting an account on the Alioth site, specify it's so you can help package Mahara.

Note: Until you have ssh access, you will need to use the git:// equivalent address.

Building packages

Once you have the repo cloned, run this to build packages:

git buildpackage

They will end up in ../build-area/ where you can check them using lintian:

lintian -I --pedantic --color=auto mahara_1.4.0-1_amd64.changes

and test them on your box by installing the deb:

sudo dpkg -i mahara*1.4.0-1*deb

Making patches for existing ubuntu/debian release packages

Naturally, you will need to prepare and test your patches. Once you've done this, you:

  • Add them to the debian/patches directory, the .patch file name should be the CVE ID if this is available (eg "CVE-2011-2773.patch"), or a simple text description if no CVE ID is available (eg "mnet_masquarading.patch)"
  • Add the filenames to the series file in the debian/patches directory
  • Describe the changes in the debian/changelog file.

Note: If you're making diffs for Ubuntu, their preferences are documented here

Once you have done this, you run git buildpackage in your git checkout. The files will be put in the ../build-area directory unless you specified elsewhere.

To create the patch you will locate the previous version's build files and download them to the build-area directory. Once you have all the files, run:

debdiff old_version.dsc new_version.dsc > release_name.diff

Finally, if this is for Ubuntu, open a launchpad bug against the mahara package in Ubuntu and upload the diffs as patches. Here's an example.

Building packages for a different branch

The default branch (master) is for unstable/sid packages. If you want to build the squeeze packages for example, then you need to use a different branch.

Set it up the first time like this:

git checkout -t origin/squeeze

so that you can easily checkout the "squeeze" branch whenever you need it.

Once you're on that branch, you can build the package by passing the branch name to git-buildpackage:

git buildpackage --git-debian-branch=squeeze

Upgrading the package for a new upstream release of Mahara

First of all, download the latest stable tarball in .tar.gz format (not .zip or .tar.bz2).

Then go inside your clone of the packaging repo, on the master branch and import the tarball:

git import-orig ../mahara-1.4.0.tar.gz

Once that's done (fix any conflicts if needed), you can bump the version number in the changelog:

dch -i

Then commit this:

debcommit -a

and finally build the package and test it (see previous section).

Once it's all good, sign the build and push it to the repo:

git buildpackage --git-tag-only
git push
git push --tags

and get your Debian sponsor to upload it for you.

Things to do when preparing a new package

Useful resources