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).

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.

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 [email protected] wnpp Using 'Your Name <[email protected]>' 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...

If your request type is ITP (1) or RFP (5) you are asked for a short description and then for some information about the package:
Please briefly describe this package; this should be an appropriate short description for the eventual package: > A DESCRIPTION Subject: ITP: PACKAGENAME -- A DESCRIPTION Package: wnpp Version: N/A; reported 2002-01-30 Severity: wishlist * Package name : PACKAGENAME Version : x.y.z Upstream Author : Name <[email protected]> * URL : http://www.some.org/ * License : (GPL, LGPL, BSD, MIT/X, etc.) Description : A DESCRIPTION -- System Information ...
Below the Description line you should give more information about the package.
If your request type is O (2) or RFA (3) you have to enter the name of the package.
Choose the request type: x Please enter the name of the package: PACKAGENAME Checking status database... Subject: O: PACKAGENAME -- SHORT DESCRIPTION Package: wnpp Version: N/A; reported 2002-01-30 Severity: normal -- System Information ...
You should add some information about maintaining the package, the upstream situation and maybe a reason why you want to give the package away.

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

Report will be sent to Debian Bug Tracking System <[email protected]> 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: [email protected] 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: [email protected]

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 [email protected].