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
post-receive hook.
The team can be contacted using:
#pkg-phototools (irc.debian.org)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
activate a post-receive hook:
# To be done on git.d.o, under /git/pkg-phototools/$SOURCE.git
git-config --add hooks.mailinglist \
"pkg-phototools-commits@lists.alioth.debian.org"
echo ". /home/groups/pkg-phototools/hooks/post-receive-email" \
>> hooks/post-receive
chmod 755 hooks/post-receive
debian/controlMaintainer: Debian PhotoTools Maintainers <pkg-phototools-devel@lists.alioth.debian.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
contributors.
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 6.7.8.2).
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:
$VERSION-$REVISION for regular uploads to
unstable, $BRANCH/$VERSION-$REVISION
for 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:
_ instead of : for epochs;-- instead of ~ for tildes.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.
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 pkg-phototools-devel@lists.alioth.debian.org *.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:
patches directory on
the website, containing $SOURCE/$BRANCH/*.diff,
which would make it very convenient to share patches with
upstreams.