To request membership to this group, please go on our Alioth page, or directly follow this link. Remember that you must have an Alioth account before requesting membership (see here to request an Alioth account).

To check the sources of a package (referred as <package> below) in our repositories, use the debcheckout command, from the devscripts package.

You can avoid specifying your Alioth user name by setting it in ~/.ssh/config as follows. Note that in that case, with debcheckout you will can replace the --user option by the -a option, for a shorter typing.

Host *.debian.org
	User your-user-name

You can avoid typing your SSH password again and again using the ssh-add command. On remote connections the SSH agent needs to be enabled with the command eval $(ssh-agent).

In case of trouble getting SSH working it is a good idea to read this wiki article.

The SVN repository is structured as follows:

debian-med/
 └ trunk/
    ├ community/
    │  ├ debtags/
    │  ├ infrastructure/
    │  └ website/
    └ packages/
       ├ <package A>/
       │  ├ branches/
       │  ├ tags/
       │  └ trunk/
       │     └ debian/
       ├ <package B>/
       │  ├ branches/
       │  ├ tags/
       │  └ trunk/
       │     └ debian/
       …

Suggested aliases for svn-buildpackage:

alias svn-b='svn-buildpackage -us -uc --svn-ignore'
alias svn-br='svn-b --svn-dont-purge --svn-reuse'
alias svn-bt='svn-buildpackage --svn-tag'

svn-inject -o sets up the mergeWithUpstream property for the SVN directories where packages are stored. In case svn-inject was not used, you can do it by hand with the command svn propset mergeWithUpstream 1 debian.

To download the upstream sources (if there is a debian/watch file): echo "origDir=.." >> .svn/deb-layout && uscan --force-download. Alternatively, you can try debian/rules get-orig-source.

If you're a Debian developer or a member of the Debian Med group on Alioth, you can commit your changes: svn commit (also svn ci). Otherwise, you can ask to be added to the group (see the Membership section), or send the result of svn diff to the mailing list (gzip -9 it, if it's too large).

It may happen that a package version has been uploaded to Debian repositories, and you forgot to tag the last build with svn-buildpackage --svn-tag. You can tag this package also retroactively. A first step, creating the tags directory, can be achieved in two ways: either create it locally as sibling of trunk/ with svn mkdir tags, and commit with svn commit, or create it remotely with svn mkdir svn+ssh://user@svn.debian.org/svn/debian-med/trunk/packages/<package>/tags. After the tags directory has been created, you're ready to tag the package: svn-buildpackage --svn-tag-only --svn-no-autodch. The --svn-no-autodch avoids debian/changelog to be marked as UNRELEASED.

Here is an example session where a package is prepared manually:

# Check out debian-med/trunk, cd to debian-med/trunk/packages
# Create new project folder with
svn mkdir projectname
svn mkdir projectname/trunk

# Put orig.tar.gz in place
mv some_version.orig.tar.gz projectname

# Inform svn-buildpackage about the location of the orig.tar.gz
echo "origDir=.." > projectname/trunk/.svn/deb-layout

# Untar source tree for development
cd projectname
tar xzvf some_version.orig.tar.gz
cd some-version # entering the unpackaged source tree
if [ ! -d debian ]; then dh_make ; fi
mv debian ../trunk
ln -s ../trunk/debian .

# continue development
fakeroot ./debian/rules binary

# until it works, finally
cd ..

# debian directory is the only thing that is stored in svn, to be merged with upstream
svn propset mergeWithUpstream 1 trunk/debian

# See if things can be compiled via svn-buildpackage
cd trunk
svn-buildpackage -uc -us

