Guidelines for developers wishing to contribute to Debian-Edu

The Debian-Edu/Skolelinux project is a Debian Pure Blend effort. It builds its own CD+DVDs based on Debian packages.

We use Subversion for version control and management of the code. The repository is placed on The project is part of the Debian Pure Blends (formerly known as Custom Debian Distributions) group, and we use Alioth for management of the contributors. In order to contribute to the project you will need an account at Alioth. This is accomplished by visiting the user portal at and creating an account.

For just read only access, use this command:

$ svn checkout svn://

Just follow the instructions, reply to any email messages that may be sent, and you will in the end be rewarded with an account. Most people are not Debian Developers, and they will be identified as <user>-guest. Registered Debian Developers don't have to live with being guests.

In order to get ssh access to Alioth you'd have to join a project, for joining Debian Edu submit a request at You'd need this for privileged access to check in your changes. For more information see It may take some days for your request to be accepted, if you get no response cry out on the mailing list, meanwhile you'd be able to use most features without ssh.

Once you have an account, the next step is to check out the Subversion tree. If Subversion is a new tool to you, we suggest a visit to the project site to find documentation on its use. To install it on your Debian system, use

# apt-get install subversion subversion-tools

To get you going, the command to check out the debian-edu code is:

$ svn co svn+ssh:// debian-edu

If logging in fails do:

$ svn co svn:// debian-edu

later on, when you get your ssh access sorted, in order to check in your changes you'd have to run:

$ svn switch --relocate svn:// svn+ssh://

At this stage you have a copy of our code locally on your computer, and the means to modify it. We suggest you use your powers to influence the contents of the CD+DVDs with some care. Improperly tested solutions will hamper the development and draw attention away from the forward movement.There are innumerable ways in which to contribute. However, the main method for reporting errors and suggesting improvements is our bugs database. If Bugzilla is a new tool to you, please look at their project site for information on its use.

It is of more benefit to the project that new developers fix bugs rather than making new additions nilly willy. Please consider squashing some bugs before suggesting new features and applications.

Once you have decided on a bug that looks a good candidate for your efforts, make sure that you have a current installation of Debian-Edu to test the fixes. Once you are satisfied that the work you have done will close the bug, check in the changes to the code using svn. Maybe before you decide to upload a new version of the package you coordinate your work with the other developers on IRC ( channel #debian-edu) so that you can't shoot in someones leg and others are informed. Don't forget to make a set of comments to the changes when you check in. Also remember to update the debian/changelog file to record your efforts and give yourself proper credit for the work. At the top line you should put the number of the svn revision. Normally you check in the changes, note the svn revision number, make the changes to debian/changelog and put the noted number plus one (it gets upped one when you check in the changelog) in the top line of debian/changelog.

Once the changelog is updated and all the files checked in, the package you are working on can be rebuilt. You will need a number of tools, all of which are available from the normal apt repositories. Use this list as a guide:

The package you are working on should build cleanly using the command

$ svn-buildpackage -rfakeroot -us -uc

from the directory immediately above the debian/ directory (using the options -us -uc to svn-buildpackage -rfakeroot will prevent a GPG signing).

$ svn-buildpackage -rfakeroot -us -uc

Then all other developers can verify who did the upload and the archive software will check if you are a valid uploader.

In order to get the package onto the CD it needs to be uploaded into the archive. Upload the package using the dput/dupload tool:

$ dput skolelinux *.changes or $ dupload --to skolelinux *.changes

That is all you need to do before the CD builds. Give yourself fifteen minutes to get a cup of coffe or a little stretch on the couch while the CD builds. After the CD is finished, you need to sync your current image of the CD with that on so that you have an updated version to test with. One way to sync the CD is to use rsync, then you download only the changes between the previous version and the current. This is a command to do that:

$ rsync --verbose --times \ \

And that's it. Now you should have a version of the CD that includes the changes you have made. The next step is to verify that the changes actually do what you think. How that is accomplished depends entirely on the nature of the changes. It may be necessary with a reinstall or it could be enough just to update the package on a current installation of Debian Edu.

Good luck!

Adding a new package to the CD/DVD

TODO: this needs to be updated for squeeze. maybe s/etch/squeeze/ is enough though ;-)

Here is the explanation of how to add a new package to the CD/DVD. At first please write a mail to and discuss it there if you are not completely sure!

Then there are two alternatives. One is to update the debian-edu-svn:src/build/CD/extrapkgs-etch-test.txt, and add the name of the new package to the list. The packages listed here will be added to the end of the list of packages to put on the CD, and might not make it into the CD.

The other is debian-edu-svn:/src/build/CD/hintpkgs-etch-test.txt, listing packages to add earlier in the package list, to control which package alternative is selected when the CD build need to make choices. The packages listed here are added just after the base packages.

Then the packages are added to the daily build which is produced from the etch-test suite. Later on it can be added to the more stable development branch.

If there are problems with getting your package on the CD you should fill a bug against the "Archive system" component.