Work-Needing and Prospective Packages

Work-Needing and Prospective Packages, WNPP for short, is a list of packages in need of new maintainers and prospective packages in Debian. In order to closely track the real status of such things, WNPP is currently operated as a pseudo-package in the Debian Bug Tracking System (BTS).


Packages in need of a new maintainer:

56 packages in need of help, organized by age or by popularity

Prospective packages:

Note: these lists are updated six times a day; for more up-to-date information please check the wnpp pseudo package entry in the BTS.

You can search the above information by package, description or type on the WNPP search website.

You can browse the above information broken down into various categories (based on debtags) on the WNPP-by-tags website.


Using WNPP

Since it uses the BTS, every developer is already familiar with the technical details, such as submission of new information, modification of information or closing of pending requests. On the other hand, in order to achieve the highest level of automatization, some procedures have to be observed.

In order to submit new information, a bug has to be filed against the wnpp pseudo package for each (prospective) package that is affected. Please note that you should only submit one bug per source package rather than one bug for each binary package built from a source package.

Adding new entries with reportbug

You can use reportbug (apt-get install reportbug):

$ reportbug --email username@domain.tld wnpp
Using 'Your Name <username@domain.tld>' as your from address.
Getting status for wnpp...
Querying Debian bug tracking system for reports on wnpp
(Use ? for help at prompts.)
...

You will see a list of reported bugs against WNPP which you should read to prevent a second report for the same package.

After the buglist you are asked for the request type:

What sort of request is this?

1 ITP This is an Intent To Package. Please submit a package description
along with copyright and URL in such a report.

2 O The package has been Orphaned. It needs a new maintainer as soon
as possible.

3 RFA This is a Request for Adoption. Due to lack of time, resources,
interest or something similar, the current maintainer is asking for
someone else to maintain this package. They will maintain it in
the meantime, but perhaps not in the best possible way. In short:
the package needs a new maintainer.

4 RFH This is a Request For Help. The current maintainer wants to continue
to maintain this package, but he/she needs some help to do this, because
his/her time is limited or the package is quite big and needs several
maintainers.

5 RFP This is a Request For Package. You have found an interesting piece
of software and would like someone else to maintain it for Debian.
Please submit a package description along with copyright and URL in
such a report.

Choose the request type:

After your selection you will be asked for the package name:

Choose the request type: x
Please enter the proposed package name: PACKAGENAME
Checking status database...

Then you are asked if you want to send your request:

Report will be sent to Debian Bug Tracking System <submit@bugs.debian.org>
Submit this bug report (e to edit) [Y|n|i|e|?]?

Adding new entries via email

It is also possible to report reports/bugs against the WNPP via email. The format of the submission should be like this:

To: submit@bugs.debian.org
Subject: [TAG (see below)]: package name -- short package description

Package: wnpp
Severity: [SEVERITY (see below)]

Some information about the package. (If this is an ITP or RFP a URL where the package (either the .deb or the original source) can be downloaded from is required, as well as information concerning its license.)

The tags to be used and their corresponding severities are:

TAG SEVERITY EXPLANATION
O normal The package has been Orphaned. It needs a new maintainer as soon as possible. If the package has a Priority higher or equal to standard, the severity should be set to important.
RFA normal This is a Request for Adoption. Due to lack of time, resources, interest or something similar, the current maintainer is asking for someone else to maintain this package. They will maintain it in the meantime, but perhaps not in the best possible way. In short: the package needs a new maintainer.
RFH normal This is a Request For Help. The current maintainer wants to continue to maintain this package, but they need some help to do this, because their time is limited or the package is quite big and needs several maintainers.
ITP wishlist This is an Intent To Package. Please submit a package description along with copyright and URL in such a report.
RFP wishlist This is a Request For Package. Someone has found an interesting piece of software and would like someone else to maintain it for Debian. Please submit a package description along with copyright and URL in such a report.
ITA normal This is an Intent To Adopt. It indicates that the bug submitter or bug owner intends to become the package maintainer of an orphaned package or package given up for adoption. You should not directly submit a report with this tag. ITA reports/bugs should be converted from RFA or O reports instead. See the procedure for RFA and O bugs below.

An example bug report can be found here.

Removing entries

The procedures for closing these bugs are as follows:

O If you are going to adopt a package, retitle its bug to replace O with ITA, in order for other people to know the package is being adopted and to prevent its automatic removal from the archive, and set yourself as the owner of the bug. To actually adopt the package, upload it with your name in its Maintainer: field, and put something like * New maintainer (Closes: #bugnumber) in the changelog of the package in order to automatically close this bug once the package has been installed; where bugnumber has to be replaced with the corresponding bugreport number. Furthermore, before you actually upload a new package with you as the maintainer, you should check if there is a new upstream release and you should try to fix the outstanding bugs.
RFA

If you are going to adopt a package, retitle its bug to replace RFA with ITA, in order for other people to know the package is being adopted and to prevent its automatic removal from the archive, and set yourself as the owner of the bug. To actually adopt the package, upload it with your name in its Maintainer: field, and close this bug once the package has been installed.

If you as the package maintainer decide to orphan the package you marked with RFA, please retitle the bug report and replace RFA with O. If you withdraw your request, please close the bug.

RFH

Normally this bug should only closed by the submitter, i.e. the package maintainer, if they consider it obsolete, either because one or more people have offered (and provided) their support or because they now think that they can handle the package for themself.

If you as the package maintainer decides to change the RFH to a request for adoption (RFA) or if you want to orphan the package (O), please retitle the bug instead of closing it and filing a new one.

ITP

package the software, upload it and close this bug once the package has been installed.

If you change your mind, and no longer want to package this, either close the bug or retitle and reclassify it as RFP, as you see fit.

If you encounter problems with packaging the program (for example it depends on another, not-yet-packaged program which you don't have time to package), you might want to record these problems as additional information in the ITP, so that it is clear what's going on with your packaging efforts.

RFP If you are going to package this, retitle the bug report to replace RFP with ITP, in order for other people to know the program is already being packaged, and set yourself as the owner of the bug. Then package the software, upload it and close this bug once the package has been installed.

If you feel that the developers' mailing list should know about your ITP, RFA or anything else, add the header

X-Debbugs-CC: debian-devel@lists.debian.org

to the message.

Of course, the easiest way of closing these bugs is to include an entry in the package changelog saying what you've done and append (closes: bug#nnnnn) to it. This way the bug will be closed automatically after the new package gets installed into the archive.

Attention: if you need to reassign, retitle, or set the owner of bug reports, you must do so by emailing the BTS control bot directly or by emailing the report number @bugs.debian.org and using Control pseudo-headers, but not by filing new reports.

Note: if a package remains orphaned for a very long time, we will examine the situation to determine if the package is needed anymore — if not, the FTP maintainers will be asked to remove the package from unstable.

If for some reason you need to contact the WNPP maintainers, they can be reached at wnpp@debian.org.