Developer Area/Packaging: Difference between revisions
From Mahara Wiki
< Developer Area
(More config files to set) |
No edit summary |
||
(7 intermediate revisions by 2 users not shown) | |||
Line 14: | Line 14: | ||
# Create a [https://alioth.debian.org/account/register.php new account] on Alioth | # Create a [https://alioth.debian.org/account/register.php new account] on Alioth | ||
# | # Request to join the [https://alioth.debian.org/projects/collab-maint/ collab-maint group] on Alioth | ||
Put the following in your <tt>~/.gbp.conf</tt>: | Put the following in your <tt>~/.gbp.conf</tt>: | ||
Line 38: | Line 38: | ||
gbp-clone ssh://git.debian.org/git/collab-maint/mahara.git | 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 [https://alioth.debian.org 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 = | = Building packages = | ||
Line 52: | Line 56: | ||
sudo dpkg -i mahara*1.4.0-1*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 [https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Update_the_packaging documented here] | |||
Once you have done this, you run <tt>git buildpackage</tt> 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 [https://bugs.launchpad.net/ubuntu/+source/mahara the mahara package in Ubuntu] and upload the diffs as patches. [https://bugs.launchpad.net/ubuntu/+source/mahara/+bug/888358 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 [https://launchpad.net/mahara/+download 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 = | |||
* Look for any [http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=mahara Debian] or [https://bugs.launchpad.net/ubuntu/+source/mahara Ubuntu] bugs that could be fixed at the same time. | |||
* Have a look at the TODO section of the [http://packages.qa.debian.org/mahara Debian Package Tracking system]. | |||
* Fix all lintian notices, warnings and errors. | |||
= Useful resources = | |||
* https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Packaging | |||
* http://www.debian.org/doc/manuals/maint-guide/ |
Latest revision as of 18:13, 14 November 2011
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:
- Create a new account on Alioth
- 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
- 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.