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 git.debian.org
and gets updated on
push operations thanks to the
The team can be contacted using:
At the moment, some links to the available packages:
Packages are maintained in Git repositories (one per package), hosted on git.debian.org.
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
# To be done on git.d.o, under /git/pkg-phototools/$SOURCE.git git-config --add hooks.mailinglist \ "email@example.com" echo ". /home/groups/pkg-phototools/hooks/post-receive-email" \ >> hooks/post-receive chmod 755 hooks/post-receive
Maintainer: Debian PhotoTools Maintainers <firstname.lastname@example.org> Vcs-Browser: http://git.debian.org/?p=pkg-phototools/$SOURCE.git Vcs-Git: git://git.debian.org/git/pkg-phototools/$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
It seems reasonable to only store
debian/ (that is:
the directory and its content) under Git for each package. Patch
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
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
debian/rules, which does that job
automatically (Developer's Reference 188.8.131.52).
Possible ways of handling branches: work on
unstable, and branch when needed, for example uploads
experimental, or at
Possible tag formats:
$VERSION-$REVISIONfor regular uploads to
$BRANCH/$VERSION-$REVISIONfor other uploads.
$PACKAGE-$VERSION-$REVISION, adding a
$BRANCH/prefix when needed.
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
that other maintainers can see easily what has to be done on a given
Quick summary of possible ways to submit patches:
# Clone a given repository git-clone git://git.debian.org/git/pkg-phototools/$SOURCE.git # Hack hack hack, commit as much as you want git-commit # 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 email@example.com *.patch # B) Push the (local) master branch somewhere online git-remote add alioth ssh://alioth.debian.org/git/users/$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.
If you're new to Git, you might want to have a look at some of these documents:
patchesdirectory on the website, containing
$SOURCE/$BRANCH/*.diff, which would make it very convenient to share patches with upstreams.