<!ENTITY % dynamicdata SYSTEM "dynamic.ent" > %dynamicdata;
<!-- CVS revision of this document -->
- <!ENTITY cvs-rev "$Revision: 1.332 $">
+ <!ENTITY cvs-rev "$Revision: 1.333 $">
<!-- if you are translating this document, please notate the CVS
revision of the original developer's reference in cvs-en-rev -->
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
<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.
-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.
+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
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. The <url name="Debian Community Guidelines" id="&url-dcg;">
+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
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.
+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.
+<url id="http://freenode.net/faq.shtml#projectcloak" name="Freenodes
+documentation"> for more information about cloaks.
<sect id="doc-rsrcs">Documentation
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
<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. 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>.
&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
(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
-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>).
+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
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>
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.
+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,
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
<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
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>
<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>
<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>summary</tt>: automatic summary mails about the state of a
+ package
<item><tt>cvs</tt>: notification of CVS commits
<item><tt>ddtp</tt>: translations of descriptions and debconf templates
- <item><tt>derivatives</tt>: changes made on the package by derivative distributions
+ <item><tt>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>
<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
-- <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
"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.
+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
<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.
+it, or if it relies on permissions being preserved on the files shipped
+inside the .diff.gz file.
</list>
<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.
+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
<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.
+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 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
+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
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
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>
<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
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.
+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
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
+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.
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">.
+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
<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">.
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">
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.
+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.
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
+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>
Those delays may be doubled during a freeze, or testing transitions may be
switched off altogether;
<item>
-It must have the same number or 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
-be 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> cannot be installed 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).
<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>
<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">
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> (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.
+<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
<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 -->
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 <package>po-debconf</package> 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
<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):
+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>
<sect3>String/password templates
<p>
<list>
-<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 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
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 <strong>should</strong>, 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 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>
+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:
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
+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>
<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
<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
non-Debian mailing lists or news groups.
</list>
<p>
-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.
+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.
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 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.
+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 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!
+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
<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
-as 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 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.
+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>
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>
~ianmdlvl / developers-reference.git / commitdiff