<!ENTITY % dynamicdata SYSTEM "dynamic.ent" > %dynamicdata;
<!-- CVS revision of this document -->
- <!ENTITY cvs-rev "$Revision: 1.293 $">
+ <!ENTITY cvs-rev "$Revision: 1.302 $">
<!-- if you are translating this document, please notate the CVS
revision of the original developer's reference in cvs-en-rev -->
In addition, if you have some packages ready for inclusion in Debian,
but are waiting for your new maintainer application to go through, you
might be able find a sponsor to upload your package for you. Sponsors
-are people who are official Debian maintainers, and who are willing to
+are people who are official Debian Developers, and who are willing to
criticize and upload your packages for you.
<!-- FIXME - out of order
Those who are seeking a
competent work and will be a good contributor.
You show this by submitting patches through the Bug Tracking System
and having a package
-sponsored by an existing maintainer for a while. Also, we expect that
+sponsored by an existing Debian Developer for a while.
+Also, we expect that
contributors are interested in the whole project and not just in
maintaining their own packages. If you can help other maintainers by
providing further information on a bug or even a patch, then do so!
Registration requires that you are familiar with Debian's philosophy
and technical documentation. Furthermore, you need a GnuPG key which
has been signed by an existing Debian maintainer. If your GnuPG key
-is not signed yet, you should try to meet a Debian maintainer in
+is not signed yet, you should try to meet a Debian Developer in
person to get your key signed. There's a <url id="&url-gpg-coord;"
name="GnuPG Key Signing Coordination page"> which should help you find
-a maintainer close to you.
-(If there is no Debian maintainer close to you,
+a Debian Developer close to you.
+(If there is no Debian Developer close to you,
alternative ways to pass the ID check may be permitted
as an absolute exception on a case-by-case-basis.
See the <url id="&url-newmaint-id;" name="identification page">
</footnote>
<p>
If your public key isn't on public key servers such as &pgp-keyserv;,
-please read the documentation available locally in &file-keyservs;.
+please read the documentation available at
+<url id="&url-newmaint-id;" name="NM Step 2: Identification">.
That document contains instructions on how to put your key on the
public key servers. The New Maintainer Group will put your public key
on the servers if it isn't already there.
cryptography even for authentication is forbidden
then please contact us so we can make special arrangements.
<p>
-To apply as a new maintainer, you need an existing Debian maintainer
-to verify your application (an <em>advocate</em>). After you have
+To apply as a new maintainer, you need an existing Debian Developer
+to support your application (an <em>advocate</em>). After you have
contributed to Debian for a while, and you want to apply to become a
registered developer, an existing developer with whom you
have worked over the past months has to express their belief that you
<sect id="irc-channels">IRC channels
<p>
Several IRC channels are dedicated to Debian's development. They are mainly
-hosted on the <url id="&url-openprojects;" name="freenode"> network
-(previously known as Open Projects Network).
-The <tt>irc.debian.org</tt> DNS entry is an alias to
-<tt>irc.freenode.net</tt>.
+hosted on the <url id="&url-oftc;" name="Open and free technology community
+(OFTC)"> network. The <tt>irc.debian.org</tt> DNS entry is an alias to
+<tt>irc.oftc.net</tt>.
<p>
The main channel for Debian in general is <em>#debian</em>. This is a large,
general-purpose channel where users can find recent news in the topic and
French speaking people interested in Debian's development.
<p>
Channels dedicated to Debian also exist on other IRC networks, notably on
-the <url name="Open and free technology community (OFTC)"
-id="http://www.oftc.net/"> IRC network.
+the <url id="&url-openprojects;" name="freenode"> IRC network, which was
+pointed at by the <tt>irc.debian.org</tt> alias until 4th June 2006.
<p>
To get a cloak on freenode, you send Jörg Jaspert <joerg@debian.org>
a signed mail where you tell what your nick is.
Delayed uploads are done for the moment via the delayed queue at
gluck. The upload-directory is
<ftpsite>gluck:~tfheen/DELAYED/[012345678]-day</ftpsite>.
-0-day is uploaded approximately one hour before dinstall runs.
+0-day is uploaded multiple times per day to ftp-master.
<p>
With a fairly recent dput, this section
<example>
<sect1>Security uploads
<p>
-Do NOT upload a package to the security upload queue (oldstable-security,
+Do <strong>NOT</strong> upload a package to the security upload queue
+(oldstable-security,
stable-security, etc.) without prior authorization from the security
team. If the package does not exactly meet the team's requirements, it
will cause many problems and delays in dealing with the unwanted upload.
been accepted into the Debian archive. Therefore, once you get
notification that your updated package has been installed into the
archive, you can and should close the bug in the BTS.
+Also, the bug should be closed with the correct version.
<p>
However, it's possible to avoid having to manually close bugs after the
upload — just list the fixed bugs in your <file>debian/changelog</file>
We prefer the <tt>closes: #<var>XXX</var></tt> syntax, as it is the
most concise entry and the easiest to integrate with the text of the
<file>changelog</file>.
- <p>
-If an upload is identified as <qref id="nmu">Non-maintainer upload (NMU)</qref>
-(and that is the case if the name of the person who commits this change
-is not exactly the same as any one of Maintainer or Uploader,
-except if the maintainer is the qa group),
-than the bug is only tagged <tt>fixed</tt> instead of being closed.
-If a maintainer upload is targetted to experimental,
-than the tag <tt>fixed-in-experimental</tt> is added to the bug;
-for NMUs, the tag <tt>fixed</tt> is used.
-(The special rule for experimental is expected to change
-as soon as version-tracking is added to the bug tracking system.)
+Unless specified different by the <var>-v</var>-switch to
+<prgn>dpkg-buildpackage</prgn>, only the bugs closed in the
+most recent changelog entry are closed (basically, exactly
+the bugs mentioned in the changelog-part
+in the <file>.changes</file> file are closed).
+ <p>
+Historically, uploads identified as
+<qref id="nmu">Non-maintainer upload (NMU)</qref>
+were tagged <tt>fixed</tt> instead of being closed,
+but that practice was ceased with the advent of version-tracking.
+The same applied to the tag <tt>fixed-in-experimental</tt>.
<p>
If you happen to mistype a bug number or forget a bug in the changelog
entries, don't hesitate to undo any damage the error caused. To reopen
the bug tracking system's control address, &email-bts-control;. To
close any remaining bugs that were fixed by your upload, email the
<file>.changes</file> file to <email>XXX-done@&bugs-host;</email>,
-where <var>XXX</var> is your bug number.
+where <var>XXX</var> is your bug number, and
+put "Version: XXX" and an empty line as the first two lines
+of the body of the email
+to mark the first version where this bug has been closed.
<p>
Bear in mind that it is not obligatory to close bugs using the
changelog as described above. If you simply want to close bugs that
removed automatically after the package has been removed from
<em>unstable</em> and no package in <em>testing</em> depends on it.
<p>
+If you are simply restructuring a source package so that it no longer
+produces one or more binary packages, there is no need to explicitly ask
+for the packages that are no longer created to be removed. Such packages
+will be removed when the new package structure has been uploaded into
+<em>unstable</em> and when no package in <em>testing</em> depends on it.
+ <p>
You also have to detail the reasons justifying that request. This is to
avoid unwanted removals and to keep a trace of why a package has been
removed. For example, you can provide the name of the package that
package. When invoked as <tt>apt-cache showpkg
<var>package</var></tt>, the program will show details for
<var>package</var>, including reverse depends.
+Other useful programs include
+<tt>apt-cache rdepends</tt>,
+<prgn>apt-rdepends</prgn> and
+<prgn>grep-dctrl>.
Removal of orphaned packages is discussed on &email-debian-qa;.
<p>
Once the package has been removed, the package's bugs should be handled.
to the Bug Tracking System. Maintainers almost always appreciate
quality patches and bug reports.
- <sect1 id="nmu-katie">How dak detects NMUs
- <p>
-Whether an upload is treated as an NMU or as a maintainer upload by
-the archive scripts and the bugtracking system (see <ref
-id="nmu-patch">) is <em>not</em> decided by looking at the version
-number (see <ref id="nmu-version">). Instead, an upload is handled as
-an NMU if the maintainer address in the <tt>.changes</tt> file is not
-binary the same as the address in the <tt>Maintainer</tt> field, or
-any of the addresses the <tt>Uploaders</tt> field, of the <tt>dsc</tt>
-file, and also if the maintainer address is not special (i.e. it is
-not set to the QA Group address).
-
<sect1 id="nmu-terms">Terminology
<p>
There are two new terms used throughout this section: ``binary-only NMU''
<p>
Sometimes, a package is removed to allow another package in: This happens
only to allow <em>another</em> package to go in if it's ready in every other
-sense. Suppose e.g. that <em>a</em> conflicts with the new version of
+sense. Suppose e.g. that <em>a</em> cannot be installed with the new version of
<em>b</em>; then <em>a</em> may be removed to allow <em>b</em> in.
<p>
Of course, there is another reason to remove a package from testing: It's
just too buggy (and having a single RC-bug is enough to be in this state).
+ <p>
+Furthermore, if a package has been removed from unstable,
+and no package in testing depends on it any more,
+then it will automatically be removed.
+
<sect2 id="circular">
<heading>circular dependencies</heading>
<p>
It is an old tradition to acknowledge bugs fixed in non-maintainer
uploads in the first changelog entry of the proper maintainer upload.
-Please use the option <tt>-v</tt> to <prgn>dpkg-buildpackage</prgn>
-to close the relevant bug report.
+As we have version tracking now,
+it is enough to keep the NMUed changelog entries and
+just mention this fact in your own changelog entry.
</sect1>
<sect1 id="bpp-changelog-errors">
<sect3>boolean:
<p>
-A true/false choice. Remember: true/false, NOT YES/NO...
+A true/false choice. Remember: true/false, <strong>not yes/no</strong>...
<sect3>select:
<p>
<sect3>String/password templates
<p>
<list>
-<item> The short description is a prompt and NOT a title. Avoid
+<item> The short description is a prompt and <strong>not</strong> a title. Avoid
question style prompts ("IP Address?") in favour of
"opened" prompts ("IP address:").
The use of colons is recommended.
question is rather long (remember that translations are often longer
than original versions)
-<item> The extended description should NOT include a question.
+<item> The extended description should <strong>not</strong> include a question.
<item> Again, please avoid referring to specific interface widgets. A common
mistake for such templates is "if you answer Yes"-type
<sect3>Select/Multiselect
<p>
<list>
-<item> The short description is a prompt and NOT a title. Do NOT use useless
+<item> The short description is a prompt and <strong>not</strong> a title.
+ Do <strong>not</strong> use useless
"Please choose..." constructions. Users are clever enough to figure
out they have to choose something...:)
<item> The extended description is what will be displayed as a more detailed
explanation of the note. Phrases, no terse writing style.
-<item> DO NOT ABUSE DEBCONF. Notes are the most common way to abuse
+<item> <strong>Do not abuse debconf.</strong>
+ Notes are the most common way to abuse
debconf. As written in debconf-devel manual page: it's best to use them
only for warning about very serious problems. The NEWS.Debian or
README.Debian files are the appropriate location for a lot of notes.
Do NOT use empty default field. If you don't want to use default
values, do not use Default at all.
<p>
-If you use po-debconf (and you SHOULD, see 2.2), consider making this
+If you use po-debconf (and you <strong>should</strong>, see 2.2), consider making this
field translatable, if you think it may be translated.
<p>
If the default value may vary depending on language/country (for
It unpacks the tarball in an empty temporary directory by doing
<example>
-zcat path/to/<packagename>_<upstream-version>.orig.tar.gz | tar xf - +</example>
+zcat path/to/<packagename>_<upstream-version>.orig.tar.gz | tar xf -
+</example>
</item>
<item>
If, after this, the temporary directory contains nothing but one
<strong>should</strong> use
<tt><packagename>-<upstream-version>.orig</tt> as the name
of the top-level directory in its tarball. This makes it possible to
-distinguish pristine tarballs from repackaged ones. + </item>
+distinguish pristine tarballs from repackaged ones.
+ </item>
<item>
<strong>should</strong> be gzipped with maximal compression.
</item>