<!ENTITY % dynamicdata SYSTEM "dynamic.ent" > %dynamicdata;
<!-- CVS revision of this document -->
- <!ENTITY cvs-rev "$Revision: 1.259 $">
+ <!ENTITY cvs-rev "$Revision: 1.292 $">
<!-- 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>
<p>
If you want to print this reference, you should use the <url
id="developers-reference.pdf" name="pdf version">.
+This page is also available in <url id="index.fr.html" name="French">.
]]>
<toc detail="sect1">
get started. Finally, if you are interested in documentation or
Quality Assurance (QA) work you can join maintainers already working on
these tasks and submit patches and improvements.
+
+
+ <sect id="mentors">Debian mentors and sponsors
+ <p>
+The mailing list &email-debian-mentors; has been set up for novice
+maintainers who seek help with initial packaging and other
+developer-related issues. Every new developer is invited to subscribe
+to that list (see <ref id="mailing-lists"> for details).
+ <p>
+Those who prefer one-on-one help (e.g., via private email) should also
+post to that list and an experienced developer will volunteer to help.
+ <p>
+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
+criticize and upload your packages for you.
+<!-- FIXME - out of order
+Those who are seeking a
+sponsor can request one at <url id="&url-sponsors;">.
+-->
+Please read the
+unofficial debian-mentors FAQ at <url id="&url-mentors;"> first.
+ <p>
+If you wish to be a mentor and/or sponsor, more information is
+available in <ref id="newmaint">.
<sect id="registering">Registering as a Debian developer
accounts on our servers and let them upload packages.
<p>
Before you actually register you should have shown that you can do
-competent work and will be a good contributor. You can show this by
-submitting patches through the Bug Tracking System or having a package
+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
contributors are interested in the whole project and not just in
maintaining their own packages. If you can help other maintainers by
is not signed yet, you should try to meet a Debian maintainer 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 you cannot find a Debian maintainer
-close to you, there may be alternative ways to pass the ID check.
+a maintainer close to you.
+(If there is no Debian maintainer 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">
for more informations.)
OpenPGP is an open standard based on <url id="&url-rfc2440;" name="RFC
2440">.
<p>
-You need a type 4 key for use in Debian Development.
+You need a version 4 key for use in Debian Development.
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 your own user
-ID; this prevents user ID tampering. <prgn>gpg</prgn> does this
-automatically.
+much less secure.
+<footnote>Version 4 keys are keys conforming to
+the OpenPGP standard as defined in RFC 2440. Version 4 is the key
+type that has always been created when using GnuPG. PGP versions
+since 5.x also could create v4 keys, the other choice having beein
+pgp 2.6.x compatible v3 keys (also called "legacy RSA" by PGP).
+<p>
+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
+the defailt.
+<p>
+The easiest way to tell whether an existing key is a v4 key or a v3
+(or v2) key is to look at the fingerprint:
+Fingerprints of version 4 keys are the SHA-1 hash of some key matieral,
+so they are 40 hex digits, usually grouped in blocks of 4. Fingerprints
+of older key format versions used MD5 and are generally shown in blocks
+of 2 hex digits. For example if your fingerprint looks like
+<tt>5B00 C96D 5D54 AEE1 206B AF84 DE7A AF6E 94C0 9C7F</tt>
+then it's a v4 key.
+<p>
+Another possibility is to pipe the key into <prgn>pgpdump</prgn>,
+which will say something like "Public Key Packet - Ver 4".
+<p>
+Also note that your key must be self-signed (i.e. it has to sign
+all its own user IDs; this prevents user ID tampering). All
+modern OpenPGP software does that automatically, but if you
+have an older key you may have to manually add those signatures.
+</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;.
citizens. This need not impede one's activities as a Debian package
maintainer however, as it may be perfectly legal to use cryptographic
products for authentication, rather than encryption purposes.
-&debian-formal; does not require the use of cryptography <em>qua</em>
-cryptography in any manner. If you live in a country where use of
+If you live in a country where use of
cryptography even for authentication is forbidden
then please contact us so we can make special arrangements.
<p>
a lot of time later on.
- <sect id="mentors">Debian mentors and sponsors
- <p>
-The mailing list &email-debian-mentors; has been set up for novice
-maintainers who seek help with initial packaging and other
-developer-related issues. Every new developer is invited to subscribe
-to that list (see <ref id="mailing-lists"> for details).
- <p>
-Those who prefer one-on-one help (e.g., via private email) should also
-post to that list and an experienced developer will volunteer to help.
- <p>
-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
-criticize and upload your packages for you.
-<!-- FIXME - out of order
-Those who are seeking a
-sponsor can request one at <url id="&url-sponsors;">.
--->
-Please read the
-inofficial debian-mentors FAQ at <url id="&url-mentors;"> first.
- <p>
-If you wish to be a mentor and/or sponsor, more information is
-available in <ref id="newmaint">.
-
-
<chapt id="developer-duties">Debian Developer's Duties
<sect id="user-maint">Maintaining your Debian information
<tt>&keyserver-host;</tt>.
<p>
If you need to add a completely new key or remove an old key, you need
-to get the new key signed by another developer. After this, a mail
-signed by another developer listing your account name, the keyids
-of the old and of the new key and the reason should be send to
-&email-debian-keyring;. If the old key is compromised or invalid, you
+to get the new key signed by another developer.
+If the old key is compromised or invalid, you
also have to add the revocation certificate. If there is no real
-reason for a new key, the Keyring Maintainers will only accept it if
-it's more secure and connected to the old key.
+reason for a new key, the Keyring Maintainers might reject the new key.
+Details can be found at
+<url id="http://keyring.debian.org/replacing_keys.html">.
<p>
The same key extraction routines discussed in <ref id="registering">
apply.
<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
all the files.
<p>
There are other additional channels dedicated to specific subjects.
-<em>#debian-bugs</em> is used for coordinating bug squash parties.
+<em>#debian-bugs</em> is used for coordinating bug squashing parties.
<em>#debian-boot</em> is used to coordinate the work on the debian-installer.
<em>#debian-doc</em> is
occasionally used to talk about documentation, like the document you are
the <url name="Open and free technology community (OFTC)"
id="http://www.oftc.net/"> IRC network.
<p>
-To get a cloak on freenode, you send Göran Weinholt <weinholt@debian.org>
+To get a cloak on freenode, you send Jörg Jaspert <joerg@debian.org>
a signed mail where you tell what your nick is.
Put "cloak" somewhere in the Subject: header.
The nick should be registered:
<sect1 id="servers-non-us">The non-US server
<p>
-The non-US server, <tt>non-us.debian.org</tt>,
-holds the canonical copy of the non-US part of the Debian archive.
-If you need to upload a package into one of the non-US sections, upload it
-to this server; see <ref id="upload-non-us">.
- <p>
-Problems with the non-US package archive should generally be submitted as
-bugs against the <package>nonus.debian.org</package> pseudo-package (notice
-the lack of hyphen between "non" and "us" in the pseudo-package name
-— that's for backwards compatibility). Remember to check whether or
-not someone else has already reported the problem to the
-<url id="http://&bugs-host;/nonus.debian.org" name="Bug Tracking System">.
+The non-US server <tt>non-us.debian.org</tt>
+was discontinued with the release of sarge. The pseudo-package
+<package>nonus.debian.org</package>
+stil exists for now.
<sect1 id="servers-www">The www-master server
<p>
<p>
Usually the only reason to use a different host is when you need to publish
materials subject to the U.S. export restrictions, in which case you can use
-one of the other servers located outside the United States, such as the
-aforementioned <tt>non-us.debian.org</tt>.
+one of the other servers located outside the United States.
<p>
Send mail to &email-debian-devel; if you have any questions.
tightened. Packages which are too buggy are removed. No changes are
allowed into <em>testing</em> except for bug fixes. After some time
has elapsed, depending on progress, the <em>testing</em> distribution
-goes into a `deep freeze', when no changes are made to it except those
-needed for the installation system. This is called a “test cycle”,
-and it can last up to two weeks. There can be several test cycles,
-until the distribution is prepared for release, as decided by the
-release manager. At the end of the last test cycle, the
-<em>testing</em> distribution is renamed to <em>stable</em>,
-overriding the old <em>stable</em> distribution, which is removed at
-that time (although it can be found at <tt>&archive-host;</tt>).
+is frozen even further.
+Details of the handling of the testing distribution are published
+by the Release Team on debian-devel-announce.
+After the open issues are solved to the satisfaction of the Release Team,
+the distribution is released.
+Releasing means
+that <em>testing</em> is renamed to <em>stable</em>,
+and a new copy is created for the new <em>testing</em>,
+and the previous <em>stable</em> is renamed to <em>oldstable</em>
+and stays there until it is finally archived.
+On archiving, the contents are moved to <tt>&archive-host;</tt>).
<p>
This development cycle is based on the assumption that the
<em>unstable</em> distribution becomes <em>stable</em> after passing a
stable distribution is incremented (e.g., ‘3.0’ becomes
‘3.0r1’, ‘2.2r4’ becomes ‘2.2r5’, and
so forth).
+Please refer to
+<qref id="upload-stable">uploads to the <em>stable</em> distribution</qref>
+for details.
<p>
Note that development under <em>unstable</em> continues during the
freeze period, since the <em>unstable</em> distribution remains in
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,
<p>
Every released Debian distribution has a <em>code name</em>: Debian
1.1 is called `buzz'; Debian 1.2, `rex'; Debian 1.3, `bo'; Debian 2.0,
-`hamm'; Debian 2.1, `slink'; Debian 2.2, `potato'; and Debian 3.0, `woody'. There is also
-a ``pseudo-distribution'', called `sid', which is the current
+`hamm'; Debian 2.1, `slink'; Debian 2.2, `potato'; Debian 3.0, `woody';
+Debian 3.1, "sarge";
+Debian (number needs to be determined), "etch".
+There is also a ``pseudo-distribution'', called `sid', which is the current
`unstable' distribution; since packages are moved from `unstable' to
`testing' as they approach stability, `sid' itself is never released.
As well as the usual contents of a Debian distribution, `sid' contains
<p>
The Incoming system is responsible for collecting updated packages and
installing them in the Debian archive. It consists of a set of
-directories and scripts that are installed both on <tt>&ftp-master-host;</tt>
-and <tt>&non-us-host;</tt>.
+directories and scripts that are installed on <tt>&ftp-master-host;</tt>.
<p>
Packages are uploaded by all the maintainers into a directory called
<file>UploadQueue</file>.
<sect1 id="madison">The <prgn>madison</prgn> utility
<p>
<prgn>madison</prgn> is a command-line utility that is available
-on both <tt>&ftp-master-host;</tt> and <tt>&non-us-host;</tt>, and on
+on <tt>&ftp-master-host;</tt>, and on
the mirror on <tt>&ftp-master-mirror;</tt>. It
uses a single argument corresponding to a package name. In result
it displays which version of the package is available for each
<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
</example>
<p>
Think twice before adding a news item to the PTS because you won't be able
-to remove it later and you wan't be able to edit it either. The only thing
+to remove it later and you won't be able to edit it either. The only thing
that you can do is send a second news item that will deprecate the
information contained in the previous one.
started by Debian, and help projects whose goals are the promotion of Debian
or its derivatives.
<p>
+All Debian developers automatically have an account on Alioth.
+They can activate it by using the recover password facility.
+External developers can request guest accounts on Alioth.
+ <p>
For more information please visit <url id="&url-alioth;">.
+ <sect id="developer-misc">Goodies for Developers
+ <p>
+ <sect1 id="lwn">LWN Subscriptions
+ <p>
+Since October of 2002, HP has sponsored a subscription to LWN for all
+interested Debian developers.
+
+Details on how to get access to this benefit are in
+<url id="http://lists.debian.org/debian-devel-announce/2002/10/msg00018.html">.
+
+
<chapt id="pkgs">Managing Packages
<p>
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
archive maintenance software will parse the changes file and see that not
all files have been uploaded.
<p>
-<!-- FIXME: is this still topical? Explain the rationale? -->
-<em>Note:</em> Do not upload to <tt>ftp-master</tt> cryptographic
-packages which belong to <em>contrib</em> or <em>non-free</em>. Uploads of
-such software should go to <tt>non-us</tt> (see <ref
-id="upload-non-us">). Furthermore packages containing code that is
-patent-restricted by the United States government cannot be uploaded to
-<tt>ftp-master</tt>; depending on the case they may still be uploaded to
-<file>non-US/non-free</file> (it's in non-free because of distribution issues
-and not because of the license of the software). If you can't upload it to
-<tt>ftp-master</tt>, then neither can you upload it to backup
-queues that finally also end up on <tt>ftp-master</tt>. If you are not sure
-whether U.S. patent controls or cryptographic controls apply to your
-package, post a message to &email-debian-devel; and ask.
- <p>
You may also find the Debian packages <ref id="dupload"> or
<ref id="dput"> useful
when uploading packages. These handy programs help automate the
<sect1 id="upload-non-us">Uploading to <tt>non-US</tt>
<p>
-<em>Note:</em> non-us is currently not processed any more.
- <p>
-As discussed above, export controlled software should not be uploaded
-to <tt>ftp-master</tt>. Instead, upload the package with anonymous FTP
-to <ftpsite>non-us.debian.org</ftpsite>, placing the files in
-&upload-queue; (again, both <ref id="dupload"> and <ref
-id="dput"> can do this for you if invoked properly).
- <p>
-Note that U.S. residents or citizens are subject to restrictions on
-export of cryptographic software. As of this writing, U.S. citizens
-are allowed to export some cryptographic software, subject to
-notification rules by the U.S. Department of Commerce. However, this
-restriction has been waived for software which is already available
-outside the U.S. Therefore, any cryptographic software which belongs
-in the <em>main</em> section of the Debian archive and does not depend
-on any package outside of <em>main</em> (e.g., does not depend on
-anything in <em>non-US/main</em>) can be uploaded to <tt>ftp-master</tt>
-or its queues, described above.
- <p>
-Debian policy does not prevent upload to non-US by U.S. residents or
-citizens, but care should be taken in doing so. It is recommended that
-developers take all necessary steps to ensure that they are not
-breaking current US law by doing an upload to non-US, <em>including
-consulting a lawyer</em>.
- <p>
-For packages in <em>non-US/main</em>, <em>non-US/contrib</em>,
-developers should at least follow the <url id="&url-u.s.-export;"
-name="procedure outlined by the US Government">. Maintainers of
-<em>non-US/non-free</em> packages should further consult the <url
-id="&url-notification-of-export;" name="rules on notification of
-export"> of non-free software.
- <p>
-This section is for information only and does not constitute legal
-advice. Again, it is strongly recommended that U.S. citizens and
-residents consult a lawyer before doing uploads to non-US.
+<em>Note:</em> non-us was discontinued with release of sarge.
<sect1 id="delayed-incoming">Delayed uploads
<sect1>Other upload queues
<p>
-The scp queues on ftp-master, non-us, and security are mostly unusable
+The scp queues on ftp-master, and security are mostly unusable
due to the login restrictions on those hosts.
<p>
The anonymous queues on ftp.uni-erlangen.de and ftp.uk.debian.org are
priority to the new one. Be sure to explain your reasoning.
<p>
For more information about <em>override files</em>, see <manref
-name="dpkg-scanpackages" section="8"> and
+name="dpkg-scanpackages" section="1"> and
<url id="&url-bts-devel;#maintincorrect">.
<p>
Note that the <tt>Section</tt> field describes both the section as
the bug to the right package. If you don't know which package it should
be reassigned to, you should ask for help on
<qref id="irc-channels">IRC</qref> or on &email-debian-devel;.
+Please make sure that the maintainer(s) of the package
+the bug is reassigned to
+know why you reassigned it.
<p>
Sometimes you also have to adjust the severity of the bug so that it
matches our definition of the severity. That's because people tend to
<sect1 id="upload-bugfix">When bugs are closed by new uploads
<p>
-As bugs and problems are fixed your packages, it is your
-responsibility as the package maintainer to close the bug. However,
-you should not close the bug until the package which fixes the bug has
+As bugs and problems are fixed in your packages, it is your
+responsibility as the package maintainer to close these bugs. However,
+you should not close a bug until the package which fixes the bug has
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.
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
If for some reason you want to completely remove a package (say, if it
is an old compatibility library which is no longer required), you
need to file a bug against <tt>ftp.debian.org</tt> asking that the
-package be removed. Make sure you indicate which distribution the
+package be removed;
+as all bugs, this bug should normally have normal severity.
+Make sure you indicate which distribution the
package should be removed from. Normally, you can only have packages
removed from <em>unstable</em> and <em>experimental</em>. Packages
are not removed from <em>testing</em> directly. Rather, they will be
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
general interest (for instance, a flavor of Debian built with <prgn>gcc</prgn>
bounds checking). It will also enable Debian to recompile entire
distributions quickly.
- </sect2>
+ <p>
+The buildds admins of each arch can be contacted by the mail address
+$arch@buildd.debian.org.
+
+ <sect1 id="packages-arch-specific">When your package is <em>not</em> portable
+ <p>
+Some packages still have issues with building and/or working on some
+of the architectures supported by Debian, and cannot be ported at all,
+or not within a reasonable amount of time. An example is a package that
+is SVGA-specific (only i386), or uses other hardware-specific features
+not supported on all architectures.
+ <p>
+In order to prevent broken packages from being uploaded to the archive, and
+wasting buildd time, you need to do a few things:
+ <p>
+ <list>
+ <item>
+ <p>
+First, make sure your package <em>does</em> fail to build on
+architectures that it cannot support.
+There are a few ways to achieve this.
+The preferred way is to have a small testsuite during build time
+that will test the functionality, and fail if it doesn't work.
+This is a good idea anyway,
+as this will prevent (some) broken uploads on all architectures,
+and also will allow the package to build
+as soon as the required functionality is available.
+ <p>
+Additionally, if you believe the list of supported architectures is
+pretty constant, you should change 'any' to a list of supported
+architectures in debian/control. This way, the build will fail also,
+and indicate this to a human reader without actually trying.
+ <item>
+ <p>
+In order to prevent autobuilders from needlessly trying to build your
+package, it must be included in <file>packages-arch-specific</file>, a
+list used by the <prgn>wanna-build</prgn> script.
+The current version is available as
+<url id="http://cvs.debian.org/srcdep/Packages-arch-specific?cvsroot=dak">;
+please see the top of the file for whom to contact for changes.
+ </list>
+ <p>
+Please note that it is insufficient to only add your package to
+Packages-arch-specific
+without making it fail to build on unsupported architectures:
+A porter or any other person trying to build your package might
+accidently upload it without noticing it doesn't work.
+If in the past some binary packages were uploaded on unsupported architectures,
+request their removal by filing a bug against
+<package>ftp.debian.org</package>
<sect id="nmu">Non-Maintainer Uploads (NMUs)
However, aesthetic changes must <em>not</em> be made in a non-maintainer
upload.
<p>
-And please remember the Hippocratic Oath: "Above all, do no harm."
-It is better if a package has an grave bug open, than if a not working
-patch was applied, and the bug is only hidden now but not resolved.
+And please remember the Hippocratic Oath: "Above all, do no harm." It
+is better to leave a package with an open grave bug than applying a
+non-functional patch, or one that hides the bug instead of resolving
+it.
<sect1 id="nmu-guidelines">How to do a NMU
for a package to enter testing is through unstable.
<p>
For the stable distribution, please take extra care. Of course, the release
-managers may also change the rules here. Please verify before upload that
+managers may also change the rules here. Please verify before you upload that
all your changes are OK for inclusion into the next stable release by the
release manager.
<p>
really fixes each problem that was fixed in the non-maintainer release.
<p>
In addition, the normal maintainer should <em>always</em> retain the
-entry in the changelog file documenting the non-maintainer upload.
+entry in the changelog file documenting the non-maintainer upload --
+and of course, also keep the changes.
+If you revert some of the changes,
+please reopen the relevant bug reports.
<sect1 id="nmu-build">Building source NMUs
have to close the bugs that have been tagged fixed by the NMU. The easiest
way is to use the <tt>-v</tt> option of <prgn>dpkg-buildpackage</prgn>,
as this allows you to include just all changes since your last maintainer
-upload. Alternativly, you
+upload. Alternatively, you
can close them manually by sending the required mails to the
BTS or by adding the required <tt>closes: #nnnn</tt> in the changelog
entry of your next upload.
<heading>Updates from unstable</heading>
<p>
The scripts that update the <em>testing</em> distribution are run each
-day after the installation of the updated packages. They generate the
+day after the installation of the updated packages;
+these scripts are called <em>britney</em>.
+They generate the
<file>Packages</file> files for the <em>testing</em> distribution, but
they do so in an intelligent manner; they try to avoid any inconsistency
and to use only non-buggy packages.
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
<p>
Now, the more complex part happens: Britney tries to update testing with
the valid candidates; first, each package alone, and then larger and even
-larger sets of packages together. Each try is accepted if unstable is not
+larger sets of packages together. Each try is accepted if testing is not
more uninstallable after the update than before. (Before and after this part,
some hints are processed; but as only release masters can hint, this is
probably not so important for you.)
<sect1 id="helper-scripts">Helper scripts
<p>
The rationale for using helper scripts in <file>debian/rules</file> is
-that lets maintainers use and share common logic among many packages.
+that they let maintainers use and share common logic among many packages.
Take for instance the question of installing menu entries: you need to
-put the file into <file>/usr/lib/menu</file>, and add commands to the
+put the file into <file>/usr/lib/menu</file> (or
+<file>/usr/lib/menu</file> for executable binary menufiles, if this is needed),
+and add commands to the
maintainer scripts to register and unregister the menu entries. Since
this is a very common thing for packages to do, why should each
maintainer rewrite all this on their own, sometimes with bugs? Also,
patches. See the package <package>dbs</package> for more information and
<package>hello-dbs</package> for an example.
<p>
-<prgn>dpatch</prgn> also provides these facilities, but it's intented to be
+<prgn>dpatch</prgn> also provides these facilities, but it's intended to be
even easier to use. See the package <package>dpatch</package> for
documentation and examples (in <file>/usr/share/doc/dpatch</file>).
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:
<file>debian/control</file> field understood by <prgn>dpkg</prgn> and
<tt>&packages-host;</tt>. If you don't want to bother migrating the
home page from the description to this field, you should probably wait
-until that is available.</p>
+until that is available.
+ Please make sure that this line matches the regular expression
+ <tt>/^ Homepage: [^ ]*$/</tt>,
+ as this allows <file>packages.debian.org</file> to parse it correctly.</p>
</sect1>
</sect>
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">
<p>
These guidelines include some writing style and typography
recommendations, general considerations about debconf usage as well as
-more specific recommendations for some parts of the distribution (for
-instance, the installation system).
+more specific recommendations for some parts of the distribution (the
+installation system for instance).
<sect1>Do not abuse debconf
<p>
Most Debian package maintainers are not native English speakers. So,
writing properly phrased templates may not be easy for them.
<p>
-Please use (and abuse) debian-l10n-english@lists.debian.org mailing
+Please use (and abuse) &email-debian-l10n-english; mailing
list. Have your templates proofread.
<p>
Badly written templates give a poor image of your package, of your
<sect2>Be kind to translators
<p>
Debconf templates may be translated. Debconf, along with its sister
-package po-debconf offers a simple framework for getting
+package <prgn>po-debconf</prgn> offers a simple framework for getting
templates translated by translation teams or even individuals.
<p>
-Please use gettext-based templates. Install po-debconf on your
+Please use gettext-based templates. Install <package>po-debconf</package> on your
development system and read its documentation ("man po-debconf" is a
good start).
<p>
translator's name and e-mail addresses are mentioned in the po files
headers.
<p>
+The use of the <prgn>podebconf-report-po</prgn> from the
+po-debconf package is highly recommended to warn translators which
+have incomplete translations and request them for updates.
+ <p>
If in doubt, you may also contact the translation team for a given
language (debian-l10n-xxxxx@lists.debian.org), or the
-debian-i18n@lists.debian.org mailing list.
+&email-debian-i18n; mailing list.
+ <p>
+Calls for translations posted to
+&email-debian-i18n; with the <file>debian/po/templates.pot</file> file
+attached or referenced in a URL are encouraged. Be sure to mentions in
+these calls for new translations which languages you have existing
+translations for, in order to avoid duplicate work.
+ <sect2>Unfuzzy complete translations when correcting typos and spelling
+ <p>
+When the text of a debconf template is corrected and you are
+<strong>sure</strong> that the change does <strong>not</strong> affect
+translations, please be kind to translators and unfuzzy their
+translations.
+ <p>
+If you don't do so, the whole template will not be translated as long
+as a translator will send you an update.
+ <p>
+To <strong>unfuzzy</strong> translations, you can proceed the following way:
+ <enumlist>
+ <item>
+Put all incomplete PO files out of the way. You can check the
+completeness by using (needs the <package>gettext</package> package installed):
+<example>for i in debian/po/*po; do echo -n $i: ; msgfmt -o /dev/null
+--statistics $i; done</example>
+ <item>
+move all files which report either fuzzy strings to a temporary
+place. Files which report no fuzzy strings (only translated and
+untranslated) will be kept in place.
+ <item>
+now <strong>and now only</strong>, modify the template for the typos
+and check again that translation are not impacted (typos, spelling
+errors, sometimes typographical corrections are usually OK)
+ <item>
+run <prgn>debconf-updatepo</prgn>. This will fuzzy all strings
+you modified in translations. You can see this by running the above
+again
+ <item>
+use the following command:
+<example>for i in debian/po/*po; do msgattrib --output-file=$i --clear-fuzzy $i; done</example>
+ <item>
+move back to debian/po the files which showed fuzzy strings in the first step
+ <item>
+run <prgn>debconf-updatepo</prgn> again
+ </enumlist>
<sect2>Do not make assumptions about interfaces
<p>
Templates text should not make reference to widgets belonging to some
meaning for users of graphical interfaces which use checkboxes for
boolean questions.
<p>
+String templates should also avoid mentioning the default values in
+their description. First, because this is redundant with the values
+seen by the users. Also, because these default values may be different
+from the maintainer choices (for instance, when the debconf database
+was preseeded).
+ <p>
More generally speaking, try to avoid referring to user actions.
Just give facts.
<sect2>Do not use first person
<p>
You should avoid the use of first person ("I will do this..." or "We
-recommend..."). The computer is not a person and the Debconf tempaltes
+recommend..."). The computer is not a person and the Debconf templates
do not speak for the Debian developers. You should use neutral
construction and often the passive form. Those of you who already
wrote scientific publications, just write your templates like you
<sect2>Description: short and extended description
<p>
-Templates descriptions have two parts: short and extended. The short
+Template descriptions have two parts: short and extended. The short
description is in the "Description:" line of the template.
<p>
The short description should be kept short (50 characters or so) so
<p>
Policy specifies that documentation should be shipped in HTML format.
We also recommend shipping documentation in PDF and plain text format if
-convenient and quality output is possible. However, it is generally
+convenient and if output of reasonable quality is possible. However, it is generally
not appropriate to ship plain text versions of documentation whose source
format is HTML.</p>
<p>
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
distributed by the upstream author.
<footnote>
We cannot prevent upstream authors from changing the tarball
-they distribute without also upping the version number, so
+they distribute without also incrementing the version number, so
there can be no guarantee that a pristine tarball is identical
to what upstream <em>currently</em> distributing at any point in
time. All that can be expected is that it is identical to
</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
<p>
You may also be interested in contacting the persons who are
subscribed to a given source package via <ref id="pkg-tracking-system">.
-You can do so by using the <tt><package-name>@&pts-host;</tt>
+You can do so by using the <tt><package>@&pts-host;</tt>
email address.
<!-- FIXME: moo@packages.d.o is easily confused with moo@packages.qa.d.o -->
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-debian-qa;.
+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
decide how to proceed. For example, they might orphan one or all of the
packages of the maintainer. If a packages has been NMUed, they might prefer
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">
avoid the chaos resulting in having several versions of the same document in
bug reports.
<p>
-The best solution is to fill a regular bug containing the translation against
+The best solution is to file a regular bug containing the translation against
the package. Make sure to use the 'PATCH' tag, and to not use a severity higher
than 'wishlist', since the lack of translation never prevented a program from
running.
<package>debhelper</package>.
<p>
The consensus is that <package>debmake</package> is now deprecated in
-favor of <package>debhelper</package>. However, it's not a bug to use
-<package>debmake</package>.
+favor of <package>debhelper</package>. It is a bug to use
+<package>debmake</package> in new packages. New packages using
+<package>debmake</package> will be rejected from the archive.
</sect1>
<sect1 id="dh-make">
~ianmdlvl / developers-reference.git / blobdiff