<para>
Important news about changes in a package can also be put in
<filename>NEWS.Debian</filename> files.
-The news will be displayed by tools like apt-listchanges, before all the rest
+The news will be displayed by tools like <systemitem role="package">apt-listchanges</systemitem>, 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
+significant changes in a package. It is better than using <systemitem role="package">debconf</systemitem> notes since
it is less annoying and the user can go back and refer to the
<filename>NEWS.Debian</filename> file after the install. And it's better than listing
major changes in <filename>README.Debian</filename>, since the user can easily
reports that you submitted. Take this opportunity to close those that you
can't reproduce anymore. To find out all the bugs you submitted, you just have
to visit
-<literal>http://&bugs-host;/from:<replaceable><your-email-addr></replaceable></literal>.
+<literal>http://&bugs-host;/from:<replaceable>your-email-addr</replaceable></literal>.
</para>
<section id="submit-many-bugs">
<title>Reporting lots of bugs at once (mass bug filing)</title>
</para>
<para>
Please use the programs <command>dd-list</command> and if appropriate
-<command>whodepends</command> (from the package devscripts) to generate a list
+<command>whodepends</command> (from the package <systemitem role="package">devscripts</systemitem>) to generate a list
of all affected packages, and include the output in your mail to
&email-debian-devel;.
</para>
</para>
<screen>
To: submit@bugs.debian.org
-Subject: <replaceable><title-of-bug></replaceable>
+Subject: <replaceable>title-of-bug</replaceable>
-Package: <replaceable><pkgname></replaceable>
+Package: <replaceable>pkgname</replaceable>
<replaceable>[ ... ]</replaceable>
-User: <replaceable><email-addr></replaceable>
-Usertags: <replaceable><tag-name> [ <tag-name> ... ]</replaceable>
+User: <replaceable>email-addr</replaceable>
+Usertags: <replaceable>tag-name [ tag-name ... ]</replaceable>
-<replaceable><description-of-bug ...></replaceable>
+<replaceable>description-of-bug ...</replaceable>
</screen>
<para>
Note that tags are seperated by spaces and cannot contain underscores. If you
-are filing bugs for for a particular group or team it is recommended that you
+are filing bugs for a particular group or team it is recommended that you
set the <literal>User</literal> to an appropriate mailing list after describing
your intention there.
</para>
<para>
To view bugs tagged with a specific usertag, visit
-<literal>http://&bugs-host;/cgi-bin/pkgreport.cgi?users=<replaceable><email-addr></replaceable>&tag=<replaceable><tag-name></replaceable></literal>.
+<literal>http://&bugs-host;/cgi-bin/pkgreport.cgi?users=<replaceable>email-addr</replaceable>&tag=<replaceable>tag-name</replaceable></literal>.
</para>
</section>
</section>
Even though there is a dedicated group of people for Quality Assurance, QA
duties are not reserved solely for them. You can participate in this effort by
keeping your packages as bug-free as possible, and as lintian-clean (see <xref
-linkend="lintian"/> ) as possible. If you do not find that possible, then you
+linkend="lintian"/>) as possible. If you do not find that possible, then you
should consider orphaning some of your packages (see <xref
-linkend="orphaning"/> ). Alternatively, you may ask the help of other people
+linkend="orphaning"/>). Alternatively, you may ask the help of other people
in order to catch up with the backlog of bugs that you have (you can ask for
help on &email-debian-qa; or
&email-debian-devel;). At the same time, you can look for
-co-maintainers (see <xref linkend="collaborative-maint"/> ).
+co-maintainers (see <xref linkend="collaborative-maint"/>).
</para>
</section>
<para>
Looking up the email address of the maintainer for the package can be
distracting. Fortunately, there is a simple email alias,
-<literal><package>@&packages-host;</literal>, which provides a way to
+<literal><replaceable>package</replaceable>@&packages-host;</literal>, which provides a way to
email the maintainer, whatever their individual email address (or addresses)
-may be. Replace <literal><package></literal> with the name of a source
+may be. Replace <replaceable>package</replaceable> with the name of a source
or a binary package.
</para>
<para>
You may also be interested in contacting the persons who are subscribed to a
-given source package via <xref linkend="pkg-tracking-system"/> . You can do so
-by using the <literal><package>@&pts-host;</literal> email
+given source package via <xref linkend="pkg-tracking-system"/>. You can do so
+by using the <literal><replaceable>package</replaceable>@&pts-host;</literal> email
address.
</para>
<!-- FIXME: moo@packages.d.o is easily confused with moo@packages.qa.d.o -->
maintainers who are deemed Missing In Action is recorded. When a member of the
QA group contacts an inactive maintainer or finds more information about one,
this is recorded in the MIA database. This system is available in
-<filename>/org/qa.debian.org/mia</filename> on the host <literal>qa.debian.org
-</literal>, and can be queried with the <command>mia-query</command> tool.
+<filename>/org/qa.debian.org/mia</filename> on the host <literal>qa.debian.org</literal>,
+and can be queried with the <command>mia-query</command> tool.
Use <command>mia-query --help</command> to see how to query the database.
If you find that no information has been recorded about an inactive maintainer yet,
or that you can add more information, you should generally proceed as follows.
</para>
<para>
If you are interested in working in the MIA team, please have a look at the
-README file in <filename>/org/qa.debian.org/mia</filename> on <literal>
-qa.debian.org</literal> where the technical details and the MIA procedures are
+<filename>README</filename> file in <filename>/org/qa.debian.org/mia</filename> on
+<literal>qa.debian.org</literal> where the technical details and the MIA procedures are
documented and contact &email-mia;.
</para>
</section>
original source tarball, and then you should download the source and apply the
diff yourself. In practice, you may want to use the source package built by
your sponsoree. In that case, you have to check that they haven't altered the
-upstream files in the <filename>.orig.tar.gz</filename> file that they're
+upstream files in the <filename>.orig.tar.{gz,bz2,lzma}</filename> file that they're
providing.
</para>
<para>
secret keyring.
</para>
<para>
-The Maintainer field of the <filename>control</filename> file and the
+The <literal>Maintainer</literal> field of the <filename>control</filename> file and the
<filename>changelog</filename> should list the person who did the packaging,
i.e., the sponsoree. The sponsoree will therefore get all the BTS mail about
the package.
</para>
<para>
You are encouraged to keep tabs on the package you sponsor using <xref
-linkend="pkg-tracking-system"/> .
+linkend="pkg-tracking-system"/>.
</para>
</section>
<!ENTITY url-newmaint-apply "http://nm.debian.org/newnm.php">
<!ENTITY url-newmaint-id "http://&www-debian-org;/devel/join/nm-step2">
<!ENTITY url-newmaint-guide "http://&www-debian-org;/doc/maint-guide/">
-<!ENTITY url-gpg-coord "http://nm.debian.org/gpg.php">
+<!ENTITY url-gpg-coord "http://wiki.debian.org/Keysigning">
<!ENTITY url-debian-security-advisories "http://&www-debian-org;/security/">
<!ENTITY url-tech-ctte "http://&www-debian-org;/devel/tech-ctte">
<!ENTITY url-ddpo "http://qa.debian.org/developer.php">
<!ENTITY url-dcg "http://people.debian.org/~enrico/dcg/">
<!ENTITY url-rt "https://rt.debian.org/">
<!ENTITY url-wiki-dm "http://wiki.debian.org/DebianMaintainer">
+<!ENTITY url-i18n-doc-check "http://svn.debian.org/wsvn/d-i/trunk/manual/scripts/doc-check?op=file">
+<!ENTITY url-i18n-l10n "http://people.debian.org/~jfs/debconf6/html/">
+<!ENTITY url-i18n-intro "http://&www-debian-org;/doc/manuals/intro-i18n/">
+<!ENTITY url-ddtp "http://ddtp.debian.net/">
+<!ENTITY url-l10n "http://&www-debian-org;/intl/l10n/">
<!ENTITY url-incoming "http://incoming.debian.org/">
<!ENTITY url-testing-maint "http://www.debian.org/devel/testing">
<!ENTITY url-dmup "http://&www-debian-org;/devel/dmup">
<!ENTITY url-worldmap "http://&www-debian-org;/devel/developers.loc">
-<!ENTITY url-i18n-l10n "http://people.debian.org/~jfs/debconf6/html/">
-<!ENTITY url-i18n-doc-check "http://svn.debian.org/wsvn/d-i/trunk/manual/scripts/doc-check?op=file">
-
<!ENTITY url-eg-desc-upstream-info "http://&packages-host;/unstable/web/wml">
<!ENTITY url-alioth "http://alioth.debian.org/">
<!ENTITY url-rfc2440 "http://www.rfc-editor.org/rfc/rfc2440.txt">
<!ENTITY url-openprojects "http://www.freenode.net/">
<!ENTITY url-oftc "http://www.oftc.net/oftc/">
+<!ENTITY url-l10n-tp "http://translationproject.org/">
+<!ENTITY url-l10n-gnome "http://live.gnome.org/TranslationProject">
+<!ENTITY url-l10n-kde "http://i18n.kde.org/">
<!-- Debian email addresses -->
<!ENTITY email-listmaster "<email>listmaster@&lists-host;</email>">
<!ENTITY email-debian-security-announce "<email>debian-security-announce@&lists-host;</email>">
<!ENTITY email-debian-l10n-english "<email>debian-l10n-english@&lists-host;</email>">
<!ENTITY email-mia "<email>mia@qa.debian.org</email>">
-
+<!ENTITY email-keyring "<email>keyring@rt.debian.org</email>">
<!ENTITY email-rt-dsa "<email>admin@rt.debian.org</email>">
<!ENTITY email-ftpmaster "<email>ftpmaster@debian.org</email>">
<!ENTITY email-bts-control "<email>control@&bugs-host;</email>">
<para>
Be very careful with your private keys. Do not place them on any public
servers or multiuser machines, such as the Debian servers (see <xref
-linkend="server-machines"/> ). Back your keys up; keep a copy offline. Read
+linkend="server-machines"/>). Back your keys up; keep a copy offline. Read
the documentation that comes with your software; read the <ulink
url="&url-pgp-faq;">PGP FAQ</ulink>.
</para>
</para>
<para>
Usually this means that other developers are allowed to NMU (see <xref
-linkend="nmu"/> ) your package if a big problem (release critical bug, security
+linkend="nmu"/>) your package if a big problem (release critical bug, security
update, etc.) occurs while you're on vacation. Sometimes it's nothing as
critical as that, but it's still appropriate to let others know that you're
unavailable.
</para>
<para>
Ideally, you should sign up at the <ulink
-url="&url-newmaint-db;gpg.php">GPG coordination site</ulink> when booking a
+url="&url-gpg-coord;">GPG coordination pages</ulink> when booking a
holiday and check if anyone there is looking for signing. This is especially
important when people go to exotic places where we don't have any developers
yet but where there are people who are interested in applying.
<title>Managing release-critical bugs</title>
<para>
Generally you should deal with bug reports on your packages as described in
-<xref linkend="bug-handling"/> . However, there's a special category of bugs
+<xref linkend="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 <literal>critical</literal>,
<literal>grave</literal> or <literal>serious</literal> are considered to
<email>debian-qa@&lists-host;</email>, or explain your difficulties and
present a plan to fix them by sending a mail to the bug report. Otherwise,
people from the QA group may want to do a Non-Maintainer Upload (see <xref
-linkend="nmu"/> ) after trying to contact you (they might not wait as long as
+linkend="nmu"/>) after trying to contact you (they might not wait as long as
usual before they do their NMU if they have seen no recent activity from you in
the BTS).
</para>
<orderedlist numeration="arabic">
<listitem>
<para>
-Orphan all your packages, as described in <xref linkend="orphaning"/> .
+Orphan all your packages, as described in <xref linkend="orphaning"/>.
</para>
</listitem>
<listitem>
<listitem>
<para>
Notify the Debian key ring maintainers that you are leaving by opening a ticket
-in Debian RT by sending a mail to keyring@rt.debian.org with the words 'Debian
+in Debian RT by sending a mail to &email-keyring; with the words 'Debian
RT' somewhere in the subject line (case doesn't matter).
</para>
</listitem>
</para>
<para>
According to <ulink
-url="http://&www-debian-org;/doc/manuals/intro-i18n/">Introduction to
+url="&url-i18n-intro;">Introduction to
i18n</ulink> 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
<para>
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
-<ulink url="http://www.iro.umontreal.ca/contrib/po/HTML/">Free Translation
+<ulink url="&url-l10n-tp;">Free Translation
Project</ulink>, the <ulink
-url="http://developer.gnome.org/projects/gtp/">Gnome translation
-Project</ulink> or the <ulink url="http://i18n.kde.org/">KDE one</ulink>. The
+url="&url-l10n-gnome;">Gnome translation
+Project</ulink> or the <ulink url="&url-l10n-kde;">KDE one</ulink>. The
only centralized resource within Debian is the <ulink
-url="http://&www-debian-org;/intl/l10n/">Central Debian translation
+url="&url-l10n;">Central Debian translation
statistics</ulink>, where you can find some statistics about the translation
files found in the actual packages, but no real infrastructure to ease the
translation process.
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
-<ulink url="http://ddtp.debian.org/">DDTP</ulink>.
+<ulink url="&url-ddtp;">Debian Description Translation Project (DDTP)</ulink>.
</para>
<para>
-For debconf templates, maintainers should use the po-debconf package to ease
+For <systemitem role="package">debconf</systemitem> templates, maintainers
+should use the <systemitem role="package">po-debconf</systemitem> 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 <ulink
-url="http://&www-debian-org;/intl/l10n/">Central Debian translation
+<ulink url="&url-ddtp;">DDTP site</ulink> (about what is actually translated),
+and on the <ulink url="&url-l10n;">Central Debian translation
statistics</ulink> site (about what is integrated in the packages).
</para>
<para>
-For web pages, each l10n team has access to the relevant CVS, and the
+For web pages, each l10n team has access to the relevant VCS, and the
statistics are available from the Central Debian translation statistics site.
</para>
<para>
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
+for the web pages (the translators have access to the VCS), but there are no
statistics pages.
</para>
<para>
</para>
<para>
There is an effort to handle Debian-specific man pages within a <ulink
-url="&url-cvsweb;manpages/?cvsroot=debian-doc">specific CVS
+url="&url-cvsweb;manpages/?cvsroot=debian-doc">specific VCS
repository</ulink>.
</para>
</section>
<section id="l10n-faqm-tr">
<title>How to get a given text translated</title>
<para>
-To translate package descriptions or debconf templates, you have nothing to do;
+To translate package descriptions or <systemitem role="package">debconf</systemitem> 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.
</para>
<para>
As a maintainer, never edit the translations in any way (even to reformat the
layout) without asking on the corresponding l10n mailing list. You risk for
-example breaksing the encoding of the file by doing so. Moreover, what you
+example breaking the encoding of the file by doing so. Moreover, what you
consider an error can be right (or even needed) in the given language.
</para>
</listitem>
<literal>Subject</literal> of an email to
&email-debian-devel-req;. In case of problems, contact the
list administrator at &email-listmaster;. More information on
-available mailing lists can be found in <xref linkend="mailing-lists"/> .
+available mailing lists can be found in <xref linkend="mailing-lists"/>.
&email-debian-devel-announce; is another list which is
mandatory for anyone who wishes to follow Debian's development.
</para>
Another good list to subscribe to is &email-debian-mentors;.
See <xref linkend="mentors"/> for details. The IRC channel
<literal>#debian</literal> can also be helpful; see <xref
-linkend="irc-channels"/> .
+linkend="irc-channels"/>.
</para>
<para>
When you know how you want to contribute to &debian-formal;,
</para>
<para>
If you wish to be a mentor and/or sponsor, more information is available in
-<xref linkend="newmaint"/> .
+<xref linkend="newmaint"/>.
</para>
</section>
linkend="key-maint"/> for more information on maintaining your public key.
</para>
<para>
-Debian uses the <command>GNU Privacy Guard</command> (package <systemitem
+Debian uses the <literal>GNU Privacy Guard</literal> (package <systemitem
role="package">gnupg</systemitem> version 1 or better) as its baseline
standard. You can use some other implementation of OpenPGP as well. Note that
OpenPGP is an open standard based on <ulink
Most of the descriptions of these packages come from the actual package
descriptions themselves. Further information can be found in the package
documentation itself. You can also see more info with the command
-<command>apt-cache show <package-name></command>.
+<command>apt-cache show <literal>package-name</literal></command>.
</para>
<section id="tools-core">
<title>Core tools</title>
</para>
<para>
Many feel that this system should be used for all packages which require
-interactive configuration; see <xref linkend="bpp-config-mgmt"/> . <systemitem
+interactive configuration; see <xref linkend="bpp-config-mgmt"/>. <systemitem
role="package">debconf</systemitem> is not currently required by Debian Policy,
but that may change in the future.
</para>
</section>
<section id="debdiff">
-<title><systemitem role="package">debdiff</systemitem></title>
+<title><command>debdiff</command></title>
<para>
<command>debdiff</command> (from the <systemitem
-role="package">devscripts</systemitem> package, <xref linkend="devscripts"/> )
+role="package">devscripts</systemitem> package, <xref linkend="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
<command>dh_make</command>, a program that creates a skeleton of files
necessary to build a Debian package out of a source tree. As the name
suggests, <command>dh_make</command> is a rewrite of <systemitem
-role="package">debmake</systemitem> and its template files use dh_* programs
+role="package">debmake</systemitem> and its template files use <command>dh_*</command> programs
from <systemitem role="package">debhelper</systemitem>.
</para>
<para>
SPECS files from RPM source packages.
</para>
<para>
-For more informations see <literal><ulink
-url="http://yada.alioth.debian.org/">YADA site</ulink></literal>.
+For more informations see <ulink
+url="http://yada.alioth.debian.org/"><literal>YADA</literal> site</ulink>.
</para>
</section>
</section>
<section id="dcut">
-<title><systemitem role="package">dcut</systemitem></title>
+<title><command>dcut</command></title>
<para>
-The <systemitem role="package">dcut</systemitem> script (part of the package
-<xref linkend="dput"/> ) helps in removing files from the ftp upload directory.
+The <command>dcut</command> script (part of the package <systemitem role="package">dput</systemitem>,
+<xref linkend="dput"/>) helps in removing files from the ftp upload directory.
</para>
</section>
</section>
<section id="dpkg-depcheck">
-<title><systemitem role="package">dpkg-depcheck</systemitem></title>
+<title><command>dpkg-depcheck</command></title>
<para>
<command>dpkg-depcheck</command> (from the <systemitem
-role="package">devscripts</systemitem> package, <xref linkend="devscripts"/> )
+role="package">devscripts</systemitem> package, <xref linkend="devscripts"/>)
runs a command under <command>strace</command> to determine all the packages
that were used by the said command.
</para>
</screen>
<para>
<command>dpkg-depcheck</command> can also be used to check for run-time
-dependencies, especially if your package uses exec(2) to run other programs.
+dependencies, especially if your package uses <citerefentry>
+<refentrytitle>exec</refentrytitle> <manvolnum>2</manvolnum> </citerefentry>
+to run other programs.
</para>
<para>
For more information please see <citerefentry>
~ianmdlvl / developers-reference.git / commitdiff