pkg-phototools — Photo Tools in Debian


This website aims at providing users with information about the packages maintained within this team, as well as providing developers with guidelines about how to contribute.

It is currently maintained in the pkg-phototools/website.git repository on and gets updated on push operations thanks to the post-receive hook.

The team can be contacted using:

User information

At the moment, some links to the available packages:

Developer information

Project members

Useful links

Best packaging practices


Packages are maintained in Git repositories (one per package), hosted on

There are instructions about creating a Git repository available on Debian's wiki.

To get commit mails for a given repository, it is sufficient to activate a post-receive hook:

# To be done on git.d.o, under /git/pkg-phototools/$SOURCE.git
git-config --add hooks.mailinglist \
echo ". /home/groups/pkg-phototools/hooks/post-receive-email" \
      >> hooks/post-receive
chmod 755 hooks/post-receive

Content of debian/control

Maintainer: Debian PhotoTools Maintainers <>
Vcs-Git: git://$SOURCE.git

The first person listed in the Uploaders field is supposed to be the primary responsible for that package. That is intended to avoid packages not receiving appropriate care because of team members all relying on each others to fix bugs, but is not supposed to limit the participation of other members, or external contributors.

Proposed workflow

It seems reasonable to only store debian/ (that is: the directory and its content) under Git for each package. Patch systems as quilt and dpatch can be used to store patches against upstream sources. Upstream tarballs can be fetched using either uscan (thanks to debian/watch files), or using apt-get source when there's already a revision in the archive.

Note that in case of a repack (to prune files that aren't DFSG-compliant), one should add a get-orig-source target to debian/rules, which does that job automatically (Developer's Reference

Possible ways of handling branches: work on master or unstable, and branch when needed, for example uploads targeted at experimental, or at $SUITE-backports).

Possible tag formats:

Either way, running git-tag -l should ensure coherence within a given package.

Due to limitations in the tag name format, the following convention has been proposed:

Per-package tasks can be listed in debian/TODO, so that other maintainers can see easily what has to be done on a given package.

Submitting patches

Quick summary of possible ways to submit patches:

# Clone a given repository
git-clone git://$SOURCE.git

# Hack hack hack, commit as much as you want

# Check the work done since origin (origin/master or origin/unstable)
git-log origin..

# A) Generate a series of patches (0001-Summary, 0002-Another, etc.), and
#    mail them to the team (the latter requires the git-email package)
git-format-patch origin
git-send-email --to *.patch

# B) Push the (local) master branch somewhere online
git-remote add alioth ssh://$YOU/$SOURCE.git
git-push alioth master
# then let the team know about the location of your branch, so that
# it can get fetched, merged, cherry-picked from, etc.
Git documentation

If you're new to Git, you might want to have a look at some of these documents:

More ideas (to be discussed)