<!DOCTYPE debiandoc PUBLIC "-//DebianDoc//DTD DebianDoc//EN" [
<!-- include version information so we don't have to hard code it
within the document -->
- <!entity % versiondata SYSTEM "version.ent"> %versiondata;
- <!-- common, language independant entities -->
- <!entity % commondata SYSTEM "common.ent" > %commondata;
+ <!ENTITY % versiondata SYSTEM "version.ent"> %versiondata;
+ <!-- common, language independent entities -->
+ <!ENTITY % commondata SYSTEM "common.ent" > %commondata;
<!-- CVS revision of this document -->
- <!entity cvs-rev "$Revision: 1.188 $">
+ <!ENTITY cvs-rev "$Revision: 1.256 $">
+
<!-- if you are translating this document, please notate the CVS
- revision of the developers reference here -->
- <!--
- <!entity cvs-en-rev "X.YY">
- -->
+ revision of the original developer's reference in cvs-en-rev -->
+ <!-- <!ENTITY cvs-en-rev "X.YZW"> -->
- <!-- -->
- <!entity FIXME "<em>FIXME:</em> ">
+ <!-- how to mark a section that needs more work -->
+ <!ENTITY FIXME "<em>FIXME:</em> ">
]>
<debiandoc>
<book>
<title>Debian Developer's Reference
- <author>Adam Di Carlo, current maintainer <email>aph@debian.org</email>
- <author>Raphaël Hertzog, co-maintainer <email>hertzog@debian.org</email>
- <author>Christian Schwarz <email>schwarz@debian.org</email>
- <author>Ian Jackson <email>ijackson@gnu.ai.mit.edu</email>
+ <author>Developer's Reference Team &email-devel-ref;
+ <author>Andreas Barth
+ <author>Adam Di Carlo
+ <author>Raphaël Hertzog
+ <author>Christian Schwarz
+ <author>Ian Jackson
<version>ver. &version;, &date-en;
<copyright>
<copyrightsummary>
+copyright © 2004 Andreas Barth</copyrightsummary>
+ <copyrightsummary>
copyright © 1998—2003 Adam Di Carlo</copyrightsummary>
<copyrightsummary>
-copyright © 2002 Raphaël Hertzog</copyrightsummary>
+copyright © 2002—2003 Raphaël Hertzog</copyrightsummary>
<copyrightsummary>
copyright © 1997, 1998 Christian Schwarz</copyrightsummary>
<p>
packages (<ref id="tools">).
<p>
It should be clear that this reference does not discuss the technical
-details of the Debian package nor how to generate Debian packages.
+details of Debian packages nor how to generate them.
Nor does this reference detail the standards to which Debian software
must comply. All of such information can be found in the <url
id="&url-debian-policy;" name="Debian Policy Manual">.
<p>
Furthermore, this document is <em>not an expression of formal
policy</em>. It contains documentation for the Debian system and
-generally agreed-upon best practices. Thus, it is what is called a
+generally agreed-upon best practices. Thus, it is not what is called a
``normative'' document.
<p>
Another good list to subscribe to is &email-debian-mentors;. See <ref
id="mentors"> for details. The IRC channel <tt>#debian</tt> can also be
-helpful.
+helpful; see <ref id="irc-channels">.
<p>
When you know how you want to contribute to &debian-formal;, you
should get in contact with existing Debian maintainers who are working
on similar tasks. That way, you can learn from experienced developers.
For example, if you are interested in packaging existing software for
-Debian you should try to get a sponsor. A sponsor will work together
+Debian, you should try to get a sponsor. A sponsor will work together
with you on your package and upload it to the Debian archive once they
are happy with the packaging work you have done. You can find a sponsor
by mailing the &email-debian-mentors; mailing list, describing your
package and yourself and asking for a sponsor (see <ref id="sponsoring">
-for more information on sponsoring). On the other hand, if you are
+and <url id="&url-mentors;"> for more information on sponsoring).
+On the other hand, if you are
interested in porting Debian to alternative architectures or kernels
you can subscribe to port specific mailing lists and ask there how to
get started. Finally, if you are interested in documentation or
preparations you have to do before you can register to become a Debian
developer.
-For example, before you apply, you have to to read the <url
+For example, before you apply, you have to read the <url
id="&url-social-contract;" name="Debian Social Contract">.
Registering as a developer means that you agree with and pledge to
uphold the Debian Social Contract; it is very important that
your identity and intentions, and checking your technical skills. As
the number of people working on &debian-formal; has grown to over
&number-of-maintainers; people and our systems are used in several
-very important places we have to be careful about being compromised.
+very important places, we have to be careful about being compromised.
Therefore, we need to verify new maintainers before we can give them
accounts on our servers and let them upload packages.
<p>
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
+a maintainer close to you. (If you cannot find a Debian maintainer
close to you, there's an alternative way to pass the ID check. You
can send in a photo ID signed with your GnuPG key. Having your GnuPG
key signed is the preferred way, however. See the
OpenPGP is an open standard based on <url id="&url-rfc2440;" name="RFC
2440">.
<p>
+<!-- FIXME: DSS is not exactly equivalent to DSA, is it? -->
The recommended public key algorithm for use in Debian development
-work is DSA (sometimes call ``DSS'' or ``DH/ElGamal''). Other key
-types may be used however. Your key length must be at least 1024
+work is DSA (sometimes called ``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
to verify 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 his belief that you
+have worked over the past months has to express their belief that you
can contribute to Debian successfully.
<p>
When you have found an advocate, have your GnuPG key signed and have
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. Those who are seeking a
+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">.
Read the documentation that comes with your software; read the <url
id="&url-pgp-faq;" name="PGP FAQ">.
<p>
+You need to ensure not only that your key is secure against being stolen,
+but also that it is secure against being lost. Generate and make a copy
+(best also in paper form) of your revocation certificate; this is needed if
+your key is lost.
+ <p>
If you add signatures to your public key, or add user identities, you
can update the Debian key ring by sending your key to the key server at
-<tt>&keyserver-host;</tt>. If you need to add a completely new key,
-or remove an old key, send mail to &email-debian-keyring;. The same
-key extraction routines discussed in <ref id="registering"> apply.
+<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
+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.
+ <p>
+The same key extraction routines discussed in <ref id="registering">
+apply.
<p>
You can find a more in-depth discussion of Debian key maintenance in
the documentation of the <package>debian-keyring</package> package.
nothing as critical as that, but it's still appropriate to let the others
know that you're unavailable.
<p>
-In order to inform the other developers, there's two things that you should do.
+In order to inform the other developers, there are two things that you should do.
First send a mail to &email-debian-private; with "[VAC] " prepended to the
subject of your message<footnote>This is so that the message can be easily
-filtered by people who don't want to read vacation notices.</footnote>,
-giving the period of time when you will be on vacation. You can also give
+filtered by people who don't want to read vacation notices.</footnote>
+and state the period of time when you will be on vacation. You can also give
some special instructions on what to do if a problem occurs.
<p>
The other thing to do is to mark yourself as "on vacation" in the
<qref id="devel-db">Debian developers' LDAP database</qref> (this
information is only accessible to Debian developers).
Don't forget to remove the "on vacation" flag when you come back!
+ <p>
+Ideally, you should sign up at the
+<url id="http://nm.debian.org/gpg.php" name="GPG coordination site">
+when booking a holiday and check if anyone there is looking for signing.
+This is especially important when people go to exotic places
+where we don't have any developers yet but
+where there are people who are interested in applying.
<sect id="upstream-coordination">Coordination with upstream developers
<p>
A big part of your job as Debian maintainer will be to stay in contact
with the upstream developers. Debian users will sometimes report bugs
-to the Bug Tracking System that are not specific to Debian. You
-must forward these bug reports to the upstream developers so that
-they can be fixed in a future release. It's not your job to fix
-non-Debian specific bugs. However, if you are able to do so, you are
-encouraged to contribute to upstream development of the package by
-providing a fix for the bug. Debian users and developers will often
-submit patches to fix upstream bugs, and you should evaluate and
-forward these patches upstream.
+that are not specific to Debian to our bug tracking system. You
+have to forward these bug reports to the upstream developers so that
+they can be fixed in a future upstream release.
+ <p>
+While it's not your job to fix non-Debian specific bugs, you may freely
+do so if you're able. When you make such fixes, be sure to pass them on
+to the upstream maintainers as well. Debian users and developers will
+sometimes submit patches to fix upstream bugs — you should evaluate
+and forward these patches upstream.
<p>
If you need to modify the upstream sources in order to build a policy
compliant package, then you should propose a nice fix to the upstream
<p>
Generally you should deal with bug reports on your packages as described in
<ref id="bug-handling">. However, there's a special category of bugs that
-you need to take care of -- the so-called release-critical bugs (RC bugs).
+you need to take care of — the so-called release-critical bugs (RC bugs).
All bug reports that have severity <em>critical</em>, <em>grave</em> or
<em>serious</em> are considered to have an impact on whether the package can
be released in the next stable release of Debian.
<sect id="mailing-lists">Mailing lists
<p>
-The mailing list server is at <tt>&lists-host;</tt>.
+Much of the conversation between Debian developers (and users) is managed
+through a wide array of mailing lists we host at
+<tt><url id="http://&lists-host;/" name="&lists-host;"></tt>.
+To find out more on how to subscribe or unsubscribe, how to post and how not
+to post, where to find old posts and how to search them, how to contact the
+list maintainers and see various other information about the mailing lists,
+please read <url id="&url-debian-lists;">. This section will only cover
+aspects of mailing lists that are of particular interest to developers.
+
+ <sect1 id="mailing-lists-rules">Basic rules for use
+ <p>
+When replying to messages on the mailing list, please do not send a
+carbon copy (<tt>CC</tt>) to the original poster unless they explicitly
+request to be copied. Anyone who posts to a mailing list should read
+it to see the responses.
+ <p>
+Cross-posting (sending the same message to multiple lists) is discouraged.
+As ever on the net, please trim down the quoting of articles you're
+replying to. In general, please adhere to the usual conventions for
+posting messages.
<p>
-Online archives of mailing lists are available at <url
-id="&url-lists-archives;">.
+Please read the <url name="code of conduct" id="&url-debian-lists;#codeofconduct">
+for more information.
<sect1 id="core-devel-mailing-lists">Core development mailing lists
<p>
</item>
</list>
<p>
-There are
-other mailing lists available for a variety of special topics; see
-<url id="&url-debian-lists-subscribe;"> for a list.
-
- <sect1 id="mailing-lists-subunsub">Subscribing and unsubscribing
- <p>
-To subscribe to or unsubscribe from any of the Debian mailing lists, email
-<tt>debian-<var>foo</var>-REQUEST@&lists-host;</tt>, where
-<tt>debian-<var>foo</var></tt> is the name of the list, with the word
-<tt>subscribe</tt> in the <em>Subject</em> to subscribe to the list or
-<tt>unsubscribe</tt> to unsubscribe.
- <p>
-If you prefer to use a web page to subscribe to multiple mailing lists,
-there's one at <url id="&url-debian-lists-subscribe;">.
- <p>
-You can download the current list of mailing lists and basic usage
-instructions from <url id="&url-debian-lists-txt;">
-or install the <package>doc-debian</package> package and have it
-locally in &file-mail-lists;.
-
- <sect1 id="mailing-lists-rules">Basic rules for use
- <p>
-When replying to messages on the mailing list, please do not send a
-carbon copy (<tt>CC</tt>) to the original poster unless they explicitly
-request to be copied. Anyone who posts to a mailing list should read
-it to see the responses.
- <p>
-Cross-posting (sending the same message to multiple lists) is discouraged.
-As ever on the net, please trim down the quoting of articles you're
-replying to. In general, please adhere to the usual conventions for
-posting messages. Please read the <url name="code of conduct"
-id="&url-debian-lists;"> for more information.
+There are other mailing lists available for a variety of special topics;
+see <url id="http://&lists-host;/"> for a list.
<sect1 id="mailing-lists-special">Special lists
<p>
about licenses, bugs, etc. or discussing the project with others where it
might be useful to have the discussion archived somewhere.
+ <sect1 id="mailing-lists-new">Requesting new development-related lists
+ <p>
+Before requesting a mailing list that relates to the development of a
+package (or a small group of related packages), please consider if using
+an alias (via a .forward-aliasname file on master.debian.org, which
+translates into a reasonably nice <var>you-aliasname@debian.org</var>
+address) or a self-managed mailing list on <qref id="alioth">Alioth</qref>
+is more appropriate.
+ <p>
+If you decide that a regular mailing list on lists.debian.org is really what
+you want, go ahead and fill in a request, following <url name="the HOWTO"
+id="&url-debian-lists-new;">.
<sect id="irc-channels">IRC channels
<p>
It is however open to anyone who wants to lurk (and learn). Its topic is
commonly full of interesting information for developers.
<p>
-Since <em>#debian-devel</em> it's an open channel, you
+Since <em>#debian-devel</em> is an open channel, you
should not speak there of issues that are discussed in
&email-debian-private;. There's another channel for this purpose,
it's called <em>#debian-private</em> and it's protected by a key.
<p>
There are other additional channels dedicated to specific subjects.
<em>#debian-bugs</em> is used for coordinating bug squash parties.
-<em>#debian-boot</em> is used to coordinate the work on the boot
-floppies (i.e., the installer). <em>#debian-doc</em> is
+<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
reading. Other channels are dedicated to an architecture or a set of
packages: <em>#debian-bsd</em>, <em>#debian-kde</em>, <em>#debian-jr</em>,
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.
+ <p>
+To get a cloak on freenode, you send Göran Weinholt <weinholt@debian.org>
+a signed mail where you tell what your nick is.
+Put "cloak" somewhere in the Subject: header.
+The nick should be registered:
+<url id="http://freenode.net/faq.shtml#nicksetup" name="Nick Setup Page">.
+The mail needs to be signed by a key in the Debian keyring.
+Please see
+<url id="http://freenode.net/faq.shtml#projectcloak" name="Freenodes documentation">
+for more information about cloaks.
<sect id="doc-rsrcs">Documentation
<p>
-This document contains a lot of information very useful to Debian developers,
-but it can not contain everything. Most of the other interesting documents
+This document contains a lot of information
+which is useful to Debian developers,
+but it cannot contain everything. Most of the other interesting documents
are linked from <url id="&url-devel-docs;" name="The Developers' Corner">.
Take the time to browse all the links, you will learn many more things.
suggestions for the web site, etc.),
generally you'll report a bug against a ``pseudo-package''. See <ref
id="submit-bug"> for information on how to submit bugs.
+ <p>
+Some of the core servers are restricted, but the information from there
+is mirrored to another server.
<sect1 id="servers-bugs">The bugs server
<p>
<tt>&bugs-host;</tt> is the canonical location for the Bug Tracking
-System (BTS). If you plan on doing some statistical analysis or
+System (BTS).
+ <p>
+It is restricted; a mirror is available on <tt>merkel</tt>.
+ <p>
+If you plan on doing some statistical analysis or
processing of Debian bugs, this would be the place to do it. Please
describe your plans on &email-debian-devel; before implementing
anything, however, to reduce unnecessary duplication of effort or
wasted processing time.
- <p>
-All Debian developers have accounts on <tt>&bugs-host;</tt>.
<sect1 id="servers-ftp-master">The ftp-master server
<p>
archive (excluding the non-US packages). Generally, package uploads
go to this server; see <ref id="upload">.
<p>
+It is restricted; a mirror is available on <tt>merkel</tt>.
+ <p>
Problems with the Debian FTP archive generally need to be reported as
bugs against the <package>ftp.debian.org</package> pseudo-package or
an email to &email-ftpmaster;, but also see the procedures in
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 on the
+not someone else has already reported the problem to the
<url id="http://&bugs-host;/nonus.debian.org" name="Bug Tracking System">.
<sect1 id="servers-www">The www-master server
If you find a problem with the Debian web server, you should generally
submit a bug against the pseudo-package,
<package>www.debian.org</package>. Remember to check whether or not someone
-else has already reported the problem on the
+else has already reported the problem to the
<url id="http://&bugs-host;/www.debian.org" name="Bug Tracking System">.
<sect1 id="servers-people">The people web server
Send mail to &email-debian-devel; if you have any questions.
<sect1 id="servers-cvs">The CVS server
+<!-- TODO: document svn.debian.org, arch.debian.org also -->
<p>
Our CVS server is located on <tt>cvs.debian.org</tt>.
<p>
&email-debian-admin;. Include the name of the requested CVS area,
the Debian account that should own the CVS root area, and why you need it.
+ <sect1 id="dchroot">chroots to different distributions
+ <p>
+On some machines, there are chroots to different distributions available.
+You can use them like
+
+<example>
+vore% dchroot unstable
+Executing shell in chroot: /org/vore.debian.org/chroots/user/unstable
+</example>
+
+In all chroots, the normal user home directories are available.
+You can find out which chroots are available via
+<tt>&url-devel-machines;</tt>.
+
<sect id="devel-db">The Developers Database
<p>
For more information please read the online documentation that you can find
at <url id="&url-debian-db-doc;">.
<p>
-One can also submit their SSH keys to be used for authorization on the
+Developers can also submit their SSH keys to be used for authorization on the
official Debian machines, and even add new *.debian.net DNS entries.
Those features are documented at <url id="&url-debian-db-mail-gw;">.
<p>
The &debian-formal; distribution consists of a lot of packages
(<file>.deb</file>'s, currently around &number-of-pkgs;) and a few
-additional files (such documentation and installation disk images).
+additional files (such as documentation and installation disk images).
<p>
Here is an example directory tree of a complete Debian archive:
<p>
(<file>source</file>) and a directory for each supported architecture
(<file>binary-i386</file>, <file>binary-m68k</file>, etc.).
<p>
-The <file>main</file> area contains additional directories which holds
+The <file>main</file> area contains additional directories which hold
the disk images and some essential pieces of documentation required
for installing the Debian distribution on a specific architecture
(<file>disks-i386</file>, <file>disks-m68k</file>, etc.).
- <sect1>Sections
+ <sect1 id="archive-sections">Sections
<p>
The <em>main</em> section of the Debian archive is what makes up the
<strong>official &debian-formal; distribution</strong>. The
<p>
On the other hand, a CD-ROM vendor could easily check the individual
package licenses of the packages in <em>non-free</em> and include as
-many on the CD-ROMs as he's allowed to. (Since this varies greatly from
+many on the CD-ROMs as it's allowed to. (Since this varies greatly from
vendor to vendor, this job can't be done by the Debian developers.)
<p>
-Note also that the term "section" is also used to refer to categories
+Note that the term "section" is also used to refer to categories
which simplify the organization and browsing of available packages, e.g.
<em>admin</em>, <em>net</em>, <em>utils</em> etc. Once upon a time, these
sections (subsections, rather) existed in the form of subdirectories within
Linux 2.2 kernel supports even more architectures, including ARM and
UltraSPARC. Since Linux supports these platforms, Debian decided that
it should, too. Therefore, Debian has ports underway; in fact, we
-also have ports underway to non-Linux kernel. Aside from
+also have ports underway to non-Linux kernels. Aside from
<em>i386</em> (our name for Intel x86), there is <em>m68k</em>,
<em>alpha</em>, <em>powerpc</em>, <em>sparc</em>, <em>hurd-i386</em>,
<em>arm</em>, <em>ia64</em>, <em>hppa</em>, <em>s390</em>, <em>mips</em>,
shipped for <em>i386</em> and <em>m68k</em> architectures. Debian 2.1
ships for the <em>i386</em>, <em>m68k</em>, <em>alpha</em>, and
<em>sparc</em> architectures. Debian 2.2 added support for the
-<em>powerpc</em> and <em>arm</em> architectures. Debian 3.0 adds
+<em>powerpc</em> and <em>arm</em> architectures. Debian 3.0 added
support of five new architectures: <em>ia64</em>, <em>hppa</em>,
<em>s390</em>, <em>mips</em> and <em>mipsel</em>.
<p>
-Information for developers or uses about the specific ports are
+Information for developers and users about the specific ports are
available at the <url id="&url-debian-ports;" name="Debian Ports web
pages">.
the package (maintainer, version, etc.).
- <sect1>Distribution directories
+ <sect1>Distributions
<p>
The directory system described in the previous chapter is itself
contained within <em>distribution directories</em>. Each
contained in <ftppath>/debian</ftppath>, which is a common location
(another is <file>/pub/debian</file>).
<p>
-A distribution is comprised of Debian source and binary packages, and the
+A distribution comprises Debian source and binary packages, and the
respective <file>Sources</file> and <file>Packages</file> index files, containing
the header information from all those packages. The former are kept in the
<file>pool/</file> directory, while the latter are kept in the <file>dists/</file>
<sect2 id="sec-dists">Stable, testing, and unstable
<p>
There are always distributions called <em>stable</em> (residing in
-<file>dists/stable</file>), one called <em>testing</em> (residing in
-<file>dists/testing</file>), and one called <em>unstable</em> (residing in
+<file>dists/stable</file>), <em>testing</em> (residing in
+<file>dists/testing</file>), and <em>unstable</em> (residing in
<file>dists/unstable</file>). This reflects the development process of the
Debian project.
<p>
(that's why this distribution is sometimes called the <em>development
distribution</em>). Every Debian developer can update his or her
packages in this distribution at any time. Thus, the contents of this
-distribution changes from day-to-day. Since no special effort is done
+distribution change from day to day. Since no special effort is made
to make sure everything in this distribution is working properly, it is
sometimes literally unstable.
<p>
-<ref id="testing"> is generated automatically by taking
+The <qref id="testing">"testing"</qref> distribution is generated
+automatically by taking
packages from unstable if they satisfy certain criteria. Those
criteria should ensure a good quality for packages within testing.
The update to testing is launched each day after the
-new packages have been installed.
+new packages have been installed. See <ref id="testing">.
<p>
After a period of development, once the release manager deems fit, the
<em>testing</em> distribution is frozen, meaning that the policies
freeze period, since the <em>unstable</em> distribution remains in
place in parallel with <em>testing</em>.
- <sect2>Experimental
+ <sect2>
+ <heading>More information about the testing distribution</heading>
+ <p>
+Packages are usually installed into the `testing' distribution after they
+have undergone some degree of testing in unstable.
+ <p>
+For more details, please see the <qref id="testing">information about the
+testing distribution</qref>.
+
+ <sect2 id="experimental">Experimental
<p>
The <em>experimental</em> distribution is a special distribution.
It is not a full distribution in the same sense as `stable' and
warned. In short, all bets are off for the <em>experimental</em>
distribution.
<p>
+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
+</example>
+ <p>
If there is a chance that the software could do grave damage to a system,
it is likely to be better to put it into <em>experimental</em>.
For instance, an experimental compressed file system should probably go
Whenever there is a new upstream version of a package that introduces new
features but breaks a lot of old ones, it should either not be uploaded, or
be uploaded to <em>experimental</em>. A new, beta, version of some software
-which uses completely different configuration can go into
+which uses a completely different configuration can go into
<em>experimental</em>, at the maintainer's discretion. If you are working
on an incompatible or complex upgrade situation, you can also use
<em>experimental</em> as a staging area, so that testers can get early
<p>
An alternative to <em>experimental</em> is to use your personal web space
on <tt>people.debian.org</tt>.
-
+ <p>
+When uploading to unstable a package which had bugs fixed in experimental,
+please consider using the option <tt>-v</tt> to <prgn>dpkg-buildpackage</prgn>
+to finally get them closed.
<sect1 id="codenames">Release code names
<p>
<p>
The various download archives and the web site have several mirrors
available in order to relieve our canonical servers from heavy load.
-In fact, some of the canonical servers aren't public, and instead a
-first tier of mirrors balances the load. That way, users always access
+In fact, some of the canonical servers aren't public — a first tier
+of mirrors balances the load instead. That way, users always access
the mirrors and get used to using them, which allows Debian to better
spread its bandwidth requirements over several servers and networks,
and basically makes users avoid hammering on one primary location.
<sect id="incoming-system">
<heading>The Incoming system
<p>
-The Incoming system is responsible of collecting updated packages and
+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>.
<p>
Packages are uploaded by all the maintainers into a directory called
-<file>unchecked</file>. This directory is scanned every 15 minutes by
-the <prgn>katie</prgn> script, which verifies the integrity of the uploaded packages and the cryptographic
-signatures. If the package is considered ready to be installed, it
+<file>UploadQueue</file>.
+This directory is scanned every few minutes by a daemon called
+<prgn>queued</prgn>, <file>*.command</file>-files are executed, and
+remaining and correctly signed <file>*.changes</file>-files are moved
+together with their corresponding files to the <file>unchecked</file>
+directory.
+This directory is not visible for most Developers, as ftp-master is restricted;
+it is scanned every 15 minutes by
+the <prgn>katie</prgn> script, which verifies the integrity of the uploaded
+packages and their cryptographic signatures.
+If the package is considered ready to be installed, it
is moved into the <file>accepted</file> directory. If this is the first upload of
-the package, it is moved in the <file>new</file> directory, where it waits
-for an approval of the ftpmasters. If the package contains files to be installed
-"by-hand" it is moved in the <file>byhand</file> directory, where it waits
-for a manual installation by the ftpmasters. Otherwise, if any error has been detected,
-the package is refused and is moved in the <file>reject</file> directory.
- <p>
-Once the package is accepted the system sends a confirmation
-mail to the maintainer, closes all the bugs marked as fixed by the upload
+the package (or it has new binary packages),
+it is moved to the <file>new</file> directory, where it waits
+for approval by the ftpmasters. If the package contains files to be installed
+"by hand" it is moved to the <file>byhand</file> directory, where it waits
+for manual installation by the ftpmasters. Otherwise, if any error has been detected,
+the package is refused and is moved to the <file>reject</file> directory.
+ <p>
+Once the package is accepted, the system sends a confirmation
+mail to the maintainer and closes all the bugs marked as fixed by the upload,
and the auto-builders may start recompiling it. The package is now publicly
-accessible at <url id="&url-incoming;"> (there is no
-such URL for packages in the non-US archive) until it is really installed
-in the Debian archive. This happens only once a day, the package
+accessible at <url id="&url-incoming;">
+until it is really installed
+in the Debian archive.
+This happens only once a day
+(and is also called `dinstall run' for historical reasons);
+the package
is then removed from incoming and installed in the pool along with all
the other packages. Once all the other updates (generating new
<file>Packages</file> and <file>Sources</file> index files for example) have been
or `experimental', the announcement will be posted to
&email-debian-devel-changes; instead.
<p>
+Though ftp-master is restricted, a copy of the installation is available
+to all developers on <tt>&ftp-master-mirror;</tt>.
+<!-- FIXME: delete it or keep it for historical purposes?
+ <p>
All Debian developers have write access to the <file>unchecked</file>
-directory in order to upload their packages, they also have that access
+directory in order to upload their packages; they also have that access
to the <file>reject</file> directory in order to remove their bad uploads
-or to move some files back in the <file>unchecked</file> directory. But
-all the other directories are only writable by the ftpmasters, that is
-why you can not remove an upload once it has been accepted.
+or to move some files back to the <file>unchecked</file> directory. But
+all the other directories are only writable by the ftpmasters, which is
+why you cannot remove an upload once it has been accepted.
- <sect1 id="delayed-incoming">Delayed incoming
+ <sect1 id="delayed-incoming-broken">Delayed incoming
+ <p>
+<em>Note:</em> This description here is currently not working, because
+ftp-master is restricted. Please see <ref id="delayed-incoming"> for
+the currently working way.
<p>
The <file>unchecked</file> directory has a special <file>DELAYED</file>
subdirectory. It is itself subdivided in nine directories
-called <file>1-day</file> to <file>9-day</file>. Packages which are uploaded in
-one of those directories will be moved in the real unchecked
+called <file>1-day</file> to <file>9-day</file>. Packages which are uploaded to
+one of those directories will be moved to the real unchecked
directory after the corresponding number of days.
-This is done by a script that is run each day and which moves the
+This is done by a script which is run each day and which moves the
packages between the directories. Those which are in "1-day" are
-installed in <file>unchecked</file> while the others are moved in the
+installed in <file>unchecked</file> while the others are moved to the
adjacent directory (for example, a package in <file>5-day</file> will
-be moved in <file>4-day</file>). This feature is particularly useful
+be moved to <file>4-day</file>). This feature is particularly useful
for people who are doing non-maintainer uploads. Instead of
waiting before uploading a NMU, it is uploaded as soon as it is
-ready but in one of those <file>DELAYED/<var>x</var>-day</file> directories.
+ready, but to one of those <file>DELAYED/<var>x</var>-day</file> directories.
That leaves the corresponding number of days for the maintainer
to react and upload another fix themselves if they are not
completely satisfied with the NMU. Alternatively they can remove
</example>
Once you've made that change, <prgn>dupload</prgn> can be used to
easily upload a package in one of the delayed directories:
-<example>DELAY=5 dupload --to delayed <changes-file></example>
-
-
- <sect id="testing">
- <heading>The "testing" distribution</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 <file>Packages</file> files for
-the <em>testing</em> distribution, but they do so in an intelligent manner
-trying to avoid any inconsistency and trying to use only
-non-buggy packages.
- <p>The inclusion of a package from <em>unstable</em> is conditional on the following:
-<list>
- <item>
-The package must have been available in <em>unstable</em> for several days;
-the precise number depends on the upload's urgency field. It
-is 10 days for low urgency, 5 days for medium urgency and 2 days for high
-urgency. Those delays may be doubled during a freeze;
- <item>
-It must have less release-critical bugs than the version available
-in <em>testing</em>;
- <item>
-It must be available on all architectures on which it has been
-previously built. <ref id="madison"> may be of interest to
-check that information;
- <item>
-It must not break any dependency of a package that is already available
-in <em>testing</em>;
- <item>
-The packages on which it depends must either be available in <em>testing</em>
-or they must be accepted into <em>testing</em> at the same time (and they will
-if they respect themselves all the criteria);
-</list>
- <p>
-To find out whether a package is progressing into testing or not, see the
-testing script output on the <url name="web page of the testing distribution"
-id="&url-testing-maint;">, or use the program <prgn>grep-excuses</prgn>
-which is in the <package>devscripts</package> package. This utility can
-easily be used in a <manref name="crontab" section="5"> to keep one
-informed of the progression of their packages into <em>testing</em>.
- <p>
-The <file>update_excuses</file> file does not always give the precise reason
-why the package is refused, one may have to find it on their own by looking
-what would break with the inclusion of the package. The <url
-id="&url-testing-maint;" name="testing web page"> gives some more information
-about the usual problems which may be causing such troubles.
- <p>
-Sometimes, some packages never enter <em>testing</em> because the set of
-inter-relationship is too complicated and can not be sorted out
-by the scripts. In that case, the release manager must be
-contacted, and he will force the inclusion of the packages.
- <p>
-In general, please refer to the <url name="testing web page"
-id="&url-testing-maint;"> for more information. It also includes
-answers to some of the frequently asked questions.
+<example>DELAY=5 dupload -X-to delayed <changes-file></example>
+-->
<sect id="pkg-info">Package information
displays each version of the package
available in the various distributions. Each version links to a page
which provides information, including the package description,
-the dependencies and package download links.
+the dependencies, and package download links.
<p>
-The bug tracking system track bugs for each package. You can
-view the bugs of a given package at the URL
+The bug tracking system tracks bugs for each package.
+You can view the bugs of a given package at the URL
<tt>http://&bugs-host;/<var>package-name</var></tt>.
<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>. It
+on both <tt>&ftp-master-host;</tt> and <tt>&non-us-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
architecture and distribution combination. An example will explain
<p>
In this example, you can see that the version in <em>unstable</em> differs from
the version in <em>testing</em> and that there has been a binary-only NMU of the
-package for the alpha architecture. Each time the package has been
+package for the alpha architecture. Each version of the package has been
recompiled on most of the architectures.
<sect id="pkg-tracking-system">The Package Tracking System
<p>
-The Package Tracking System (PTS) is basically a tool to track by mail
-the activity of a source package. You just have to subscribe
-to a source package to start getting the mails related to it.
-You get the same mails as the maintainer. Each mail
-sent through the PTS is classified and associated to one of
-the keyword listed below. This will let you select the mails that
+The Package Tracking System (PTS) is an email-based tool to track
+the activity of a source package. This really means that you can
+get the same emails that the package maintainer gets, simply by
+subscribing to the package in the PTS.
+ <p>
+Each email sent through the PTS is classified under one of
+the keywords listed below. This will let you select the mails that
you want to receive.
<p>
By default you will get:
<tag><tt>bts-control</tt>
<item>
-The control mails notifying a status change in one of the bugs.
+The email notifications from <email>control@bugs.debian.org</email>
+about bug report status changes.
<tag><tt>upload-source</tt>
<item>
-The
confirmation mail from <prgn>katie</prgn> when an uploaded source
+The
email notification from <prgn>katie</prgn> when an uploaded source
package is accepted.
<tag><tt>katie-other</tt>
<item>
-Other warning and error mails from <prgn>katie</prgn> (like the
-override disparity for the section or priority field).
+Other warning and error emails from <prgn>katie</prgn> (such as an
+override disparity for the section and/or the priority field).
<tag><tt>default</tt>
<item>
-Any non-automatic mail sent to the PTS by people who wanted to
-contact the subscribers of the package.
+Any non-automatic email sent to the PTS by people who wanted to
+contact the subscribers of the package. This can be done by sending mail
+to <tt><var>sourcepackage</var>@&pts-host;</tt>. In order to prevent spam,
+all messages sent to these addresses must contain the <tt>X-PTS-Approved</tt>
+header with a non-empty value.
<tag><tt>summary</tt>
<item>
-In the future, you may receive regular summary mails to keep you
-informed of the package's status (bug statistics, porting overview,
-progression in <em>testing</em>, ...).
+(This is a planned expansion.)
+The regular summary emails about the package's status (bug statistics,
+porting overview, progression in <em>testing</em>, ...).
</taglist>
+
<p>
-You can also decide to receive some more information:
+You can also decide to receive additional information:
<taglist>
<tag><tt>upload-binary</tt>
<item>
-The confirmation mail from <prgn>katie</prgn> when an uploaded binary
-package is accepted (to check that your package is recompiled for all
-architectures).
+The email notification from <prgn>katie</prgn> when an uploaded binary
+package is accepted. In other words, whenever a build daemon or a porter
+uploads your package for another architecture, you can get an email to
+track how your package gets recompiled for all architectures.
<tag><tt>cvs</tt>
<item>
-CVS commits if the maintainer has setup a system to forward commit
-notification to the PTS.
+CVS commit notifications, if the package has a CVS repository and the
+maintainer has set up forwarding commit notifications to the PTS.
<tag><tt>ddtp</tt>
<item>
<taglist>
-<tag><tt>subscribe <srcpackage> [<email>]</tt>
+<tag><tt>subscribe <sourcepackage> [<email>]</tt>
<item>
Subscribes <var>email</var> to communications related to the source package
- <var>srcpackage</var>. Sender address is used if the second argument is
- not present. If <var>srcpackage</var> is not a valid source package,
+ <var>sourcepackage</var>. Sender address is used if the second argument is
+ not present. If <var>sourcepackage</var> is not a valid source package,
you'll get a warning. However if it's a valid binary package, the PTS
will subscribe you to the corresponding source package.
-<tag><tt>unsubscribe <srcpackage> [<email>]</tt>
+<tag><tt>unsubscribe <sourcepackage> [<email>]</tt>
<item>
- Removes a previous subscription to the source package <var>srcpackage</var>
+ Removes a previous subscription to the source package <var>sourcepackage</var>
using the specified email address or the sender address if the second
argument is left out.
<tag><tt>keyword [<email>]</tt>
<item>
- Tells you the keywords that you are accepting. Each mail sent through
- the Package Tracking System is associated to a keyword and you receive
- only the mails associated to keywords that you are accepting. Here is
- the list of available keywords:
+ Tells you the keywords that you are accepting.
+ For an explanation of keywords, <qref id="pkg-tracking-system">see
+ above</qref>. Here's a quick summary:
<list>
<item><tt>bts</tt>: mails coming from the Debian Bug Tracking System
<item><tt>bts-control</tt>: reply to mails sent to &email-bts-control;
<item><tt>default</tt>: all the other mails (those which aren't "automatic")
</list>
-<tag><tt>keyword <srcpackage> [<email>]</tt>
+<tag><tt>keyword <sourcepackage> [<email>]</tt>
<item>
- Same as previous item but for the given source package since
+ Same as the previous item but for the given source package, since
you may select a different set of keywords for each source package.
<tag><tt>keyword [<email>] {+|-|=} <list of keywords></tt>
<item>
- Accept (+) or refuse (-) mails associated to the given keyword(s).
+ Accept (+) or refuse (-) mails classified under the given keyword(s).
Define the list (=) of accepted keywords.
-<tag><tt>keyword <srcpackage> [<email>] {+|-|=} <list of keywords></tt>
+<tag><tt>keyword <sourcepackage> [<email>] {+|-|=} <list of keywords></tt>
<item>
Same as previous item but overrides the keywords list for the
indicated source package.
<sect1 id="pts-mail-filtering">Filtering PTS mails
<p>
Once you are subscribed to a package, you will get the mails sent to
-<tt><var>srcpackage</var>@packages.qa.debian.org</tt>. Those mails
+<tt><var>sourcepackage</var>@packages.qa.debian.org</tt>. Those mails
have special headers appended to let you filter them in a special
-mailbox with <prgn>procmail</prgn>. The added headers are
+mailbox (e.g. with <prgn>procmail</prgn>). The added headers are
<tt>X-Loop</tt>, <tt>X-PTS-Package</tt>, <tt>X-PTS-Keyword</tt> and
<tt>X-Unsubscribe</tt>.
<p>
<sect1 id="pts-cvs-commit">Forwarding CVS commits in the PTS
<p>
If you use a publicly accessible CVS repository for maintaining
-your Debian package you may want to forward the commit notification
-to the PTS so that the subscribers (possible co-maintainers) can
+your Debian package, you may want to forward the commit notification
+to the PTS so that the subscribers (and possible co-maintainers) can
closely follow the package's evolution.
<p>
-It's very easy to setup. Once your CVS repository generates commit
-notifications, you just have to make sure it sends a copy of those mails
-to <tt><var>srcpackage</var>_cvs@&pts-host;</tt>. Only people who
-accepts the <em>cvs</em> keyword will receive the notifications.
+Once you set up the CVS repository to generate commit notifications,
+you just have to make sure it sends a copy of those mails
+to <tt><var>sourcepackage</var>_cvs@&pts-host;</tt>. Only the people
+who accept the <em>cvs</em> keyword will receive these notifications.
+
+ <sect1 id="pts-web">The PTS web interface
+ <p>
+The PTS has a web interface at <url id="http://&pts-host;/"> that puts
+together a lot of information about each source package. It features many useful
+links (BTS, QA stats, contact information, DDTP translation status,
+buildd logs) and gathers much more information from various places
+(30 latest changelog entries, testing status, ...). It's a very useful
+tool if you want to know what's going on with a specific source
+package. Furthermore there's a form that allows easy subscription to
+the PTS via email.
+ <p>
+You can jump directly to the web page concerning a specific source package
+with a URL like <tt>http://&pts-host;/<var>sourcepackage</var></tt>.
+ <p>
+This web interface has been designed like a portal for the development of
+packages: you can add custom content on your packages' pages. You can
+add "static information" (news items that are meant to stay available
+indefinitely) and news items in the "latest news" section.
+ <p>
+Static news items can be used to indicate:
+<list>
+<item>the availability of a project hosted on <qref id="alioth">Alioth</qref> for co-maintaining the package
+<item>a link to the upstream web site
+<item>a link to the upstream bug tracker
+<item>the existence of an IRC channel dedicated to the software
+<item>any other available resource that could be useful in the maintenance of the package
+</list>
+Usual news items may be used to announce that:
+<list>
+<item>beta packages are available for testing
+<item>final packages are expected for next week
+<item>the packaging is about to be redone from scratch
+<item>backports are available
+<item>the maintainer is on vacation (if they wish to publish this information)
+<item>a NMU is being worked on
+<item>something important will affect the package
+</list>
+ <p>
+Both kinds of news are generated in a similar manner: you just have to send
+an email either to <email>pts-static-news@qa.debian.org</email> or to
+<email>pts-news@qa.debian.org</email>. The mail should indicate which
+package is concerned by having the name of the source package in a
+<tt>X-PTS-Package</tt> mail header or in a <tt>Package</tt> pseudo-header (like the
+BTS reports). If a URL is available in the <tt>X-PTS-Url</tt> mail header or in
+the <tt>Url</tt> pseudo-header, then the result is a link to that URL instead
+of a complete news item.
+ <p>
+Here are a few examples of valid mails used to generate news items in
+the PTS. The first one adds a link to the cvsweb interface of debian-cd
+in the "Static information" section:
+<example>
+From: Raphael Hertzog <hertzog@debian.org>
+To: pts-static-news@qa.debian.org
+Subject: Browse debian-cd CVS repository with cvsweb
+
+Package: debian-cd
+Url: http://cvs.debian.org/debian-cd/
+</example>
+ <p>
+The second one is an announcement sent to a mailing list which is also sent
+to the PTS so that it is published on the PTS web page of the package. Note the
+use of the BCC field to avoid answers sent to the PTS by mistake.
+<example>
+From: Raphael Hertzog <hertzog@debian.org>
+To: debian-gtk-gnome@lists.debian.org
+Bcc: pts-news@qa.debian.org
+Subject: Galeon 2.0 backported for woody
+X-PTS-Package: galeon
+
+Hello gnomers!
+
+I'm glad to announce that galeon has been backported for woody. You'll find
+everything here:
+...
+</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
+that you can do is send a second news item that will deprecate the
+information contained in the previous one.
<sect id="ddpo">Developer's packages overview
<p>
you don't forget any open bug, and so that you don't forget which
packages are under your responsibility.
+ <sect id="alioth">Debian *Forge: Alioth
+ <p>
+Alioth is a fairly new Debian service, based on a slightly modified version
+of the GForge software (which evolved from SourceForge). This software
+offers developers access to easy-to-use tools such as bug trackers, patch
+manager, project/task managers, file hosting services, mailing lists, CVS
+repositories etc. All these tools are managed via a web interface.
+ <p>
+It is intended to provide facilities to free software projects backed or led
+by Debian, facilitate contributions from external developers to projects
+started by Debian, and help projects whose goals are the promotion of Debian
+or its derivatives.
+ <p>
+For more information please visit <url id="&url-alioth;">.
+
<chapt id="pkgs">Managing Packages
<p>
pseudo-package <package>wnpp</package>
describing your plan to create a new package, including, but not
limiting yourself to, a description of the package, the license of the
-prospective package and the current URL where it can be downloaded
+prospective package, and the current URL where it can be downloaded
from.
<p>
You should set the subject of the bug to ``ITP: <var>foo</var>
of the message (no, don't use <tt>CC:</tt>, because that way the message's subject
won't indicate the bug number).
<p>
-Please include a <tt>Closes: bug#<var>nnnnn</var></tt> entry on the
+Please include a <tt>Closes: bug#<var>nnnnn</var></tt> entry in the
changelog of the new package in order for the bug report to be
-automatically closed once the new package is installed on the archive
-(<ref id="upload-bugfix">).
+automatically closed once the new package is installed in the archive
+(see <ref id="upload-bugfix">).
<p>
There are a number of reasons why we ask maintainers to announce their
intentions:
the package is installed into the archive. See <ref
id="upload-bugfix">.
<p>
-It is conventional that the changelog entry notating of a package that
+It is conventional that the changelog entry of a package that
contains a new upstream version of the software looks like this:
<example>
* new upstream version
`testing-security', but read <ref id="bug-security"> for more information on
those.
<p>
-It is technically possible to upload a package into several distributions
-at the same time but it usually doesn't make sense to use that feature
-because the dependencies of the package may vary with the distribution.
-In particular, it never makes sense to combine the <em>experimental</em>
-distribution with anything else.
+It is not possible to upload a package into several distributions
+at the same time.
- <sect1 id="upload-stable">Uploads to <em>stable</em>
+ <sect1 id="upload-stable">
+ <heading>Special case: uploads to the <em>stable</em> distribution</heading>
<p>
Uploading to <em>stable</em> means that the package will be placed into the
<file>stable-proposed-updates</file> directory of the Debian archive for further
Extra care should be taken when uploading to <em>stable</em>. Basically, a
package should only be uploaded to stable if one of the following happens:
<list>
- <item>a security problem (e.g. a Debian security advisory)
<item>a truly critical functionality problem
<item>the package becomes uninstallable
<item>a released architecture lacks the package
</list>
+<p>
+In the past, uploads to <em>stable</em> were used to address security
+problems as well. However, this practice is deprecated, as uploads
+used for Debian security advisories are automatically copied to the
+appropriate <file>proposed-updates</file> archive when the advisory is
+released. See <ref id="bug-security"> for detailed information on
+handling security problems.
<p>
-It is discouraged to change anything else in the package that isn't
-important, because even trivial fixes can cause bugs later on. Uploading
-new upstream versions to fix security problems is deprecated; applying the
-specific patch from the new upstream version to the old one ("back-porting"
-the patch) is the right thing to do in most cases.
+Changing anything else in the package that isn't important is discouraged,
+because even trivial fixes can cause bugs later on.
<p>
Packages uploaded to <em>stable</em> need to be compiled on systems running
<em>stable</em>, so that their dependencies are limited to the libraries
verbose, if necessary) in your changelog entries for uploads to
<em>stable</em>, because otherwise the package won't be considered for
inclusion.
-
- <sect1 id="upload-t-p-u">Uploads to <em>testing-proposed-updates</em>
- <p>
-The testing distribution is fed with packages from unstable according to the rules
-explained in <ref id="testing">. However, the release manager may stop the testing
-scripts when he wants to freeze the distribution. In that case, you may want to
-upload to <em>testing-proposed-updates</em> to provide fixed packages during the freeze.
<p>
-Keep in mind that packages uploaded there are not automatically processed, they
-have to go through the hands of the release manager. So you'd better have a good
-reason to upload there. In order to know what a good reason is in the
-release manager's eyes, you should read the instructions that he regularly
-gives on &email-debian-devel-announce;.
+It's best practice to speak with the stable release manager <em>before</em>
+uploading to <em>stable</em>/<em>stable-proposed-updates</em>, so that the
+uploaded package fits the needs of the next point release.
+
+ <sect1 id="upload-t-p-u">
+ <heading>Special case: uploads to <em>testing/testing-proposed-updates</em></heading>
<p>
-You should not upload to <em>testing-proposed-updates</em> when you can update your
-packages through <em>unstable</em>. If you can't (for example because you have a
-newer development version in unstable), you may use it but it is recommended to ask
-the authorization of the release manager before.
+Please see the information in the <qref id="t-p-u">testing section</qref> for details.
<sect id="upload">Uploading a package
<sect1 id="upload-ftp-master">Uploading to <tt>ftp-master</tt>
<p>
-To upload a package, you need a personal account on
-<ftpsite>&ftp-master-host;</ftpsite>, which you should have as an
-official maintainer. If you use <prgn>scp</prgn> or <prgn>rsync</prgn>
-to transfer the files, place them into &us-upload-dir;;
-if you use anonymous FTP to upload, place them into
-&upload-queue;.
+To upload a package, you should upload the files (including the signed
+changes and dsc-file) with anonymous ftp to
+<ftpsite>&ftp-master-host;</ftpsite> in the directory &upload-queue;.
+To get the files processed there, they need to be signed with a key in the
+debian keyring.
<p>
Please note that you should transfer
the changes file last. Otherwise, your upload may be rejected because the
archive maintenance software will parse the changes file and see that not
-all files have been uploaded. If you don't want to bother with transferring
-the changes file last, you can simply copy your files to a temporary
-directory on <tt>ftp-master</tt> and then move them to
-&us-upload-dir;.
- <p>
+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 can not be uploaded to
+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 the overseas upload
-queues on <tt>chiark</tt> or <tt>erlangen</tt>. If you are not sure
+<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
+when uploading packages. These handy programs help automate the
process of uploading packages into Debian.
<p>
-After uploading your package, you can check how the archive
-maintenance software will process it by running <prgn>dinstall</prgn>
-on your changes file:
-<example>dinstall -n foo.changes</example>
- <p>
-Note that <prgn>dput</prgn> can do this for you automatically.
+For removing packages, please see the README file in that ftp directory,
+and the Debian package <ref id="dcut">.
<sect1 id="upload-non-us">Uploading to <tt>non-US</tt>
<p>
-As discussed above, export controlled software should not be uploaded
-to <tt>ftp-master</tt>. Instead, upload the package to
-<ftpsite>non-us.debian.org</ftpsite>, placing the files in
-&non-us-upload-dir; (again, both <ref id="dupload"> and <ref
-id="dput"> can do this for you if invoked properly). By default,
-you can use the same account/password that works on
-<tt>ftp-master</tt>. If you use anonymous FTP to upload, place the
-files into &upload-queue;.
+<em>Note:</em> non-us is currently not processed any more.
<p>
-You can check your upload the same way it's done on <tt>ftp-master</tt>,
-with:
-<example>dinstall -n foo.changes</example>
+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
residents consult a lawyer before doing uploads to non-US.
- <sect1>Uploads via <tt>chiark</tt>
- <p>
-If you have a slow network connection to <tt>ftp-master</tt>, there are
-alternatives. One is to upload files to <file>Incoming</file> via a
-upload queue in Europe on <tt>chiark</tt>. For details connect to
-<url id="&url-chiark-readme;">.
- <p>
-<em>Note:</em> Do not upload packages containing software that is
-export-controlled by the United States government to the queue on
-<tt>chiark</tt>. Since this upload queue goes to <tt>ftp-master</tt>, the
-prescription found in <ref id="upload-ftp-master"> applies here as well.
- <p>
-The program <prgn>dupload</prgn> comes with support for uploading to
-<tt>chiark</tt>; please refer to the documentation that comes with the
-program for details.
-
-
- <sect1>Uploads via <tt>erlangen</tt>
+ <sect1 id="delayed-incoming">Delayed uploads
<p>
-Another upload queue is available in Germany: just upload the files
-via anonymous FTP to <url id="&url-upload-erlangen;">.
+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.
<p>
-The upload must be a complete Debian upload, as you would put it into
-<tt>ftp-master</tt>'s <file>Incoming</file>, i.e., a <file>.changes</file> files
-along with the other files mentioned in the <file>.changes</file>. The
-queue daemon also checks that the <file>.changes</file> is correctly
-signed with GnuPG or OpenPGP by a Debian developer, so that no bogus files can find
-their way to <tt>ftp-master</tt> via this queue. Please also make sure that
-the <tt>Maintainer</tt> field in the <file>.changes</file> contains
-<em>your</em> e-mail address. The address found there is used for all
-replies, just as on <tt>ftp-master</tt>.
- <p>
-There's no need to move your files into a second directory after the
-upload, as on <tt>chiark</tt>. And, in any case, you should get a
-mail reply from the queue daemon explaining what happened to your
-upload. Hopefully it should have been moved to <tt>ftp-master</tt>, but in
-case of errors you're notified, too.
+With a fairly recent dput, this section
+<example>
+[tfheen_delayed]
+method = scp
+fqdn = gluck.debian.org
+incoming = ~tfheen
+</example>
+in ~/.dput.cf should work fine for uploading to the DELAYED queue.
<p>
-<em>Note:</em> Do not upload packages containing software that is
-export-controlled by the United States government to the queue on
-<tt>erlangen</tt>. Since this upload queue goes to <tt>ftp-master</tt>, the
+<em>Note:</em>
+Since this upload queue goes to <tt>ftp-master</tt>, the
prescription found in <ref id="upload-ftp-master"> applies here as well.
- <p>
-The program <prgn>dupload</prgn> comes with support for uploading to
-<tt>erlangen</tt>; please refer to the documentation that comes with
-the program for details.
+ <sect1>Security uploads
+ <p>
+Do NOT 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.
+For details, please see section <ref id="bug-security">.
<sect1>Other upload queues
<p>
-Another upload queue is available which is based in the US, and is a
-good backup when there are problems reaching <tt>ftp-master</tt>. You can
-upload files, just as in <tt>erlangen</tt>, to <url
-id="&url-upload-samosa;">.
+The scp queues on ftp-master, non-us, and security are mostly unusable
+due to the login restrictions on those hosts.
<p>
-An upload queue is available in Japan: just upload the files via
-anonymous FTP to <url id="&url-upload-jp;">.
-
+The anonymous queues on ftp.uni-erlangen.de and ftp.uk.debian.org are
+currently down. Work is underway to resurrect those.
+ <p>
+The queues on master.debian.org, samosa.debian.org, master.debian.or.jp,
+and ftp.chiark.greenend.org.uk are down permanently, and will not be
+resurrected. The queue in Japan will be replaced with a new queue on
+hp.debian.or.jp some day.
+ <p>
+For the time being, the anonymous ftp queue on auric.debian.org (the
+former ftp-master) works, but it is deprecated and will be removed at
+some point in the future.
<sect1 id="upload-notification">
<heading>Notification that a new package has been installed</heading>
section the package was inserted into. If there is a disparity, you
will receive a separate email notifying you of that. Read on below.
<p>
-Note also that if you upload via queues, the queue daemon software will
+Note that if you upload via queues, the queue daemon software will
also send you a notification by email.
- <sect id="override-file">Determining section and priority of a package
+ <sect id="override-file">Specifying the package section, subsection and priority
<p>
The <file>debian/control</file> file's <tt>Section</tt> and
<tt>Priority</tt> fields do not actually specify where the file will
name="dpkg-scanpackages" section="8"> and
<url id="&url-bts-devel;#maintincorrect">.
<p>
-Note also that the term "section" is used for the separation of packages
-according to their licensing, e.g. <em>main</em>, <em>contrib</em> and
-<em>non-free</em>. This is described in another section, <ref id="archive">.
+Note that the <tt>Section</tt> field describes both the section as
+well as the subsection, which are described in <ref
+id="archive-sections">. If the section is "main", it should be
+omitted. The list of allowable subsections can be found in <url
+id="&url-debian-policy;ch-archive.html#s-subsections">.
- <sect id="bug-handling">Handling package bugs
+ <sect id="bug-handling">Handling bugs
+ <p>
+Every developer has to be able to work with the Debian <url name="bug
+tracking system" id="&url-bts;">. This includes knowing how to file bug
+reports properly (see <ref id="submit-bug">), how to update them and
+reorder them, and how to process and close them.
+ <p>
+The bug tracking system's features are described
+in the <url id="&url-bts-devel;" name="BTS documentation for developers">.
+This includes closing bugs, sending followup messages, assigning severities
+and tags, marking bugs as forwarded, and other issues.
<p>
-Often as a package maintainer, you find bugs in other packages or else
-have bugs reported to your packages which need to be reassigned. The
-<url id="&url-bts-control;" name="BTS instructions"> can tell you how
-to do this. Some information on filing bugs can be found in <ref
-id="submit-bug">.
+Operations such as reassigning bugs to other packages, merging separate
+bug reports about the same issue, or reopening bugs when they are
+prematurely closed, are handled using the so-called control mail server.
+All of the commands available in this server are described in the
+<url id="&url-bts-control;" name="BTS control server documentation">.
<sect1 id="bug-monitoring">Monitoring bugs
<p>
<sect1 id="bug-answering">Responding to bugs
<p>
-Make sure that any discussion you have about bugs are sent both to
-the original submitter of the bug, and the bug itself (e.g.,
-<email>123@&bugs-host;</email>). If you're writing a new
+When responding to bugs, make sure that any discussion you have about
+bugs is sent both to the original submitter of the bug, and to the bug
+itself (e.g., <email>123@&bugs-host;</email>). If you're writing a new
mail and you don't remember the submitter email address, you can
use the <email>123-submitter@&bugs-host;</email> email to
contact the submitter <em>and</em> to record your mail within the
bug log (that means you don't need to send a copy of the mail to
<email>123@&bugs-host;</email>).
<p>
+If you get a bug which mentions "FTBFS", that means "Fails to build
+from source". Porters frequently use this acronym.
+ <p>
Once you've dealt with a bug report (e.g. fixed it), mark it as
<em>done</em> (close it) by sending an explanation message to
<email>123-done@&bugs-host;</email>. If you're fixing a bug by
<p>
As a package maintainer, you will often find bugs in other packages or
have bugs reported against your packages which are actually bugs in
-other packages. The bug tracking system's features interesting to developers
+other packages. The bug tracking system's features
are described in the <url id="&url-bts-devel;" name="BTS documentation for
Debian developers">. Operations such as reassigning, merging, and tagging
bug reports are described in the <url id="&url-bts-control;" name="BTS
some guidelines for managing your own bugs, based on the collective
Debian developer experience.
<p>
-Filing bugs for problems that you find in other packages is one of
+Filing bugs for problems that you find in other packages is one of
the "civic obligations" of maintainership, see <ref id="submit-bug">
for details. However, handling the bugs in your own packages is
even more important.
Decide whether the report corresponds to a real bug or not. Sometimes
users are just calling a program in the wrong way because they haven't
read the documentation. If you diagnose this, just close the bug with
-enough information to let the user correct his problem (give pointers
+enough information to let the user correct their problem (give pointers
to the good documentation and so on). If the same report comes up
again and again you may ask yourself if the documentation is good
enough or if the program shouldn't detect its misuse in order to
give an informative error message. This is an issue that may need
-to be brought to the upstream author.
+to be brought up with the upstream author.
<p>
-If the bug submitter disagree with your decision to close the bug,
+If the bug submitter disagrees with your decision to close the bug,
they may reopen it until you find an agreement on how to handle it.
If you don't find any, you may want to tag the bug <tt>wontfix</tt>
to let people know that the bug exists but that it won't be corrected.
doing so, please read the <url id="&url-tech-ctte;" name="recommended procedure">.
<item>
If the bug is real but it's caused by another package, just reassign
-the bug the right package. If you don't know which package it should
-be reassigned to, you may either ask for help on &email-debian-devel; or
-reassign it to <package>debian-policy</package> to let them decide which
-package is in fault.
+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;.
<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
Some bugs may even be dropped to wishlist severity when the requested
change is just cosmetic.
<item>
-The bug submitter may have forgotten to provide some information, in that
-case you have to ask him the information required. You may use the
+If the bug is real but the same problem has already been reported by
+someone else, then the two relevant bug reports should be merged
+into one using the merge command of the BTS.
+In this way, when the
+bug is fixed, all of the submitters will be informed of this.
+(Note, however, that emails sent to one bug report's submitter won't
+automatically be sent to the other report's submitter.)
+For more
+details on the technicalities of the merge command and its relative,
+the unmerge command, see the BTS control server documentation.
+ <item>
+The bug submitter may have forgotten to provide some information, in which
+case you have to ask them the required information. You may use the
<tt>moreinfo</tt> tag to mark the bug as such. Moreover if you can't
reproduce the bug, you tag it <tt>unreproducible</tt>. Anyone who
can reproduce the bug is then invited to provide more information
the bug has been fixed or not. If it has, you just close it, otherwise
you have to remind the author about it. If you have the required skills
you can prepare a patch that fixes the bug and that you send at the
-same time to the author. Make sure to send the patch in the BTS and to
+same time to the author. Make sure to send the patch to the BTS and to
tag the bug as <tt>patch</tt>.
<item>
If you have fixed a bug in your local copy, or if a fix has been
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.)
+ <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
wrongly closed bugs, send an <tt>reopen <var>XXX</var></tt> command to
don't have anything to do with an upload you made, do it by emailing
an explanation to <email>XXX-done@&bugs-host;</email>. Do
<strong>not</strong> close bugs in the changelog entry of a version if
-the changes in that version of the package doesn't have any bearing on
+the changes in that version of the package don't have any bearing on
the bug.
<p>
For general information on how to write your changelog entries, see
<!-- information about the security database goes here once it's ready -->
<!-- (mdz) -->
- <sect2 id="bug-security-you">What to do when you learn of a
- security problem
- <p>
+<p>
When you become aware of a security-related bug in a Debian package,
whether or not you are the maintainer, collect pertinent information
-about the problem, and promptly contact the security team at
-&email-security-team;.
+about the problem, and promptly contact the security team at
+&email-security-team; as soon as possible. <strong>DO NOT UPLOAD</strong> any
+packages for stable; the security team will do that.
+
Useful information includes, for example:
<list compact>
especially helpful)
<item>Any fixed packages that you have prepared yourself (send only
- the <tt>.diff.gz</tt> and <tt>.dsc</tt> files)
+ the <tt>.diff.gz</tt> and <tt>.dsc</tt> files and read <ref
+ id="bug-security-building"> first)
+
+ <item>Any assistance you can provide to help with testing (exploits,
+ regression testing, etc.)
<item>Any information needed for the advisory (see <ref
id="bug-security-advisories">)
<sect2 id="bug-security-confidentiality">Confidentiality
<p>
Unlike most other activities within Debian, information about security
-issues must sometimes be kept private for a time. Whether this is the
+issues must sometimes be kept private for a time.
+This allows software distributors to coordinate their disclosure in
+order to minimize their users' exposure. Whether this is the
case depends on the nature of the problem and corresponding fix, and
whether it is already a matter of public knowledge.
+
<p>
-There are a few ways a developer can learn of a security problem:
+There are a few ways developers can learn of a security problem:
<list compact>
- <item>he notices it on a public forum (mailing list, web site, etc.)
+ <item>they notice it on a public forum (mailing list, web site, etc.)
<item>someone files a bug report
- <item>someone informs him via private email
+ <item>someone informs them via private email
</list>
In the first two cases, the information is public and it is important
possible options for dealing with the problem:
<list>
- <item>if it is a trivial problem (like insecure temporary files)
- there is no need to keep the problem a secret and a fix should be
- made and released.
+ <item>If the security exposure is minor, there is sometimes no need
+ to keep the problem a secret and a fix should be made and released.
- <item>if the problem is severe (remotely exploitable, possibility to
- gain root privileges) it is preferable to share the information with
+ <item>If the problem is severe, it is preferable to share the
+ information with
other vendors and coordinate a release. The security team keeps
contacts with the various organizations and individuals and can take
care of that.
</list>
<p>
- In all cases if the person who reports the problem asks to not
- disclose the information that should be respected, with the obvious
- exception of informing the security team (make sure you tell the
- security team that the information can not be disclosed).
+ In all cases if the person who reports the problem asks that it not
+ be disclosed, such requests should be honored, with the obvious
+ exception of informing the security team in order that a fix may be
+ produced for a stable release of Debian. When sending confidential
+ information to the security team, be sure to mention this fact.
<p>
-Please note that if secrecy is needed you can also not upload a fix to
-unstable (or anywhere else), since the changelog and diff information
-for unstable is public.
+Please note that if secrecy is needed you may not upload a fix to
+unstable (or anywhere else, such as a public CVS repository). It is
+not sufficient to obfuscate the details of the change, as the code
+itself is public, and can (and will) be examined by the general public.
<p>
There are two reasons for releasing information even though secrecy is
-requested: the problem has been known for a while, or that the problem
+requested: the problem has been known for a while, or the problem
or exploit has become public.
<sect2 id="bug-security-advisories">Security Advisories
<p>
Security advisories are only issued for the current, released stable
-distribution, not for testing or unstable. When released, advisories
+distribution, and <em>not</em> for testing or unstable. When released,
+advisories
are sent to the &email-debian-security-announce;
+
mailing list and posted on <url
id="&url-debian-security-advisories;" name="the security web page">.
Security advisories are written and posted by the security
-team. However they certainly do not mind if a maintainer can supply
-some of the information for them, or write part of the
-text. Information that should be in an advisory includes:
+team. However they certainly do not mind if a
+maintainer can supply some of the information for them, or write part
+of the text. Information that should be in an advisory includes:
<list compact>
<item>A description of the problem and its scope, including:
<list>
<item>The type of problem (privilege escalation, denial of
service, etc.)
+ <item>What privileges may be gained, and by whom (if any)
<item>How it can be exploited
<item>Whether it is remotely or locally exploitable
<item>How the problem was fixed
</list>
+
+ This information allows users to assess the threat to their systems.
+
<item>Version numbers of affected packages
<item>Version numbers of fixed packages
<item>Information on where to obtain the updated packages
+ (usually from the Debian security archive)
<item>References to upstream advisories, <url
id="http://cve.mitre.org" name="CVE"> identifiers, and any other
information useful in cross-referencing the vulnerability
<heading>Preparing packages to address security issues</heading>
<p>
One way that you can assist the security team in their duties is to
-provide fixed packages suitable for a security advisory for the stable
+provide them with fixed packages suitable for a security advisory for
+the stable
Debian release.
<p>
When an update is made to the stable release, care must be taken to
avoid changing system behavior or introducing new bugs. In order to
do this, make as few changes as possible to fix the bug. Users and
administrators rely on the exact behavior of a release once it is
- made, so any change that is made might break someone's system.
- This is especially true of libraries: make sure you never change the
- API or ABI, no matter how small the change.
+ made, so any change that is made might break someone's system. This
+ is especially true of libraries: make sure you never change the API or
+ ABI, no matter how small the change.
<p>
This means that moving to a new upstream version is not a good
solution. Instead, the relevant changes should be back-ported to the
In some cases, it is not possible to back-port a security fix, for
example when large amounts of source code need to be modified or
rewritten. If this happens, it may be necessary to move to a new
-upstream version. However, you must always coordinate that with the
-security team beforehand.
+upstream version. However, this is only done in extreme situations,
+and you must always coordinate that with the security team beforehand.
<p>
Related to this is another important guideline: always test your
changes. If you have an exploit available, try it and see if it
package. Test other, normal actions as well, as sometimes a security
fix can break seemingly unrelated features in subtle ways.
<p>
+Do <strong>NOT</strong> include any changes in your package which are
+not directly related to fixing the vulnerability. These will only
+need to be reverted, and this wastes time. If there are other bugs in
+your package that you would like to fix, make an upload to
+proposed-updates in the usual way, after the security advisory is
+issued. The security update mechanism is not a means for introducing
+changes to your package which would otherwise be rejected from the
+stable release, so please do not attempt to do this.
+<p>
Review and test your changes as much as possible. Check the
differences from the previous version repeatedly
(<prgn>interdiff</prgn> from the <package>patchutils</package> package
and <prgn>debdiff</prgn> from <package>devscripts</package> are useful
tools for this, see <ref id="debdiff">).
<p>
-When packaging the fix, keep the following points in mind:
+Be sure to verify the following items:
<list>
- <item>Make sure you target the right distribution in your
+ <item>Target the right distribution in your
<file>debian/changelog</file>. For stable this is <tt>stable-security</tt> and for
testing this is <tt>testing-security</tt>, and for the previous
stable release, this is <tt>oldstable-security</tt>. Do not target
- <var>distribution</var>-proposed-updates!
+ <var>distribution</var>-proposed-updates or <tt>stable</tt>!
+
+ <item>The upload should have urgency=high.
+
+ <item>Make descriptive, meaningful changelog entries. Others will
+ rely on them to determine whether a particular bug was fixed.
+ Always include an external reference, preferably a CVE
+ identifier, so that it can be cross-referenced. Include the same
+ information in the changelog for unstable, so that it is clear that
+ the same bug was fixed, as this is very helpful when verifying
+ that the bug is fixed in the next stable release. If a CVE
+ identifier has not yet been assigned, the security team will
+ request one so that it can be included in the package and in the advisory.
<item>Make sure the version number is proper. It must be greater
than the current package, but less than package versions in later
distributions. If in doubt, test it with <tt>dpkg
- --compare-versions</tt>. For <em>testing</em>, there must be
+ --compare-versions</tt>. Be careful not to re-use a version
+ number that you have already used for a previous upload. For
+ <em>testing</em>, there must be
a higher version in <em>unstable</em>. If there is none yet (for example,
if <em>testing</em> and <em>unstable</em> have the same version) you must upload a
new version to unstable first.
not build those. This point applies to normal package uploads as
well.
- <item>If the upstream source has been uploaded to
+ <item>Unless the upstream source has been uploaded to
security.debian.org before (by a previous security update), build
- the upload without the upstream source (<tt>dpkg-buildpackage
- -sd</tt>). Otherwise, build with full source
- (<tt>dpkg-buildpackage -sa</tt>).
+ the upload with full upstream source (<tt>dpkg-buildpackage
+ -sa</tt>). If there has been a previous upload to
+ security.debian.org with the same upstream version, you may upload
+ without upstream source (<tt>dpkg-buildpackage -sd</tt>).
<item>Be sure to use the exact same <file>*.orig.tar.gz</file> as used in the
normal archive, otherwise it is not possible to move the security
fix into the main archives later.
- <item>Be sure, when compiling a package, to compile on a clean
+ <item>Build the package on a clean
system which only has packages installed from the distribution you
are building for. If you do not have such a system yourself, you
can use a debian.org machine (see <ref id="server-machines">)
<sect2 id="bug-security-upload">Uploading the fixed package
<p>
-<em>DO NOT</em> upload a package to the security upload queue without
+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.
<p>
-<em>DO NOT</em> upload your fix to proposed-updates without
+Do <strong>NOT</strong> upload your fix to proposed-updates without
coordinating with the security team. Packages from
security.debian.org will be copied into the proposed-updates directory
automatically. If a package with the same or a higher version number
<var>distribution</var>-proposed-updates on ftp-master or in the non-US
archive.
-
<sect id="archive-manip">
<heading>Moving, removing, renaming, adopting, and orphaning
packages</heading>
<p>
Sometimes a package will change its section. For instance, a
package from the `non-free' section might be GPL'd in a later version,
-in which case, the package should be moved to `main' or
+in which case the package should be moved to `main' or
`contrib'.<footnote> See the <url id="&url-debian-policy;"
name="Debian Policy Manual"> for guidelines on what section a package
belongs in.
removed. For example, you can provide the name of the package that
supersedes the one to be removed.
<p>
-Usually you only ask the removal of a package maintained by yourself.
+Usually you only ask for the removal of a package maintained by yourself.
If you want to remove another package, you have to get the approval
-of its last maintainer.
+of its maintainer.
<p>
If in doubt concerning whether a package is disposable, email
&email-debian-devel; asking for opinions. Also of interest is the
package. When invoked as <tt>apt-cache showpkg
<var>package</var></tt>, the program will show details for
<var>package</var>, including reverse depends.
+Removal of orphaned packages is discussed on &email-debian-qa;.
<p>
Once the package has been removed, the package's bugs should be handled.
They should either be reassigned to another package in the case where
In the past, it was possible to remove packages from <file>incoming</file>.
However, with the introduction of the new incoming system, this is no longer
possible. Instead, you have to upload a new revision of your package with
-a higher version as the package you want to replace. Both versions will be
+a higher version than the package you want to replace. Both versions will be
installed in the archive but only the higher version will actually be
available in <em>unstable</em> since the previous version will immediately
be replaced by the higher. However, if you do proper testing of your
<sect1>Replacing or renaming packages
<p>
-Sometimes you made a mistake naming the package and you need to rename
-it. In this case, you need to follow a two-step process. First, set
+When you make a mistake naming your package, you should follow a two-step
+process to rename it. First, set
your <file>debian/control</file> file to replace and conflict with the
obsolete name of the package (see the <url id="&url-debian-policy;"
name="Debian Policy Manual"> for details). Once you've uploaded
against the pseudo package <package>wnpp</package>. The bug report should be
titled <tt>O: <var>package</var> -- <var>short description</var></tt>
indicating that the package is now orphaned. The severity of the bug
-should be set to <em>normal</em>. If you feel it's necessary, send a copy
+should be set to <em>normal</em>; if the package has a priority of standard
+or higher, it should be set to important.
+If you feel it's necessary, send a copy
to &email-debian-devel; by putting the address in the X-Debbugs-CC: header
of the message (no, don't use CC:, because that way the message's subject
won't indicate the bug number).
<p>
-If the package is especially crucial to Debian, you should instead submit
+If you just intend to give the package away, but you can keep maintainership
+for the moment, then you should instead submit
a bug against <package>wnpp</package> and title it <tt>RFA: <var>package</var> --
-<var>short description</var></tt> and set its severity to
-<em>important</em>. <tt>RFA</tt> stands for <em>Request For Adoption</em>.
-Definitely copy the message to debian-devel in this case, as described
-above.
+<var>short description</var></tt>.
+<tt>RFA</tt> stands for <em>Request For Adoption</em>.
<p>
-Read instructions on the <url id="&url-wnpp;" name="WNPP web pages">
-for more information.
+More information is on the <url id="&url-wnpp;" name="WNPP web pages">.
<sect1 id="adopting">Adopting a package
<p>
most of this chapter.
<p>
Porting is the act of building Debian packages for architectures that
-is different from the original architecture of the package
+are different from the original architecture of the package
maintainer's binary package. It is a unique and essential activity.
In fact, porters do most of the actual compiling of Debian packages.
For instance, for a single <em>i386</em> binary package, there must be
committed by Debian maintainers — common problems which often stymie
porters, and make their jobs unnecessarily difficult.
<p>
-The first and most important watchword is to respond quickly to bug or
+The first and most important thing is to respond quickly to bug or
issues raised by porters. Please treat porters with courtesy, as if
-they were in fact co-maintainers of your package (which in a way, they
-are). Please be tolerant of succinct or even unclear bug reports,
-doing your best to hunt down whatever the problem is.
+they were in fact co-maintainers of your package (which, in a way, they
+are). Please be tolerant of succinct or even unclear bug reports;
+do your best to hunt down whatever the problem is.
<p>
By far, most of the problems encountered by porters are caused by
<em>packaging bugs</em> in the source packages. Here is a checklist
Make sure you don't rely on locally installed or hacked configurations
or programs. For instance, you should never be calling programs in
<file>/usr/local/bin</file> or the like. Try not to rely on programs
-be setup in a special way. Try building your package on another
+being setup in a special way. Try building your package on another
machine, even if it's the same architecture.
<item>
-Don't depend on the package you're building already being installed (a
+Don't depend on the package you're building being installed already (a
sub-case of the above issue).
<item>
Don't rely on the compiler being a certain version, if possible. If
``binary-indep'' targets, as the Debian Policy Manual requires.
Make sure that both targets work independently, that is, that you can
call the target without having called the other before. To test this,
-try to run <tt>dpkg-buildpackage -b</tt>.
+try to run <tt>dpkg-buildpackage -B</tt>.
</enumlist>
set <var>porter-email</var> to your email address. This will do a
binary-only build of only the architecture-dependent portions of the
package, using the `binary-arch' target in <file>debian/rules</file>.
+ <p>
+If you are working on a Debian machine for your porting efforts and you
+need to sign your upload locally for its acceptance in the archive, you
+can run <prgn>debsign</prgn> on your <file>.changes</file> file to have
+it signed conveniently, or use the remote signing mode of <prgn>dpkg-sig</prgn>.
+
<sect2 id="binary-only-nmu">
<heading>Recompilation or binary-only NMU</heading>
an updated environment. However, you have to bump the version number in
this case, so that the old bad package can be replaced in the Debian archive
(<prgn>katie</prgn> refuses to install new packages if they don't have a
-version number greater than the currently available one). Despite the
+version number greater than the currently available one).
+ <p>
+You have to make sure that your binary-only NMU doesn't render the package
+uninstallable. This could happen when a source package generates
+arch-dependent and arch-independent packages that depend on each other via
+$(Source-Version).
+ <p>
+Despite the
required modification of the changelog, these are called binary-only NMUs
— there is no need in this case to trigger all other architectures
to consider themselves out of date or requiring recompilation.
``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''.
+ <p>
+Similar to initial porter uploads, the correct way of invoking
+<prgn>dpkg-buildpackage</prgn> is <tt>dpkg-buildpackage -B</tt> to only
+build the architecture-dependent parts of the package.
<sect2 id="source-nmu-when-porter">
non-porter, since porters have to cope with a large quantity of
packages.
Again, the situation varies depending on the distribution they are
-uploading to.
-
-<!--
-FIXME: commented out until I can work out how to upload to testing directly
-
- Crucial fixes (i.e., changes need to get a source
-package to compile for a released-targeted architecture) can be
-uploaded with <em>no</em> waiting period for the `frozen' distribution.
- -->
+uploading to. It also varies whether the architecture is a candidate
+for inclusion into the next stable release; the release managers
+decide and announce which architectures are candidates.
<p>
-However, if you are a porter doing an NMU for `unstable', the above
+If you are a porter doing an NMU for `unstable', the above
guidelines for porting should be followed, with two variations.
Firstly, the acceptable waiting period — the time between when the
bug is submitted to the BTS and when it is OK to do an NMU — is seven
can be shortened if the problem is critical and imposes hardship on
the porting effort, at the discretion of the porter group. (Remember,
none of this is Policy, just mutually agreed upon guidelines.)
+For uploads to stable or testing, please coordinate with the appropriate
+release team first.
<p>
Secondly, porters doing source NMUs should make sure that the bug they
submit to the BTS should be of severity `serious' or greater. This
Porters should try to avoid patches which simply kludge around bugs in
the current version of the compile environment, kernel, or libc.
Sometimes such kludges can't be helped. If you have to kludge around
-compilers bugs and the like, make sure you <tt>#ifdef</tt> your work
+compiler bugs and the like, make sure you <tt>#ifdef</tt> your work
properly; also, document your kludge so that people know to remove it
once the external problems have been fixed.
<p>
results of their work during the waiting period. This helps others
running the port have the benefit of the porter's work, even during
the waiting period. Of course, such locations have no official
-blessing or status, so buyer, beware.
+blessing or status, so buyer beware.
<sect1 id="porter-automation">
<sect id="nmu">Non-Maintainer Uploads (NMUs)
<p>
Under certain circumstances it is necessary for someone other than the
-official package maintainer to make a release of a package. This is
+official package maintainer to make a release of a package. This is
called a non-maintainer upload, or NMU.
<p>
-Debian porters, who compile packages for different architectures,
-occasionally do binary-only NMUs as part of their porting activity
-(see <ref id="porting">). Another reason why NMUs are done is when a
-Debian developers needs to fix another developers' packages in order to
-address serious security problems or crippling bugs, especially during
-the freeze, or when the package maintainer is unable to release a fix
+This section handles only source NMUs, i.e. NMUs which upload a new
+version of the package. For binary-only NMUs by porters or QA members,
+please see <ref id="binary-only-nmu">.
+If a buildd builds and uploads a package,
+that too is strictly speaking a binary NMU.
+See <ref id="buildd"> for some more information.
+ <p>
+The main reason why NMUs are done is when a
+developer needs to fix another developer's packages in order to
+address serious problems or crippling bugs
+or when the package maintainer is unable to release a fix
in a timely fashion.
- <p>
-This chapter contains information providing guidelines for when and
-how NMUs should be done. A fundamental distinction is made between
-source and binary-only NMUs, which is explained in the next section.
-
- <sect1 id="nmu-terms">Terminology
- <p>
-There are two new terms used throughout this section: ``binary-only NMU''
-and ``source NMU''. These terms are used with specific technical
-meaning throughout this document. Both binary-only and source NMUs are
-similar, since they involve an upload of a package by a developer who
-is not the official maintainer of that package. That is why it's a
-<em>non-maintainer</em> upload.
- <p>
-A source NMU is an upload of a package by a developer who is not the
-official maintainer, for the purposes of fixing a bug in the package.
-Source NMUs always involves changes to the source (even if it is just
-a change to <file>debian/changelog</file>). This can be either a
-change to the upstream source, or a change to the Debian bits of the
-source. Note, however, that source NMUs may also include
-architecture-dependent packages, as well as an updated Debian diff.
- <p>
-A binary-only NMU is a recompilation and upload of a binary package
-for a given architecture. As such, it is usually part of a porting
-effort. A binary-only NMU is a non-maintainer uploaded binary version
-of a package, with no source changes required. There are many cases
-where porters must fix problems in the source in order to get them to
-compile for their target architecture; that would be considered a
-source NMU rather than a binary-only NMU. As you can see, we don't
-distinguish in terminology between porter NMUs and non-porter NMUs.
<p>
-Both classes of NMUs, source and binary-only, can be lumped by the
-term ``NMU''. However, this often leads to confusion, since most
-people think ``source NMU'' when they think ``NMU''. So it's best to
-be careful. In this chapter, if we use the unqualified term ``NMU'',
-we refer to any type of non-maintainer upload NMUs, whether source and
-binary, or binary-only.
-
-
- <sect1 id="nmu-who">Who can do an NMU
+First and foremost, it is critical that NMU patches to source should
+be as non-disruptive as possible. Do not do housekeeping tasks, do
+not change the name of modules or files, do not move directories; in
+general, do not fix things which are not broken. Keep the patch as
+small as possible. If things bother you aesthetically, talk to the
+Debian maintainer, talk to the upstream maintainer, or submit a bug.
+However, aesthetic changes must <em>not</em> be made in a non-maintainer
+upload.
<p>
-Only official, registered Debian maintainers can do binary or source
-NMUs. An official maintainer is someone who has their key in the
-Debian key ring. Non-developers, however, are encouraged to download
-the source package and start hacking on it to fix problems; however,
-rather than doing an NMU, they should just submit worthwhile patches
-to the Bug Tracking System. Maintainers almost always appreciate
-quality patches and bug reports.
+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.
- <sect1 id="nmu-when">When to do a source NMU
- <p>
-Guidelines for when to do a source NMU depend on the target
-distribution, i.e., stable, unstable, or experimental. Porters have
-slightly different rules than non-porters, due to their unique
-circumstances (see <ref id="source-nmu-when-porter">).
+ <sect1 id="nmu-guidelines">How to do a NMU
<p>
-When a security bug is detected, the security team may do an NMU.
-Please refer to <ref id="bug-security"> for more information.
+NMUs which fix important, serious or higher severity bugs are encouraged
+and accepted.
+You should endeavor to reach the current maintainer of the package; they
+might be just about to upload a fix for the problem, or have a better
+solution present.
<p>
-During the release cycle (see <ref id="sec-dists">), NMUs which fix
-serious or higher severity bugs are encouraged and accepted. Even
-during this window, however, you should endeavor to reach the current
-maintainer of the package; they might be just about to upload a fix
-for the problem. As with any source NMU, the guidelines found in <ref
-id="nmu-guidelines"> need to be followed. Special exceptions are made
-for <ref id="qa-bsp">.
+NMUs should be made to assist a package's maintainer in resolving bugs.
+Maintainers should be thankful for that help, and NMUers should respect
+the decisions of maintainers, and try to personally help the maintainer by
+their work.
<p>
-Uploading bug fixes to unstable by non-maintainers should only be done
-by following this protocol:
+A NMU should follow all conventions, written down in this section.
+For an upload to testing or unstable, this order of steps is recommended:
<p>
<list>
<item>
filed in the Debian Bug Tracking System (BTS).
If they are not, submit them immediately.
<item>
-Wait a few days the response from the maintainer. If you don't get
-any response, you may want to help him by sending the patch that fixes
+Wait a few days for the response from the maintainer. If you don't get
+any response, you may want to help them by sending the patch that fixes
the bug. Don't forget to tag the bug with the "patch" keyword.
<item>
Wait a few more days. If you still haven't got an answer from the
-maintainer, send him a mail announcing your intent to NMU the package.
-Prepare an NMU as described in <ref id="nmu-guidelines">, test it
+maintainer, send them a mail announcing your intent to NMU the package.
+Prepare an NMU as described in this section, and test it
carefully on your machine (cf. <ref id="sanitycheck">).
Double check that your patch doesn't have any unexpected side effects.
Make sure your patch is as small and as non-disruptive as it can be.
important to notice that even in these so-called "bug squashing party"
times, the NMU'er has to file bugs and contact the developer first,
and act later.
-
- <sect1 id="nmu-guidelines">How to do a source NMU
+Please see <ref id="qa-bsp"> for details.
<p>
-The following applies to porters insofar as they are playing the dual
-role of being both package bug-fixers and package porters. If a
-porter has to change the Debian source archive, automatically their
-upload is a source NMU and is subject to its rules. If a porter is
-simply uploading a recompiled binary package, the rules are different;
-see <ref id="porter-guidelines">.
+For the testing distribution, the rules may be changed by the release
+managers. Please take additional care, and acknowledge that the usual way
+for a package to enter testing is through unstable.
<p>
-First and foremost, it is critical that NMU patches to source should
-be as non-disruptive as possible. Do not do housekeeping tasks, do
-not change the name of modules or files, do not move directories; in
-general, do not fix things which are not broken. Keep the patch as
-small as possible. If things bother you aesthetically, talk to the
-Debian maintainer, talk to the upstream maintainer, or submit a bug.
-However, aesthetic changes must <em>not</em> be made in a non-maintainer
-upload.
+For the stable distribution, please take extra care. Of course, the release
+managers may also change the rules here. Please verify before upload that
+all your changes are OK for inclusion into the next stable release by the
+release manager.
+ <p>
+When a security bug is detected, the security team may do an NMU, using
+their own rules. Please refer to <ref id="bug-security"> for more
+information.
+ <p>
+For the differences for Porters NMUs, please see
+<ref id="source-nmu-when-porter">.
+ <p>
+Of course, it is always possible to agree on special rules with a maintainer
+(like the maintainer asking "please upload this fix directly for me, and no
+diff required").
- <sect2 id="nmu-version">Source NMU version numbering
+ <sect1 id="nmu-version">NMU version numbering
<p>
Whenever you have made a change to a package, no matter how trivial,
the version number needs to change. This enables our packing system
the release should start with the <var>debian-revision</var> value
`0.1'. The usual maintainer of a package should start their
<var>debian-revision</var> numbering at `1'.
+ <p>
+If you upload a package to testing or stable, sometimes, you need to
+"fork" the version number tree. For this, version numbers like
+1.1-3sarge0.1 could be used.
- <sect2 id="nmu-changelog">
+ <sect1 id="nmu-changelog">
<heading>Source NMUs must have a new changelog entry</heading>
<p>
A non-maintainer doing a source NMU must create a changelog entry,
</example>
- <sect2 id="nmu-patch">Source NMUs and the Bug Tracking System
+ <sect1 id="nmu-patch">Source NMUs and the Bug Tracking System
<p>
Maintainers other than the official package maintainer should make as
few changes to the package as possible, and they should always send a
If the source NMU (non-maintainer upload) fixes some existing bugs,
these bugs should be tagged <em>fixed</em> in the Bug Tracking
System rather than closed. By convention, only the official package
-maintainer or the original bug submitter are allowed to close bugs.
+maintainer or the original bug submitter close bugs.
Fortunately, Debian's archive system recognizes NMUs and thus marks
the bugs fixed in the NMU appropriately if the person doing the NMU
has listed all bugs in the changelog with the <tt>Closes:
changes in the NMU are incorporated officially into the package by
the official package maintainer.
<p>
-Also, after doing an NMU, you have to open a new bug and include a
-patch showing all the changes you have made. Alternatively you can send
-that information to the existing bugs that are fixed by your NMU.
+Also, after doing an NMU, you have to send
+that information to the existing bugs that are fixed by your NMU,
+including the unified diff.
+Alternatively you can open a new bug and include a
+patch showing all the changes you have made.
The normal maintainer will either apply the patch or employ an alternate
method of fixing the problem. Sometimes bugs are fixed independently
upstream, which is another good reason to back out an NMU's patch.
entry in the changelog file documenting the non-maintainer upload.
- <sect2 id="nmu-build">Building source NMUs
+ <sect1 id="nmu-build">Building source NMUs
<p>
Source NMU packages are built normally. Pick a distribution using the
same rules as found in <ref id="distribution">, follow the other
If one of your packages has been NMU'ed, you have to incorporate the
changes in your copy of the sources. This is easy, you just have
to apply the patch that has been sent to you. Once this is done, you
-have to close the bugs that have been tagged fixed by the NMU. You
-can either close them manually by sending the required mails to the
+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
+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.
<p>
personal attack against the maintainer. It is a proof that
someone cares enough about the package and that they were willing to help
you in your work, so you should be thankful. You may also want to
-ask them if they would be interested to help you on a more frequent
+ask them if they would be interested in helping you on a more frequent
basis as co-maintainer or backup maintainer
(see <ref id="collaborative-maint">).
+ <sect1 id="nmu-vs-qa">NMU vs QA uploads
+ <p>
+Unless you know the maintainer is still active, it is wise to check the
+package to see if it has been orphaned. The current list of orphaned
+packages which haven't had their maintainer set correctly is available at
+<url id="&url-debian-qa-orphaned;">. If you perform an NMU on an
+improperly orphaned package, please set the maintainer to ``Debian QA Group
+<packages@qa.debian.org>''. Also, the bugs are closed in that case,
+and not only marked fixed.
- <sect id="collaborative-maint">
- <heading>Collaborative maintenance</heading>
- <p>
-"Collaborative maintenance" is a term describing the sharing of Debian
-package maintenance duties by several people. This collaboration is
-almost always a good idea, since it generally results in higher quality and
-faster bug fix turnaround time. It is strongly recommended that
-packages in which a priority of <tt>Standard</tt> or which are part of
-the base set have co-maintainers.</p>
- <p>
-Generally there is a primary maintainer and one or more
-co-maintainers. The primary maintainer is the whose name is listed in
-the <tt>Maintainer</tt> field of the <file>debian/control</file> file.
-Co-maintainers are all the other maintainers.</p>
- <p>
-In its most basic form, the process of adding a new co-maintainer is
-quite easy:<list>
- <item>
- <p>
-Setup the co-maintainer with access to the sources you build the
-package from. Generally this implies you are using a network-capable
-version control system, such as <prgn>CVS</prgn> or
-<prgn>Subversion</prgn>.</p>
- </item>
- <item>
- <p>
-Add the co-maintainer's correct maintainer name and address to the
-<tt>Uploaders</tt> field in the global part of the
-<file>debian/control</file> file.
-<example>
-Uploaders: John Buzz <jbuzz@debian.org>, Adam Rex <arex@debian.org>
-</example>
-</p>
+ <sect1 id="nmu-who">Who can do an NMU
+ <p>
+Only official, registered Debian maintainers can do binary or source
+NMUs. An official maintainer is someone who has their key in the
+Debian key ring. Non-developers, however, are encouraged to download
+the source package and start hacking on it to fix problems; however,
+rather than doing an NMU, they should just submit worthwhile patches
+to the Bug Tracking System. Maintainers almost always appreciate
+quality patches and bug reports.
+
+ <sect1 id="nmu-terms">Terminology
+ <p>
+There are two new terms used throughout this section: ``binary-only NMU''
+and ``source NMU''. These terms are used with specific technical
+meaning throughout this document. Both binary-only and source NMUs are
+similar, since they involve an upload of a package by a developer who
+is not the official maintainer of that package. That is why it's a
+<em>non-maintainer</em> upload.
+ <p>
+A source NMU is an upload of a package by a developer who is not the
+official maintainer, for the purposes of fixing a bug in the package.
+Source NMUs always involves changes to the source (even if it is just
+a change to <file>debian/changelog</file>). This can be either a
+change to the upstream source, or a change to the Debian bits of the
+source. Note, however, that source NMUs may also include
+architecture-dependent packages, as well as an updated Debian diff.
+ <p>
+A binary-only NMU is a recompilation and upload of a binary package
+for a given architecture. As such, it is usually part of a porting
+effort. A binary-only NMU is a non-maintainer uploaded binary version
+of a package, with no source changes required. There are many cases
+where porters must fix problems in the source in order to get them to
+compile for their target architecture; that would be considered a
+source NMU rather than a binary-only NMU. As you can see, we don't
+distinguish in terminology between porter NMUs and non-porter NMUs.
+ <p>
+Both classes of NMUs, source and binary-only, can be lumped by the
+term ``NMU''. However, this often leads to confusion, since most
+people think ``source NMU'' when they think ``NMU''. So it's best to
+be careful: always use ``binary NMU'' or ``binNMU'' for binary-only
+NMUs.
+
+
+ <sect id="collaborative-maint">
+ <heading>Collaborative maintenance</heading>
+ <p>
+"Collaborative maintenance" is a term describing the sharing of Debian
+package maintenance duties by several people. This collaboration is
+almost always a good idea, since it generally results in higher quality and
+faster bug fix turnaround time. It is strongly recommended that
+packages with a priority of <tt>Standard</tt> or which are part of
+the base set have co-maintainers.</p>
+ <p>
+Generally there is a primary maintainer and one or more
+co-maintainers. The primary maintainer is the person whose name is listed in
+the <tt>Maintainer</tt> field of the <file>debian/control</file> file.
+Co-maintainers are all the other maintainers.</p>
+ <p>
+In its most basic form, the process of adding a new co-maintainer is
+quite easy:
+<list>
+ <item>
+ <p>
+Setup the co-maintainer with access to the sources you build the
+package from. Generally this implies you are using a network-capable
+version control system, such as <prgn>CVS</prgn> or
+<prgn>Subversion</prgn>.</p>
+ </item>
+ <item>
+ <p>
+Add the co-maintainer's correct maintainer name and address to the
+<tt>Uploaders</tt> field in the global part of the
+<file>debian/control</file> file.
+<example>
+Uploaders: John Buzz <jbuzz@debian.org>, Adam Rex <arex@debian.org>
+</example>
+</p>
</item>
<item>
<p>
should subscribe themselves to the appropriate source package.</p>
</item>
</list></p>
+ <p>
+Collaborative maintenance can often be further eased with the use of
+tools on Alioth (see <ref id="alioth">).
</sect>
+ <sect id="testing">
+ <heading>The testing distribution</heading>
+ <p>
+ <sect1 id="testing-basics">
+ <heading>Basics</heading>
+ <p>
+Packages are usually installed into the `testing' distribution after they
+have undergone some degree of testing in unstable.
+ <p>
+They must be in sync on all architectures and
+mustn't have dependencies that make them uninstallable; they also have to
+have generally no known release-critical bugs at the time they're
+installed into testing.
+This way, `testing' should always be close to being a release candidate.
+Please see below for details.
+ <sect1 id="testing-unstable">
+ <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
+<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.
+ <p>
+The inclusion of a package from <em>unstable</em> is conditional on
+the following:
+<list>
+ <item>
+The package must have been available in <em>unstable</em> for 2, 5 or 10
+days, depending on the urgency (high, medium or low).
+Please note that the urgency is sticky, meaning that the highest
+urgency uploaded since the previous testing transition is taken into account.
+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
+in <em>testing</em>;
+ <item>
+It must be available on all architectures on which it has previously
+been built in unstable. <ref id="madison"> may be of interest to
+check that information;
+ <item>
+It must not break any dependency of a package which is already available
+in <em>testing</em>;
+ <item>
+The packages on which it depends must either be available in <em>testing</em>
+or they must be accepted into <em>testing</em> at the same time (and they will
+if they fulfill all the necessary criteria);
+</list>
+ <p>
+To find out whether a package is progressing into testing or not, see the
+testing script output on the <url name="web page of the testing distribution"
+id="&url-testing-maint;">, or use the program <prgn>grep-excuses</prgn>
+which is in the <package>devscripts</package> package. This utility can
+easily be used in a <manref name="crontab" section="5"> to keep yourself
+informed of the progression of your packages into <em>testing</em>.
+ <p>
+The <file>update_excuses</file> file does not always give the precise reason
+why the package is refused; you may have to find it on your own by looking
+for what would break with the inclusion of the package. The
+<url id="&url-testing-maint;" name="testing web page"> gives some more
+information about the usual problems which may be causing such troubles.
+ <p>
+Sometimes, some packages never enter <em>testing</em> because the set of
+inter-relationship is too complicated and cannot be sorted out
+by the scripts. See below for details.
+ <p>
+Some further dependency analysis is shown on
+<url id="http://bjorn.haxx.se/debian/"> — but be warned,
+this page also shows build dependencies which
+are not considered by britney.
+
+ <sect2 id="outdated">
+ <heading>out-of-date</heading>
+ <p>
+<!-- FIXME: better rename this file than document rampant professionalism? -->
+For the testing migration script, "outdated" means: There are different
+versions in unstable for the release architectures (except for the
+architectures in fuckedarches; fuckedarches is a list of architectures
+that don't keep up (in update_out.py), but currently, it's empty).
+"outdated" has nothing whatsoever to do with the architectures this package
+has in testing.
+ <p>
+Consider this example:
+ <p>
+ <example>
+foo | alpha | arm
+---------+-------+----
+testing | 1 | -
+unstable | 1 | 2
+</example>
+ <p>
+The package is out of date on alpha in unstable, and will not go to
+testing. And removing foo from testing would not help at all, the package
+is still out of date on alpha, and will not propagate to testing.
+ <p>
+However, if ftp-master removes a package in unstable (here on arm):
+ <p>
+ <example>
+foo | alpha | arm | hurd-i386
+---------+-------+-----+----------
+testing | 1 | 1 | -
+unstable | 2 | - | 1
+ </example>
+ <p>
+In this case, the package is up to date on all release architectures in
+unstable (and the extra hurd-i386 doesn't matter, as it's not a release
+architecture).
+ <p>
+Sometimes, the question is raised if it is possible to allow packages in
+that are not yet built on all architectures: No. Just plainly no. (Except
+if you maintain glibc or so.)
+
+ <sect2 id="removals">
+ <heading>Removals from testing</heading>
+ <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
+<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).
+
+ <sect2 id="circular">
+ <heading>circular dependencies</heading>
+ <p>
+A situation which is not handled very well by britney is if package <em>a</em>
+depends on the new version of package <em>b</em>, and vice versa.
+ <p>
+An example of this is:
+ <p>
+ <example>
+ | testing | unstable
+--+-----------------+------------
+a | 1; depends: b=1 | 2; depends: b=2
+b | 1; depends: a=1 | 2; depends: a=2
+ </example>
+ <p>
+Neither package <em>a</em> nor package <em>b</em> is considered for update.
+ <p>
+Currently, this requires some manual hinting from the release team.
+Please contact them by sending mail to &email-debian-release; if this
+happens to one of your packages.
+
+
+ <sect2>
+ <heading>influence of package in testing</heading>
+ <p>
+Generally, there is nothing that the status of a package in testing means
+for transition of the next version from unstable to testing, with two
+exceptions: If the RC-bugginess of the package goes down, it may go in
+even if it is still RC-buggy. The second exception is if the version
+of the package in testing is out of sync on the different arches: Then
+any arch might just upgrade to the version of the source package;
+however, this can happen only if the package was previously forced
+through, the arch is in fuckedarches, or there was no binary package of that
+arch present in unstable at all during the testing migration.
+ <p>
+In summary this means: The only influence that a package being in testing
+has on a new version of the same package is that the new version might
+go in easier.
+
+ <sect2 id="details">
+ <heading>details</heading>
+ <p>
+If you are interested in details, this is how britney works:
+ <p>
+The packages are looked at to determine whether they are valid
+candidates. This gives the "update excuses". The most common reasons
+why a package is not considered are too young, RC-bugginess, and out of
+date on some arches. For this part, the release managers have hammers
+of any size to force britney to consider a package. (Also, the base
+freeze is coded in that part of britney.) (There is a similar thing
+for binary-only updates, but this is not described here. If you're
+interested in that, please peruse the code.)
+ <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
+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.)
+ <p>
+If you want to see more details, you can look it up on
+merkel:/org/ftp.debian.org/testing/update_out/ (or there in
+~aba/testing/update_out to see a setup with a smaller packages file). Via
+web, it's at <url
+id="http://ftp-master.debian.org/testing/update_out_code/">
+ <p>
+The hints are available via <url
+id="http://ftp-master.debian.org/testing/hints/">.
+
+
+ <sect1 id="t-p-u">
+ <heading>Direct updates to testing</heading>
+ <p>
+The testing distribution is fed with packages from unstable according to the rules
+explained above. However, in some cases, it is necessary to upload
+packages built only for testing. For that, you may want to
+upload to <em>testing-proposed-updates</em>.
+ <p>
+Keep in mind that packages uploaded there are not automatically processed, they
+have to go through the hands of the release manager. So you'd better have a good
+reason to upload there. In order to know what a good reason is in the
+release managers' eyes, you should read the instructions that they regularly
+give on &email-debian-devel-announce;.
+ <p>
+You should not upload to <em>testing-proposed-updates</em> when you can update your
+packages through <em>unstable</em>. If you can't (for example because you have a
+newer development version in unstable), you may use this facility,
+but it is recommended that you ask for authorization from
+the release manager first.
+Even if a package is
+frozen, updates through unstable are possible, if the upload via unstable
+does not pull in any new dependencies.
+ <p>
+Version numbers are usually selected by adding the codename of the testing
+distribution and a running number, like 1.2sarge1 for the first upload
+through testing-proposed-updates of package version 1.2.
+ <p>
+Please make sure you didn't miss any of these items in your upload:
+<list>
+<item> Make sure that your package really needs to go through
+<em>testing-proposed-updates</em>, and can't go through unstable;
+<item> Make sure that you included only the minimal amount of changes;
+<item> Make sure that you included an appropriate explanation in the
+changelog;
+<item> Make sure that you've written <em>testing</em> or
+<em>testing-proposed-updates</em> into your target distribution;
+<item> Make sure that you've built and tested your package in
+<em>testing</em>, not in <em>unstable</em>;
+<item> Make sure that your version number is higher than the version in
+<em>testing</em> and <em>testing-proposed-updates</em>, and lower than in
+<em>unstable</em>;
+<item> After uploading and successful build on all platforms, contact the
+release team at &email-debian-release; and ask them to approve your upload.
+</list>
+
+ <sect1 id="faq">
+ <heading>Frequently asked questions</heading>
+ <p>
+
+ <sect2 id="rc">
+ <heading>What are release-critical bugs, and how do they get counted?</heading>
+ <p>
+All bugs of some higher severities are by default considered release-critical; currently, these are critical, grave, and serious bugs.
+ <p>
+Such bugs are presumed to have an impact on the chances that the package will be released with the stable release of Debian: in general, if a package has open release-critical bugs filed on it, it won't get into "testing", and consequently won't be released in "stable".
+ <p>
+The unstable bug count are all release-critical bugs
+without either any release-tag (such as potato, woody) or with release-tag sid;
+also, only if they are neither fixed nor set to sarge-ignore.
+The "testing" bug count for a package is considered to be roughly
+the bug count of unstable count at the last point
+when the "testing" version equalled the "unstable" version.
+ <p>
+This will change post-sarge, as soon as we have versions in the bug tracking system.
+
+
+ <sect2>
+ <heading>How could installing a package into "testing" possibly break other packages?</heading>
+ <p>
+The structure of the distribution archives is such that they can only contain one version of a package; a package is defined by its name. So when the source package acmefoo is installed into "testing", along with its binary packages acme-foo-bin, acme-bar-bin, libacme-foo1 and libacme-foo-dev, the old version is removed.
+ <p>
+However, the old version may have provided a binary package with an old soname of a library, such as libacme-foo0. Removing the old acmefoo will remove libacme-foo0, which will break any packages which depend on it.
+ <p>
+Evidently, this mainly affects packages which provide changing sets of binary packages in different versions (in turn, mainly libraries). However, it will also affect packages upon which versioned dependencies have been declared of the ==, <=, or << varieties.
+ <p>
+When the set of binary packages provided by a source package change in this way, all the packages that depended on the old binaries will have to be updated to depend on the new binaries instead. Because installing such a source package into "testing" breaks all the packages that depended on it in "testing", some care has to be taken now: all the depending packages must be updated and ready to be installed themselves so that they won't be broken, and, once everything is ready, manual intervention by the release manager or an assistant is normally required.
+ <p>
+If you are having problems with complicated groups of packages like this, contact debian-devel or debian-release for help.
+ </sect>
<chapt id="best-pkging-practices">
<heading>Best Packaging Practices</heading>
Helper scripts take care of these issues. Assuming you comply with
the conventions expected by the helper script, the helper takes care
of all the details. Changes in policy can be made in the helper
-script, then packages just need to be rebuilt with the new version of
+script; then packages just need to be rebuilt with the new version of
the helper and no other changes.
<p>
<ref id="tools"> contains a couple of different helpers. The most
<heading>Separating your patches into multiple files</heading>
<p>
Big, complex packages may have many bugs that you need to deal with.
-If you correct a number of bug directly in the source, if you're not
+If you correct a number of bugs directly in the source, and you're not
careful, it can get hard to differentiate the various patches that you
applied. It can get quite messy when you have to update the package
to a new upstream version which integrates some of the fixes (but not
<sect1 id="multiple-binary">Multiple binary packages
<p>
A single source package will often build several binary packages,
-either to provide several flavors of the same software (examples are
-the <package>vim-*</package> packages) or to make several small
+either to provide several flavors of the same software (e.g.,
+the <package>vim</package> source package) or to make several small
packages instead of a big one (e.g., if the user can install only the
-subset she needs, and thus save some disk space).
+subset needed, and thus save some disk space).
<p>
The second case can be easily managed in <file>debian/rules</file>.
You just need to move the appropriate files from the build directory
into the package's temporary trees. You can do this using
-<prgn>install</prgn>
(vanilla approach) or <prgn>dh_install</prgn>
-(from <package>debhelper</package>). Be sure to check the different
+<prgn>install</prgn> or <prgn>dh_install</prgn>
+from <package>debhelper</package>. Be sure to check the different
permutations of the various packages, ensuring that you have the
inter-package dependencies set right in <file>debian/control</file>.
<p>
The first case is a bit more difficult since it involves multiple
-recompiles of the same software but with different configure
-options. The <package>vim</package> is an example of how to manage
+recompiles of the same software but with different configuration
+options. The <package>vim</package> source package is an example of how to manage
this using an hand-crafted <file>debian/rules</file> file.
<!-- &FIXME; Find a good debhelper example with multiple configure/make
</sect1>
</sect>
- <sect id="bpp-debian-maint-scripts">
- <heading>Best practices for maintainer scripts</heading>
- <p>
-Maintainer scripts include the files <file>debian/postinst</file>,
-<file>debian/preinst</file>, <file>debian/prerm</file> and
-<file>debian/postrm</file>. These scripts take care of any package
-installation or deinstallation setup which isn't handled merely by the
-creation or removal of files and directories. The following
-instructions supplement the <url id="&url-debian-policy;" name="Debian
-Policy">.
- <p>
-Maintainer scripts must be idempotent. That means that you need to
-make sure nothing bad will happen if the script is called twice where
-it would usually be called once.
- <p>
-Standard input and output may be redirected (e.g. into pipes) for
-logging purposes, so don't rely on them being a tty.
- <p>
-All prompting or interactive configuration should be kept to a
-minimum. When it is necessary, you should use the
-<package>debconf</package> package for the interface. Remember that
-prompting in any case can only be in the <tt>configure</tt> stage of
-the <file>postinst</file> script.
- <p>
-Keep the maintainer scripts as simple as possible. We suggest you use
-pure POSIX shell scripts. Remember, if you do need any bash features,
-the maintainer script must have a bash sh-bang line. POSIX shell or
-Bash are preferred to Perl, since they enable
-<package>debhelper</package> to easily add bits to the scripts.
- <p>
-If you change your maintainer scripts, be sure to test package
-removal, double installation, and purging. Be sure that a purged
-package is completely gone, that is, it must remove any files created,
-directly or indirectly, in any maintainer script.
- <p>
-If you need to check for the existence of a command, you should use
-something like
-<example>if [ -x /usr/sbin/install-docs ]; then ...</example>
-
-If you don't wish to hard-code the path of the command in your
-maintainer script, the following POSIX-compliant shell function may
-help:
-
-&example-pathfind;
-
-You can use this function to search <tt>$PATH</tt> for a command name,
-passed as an argument. It returns true (zero) if the command was
-found, and false if not. This is really the most portable way, since
-<tt>command -v</tt>, <prgn>type</prgn>, and <prgn>which</prgn> are not
-POSIX.
- <p>
-While <prgn>which</prgn> is an acceptable alternative, since
-it is from the required <package>debianutils</package> package, it's
-not on the root partition. That is, it's in <file>/usr/bin</file> rather
-than <file>/bin</file>, so one can't use it in scripts which are run
-before the <file>/usr</file> partition is mounted. Most scripts won't have
-this problem, though.
- </sect>
-
<sect id="bpp-debian-control">
<heading>Best practices for <file>debian/control</file></heading>
<p>
The following practices are relevant to the
<file>debian/control</file> file. They supplement the <url
-id="&url-debian-policy;ch-miscellaneous.html#s-descriptions"
+id="&url-debian-policy;ch-binary.html#s-descriptions"
name="Policy on package descriptions">.
<p>
The description of the package, as defined by the corresponding field
in the <file>control</file> file, contains both the package synopsis
-and the long description for the package.
-
+and the long description for the package. <ref id="bpp-desc-basics">
+describes common guidelines for both parts of the package description.
+Following that, <ref id="bpp-pkg-synopsis"> provides guidelines
+specific to the synopsis, and <ref id="bpp-pkg-desc"> contains
+guidelines specific to the description.
<sect1 id="bpp-desc-basics">
<heading>General guidelines for package descriptions</heading>
<p>
How do you write for non-technical users? Avoid jargon. Avoid
referring to other applications or frameworks that the user might not
-be familiar with — "GNOME" or "KDE" is fine, but "GTK+" is
+be familiar with — "GNOME" or "KDE" is fine, since users are
+probably familiar with these terms, but "GTK+" is
probably not. Try not to assume any knowledge at all. If you must
use technical terms, introduce them.
+ <p>
+Be objective. Package descriptions are not the place for advocating
+your package, no matter how much you love it. Remember that the
+reader may not care about the same things you care about.
<p>
References to the names of any other software packages, protocol names,
standards, or specifications should use their canonical forms, if one
Windows", "X-Windows", or "X Window". Use "GTK+", not "GTK" or "gtk".
Use "GNOME", not "Gnome". Use "PostScript", not "Postscript" or
"postscript".
+ <p>
+If you are having problems writing your description, you may wish to
+send it along to &email-debian-l10n-english; and request feedback.
</sect1>
e.g., "Rudolph the red-nosed reindeer". The appositive clause here is
"red-nosed reindeer". Since the synopsis is a clause, rather than a
full sentence, we recommend that it neither start with a capital nor
-end with a full stop (period). Imagine that the synopsis is combined
-with the package name in the following way:
+end with a full stop (period). It should also not begin with an
+article, either definite ("the") or indefinite ("a" or "an").
+ <p>
+It might help to imagine that the synopsis is combined with the
+package name in the following way:
+
+<example><var>package-name</var> is a <var>synopsis</var>.</example>
+
+Alternatively, it might make sense to think of it as
+
+<example><var>package-name</var> is <var>synopsis</var>.</example>
+
+or, if the package name itself is a plural (such as
+"developers-tools")
+
+<example><var>package-name</var> are <var>synopsis</var>.</example>
-<example>The <var>package-name</var> is a <var>synopsis</var>.</example>
+This way of forming a sentence from the package name and synopsis
+should be considered as a heuristic and not a strict rule. There are
+some cases where it doesn't make sense to try to form a sentence.
</sect1>
<sect1 id="bpp-pkg-desc">
package. Assume that the user has already read the package synopsis.
<p>
The long description should consist of full and complete sentences.
-It is recommended to use two spaces after full stops in sentences. We
-realize this is an American style rather than European, but it is
-additionally helpful in creating visual space in fixed-width fonts.
<p>
The first paragraph of the long description should answer the
following questions: what does the package do? what task does it help
have? What outstanding features and deficiencies are there compared
to other packages (e.g., "if you need X, use Y instead")? Is this
package related to other packages in some way that is not handled by
-the package manager (e.g., "this is the client to the foo server")?
- <p>
-Be objective. Package descriptions are not the place for advocating
-your package, no matter how much you love it. Remember that the
-reader may not care about the same things you care about.
+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:
<example>ispell -d american -g debian/control</example>
+ <p>
+Users usually expect these questions to be answered in the package
+description:
+ <list>
+ <item>
+What does the package do? If it is an add-on to another package,
+then the short description of the package we are an add-on to
+should be put in here.
+ <item>
+Why should I want this package? This is related to the above,
+but not the same (this is a mail user agent; this is cool, fast,
+interfaces with PGP and LDAP and IMAP, has features X, Y, and Z).
+ <item>
+If this package should not be installed directly, but is pulled in
+by another package, this should be mentioned.
+ <item>
+If the package is experimental, or there are other reasons it
+should not be used, if there are other packages that should be
+used instead, it should be here as well.
+ <item>
+How is this package different from the competition? Is it a better
+implementation? more features? different features? Why should I
+choose this package.
+<!-- FIXME: what's this?
+(the second questions is about the class of packages, and
+this about this particular package, if you have information related to both).
+-->
+ </list>
+
</sect1>
Where's the description? If you can't think of a descriptive message,
start by inserting the title of each different bug.
</sect1>
+
+ <sect1 id="bpp-news-debian">
+ <heading>Supplementing changelogs with NEWS.Debian files</heading>
+ <p>
+Important news about changes in a package can also be put in NEWS.Debian
+files. The news will be displayed by tools like apt-listchanges, before
+all the rest of the changelogs. This is the preferred means to let the user
+know about significant changes in a package. It is better than using
+debconf notes since it is less annoying and the user can go back and refer
+to the NEWS.Debian file after the install. And it's better than listing
+major changes in README.Debian, since the user can easily miss such notes.
+ <p>
+The file format is the same as a debian changelog file, but leave off
+the asterisks and describe each news item with a full paragraph when
+necessary rather than the more concise summaries that would go in a
+changelog. It's a good idea to run your file through dpkg-parsechangelog to
+check its formatting as it will not be automatically checked during build
+as the changelog is. Here is an example of a real NEWS.Debian file:
+<example>
+cron (3.0pl1-74) unstable; urgency=low
+
+ The checksecurity script is no longer included with the cron package:
+ it now has its own package, "checksecurity". If you liked the
+ functionality provided with that script, please install the new
+ package.
+
+ -- Steve Greenland <stevegr@debian.org> Sat, 6 Sep 2003 17:15:03 -0500
+</example>
+ <p>
+The NEWS.Debian file is installed as
+/usr/share/doc/<package>/NEWS.Debian.gz. It is compressed, and
+always has that name even in Debian native packages. If you use debhelper,
+dh_installchangelogs will install debian/NEWS files for you.
+ <p>
+Unlike changelog files, you need not update NEWS.Debian files with every
+release. Only update them if you have something particularly newsworthy
+that user should know about. If you have no news at all, there's no need
+to ship a NEWS.Debian file in your package. No news is good news!
</sect>
<!--
<p>
&FIXME; presentation of cvs-buildpackage, updating sources
via CVS (debian/rules refresh).
+ <url id="http://www.debian.org/devel/cvs_packages">
-->
+ <sect id="bpp-debian-maint-scripts">
+ <heading>Best practices for maintainer scripts</heading>
+ <p>
+Maintainer scripts include the files <file>debian/postinst</file>,
+<file>debian/preinst</file>, <file>debian/prerm</file> and
+<file>debian/postrm</file>. These scripts take care of any package
+installation or deinstallation setup which isn't handled merely by the
+creation or removal of files and directories. The following
+instructions supplement the <url id="&url-debian-policy;" name="Debian
+Policy">.
+ <p>
+Maintainer scripts must be idempotent. That means that you need to
+make sure nothing bad will happen if the script is called twice where
+it would usually be called once.
+ <p>
+Standard input and output may be redirected (e.g. into pipes) for
+logging purposes, so don't rely on them being a tty.
+ <p>
+All prompting or interactive configuration should be kept to a
+minimum. When it is necessary, you should use the
+<package>debconf</package> package for the interface. Remember that
+prompting in any case can only be in the <tt>configure</tt> stage of
+the <file>postinst</file> script.
+ <p>
+Keep the maintainer scripts as simple as possible. We suggest you use
+pure POSIX shell scripts. Remember, if you do need any bash features,
+the maintainer script must have a bash shebang line. POSIX shell or
+Bash are preferred to Perl, since they enable
+<package>debhelper</package> to easily add bits to the scripts.
+ <p>
+If you change your maintainer scripts, be sure to test package
+removal, double installation, and purging. Be sure that a purged
+package is completely gone, that is, it must remove any files created,
+directly or indirectly, in any maintainer script.
+ <p>
+If you need to check for the existence of a command, you should use
+something like
+<example>if [ -x /usr/sbin/install-docs ]; then ...</example>
+
+If you don't wish to hard-code the path of a command in your
+maintainer script, the following POSIX-compliant shell function may
+help:
+
+&example-pathfind;
+
+You can use this function to search <tt>$PATH</tt> for a command name,
+passed as an argument. It returns true (zero) if the command was
+found, and false if not. This is really the most portable way, since
+<tt>command -v</tt>, <prgn>type</prgn>, and <prgn>which</prgn> are not
+POSIX.
+ <p>
+While <prgn>which</prgn> is an acceptable alternative, since
+it is from the required <package>debianutils</package> package, it's
+not on the root partition. That is, it's in <file>/usr/bin</file> rather
+than <file>/bin</file>, so one can't use it in scripts which are run
+before the <file>/usr</file> partition is mounted. Most scripts won't have
+this problem, though.
+ </sect>
+
+
<sect id="bpp-config-mgmt">
<heading>Configuration management with <package>debconf</package></heading>
-
<p>
<package>Debconf</package> is a configuration management system which
can be used by all the various packaging scripts
future.
<p>
Debconf is a great tool but it is often poorly used. Many common mistakes
-are listed in the <manref name="debconf-devel" section="8"> man page.
+are listed in the <manref name="debconf-devel" section="7"> man page.
It is something that you must read if you decide to use debconf.
+Also, we document some best practices here.
+ <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).
+
+ <sect1>Do not abuse debconf
+ <p>
+Since debconf appeared in Debian, it has been widely abused and
+several criticisms received by the Debian distribution come from
+debconf abuse with the need of answering a wide bunch of questions
+before getting any little thing installed.
+ <p>
+Keep usage notes to what they belong: the NEWS.Debian, or
+README.Debian file. Only use notes for important notes which may
+directly affect the package usability. Remember that notes will always
+block the install until confirmed or bother the user by email.
+ <p>
+Carefully choose the questions priorities in maintainer scripts. See
+<manref name="debconf-devel" section="7"> for details about priorities.
+Most questions should use medium and low priorities.
+
+ <sect1>General recommendations for authors and translators
+ <p>
+ <sect2>Write correct English
+ <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
+list. Have your templates proofread.
+ <p>
+Badly written templates give a poor image of your package, of your
+work...or even of Debian itself.
+ <p>
+Avoid technical jargon as much as possible. If some terms sound common
+to you, they may be impossible to understand for others. If you cannot
+avoid them, try to explain them (use the extended description). When
+doing so, try to balance between verbosity and simplicity.
+
+ <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
+templates translated by translation teams or even individuals.
+ <p>
+Please use gettext-based templates. Install po-debconf on your
+development system and read its documentation ("man po-debconf" is a
+good start).
+ <p>
+Avoid changing templates too often. Changing templates text induces
+more work to translators which will get their translation "fuzzied". If
+you plan changes to your original templates, please contact
+translators. Most active translators are very reactive and getting
+their work included along with your modified templates will save you
+additional uploads. If you use gettext-based templates, the
+translator's name and e-mail addresses are mentioned in the po files
+headers.
+ <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.
+
+ <sect2>Do not make assumptions about interfaces
+ <p>
+Templates text should not make reference to widgets belonging to some
+debconf interfaces. Sentences like "If you answer Yes..." have no
+meaning for users of graphical interfaces which use checkboxes for
+boolean questions.
+ <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
+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
+would write a scientific paper.
+
+ <sect2>Be gender neutral
+ <p>
+The world is made of men and women. Please use gender-neutral
+constructions in your writing. This is not Political Correctness, this
+is showing respect to all humanity.
+
+
+ <sect1>Templates fields definition
+ <p>
+This part gives some information which is mostly taken from the
+<manref name="debconf-devel" section="7"> manual page.
+
+ <sect2>Type
+ <p>
+
+ <sect3>string:
+ <p>
+Results in a free-form input field that the user can type any string into.
+
+ <sect3>password:
+ <p>
+Prompts the user for a password. Use this with caution; be aware that
+the password the user enters will be written to debconf's
+database. You should probably clean that value out of the database as
+soon as is possible.
+
+ <sect3>boolean:
+ <p>
+A true/false choice. Remember: true/false, NOT YES/NO...
+
+ <sect3>select:
+ <p>
+A choice between one of a number of values. The choices must be
+specified in a field named 'Choices'. Separate the possible values
+with commas and spaces, like this: Choices: yes, no, maybe
+
+ <sect3>multiselect:
+ <p>
+Like the select data type, except the user can choose any number of
+
+ items from the choices list (or chose none of them).
+
+ <sect3>note:
+ <p>
+Rather than being a question per se, this datatype indicates a note
+that can be displayed to the user. It should be used only for
+important notes that the user really should see, since debconf will go
+to great pains to make sure the user sees it; halting the install for
+them to press a key, and even mailing the note to them in some
+cases.
+
+ <sect3>text:
+ <p>
+This type is now considered obsolete: don't use it.
+
+ <sect3>error:
+ <p>
+<strong>THIS TEMPLATE TYPE IS NOT HANDLED BY DEBCONF YET.</strong>
+ <p>
+It has been added to cdebconf, the C version of debconf, first used in
+the Debian Installer.
+ <p>
+Please do not use it unless debconf supports it.
+ <p>
+This type is designed to handle error message. It is mostly similar to
+the "note" type. Frontends may present it differently (for instance,
+the dialog frontend of cdebconf draws a red screen instead of the
+usual blue one).
+
+
+ <sect2>Description: short and extended description
+ <p>
+Templates 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
+that it may be accomodated by most debconf interfaces. Keeping it
+short also helps translators, as usually translations tend to end up
+being longer than the original.
+ <p>
+The short description should be able to stand on its own. Some
+interfaces do not show the long description by default, or only if the
+user explicitely asks for it or even do not show it at all. Avoid
+things like "What do you want to do?"
+ <p>
+The short description does not necessarily have to be a full
+sentence. This is part of the "keep it short and efficient"
+recommendation.
+ <p>
+The extended description should not repeat the short description word
+for word. If you can't think up a long description, then first, think
+some more. Post to debian-devel. Ask for help. Take a writing class!
+That extended description is important. If after all that you still
+can't come up with anything, leave it blank.
+ <p>
+The extended description should use complete sentences. Paragraphs
+should be kept short for improved readability. Do not mix two ideas
+in the same paragraph but rather use another paragraph.
+ <p>
+Don't be too verbose. Some debconf interfaces cannot deal very well
+with descriptions of more than about 20 lines, so try to keep it below
+this limit.
+ <p>
+For specific rules depending on templates type (string, boolean,
+etc.), please read below.
+
+ <sect2>Choices
+ <p>
+This field should be used for Select and Multiselect types. It
+contains the possible choices which will be presented to users. These
+choices should be separated by commas.
+
+
+ <sect2>Default
+ <p>
+This field is optional. It contains the default answer for string,
+select and multiselect templates. For multiselect templates, it may
+contain a comma-separated list of choices.
+
+ <sect1>Templates fields specific style guide
+ <p>
+
+ <sect2>Type field
+ <p>
+No specific indication except: use the appropriate type by referring
+to the previous section.
+
+ <sect2>Description field
+ <p>
+Below are specific instructions for properly writing the Description
+(short and extended) depending on the template type.
+
+ <sect3>String/password templates
+ <p>
+<list>
+<item> The short description is a prompt and NOT a title. Avoid
+ question style prompts ("IP Address?") in favour of
+ "opened" prompts ("IP address:").
+ The use of colons is recommended.
+
+<item> The extended description is a complement to the short description.
+ In the extended part, explain what is being asked, rather than ask
+ the same question again using longer words. Use complete sentences.
+ Terse writing style is strongly discouraged.
+</list>
+
+ <sect3>Boolean templates
+ <p>
+<list>
+<item> The short description should be phrased in the form of a question
+ which should be kept short and should generally end with a question
+ mark. Terse writing style is permitted and even encouraged if the
+ question is rather long (remember that translations are often longer
+ than original versions)
+
+<item> The extended description should NOT include a question.
+
+<item> Again, please avoid referring to specific interface widgets. A common
+ mistake for such templates is "if you answer Yes"-type
+ constructions.
+</list>
+
+ <sect3>Select/Multiselect
+ <p>
+<list>
+<item> The short description is a prompt and NOT a title. Do NOT use useless
+ "Please choose..." constructions. Users are clever enough to figure
+ out they have to choose something...:)
+
+<item> The extended description will complete the short description. It may
+ refer to the available choices. It may also mention that the user
+ may choose more than one of the available choices, if the template
+ is a multiselect one (although the interface often makes this
+ clear).
+</list>
+
+ <sect3>Notes
+ <p>
+<list>
+<item> The short description should be considered to be a *title*.
+
+<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
+ 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.
+ If, by reading this, you consider converting your Note type templates
+ to entries in NEWS/Debian or README.Debian, plus consider keeping existing
+ translations for the future.
+</list>
+
+
+ <sect2>Choices field
+ <p>
+If the Choices are likely to change often, please consider using the
+"__Choices" trick. This will split each individual choice into a
+single string, which will considerably help translators for doing
+their work.
+
+ <sect2>Default field
+ <p>
+If the default value, for a "select" template, is likely to vary
+depending on the user language (for instance, if the choice is a
+language choice), please use the "_DefaultChoice" trick.
+ <p>
+This special field allow translators to put the most appropriate
+choice according to their own language. It will become the default
+choice when their language is used while your own mentioned Default
+Choice will be used chan using English.
+ <p>
+Example, taken from the geneweb package templates:
+<example>
+Template: geneweb/lang
+Type: select
+__Choices: Afrikaans (af), Bulgarian (bg), Catalan (ca), Chinese (zh), Czech (cs), Danish (da), Dutch (nl), English (en), Esperanto (eo), Estonian (et), Finnish (fi), French (fr), German (de), Hebrew (he), Icelandic (is), Italian (it), Latvian (lv), Norwegian (no), Polish (pl), Portuguese (pt), Romanian (ro), Russian (ru), Spanish (es), Swedish (sv)
+# This is the default choice. Translators may put their own language here
+# instead of the default.
+# WARNING : you MUST use the ENGLISH FORM of your language
+# For instance, the french translator will need to put "French (fr)" here.
+_DefaultChoice: English (en)[ translators, please see comment in PO files]
+_Description: Geneweb default language:
+</example>
+ <p>
+Note the use of brackets which allow internal comments in debconf
+fields. Also note the use of comments which will show up in files the
+translators will work with.
+ <p>
+The comments are needed as the DefaultChoice trick is a bit
+confusing: the translators may put their own choice
+
+ <sect2>Default field
+ <p>
+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
+field translatable, if you think it may be translated.
+ <p>
+If the default value may vary depending on language/country (for
+instance the default value for a language choice), consider using the
+special "_DefaultChoice" type documented in <manref name="po-debconf" section="7">).
</sect>
any language-independent information and define those as entities in a
separate file which is included by all the different
translations. This makes it much easier, for instance, to keep URLs
-up-to-date across multiple files.
+up to date across multiple files.
</sect1>
</sect>
<prgn>autoconf</prgn>/<prgn>automake</prgn></heading>
<p>
Keeping <prgn>autoconf</prgn>'s <file>config.sub</file> and
-<file>config.guess</file> files up-to-date is critical for porters,
+<file>config.guess</file> files up to date is critical for porters,
especially on more volatile architectures. Some very good packaging
practices for any package using <prgn>autoconf</prgn> and/or
<prgn>automake</prgn> have been synthesized in
Libraries are always difficult to package for various reasons. The policy
imposes many constraints to ease their maintenance and to make sure
upgrades are as simple as possible when a new upstream version comes out.
-A breakage in a library can result in dozens of dependent packages
+Breakage in a library can result in dozens of dependent packages
breaking.
<p>
Good practices for library packaging have been grouped in
Lisp packages should register themselves with
<package>common-lisp-controller</package>, about which see
&file-lisp-controller;.
+<!-- TODO: mozilla extension policy, once that becomes available -->
</list>
</sect1>
<prgn>lintian</prgn> or <prgn>linda</prgn> (see <ref id="tools-lint">)
when run over the entire Debian archive.
</sect1>
- </sect>
+
+ <sect1 id="bpp-locale">
+ <heading>Needing a certain locale during build</heading>
+ <p>
+If you need a certain locale during build, you can create a temporary
+file via this trick:
+ <p>
+If you set LOCPATH to the equivalent of /usr/lib/locale, and LC_ALL to
+the name of the locale you generate, you should get what you want
+without being root. Something like this:
+
+<example>
+LOCALE_PATH=debian/tmpdir/usr/lib/locale
+LOCALE_NAME=en_IN
+LOCALE_CHARSET=UTF-8
+
+mkdir -p $LOCALE_PATH
+localedef -i "$LOCALE_NAME.$LOCALE_CHARSET" -f "$LOCALE_CHARSET" "$LOCALE_PATH/$LOCALE_NAME.$LOCALE_CHARSET"
+
+# Using the locale
+LOCPATH=$LOCALE_PATH LC_ALL=$LOCALE_NAME.$LOCALE_CHARSET date
+</example>
+ </sect1>
+
+ <sect1 id="bpp-transition">
+ <heading>Make transition packages deborphan compliant</heading>
+ <p>
+Deborphan is a program for helping users to detect which packages can safely be
+removed from the system, i.e. the ones that have no packages depending on
+them. The default operation is to search only within the libs and oldlibs
+sections, to hunt down unused libraries. But when passed the right argument,
+it tries to catch other useless packages.
+ <p>
+For example, with --guess-dummy, deborphan tries to search all transitional packages
+which were needed for upgrade but which can now safely be removed. For that,
+it looks for the string "dummy" or "transitional" in their short
+description.
+ <p>
+So, when you are creating such a package, please make sure to add this text
+to your short description. If you are looking for examples, just run:
+ <example>apt-cache search .|grep dummy</example> or
+ <example>apt-cache search .|grep transitional</example>.
+ </sect1>
+
+
+ <sect1 id="bpp-origtargz">
+ <heading>Best practices for <file>orig.tar.gz</file> files</heading>
+ <p>
+ There are two kinds of original source tarballs: Pristine source
+ and repackaged upstream source.
+ </p>
+ <sect2 id="pristine source">
+ <heading>Pristine source</heading>
+ <p>
+The defining characteristic of a pristine source tarball is that the
+.orig.tar.gz file is byte-for-byte identical to a tarball officially
+distributed by the upstream author.
+<footnote>
+We cannot prevent upstream authors from changing the tarball
+they distribute without also upping 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
+something that upstream once <em>did</em> distribute.
+
+If a difference arises later (say, if upstream notices that he wasn't
+using maximal comression in his original distribution and then
+re-<tt>gzip</tt>s it), that's just too bad. Since there is no good way
+to upload a new .orig.tar.gz for the same version, there is not even
+any point in treating this situation as a bug.
+</footnote>
+This makes it possible to use checksums to easily verify that all
+changes between Debian's version and upstream's are contained in the
+Debian diff. Also, if the original source is huge, upstream authors
+and others who already have the upstream tarball can save download
+time if they want to inspect your packaging in detail.
+ </p>
+ <p>
+There is no universally accepted guidelines that upstream authors
+follow regarding to the directory structure inside their tarball, but
+<prgn>dpkg-source</prgn> is nevertheless able to deal with most
+upstream tarballs as pristine source. Its strategy is equivalent to
+the following:
+ </p>
+ <p>
+ <enumlist>
+ <item>
+It unpacks the tarball in an empty temporary directory by doing
+
+<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
+directory and no other files, <prgn>dpkg-source</prgn> renames that
+directory to
+<tt><packagename>-<upstream-version>(.orig)</tt>. The name
+of the top-level directory in the tarball does not matter, and is
+forgotten.
+ </item>
+ <item>
+Otherwise, the upstream tarball must have been packaged without a
+common top-level directory (shame on the upstream author!). In this
+case, <prgn>dpkg-source</prgn> renames the temporary directory
+<em>itself</em> to
+<tt><packagename>-<upstream-version>(.orig)</tt>.
+ </item>
+ </enumlist>
+ </p>
+ </sect2>
+ <sect2 id="repackaged origtargz">
+ <heading>Repackaged upstream source</heading>
+ <p>
+You <strong>should</strong> upload packages with a pristine source
+tarball if possible, but there are various reasons why it might not be
+possible. This is the case if upstream does not distribute the source
+as gzipped tar at all, or if upstream's tarball contains non-DFSG-free
+material that you must remove before uploading.
+ </p>
+ <p>
+In these cases the developer must construct a suitable .orig.tar.gz
+file himself. We refer to such a tarball as a "repackaged upstream
+source". Note that a "repackaged upstream source" is different from a
+Debian-native package. A repackaged source still comes with
+Debian-specific changes in a separate <tt>.diff.gz</tt> and still has
+a version number composed of <tt><upstream-version></tt> and
+<tt><debian-revision></tt>.
+ </p>
+ <p>
+There may be cases where it is desirable to repackage the source even
+though upstream distributes a <tt>.tar.gz</tt> that could in principle
+be used in its pristine form. The most obvious is if
+<em>significant</em> space savings can be achieved by recompressing
+the tar archive or by removing genuinely useless cruft from the
+upstream archive. Use your own discretion here, but be prepared to
+defend your decision if you repackage source that could have been
+pristine.
+ </p>
+ <p>
+A repackaged .orig.tar.gz
+ </p>
+ <p>
+ <enumlist>
+ <item>
+<p>
+<strong>must</strong> contain detailed information how
+the repackaged source was obtained, and how this can be reproduced, in
+<file>README.Debian-source</file> or a similar file. This file should
+be in the <file>diff.gz</file> part of the Debian source package,
+usually in the <file>debian</file> directory, <em>not</em> in the
+repackaged <file>orig.tar.gz</file>. It is also a good idea to provide a
+<tt>get-orig-source</tt> target in your <file>debian/rules</file> file
+that repeats the process, as described in the Policy Manual, <url
+id="&url-debian-policy;ch-source.html#s-debianrules" name="Main
+building script: debian/rules">.
+</p>
+ </item>
+ <item>
+<strong>should not</strong> contain any file that does not come from the
+upstream author(s), or whose contents has been changed by you.
+<footnote>
+As a special exception, if the omission of non-free files would lead
+to the source failing to build without assistance from the Debian
+diff, it might be appropriate to instead edit the files, omitting only
+the non-free parts of them, and/or explain the situation in a
+README.Debian-source <!-- or similarly named --> file in the root of the source
+tree. But in that case please also urge the upstream author to make
+the non-free components easier seperable from the rest of the source.
+</footnote>
+ </item>
+ <item>
+<p>
+<strong>should</strong>, except where impossible for legal reasons,
+preserve the entire building and portablility infrastructure provided
+by the upstream author. For example, it is not a sufficient reason for
+omitting a file that it is used only when building on
+MS-DOS. Similarly, a Makefile provided by upstream should not be
+omitted even if the first thing your <file>debian/rules</file> does is
+to overwrite it by running a configure script.
+</p>
+<p>
+(<em>Rationale:</em> It is common for Debian users who need to build
+software for non-Debian platforms to fetch the source from a Debian
+mirror rather than trying to locate a canonical upstream distribution
+point).
+</p> </item>
+ <item>
+<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>
+ <item>
+<strong>should</strong> be gzipped with maximal compression.
+ </item>
+ </enumlist>
+ </p>
+ <p>
+The canonical way to meet the latter two points is to let
+<tt>dpkg-source -b</tt> construct the repackaged tarball from an
+unpacked directory.
+ </p>
+ </sect2>
+ <sect2 id="changed-binfiles">
+ <heading>Changing binary files in <tt>diff.gz</tt></heading>
+ <p>
+Sometimes it is necessary to change binary files contained in the
+original tarball, or to add binary files that are not in it.
+If this is done by simply copying the files into the debianized source
+tree, <prgn>dpkg-source</prgn> will not be able to handle this. On the
+other hand, according to the guidelines given above, you cannot
+include such a changed binary file in a repackaged
+<file>orig.tar.gz</file>. Instead, include the file in the
+<file>debian</file> directory in <prgn>uuencode</prgn>d (or similar)
+form
+<footnote>
+The file should have a name that makes it clear which binary file it
+encodes. Usually, some postfix indicating the encoding should be
+appended to the original filename.
+</footnote>.
+The file would then be decoded and copied to its place during the
+build process. Thus the change will be visible quite easy.
+</p>
+<p>
+Some packages use <prgn>dbs</prgn> to manage patches to their upstream
+source, and always create a new <tt>orig.tar.gz</tt> file that
+contains the real <tt>orig.tar.gz</tt> in its toplevel directory. This
+is questionable with respect to the preference for pristine source. On
+the other hand, it is easy to modify or add binary files in this case:
+Just put them into the newly created <tt>orig.tar.gz</tt> file,
+besides the real one, and copy them to the right place during the
+build process.
+ </p>
+ </sect2>
+ </sect1>
+
+
+ </sect>
</chapt>
the most critical thing to spend their time on.
<sect id="submit-bug">
- <heading>Bug reporting</heading>
+ <heading>Bug reporting</heading>
<p>
We encourage you to file bugs as you find them in Debian packages. In
fact, Debian developers are often the first line testers. Finding and
-reporting bugs in other developer's packages improves the quality of
+reporting bugs in other developers' packages improves the quality of
Debian.
<p>
+Read the <url name="instructions for reporting bugs"
+id="&url-bts-report;"> in the Debian <url name="bug tracking system"
+id="&url-bts;">.
+ <p>
Try to submit the bug from a normal user account at which you are
-likely to receive mail. Do not submit bugs as root.
+likely to receive mail, so that people can reach you if they need
+further information about the bug. Do not submit bugs as root.
+ <p>
+You can use a tool like <manref name="reportbug" section="1"> to
+submit bugs. It can automate and generally ease the process.
+ <p>
+Make sure the bug is not already filed against a package.
+Each package has a bug list easily reachable at
+<tt>http://&bugs-host;/<var>packagename</var></tt>
+Utilities like <manref name="querybts" section="1"> can also
+provide you with this information (and <prgn>reportbug</prgn>
+will usually invoke <prgn>querybts</prgn> before sending, too).
+ <p>
+Try to direct your bugs to the proper location. When for example
+your bug is about a package which overwrites files from another package,
+check the bug lists for <em>both</em> of those packages in order to
+avoid filing duplicate bug reports.
<p>
-Make sure the bug is not already filed against a package. Try to do a
-good job reporting a bug and redirecting it to the proper location.
For extra credit, you can go through other packages, merging bugs
-which are reported more than once, or setting bug severities to
-`fixed' when they have already been fixed. Note that when you are
+which are reported more than once, or tagging bugs `fixed'
+when they have already been fixed. Note that when you are
neither the bug submitter nor the package maintainer, you should
not actually close the bug (unless you secure permission from the
maintainer).
with the bug reports that you submitted. Take this opportunity to
close those that you can't reproduce anymore. To find
out all the bugs you submitted, you just have to visit
-<tt>http://&bugs-host;/from:<your-email-addr></tt>.
+<tt>http://&bugs-host;/from:<var><your-email-addr></var></tt>.
<sect1 id="submit-many-bugs">Reporting lots of bugs at once
<p>
possible. If you do not find that possible, then you should consider
orphaning some of your packages (see <ref
id="orphaning">). Alternatively, you may ask the help of other people
-in order to catch up the backlog of bugs that you have (you can ask
+in order to catch up with the backlog of bugs that you have (you can ask
for help on &email-debian-qa; or &email-debian-devel;). At the same
time, you can look for co-maintainers (see <ref id="collaborative-maint">).
<p>
From time to time the QA group organizes bug squashing parties to get rid of
as many problems as possible. They are announced on &email-debian-devel-announce;
-and the announce explains what area will be focused on during the party:
+and the announcement explains which area will be the focus of the party:
usually they focus on release critical bugs but it may happen that they
-decide to help finish a major upgrade going on (like a new perl version
+decide to help finish a major upgrade (like a new perl version
which requires recompilation of all the binary modules).
<p>
The rules for non-maintainer uploads differ during the parties because
-the announce of the party is considered like a prior notice for NMU. If
+the announcement of the party is considered prior notice for NMU. If
you have packages that may be affected by the party (because they have
release critical bugs for example), you should send an update to each of
the corresponding bug to explain their current status and what you expect
<p>
People participating in the party have special rules for NMU, they can
NMU without prior notice if they upload their NMU to
-DELAYED/3-day at least. All other NMU rules applies as usually, they
-should send the patch of the NMU in the BTS (in one of the open bugs
-fixed by the NMU or in a new bug tagged fixed). They should
-also respect the maintainer's wishes if he expressed some.
+DELAYED/3-day at least. All other NMU rules apply as usually; they
+should send the patch of the NMU to the BTS (to one of the open bugs
+fixed by the NMU, or to a new bug, tagged fixed). They should
+also respect any particular wishes of the maintainer.
<p>
-If someone doesn't feel confident with an NMU, he should just send a patch
+If you don't feel confident about doing an NMU, just send a patch
to the BTS. It's far better than a broken NMU.
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>
email address.
-
+<!-- FIXME: moo@packages.d.o is easily confused with moo@packages.qa.d.o -->
<sect id="mia-qa">Dealing with inactive and/or unreachable maintainers
<p>
haven't registered out of the system, so to speak. On the other hand,
it is also possible that they just need a reminder.
<p>
+There is a simple system (the MIA database) in which information about
+maintainers who are deemed Missing In Action are recorded. When a member of the
+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
+about an inactive maintainer already, or that you can add more information,
+you should generally proceed as follows.
+ <p>
The first step is to politely contact the maintainer, and wait for a
-response, for a reasonable time. It is quite hard to define "reasonable
+response for a reasonable time. It is quite hard to define "reasonable
time", but it is important to take into account that real life is sometimes
-very hectic. One way to handle this would be send a reminder after two
+very hectic. One way to handle this would be to send a reminder after two
weeks.
<p>
If the maintainer doesn't reply within four weeks (a month), one can
<list>
<item>The "echelon" information available through the
<url id="&url-debian-db;" name="developers' LDAP database">,
- which indicates when's the last time a developer has posted to
+ which indicates when the developer last has posted to
a Debian mailing list. (This includes uploads via
debian-*-changes lists.) Also, remember to check whether the
maintainer is marked as "on vacation" in the database.
any RC bugs that have been open for ages? Furthermore, how
many bugs are there in general? Another important piece of
information is whether the packages have been NMUed, and if
- so, by whom?
+ so, by whom.
<item>Is there any activity of the maintainer outside of Debian?
For example, they might have posted something recently to
non-Debian mailing lists or news groups.
</list>
<p>
-One big problem are packages which were sponsored -- the maintainer is not
+One big 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
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
-to contact the NMUer before orphaning the package -- perhaps the person who
+to contact the NMUer before orphaning the package — perhaps the person who
has done the NMU is interested in the package.
<p>
One last word: please remember to be polite. We are all volunteers and
cannot dedicate all of our time to Debian. Also, you are not aware of the
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
+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!)
<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
+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.
able to do it on their own, a new maintainer applicant. Sponsoring a package
also means accepting responsibility for it.
<p>
+ <!-- FIXME: service down
If you wish to volunteer as a sponsor, you can sign up at <url
id="&url-sponsors;">.
<p>
+ -->
New maintainers usually have certain difficulties creating Debian packages
— this is quite understandable. That is why the sponsor is there, to check
the package and verify that it is good enough for inclusion in Debian.
the package meets minimum Debian standards. That implies that you
must build and test the package on your own system before uploading.
<p>
-You can not simply upload a binary <file>.deb</file> from the sponsoree. In
+You cannot simply upload a binary <file>.deb</file> from the sponsoree. In
theory, you should only ask for the diff file and the location of the
original source tarball, and then you should download the source and apply
the diff yourself. In practice, you may want to use the source package
email before the package is in acceptable shape. Being a sponsor
means being a mentor.
<p>
-Once the package meets Debian standards, build the package with
-<example>dpkg-buildpackage -us -uc</example> and sign it
-with <example>debsign -m"<var>FULLNAME</var> <var>email-addr</var>" <var>changes-file</var></example>
-before uploading it to the incoming directory.
+Once the package meets Debian standards, build and sign it with
+<example>dpkg-buildpackage -k<var>KEY-ID</var></example>
+before uploading it to the incoming directory. Of course, you can also
+use any part of your <var>KEY-ID</var>, as long as it's unique in your
+secret keyring.
<p>
The Maintainer field of the <file>control</file> file and the
<file>changelog</file> should list the person who did the packaging, i.e., the
Application Managers"> at the Debian web site.
+ <chapt id="l10n">Internationalizing, translating, being internationalized
+ and being translated
+ <p>
+Debian supports an ever-increasing number of natural languages. Even if you are
+a native English speaker and do not speak any other language, it is part of your
+duty as a maintainer to be aware of issues of internationalization (abbreviated
+i18n because there are 18 letters between the 'i' and the 'n' in
+internationalization). Therefore, even if you are ok with English-only
+programs, you should read most of this chapter.
+ <p>
+According to <url id="http://www.debian.org/doc/manuals/intro-i18n/"
+name="Introduction to i18n"> from Tomohiro KUBOTA, "I18N (internationalization)
+means modification of a software or related technologies so that a software can
+potentially handle multiple languages, customs, and so on in the world." while
+"L10N (localization) means implementation of a specific language for an already
+internationalized software."
+ <p>
+l10n and i18n are interconnected, but the difficulties related to each of them are very
+different. It's not really difficult to allow a program to change the language
+in which texts are displayed based on user settings, but it is very time
+consuming to actually translate these messages. On the other hand, setting the
+character encoding is trivial, but adapting the code to use several character
+encodings is a really hard problem.
+ <p>
+Setting aside the i18n problems, where no general guideline can be given, there is
+actually no central infrastructure for l10n within Debian which could be
+compared to the dbuild mechanism for porting. So most of the work has to be
+done manually.
+
+
+ <sect id="l10n-handling">How translations are handled within Debian
+ <p>
+Handling translation of the texts contained in a package is still a manual
+task, and the process depends on the kind of text you want to see translated.
+ <p>
+For program messages, the gettext infrastructure is used most of the time.
+Most of the time, the translation is handled upstream within projects like the
+<url id="http://www.iro.umontreal.ca/contrib/po/HTML/" name="Free Translation
+Project">, the <url id="http://developer.gnome.org/projects/gtp/" name="Gnome
+translation Project"> or the <url id="http://i18n.kde.org/" name="KDE one">.
+The only centralized resource within Debian is the <url
+id="http://www.debian.org/intl/l10n/" name="Central Debian translation
+statistics">, where you can find some statistics about the translation files
+found in the actual packages, but no real infrastructure to ease the translation
+process.
+ <p>
+An effort to translate the package descriptions started long ago, even if very
+little support is offered by the tools to actually use them (i.e., only APT can use
+them, when configured correctly). Maintainers don't need to do
+anything special to support translated package descriptions;
+translators should use the <url id="http://ddtp.debian.org/"
+name="DDTP">.
+ <p>
+For debconf templates, maintainers should use the po-debconf package to ease the
+work of translators, who could use the DDTP to do their work (but the French and
+Brazilian teams don't). Some statistics can be found both on the DDTP site
+(about what is actually translated), and on the <url
+id="http://www.debian.org/intl/l10n/" name="Central Debian translation
+statistics"> site (about what is integrated in the packages).
+ <p>
+For web pages, each l10n team has access to the relevant CVS, and the statistics
+are available from the Central Debian translation statistics site.
+ <p>
+For general documentation about Debian, the process is more or less the same
+than for the web pages (the translators have access to the CVS), but there are
+no statistics pages.
+ <p>
+For package-specific documentation (man pages, info documents, other formats),
+almost everything remains to be done.
+ <p>
+Most notably, the KDE project handles
+translation of its documentation in the same way as its program messages.
+ <p>
+There is an effort to handle Debian-specific man pages
+within a <url
+id="http://cvs.debian.org/manpages/?cvsroot=debian-doc" name="specific CVS
+repository">.
+
+
+ <sect id="l10n-faqm">I18N & L10N FAQ for maintainers
+ <p>
+This is a list of problems that maintainers may face concerning i18n and l10n.
+While reading this, keep in mind that there is no real consensus on these
+points within Debian, and that this is only advice. If you have a better idea
+for a given problem, or if you disagree on some points, feel free to provide
+your feedback, so that this document can be enhanced.
+
+ <sect1 id="l10n-faqm-tr">How to get a given text translated
+ <p>
+To translate package descriptions or debconf templates, you have nothing to do;
+the DDTP infrastructure will dispatch the material to translate to volunteers
+with no need for interaction from your part.
+ <p>
+For all other material (gettext files, man pages, or other documentation), the
+best solution is to put your text somewhere on the Internet, and ask on debian-i18n
+for a translation in different languages. Some translation team members are
+subscribed to this list, and they will take care of the translation and of the
+reviewing process. Once they are done, you will get your translated document from them
+in your mailbox.
+
+ <sect1 id="l10n-faqm-rev">How to get a given translation reviewed
+ <p>
+From time to time, individuals translate some texts in your package
+and will ask you for inclusion of the translation in the package. This can become problematic if
+you are not fluent in the given language. It is a good idea to send the
+document to the corresponding l10n mailing list, asking for a review. Once it
+has been done, you should feel more confident in the quality of the
+translation, and feel safe to include it in your package.
+
+ <sect1 id="l10n-faqm-update">How to get a given translation updated
+ <p>
+If you have some translations of a given text lying around, each time you
+update the original, you should ask the previous translator to update
+the translation with your new changes.
+Keep in mind that this task takes time; at least one week to get
+the update reviewed and all.
+ <p>
+If the translator is unresponsive, you may ask for help on the corresponding
+l10n mailing list. If everything fails, don't forget to put a warning in the
+translated document, stating that the translation is somehow outdated, and that
+the reader should refer to the original document if possible.
+ <p>
+Avoid removing a translation completely because it is outdated. Old
+documentation is often better than no documentation at all for non-English
+speakers.
+
+ <sect1 id="l10n-faqm-bug">How to handle a bug report concerning a translation
+ <p>
+The best solution may be to mark the bug as "forwarded to upstream", and
+forward it to both the previous translator and his/her team (using the
+corresponding debian-l10n-XXX mailing list).
+<!-- TODO: add the i18n tag to the bug? -->
+
+ <sect id="l10n-faqtr">I18N & L10N FAQ for translators
+ <p>
+While reading this, please keep in mind that there is no general procedure
+within Debian concerning these points, and that in any case, you should
+collaborate with your team and the package maintainer.
+
+ <sect1 id="l10n-faqtr-help">How to help the translation effort
+ <p>
+Choose what you want to translate, make sure that nobody is already working on
+it (using your debian-l10n-XXX mailing list), translate it, get it reviewed by
+other native speakers on your l10n mailing list, and provide it to the
+maintainer of the package (see next point).
+
+ <sect1 id="l10n-faqtr-inc">How to provide a translation for inclusion in a package
+ <p>
+Make sure your translation is correct (asking for review on your l10n mailing
+list) before providing it for inclusion. It will save time for everyone, and
+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 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.
+
+ <sect id="l10n-best">Best current practice concerning l10n
+ <p>
+<list>
+ <item>
+As a maintainer, never edit the translations in any way (even to reformat the
+layout) without asking to the corresponding l10n mailing list. You risk for
+example to break the encoding of the file by doing so. Moreover, what you
+consider as an error can be right (or even needed) in the given language.
+ <item>
+As a translator, if you find an error in the original text, make sure to report
+it. Translators are often the most attentive readers of a given text, and if
+they don't report the errors they find, nobody will.
+ <item>
+In any case, remember that the major issue with l10n is that it requires
+several people to cooperate, and that it is very easy to start a flamewar about
+small problems because of misunderstandings. So if you have problems with your
+interlocutor, ask for help on the corresponding l10n mailing list, on
+debian-i18n, or even on debian-devel (but beware, l10n discussions very often
+become flamewars on that list :)
+ <item>
+In any case, cooperation can only be achieved with <strong>mutual respect</strong>.
+</list>
+
<appendix id="tools">Overview of Debian Maintainer Tools
<p>
maintainers. The following is by no means complete or definitive, but
just a guide to some of the more popular tools.
<p>
-Debian maintainer tools are meant to help convenience developers and
+Debian maintainer tools are meant to aid developers and
free their time for critical tasks. As Larry Wall says, there's more
than one way to do it.
<p>
some do not. Debian is officially agnostic on this issue; any tool
which gets the job done is fine. Therefore, this section is not meant
to stipulate to anyone which tools they should use or how they should
-go about with their duties of maintainership. Nor is it meant to
+go about their duties of maintainership. Nor is it meant to
endorse any particular tool to the exclusion of a competing tool.
<p>
Most of the descriptions of these packages come from the actual
<heading><package>dpkg-dev</package>
<p>
<package>dpkg-dev</package> contains the tools (including
-<prgn>dpkg-source</prgn>) required to unpack, build and upload Debian
+<prgn>dpkg-source</prgn>) required to unpack, build, and upload Debian
source packages. These utilities contain the fundamental, low-level
-functionality required to create and manipulated packages; as such,
-they are required for any Debian maintainer.
+functionality required to create and manipulate packages; as such,
+they are essential for any Debian maintainer.
<sect1 id="debconf">
<heading><package>debconf</package></heading>
configuring packages interactively. It is user interface
independent, allowing end-users to configure packages with a
text-only interface, an HTML interface, or a dialog interface. New
-interfaces can be added modularly.
+interfaces can be added as modules.
<p>
You can find documentation for this package in the
<package>debconf-doc</package> package.
<p>
-Many feel that this system should be used for all packages requiring
+Many feel that this system should be used for all packages which require
interactive configuration; see <ref id="bpp-config-mgmt">.
<package>debconf</package> is not currently required by Debian Policy,
but that may change in the future.
you to build packages without being root (packages usually want to
install files with root ownership). If you have
<package>fakeroot</package> installed, you can build packages as a
-user: <tt>dpkg-buildpackage -rfakeroot</tt>.
+regular user: <tt>dpkg-buildpackage -rfakeroot</tt>.
</sect1>
</sect>
is "a Unix C language processor which carries out more thorough checks
on the code than is usual with C compilers." Package lint tools help
package maintainers by automatically finding common problems and
-policy violations with their packages.</p>
+policy violations in their packages.</p>
<sect1 id="lintian">
<heading><package>lintian</package></heading>
<p>
<package>lintian</package> dissects Debian packages and emits
-information on bugs
+information about bugs
and policy violations. It contains automated checks for many aspects
of Debian policy as well as some checks for common errors.
<p>
You should periodically get the newest <package>lintian</package> from
`unstable' and check over all your packages. Notice that the <tt>-i</tt>
option provides detailed explanations of what each error or warning means,
-what is its basis in Policy, and commonly how you can fix the problem.
+what its basis in Policy is, and commonly how you can fix the problem.
<p>
Refer to <ref id="sanitycheck"> for more information on how and when
to use Lintian.
<p>
You can also see a summary of all problems reported by Lintian on your
-packages at <url id="&url-lintian;">. Those reports contain the latest
-<prgn>lintian</prgn> output on the whole development distribution
+packages at <url id="&url-lintian;">. These reports contain the latest
+<prgn>lintian</prgn> output for the whole development distribution
("unstable").
</sect1>
<prgn>debdiff</prgn> (from the <package>devscripts</package> package, <ref id="devscripts">)
compares file lists and control files of two packages. It is a simple
regression test, as it will help you notice if the number of binary
-packages has changed since the last upload, or if something's changed
+packages has changed since the last upload, or if something has changed
in the control file. Of course, some of the changes it reports will be
all right, but it can help you prevent various accidents.
<p>
<p>
Package building tools make the process of writing
<file>debian/rules</file> files easier. See <ref id="helper-scripts">
-for more information on why these might or might not be desired.
+for more information about why these might or might not be desired.
<sect1 id="debhelper">
<heading><package>debhelper</package></heading>
<p>
-<package>debhelper</package> is a collection of programs that can be
+<package>debhelper</package> is a collection of programs which can be
used in <file>debian/rules</file> to automate common tasks related to
-building binary Debian packages. Programs are included to install
+building binary Debian packages. <package>debhelper</package> includes
+programs to install
various files into your package, compress files, fix file permissions,
-integrate your package with the Debian menu system.
+and integrate your package with the Debian menu system.
<p>
Unlike some approaches, <package>debhelper</package> is broken into
-several small, granular commands which act in a consistent manner. As
-such, it allows a greater granularity of control than some of the
+several small, simple commands which act in a consistent manner. As
+such, it allows more fine-grained control than some of the
other "debian/rules tools".
<p>
There are a number of little <package>debhelper</package> add-on
<sect1 id="debmake">
<heading><package>debmake</package>
<p>
-<package>debmake</package>, a pre-cursor to
-<package>debhelper</package>, is a less granular
+<package>debmake</package>, a precursor to
+<package>debhelper</package>, is a more coarse-grained
<file>debian/rules</file> assistant. It includes two main programs:
<prgn>deb-make</prgn>, which can be used to help a maintainer convert
a regular (non-Debian) source archive into a Debian source package;
<package>yada</package> is another packaging helper tool. It uses a
<file>debian/packages</file> file to auto-generate
<file>debian/rules</file> and other necessary files in the
-<file>debian/</file> subdirectory.
- <p>
-Note that <package>yada</package> is called "essentially unmaintained"
-by it's own maintainer, Charles Briscoe-Smith. As such, it can be
-considered deprecated.
+<file>debian/</file> subdirectory. The <file>debian/packages</file> file
+contains instruction to build packages and there is no need to create any
+<file>Makefile</file> files. There is possibility to
+use macro engine similar to the one used in SPECS files from RPM
+source packages.</p>
+ <p>
+For more informations see
+<tt><url id="http://yada.alioth.debian.org/" name="YADA site"></tt>.</p>
</sect1>
<sect1 id="equivs">
<heading><package>debootstrap</package></heading>
<p>
The <package>debootstrap</package> package and script allows you to
-"bootstrap" a Debian base system into any part of your file-system.
+"bootstrap" a Debian base system into any part of your filesystem.
By "base system", we mean the bare minimum of packages required to
operate and install the rest of the system.
<p>
Having a system like this can be useful in many ways. For instance,
you can <prgn>chroot</prgn> into it if you want to test your build
-depends. Or, you can test how your package behaves when installed
-into a bare base system. Chroot builders use this package, see below.
+dependencies. Or you can test how your package behaves when installed
+into a bare base system. Chroot builders use this package; see below.
</sect1>
<sect1 id="pbuilder">
wrong build dependencies will not exist in the resulting package.</p>
<p>
A related package is <package>pbuilder-uml</package>, which goes even
-further build doing the build within User-mode-linux.</p>
+further by doing the build within a User Mode Linux environment.</p>
</sect1>
<sect1 id="sbuild">
possibility of running <prgn>dinstall</prgn> in dry-run mode after the
upload.
</sect1>
+ <sect1 id="dcut">
+ <heading><package>dcut</package></heading>
+ <p>
+The <package>dcut</package> script (part of the package <ref id="dput">)
+helps in removing files from the ftp upload directory.
+ </sect1>
</sect>
<sect id="tools-maint-automate">
<heading>Maintenance automation</heading>
<p>
The following tools help automate different maintenance tasks, from
-adding changelog entries or signature lines, looking up bugs in Emacs,
-to making use of the newest and official use of
+adding changelog entries or signature lines and looking up bugs in Emacs
+to making use of the newest and official
<file>config.sub</file>.</p>
<sect1 id="devscripts">
wrapper around <prgn>dpkg-buildpackage</prgn>. The <prgn>bts</prgn>
utility is also very helpful to update the state of bug reports on the
command line. <prgn>uscan</prgn> can be used to watch for new upstream
-versions of your packages.
The <prgn>debrsign</prgn> can be used to
+versions of your packages. <prgn>debrsign</prgn> can be used to
remotely sign a package prior to upload, which is nice when the
machine you build the package on is different from where your GPG keys
are.</p>
<sect1 id="autotools-dev">
<heading><package>autotools-dev</package></heading>
<p>
-Contains best practices for people maintaining packages that use
+<package>autotools-dev</package>
+contains best practices for people who maintain packages which use
<prgn>autoconf</prgn> and/or <prgn>automake</prgn>. Also contains
canonical <file>config.sub</file> and <file>config.guess</file> files
which are known to work on all Debian ports.</p>
modified), the new package will inherit the changes.</p>
<p>
This utility can make it easy to copy packages from one computer to
-another, or to recreate packages that are installed on your system
-but no longer available elsewhere, or to store the current state of a
+another, or to recreate packages which are installed on your system
+but no longer available elsewhere, or to save the current state of a
package before you upgrade it.</p>
</sect1>
<p>
<prgn>alien</prgn> converts binary packages between various packaging
formats, including Debian, RPM (RedHat), LSB (Linux Standard Base),
-Solaris and Slackware packages.</p>
+Solaris, and Slackware packages.</p>
</sect1>
<sect1 id="debsums">
<p>
<package>dpkg-dev-el</package> is an Emacs lisp package which provides
assistance when editing some of the files in the <file>debian</file>
-directory of your package. For instance, when editing
-<file>debian/changelog</file>, there are handy functions for
-finalizing a version and listing the package's current bugs.</p>
+directory of your package. For instance,
+there are handy functions for
+listing a package's current bugs,
+and for finalizing the latest entry in a
+<file>debian/changelog</file> file.
</sect1>
<sect1 id="dpkg-depcheck">
<!-- FIXME: add the following
questionable:
+ dbs (referred to above)
+ dpatch (referred to above)
+ debarchiver
ucf
dpkg-awk
grep-dctrl
~ianmdlvl / developers-reference.git / blobdiff