# check build
lintian ../build-area/*changes

The area on Alioth that contains the Git repositories (/git/debian-med) is not itself structured, but the repositories can be arranged in different possible layouts.

For packages were we set the mergeWithUpstream property, which excludes the upstream sources, there is no easy way to prepare a Git repository from our Subversion repository that would look like the package was always managed in Git. Nevertheless, the following recipe will generate a Git repository that contains all the history of the debian directory, plus a collection of selected upstream source releases.

It is also possible to prepare a Git repository containing some of the package's history using the command git-import-dscs --debsnap from the helper toolkit git-buildpackage. This will download all the versions of a package available in snapshots.debian.org and create tags for each of them. Note that as this paragraph is written, the tool is not aware that backports should be a different branch

Most source packages maintained as Git repositories in Debian Med are using the git-buildpackage helper toolkit. In doubt, try this one first.

git-buildpackage's command git-import-orig allows very easy update of the upstream branch when the original sources are distributed as a compressed archive. Its option --pristine-tar is useful for stabilizing the MD5 sum of the “orig.tar.gz” produced when building a source package from the repository alone (not doing so results in archive rejection of package updates). With recent versions of git-buildpackage, it is often unnecessary to rename the freshly downloaded original upstream archive.

Some newcomers tend to go the create DEBIAN dir, move files around and `dpkg-deb -b` way to create Debian packages. Short answer: Forget about this. The only way to the official Debian mirror leads via proper source packages. The right way to build Debian packages is described in Debian New Maintainers' Guide.

If you intent to work on a Debian package you should follow the normal Debian rules and file a WNPP bug report.

It is a good idea to keep the Debian Med mailing list debian-med@lists.debian.org in CC and to set it as the owner of the ITP to keep your co-workers informed. This will ensure that we notice if for some reason the package has not been uploaded.

In addition, please add the package to the “task” file where it fits the best, and document your ITP number using the WNPP field name.

Debian offers backports to its stable version. Backports of Debian Med packages should be kept as branches in our Subversion or Git repositories.

Debian Med operates a Personal Package Archive (PPA) on Launchpad, where packages are backported for Ubuntu. There is currently no team policy on what to build.

Please keep in mind issues like the possibility to upgrade to the next Ubuntu stable release. Packages that are backports can be made inferior in version by using a tilde. If the package contains additional development, a version number without the tilde will make it higher, but not as high as the next Debian revision. For example: 2.12.0-1~natty1 (backport in PPA) < 2.12.0-1 (from Debian in Ubuntu) < 2.12.0-1natty1 (in PPA, containing additions) < 2.12.0-2 (from Debian in Ubuntu).

Packages sent to this PPA may be kept as branches in our repositories.

Lintian checks are adapted to Ubuntu by setting the environment as follows: LINTIAN_PROFILE=ubuntu.

GNU R sometimes introduces backward incompatibilities, so the current practice is to make packages depend on versions equal or higher to the one against which they were built. When using r-base-dev, this can be acheived by adding the substitution variable ${R:Depends} in the Depends field of the binary package.

We use the machine-readable format for the debian/copyright file. The Source field does not need to contain the full URL to the particular version that is being packaged, since this can be determined by the uscan program with the debian/watch file. Please list yourself in the Files: debian/* section if you think that your contributions are not trivial and therefore subjected to copyright. Please chose a license that is compatible with the program you package. You can also use “same as if it were in the public domain” or “same as the packaged program itself”.

To create some reasonable skeleton for a debian/copyright file you can try the following:

To verify the correct syntax of the debian/copyright file you can use:

from package libconfig-model-perl.

Packages hosted in our Subversion repository, that have been modified but not uploaded must use UNRELEASED as a distribution name. This can be done automatically by declaring DEBCHANGE_RELEASE_HEURISTIC=changelog in ~/.devscripts and using dch.

We use the bibliographic information which should be stored in the file debian/upstream. The purpose of specifying this is to enhance the contact to upstream which thus gets an extra reward of their work if their citations show up on pages inside the Debian domain and if users more popularly are asked to cite upstream when working with the program in question.

Packages managed with git-buildpackage may mark this by including a debian/gbp.conf configuration file. The following recommended values will make pristine-tar used by default.

[DEFAULT]
pristine-tar = True

This file is recommended by the Policy (§ 4.14) from version 3.8.0 for documenting source package handling. Please follow the recommendation. For instance, this file is needed when we use a patch system, when the upstream sources are in another format than gzipped tar archive, when we repack the sources,…

This file was (recommended by the Security team) for describing to others than the regular maintainer how the package's functionality can properly be tested.

Debhelper uses compatibility levels to control the behaviour of its commands. We currently recommend to use the level 8 which is available in current Stable (Squeeze) and backported to Oldstable. However, there is no urgent need to touch packages only because it has an older Debhelper version.

It is strongly recommended to use the short dh notation in debian/rules files which makes code factorisation very simple and easy to understand the packaging for other members of the team. Even complex packaging becomes quite transparent this way.

Before the short dh notation of debhelper existed CDBS was the only way to factorise code in debian/rules files. So it was recommended in the past but it turned out that CDBS is badly documented and recently introduced incompatible changes. So it is sometimes reasonable to switch from CDBS to dh if some problems in the packaging might occure.

It is technically possible to build CDBS packages using Debhelper without the debian/compat file. Please do not, and always include such a file according to the above guidelines.

We are currently using two different version control systems, Subversion and Git.

Try to inject a new package only after successfully building it with dpkg-buildpackage (or any wrapper around it). Use a file like debian/DRAFT to mention when the package is a draft.

Once you injected a new package please make sure that it is mentioned in the appropriate tasks file in the SVN source of the debian-med Blend package. Some team members watch the changes in the Debian Med packaging pool but it helps if the maintainer of a new package verifies that everything is in the right place.

We prefer that uploaded packages are built in a chroot, to provide similar build environment to the whole team. After upload, please tag the Suvbersion or Git repository.

Often happens that the upstream code doesn't fit well into the Debian distribution: be this wrong paths, missing features, anything that implies editing the source files. When you directly edit upstream's source files, your changes will be put into a .diff.gz file if you use the 1.0 source format and in a monolithic patch if you use the 3.0 (quilt) format. To better organise the patches and group the by function, please use a patch handling system which keeps patches under the debian/patches directory.

The 3.0 (quilt) Dpkg source format provides its own patch system. Apart from this, the most popular is quilt. simple-patchsys, from the CDBS package, is deprecated since version 0.4.85. dpatch has been popular as well, but is not compatible with the 3.0 (quilt) source format and is planned to be removed 2017. Please don't use any other patch system in Debian Med, unless absolutely necessary.