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).
- 150 packages up for adoption, organized by maintainer or by age
- 1226 orphaned packages, organized by age
- 56 packages currently being adopted, organized by age or by activity
- 2010 packages being worked on, organized by age or by activity
- 3328 requested packages, organized by age
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.
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.
You can use reportbug (apt-get install reportbug):$ reportbug --email firstname.lastname@example.org wnpp
Using 'Your Name <email@example.com>' 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
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
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
Version: N/A; reported 2002-01-30
* Package name : PACKAGENAME
Version : x.y.z
Upstream Author : Name <firstname.lastname@example.org>
* URL : http://www.some.org/
* License : (GPL, LGPL, BSD, MIT/X, etc.)
Description : A DESCRIPTION
-- System Information
Descriptionline 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
Version: N/A; reported 2002-01-30
-- 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@example.com>
Submit this bug report (e to edit) [Y|n|i|e|?]?
It is also possible to report reports/bugs against the WNPP via email. The format of the submission should be like this:To: firstname.lastname@example.org
Subject: [TAG (see below)]: package name -- short package description
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:
|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.
An example bug report can be found here.
The procedures for closing these bugs are as follows:
|O||If you are going to adopt a package, retitle its bug
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
If you are going to adopt a package, retitle its bug
If you as the package maintainer decide to orphan the package you
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 (
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
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
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@example.com.