alioth patch tracker and task manager enabled
Guillem and I have enabled the patch tracker for Alioth's pkg-hurd
project. This means that we now have a centralized place to collect
porting patches for other packages. Likewise, we have enabled the task
manager, which will hopefully cut down on duplicated work as people can
see whether somebody is already working on a package.
The patch tracker and the task manager are located at
It is highly recommended that you get an Alioth account. Debian
Developers have such an account automatically, others can easily create
one which will be prepended by 'guest-'.
In order to make it easy to browse through patches and keep track of
them, please follow some simple guidelines when submitting them:
1. The Summary should contain the name of the package. If there is a
Debian bug associated with the patch already, the bug number should
be prepended. If the patch is for something else than a build fix, a
short description of it should be added as well.
#285857: dpkg-shlibdeps /usr -> . support
If you submit an already registered patch to the Debain BTS, the
summary should be updated with the bug number, once available.
2. Patches have a 'Category' and a 'Group'.
'Category' is the type of build failure:
- 'build-env' are for general build environment problems like faulty
configure.in files or totally missing gnu support for
- 'debian' is for debian specific problems, like wrong Build-Depends
or required special-casing of things in debian/rules.
- 'posix' is for code problems like PATH_MAX or MAXHOSTNAMELEN.
- 'linuxism' is for code assuming the only system running on top of
glibc is GNU/Linux, or code using Linux syscalls or other
Linux-specific stuff without checking.
- 'several' if more than one of the above is covered in the patch. It
might be more appropriate to split up your patch in this case.
- 'other' if none of the above fit.
'Group' is for the status of the patch (we couldn't choose the field
name, sorry). Possible values are:
- 'unreviewed' - Use this if you submit a patch for the first time
which has not been looked at.
- 'needs-work' - The patch is either not functional yet or not
perfect and needs revising.
- 'unsubmitted' - The patch has been positively reviewed but not
submitted to the BTS or upstream yet.
- 'submitted' - The patch has been submitted.
- 'fixed-debian'/'fixed-upstream'/'fixed' - The patch has been
included in the debian package or in an upstream release, or in
Further categories and groups can be added as needed, your comments
If you submit a new patch, you should try to classify it as good as
possible and set it to 'unreviewed' if nothing else happened earlier,
like in case you salvaged the patch from the BTS.
3. As Detailed Description, you should add a pseudo-header in a
debian/control style format, including at least the following
- 'Author:' The person who initially wrote the patch.
- 'Source:' The Debian source package name. You can find that out by
running 'apt-cache showsrc <package> | grep Package'.
- 'Strip-Level:' which strip level has to be passed to the patch
utilty in order to successfully apply the patch (e.g. '-p0' or
'-p2'). If your patch is targetted to be put under debian/patches,
put the proposed filename here, like
- 'Status:' Mostly the group from above, but you can be a bit more
verbose here. E.g., add the bug number in paranthesis for
'submitted', or shortly specify what works still needs to be done
for 'needs-work'. Also, you can put more than one here, like
Status: Applied in #102991, dropped subsequently
Status: submitted(#281870), needs-work
Status: submitted(#218624), needs-work (NCARGS)
- 'Categories:' The same as the Categories field, but you should
specify all applicable categories here in case your patch is in
'several', or clarify if you put it into 'other'.
You can add further comments in free-form after this pseudo-header.
Exampless for Detailed Descriptions:
Author: Guillem Jover <firstname.lastname@example.org>
Status: submitted(#218624), needs-work (NCARGS)
Categories: posix, linuxism
Author: Munteanu Alexandru <email@example.com>
Author: Samuel Thibault <firstname.lastname@example.org>
Status: submitted(#285857), needs-testing
4. Add your patch with a meaningful description (its filename suffices).
I hope this was not too confusing, just look at the patches which are
already there to see how it should be done.
Some other notes for working with patches:
6. If the state of a patch changes, please copy the whole pseudo-header
in a new comment, modifying the changed bit (and possibly adding an
explanation). See the krb4 patch for an example.
7. If you have a task manager item for that particular package you
should build a task relation between the task and the patch by
following that link.
8. If you review somebody else's patch, just add a comment laying out
what should be changed, or set the patch from 'reviewed' to
'unsubmitted' or whatever is appropriate along with your positive
The patch tracker is meant as a tool, so longer discussions about
particular patches are probably easier to have on a proper mailing list.
Also, debian-hurd will get notifications about new or changed patches,
so people can take a look at them and review them. We can change that to
another list if it turns out to be too annoying or somebody objects.
At the end, I'd like to thank everybody who made this patch tracker
necessary in the first place :) It's great to see people interested in
porting packages to GNU/Hurd. Keep up the good work!