<!-- common, language independant entities -->
<!entity % commondata SYSTEM "common.ent" > %commondata;
<!-- CVS revision of this document -->
- <!entity cvs-rev "$Revision: 1.35 $">
+ <!entity cvs-rev "$Revision: 1.37 $">
<!-- if you are translating this document, please notate the RCS
revision of the developers reference here -->
example, any of the following mechanisms would suffice:
<list>
<item>
-An RSA key signed by any well-known signature, such as:
+An OpenPGP key signed by any well-known signature, such as:
<list>
<item>
Any current Debian developer you have met <em>in real life</em>.
Alternatively, you may identify yourself with a scanned (or physically
mailed) copy of any formal documents certifying your identity (such as
a birth certificate, national ID card, U.S. Driver's License, etc.).
-If emailed, please sign the mail with your PGP key.
+If emailed, please sign the mail with your OpenPGP key.
</list>
</list>
<p>
-If you do not have an RSA key yet, generate one. Every developer needs
-a RSA key in order to sign and verify package uploads. You should read
-the PGP manual, since it has much important information which is
-critical to its security. Many more security failures are due to
-human error than to software failure or high-powered spy techniques.
-See <ref id="key-maint"> for more information on maintianing your
-public key.
- <p>
-Debian uses <prgn>pgp</prgn> version 2.6 as its baseline standard.
-You can use <prgn>gpg</prgn> or some other version of <prgn>pgp</prgn>
-if and only if you can create an RSA key compatible with
-<prgn>pgp</prgn> version 2.6. Note that we are also working on the
-ability to use non-RSA keys, since RSA algorithms have patent
-protection, but this is still in early stages.
- <p>
-Your RSA key must be at least 1024 bits long. There is no reason to
-use a smaller key, and doing so would be much less secure. Your key
-must be signed with at least your own user ID. This prevents user ID
-tampering. You can do it by executing <tt>pgp -ks
-<var>your_userid</var></tt>.
+If you do not have an OpenPGP key yet, generate one. Every developer
+needs a OpenPGP key in order to sign and verify package uploads. You
+should read the manual for the software you are using, since it has
+much important information which is critical to its security. Many
+more security failures are due to human error than to software failure
+or high-powered spy techniques. See <ref id="key-maint"> for more
+information on maintianing your public key.
+ <p>
+Debian uses the <prgn>GNU Privacy Guard</prgn> (package
+<package>gnupg</package> version 1 or better as its baseline standard.
+You can use some other implementation of OpenPGP as well. Note that
+OpenPGP is a open standard based on <url id="&url-rfc2440;" name="RFC
+2440">.
+ <p>
+The recommended public key algorithm for use in Debian development
+work is the DSA (sometimes call ``DSS'' or ``DH/ElGamal''). Other key
+types may be used however. Your key length must be at least 1024
+bits; there is no reason to use a smaller key, and doing so would be
+much less secure. Your key must be signed with at least your own user
+ID; this prevents user ID tampering. <prgn>gpg</prgn> does this
+automatically.
<p>
Also remember that one of the names on your key must match the email
address you list as the official maintainer for your packages. For
instance, I set the maintainer of the
<package>developers-reference</package> package to ``Adam Di Carlo
-<aph@debian.org>''; therefore, one of the user IDs on my RSA key
-is that same value, ``Adam Di Carlo <aph@debian.org>''.
+<aph@debian.org>''; therefore, one of the user IDs on my key is
+that same value, ``Adam Di Carlo <aph@debian.org>''.
<p>
-If your RSA key isn't on public key servers such as &pgp-keyserv;,
+If your public key isn't on public key servers such as &pgp-keyserv;,
please read the documentation available locally in &file-keyservs;.
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.
<p>
Due to export restrictions by the United States government some Debian
-packages, including <package>pgp</package>, have been moved to an ftp
-site outside of the United States. You can find the current locations
-of those packages at <url id="&url-readme-non-us;">.
+packages, including <package>gnupg</package>, are located on ftp sites
+outside of the United States. You can find the current locations of
+those packages at <url id="&url-readme-non-us;">.
<p>
Some countries restrict the use of cryptographic software by their
citizens. This need not impede one's activities as a Debian package
&email-new-maintainer; to register as an offical Debian developer so
that you will be able to upload your packages. This message must
contain all the information discussed above. The message must also
-contain your RSA public key (extracted using <tt>pgp -kxa</tt> in the
-case of PGP) for the database of keys which is distributed from <url
-id="url-debian-keyring;">, or the <package>debian-keyring</package>
+contain your public key (extracted using <tt>gpg --armor --export
+<var>user_id</var></tt> in the case of <prgn>gpg</prgn>) for the
+database of keys which is distributed from <url
+id="url-debian-keyring;"> and the <package>debian-keyring</package>
package. Please be sure to sign your request message with your chosen
public key.
<p>
Once this information is received and processed, you should be
contacted with information about your new Debian maintainer account.
-If you don't hear anything within 7-14 days, please send a followup
+If you don't hear anything within a month, please send a followup
message asking if your original application was received. Do
<em>not</em> re-send your original application, that will just confuse
-the new-maintainer team. Please be patient, especially near release
+the New Maintainer Group. Please be patient, especially near release
points; mistakes do occasionally happen, and people do sometimes run
out of volunteer time.
Be very careful with your private keys. Do not place them on any
public servers or multiuser machines, such as
<tt>master.debian.org</tt>. Back your keys up; keep a copy offline.
-Read the documentation that comes with your software (either PGP or
-GNUPG); read the <url id="&url-pgp-faq;" name="PGP FAQ">.
+Read the documentation that comes with your software; read the <url
+id="&url-pgp-faq;" name="PGP FAQ">.
<p>
If you add or remove signatures from your public key, or add or remove
user identities, you need to update the key servers and mail your
<p>
All of these fields are mandatory for a Debian upload. See the list
of control fields in the <url id="&url-pkg-manual;" name="Debian
-Packaging Manual"> for the contents of these fields. Only the
-<tt>Distribution</tt> field is discussed here, since it relates to the
-archive maintenance policies.
+Packaging Manual"> for the contents of these fields. You can close
+bugs automatically using the <tt>Description</tt> field, see <ref
+id="upload-bugfix">. Only the <tt>Distribution</tt> field is
+discussed in this section, since it relates to the archive maintenance
+policies.
<sect1 id="upload-dist">Picking a distribution
command sent to &email-bts-control;. If you do so, the original
submitter will not receive any feedback on why the bug was closed.
- <sect>When bugs are closed by new uploads
+ <sect id="upload-bugfix">When bugs are closed by new uploads
<p>
If you fix a bug in your packages, it is your responsibility as the
package maintainer to close the bug when it has been fixed. However,
notification that your updated package has been installed into the
archive, you can and should close the bug in the BTS.
<p>
-Again, see the BTS documentation for details on how to do this.
-Often, it is sufficient to mail the <tt>.changes</tt> file to
+If you are using a new version of <package>dpkg-dev</package> and you
+do your changelog entry properly, <prgn>dinstall</prgn> will close the
+bugs automatically. All you have to do is follow a certain syntax
+in your <file>debian/changelog</file> file:
+<example>
+acme-cannon (3.1415) unstable; urgency=low
+
+ * Frobbed with options (closes: Bug#98339)
+ * Added safety to prevent operator dismemberment, closes: bug #98765,
+ bug #98713, #98714.
+ * Added manpage. closes: #98725.
+</example>
+
+Technically speaking, the following Perl regular expression is what is
+used:
+<example>
+ /closes:\s*(bug)?\#\d+(,\s*(bug)?\#\d+)*/gi
+</example>
+
+The author prefers the <tt>(closes: Bug#<var>XXX</var>)</tt> syntax,
+since it stands out from the rest of the changelog entries.
+ <p>
+If you want to close bugs the old fashioned, manual way, it is usually
+sufficient to mail the <tt>.changes</tt> file to
<email>XXX-done@bugs.debian.org</email>, where <var>XXX</var> is your
bug number.
~ianmdlvl / developers-reference.git / blobdiff