<!ENTITY % versiondata SYSTEM "version.ent"> %versiondata;
<!-- common, language independent entities -->
<!ENTITY % commondata SYSTEM "common.ent" > %commondata;
+ <!ENTITY % dynamicdata SYSTEM "dynamic.ent" > %dynamicdata;
<!-- CVS revision of this document -->
- <!ENTITY cvs-rev "$Revision: 1.252 $">
+ <!ENTITY cvs-rev "$Revision: 1.334 $">
<!-- if you are translating this document, please notate the CVS
revision of the original developer's reference in cvs-en-rev -->
<copyright>
<copyrightsummary>
-copyright © 2004 Andreas Barth</copyrightsummary>
+copyright © 2004—2007 Andreas Barth</copyrightsummary>
<copyrightsummary>
copyright © 1998—2003 Adam Di Carlo</copyrightsummary>
<copyrightsummary>
id="&url-gpl;" name="the GNU web site">. You can also obtain it by
writing to the &fsf-addr;.
+<![ %htmltext [
+ <p>
+If you want to print this reference, you should use the <url
+id="developers-reference.pdf" name="pdf version">.
+This page is also available in <url id="index.fr.html" name="French">.
+]]>
+
<toc detail="sect1">
<chapt id="scope">Scope of This Document
get started. Finally, if you are interested in documentation or
Quality Assurance (QA) work you can join maintainers already working on
these tasks and submit patches and improvements.
+
+ <p>
+One pitfall could be a too-generic local part in your mailadress:
+Terms like mail, admin, root, master should be avoided, please
+see <url id="http://www.debian.org/MailingLists/"> for details.
+
+
+ <sect id="mentors">Debian mentors and sponsors
+ <p>
+The mailing list &email-debian-mentors; has been set up for novice
+maintainers who seek help with initial packaging and other
+developer-related issues. Every new developer is invited to subscribe
+to that list (see <ref id="mailing-lists"> for details).
+ <p>
+Those who prefer one-on-one help (e.g., via private email) should also
+post to that list and an experienced developer will volunteer to help.
+ <p>
+In addition, if you have some packages ready for inclusion in Debian,
+but are waiting for your new maintainer application to go through, you
+might be able find a sponsor to upload your package for you. Sponsors
+are people who are official Debian Developers, and who are willing to
+criticize and upload your packages for you.
+<!-- FIXME - out of order
+Those who are seeking a
+sponsor can request one at <url id="&url-sponsors;">.
+-->
+Please read the
+unofficial debian-mentors FAQ at <url id="&url-mentors;"> first.
+ <p>
+If you wish to be a mentor and/or sponsor, more information is
+available in <ref id="newmaint">.
<sect id="registering">Registering as a Debian developer
<p>
Before you decide to register with &debian-formal;, you will need to
read all the information available at the <url id="&url-newmaint;"
-name="New Maintainer's Corner">. It describes exactly the
+name="New Maintainer's Corner">. It describes in detail the
preparations you have to do before you can register to become a Debian
developer.
The process of registering as a developer is a process of verifying
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
+&number-of-maintainers; and our systems are used in several
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>
Before you actually register you should have shown that you can do
-competent work and will be a good contributor. You can show this by
-submitting patches through the Bug Tracking System or having a package
-sponsored by an existing maintainer for a while. Also, we expect that
+competent work and will be a good contributor.
+You show this by submitting patches through the Bug Tracking System
+and having a package
+sponsored by an existing Debian Developer for a while.
+Also, we expect that
contributors are interested in the whole project and not just in
maintaining their own packages. If you can help other maintainers by
providing further information on a bug or even a patch, then do so!
Registration requires that you are familiar with Debian's philosophy
and technical documentation. Furthermore, you need a GnuPG key which
has been signed by an existing Debian maintainer. If your GnuPG key
-is not signed yet, you should try to meet a Debian maintainer in
+is not signed yet, you should try to meet a Debian Developer in
person to get your key signed. There's a <url id="&url-gpg-coord;"
name="GnuPG Key Signing Coordination page"> which should help you find
-a maintainer close to you. (If 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
-<url id="&url-newmaint-id;" name="identification page"> for more
-information about these two options.)
+a Debian Developer close to you.
+(If there is no Debian Developer close to you,
+alternative ways to pass the ID check may be permitted
+as an absolute exception on a case-by-case-basis.
+See the <url id="&url-newmaint-id;" name="identification page">
+for more information.)
<p>
If you do not have an OpenPGP key yet, generate one. Every developer
-needs a OpenPGP key in order to sign and verify package uploads. You
+needs an OpenPGP key in order to sign and verify package uploads. You
should read the manual for the software you are using, since it has
much important information which is critical to its security. Many
more security failures are due to human error than to software failure
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 called ``DSS'' or ``DH/ElGamal'').
-Other key types may be used, however. Your key length must be at least 1024
+You need a version 4 key for use in Debian Development.
+Your key length must be at least 1024
bits; there is no reason to use a smaller key, and doing so would be
-much less secure. Your key must be signed with at least your own user
-ID; this prevents user ID tampering. <prgn>gpg</prgn> does this
-automatically.
- <p>
-If your public key isn't on public key servers such as &pgp-keyserv;,
-please read the documentation available locally in &file-keyservs;.
+much less secure.
+<footnote>Version 4 keys are keys conforming to
+the OpenPGP standard as defined in RFC 2440. Version 4 is the key
+type that has always been created when using GnuPG. PGP versions
+since 5.x also could create v4 keys, the other choice having beein
+pgp 2.6.x compatible v3 keys (also called "legacy RSA" by PGP).
+<p>
+Version 4 (primary) keys can either use the RSA or the DSA algorithms,
+so this has nothing to do with GnuPG's question about "which kind
+of key do you want: (1) DSA and Elgamal, (2) DSA (sign only), (5)
+RSA (sign only)". If you don't have any special requirements just pick
+the default.
+<p>
+The easiest way to tell whether an existing key is a v4 key or a v3
+(or v2) key is to look at the fingerprint:
+Fingerprints of version 4 keys are the SHA-1 hash of some key matieral,
+so they are 40 hex digits, usually grouped in blocks of 4. Fingerprints
+of older key format versions used MD5 and are generally shown in blocks
+of 2 hex digits. For example if your fingerprint looks like
+<tt>5B00 C96D 5D54 AEE1 206B AF84 DE7A AF6E 94C0 9C7F</tt>
+then it's a v4 key.
+<p>
+Another possibility is to pipe the key into <prgn>pgpdump</prgn>,
+which will say something like "Public Key Packet - Ver 4".
+<p>
+Also note that your key must be self-signed (i.e. it has to sign
+all its own user IDs; this prevents user ID tampering). All
+modern OpenPGP software does that automatically, but if you
+have an older key you may have to manually add those signatures.
+</footnote>
+ <p>
+If your public key isn't on a public key server such as &pgp-keyserv;,
+please read the documentation available at
+<url id="&url-newmaint-id;" name="NM Step 2: Identification">.
That document contains instructions on how to put your key on the
public key servers. The New Maintainer Group will put your public key
on the servers if it isn't already there.
citizens. This need not impede one's activities as a Debian package
maintainer however, as it may be perfectly legal to use cryptographic
products for authentication, rather than encryption purposes.
-&debian-formal; does not require the use of cryptography <em>qua</em>
-cryptography in any manner. If you live in a country where use of
+If you live in a country where use of
cryptography even for authentication is forbidden
then please contact us so we can make special arrangements.
<p>
-To apply as a new maintainer, you need an existing Debian maintainer
-to verify your application (an <em>advocate</em>). After you have
+To apply as a new maintainer, you need an existing Debian Developer
+to support your application (an <em>advocate</em>). After you have
contributed to Debian for a while, and you want to apply to become a
registered developer, an existing developer with whom you
have worked over the past months has to express their belief that you
a lot of time later on.
- <sect id="mentors">Debian mentors and sponsors
- <p>
-The mailing list &email-debian-mentors; has been set up for novice
-maintainers who seek help with initial packaging and other
-developer-related issues. Every new developer is invited to subscribe
-to that list (see <ref id="mailing-lists"> for details).
- <p>
-Those who prefer one-on-one help (e.g., via private email) should also
-post to that list and an experienced developer will volunteer to help.
- <p>
-In addition, if you have some packages ready for inclusion in Debian,
-but are waiting for your new maintainer application to go through, you
-might be able find a sponsor to upload your package for you. Sponsors
-are people who are official Debian maintainers, and who are willing to
-criticize and upload your packages for you. Those who are seeking a
-sponsor can request one at <url id="&url-sponsors;">. Please read the
-inofficial debian-mentors FAQ at <url id="&url-mentors;"> first.
- <p>
-If you wish to be a mentor and/or sponsor, more information is
-available in <ref id="newmaint">.
-
-
<chapt id="developer-duties">Debian Developer's Duties
<sect id="user-maint">Maintaining your Debian information
<tt>&keyserver-host;</tt>.
<p>
If you need to add a completely new key or remove an old key, you need
-to get the new key signed by another developer. After this, a mail
-signed by another developer listing your account name, the keyids
-of the old and of the new key and the reason should be send to
-&email-debian-keyring;. If the old key is compromised or invalid, you
+to get the new key signed by another developer.
+If the old key is compromised or invalid, you
also have to add the revocation certificate. If there is no real
-reason for a new key, the Keyring Maintainers will only accept it if
-it's more secure and connected to the old key.
+reason for a new key, the Keyring Maintainers might reject the new key.
+Details can be found at
+<url id="http://keyring.debian.org/replacing_keys.html">.
<p>
The same key extraction routines discussed in <ref id="registering">
apply.
issue several calls for votes on &email-debian-devel-announce; (and all
developers are expected to be subscribed to that list). Democracy doesn't
work well if people don't take part in the vote, which is why we encourage
-all developers to vote. Voting is conducted via GPG-signed/encrypted emails
+all developers to vote. Voting is conducted via GPG-signed/encrypted email
messages.
<p>
-The list of all the proposals (past and current) is available on the
+The list of all proposals (past and current) is available on the
<url id="&url-vote;" name="Debian Voting Information"> page, along with
information on how to make, second and vote on proposals.
<p>
It is common for developers to have periods of absence, whether those are
planned vacations or simply being buried in other work. The important thing
-to notice is that the other developers need to know that you're on vacation
+to notice is that other developers need to know that you're on vacation
so that they can do whatever is needed if a problem occurs with your
packages or other duties in the project.
<p>
Usually this means that other developers are allowed to NMU (see
-<ref id="nmu">) your package if a big problem (release critical bugs,
+<ref id="nmu">) your package if a big problem (release critical bug,
security update, etc.) occurs while you're on vacation. Sometimes it's
-nothing as critical as that, but it's still appropriate to let the others
+nothing as critical as that, but it's still appropriate to let others
know that you're unavailable.
<p>
-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>
-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.
+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> 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>
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).
-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.
-Those bugs can delay the Debian release
-and/or can justify the removal of a package at freeze time. That's why
-these bugs need to be corrected as quickly as possible.
+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.
+These bugs can delay the Debian release and/or can justify the removal of
+a package at freeze time. That's why these bugs need to be corrected as
+quickly as possible.
<p>
Developers who are part of the <url id="&url-debian-qa;"
name="Quality Assurance"> group are following all such bugs, and trying
<item>
Orphan all your packages, as described in <ref id="orphaning">.
<item>
-Send an email about why you are leaving the project to
+Send an gpg-signed email about why you are leaving the project to
&email-debian-private;.
<item>
Notify the Debian key ring maintainers that you are leaving by
-emailing to &email-debian-keyring;.
+opening a ticket in Debian RT by sending a mail
+to keyring@rt.debian.org with the words 'Debian RT' somewhere in the subject
+line (case doesn't matter).
</enumlist>
replying to. In general, please adhere to the usual conventions for
posting messages.
<p>
-Please read the <url name="code of conduct" id="&url-debian-lists;#codeofconduct">
-for more information.
+Please read the <url name="code of conduct"
+id="&url-debian-lists;#codeofconduct"> for more information. The <url
+name="Debian Community Guidelines" id="&url-dcg;">
+are also worth reading.
<sect1 id="core-devel-mailing-lists">Core development mailing lists
<p>
<sect id="irc-channels">IRC channels
<p>
Several IRC channels are dedicated to Debian's development. They are mainly
-hosted on the <url id="&url-openprojects;" name="freenode"> network
-(previously known as Open Projects Network).
-The <tt>irc.debian.org</tt> DNS entry is an alias to
-<tt>irc.freenode.net</tt>.
+hosted on the <url id="&url-oftc;" name="Open and free technology community
+(OFTC)"> network. The <tt>irc.debian.org</tt> DNS entry is an alias to
+<tt>irc.oftc.net</tt>.
<p>
The main channel for Debian in general is <em>#debian</em>. This is a large,
general-purpose channel where users can find recent news in the topic and
all the files.
<p>
There are other additional channels dedicated to specific subjects.
-<em>#debian-bugs</em> is used for coordinating bug squash parties.
-<em>#debian-boot</em> is used to coordinate the work on the boot
-floppies (i.e., the installer).
-<!-- FIXME: is boot-floppies an anachronism, or still the channel name? -->
+<em>#debian-bugs</em> is used for coordinating bug squashing parties.
+<em>#debian-boot</em> is used to coordinate the work on the debian-installer.
<em>#debian-doc</em> is
occasionally used to talk about documentation, like the document you are
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>,
<em>#debian-edu</em>,
-<em>#debian-sf</em> (SourceForge package), <em>#debian-oo</em> (OpenOffice
+<em>#debian-oo</em> (OpenOffice
package) ...
<p>
Some non-English developers' channels exist as well, for example
French speaking people interested in Debian's development.
<p>
Channels dedicated to Debian also exist on other IRC networks, notably on
-the <url name="Open and free technology community (OFTC)"
-id="http://www.oftc.net/"> IRC network.
+the <url id="&url-openprojects;" name="freenode"> IRC network, which was
+pointed at by the <tt>irc.debian.org</tt> alias until 4th June 2006.
+ <p>
+To get a cloak on freenode, you send Jörg Jaspert
+<joerg@debian.org> a signed mail where you tell what your nick is.
+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
for porting activities, and they all have a permanent connection to the
Internet.
<p>
-Most of the machines are available for individual developers to use,
+Some of the machines are available for individual developers to use,
as long as the developers follow the rules set forth in the
<url name="Debian Machine Usage Policies" id="&url-dmup;">.
<p>
Generally speaking, you can use these machines for Debian-related purposes
as you see fit. Please be kind to system administrators, and do not use
up tons and tons of disk space, network bandwidth, or CPU without first
-getting the approval of the system administrators. Usually these machines are run by
-volunteers.
+getting the approval of the system administrators. Usually these machines
+are run by volunteers.
<p>
Please take care to protect your Debian passwords and SSH keys installed on
Debian machines. Avoid login or upload methods which send passwords over
<p>
If you have a problem with the operation of a Debian server, and you
think that the system operators need to be notified of this problem,
-the Debian system administrator team is reachable at
-<email>debian-admin@lists.debian.org</email>.
+you can check the list of open issues in the DSA queue of our request
+tracker at <url id="&url-rt;"> (you can login with user "guest" and
+password "readonly"). To report a new problem, simply send a mail to
+<email>admin@rt.debian.org</email> and make sure to put the string
+"Debian RT" somewhere in the subject.
<p>
If you have a problem with a certain service, not related to the system
administration (such as packages to be removed from the archive,
<sect1 id="servers-ftp-master">The ftp-master server
<p>
-The <tt>ftp-master.debian.org</tt> server holds the canonical copy of the Debian
-archive (excluding the non-US packages). Generally, package uploads
+The <tt>ftp-master.debian.org</tt> server holds the canonical copy of the
+Debian archive. Generally, package uploads
go to this server; see <ref id="upload">.
<p>
It is restricted; a mirror is available on <tt>merkel</tt>.
an email to &email-ftpmaster;, but also see the procedures in
<ref id="archive-manip">.
- <sect1 id="servers-non-us">The non-US server
- <p>
-The non-US server, <tt>non-us.debian.org</tt>,
-holds the canonical copy of the non-US part of the Debian archive.
-If you need to upload a package into one of the non-US sections, upload it
-to this server; see <ref id="upload-non-us">.
- <p>
-Problems with the non-US package archive should generally be submitted as
-bugs against the <package>nonus.debian.org</package> pseudo-package (notice
-the lack of hyphen between "non" and "us" in the pseudo-package name
-— that's for backwards compatibility). Remember to check whether or
-not someone else has already reported the problem to the
-<url id="http://&bugs-host;/nonus.debian.org" name="Bug Tracking System">.
-
<sect1 id="servers-www">The www-master server
<p>
The main web server is <tt>www-master.debian.org</tt>.
<p>
Usually the only reason to use a different host is when you need to publish
materials subject to the U.S. export restrictions, in which case you can use
-one of the other servers located outside the United States, such as the
-aforementioned <tt>non-us.debian.org</tt>.
+one of the other servers located outside the United States.
<p>
Send mail to &email-debian-devel; if you have any questions.
- <sect1 id="servers-cvs">The CVS server
-<!-- TODO: document svn.debian.org, arch.debian.org also -->
+ <sect1 id="servers-vcs">The VCS servers
<p>
-Our CVS server is located on <tt>cvs.debian.org</tt>.
+If you need to use a Version Control System for any of your Debian work,
+you can use one the existing repositories hosted on Alioth or you can
+request a new project and ask for the VCS repository of your choice.
+Alioth supports CVS (alioth.debian.org), Subversion
+(svn.debian.org), Arch (tla/baz, both on arch.debian.org), Bazaar
+(bzr.debian.org), Mercurial (hg.debian.org) and Git (git.debian.org).
+Checkout <url id="&url-alioth-pkg;"> if you plan
+to maintain packages in a VCS repository. See <ref id="alioth"> for
+information on the services provided by Alioth.
<p>
-If you need to use a publicly accessible CVS
-server, for instance, to help coordinate work on a package between
-many different developers, you can request a CVS area on the server.
- <p>
-Generally, <tt>cvs.debian.org</tt> offers a combination of local CVS
-access, anonymous client-server read-only access, and full
-client-server access through <prgn>ssh</prgn>. Also, the CVS area can
-be accessed read-only via the Web at <url id="&url-cvsweb;">.
- <p>
-To request a CVS area, send a request via email to
-&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.
+Historically, Debian first used <tt>cvs.debian.org</tt> to host CVS
+repositories. But that service is deprecated in favor of Alioth.
+Only a few projects are still using it.
<sect1 id="dchroot">chroots to different distributions
<p>
On some machines, there are chroots to different distributions available.
-You can use them like
+You can use them like this:
<example>
vore% dchroot unstable
&sample-dist-dirtree;
<p>
As you can see, the top-level directory contains two directories,
-<file>dists/</file> and <file>pool/</file>. The latter is a “pool” in which the
+<file>dists/</file> and <file>pool/</file>. The latter is a
+“pool” in which the
packages actually are, and which is handled by the archive maintenance
database and the accompanying programs. The former contains the
distributions, <em>stable</em>, <em>testing</em> and <em>unstable</em>.
equally applicable to the <em>unstable</em> and <em>testing</em>
distributions.
<p>
-<file>dists/stable</file> contains three directories, namely <file>main</file>,
-<file>contrib</file>, and <file>non-free</file>.
+<file>dists/stable</file> contains three directories, namely
+<file>main</file>, <file>contrib</file>, and <file>non-free</file>.
<p>
In each of the areas, there is a directory for the source packages
(<file>source</file>) and a directory for each supported architecture
<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 that the term "section" is also used to refer to categories
<sect1>Architectures
<p>
-In the first days, the Linux kernel was only available for the Intel
-i386 (or greater) platforms, and so was Debian. But when Linux became
+In the first days, the Linux kernel was only available for Intel
+i386 (or greater) platforms, and so was Debian. But as Linux became
more and more popular, the kernel was ported to other architectures,
too.
<p>
contains the sources of the program. If a package is distributed
elsewhere too, the <file>.orig.tar.gz</file> file stores the so-called
<em>upstream source code</em>, that is the source code that's
-distributed from the <em>upstream maintainer</em> (often the author of
+distributed by the <em>upstream maintainer</em> (often the author of
the software). In this case, the <file>.diff.gz</file> contains the
changes made by the Debian maintainer.
<p>
(another is <file>/pub/debian</file>).
<p>
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>
-directory of the archive (for backwards compatibility).
+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> directory of the archive (for backwards
+compatibility).
<sect2 id="sec-dists">Stable, testing, and unstable
<p>
After a period of development, once the release manager deems fit, the
<em>testing</em> distribution is frozen, meaning that the policies
-which control how packages move from <em>unstable</em> to <em>testing</em> are
-tightened. Packages which are too buggy are removed. No changes are
-allowed into <em>testing</em> except for bug fixes. After some time
-has elapsed, depending on progress, the <em>testing</em> distribution
-goes into a `deep freeze', when no changes are made to it except those
-needed for the installation system. This is called a “test cycle”,
-and it can last up to two weeks. There can be several test cycles,
-until the distribution is prepared for release, as decided by the
-release manager. At the end of the last test cycle, the
-<em>testing</em> distribution is renamed to <em>stable</em>,
-overriding the old <em>stable</em> distribution, which is removed at
-that time (although it can be found at <tt>&archive-host;</tt>).
+which control how packages move from <em>unstable</em> to <em>testing</em>
+are tightened. Packages which are too buggy are removed. No changes are
+allowed into <em>testing</em> except for bug fixes. After some time has
+elapsed, depending on progress, the <em>testing</em> distribution is
+frozen even further. Details of the handling of the testing distribution
+are published by the Release Team on debian-devel-announce. After the
+open issues are solved to the satisfaction of the Release Team, the
+distribution is released. Releasing means that <em>testing</em> is
+renamed to <em>stable</em>, and a new copy is created for the new
+<em>testing</em>, and the previous <em>stable</em> is renamed to
+<em>oldstable</em> and stays there until it is finally archived. On
+archiving, the contents are moved to <tt>&archive-host;</tt>).
<p>
This development cycle is based on the assumption that the
<em>unstable</em> distribution becomes <em>stable</em> after passing a
stable distribution is incremented (e.g., ‘3.0’ becomes
‘3.0r1’, ‘2.2r4’ becomes ‘2.2r5’, and
so forth).
+Please refer to
+<qref id="upload-stable">uploads to the <em>stable</em> distribution</qref>
+for details.
<p>
Note that development under <em>unstable</em> continues during the
freeze period, since the <em>unstable</em> distribution remains in
These are the <manref name="sources.list" section="5"> lines for
<em>experimental</em>:
<example>
-deb http://ftp.<var>xy</var>.debian.org/debian/ ../project/experimental main
-deb-src http://ftp.<var>xy</var>.debian.org/debian/ ../project/experimental main
+deb http://ftp.<var>xy</var>.debian.org/debian/ experimental main
+deb-src http://ftp.<var>xy</var>.debian.org/debian/ experimental main
</example>
<p>
If there is a chance that the software could do grave damage to a system,
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.
+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>
Every released Debian distribution has a <em>code name</em>: Debian
1.1 is called `buzz'; Debian 1.2, `rex'; Debian 1.3, `bo'; Debian 2.0,
-`hamm'; Debian 2.1, `slink'; Debian 2.2, `potato'; and Debian 3.0, `woody'. There is also
-a ``pseudo-distribution'', called `sid', which is the current
+`hamm'; Debian 2.1, `slink'; Debian 2.2, `potato'; Debian 3.0, `woody';
+Debian 3.1, "sarge";
+Debian 4.0, "etch".
+There is also a ``pseudo-distribution'', called `sid', which is the current
`unstable' distribution; since packages are moved from `unstable' to
`testing' as they approach stability, `sid' itself is never released.
As well as the usual contents of a Debian distribution, `sid' contains
<p>
The Incoming system is responsible for collecting updated packages and
installing them in the Debian archive. It consists of a set of
-directories and scripts that are installed both on <tt>&ftp-master-host;</tt>
-and <tt>&non-us-host;</tt>.
+directories and scripts that are installed on <tt>&ftp-master-host;</tt>.
<p>
Packages are uploaded by all the maintainers into a directory called
-<file>unchecked</file>. This directory 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 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.
+<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 (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 the `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
-made, a special script is called to ask all the primary mirrors to update
-themselves.
+<file>Packages</file> and <file>Sources</file> index files for example)
+have been made, a special script is called to ask all the primary mirrors
+to update themselves.
<p>
The archive maintenance software will also send the OpenPGP/GnuPG signed
<file>.changes</file> file that you uploaded to the appropriate mailing
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
to the <file>reject</file> directory in order to remove their bad uploads
<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 to
-one of those directories will be moved to 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 which is run each day and which moves the
packages between the directories. Those which are in "1-day" are
</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>
-
+<example>DELAY=5 dupload -X-to delayed <changes-file></example>
+-->
<sect id="pkg-info">Package information
<sect1 id="madison">The <prgn>madison</prgn> utility
<p>
<prgn>madison</prgn> is a command-line utility that is available
-on both <tt>&ftp-master-host;</tt> and <tt>&non-us-host;</tt>, and on
+on <tt>&ftp-master-host;</tt>, and on
the mirror on <tt>&ftp-master-mirror;</tt>. It
uses a single argument corresponding to a package name. In result
it displays which version of the package is available for each
libdbd-mysql-perl | 1.2219-1 | unstable | source, alpha, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc
</example>
<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 version of the package has been
-recompiled on most of the architectures.
+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 version of the package
+has been recompiled on most of the architectures.
<sect id="pkg-tracking-system">The Package Tracking System
<p>
all messages sent to these addresses must contain the <tt>X-PTS-Approved</tt>
header with a non-empty value.
+ <tag><tt>contact</tt>
+ <item>
+Mails sent to the maintainer through the *@packages.debian.org email
+aliases.
+
<tag><tt>summary</tt>
<item>
-(This is a planned expansion.)
-The regular summary emails about the package's status (bug statistics,
-porting overview, progression in <em>testing</em>, ...).
+Regular summary emails about the package's status.
+Currently, only progression in <em>testing</em> is sent.
+
</taglist>
<p>
<tag><tt>cvs</tt>
<item>
-CVS commit notifications, if the package has a CVS repository and the
-maintainer has set up forwarding commit notifications to the PTS.
+VCS commit notifications, if the package has a VCS repository and the
+maintainer has set up forwarding of commit notifications to the PTS. The
+"cvs" name is historic, in most cases commit notifications will come
+from some other VCS like subversion or git.
<tag><tt>ddtp</tt>
<item>
Translations of descriptions or debconf templates
submitted to the Debian Description Translation Project.
+
+ <tag><tt>derivatives</tt>
+ <item>
+Information about changes made to the package in derivative distributions
+(for example Ubuntu).
</taglist>
<sect1 id="pts-commands">The PTS email interface
<p>
You can control your subscription(s) to the PTS by sending
-various commands to <email>pts@qa.debian.org</email>.
+various commands to <email>pts@qa.debian.org</email>.
<taglist>
<tag><tt>unsubscribe <sourcepackage> [<email>]</tt>
<item>
- 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.
+ 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>unsubscribeall [<email>]</tt>
+<item>
+ Removes all subscriptions of the specified email address or the sender
+ address if the second argument is left out.
<tag><tt>which [<email>]</tt>
<item>
<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>summary</tt>: automatic summary mails about the state of a package
- <item><tt>cvs</tt>: notification of CVS commits
+ <item><tt>summary</tt>: automatic summary mails about the state of a
+ package
+ <item><tt>contact</tt>: mails sent to the maintainer through the
+ *@packages.debian.org aliases
+ <item><tt>cvs</tt>: notification of VCS commits
<item><tt>ddtp</tt>: translations of descriptions and debconf templates
+ <item><tt>derivatives</tt>: changes made on the package by derivative
+ distributions
<item><tt>upload-source</tt>: announce of a new source upload that
- has been accepted
- <item><tt>upload-binary</tt>: announce of a new binary-only upload (porting)
+ has been accepted
+ <item><tt>upload-binary</tt>: announce of a new binary-only upload
+ (porting)
<item><tt>katie-other</tt>: other mails from ftpmasters
(override disparity, etc.)
- <item><tt>default</tt>: all the other mails (those which aren't "automatic")
- </list>
+ <item><tt>default</tt>: all the other mails (those which aren't
+ "automatic")
+</list>
<tag><tt>keyword <sourcepackage> [<email>]</tt>
<item>
<tag><tt>keyword [<email>] {+|-|=} <list of keywords></tt>
<item>
Accept (+) or refuse (-) mails classified under the given keyword(s).
- Define the list (=) of accepted keywords.
+ Define the list (=) of accepted keywords. This changes the default set
+ of keywords accepted by a user.
+
+<tag><tt>keywordall [<email>] {+|-|=} <list of keywords></tt>
+<item>
+ Accept (+) or refuse (-) mails classified under the given keyword(s).
+ Define the list (=) of accepted keywords. This changes the set of
+ accepted keywords of all the currently active subscriptions of a user.
<tag><tt>keyword <sourcepackage> [<email>] {+|-|=} <list of keywords></tt>
<item>
the bot.
</taglist>
+ <p>
+The <prgn>pts-subscribe</prgn> command-line utility (from the
+<package>devscripts</package> package) can be handy to temporarily
+subscribe to some packages, for example after having made an
+non-maintainer upload.
+
<sect1 id="pts-mail-filtering">Filtering PTS mails
<p>
Once you are subscribed to a package, you will get the mails sent to
X-Loop: dpkg@&pts-host;
X-PTS-Package: dpkg
X-PTS-Keyword: upload-source
-X-Unsubscribe: echo 'unsubscribe dpkg' | mail pts@qa.debian.org
+List-Unsubscribe: <mailto:pts@qa.debian.org?body=unsubscribe+dpkg>
</example>
- <sect1 id="pts-cvs-commit">Forwarding CVS commits in the PTS
+ <sect1 id="pts-vcs-commit">Forwarding VCS commits in the PTS
<p>
-If you use a publicly accessible CVS repository for maintaining
+If you use a publicly accessible VCS repository for maintaining
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>
-Once you set up the CVS repository to generate commit notifications,
+Once you set up the VCS 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.
+Note that the mail need to be sent from a <tt>debian.org</tt> machine,
+otherwise you'll have to add the <tt>X-PTS-Approved: 1</tt> header.
+ <p>
+For Subversion repositories, the usage of svnmailer is recommended.
+See <url id="&url-alioth-pkg;"> for an example on how to do it.
<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,
+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
<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>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
+<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>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>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>
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.
+<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
</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.
+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
</example>
<p>
Think twice before adding a news item to the PTS because you won't be able
-to remove it later and you wan't be able to edit it either. The only thing
+to remove it later and you won't be able to edit it either. The only thing
that you can do is send a second news item that will deprecate the
information contained in the previous one.
useful information.
<p>
It is a good idea to look up your own data regularly so that
-you don't forget any open bug, and so that you don't forget which
-packages are under your responsibility.
+you don't forget any open bugs, and so that you don't forget which
+packages are your responsibility.
- <sect id="alioth">Debian *Forge: Alioth
+ <sect id="alioth">Debian's GForge installation: 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
+Alioth is a 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.
+or its derivatives. It's heavily used by many Debian teams and provides
+hosting for all sorts of VCS repositories.
<p>
-For more information please visit <url id="&url-alioth;">.
+All Debian developers automatically have an account on Alioth.
+They can activate it by using the recover password facility.
+External developers can request guest accounts on Alioth.
+ <p>
+For more information please visit the following links:
+<list>
+<item><url id="&url-alioth-wiki;">
+<item><url id="&url-alioth-faq;">
+<item><url id="&url-alioth-pkg;">
+<item><url id="&url-alioth;">
+</list>
+
+ <sect id="developer-misc">Goodies for Developers
+ <p>
+ <sect1 id="lwn">LWN Subscriptions
+ <p>
+Since October of 2002, HP has sponsored a subscription to LWN for all
+interested Debian developers.
+
+Details on how to get access to this benefit are in
+<url id="http://lists.debian.org/debian-devel-announce/2002/10/msg00018.html">.
+
<chapt id="pkgs">Managing Packages
-- <var>short description</var>'', substituting the name of the new
package for <var>foo</var>. The severity of the bug report must be set
to <em>wishlist</em>. If you feel it's necessary, send a copy to
-&email-debian-devel; by putting the address in the <tt>X-Debbugs-CC:</tt> header
-of the message (no, don't use <tt>CC:</tt>, because that way the message's subject
-won't indicate the bug number).
+&email-debian-devel; by putting the address in the <tt>X-Debbugs-CC:</tt>
+header 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 in the
changelog of the new package in order for the bug report to be
automatically closed once the new package is installed in the archive
(see <ref id="upload-bugfix">).
+ <p>
+When closing security bugs include CVE numbers as well as the
+"Closes: #nnnnn".
+This is useful for the security team to track vulnerabilities.
+If an upload is made to fix the bug before the advisory ID is known,
+it is encouraged to modify the historical changelog entry with the next
+upload. Even in this case, please include all available pointers to
+background information in the original changelog entry.
+
<p>
There are a number of reasons why we ask maintainers to announce their
intentions:
The announcements give maintainers and other interested parties a
better feel of what is going on, and what is new, in the project.
</list>
-
+ <p>
+Please see <url id="http://ftp-master.debian.org/REJECT-FAQ.html">
+for common rejection reasons for a new package.
<sect id="changelog-entries">Recording changes in the package
<p>
tests the <file>postrm</file> and <file>prerm</file> scripts.
<item>
Remove the package, then reinstall it.
+ <item>
+Copy the source package in a different directory and try unpacking it and
+rebuilding it. This tests if the package relies on existing files outside of
+it, or if it relies on permissions being preserved on the files shipped
+inside the .diff.gz file.
</list>
source tar-file used by <prgn>dpkg-source</prgn> when constructing the
<file>.dsc</file> file and diff to be uploaded <em>must</em> be
byte-for-byte identical with the one already in the archive.
+ <p>
+Please notice that, in non-native packages, permissions on files that are
+not present in the .orig.tar.gz will not be preserved, as diff does not
+store file permissions in the patch.
<sect id="distribution">Picking a distribution
<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
-testing before it is actually included in <em>stable</em>.
+Uploading to <em>stable</em> means that the package will transfered to the
+<em>p-u-new</em>-queue for review by the stable release managers, and
+if approved will be installed in
+<file>stable-proposed-updates</file> directory of the Debian archive.
+From there, it will be included in <em>stable</em> with the next point
+release.
<p>
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:
those other packages uninstallable, is strongly discouraged.
<p>
The Release Team (which can be reached at &email-debian-release;) will
-regularly evaluate the uploads in <em>stable-proposed-updates</em> and decide if
-your package can be included in <em>stable</em>. Please be clear (and
-verbose, if necessary) in your changelog entries for uploads to
+regularly evaluate the uploads To <em>stable-proposed-updates</em> and
+decide if your package can be included in <em>stable</em>. Please be clear
+(and verbose, if necessary) in your changelog entries for uploads to
<em>stable</em>, because otherwise the package won't be considered for
inclusion.
<p>
<sect1 id="upload-t-p-u">
<heading>Special case: uploads to <em>testing/testing-proposed-updates</em></heading>
<p>
-Please see the information in the <qref id="t-p-u">testing section</qref> for details.
+Please see the information in the <qref id="t-p-u">testing section</qref>
+for details.
<sect id="upload">Uploading a package
archive maintenance software will parse the changes file and see that not
all files have been uploaded.
<p>
-<!-- FIXME: is this still topical? Explain the rationale? -->
-<em>Note:</em> Do not upload to <tt>ftp-master</tt> cryptographic
-packages which belong to <em>contrib</em> or <em>non-free</em>. Uploads of
-such software should go to <tt>non-us</tt> (see <ref
-id="upload-non-us">). Furthermore packages containing code that is
-patent-restricted by the United States government cannot be uploaded to
-<tt>ftp-master</tt>; depending on the case they may still be uploaded to
-<file>non-US/non-free</file> (it's in non-free because of distribution issues
-and not because of the license of the software). If you can't upload it to
-<tt>ftp-master</tt>, then neither can you upload it to backup
-queues that finally also end up on <tt>ftp-master</tt>. If you are not sure
-whether U.S. patent controls or cryptographic controls apply to your
-package, post a message to &email-debian-devel; and ask.
- <p>
You may also find the Debian packages <ref id="dupload"> or
<ref id="dput"> useful
when uploading packages. These handy programs help automate the
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>
-<em>Note:</em> non-us is currently not processed any more.
- <p>
-As discussed above, export controlled software should not be uploaded
-to <tt>ftp-master</tt>. Instead, upload the package with anonymous FTP
-to <ftpsite>non-us.debian.org</ftpsite>, placing the files in
-&upload-queue; (again, both <ref id="dupload"> and <ref
-id="dput"> can do this for you if invoked properly).
- <p>
-Note that U.S. residents or citizens are subject to restrictions on
-export of cryptographic software. As of this writing, U.S. citizens
-are allowed to export some cryptographic software, subject to
-notification rules by the U.S. Department of Commerce. However, this
-restriction has been waived for software which is already available
-outside the U.S. Therefore, any cryptographic software which belongs
-in the <em>main</em> section of the Debian archive and does not depend
-on any package outside of <em>main</em> (e.g., does not depend on
-anything in <em>non-US/main</em>) can be uploaded to <tt>ftp-master</tt>
-or its queues, described above.
- <p>
-Debian policy does not prevent upload to non-US by U.S. residents or
-citizens, but care should be taken in doing so. It is recommended that
-developers take all necessary steps to ensure that they are not
-breaking current US law by doing an upload to non-US, <em>including
-consulting a lawyer</em>.
- <p>
-For packages in <em>non-US/main</em>, <em>non-US/contrib</em>,
-developers should at least follow the <url id="&url-u.s.-export;"
-name="procedure outlined by the US Government">. Maintainers of
-<em>non-US/non-free</em> packages should further consult the <url
-id="&url-notification-of-export;" name="rules on notification of
-export"> of non-free software.
- <p>
-This section is for information only and does not constitute legal
-advice. Again, it is strongly recommended that U.S. citizens and
-residents consult a lawyer before doing uploads to non-US.
-
-
<sect1 id="delayed-incoming">Delayed uploads
<p>
Delayed uploads are done for the moment via the delayed queue at
gluck. The upload-directory is
<ftpsite>gluck:~tfheen/DELAYED/[012345678]-day</ftpsite>.
-0-day is uploaded approximately one hour before dinstall runs.
+0-day is uploaded multiple times per day to ftp-master.
<p>
With a fairly recent dput, this section
<example>
<sect1>Security uploads
<p>
-Do NOT upload a package to the security upload queue (oldstable-security,
+Do <strong>NOT</strong> upload a package to the security upload queue
+(oldstable-security,
stable-security, etc.) without prior authorization from the security
team. If the package does not exactly meet the team's requirements, it
will cause many problems and delays in dealing with the unwanted upload.
<sect1>Other upload queues
<p>
-The scp queues on ftp-master, non-us, and security are mostly unusable
+The scp queues on ftp-master, and security are mostly unusable
due to the login restrictions on those hosts.
<p>
The anonymous queues on ftp.uni-erlangen.de and ftp.uk.debian.org are
-currently down. Work is underway to resurrect those.
+currently down. Work is underway to resurrect them.
<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
<em>override file</em>.
<p>
To alter the actual section that a package is put in, you need to
-first make sure that the <file>debian/control</file> in your package
+first make sure that the <file>debian/control</file> file in your package
is accurate. Next, send an email &email-override; or submit a bug
against <package>ftp.debian.org</package> requesting that the section
or priority for your package be changed from the old section or
priority to the new one. Be sure to explain your reasoning.
<p>
For more information about <em>override files</em>, see <manref
-name="dpkg-scanpackages" section="8"> and
+name="dpkg-scanpackages" section="1"> and
<url id="&url-bts-devel;#maintincorrect">.
<p>
Note that the <tt>Section</tt> field describes both the section as
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
+All of the commands available on this server are described in the
<url id="&url-bts-control;" name="BTS control server documentation">.
<sect1 id="bug-monitoring">Monitoring bugs
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
+If you get a bug which mentions "FTBFS", this 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
require a decision of the technical committee by reassigning the bug
to <package>tech-ctte</package> (you may use the clone command of
the BTS if you wish to keep it reported against your package). Before
-doing so, please read the <url id="&url-tech-ctte;" name="recommended procedure">.
+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 to the right package. If you don't know which package it should
be reassigned to, you should ask for help on
<qref id="irc-channels">IRC</qref> or on &email-debian-devel;.
+Please make sure that the maintainer(s) of the package
+the bug is reassigned to
+know why you reassigned it.
<p>
Sometimes you also have to adjust the severity of the bug so that it
matches our definition of the severity. That's because people tend to
Some bugs may even be dropped to wishlist severity when the requested
change is just cosmetic.
<item>
+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
+case you have to ask them for 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
Forwarding a bug is not enough, you have to check at each release if
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 to the BTS and to
+you can prepare a patch that fixes the bug and
+send it to the author at the same time.
+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
<sect1 id="upload-bugfix">When bugs are closed by new uploads
<p>
-As bugs and problems are fixed your packages, it is your
-responsibility as the package maintainer to close the bug. However,
-you should not close the bug until the package which fixes the bug has
+As bugs and problems are fixed in your packages, it is your
+responsibility as the package maintainer to close these bugs. However,
+you should not close a bug until the package which fixes the bug has
been accepted into the Debian archive. Therefore, once you get
notification that your updated package has been installed into the
archive, you can and should close the bug in the BTS.
+Also, the bug should be closed with the correct version.
<p>
However, it's possible to avoid having to manually close bugs after the
upload — just list the fixed bugs in your <file>debian/changelog</file>
We prefer the <tt>closes: #<var>XXX</var></tt> syntax, as it is the
most concise entry and the easiest to integrate with the text of the
<file>changelog</file>.
- <p>
-If an upload is identified as <ref id="nmu" name="Non-maintainer upload (NMU)">
-(and that is the case if the name of the person who commits this change
-is not exactly the same as any one of Maintainer or Uploader,
-except if the maintainer is the qa group),
-than the bug is only tagged <tt>fixed</tt> instead of being closed.
-If a maintainer upload is targetted to experimental,
-than the tag <tt>fixed-in-experimental</tt> is added to the bug;
-for NMUs, the tag <tt>fixed</tt> is used.
-(The special rule for experimental is expected to change
-as soon as version-tracking is added to the bug tracking system.)
+Unless specified different by the <var>-v</var>-switch to
+<prgn>dpkg-buildpackage</prgn>, only the bugs closed in the
+most recent changelog entry are closed (basically, exactly
+the bugs mentioned in the changelog-part
+in the <file>.changes</file> file are closed).
+ <p>
+Historically, uploads identified as
+<qref id="nmu">Non-maintainer upload (NMU)</qref>
+were tagged <tt>fixed</tt> instead of being closed,
+but that practice was ceased with the advent of version-tracking.
+The same applied to the tag <tt>fixed-in-experimental</tt>.
<p>
If you happen to mistype a bug number or forget a bug in the changelog
entries, don't hesitate to undo any damage the error caused. To reopen
-wrongly closed bugs, send an <tt>reopen <var>XXX</var></tt> command to
+wrongly closed bugs, send a <tt>reopen <var>XXX</var></tt> command to
the bug tracking system's control address, &email-bts-control;. To
close any remaining bugs that were fixed by your upload, email the
<file>.changes</file> file to <email>XXX-done@&bugs-host;</email>,
-where <var>XXX</var> is your bug number.
+where <var>XXX</var> is the bug number, and
+put "Version: YYY" and an empty line as the first two lines
+of the body of the email,
+where <var>YYY</var> is the first version
+where the bug has been fixed.
+
<p>
Bear in mind that it is not obligatory to close bugs using the
changelog as described above. If you simply want to close bugs that
Due to their sensitive nature, security-related bugs must be handled
carefully. The Debian Security Team exists to coordinate this
activity, keeping track of outstanding security problems, helping
-maintainers with security problems or fix them themselves, sending
+maintainers with security problems or fixing them themselves, sending
security advisories, and maintaining security.debian.org.
<!-- information about the security database goes here once it's ready -->
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; as soon as possible. <strong>DO NOT UPLOAD</strong> any
-packages for stable; the security team will do that.
+&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>
- <item>What versions of the package are known to be affected by the
+ <item>Which versions of the package are known to be affected by the
bug. Check each version that is present in a supported Debian
release, as well as testing and unstable.
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 several 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 them via private email
</list>
<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
+ in contact with the various organizations and individuals and can take
care of that.
</list>
<list>
<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
+ <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 or <tt>stable</tt>!
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.
+ 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
--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.
+ 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.
<item>Do not make source-only uploads if your package has any
binary-all packages (do not use the <tt>-S</tt> option to
- <prgn>dpkg-buildpackage</prgn>). The <prgn>buildd</prgn> infrastructure will
- not build those. This point applies to normal package uploads as
- well.
+ <prgn>dpkg-buildpackage</prgn>). The <prgn>buildd</prgn>
+ infrastructure will not build those. This point applies to normal
+ package uploads as well.
<item>Unless the upstream source has been uploaded to
security.debian.org before (by a previous security update), build
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 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>Build the package on a clean
system which only has packages installed from the distribution you
approved by the security team, it needs to be uploaded so that it can
be installed in the archives. For security uploads, the place to
upload to is
-<tt>ftp://security.debian.org/pub/SecurityUploadQueue/</tt> .
+<tt>ftp://security-master.debian.org/pub/SecurityUploadQueue/</tt> .
<p>
Once an upload to the security queue has been accepted, the package
<p>
If a member of the security team accepts a package, it will be
-installed on security.debian.org as well as the proper
-<var>distribution</var>-proposed-updates on ftp-master or in the non-US
-archive.
+installed on security.debian.org as well as proposed for the proper
+<var>distribution</var>-proposed-updates on ftp-master.
<sect id="archive-manip">
<heading>Moving, removing, renaming, adopting, and orphaning
<p>
Some archive manipulation operations are not automated in the Debian
upload process. These procedures should be manually followed by
-maintainers. This chapter gives guidelines in what to do in these
+maintainers. This chapter gives guidelines on what to do in these
cases.
<sect1 id="moving-pkgs">Moving packages
If you need to change the section for one of your packages, change the
package control information to place the package in the desired
section, and re-upload the package (see the <url id="&url-debian-policy;"
-name="Debian Policy Manual"> for details). If your new section is
-valid, it will be moved automatically. If it does not, then contact
-the ftpmasters in order to understand what happened.
+name="Debian Policy Manual"> for details).
+You must ensure that you include the <file>.orig.tar.gz</file> in your upload
+(even if you are not uploading a new upstream version),
+or it will not appear in the new section together with the rest of the
+package. If your new section is valid, it will be moved automatically. If
+it does not, then contact the ftpmasters in order to understand what
+happened.
<p>
If, on the other hand, you need to change the <em>subsection</em> of
one of your packages (e.g., ``devel'', ``admin''), the procedure is
If for some reason you want to completely remove a package (say, if it
is an old compatibility library which is no longer required), you
need to file a bug against <tt>ftp.debian.org</tt> asking that the
-package be removed. Make sure you indicate which distribution the
+package be removed;
+as all bugs, this bug should normally have normal severity.
+Make sure you indicate which distribution the
package should be removed from. Normally, you can only have packages
removed from <em>unstable</em> and <em>experimental</em>. Packages
are not removed from <em>testing</em> directly. Rather, they will be
removed automatically after the package has been removed from
<em>unstable</em> and no package in <em>testing</em> depends on it.
<p>
-You also have to detail the reasons justifying that request. This is to
+There is one exception when an explicit removal request is not necessary:
+If a (source or binary) package is an orphan, it will be removed
+semi-automatically.
+For a binary-package, this means if there is no longer any source package
+producing this binary package;
+if the binary package is just no longer produced on some architectures,
+a removal request is still necessary.
+For a source-package, this means that all binary packages it refers to
+have been taken over by another source package.
+ <p>
+In your removal request, you have to detail the reasons justifying the
+request. This is to
avoid unwanted removals and to keep a trace of why a package has been
removed. For example, you can provide the name of the package that
supersedes the one to be removed.
If you want to remove another package, you have to get the approval
of its maintainer.
<p>
+Further information relating to these and other package removal related
+topics may be found at <url
+id="http://wiki.debian.org/ftpmaster_Removals"> and <url
+id="http://qa.debian.org/howto-remove.html">.
+ <p>
If in doubt concerning whether a package is disposable, email
&email-debian-devel; asking for opinions. Also of interest is the
<prgn>apt-cache</prgn> program from the <package>apt</package>
package. When invoked as <tt>apt-cache showpkg
<var>package</var></tt>, the program will show details for
<var>package</var>, including reverse depends.
+Other useful programs include
+<tt>apt-cache rdepends</tt>,
+<prgn>apt-rdepends</prgn> and
+<prgn>grep-dctrl</prgn>.
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
the actual code has evolved into another package (e.g. <tt>libfoo12</tt>
was removed because <tt>libfoo13</tt> supersedes it) or closed if the
-software is simply no more part of Debian.
+software is simply no longer part of Debian.
<sect2>Removing packages from <file>Incoming</file>
<p>
<sect1 id="orphaning">Orphaning a package
<p>
-If you can no longer maintain a package, you need to inform the others
-about that, and see that the package is marked as orphaned.
+If you can no longer maintain a package, you need to inform others,
+and see that the package is marked as orphaned.
You should set the package maintainer to <tt>Debian QA Group
&orphan-address;</tt> and submit a bug report
against the pseudo package <package>wnpp</package>. The bug report should be
<p>
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>.
+a bug against <package>wnpp</package> and title it <tt>RFA:
+<var>package</var> -- <var>short description</var></tt>.
<tt>RFA</tt> stands for <em>Request For Adoption</em>.
<p>
More information is on the <url id="&url-wnpp;" name="WNPP web pages">.
<sect1 id="adopting">Adopting a package
<p>
-A list of packages in need of a new maintainer is available at in the
+A list of packages in need of a new maintainer is available in the
<url name="Work-Needing and Prospective Packages list (WNPP)"
id="&url-wnpp;">. If you wish to take over maintenance of any of the
packages listed in the WNPP, please take a look at the aforementioned
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>.
+it signed conveniently, or use the remote signing mode of
+<prgn>dpkg-sig</prgn>.
<sect2 id="binary-only-nmu">
get this wrong, the archive maintainers will reject your upload (due
to lack of corresponding source code).
<p>
-The ``magic'' for a recompilation-only NMU is triggered by using the
-third-level number on the Debian part of the version. For instance,
-if the latest version you are recompiling against was version
-``2.9-3'', your NMU should carry a version of ``2.9-3.0.1''. If the
-latest version was ``3.4-2.1'', your NMU should have a version number
-of ``3.4-2.1.1''.
+The ``magic'' for a recompilation-only NMU is triggered by using a
+suffix appended to the package version number,
+following the form b<number>.
+For instance, if the latest version you are
+recompiling against was version ``2.9-3'', your NMU should carry a
+version of ``2.9-3+b1''. If the latest version was ``3.4+b1'' (i.e, a
+native package with a previous recompilation NMU), your NMU should have
+a version number of ``3.4+b2''.
+
+<footnote>
+In the past, such NMUs used the third-level number on the Debian part of
+the revision to denote their recompilation-only status; however, this
+syntax was ambiguous with native packages and did not allow proper
+ordering of recompile-only NMUs, source NMUs, and security NMUs on the
+same package, and has therefore been abandoned in favor of this new
+syntax.</footnote>
<p>
Similar to initial porter uploads, the correct way of invoking
<prgn>dpkg-buildpackage</prgn> is <tt>dpkg-buildpackage -B</tt> to only
<sect1 id="porter-automation">
<heading>Porting infrastructure and automation</heading>
<p>
-There is infrastructure and several tools to help automate the package
+There is infrastructure and several tools to help automate package
porting. This section contains a brief overview of this automation and
porting to these tools; see the package documentation or references for
full information.</p>
most porting efforts are either using it currently or planning to use
it in the near future. The actual automated builder is packaged as
<package>sbuild</package>, see its description in <ref id="sbuild">.
-The complete <package>buildd</package> system also collects a number of as yet unpackaged
-components which are currently very useful and in use continually,
-such as <prgn>andrea</prgn> and
-<prgn>wanna-build</prgn>.
+The complete <package>buildd</package> system also collects a number of as
+yet unpackaged components which are currently very useful and in use
+continually, such as <prgn>andrea</prgn> and <prgn>wanna-build</prgn>.
<p>
Some of the data produced by <package>buildd</package> which is
generally useful to porters is available on the web at <url
We are quite proud of this system, since it has so
many possible uses. Independent development groups can use the system for
different sub-flavors of Debian, which may or may not really be of
-general interest (for instance, a flavor of Debian built with <prgn>gcc</prgn>
-bounds checking). It will also enable Debian to recompile entire
-distributions quickly.
- </sect2>
+general interest (for instance, a flavor of Debian built with
+<prgn>gcc</prgn> bounds checking). It will also enable Debian to
+recompile entire distributions quickly.
+ <p>
+The buildds admins of each arch can be contacted at the mail address
+$arch@buildd.debian.org.
+
+ <sect1 id="packages-arch-specific">When your package is <em>not</em> portable
+ <p>
+Some packages still have issues with building and/or working on some
+of the architectures supported by Debian, and cannot be ported at all,
+or not within a reasonable amount of time. An example is a package that
+is SVGA-specific (only i386), or uses other hardware-specific features
+not supported on all architectures.
+ <p>
+In order to prevent broken packages from being uploaded to the archive, and
+wasting buildd time, you need to do a few things:
+ <p>
+ <list>
+ <item>
+ <p>
+First, make sure your package <em>does</em> fail to build on
+architectures that it cannot support.
+There are a few ways to achieve this.
+The preferred way is to have a small testsuite during build time
+that will test the functionality, and fail if it doesn't work.
+This is a good idea anyway,
+as this will prevent (some) broken uploads on all architectures,
+and also will allow the package to build
+as soon as the required functionality is available.
+ <p>
+Additionally, if you believe the list of supported architectures is
+pretty constant, you should change 'any' to a list of supported
+architectures in debian/control. This way, the build will fail also,
+and indicate this to a human reader without actually trying.
+ <item>
+ <p>
+In order to prevent autobuilders from needlessly trying to build your
+package, it must be included in <file>packages-arch-specific</file>, a
+list used by the <prgn>wanna-build</prgn> script.
+The current version is available as
+<url id="http://cvs.debian.org/srcdep/Packages-arch-specific?cvsroot=dak">;
+please see the top of the file for whom to contact for changes.
+ </list>
+ <p>
+Please note that it is insufficient to only add your package to
+Packages-arch-specific
+without making it fail to build on unsupported architectures:
+A porter or any other person trying to build your package might
+accidently upload it without noticing it doesn't work.
+If in the past some binary packages were uploaded on unsupported
+architectures, request their removal by filing a bug against
+<package>ftp.debian.org</package>
<sect id="nmu">Non-Maintainer Uploads (NMUs)
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
+developer needs to fix another developer's package in order to
address serious problems or crippling bugs
or when the package maintainer is unable to release a fix
in a timely fashion.
However, aesthetic changes must <em>not</em> be made in a non-maintainer
upload.
<p>
-And please remember the Hippocratic Oath: "Above all, do no harm."
-It is better if a package has an grave bug open, than if a not working
-patch was applied, and the bug is only hidden now but not resolved.
+And please remember the Hippocratic Oath: "Above all, do no harm." It
+is better to leave a package with an open grave bug than applying a
+non-functional patch, or one that hides the bug instead of resolving
+it.
<sect1 id="nmu-guidelines">How to do a NMU
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.
+solution.
<p>
NMUs should be made to assist a package's maintainer in resolving bugs.
Maintainers should be thankful for that help, and NMUers should respect
for a package to enter testing is through unstable.
<p>
For the stable distribution, please take extra care. Of course, the release
-managers may also change the rules here. Please verify before upload that
+managers may also change the rules here. Please verify before you upload that
all your changes are OK for inclusion into the next stable release by the
release manager.
<p>
package in the archive was not made by the official maintainer.
<p>
If there is no <var>debian-revision</var> component in the version
-number then one should be created, starting at `0.1'. If it is
+number then one should be created, starting at `0.1' (but in case
+of a debian native package still upload it as native package).
+If it is
absolutely necessary for someone other than the usual maintainer to
make a release based on a new upstream version then the person making
the release should start with the <var>debian-revision</var> value
<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,
+Anyone who is doing a source NMU must create a changelog entry,
describing which bugs are fixed by the NMU, and generally why the NMU
was required and what it fixed. The changelog entry will have the
-non-maintainer's email address in the log entry and the NMU version
-number in it.
+email address of the person who uploaded it in the log entry
+and the NMU version number in it.
<p>
By convention, source NMU changelog entries start with the line
<example>
architectures, then you do a source NMU as usual and you will have to
send a patch.
<p>
-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 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:
-bug#<var>nnnnn</var></tt> syntax (see <ref id="upload-bugfix"> for
-more information describing how to close bugs via the changelog).
-Tagging the bugs <em>fixed</em> ensures that everyone knows that the
-bug was fixed in an NMU; however the bug is left open until the
-changes in the NMU are incorporated officially into the package by
-the official package maintainer.
+Bugs fixed by source NMUs used to be tagged fixed instead of closed,
+but since version tracking is in place, such bugs are now also
+closed with the NMU version.
<p>
Also, after doing an NMU, you have to send
-that information to the existing bugs that are fixed by your NMU,
+the 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
+Historically, it was custom to 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
really fixes each problem that was fixed in the non-maintainer release.
<p>
In addition, the normal maintainer should <em>always</em> retain the
-entry in the changelog file documenting the non-maintainer upload.
+entry in the changelog file documenting the non-maintainer upload --
+and of course, also keep the changes.
+If you revert some of the changes,
+please reopen the relevant bug reports.
<sect1 id="nmu-build">Building source NMUs
<p>
Source NMU packages are built normally. Pick a distribution using the
same rules as found in <ref id="distribution">, follow the other
-prescriptions in <ref id="upload">.
+instructions in <ref id="upload">.
<p>
Make sure you do <em>not</em> change the value of the maintainer in
the <file>debian/control</file> file. Your name as given in the NMU entry of
have to close the bugs that have been tagged fixed by the NMU. The easiest
way is to use the <tt>-v</tt> option of <prgn>dpkg-buildpackage</prgn>,
as this allows you to include just all changes since your last maintainer
-upload. Alternativly, you
+upload. Alternatively, you
can close them manually by sending the required mails to the
BTS or by adding the required <tt>closes: #nnnn</tt> in the changelog
entry of your next upload.
<p>
In any case, you should not be upset by the NMU. An NMU is not a
personal attack against the maintainer. It is a proof that
-someone cares enough about the package and that they were willing to help
+someone cares enough about the package 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 in helping you on a more frequent
basis as co-maintainer or backup maintainer
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.
+<packages@qa.debian.org>''.
<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
+Only official, registered Debian Developers can do binary or source
+NMUs. A Debian Developer 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
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
+Both classes of NMUs, source and binary-only, can be lumped under 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
"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
+faster bug fix turnaround times. 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>
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>
+<prgn>Subversion</prgn>. Alioth (see <ref id="alioth">) provides such
+tools, amongst others.</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">).
+ <p>
+Another form of collaborative maintenance is team maintenance, which is
+recommended if you maintain several packages with the same group of
+developers. In that case, the Maintainer and Uploaders field of each
+package must be managed with care. It is recommended to choose between
+one of the two following schemes:
+ <enumlist>
+ <item>
+ <p>
+Put the team member mainly responsible for the package in the Maintainer
+field. In the Uploaders, put the mailing list address, and the team members
+who care for the package.
+ </item>
+ <item>
+ <p>
+Put the mailing list address in the Maintainer field. In the Uploaders
+field, put the team members who care for the package.
+In this case, you must make sure the mailing list accept bug reports
+without any human interaction (like moderation for non-subscribers).
+ </item>
+ </enumlist>
+ <p>
+In any case, it is a bad idea to automatically put all team members in
+the Uploaders field. It clutters the Developer's Package Overview listing
+(see <ref id="ddpo">) with packages one doesn't really care for, and
+creates a false sense of good maintenance.
</sect>
<sect id="testing">
<heading>Updates from unstable</heading>
<p>
The scripts that update the <em>testing</em> distribution are run each
-day after the installation of the updated packages. They generate the
+day after the installation of the updated packages;
+these scripts are called <em>britney</em>.
+They generate the
<file>Packages</file> files for the <em>testing</em> distribution, but
they do so in an intelligent manner; they try to avoid any inconsistency
and to use only non-buggy packages.
Those delays may be doubled during a freeze, or testing transitions may be
switched off altogether;
<item>
-It must have fewer release-critical bugs than the version currently available
-in <em>testing</em>;
+It must have the same number or fewer release-critical bugs than the
+version currently available in <em>testing</em>;
<item>
It must be available on all architectures on which it has previously
been built in unstable. <ref id="madison"> may be of interest to
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);
+or they must be accepted into <em>testing</em> at the same time (and they
+will be if they fulfill all the necessary criteria);
</list>
<p>
To find out whether a package is progressing into testing or not, see the
<sect2 id="outdated">
<heading>out-of-date</heading>
<p>
-<!-- FIXME: better rename this file than document rampant professionalism? -->
+<!-- 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
<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.
+sense. Suppose e.g. that <em>a</em> cannot be installed with the new
+version of <em>b</em>; then <em>a</em> may be removed to allow <em>b</em>
+in.
<p>
Of course, there is another reason to remove a package from testing: It's
just too buggy (and having a single RC-bug is enough to be in this state).
+ <p>
+Furthermore, if a package has been removed from unstable,
+and no package in testing depends on it any more,
+then it will automatically be removed.
+
<sect2 id="circular">
<heading>circular dependencies</heading>
<p>
-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.
+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>
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
+date on some arches. For this part of britney,
+the release managers have hammers
+of various sizes 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
+larger sets of packages together. Each try is accepted if testing is not
more uninstallable after the update than before. (Before and after this part,
some hints are processed; but as only release masters can hint, this is
probably not so important for you.)
<sect1 id="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>.
+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;.
+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.
+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
<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.
+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".
+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;
+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.
+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>
+ <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.
+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.
+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.
+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.
+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.
+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">
<sect1 id="helper-scripts">Helper scripts
<p>
The rationale for using helper scripts in <file>debian/rules</file> is
-that lets maintainers use and share common logic among many packages.
+that they let maintainers use and share common logic among many packages.
Take for instance the question of installing menu entries: you need to
-put the file into <file>/usr/lib/menu</file>, and add commands to the
-maintainer scripts to register and unregister the menu entries. Since
-this is a very common thing for packages to do, why should each
-maintainer rewrite all this on their own, sometimes with bugs? Also,
-supposing the menu directory changed, every package would have to be
-changed.
+put the file into <file>/usr/lib/menu</file> (or
+<file>/usr/lib/menu</file> for executable binary menufiles, if this is
+needed), and add commands to the maintainer scripts to register and
+unregister the menu entries. Since this is a very common thing for
+packages to do, why should each maintainer rewrite all this on their own,
+sometimes with bugs? Also, supposing the menu directory changed, every
+package would have to be changed.
<p>
Helper scripts take care of these issues. Assuming you comply with
the conventions expected by the helper script, the helper takes care
patches. See the package <package>dbs</package> for more information and
<package>hello-dbs</package> for an example.
<p>
-<prgn>dpatch</prgn> also provides these facilities, but it's intented to be
+<prgn>dpatch</prgn> also provides these facilities, but it's intended to be
even easier to use. See the package <package>dpatch</package> for
documentation and examples (in <file>/usr/share/doc/dpatch</file>).
A single source package will often build several binary packages,
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).
+packages instead of a big one (e.g., so the user can install only the
+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
<p>
The first case is a bit more difficult since it involves multiple
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.
+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
cycles -->
the package manager (e.g., "this is the client for the foo server")?
<p>
Be careful to avoid spelling and grammar mistakes. Ensure that you
-spell-check it. <prgn>ispell</prgn> has a special <tt>-g</tt> option
-for <file>debian/control</file> files:
+spell-check it. Both <prgn>ispell</prgn> and <prgn>aspell</prgn>
+have special modes for checking <file>debian/control</file> files:
<example>ispell -d american -g debian/control</example>
+<example>aspell -d en -D -c debian/control</example>
<p>
Users usually expect these questions to be answered in the package
description:
<file>debian/control</file> field understood by <prgn>dpkg</prgn> and
<tt>&packages-host;</tt>. If you don't want to bother migrating the
home page from the description to this field, you should probably wait
-until that is available.</p>
+until that is available.
+ Please make sure that this line matches the regular expression
+ <tt>/^ Homepage: [^ ]*$/</tt>,
+ as this allows <file>packages.debian.org</file> to parse it correctly.</p>
+ </sect1>
+
+ <sect1 id="bpp-vcs">
+ <heading>Version Control System location</heading>
+ <p>
+There are additional fields for the location of the Version Control System
+in <file>debian/control</file>.
+ <sect2><heading>XS-Vcs-Browser</heading>
+ <p>
+Value of this field should be a <tt>http://</tt> URL pointing to a
+web-browsable copy of the Version Control System repository used to
+maintain the given package, if available.
+ <p>
+The information is meant to be useful for the final user, willing to
+browse the latest work done on the package (e.g. when looking for the
+patch fixing a bug tagged as <tt>pending</tt> in the bug tracking
+system).
+ <sect2><heading>XS-Vcs-*</heading>
+ <p>
+Value of this field should be a string identifying unequivocally the
+location of the Version Control System repository used to maintain the
+given package, if available. <tt>*</tt> identify the Version Control
+System; currently the following systems are supported by the package
+tracking system: <tt>arch</tt>, <tt>bzr</tt> (Bazaar), <tt>cvs</tt>,
+<tt>darcs</tt>, <tt>git</tt>, <tt>hg</tt> (Mercurial), <tt>mtn</tt>
+(Monotone), <tt>svn</tt> (Subversion). It is allowed to specify different
+VCS fields for the same package: they will all be shown in the PTS web
+interface.
+ <p>
+The information is meant to be useful for a user knowledgeable in the
+given Version Control System and willing to build the current version of
+a package from the VCS sources. Other uses of this information might
+include automatic building of the latest VCS version of the given
+package. To this end the location pointed to by the field should better
+be version agnostic and point to the main branch (for VCSs supporting
+such a concept). Also, the location pointed to should be accessible to
+the final user; fulfilling this requirement might imply pointing to an
+anonymous access of the repository instead of pointing to an
+SSH-accessible version of the same.
+ <p>
+In the following example, an instance of the field for a Subversion
+repository of the <package>vim</package> package is shown. Note how the
+URL is in the <tt>svn://</tt> scheme (instead of <tt>svn+ssh://</tt>) and
+how it points to the <file>trunk/</file> branch. The use of the
+<tt>XS-Vcs-Browser</tt> field described above is also shown.
+<example>
+ Source: vim
+ Section: editors
+ Priority: optional
+ <snip>
+ XS-Vcs-Svn: svn://svn.debian.org/svn/pkg-vim/trunk/packages/vim
+ XS-Vcs-Browser: http://svn.debian.org/wsvn/pkg-vim/trunk/packages/vim
+</example>
</sect1>
</sect>
tracking system.
<p>
It is an old tradition to acknowledge bugs fixed in non-maintainer
-uploads in the first changelog entry of the proper maintainer upload,
-for instance, in a changelog entry like this:
-<example>
- * Maintainer upload, closes: #42345, #44484, #42444.
-</example>
-This will close the NMU bugs tagged "fixed" when the package makes
-it into the archive. The bug for the fact that an NMU was done can be
-closed the same way. Of course, it's also perfectly acceptable to
-close NMU-fixed bugs by other means; see <ref id="bug-answering">.
+uploads in the first changelog entry of the proper maintainer upload.
+As we have version tracking now,
+it is enough to keep the NMUed changelog entries and
+just mention this fact in your own changelog entry.
</sect1>
<sect1 id="bpp-changelog-errors">
<heading>Common errors in changelog entries</heading>
<p>
-The following examples demonstrate some common errors or example of
+The following examples demonstrate some common errors or examples of
bad style in changelog entries.
<p>
<p>
These guidelines include some writing style and typography
recommendations, general considerations about debconf usage as well as
-more specific recommendations for some parts of the distribution (for
-instance, the installation system).
+more specific recommendations for some parts of the distribution (the
+installation system for instance).
<sect1>Do not abuse debconf
<p>
Most Debian package maintainers are not native English speakers. So,
writing properly phrased templates may not be easy for them.
<p>
-Please use (and abuse) debian-l10n-english@lists.debian.org mailing
+Please use (and abuse) &email-debian-l10n-english; mailing
list. Have your templates proofread.
<p>
Badly written templates give a poor image of your package, of your
<sect2>Be kind to translators
<p>
Debconf templates may be translated. Debconf, along with its sister
-package po-debconf offers a simple framework for getting
+package <prgn>po-debconf</prgn> offers a simple framework for getting
templates translated by translation teams or even individuals.
<p>
-Please use gettext-based templates. Install po-debconf on your
-development system and read its documentation ("man po-debconf" is a
-good start).
+Please use gettext-based templates. Install <package>po-debconf</package>
+on your development system and read its documentation ("man po-debconf" is
+a good start).
<p>
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
+translators. Most active translators are very responsive 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>
+The use of the <prgn>podebconf-report-po</prgn> from the
+po-debconf package is highly recommended to warn translators which
+have incomplete translations and request them for updates.
+ <p>
If in doubt, you may also contact the translation team for a given
language (debian-l10n-xxxxx@lists.debian.org), or the
-debian-i18n@lists.debian.org mailing list.
+&email-debian-i18n; mailing list.
+ <p>
+Calls for translations posted to
+&email-debian-i18n; with the <file>debian/po/templates.pot</file> file
+attached or referenced in a URL are encouraged. Be sure to mentions in
+these calls for new translations which languages you have existing
+translations for, in order to avoid duplicate work.
+ <sect2>Unfuzzy complete translations when correcting typos and spelling
+ <p>
+When the text of a debconf template is corrected and you are
+<strong>sure</strong> that the change does <strong>not</strong> affect
+translations, please be kind to translators and unfuzzy their
+translations.
+ <p>
+If you don't do so, the whole template will not be translated as long
+as a translator will send you an update.
+ <p>
+To <strong>unfuzzy</strong> translations, you can proceed the following way:
+ <enumlist>
+ <item>
+Put all incomplete PO files out of the way. You can check the
+completeness by using (needs the <package>gettext</package> package
+installed):
+<example>for i in debian/po/*po; do echo -n $i: ; msgfmt -o /dev/null
+--statistics $i; done</example>
+ <item>
+move all files which report either fuzzy strings to a temporary
+place. Files which report no fuzzy strings (only translated and
+untranslated) will be kept in place.
+ <item>
+now <strong>and now only</strong>, modify the template for the typos
+and check again that translation are not impacted (typos, spelling
+errors, sometimes typographical corrections are usually OK)
+ <item>
+run <prgn>debconf-updatepo</prgn>. This will fuzzy all strings
+you modified in translations. You can see this by running the above
+again
+ <item>
+use the following command:
+<example>for i in debian/po/*po; do msgattrib --output-file=$i --clear-fuzzy $i; done</example>
+ <item>
+move back to debian/po the files which showed fuzzy strings in the first step
+ <item>
+run <prgn>debconf-updatepo</prgn> again
+ </enumlist>
<sect2>Do not make assumptions about interfaces
<p>
Templates text should not make reference to widgets belonging to some
meaning for users of graphical interfaces which use checkboxes for
boolean questions.
<p>
+String templates should also avoid mentioning the default values in
+their description. First, because this is redundant with the values
+seen by the users. Also, because these default values may be different
+from the maintainer choices (for instance, when the debconf database
+was preseeded).
+ <p>
More generally speaking, try to avoid referring to user actions.
Just give facts.
<sect2>Do not use first person
<p>
You should avoid the use of first person ("I will do this..." or "We
-recommend..."). The computer is not a person and the Debconf tempaltes
+recommend..."). The computer is not a person and the Debconf templates
do not speak for the Debian developers. You should use neutral
-construction and often the passive form. Those of you who already
+construction. Those of you who already
wrote scientific publications, just write your templates like you
would write a scientific paper.
+However, try using action voice if still possible, like
+"Enable this if ..."
+instead of
+"This can be enabled if ...".
<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.
+constructions in your writing.
<sect1>Templates fields definition
<sect3>boolean:
<p>
-A true/false choice. Remember: true/false, NOT YES/NO...
+A true/false choice. Remember: true/false, <strong>not yes/no</strong>...
<sect3>select:
<p>
<sect3>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
+This type is designed to handle error messages. 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).
+ <p>
+It is recommended to use this type for any message that needs user
+attention for a correction of any kind.
<sect2>Description: short and extended description
<p>
-Templates descriptions have two parts: short and extended. The short
+Template descriptions have two parts: short and extended. The short
description is in the "Description:" line of the template.
<p>
The short description should be kept short (50 characters or so) so
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.
+Don't be too verbose. User tend to ignore too long screens.
+20 lines are by experience a border you shouldn't cross,
+because that means that in the classical dialog interface,
+people will need to scroll, and lot of people just don't do that.
+ <p>
+The extended description should <strong>never</strong> include a question.
<p>
For specific rules depending on templates type (string, boolean,
etc.), please read below.
<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 short description is a prompt and <strong>not</strong> a title.
+ Avoid question style prompts ("IP Address?") in favour of "opened"
+ prompts ("IP address:"). The use of colons is recommended.
<item> The extended description is a complement to the short description.
In the extended part, explain what is being asked, rather than ask
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.
<sect3>Select/Multiselect
<p>
<list>
-<item> The short description is a prompt and NOT a title. Do NOT use useless
+<item> The short description is a prompt and <strong>not</strong> a title.
+ Do <strong>not</strong> use useless
"Please choose..." constructions. Users are clever enough to figure
out they have to choose something...:)
<item> The extended description is what will be displayed as a more detailed
explanation of the note. Phrases, no terse writing style.
-<item> DO NOT ABUSE DEBCONF. Notes are the most common way to abuse
+<item> <strong>Do not abuse debconf.</strong>
+ Notes are the most common way to abuse
debconf. As written in debconf-devel manual page: it's best to use them
only for warning about very serious problems. The NEWS.Debian or
README.Debian files are the appropriate location for a lot of notes.
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.
+ to entries in NEWS/Debian or README.Debian, plus consider keeping
+ existing translations for the future.
</list>
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.
+If you use po-debconf (and you <strong>should</strong>, see 2.2), consider
+making this field translatable, if you think it may be translated.
<p>
If the default value may vary depending on language/country (for
instance the default value for a language choice), consider using the
-special "_DefaultChoice" type documented in <manref name="po-debconf" section="7">).
+special "_DefaultChoice" type documented in <manref name="po-debconf"
+section="7">).
</sect>
<p>
Policy specifies that documentation should be shipped in HTML format.
We also recommend shipping documentation in PDF and plain text format if
-convenient and quality output is possible. However, it is generally
-not appropriate to ship plain text versions of documentation whose source
-format is HTML.</p>
+convenient and if output of reasonable quality is possible. However, it
+is generally not appropriate to ship plain text versions of documentation
+whose source format is HTML.</p>
<p>
Major shipped manuals should register themselves with
<package>doc-base</package> on installation. See the
<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.
+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.
+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 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="pristinesource">
+ <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 incrementing the version number, so
+there can be no guarantee that a pristine tarball is identical
+to what upstream <em>currently</em> distributing at any point in
+time. All that can be expected is that it is identical to
+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="repackagedorigtargz">
+ <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 the <file>debian/copyright</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.
+Note that you don't need to depend on <package>sharutils</package> to get
+the <prgn>uudecode</prgn> program if you use <prgn>perl</prgn>'s
+<tt>pack</tt> function.
+The code could look like
+<example>
+uuencode-file:
+ perl -ne 'print(pack "u", $$_);' $(file) > $(file).uuencoded
+
+uudecode-file:
+ perl -ne 'print(unpack "u", $$_);' $(file).uuencoded > $(file)
+</example>
+</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>
+ <sect1 id="bpp-dbg">
+ <heading>Best practices for debug packages</heading>
+ <p>
+A debug package is a package with a name ending in "-dbg", that contains
+additional information that gdb can use. Since Debian binaries are
+stripped by default, debugging information, including function names and
+line numbers, is otherwise not available when running gdb on Debian binaries.
+Debug packages allow users who need this additional debugging information to
+install it, without bloating a regular system with the information.
+ <p>
+It is up to a package's maintainer whether to create a debug package or
+not. Maintainers are encouraged to create debug packages for library
+packages, since this can aid in debugging many programs linked to a
+library. In general, debug packages do not need to be added for all
+programs; doing so would bloat the archive. But if a maintainer finds
+that users often need a debugging version of a program, it can be
+worthwhile to make a debug package for it. Programs that are core
+infrastructure, such as apache and the X server are also good candidates
+for debug packages.
+ <p>
+Some debug packages may contain an entire special debugging build of a
+library or other binary, but most of them can save space and build time
+by instead containing separated debugging symbols that gdb can find and
+load on the fly when debugging a program or library. The convention in
+Debian is to keep these symbols in <file>/usr/lib/debug/<em>path</em></file>,
+where <em>path</em> is the path to the executable or library. For example,
+debugging symbols for <file>/usr/bin/foo</file> go in
+<file>/usr/lib/debug/usr/bin/foo</file>, and
+debugging symbols for <file>/usr/lib/libfoo.so.1</file> go in
+<file>/usr/lib/debug/usr/lib/libfoo.so.1</file>.
+ <p>
+The debugging symbols can be extracted from an object file using
+"objcopy --only-keep-debug". Then the object file can be stripped, and
+"objcopy --add-gnu-debuglink" used to specify the path to the debugging
+symbol file. <manref name="objcopy" section="1"> explains in detail how this
+works.
+ <p>
+The dh_strip command in debhelper supports creating debug packages, and
+can take care of using objcopy to separate out the debugging symbols for
+you. If your package uses debhelper, all you need to do is call
+"dh_strip --dbg-package=libfoo-dbg", and add an entry to debian/control
+for the debug package.
+ <p>
+Note that the Debian package should depend on the package that it
+provides debugging symbols for, and this dependency should be versioned.
+For example:
+
+<example>
+Depends: libfoo-dbg (= ${binary:Version})
+</example>
+
+
</sect>
</chapt>
out all the bugs you submitted, you just have to visit
<tt>http://&bugs-host;/from:<var><your-email-addr></var></tt>.
- <sect1 id="submit-many-bugs">Reporting lots of bugs at once
+ <sect1 id="submit-many-bugs">Reporting lots of bugs at once (mass bug filing)
<p>
Reporting a great number of bugs for the same problem on a great
-number of different packages — i.e., more than 10 — is a deprecated
-practice. Take all possible steps to avoid submitting bulk bugs at
-all. For instance, if checking for the problem can be automated, add
-a new check to <package>lintian</package> so that an error or warning
+number of different packages — i.e., more than 10 — is a
+deprecated practice. Take all possible steps to avoid submitting bulk
+bugs at all. For instance, if checking for the problem can be automated,
+a
dd a new check to <package>lintian</package> so that an error or warning
is emitted.
<p>
If you report more than 10 bugs on the same topic at once, it is
recommended that you send a message to &email-debian-devel; describing
-your intention before submitting the report. This will allow other
+your intention before submitting the report, and mentioning the
+fact in the subject of your mail. This will allow other
developers to verify that the bug is a real problem. In addition, it
will help prevent a situation in which several maintainers start
filing the same bug report simultaneously.
<p>
+Please use the programms <prgn>dd-list</prgn> and
+if appropriate <prgn>whodepends</prgn>
+(from the package devscripts)
+to generate a list of all affected packages, and include the
+output in your mail to &email-debian-devel;.
+ <p>
Note that when sending lots of bugs on the same subject, you should
send the bug report to <email>maintonly@&bugs-host;</email> so
that the bug report is not forwarded to the bug distribution mailing
<sect1 id="qa-bsp">Bug squashing parties
<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 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 (like a new perl version
-which requires recompilation of all the binary modules).
+as many problems as possible. They are announced on
+&email-debian-devel-announce; 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
+(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 announcement of the party is considered prior notice for NMU. If
<p>
You may also be interested in contacting the persons who are
subscribed to a given source package via <ref id="pkg-tracking-system">.
-You can do so by using the <tt><package-name>@&pts-host;</tt>
+You can do so by using the <tt><package>@&pts-host;</tt>
email address.
<!-- FIXME: moo@packages.d.o is easily confused with moo@packages.qa.d.o -->
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
+maintainers who are deemed Missing In Action is 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,
+with a tool known as <prgn>mia-query</prgn>.
+Use <example>mia-query --help</example> to see how to query the database.
+If you find that no information has been recorded
+about an inactive maintainer yet, 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
+The first step is to politely contact the maintainer,
+and wait a reasonable time for a response.
+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 to send a reminder after two
weeks.
<list>
<item>The "echelon" information available through the
<url id="&url-debian-db;" name="developers' LDAP database">,
- which indicates when the developer last has posted to
+ which indicates when the developer last 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.
non-Debian mailing lists or news groups.
</list>
<p>
-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
-package, they're responsible for the upload anyhow, and should know what
-happened to the person they sponsored.
+A bit of a problem are packages which were sponsored — the
+maintainer is not an official Debian developer. The echelon information is
+not available for sponsored people, for example, so you need to find and
+contact the Debian developer who has actually uploaded the package. Given
+that they signed the package, they're responsible for the upload anyhow,
+and are likely to know what happened to the person they sponsored.
<p>
It is also allowed to post a query to &email-debian-devel;, asking if anyone
is aware of the whereabouts of the missing maintainer.
+Please Cc: the person in question.
<p>
-Once you have gathered all of this, you can contact &email-debian-qa;.
-People on this alias will use the information you provided in order to
+Once you have gathered all of this, you can contact &email-mia;.
+People on this alias will use the information you provide 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
-has done the NMU is interested in the package.
+packages of the maintainer. If a package has been NMUed, they might prefer
+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
-of the deceased and find a very impolite, angry and accusing message!)
+seriously ill or might even have 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
-not have the time or interest anymore, they should "let go" and give the
-package to someone with more time.
+So you can stress the importance of the greater good — if a
+maintainer does not have the time or interest anymore, they should "let
+go" and give the package to someone with more time.
+ <p>
+If you are interested in working in the MIA team, please have a look at the
+README file in /org/qa.debian.org/mia on qa.debian.org where the technical
+details and the MIA procedures are documented and contact &email-mia;.
<sect id="newmaint">
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.
-(Note that if the sponsored package is new, the ftpmasters will also have to
-inspect it before letting it in.)
+— 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. (Note that if the sponsored package is new, the ftpmasters will
+also have to inspect it before letting it in.)
<p>
Sponsoring merely by signing the upload or just recompiling is
<strong>definitely not recommended</strong>. You need to build the source
email before the package is in acceptable shape. Being a sponsor
means being a mentor.
<p>
-Once the package meets Debian standards, build and sign it with
-<example>dpkg-buildpackage -k<var>KEY-ID</var></example>
+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
-sponsoree. The sponsoree will therefore get all the BTS mail about the
+<file>changelog</file> should list the person who did the packaging, i.e.,
+the sponsoree. The sponsoree will therefore get all the BTS mail about the
package.
<p>
If you prefer to leave a more evident trace of your sponsorship job, you
<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.
+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."
+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.
+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.
+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
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">.
+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.
+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;
+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
+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.
+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.
+For general documentation about Debian, the process is more or less the
+same as 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.
+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.
+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
<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.
+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.
+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.
+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.
+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>
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.
+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
<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).
+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>
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.
+The best solution is to file a regular bug containing the translation
+against the package. Make sure to use the 'PATCH' tag, and to not use a
+severity higher than 'wishlist', since the lack of translation never
+prevented a program from running.
<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.
+layout) without asking on the corresponding l10n mailing list. You risk for
+example breaksing the encoding of the file by doing so. Moreover, what you
+consider 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.
+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 :)
+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>.
+In any case, cooperation can only be achieved with <strong>mutual
+respect</strong>.
</list>
<sect1 id="debdiff">
<heading><package>debdiff</package></heading>
<p>
-<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 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.
+<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 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>
You can run it over a pair of binary packages:
<example>
<package>debhelper</package>.
<p>
The consensus is that <package>debmake</package> is now deprecated in
-favor of <package>debhelper</package>. However, it's not a bug to use
-<package>debmake</package>.
+favor of <package>debhelper</package>. It is a bug to use
+<package>debmake</package> in new packages. New packages using
+<package>debmake</package> will be rejected from the archive.
</sect1>
<sect1 id="dh-make">
~ianmdlvl / developers-reference.git / blobdiff