If you want to get involved, get in touch with one of the members of the packaging team.
- 1 Prerequisites
- 2 Getting the code from the packaging repo
- 3 Building packages
- 4 Upgrading the package for a new upstream release of Mahara
- 5 Things to do when preparing a new package
- 6 Useful resources
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:
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@example.com" 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:
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.
Once you have the repo cloned, run this to build packages:
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
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:
Then commit this:
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
- Look for any Debian or Ubuntu bugs that could be fixed at the same time.
- Have a look at the TODO section of the Debian Package Tracking system.
- Fix all lintian notices, warnings and errors.