<!-- include version information so we don't have to hard code it
within the document -->
<!ENTITY % versiondata SYSTEM "version.ent"> %versiondata;
- <!-- common, language independant entities -->
+ <!-- common, language independent entities -->
<!ENTITY % commondata SYSTEM "common.ent" > %commondata;
<!-- CVS revision of this document -->
- <!ENTITY cvs-rev "$Revision: 1.228 $">
+ <!ENTITY cvs-rev "$Revision: 1.244 $">
<!-- if you are translating this document, please notate the CVS
revision of the original developer's reference in cvs-en-rev -->
<title>Debian Developer's Reference
<author>Developer's Reference Team &email-devel-ref;
- <author>Adam Di Carlo, editor
+ <author>Andreas Barth
+ <author>Adam Di Carlo
<author>Raphaël Hertzog
<author>Christian Schwarz
<author>Ian Jackson
<copyright>
<copyrightsummary>
+copyright © 2004 Andreas Barth</copyrightsummary>
+ <copyrightsummary>
copyright © 1998—2003 Adam Di Carlo</copyrightsummary>
<copyrightsummary>
copyright © 2002—2003 Raphaël Hertzog</copyrightsummary>
packages (<ref id="tools">).
<p>
It should be clear that this reference does not discuss the technical
-details of the Debian package nor how to generate Debian packages.
+details of Debian packages nor how to generate them.
Nor does this reference detail the standards to which Debian software
must comply. All of such information can be found in the <url
id="&url-debian-policy;" name="Debian Policy Manual">.
are happy with the packaging work you have done. You can find a sponsor
by mailing the &email-debian-mentors; mailing list, describing your
package and yourself and asking for a sponsor (see <ref id="sponsoring">
-for more information on sponsoring). On the other hand, if you are
+and <url id="&url-mentors;"> for more information on sponsoring).
+On the other hand, if you are
interested in porting Debian to alternative architectures or kernels
you can subscribe to port specific mailing lists and ask there how to
get started. Finally, if you are interested in documentation or
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;">.
+sponsor can request one at <url id="&url-sponsors;">. Please read the
+inofficial debian-mentors FAQ at <url id="&url-mentors;"> first.
<p>
If you wish to be a mentor and/or sponsor, more information is
available in <ref id="newmaint">.
Read the documentation that comes with your software; read the <url
id="&url-pgp-faq;" name="PGP FAQ">.
<p>
+You need to ensure not only that your key is secure against being stolen,
+but also that it is secure against being lost. Generate and make a copy
+(best also in paper form) of your revocation certificate; this is needed if
+your key is lost.
+ <p>
If you add signatures to your public key, or add user identities, you
can update the Debian key ring by sending your key to the key server at
<tt>&keyserver-host;</tt>. If you need to add a completely new key,
nothing as critical as that, but it's still appropriate to let the others
know that you're unavailable.
<p>
-In order to inform the other developers, there's two things that you should do.
+In order to inform the other developers, there are two things that you should do.
First send a mail to &email-debian-private; with "[VAC] " prepended to the
subject of your message<footnote>This is so that the message can be easily
filtered by people who don't want to read vacation notices.</footnote>
While it's not your job to fix non-Debian specific bugs, you may freely
do so if you're able. When you make such fixes, be sure to pass them on
to the upstream maintainers as well. Debian users and developers will
-sometimes submit patches to fix upstream bugs -- you should evaluate
+sometimes submit patches to fix upstream bugs — you should evaluate
and forward these patches upstream.
<p>
If you need to modify the upstream sources in order to build a policy
<p>
Generally you should deal with bug reports on your packages as described in
<ref id="bug-handling">. However, there's a special category of bugs that
-you need to take care of -- the so-called release-critical bugs (RC bugs).
+you need to take care of — the so-called release-critical bugs (RC bugs).
All bug reports that have severity <em>critical</em>, <em>grave</em> or
<em>serious</em> are considered to have an impact on whether the package can
be released in the next stable release of Debian.
suggestions for the web site, etc.),
generally you'll report a bug against a ``pseudo-package''. See <ref
id="submit-bug"> for information on how to submit bugs.
+ <p>
+Some of the core servers are restricted, but the information from there
+is mirror to another server.
<sect1 id="servers-bugs">The bugs server
<p>
<tt>&bugs-host;</tt> is the canonical location for the Bug Tracking
-System (BTS). If you plan on doing some statistical analysis or
+System (BTS).
+ <p>
+It is restricted; a mirror is available on <tt>merkel</tt>.
+ <p>
+If you plan on doing some statistical analysis or
processing of Debian bugs, this would be the place to do it. Please
describe your plans on &email-debian-devel; before implementing
anything, however, to reduce unnecessary duplication of effort or
wasted processing time.
- <p>
-All Debian developers have accounts on <tt>&bugs-host;</tt>.
<sect1 id="servers-ftp-master">The ftp-master server
<p>
archive (excluding the non-US packages). Generally, package uploads
go to this server; see <ref id="upload">.
<p>
+It is restricted; a mirror is available on <tt>merkel</tt>.
+ <p>
Problems with the Debian FTP archive generally need to be reported as
bugs against the <package>ftp.debian.org</package> pseudo-package or
an email to &email-ftpmaster;, but also see the procedures in
&email-debian-admin;. Include the name of the requested CVS area,
the Debian account that should own the CVS root area, and why you need it.
+ <sect1 id="dchroot">chroots to different distributions
+ <p>
+On some machines, there are chroots to different distributions available.
+You can use them like
+
+<example>
+vore% dchroot unstable
+Executing shell in chroot: /org/vore.debian.org/chroots/user/unstable
+</example>
+
+In all chroots, the normal user home directories are available.
+You can find out which chroots are available via
+<tt>&url-devel-machines;</tt>.
+
<sect id="devel-db">The Developers Database
<p>
to make sure everything in this distribution is working properly, it is
sometimes literally unstable.
<p>
-<qref id="testing">"testing"</qref> is generated automatically by taking
+The <qref id="testing">"testing"</qref> distribution is generated
+automatically by taking
packages from unstable if they satisfy certain criteria. Those
criteria should ensure a good quality for packages within testing.
The update to testing is launched each day after the
freeze period, since the <em>unstable</em> distribution remains in
place in parallel with <em>testing</em>.
- <sect2 id="testing">
+ <sect2>
<heading>More information about the testing distribution</heading>
+ <p>
+Packages are usually installed into the `testing' distribution after they
+have undergone some degree of testing in unstable.
<p>
-The scripts that update the <em>testing</em> distribution are run each
-day after the installation of the updated packages. They generate the
-<file>Packages</file> files for the <em>testing</em> distribution, but
-they do so in an intelligent manner trying to avoid any inconsistency
-and trying to use only non-buggy packages.
- <p>
-The inclusion of a package from <em>unstable</em> is conditional on
-the following:
-<list>
- <item>
-The package must have been available in <em>unstable</em> for several days;
-the precise number depends on the upload's urgency field. It
-is 10 days for low urgency, 5 days for medium urgency and 2 days for high
-urgency. Those delays may be doubled during a freeze;
- <item>
-It must have less release-critical bugs than the version available
-in <em>testing</em>;
- <item>
-It must be available on all architectures on which it has been
-previously built. <ref id="madison"> may be of interest to
-check that information;
- <item>
-It must not break any dependency of a package that is already available
-in <em>testing</em>;
- <item>
-The packages on which it depends must either be available in <em>testing</em>
-or they must be accepted into <em>testing</em> at the same time (and they will
-if they respect all the necessary criteria);
-</list>
- <p>
-To find out whether a package is progressing into testing or not, see the
-testing script output on the <url name="web page of the testing distribution"
-id="&url-testing-maint;">, or use the program <prgn>grep-excuses</prgn>
-which is in the <package>devscripts</package> package. This utility can
-easily be used in a <manref name="crontab" section="5"> to keep one
-informed of the progression of their packages into <em>testing</em>.
- <p>
-The <file>update_excuses</file> file does not always give the precise reason
-why the package is refused, one may have to find it on their own by looking
-for what would break with the inclusion of the package. The
-<url id="&url-testing-maint;" name="testing web page"> gives some more
-information about the usual problems which may be causing such troubles.
- <p>
-Sometimes, some packages never enter <em>testing</em> because the set of
-inter-relationship is too complicated and cannot be sorted out
-by the scripts. In that case, the release manager must be
-contacted, and he will force the inclusion of the packages.
- <p>
-In general, please refer to the <url name="testing web page"
-id="&url-testing-maint;"> for more information. It also includes
-answers to some of the frequently asked questions.
-
+For more details, please see the <qref id="testing">information about the
+testing distribution</qref>.
<sect2 id="experimental">Experimental
<p>
<p>
An alternative to <em>experimental</em> is to use your personal web space
on <tt>people.debian.org</tt>.
-
+ <p>
+Please consider to use the option <tt>-v</tt> to <prgn>dpkg-buildpackage</prgn>
+if uploading a package to unstable to get the bugs finally closed that were
+first fixed in experimental.
<sect1 id="codenames">Release code names
<p>
all the other directories are only writable by the ftpmasters, that is
why you can not remove an upload once it has been accepted.
- <sect1 id="delayed-incoming">Delayed incoming
+ <sect1 id="delayed-incoming-broken">Delayed incoming
+ <p>
+<em>Note:</em> This description here is currently not working, because
+ftp-master is restricted. Please see <ref id="delayed-incoming"> for
+the currently working way.
<p>
The <file>unchecked</file> directory has a special <file>DELAYED</file>
subdirectory. It is itself subdivided in nine directories
uploaded package fits the needs of the next point release.
<sect1 id="upload-t-p-u">
- <heading>Special case: uploads to <em>testing-proposed-updates</em></heading>
- <p>
-The testing distribution is fed with packages from unstable according to the rules
-explained in <ref id="testing">. However, the release manager may stop the testing
-scripts when he wants to freeze the distribution. In that case, you may want to
-upload to <em>testing-proposed-updates</em> to provide fixed packages during the freeze.
+ <heading>Special case: uploads to <em>testing/testing-proposed-updates</em></heading>
<p>
-Keep in mind that packages uploaded there are not automatically processed, they
-have to go through the hands of the release manager. So you'd better have a good
-reason to upload there. In order to know what a good reason is in the
-release manager's eyes, you should read the instructions that he regularly
-gives on &email-debian-devel-announce;.
- <p>
-You should not upload to <em>testing-proposed-updates</em> when you can update your
-packages through <em>unstable</em>. If you can't (for example because you have a
-newer development version in unstable), you may use it but it is recommended to ask
-the authorization of the release manager before.
+Please see the information in the <qref id="t-p-u">testing section</qref> for details.
<sect id="upload">Uploading a package
residents consult a lawyer before doing uploads to non-US.
- <sect1>Delayed uploads
+ <sect1 id="delayed-incoming">Delayed uploads
<p>
Delayed uploads are done for the moment via the delayed queue at
gluck. The upload-directory is
<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 may either ask for help on &email-debian-devel; or
-reassign it to <package>debian-policy</package> to let them decide which
-package is at fault.
+be reassigned to, you should ask for help on
+<qref id="irc-channels">IRC</qref> or on &email-debian-devel;.
<p>
Sometimes you also have to adjust the severity of the bug so that it
matches our definition of the severity. That's because people tend to
against the pseudo package <package>wnpp</package>. The bug report should be
titled <tt>O: <var>package</var> -- <var>short description</var></tt>
indicating that the package is now orphaned. The severity of the bug
-should be set to <em>normal</em>. If you feel it's necessary, send a copy
+should be set to <em>normal</em>; if the package has a priority of standard
+or higher, it should be set to important.
+If you feel it's necessary, send a copy
to &email-debian-devel; by putting the address in the X-Debbugs-CC: header
of the message (no, don't use CC:, because that way the message's subject
won't indicate the bug number).
<p>
-If the package is especially crucial to Debian, you should instead submit
+If you just intend to give the package away, but you can keep maintainership
+for the moment, then you should instead submit
a bug against <package>wnpp</package> and title it <tt>RFA: <var>package</var> --
-<var>short description</var></tt> and set its severity to
-<em>important</em>. <tt>RFA</tt> stands for <em>Request For Adoption</em>.
-Definitely copy the message to debian-devel in this case, as described
-above.
+<var>short description</var></tt>.
+<tt>RFA</tt> stands for <em>Request For Adoption</em>.
<p>
-Read instructions on the <url id="&url-wnpp;" name="WNPP web pages">
-for more information.
+More information is on the <url id="&url-wnpp;" name="WNPP web pages">.
<sect1 id="adopting">Adopting a package
<p>
set <var>porter-email</var> to your email address. This will do a
binary-only build of only the architecture-dependent portions of the
package, using the `binary-arch' target in <file>debian/rules</file>.
+ <p>
+If you are working on a Debian machine for your porting efforts and you
+need to sign your upload locally for the acceptance in the archive, you
+can run <prgn>debsign</prgn> on your <file>.changes</file> file to have
+it signed conveniently, or use the remote signing mode of <prgn>dpkg-sig</prgn>.
+
<sect2 id="binary-only-nmu">
<heading>Recompilation or binary-only NMU</heading>
an updated environment. However, you have to bump the version number in
this case, so that the old bad package can be replaced in the Debian archive
(<prgn>katie</prgn> refuses to install new packages if they don't have a
-version number greater than the currently available one). Despite the
+version number greater than the currently available one).
+ <p>
+You have to make sure that your binary-only NMU doesn't render the package
+uninstallable. This could happen when a source package generates
+arch-dependend and arch-independend packages that depend on each other via
+$(Source-Version).
+ <p>
+Despite the
required modification of the changelog, these are called binary-only NMUs
— there is no need in this case to trigger all other architectures
to consider themselves out of date or requiring recompilation.
``2.9-3'', your NMU should carry a version of ``2.9-3.0.1''. If the
latest version was ``3.4-2.1'', your NMU should have a version number
of ``3.4-2.1.1''.
+ <p>
+Similar to initial porter uploads, the correct way of invoking
+<prgn>dpkg-buildpackage</prgn> is <tt>dpkg-buildpackage -B</tt> to only
+build the architecture-dependent parts of the package.
<sect2 id="source-nmu-when-porter">
non-porter, since porters have to cope with a large quantity of
packages.
Again, the situation varies depending on the distribution they are
-uploading to.
-
-<!--
-FIXME: commented out until I can work out how to upload to testing directly
-
- Crucial fixes (i.e., changes need to get a source
-package to compile for a released-targeted architecture) can be
-uploaded with <em>no</em> waiting period for the `frozen' distribution.
- -->
+uploading to. It also varies whether the architecture is a candidate
+for inclusion into the next stable release; the release managers
+decide and announce which architectures are candidates.
<p>
-However, if you are a porter doing an NMU for `unstable', the above
+If you are a porter doing an NMU for `unstable', the above
guidelines for porting should be followed, with two variations.
Firstly, the acceptable waiting period — the time between when the
bug is submitted to the BTS and when it is OK to do an NMU — is seven
can be shortened if the problem is critical and imposes hardship on
the porting effort, at the discretion of the porter group. (Remember,
none of this is Policy, just mutually agreed upon guidelines.)
+For uploads to stable or testing, please coordinate with the appropriate
+release team first.
<p>
Secondly, porters doing source NMUs should make sure that the bug they
submit to the BTS should be of severity `serious' or greater. This
<sect id="nmu">Non-Maintainer Uploads (NMUs)
<p>
Under certain circumstances it is necessary for someone other than the
-official package maintainer to make a release of a package. This is
+official package maintainer to make a release of a package. This is
called a non-maintainer upload, or NMU.
<p>
-Debian porters, who compile packages for different architectures,
-occasionally do binary-only NMUs as part of their porting activity
-(see <ref id="porting">). Another reason why NMUs are done is when a
-Debian developer needs to fix another developer's packages in order to
-address serious security problems or crippling bugs, especially during
-the freeze, or when the package maintainer is unable to release a fix
+This section handles only source NMUs, i.e. NMUs which upload a new
+version of the package. For binary-only NMUs by porters or QA members,
+please see <ref id="binary-only-nmu">.
+For buildd uploads (which are strictly speaking also NMUs), please see <ref
+id="buildd">.
+ <p>
+The main reason why NMUs are done is when a
+developer needs to fix another developer's packages in order to
+address serious problems or crippling bugs
+or when the package maintainer is unable to release a fix
in a timely fashion.
- <p>
-This chapter contains information providing guidelines for when and
-how NMUs should be done. A fundamental distinction is made between
-source and binary-only NMUs, which is explained in the next section.
-
- <sect1 id="nmu-terms">Terminology
- <p>
-There are two new terms used throughout this section: ``binary-only NMU''
-and ``source NMU''. These terms are used with specific technical
-meaning throughout this document. Both binary-only and source NMUs are
-similar, since they involve an upload of a package by a developer who
-is not the official maintainer of that package. That is why it's a
-<em>non-maintainer</em> upload.
- <p>
-A source NMU is an upload of a package by a developer who is not the
-official maintainer, for the purposes of fixing a bug in the package.
-Source NMUs always involves changes to the source (even if it is just
-a change to <file>debian/changelog</file>). This can be either a
-change to the upstream source, or a change to the Debian bits of the
-source. Note, however, that source NMUs may also include
-architecture-dependent packages, as well as an updated Debian diff.
<p>
-A binary-only NMU is a recompilation and upload of a binary package
-for a given architecture. As such, it is usually part of a porting
-effort. A binary-only NMU is a non-maintainer uploaded binary version
-of a package, with no source changes required. There are many cases
-where porters must fix problems in the source in order to get them to
-compile for their target architecture; that would be considered a
-source NMU rather than a binary-only NMU. As you can see, we don't
-distinguish in terminology between porter NMUs and non-porter NMUs.
- <p>
-Both classes of NMUs, source and binary-only, can be lumped by the
-term ``NMU''. However, this often leads to confusion, since most
-people think ``source NMU'' when they think ``NMU''. So it's best to
-be careful. In this chapter, if we use the unqualified term ``NMU'',
-we refer to any type of non-maintainer upload NMUs, whether source and
-binary, or binary-only.
-
-
- <sect1 id="nmu-who">Who can do an NMU
+First and foremost, it is critical that NMU patches to source should
+be as non-disruptive as possible. Do not do housekeeping tasks, do
+not change the name of modules or files, do not move directories; in
+general, do not fix things which are not broken. Keep the patch as
+small as possible. If things bother you aesthetically, talk to the
+Debian maintainer, talk to the upstream maintainer, or submit a bug.
+However, aesthetic changes must <em>not</em> be made in a non-maintainer
+upload.
<p>
-Only official, registered Debian maintainers can do binary or source
-NMUs. An official maintainer is someone who has their key in the
-Debian key ring. Non-developers, however, are encouraged to download
-the source package and start hacking on it to fix problems; however,
-rather than doing an NMU, they should just submit worthwhile patches
-to the Bug Tracking System. Maintainers almost always appreciate
-quality patches and bug reports.
+And please remember the Hippocratic Oath: "Above all, do no harm."
+It is better if a package has an grave bug open, than if a not working
+patch was applied, and the bug is only hidden now but not resolved.
- <sect1 id="nmu-when">When to do a source NMU
- <p>
-Guidelines for when to do a source NMU depend on the target
-distribution, i.e., stable, unstable, or experimental. Porters have
-slightly different rules than non-porters, due to their unique
-circumstances (see <ref id="source-nmu-when-porter">).
+ <sect1 id="nmu-guidelines">How to do a NMU
<p>
-When a security bug is detected, the security team may do an NMU.
-Please refer to <ref id="bug-security"> for more information.
+NMUs which fix important, serious or higher severity bugs are encouraged
+and accepted.
+You should endeavor to reach the current maintainer of the package; they
+might be just about to upload a fix for the problem, or have a better
+solution present.
<p>
-During the release cycle (see <ref id="sec-dists">), NMUs which fix
-serious or higher severity bugs are encouraged and accepted. Even
-during this window, however, you should endeavor to reach the current
-maintainer of the package; they might be just about to upload a fix
-for the problem. As with any source NMU, the guidelines found in <ref
-id="nmu-guidelines"> need to be followed. Special exceptions are made
-for <ref id="qa-bsp">.
+NMUs should be made to assist a package's maintainer in resolving bugs.
+Maintainers should be thankfull for that help, and NMUers should respect
+the decisions of maintainers, and try to personally help the maintainer by
+their work.
<p>
-Uploading bug fixes to unstable by non-maintainers should only be done
-by following this protocol:
+A NMU should follow all conventions, written down in this section.
+For an upload to testing or unstable, this order of steps is recommended:
<p>
<list>
<item>
important to notice that even in these so-called "bug squashing party"
times, the NMU'er has to file bugs and contact the developer first,
and act later.
-
- <sect1 id="nmu-guidelines">How to do a source NMU
+Please see <ref id="qa-bsp"> for details.
<p>
-The following applies to porters insofar as they are playing the dual
-role of being both package bug-fixers and package porters. If a
-porter has to change the Debian source archive, their upload is
-automatically a source NMU and is subject to its rules. If a porter is
-simply uploading a recompiled binary package, the rules are different;
-see <ref id="porter-guidelines">.
+For the testing distribution, the rules may be changed by the release
+managers. Please take additional care, and acknowledge that the usual way
+for a package to enter testing is through unstable.
<p>
-First and foremost, it is critical that NMU patches to source should
-be as non-disruptive as possible. Do not do housekeeping tasks, do
-not change the name of modules or files, do not move directories; in
-general, do not fix things which are not broken. Keep the patch as
-small as possible. If things bother you aesthetically, talk to the
-Debian maintainer, talk to the upstream maintainer, or submit a bug.
-However, aesthetic changes must <em>not</em> be made in a non-maintainer
-upload.
+For the stable distribution, please take extra care. Of course, the release
+managers may also change the rules here. Please verify before upload that
+all your changes are ok for inclusion into the next stable release by the
+release manager.
+ <p>
+When a security bug is detected, the security team may do an NMU, using
+their own rules. Please refer to <ref id="bug-security"> for more
+information.
+ <p>
+For the differences for Porters NMUs, please see
+<ref id="source-nmu-when-porter">.
+ <p>
+Of course, it is always possible to agree on special rules with a maintainer
+(like the maintainer asking "please upload this fix directly for me, and no
+diff required").
- <sect2 id="nmu-version">Source NMU version numbering
+ <sect1 id="nmu-version">NMU version numbering
<p>
Whenever you have made a change to a package, no matter how trivial,
the version number needs to change. This enables our packing system
the release should start with the <var>debian-revision</var> value
`0.1'. The usual maintainer of a package should start their
<var>debian-revision</var> numbering at `1'.
+ <p>
+If you upload a package to testing or stable, sometimes, you need to
+"fork" the version number tree. For this, version numbers like
+1.1-3sarge0.1 could be used.
- <sect2 id="nmu-changelog">
+ <sect1 id="nmu-changelog">
<heading>Source NMUs must have a new changelog entry</heading>
<p>
A non-maintainer doing a source NMU must create a changelog entry,
</example>
- <sect2 id="nmu-patch">Source NMUs and the Bug Tracking System
+ <sect1 id="nmu-patch">Source NMUs and the Bug Tracking System
<p>
Maintainers other than the official package maintainer should make as
few changes to the package as possible, and they should always send a
If the source NMU (non-maintainer upload) fixes some existing bugs,
these bugs should be tagged <em>fixed</em> in the Bug Tracking
System rather than closed. By convention, only the official package
-maintainer or the original bug submitter are allowed to close bugs.
+maintainer or the original bug submitter close bugs.
Fortunately, Debian's archive system recognizes NMUs and thus marks
the bugs fixed in the NMU appropriately if the person doing the NMU
has listed all bugs in the changelog with the <tt>Closes:
changes in the NMU are incorporated officially into the package by
the official package maintainer.
<p>
-Also, after doing an NMU, you have to open a new bug and include a
-patch showing all the changes you have made. Alternatively you can send
-that information to the existing bugs that are fixed by your NMU.
+Also, after doing an NMU, you have to send
+that information to the existing bugs that are fixed by your NMU,
+including the unified diff.
+Alternatively you can open a new bug and include a
+patch showing all the changes you have made.
The normal maintainer will either apply the patch or employ an alternate
method of fixing the problem. Sometimes bugs are fixed independently
upstream, which is another good reason to back out an NMU's patch.
entry in the changelog file documenting the non-maintainer upload.
- <sect2 id="nmu-build">Building source NMUs
+ <sect1 id="nmu-build">Building source NMUs
<p>
Source NMU packages are built normally. Pick a distribution using the
same rules as found in <ref id="distribution">, follow the other
If one of your packages has been NMU'ed, you have to incorporate the
changes in your copy of the sources. This is easy, you just have
to apply the patch that has been sent to you. Once this is done, you
-have to close the bugs that have been tagged fixed by the NMU. You
-can either close them manually by sending the required mails to the
+have to close the bugs that have been tagged fixed by the NMU. The easiest
+way is to use the <tt>-v</tt> option of <prgn>dpkg-buildpackage</prgn>,
+as this allows you to include just all changes since your last maintainer
+upload. Alternativly, you
+can close them manually by sending the required mails to the
BTS or by adding the required <tt>closes: #nnnn</tt> in the changelog
entry of your next upload.
<p>
basis as co-maintainer or backup maintainer
(see <ref id="collaborative-maint">).
+ <sect1 id="nmu-vs-qa">NMU vs QA uploads
+ <p>
+Unless you know the maintainer is still active, it is wise to check the
+package to see if it has been orphaned. The current list of orphaned
+packages which haven't had their maintainer set correctly is available at
+<url id="&url-debian-qa-orphaned;">. If you perform an NMU on an
+improperly orphaned package, please set the maintainer to ``Debian QA Group
+<packages@qa.debian.org>''.
+
+ <sect1 id="nmu-who">Who can do an NMU
+ <p>
+Only official, registered Debian maintainers can do binary or source
+NMUs. An official maintainer is someone who has their key in the
+Debian key ring. Non-developers, however, are encouraged to download
+the source package and start hacking on it to fix problems; however,
+rather than doing an NMU, they should just submit worthwhile patches
+to the Bug Tracking System. Maintainers almost always appreciate
+quality patches and bug reports.
+
+ <sect1 id="nmu-terms">Terminology
+ <p>
+There are two new terms used throughout this section: ``binary-only NMU''
+and ``source NMU''. These terms are used with specific technical
+meaning throughout this document. Both binary-only and source NMUs are
+similar, since they involve an upload of a package by a developer who
+is not the official maintainer of that package. That is why it's a
+<em>non-maintainer</em> upload.
+ <p>
+A source NMU is an upload of a package by a developer who is not the
+official maintainer, for the purposes of fixing a bug in the package.
+Source NMUs always involves changes to the source (even if it is just
+a change to <file>debian/changelog</file>). This can be either a
+change to the upstream source, or a change to the Debian bits of the
+source. Note, however, that source NMUs may also include
+architecture-dependent packages, as well as an updated Debian diff.
+ <p>
+A binary-only NMU is a recompilation and upload of a binary package
+for a given architecture. As such, it is usually part of a porting
+effort. A binary-only NMU is a non-maintainer uploaded binary version
+of a package, with no source changes required. There are many cases
+where porters must fix problems in the source in order to get them to
+compile for their target architecture; that would be considered a
+source NMU rather than a binary-only NMU. As you can see, we don't
+distinguish in terminology between porter NMUs and non-porter NMUs.
+ <p>
+Both classes of NMUs, source and binary-only, can be lumped by the
+term ``NMU''. However, this often leads to confusion, since most
+people think ``source NMU'' when they think ``NMU''. So it's best to
+be careful. Best use always ``binary NMU'' or ``binNMU'' for binary-only
+NMUs.
+
<sect id="collaborative-maint">
<heading>Collaborative maintenance</heading>
tools on Alioth (see <ref id="alioth">).
</sect>
+ <sect id="testing">
+ <heading>The testing distribution</heading>
+ <p>
+ <sect1 id="testing-basics">
+ <heading>Basics</heading>
+ <p>
+Packages are usually installed into the `testing' distribution after they
+have undergone some degree of testing in unstable.
+ <p>
+They must be in sync on all architectures and
+mustn't have dependencies that make them uninstallable; they also have to
+have generally no known release-critical bugs at the time they're
+installed into testing.
+This way, `testing' should always be close to being a release candidate.
+Please see below for details.
+ <sect1 id="testing-unstable">
+ <heading>Updates from unstable</heading>
+ <p>
+The scripts that update the <em>testing</em> distribution are run each
+day after the installation of the updated packages. They generate the
+<file>Packages</file> files for the <em>testing</em> distribution, but
+they do so in an intelligent manner trying to avoid any inconsistency
+and trying to use only non-buggy packages.
+ <p>
+The inclusion of a package from <em>unstable</em> is conditional on
+the following:
+<list>
+ <item>
+The package must have been available in <em>unstable</em> for 2, 5 or 10
+days, depending on the urgency (high, medium or low).
+Please note that the urgency is sticky, means that the highest
+urgency uploaded since the last testing transition is taken into account.
+Those delays may be doubled during a freeze, or testing transition may be
+switched off at all;
+ <item>
+It must have less release-critical bugs than the version available
+in <em>testing</em>;
+ <item>
+It must be available on all architectures on which it has been
+previously built in unstable. <ref id="madison"> may be of interest to
+check that information;
+ <item>
+It must not break any dependency of a package that is already available
+in <em>testing</em>;
+ <item>
+The packages on which it depends must either be available in <em>testing</em>
+or they must be accepted into <em>testing</em> at the same time (and they will
+if they respect all the necessary criteria);
+</list>
+ <p>
+To find out whether a package is progressing into testing or not, see the
+testing script output on the <url name="web page of the testing distribution"
+id="&url-testing-maint;">, or use the program <prgn>grep-excuses</prgn>
+which is in the <package>devscripts</package> package. This utility can
+easily be used in a <manref name="crontab" section="5"> to keep one
+informed of the progression of their packages into <em>testing</em>.
+ <p>
+The <file>update_excuses</file> file does not always give the precise reason
+why the package is refused, one may have to find it on their own by looking
+for what would break with the inclusion of the package. The
+<url id="&url-testing-maint;" name="testing web page"> gives some more
+information about the usual problems which may be causing such troubles.
+ <p>
+Sometimes, some packages never enter <em>testing</em> because the set of
+inter-relationship is too complicated and cannot be sorted out
+by the scripts. See below for details.
+ <p>
+Some further dependency analysis is shown on
+<url id="http://bjorn.haxx.se/debian/"> - but be warned, they show also
+the build dependencies that are not considered by britney.
+
+ <sect2 id="outdated">
+ <heading>out-of-date</heading>
+ <p>
+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 an list of architectures
+that don't keep up (in update_out.py), but currently, it's empty).
+"outdated" has nothing whatsoever to do with the architectures this package
+has in testing.
+ <p>
+Consider this example:
+ <p>
+ <example>
+foo | alpha | arm
+---------+-------+----
+testing | 1 | -
+unstable | 1 | 2
+</example>
+ <p>
+The package is out of date on alpha in unstable, and will not go to
+testing. And removing foo from testing would not help at all, the package
+is still out of date on alpha, and will not propagate to testing.
+ <p>
+However, if ftp-master removes a package in unstable (here on arm):
+ <p>
+ <example>
+foo | alpha | arm | hurd-i386
+---------+-------+-----+----------
+testing | 1 | 1 | -
+unstable | 2 | - | 1
+ </example>
+ <p>
+In this case, the package is up to date on all release architectures in
+unstable (and the extra hurd-i386 doesn't matter, as it's not a release
+architecture).
+ <p>
+Sometimes, the question is raised if it is possible to allow packages in
+that are not yet built on all architectures: No. Just plainly no. (Except
+if you maintain glibc or so.)
+
+ <sect2 id="removals">
+ <heading>Removals from testing</heading>
+ <p>
+Sometimes, a package is removed to allow another package in: This happens
+only to allow _another_ package to go in, that's ready in every other
+sense. Consider e.g. that a conflicts with the new version of b; than a may
+be removed to allow b 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 that is not handled very well by britney is if package a
+depends on the new version of package b, and vice versa.
+ <p>
+An example of this is:
+ <p>
+ <example>
+ | testing | unstable
+--+-----------------+------------
+a | 1; depends: b=1 | 2; depends: b=2
+b | 1; depends: a=1 | 2; depends: a=2
+ </example>
+ <p>
+Package a is not considered for update, and package b also not.
+ <p>
+Currently, this requires some manual hinting from the release team.
+Please, contact them by sending mail to &email-debian-release; if that
+happens to one of your packages.
+
+
+ <sect2>
+ <heading>influence of package in testing</heading>
+ <p>
+Generally, there is nothing that the status of a package in testing means
+for transition of the next version from unstable to testing, with two
+exceptions: If the RC-bugginess of the package goes down, it may go in
+even if it is still RC-buggy. The second exception is if the version
+of the package in testing is out of sync on the different arches: Then
+any arch might just upgrade to the version of the source package;
+however, this can happen only if the package was previously forced
+through, the arch is in fuckedarches or there was no binary package of that
+arch present in unstable at all during the testing migration.
+ <p>
+In summary this means: The only influence that a package being in testing
+has on a new version of the same package is that the new version might
+go in easier.
+
+ <sect2 id="details">
+ <heading>details</heading>
+ <p>
+If you are interested in details, this is how britney works:
+ <p>
+The packages are looked at to determine whether they are valid
+candidates. This gives the "update excuses". The most common reasons
+why a package is not considered are too young, RC-bugginess and out of
+date on some arches. For this part, the release managers have hammers
+of any size to force britney to consider a package. (Also, the base
+freeze is coded in that part of britney.) (There is a similar thing
+for binary-only updates, but this is not described here. If you're
+interessted in that, please use 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 sarge is not
+more uninstallable after the update as before. (Before and after this part,
+some hints are processed; but as only release masters can hint, this is
+probably not so important for you.)
+ <p>
+If you want to see more details, you can look it up on
+merkel:/org/ftp.debian.org/testing/update_out/ (or there in
+~aba/testing/update_out to see a setup with a smaller packages file). Via
+web, it's at <url
+id="http://ftp-master.debian.org/testing/update_out_code/">
+ <p>
+The hints are available via <url
+id="http://ftp-master.debian.org/testing/hints/">.
+
+
+ <sect1 id="t-p-u">
+ <heading>Direct updates to testing</heading>
+ <p>
+The testing distribution is fed with packages from unstable according to the rules
+explained above. However, in some cases, it is necessary to upload
+packages built only for testing. For that, you may want to
+upload to <em>testing-proposed-updates</em>.
+ <p>
+Keep in mind that packages uploaded there are not automatically processed, they
+have to go through the hands of the release manager. So you'd better have a good
+reason to upload there. In order to know what a good reason is in the
+release manager's eyes, you should read the instructions that he regularly
+gives 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 it but it is recommended to ask
+the authorization of the release manager before. Even if a package is
+frozen, updates through unstable are possible, if the upload via unstable
+does not pulls an new dependency in.
+ <p>
+Version numbers are usually selected by adding the codename of the testing
+distribution and a incrementing number, like 1.2sarge1 for the first upload
+through testing-proposed-updates of the package version 1.2.
+ <p>
+Please make sure you didn't miss any of these items at your upload:
+<list>
+<item> Make sure that your package really needs to go through
+<em>testing-proposed-uploads</em>, and can't go through unstable;
+<item> Make sure that you included only the minimal amount of changes;
+<item> Make sure that you included an appropriate explaination in the
+changelog;
+<item> Make sure that you've written <em>testing</em> or
+<em>testing-proposed-updates</em> into your target distribution;
+<item> Make sure that you've build and tested your package in
+<em>testing</em>, not in <em>unstable</em>;
+<item> Make sure that your version number is higher than the version in
+<em>testing</em> and <em>testing-proposed-updates</em>, and lower than in
+<em>unstable</em>;
+<item> After uploading and successful build on all platforms, contact the
+release team at &email-debian-release; and ask them to approve your upload.
+</list>
+
+
+ <sect1 id="faq">
+ <heading>Frequently asked questions</heading>
+ <p>
+
+ <sect2 id="rc">
+ <heading>What are release-critical bugs, and how do they get counted?</heading>
+ <p>
+All bugs of some higher severities are by default considered release-critical; currently, these are critical, grave and serious bugs.
+ <p>
+Such bugs are presumed to have an impact on the chances that the package will be released with the stable release of Debian: in general, if a package has open release-critical bugs filed on it, it won't get into "testing", and consequently won't be released in "stable".
+ <p>
+The "testing" bug count for a package is considered to be roughly the bug count at the last point when the "testing" version equalled the "unstable" version. The bugs tagged woody or sarge will not be counted. Bugs with the sid tag will be counted, though.
+
+
+ <sect2>
+ <heading>How could installing a package into "testing" possibly break other packages?</heading>
+ <p>
+The structure of the distribution archives is such that they can only contain one version of a package; a package is defined by its name. So, when the source package acmefoo is installed into "testing", along with its binary packages acme-foo-bin, acme-bar-bin, libacme-foo1 and libacme-foo-dev, the old version is removed.
+ <p>
+However, the old version may have provided a binary package with an old soname of a library, such as libacme-foo0. Removing the old acmefoo will remove libacme-foo0, which will break any packages which depend on it.
+ <p>
+Evidently, this mainly affects packages which provide changing sets of binary packages in different versions (in turn, mainly libraries). However, it will also affect packages upon which versioned dependencies have been declared of the ==, <= or << varieties.
+ <p>
+When the set of binary packages provided by a source package change in this way, all the packages that depended on the old binaries will have to be updated to depend on the new binaries instead. Because installing such a source package into "testing" breaks all the packages that depended on it in "testing", some care now has to be taken: all the depending packages must be updated and ready to be installed themselves so that they won't be broken, and, once everything is ready, manual intervention by the release manager or an assistant is normally required.
+ <p>
+If you are having problems with complicated groups of packages like this, contact debian-devel or debian-release for help.
+ </sect>
<chapt id="best-pkging-practices">
<heading>Best Packaging Practices</heading>
<heading>Separating your patches into multiple files</heading>
<p>
Big, complex packages may have many bugs that you need to deal with.
-If you correct a number of bug directly in the source, if you're not
+If you correct a number of bugs directly in the source, and you're not
careful, it can get hard to differentiate the various patches that you
applied. It can get quite messy when you have to update the package
to a new upstream version which integrates some of the fixes (but not
for <file>debian/control</file> files:
<example>ispell -d american -g debian/control</example>
+ <p>
+User usually expect these questions to be answered in the package
+description.
+ <list>
+ <item>
+What does the package do? If it is an add-on to another package,
+then the short description of the package we are an add on to
+should be put in here.
+ <item>
+Why should I want this package? This is related to the above,
+but not the same (this is a mail user agent; this is cool, fast,
+interfaces with pgp and ldap and imap, has features X, Y, and Z).
+ <item>
+If this package should not be installed directly, but is pulled in
+by another package, this should be mentioned.
+ <item>
+If the package is experimental, or there are other reasons it
+should not be used, if there are other packages that should be
+used instead, it should be here as well.
+ <item>
+How is this package different from the competition? Is it a better
+implementation? more features? different features? Why should I
+choose this package (2. should talk about the class of packages, and
+this about this particular package, if you have information related to both).
+ </list>
+
</sect1>
Where's the description? If you can't think of a descriptive message,
start by inserting the title of each different bug.
</sect1>
+
+ <sect1 id="bpp-news-debian">
+ <heading>Suplimenting changelogs with NEWS.Debian files</heading>
+ <p>
+Important news about changes in a package can also be put in NEWS.Debian
+files. The news will be displayed by tools like apt-listchanges, before
+all the rest of the changelogs. This is the preferred means to let the user
+know about significant changes in a package. It is better than using
+debconf notes since it is less annoying and the user can go back and refer
+to the NEWS.Debian file after the install. And it's better than listing
+major changes in README.Debian, since the user can easily miss such notes.
+ <p>
+The file format is the same as a debian changelog file, but leave off
+the asterisks and describe each news item with a full paragraph when
+necessary rather than the more concise summaries that would go in a
+changelog. It's a good idea to run your file through dpkg-parsechangelog to
+check its formatting as it will not be automatically checked during build
+as the changelog is. Here is an example of a real NEWS.Debian file:
+<example>
+cron (3.0pl1-74) unstable; urgency=low
+
+ The checksecurity script is no longer included with the cron package:
+ it now has its own package, "checksecurity". If you liked the
+ functionality provided with that script, please install the new
+ package.
+
+ -- Steve Greenland <stevegr&debian.org> Sat, 6 Sep 2003 17:15:03 -0500
+</example>
+ <p>
+The NEWS.Debian file is installed as
+/usr/share/doc/<package>/NEWS.Debian.gz. It is compressed, and
+always has that name even in Debian native packages. If you use debhelper,
+dh_installchangelogs will install debian/NEWS files for you.
+ <p>
+Unlike changelog files, you need not update NEWS.Debian files with every
+release. Only update them if you have something particularly newsworthy
+that user should know about. If you have no news at all, there's no need
+to ship a NEWS.Debian file in your package. No news is good news!
</sect>
<!--
<prgn>lintian</prgn> or <prgn>linda</prgn> (see <ref id="tools-lint">)
when run over the entire Debian archive.
</sect1>
- </sect>
+
+ <sect1 id="bpp-locale">
+ <heading>Needing a certain locale during build</heading>
+ <p>
+If you need a certain locale during build, you can create a temporary
+file via this trick:
+ <p>
+If you set LOCPATH to the equivalent of /usr/lib/locale, and LC_ALL to
+the name of the locale you generate, you should get what you want
+without being root. Something like this:
+
+<example>
+LOCALE_PATH=debian/tmpdir/usr/lib/locale
+LOCALE_NAME=en_IN
+LOCALE_CHARSET=UTF-8
+
+mkdir -p $LOCALE_PATH
+localedef -i "$LOCALE_NAME.$LOCALE_CHARSET" -f "$LOCALE_CHARSET" "$LOCALE_PATH/$LOCALE_NAME.$LOCALE_CHARSET"
+
+# Using the locale
+LOCPATH=$LOCALE_PATH LC_ALL=$LOCALE_NAME.$LOCALE_CHARSET date
+</example>
+ </sect1>
+
+ <sect1 id="bpp-transition">
+ <heading>Make transition packages deborphan compliant</heading>
+ <p>
+Deborphan is a program helping users to detect which packages can be safely
+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, 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 example, just run:
+ <example>apt-cache search .|grep dummy</example> or
+ <example>apt-cache search .|grep transitional</example>.
+ </sect1>
+
+ </sect>
</chapt>
haven't registered out of the system, so to speak. On the other hand,
it is also possible that they just need a reminder.
<p>
+There is a simple system (the MIA database) in which information about
+maintainers who are deemed inactive are recorded. When a member of the
+QA group contacts an inactive maintainer or finds more information about
+them, this is recorded in the MIA database. This system is available
+in /org/qa.debian.org/mia on the host qa.debian.org, and can be queried
+with a tool known as <prgn>mia-history</prgn>. By default,
+<prgn>mia-history</prgn> shows information about every person it knows
+about, but it accepts regular expressions as arguments which it uses to
+match user names. <example>mia-history --help</example> shows which
+arguments are accepted. If you find that no information has been recorded
+about an inactive maintainer already, or that you can add more information,
+you will 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
time", but it is important to take into account that real life is sometimes
non-Debian mailing lists or news groups.
</list>
<p>
-One big problem are packages which were sponsored -- the maintainer is not
+One big problem are packages which were sponsored — the maintainer is not
an official Debian developer. The echelon information is not available for
sponsored people, for example, so you need to find and contact the Debian
developer who has actually uploaded the package. Given that they signed the
People on this alias will use the information you provided in order to
decide how to proceed. For example, they might orphan one or all of the
packages of the maintainer. If a packages has been NMUed, they might prefer
-to contact the NMUer before orphaning the package -- perhaps the person who
+to contact the NMUer before orphaning the package — perhaps the person who
has done the NMU is interested in the package.
<p>
One last word: please remember to be polite. We are all volunteers and
cannot dedicate all of our time to Debian. Also, you are not aware of the
circumstances of the person who is involved. Perhaps they might be
-seriously ill or might even had died -- you do not know who may be on the
-receiving side -- imagine how a relative will feel if they read the e-mail
+seriously ill or might even had died — you do not know who may be on the
+receiving side — imagine how a relative will feel if they read the e-mail
of the deceased and find a very impolite, angry and accusing message!)
<p>
On the other hand, although we are volunteers, we do have a responsibility.
-So you can stress the importance of the greater good -- if a maintainer does
+So you can stress the importance of the greater good — if a maintainer does
not have the time or interest anymore, they should "let go" and give the
package to someone with more time.
<p>
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.
+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 uniq in your
+secret keyring.
<p>
The Maintainer field of the <file>control</file> file and the
<file>changelog</file> should list the person who did the packaging, i.e., the
Application Managers"> at the Debian web site.
+ <chapt id="l10n">Internationalizing, translating, being internationalized
+ and being translated
+ <p>
+Debian supports an ever-increasing number of natural languages. Even if you are
+native English speaker and do not speak any other language, it is part of your
+duty as a maintainer to be aware of issues of internationalization (abbreviated
+i18n because there are 18 letters between the 'i' and the 'n' in
+internationalization). Therefore, even if you are ok with English only
+programs, you should read most of this chapter.
+ <p>
+According to <url id="http://www.debian.org/doc/manuals/intro-i18n/"
+name="Introduction to i18n"> from Tomohiro KUBOTA, "I18N (internationalization)
+means modification of a software or related technologies so that a software can
+potentially handle multiple languages, customs, and so on in the world." while
+"L10N (localization) means implementation of a specific language for an already
+internationalized software."
+ <p>
+l10n and i18n are tied, 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>
+Letting alone the i18n problems, where no general receipt exist, there is
+actually no central infrastructure for l10n within Debian which could be
+compared to the dbuild mechanism for porting. So, most of the work has to be
+done manually.
+
+
+ <sect id="l10n-handling">How translations are handled within Debian
+ <p>
+Handling translation of the texts contained in a package is still a manual
+task, and the process depends on the kind of text you want to see translated.
+ <p>
+For program messages, the gettext infrastructure is used most of the time.
+Most of the time, the translation is handled upstream within projects like the
+<url id="http://www.iro.umontreal.ca/contrib/po/HTML/" name="Free Translation
+Project">, the <url id="http://developer.gnome.org/projects/gtp/" name="Gnome
+translation Project"> or the <url id="http://i18n.kde.org/" name="KDE one">.
+The only centralized resource within Debian is the <url
+id="http://www.debian.org/intl/l10n/" name="Central Debian translation
+statistics">, where you can find some statistics about the translation files
+found in the actual package, but no real infrastructure to ease the translation
+process.
+ <p>
+An effort to translate the package descriptions started long ago even if very
+few support is offered by the tools to actually use them (ie, only APT can use
+them, when configured correctly). There is nothing to do for the maintainers,
+and the translators should use the <url id="http://ddtp.debian.org/"
+name="DDTP">.
+ <p>
+For debconf templates, maintainer should use the po-debconf package to ease the
+work of translators, which could use the DDTP to do their work (but French and
+Brazilian teams don't). Some statistics can be found both on the DDTP site
+(about what is actually translated), and on the <url
+id="http://www.debian.org/intl/l10n/" name="Central Debian translation
+statistics"> site (about what is integrated in the packages).
+ p>
+For web pages, each l10n team has access to the relevant CVS, and the statistics
+are available from the Central Debian translation statistics site.
+ <p>
+For general documentation about Debian, the process is more or less the same
+than for the web pages (the translators have an access to the CVS), but there is
+no statistics pages.
+ <p>
+For package specific documentation (man pages, info document, other formats),
+almost everything have yet to be done. Most notably, the KDE project handles
+translation of its documentation in the same way as its program messages.
+Debian specific man pages begin to be handled within a <url
+id="http://cvs.debian.org/manpages/?cvsroot=debian-doc" name="specific CVS
+repository"> .
+
+
+ <sect id="l10n-faqm">I18N & L10N FAQ for maintainers
+ <p>
+This is a list of problems that maintainers may face concerning i18n and l10n.
+While reading this, keep in mind that there is no real consensus on those
+points within Debian, and that they are only advices. 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 description 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 Internet, and ask on debian-i18n
+for a translation in the 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 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 included in your package
+and will ask you for inclusion 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 include it fearlessly into your package.
+
+ <sect1 id="l10n-faqm-update">How to get a given translation updated?
+ <p>
+If you have some translations of a given text laying around, each time you
+update the original, you should kindly ask to the previous translator to update
+his/her work to make the translation up to date with regard to the current
+original text. 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 to 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 completely a translation because it is outdated. An old
+documentation is often better than no documentation at all for non-English
+speaker.
+
+ <sect1 id="l10n-faqm-bug">How to handle a bug report concerning a translation?
+ <p>
+The best solution may be to mark the bug as "forwarded to upstream", and
+forward it to both the previous translator and his/her team (using the
+corresponding debian-l10n-XXX mailing list).
+
+ <sect id="l10n-faqtr">I18N & L10N FAQ for translators
+ <p>
+While reading this, please keep in mind that there is no general procedure
+within Debian concerning those points, and that in any case, you should
+collaborate with your team and the package maintainer.
+
+ <sect1 id="l10n-faqtr-help">How to help the translation effort?
+ <p>
+Choose what you want to translate, make sure that nobody is already working on
+it (using your debian-l10n-XXX mailing list), translate it, get it reviewed by
+other native speakers on your l10n mailing list, and provide it to the
+maintainer of the package (see next point).
+
+ <sect1 id="l10n-faqtr-inc">How to provide a translation for inclusion in a package?
+ <p>
+Make sure your translation is correct (asking for review on your l10n mailing
+list) before providing it for inclusion. It will save time for everyone, and
+avoid the chaos resulting in having several versions of the same document in
+bug reports.
+ <p>
+The best solution is to fill a regular bug containing the translation against
+the package. Make sure to use the 'PATCH' tag, and to not use a gravity higher
+than 'wishlist', since the lack of translation never prevented a program from
+running.
+
+ <sect id="l10n-best">Best current practice concerning l10n
+ <p>
+<list>
+ <item>
+As a maintainer, never edit the translations in any way (even to reformat the
+layout) without asking to the corresponding l10n mailing list. You risk for
+example to break the encoding of the file by doing so. Moreover, what you
+consider as an error can be right (or even needed) in the given language.
+ <item>
+As a translator, if you find an error in the original text, make sure to report
+it. Translators are often the most attentive readers of a given text, and if
+they don't report the errors they find, nobody will.
+ <item>
+In any case, remember that the major issue with l10n is that it requires
+several people to cooperate, and that it is very easy to start a flamewar about
+small problems because of misunderstanding. So, if you have problems with your
+interlocutor, ask for help on the corresponding l10n mailing list, on
+debian-i18n, or even on debian-devel (but beware, l10n discussions very often
+become flamewars on that list :)
+ <item>
+In any case, cooperation can only be achieved with <strong>mutual respect</strong>.
+</list>
+
<appendix id="tools">Overview of Debian Maintainer Tools
<p>
<package>yada</package> is another packaging helper tool. It uses a
<file>debian/packages</file> file to auto-generate
<file>debian/rules</file> and other necessary files in the
-<file>debian/</file> subdirectory.
- <p>
-Note that <package>yada</package> is called "essentially unmaintained"
-by it's own maintainer, Charles Briscoe-Smith. As such, it can be
-considered deprecated.
+<file>debian/</file> subdirectory. The <file>debian/packages</file> file
+contains instruction to build packages and there is no need to create any
+<file>Makefile</file> files. There is possibility to
+use macro engine similar to the one used in SPECS files from RPM
+source packages.</p>
+ <p>
+For more informations see
+<tt><url id="http://yada.alioth.debian.org/" name="YADA site"></tt>.</p>
</sect1>
<sect1 id="equivs">
~ianmdlvl / developers-reference.git / blobdiff