<!ENTITY % dynamicdata SYSTEM "dynamic.ent" > %dynamicdata;
<!-- CVS revision of this document -->
- <!ENTITY cvs-rev "$Revision: 1.287 $">
+ <!ENTITY cvs-rev "$Revision: 1.296 $">
<!-- if you are translating this document, please notate the CVS
revision of the original developer's reference in cvs-en-rev -->
<copyright>
<copyrightsummary>
-copyright © 2004—2005 Andreas Barth</copyrightsummary>
+copyright © 2004—2006 Andreas Barth</copyrightsummary>
<copyrightsummary>
copyright © 1998—2003 Adam Di Carlo</copyrightsummary>
<copyrightsummary>
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">
Version 4 (primary) keys can either use the RSA or the DSA algorithms,
so this has nothing to do with GnuPG's question about "which kind
of key do you want: (1) DSA and Elgamal, (2) DSA (sign only), (5)
-RSA (sign only). If you don't have any special requirements just pick
+RSA (sign only)". If you don't have any special requirements just pick
the defailt.
<p>
The easiest way to tell whether an existing key is a v4 key or a v3
</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
<item>
Orphan all your packages, as described in <ref id="orphaning">.
<item>
-Send an email about why you are leaving the project to
+Send an gpg-signed email about why you are leaving the project to
&email-debian-private;.
<item>
Notify the Debian key ring maintainers that you are leaving by
<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.
These are the <manref name="sources.list" section="5"> lines for
<em>experimental</em>:
<example>
-deb http://ftp.<var>xy</var>.debian.org/debian/ ../project/experimental main
-deb-src http://ftp.<var>xy</var>.debian.org/debian/ ../project/experimental main
+deb http://ftp.<var>xy</var>.debian.org/debian/ experimental main
+deb-src http://ftp.<var>xy</var>.debian.org/debian/ experimental main
</example>
<p>
If there is a chance that the software could do grave damage to a system,
<item>
Translations of descriptions or debconf templates
submitted to the Debian Description Translation Project.
+
+ <tag><tt>derivatives</tt>
+ <item>
+Information about changes made to the package in derivative distributions
+(for example Ubuntu).
</taglist>
<sect1 id="pts-commands">The PTS email interface
<p>
You can control your subscription(s) to the PTS by sending
-various commands to <email>pts@qa.debian.org</email>.
+various commands to <email>pts@qa.debian.org</email>.
<taglist>
using the specified email address or the sender address if the second
argument is left out.
+<tag><tt>unsubscribeall [<email>]</tt>
+<item>
+ Removes all subscriptions of the specified email address or the sender
+ address if the second argument is left out.
+
<tag><tt>which [<email>]</tt>
<item>
Lists all subscriptions for the sender or the email address optionally
<item><tt>summary</tt>: automatic summary mails about the state of a package
<item><tt>cvs</tt>: notification of CVS commits
<item><tt>ddtp</tt>: translations of descriptions and debconf templates
+ <item><tt>derivatives</tt>: changes made on the package by derivative distributions
<item><tt>upload-source</tt>: announce of a new source upload that
has been accepted
<item><tt>upload-binary</tt>: announce of a new binary-only upload (porting)
<tag><tt>keyword [<email>] {+|-|=} <list of keywords></tt>
<item>
Accept (+) or refuse (-) mails classified under the given keyword(s).
- Define the list (=) of accepted keywords.
+ Define the list (=) of accepted keywords. This changes the default set
+ of keywords accepted by a user.
+
+<tag><tt>keywordall [<email>] {+|-|=} <list of keywords></tt>
+<item>
+ Accept (+) or refuse (-) mails classified under the given keyword(s).
+ Define the list (=) of accepted keywords. This changes the set of
+ accepted keywords of all the currently active subscriptions of a user.
<tag><tt>keyword <sourcepackage> [<email>] {+|-|=} <list of keywords></tt>
<item>
the bot.
</taglist>
+ <p>
+The <prgn>pts-subscribe</prgn> command-line utility (from the
+<package>devscripts</package> package) can be handy to temporarily
+subscribe to some packages, for example after having made an
+non-maintainer upload.
+
<sect1 id="pts-mail-filtering">Filtering PTS mails
<p>
Once you are subscribed to a package, you will get the mails sent to
tests the <file>postrm</file> and <file>prerm</file> scripts.
<item>
Remove the package, then reinstall it.
+ <item>
+Copy the source package in a different directory and try unpacking it and
+rebuilding it. This tests if the package relies on existing files outside of
+it, or if it relies on permissions being preserved on the files shipped inside
+the .diff.gz file.
</list>
source tar-file used by <prgn>dpkg-source</prgn> when constructing the
<file>.dsc</file> file and diff to be uploaded <em>must</em> be
byte-for-byte identical with the one already in the archive.
+ <p>
+Please notice that, in non-native packages, permissions on files that are not
+present in the .orig.tar.gz will not be preserved, as diff does not store file
+permissions in the patch.
<sect id="distribution">Picking a distribution
approved by the security team, it needs to be uploaded so that it can
be installed in the archives. For security uploads, the place to
upload to is
-<tt>ftp://security.debian.org/pub/SecurityUploadQueue/</tt> .
+<tt>ftp://security-master.debian.org/pub/SecurityUploadQueue/</tt> .
<p>
Once an upload to the security queue has been accepted, the package
get this wrong, the archive maintainers will reject your upload (due
to lack of corresponding source code).
<p>
-The ``magic'' for a recompilation-only NMU is triggered by using the
-third-level number on the Debian part of the version. For instance,
-if the latest version you are recompiling against was version
-``2.9-3'', your NMU should carry a version of ``2.9-3.0.1''. If the
-latest version was ``3.4-2.1'', your NMU should have a version number
-of ``3.4-2.1.1''.
+The ``magic'' for a recompilation-only NMU is triggered by using a
+suffix appended to the package version number,
+following the form b<number>.
+For instance, if the latest version you are
+recompiling against was version ``2.9-3'', your NMU should carry a
+version of ``2.9-3+b1''. If the latest version was ``3.4+b1'' (i.e, a
+native package with a previous recompilation NMU), your NMU should have
+a version number of ``3.4+b2''.
+
+<footnote>
+In the past, such NMUs used the third-level number on the Debian part of
+the revision to denote their recompilation-only status; however, this
+syntax was ambiguous with native packages and did not allow proper
+ordering of recompile-only NMUs, source NMUs, and security NMUs on the
+same package, and has therefore been abandoned in favor of this new
+syntax.</footnote>
<p>
Similar to initial porter uploads, the correct way of invoking
<prgn>dpkg-buildpackage</prgn> is <tt>dpkg-buildpackage -B</tt> to only
Those delays may be doubled during a freeze, or testing transitions may be
switched off altogether;
<item>
-It must have fewer release-critical bugs than the version currently available
+It must have the same number or fewer release-critical bugs than the version currently available
in <em>testing</em>;
<item>
It must be available on all architectures on which it has previously
the package manager (e.g., "this is the client for the foo server")?
<p>
Be careful to avoid spelling and grammar mistakes. Ensure that you
-spell-check it. <prgn>ispell</prgn> has a special <tt>-g</tt> option
-for <file>debian/control</file> files:
+spell-check it. Both <prgn>ispell</prgn> and <prgn>aspell</prgn>
+have special modes for checking <file>debian/control</file> files:
<example>ispell -d american -g debian/control</example>
+<example>aspell -d en -D -c debian/control</example>
<p>
Users usually expect these questions to be answered in the package
description:
tracking system.
<p>
It is an old tradition to acknowledge bugs fixed in non-maintainer
-uploads in the first changelog entry of the proper maintainer upload,
-for instance, in a changelog entry like this:
-<example>
- * Maintainer upload, closes: #42345, #44484, #42444.
-</example>
-This will close the NMU bugs tagged "fixed" when the package makes
-it into the archive. The bug for the fact that an NMU was done can be
-closed the same way. Of course, it's also perfectly acceptable to
-close NMU-fixed bugs by other means; see <ref id="bug-answering">.
+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.
</sect1>
<sect1 id="bpp-changelog-errors">
There are two kinds of original source tarballs: Pristine source
and repackaged upstream source.
</p>
- <sect2 id="pristine source">
+ <sect2 id="pristinesource">
<heading>Pristine source</heading>
<p>
The defining characteristic of a pristine source tarball is that the
</enumlist>
</p>
</sect2>
- <sect2 id="repackaged origtargz">
+ <sect2 id="repackagedorigtargz">
<heading>Repackaged upstream source</heading>
<p>
You <strong>should</strong> upload packages with a pristine source
QA group contacts an inactive maintainer or finds more information about
one, this is recorded in the MIA database. This system is available
in /org/qa.debian.org/mia on the host qa.debian.org, and can be queried
-with a tool known as <prgn>mia-history</prgn>. By default,
-<prgn>mia-history</prgn> shows information about every person it knows
-about, but it accepts regular expressions as arguments which it uses to
-match user names. <example>mia-history --help</example> shows which
-arguments are accepted. If you find that no information has been recorded
+with a tool known as <prgn>mia-query</prgn>.
+Use <example>mia-query --help</example> to see how to query the database.
+If you find that no information has been recorded
about an inactive maintainer already, or that you can add more information,
you should generally proceed as follows.
<p>
non-Debian mailing lists or news groups.
</list>
<p>
-One big problem are packages which were sponsored — the maintainer is not
+A bit of a problem are packages which were sponsored — the maintainer is not
an official Debian developer. The echelon information is not available for
sponsored people, for example, so you need to find and contact the Debian
developer who has actually uploaded the package. Given that they signed the
-package, they're responsible for the upload anyhow, and should know what
+package, they're responsible for the upload anyhow, and are likely to know what
happened to the person they sponsored.
<p>
It is also allowed to post a query to &email-debian-devel;, asking if anyone
is aware of the whereabouts of the missing maintainer.
+Please Cc: the person in question.
<p>
Once you have gathered all of this, you can contact &email-mia;.
People on this alias will use the information you provided in order to
circumstances of the person who is involved. Perhaps they might be
seriously ill or might even had died — you do not know who may be on the
receiving side. Imagine how a relative will feel if they read the e-mail
-of the deceased and find a very impolite, angry and accusing message!)
+of the deceased and find a very impolite, angry and accusing message!
<p>
On the other hand, although we are volunteers, we do have a responsibility.
So you can stress the importance of the greater good — if a maintainer does
not have the time or interest anymore, they should "let go" and give the
package to someone with more time.
+ <p>
+If you are interested in working in the MIA team, please have a look at the
+README file in /org/qa.debian.org/mia on qa.debian.org where the technical
+details and the MIA procedures are documented and contact &email-mia;.
<sect id="newmaint">