<!entity % commondata SYSTEM "common.ent" > %commondata;
<!-- CVS revision of this document -->
- <!entity cvs-rev "$Revision: 1.110 $">
+ <!entity cvs-rev "$Revision: 1.111 $">
<!-- if you are translating this document, please notate the CVS
revision of the developers reference here -->
<!--
may want to subscribe to &email-debian-vote;.
<p>
The list of all the proposals (past and current) is available on the
-web at <url id="url-vote">. You will find there additionnal information
+web at <url id="url-vote">. You will find there additional information
about how to make a vote proposal.
<p>
&email-debian-private; is a special mailing list for private
discussions amongst Debian developers. It is meant to be used for
-posts which for whatever reason should not be published publically.
+posts which for whatever reason should not be published publicly.
As such, it is a low volume list, and users are urged not to use
&email-debian-private; unless it is really necessary. Moreover, do
<em>not</em> forward email from that list to anyone. Archives of this
in the archives of debian-private in <file>&master-host;:&file-debian-private-archive;</file>, just <prgn>zgrep</prgn> for <em>#debian-private</em> in
all the files.
<p>
-There are other additionnal channels dedicated to specific subjects.
+There are other additional channels dedicated to specific subjects.
<em>#debian-bugs</em> is used for coordinating bug squash parties.
<em>#debian-boot</em> is used to coordinate the work on the boot
floppies (i.e. the installer). <em>#debian-doc</em> is
-occasionnaly used to work on documentation like the one you are
+occasionally used to work on documentation like the one you are
reading. Other channels are dedicated to an architecture or a set of
-packages : <em>#debian-bsd</em>, <em>#debian-kde</em>,
+packages: <em>#debian-bsd</em>, <em>#debian-kde</em>,
<em>#debian-sf</em> (SourceForge package), <em>#debian-oo</em> (OpenOffice
package) ...
<p>
-Some non-english channels exist, for example <em>#debian-devel-fr</em> for
-french speaking people interested in Debian's development.
+Some non-English channels exist, for example <em>#debian-devel-fr</em> for
+French speaking people interested in Debian's development.
<sect id="doc-rsrcs">Documentation
<sect1 id="servers-cvs">The CVS server
<p>
<tt>cvs.debian.org</tt> is also known as <tt>klecker.debian.org</tt>,
-discussed above. If you need to use a publically accessible CVS
+discussed above. If you need to use a publicly accessible CVS
server, for instance, to help coordinate work on a package between
many different developers, you can request a CVS area on the server.
<p>
ships for the <em>i386</em>, <em>m68k</em>, <em>alpha</em>, and
<em>sparc</em> architectures. Debian 2.2 added support for the
<em>powerpc</em> and <em>arm</em> architectures. Debian 3.0 adds
-support of five new architectures : <em>ia64</em>, <em>hppa</em>,
+support of five new architectures: <em>ia64</em>, <em>hppa</em>,
<em>s390</em>, <em>mips</em> and <em>mipsel</em>.
<p>
Information for developers or uses about the specific ports are
<p>
Once the package is accepted the system sends a confirmation
mail to the maintainer, closes all the bugs marked as fixed by the upload
-and the autobuilders may start recompiling it. The package is now publically
+and the auto-builders may start recompiling it. The package is now publicly
accessible at <url id="&url-incoming;"> (there is no
such URL for packages in the non-US archive) until it is really installed
in the Debian archive. This happens only once a day, the package
<sect1 id="delayed-incoming">Delayed incoming
<p>
The <file>unchecked</file> directory has a special <file>DELAYED</file>
-subdirectory. It is itself subdivised in nine directories
+subdirectory. It is itself subdivided in nine directories
called <file>1-day</file> to <file>9-day</file>. Packages which are uploaded in
one of those directories will be moved in the real unchecked
directory after the corresponding number of days.
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 conditionned:
+ <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 urgency field's value of the upload. It
+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>
the keyword listed below. This will let you select the mails that
you want to receive.
<p>
-By default you will get :
+By default you will get:
<taglist>
<tag><tt>bts</tt>
<item>
progression in testing, ...).
</taglist>
<p>
-You can also decide to receive some more information :
+You can also decide to receive some more information:
<taglist>
<tag><tt>upload-binary</tt>
<item>
Tells you the keywords that you are accepting. Each mail sent through
the Package Tracking System is associated to a keyword and you receive
only the mails associated to keywords that you are accepting. Here is
- the list of available keywords :
+ the list of available keywords:
<list>
- <item><tt>bts</tt> : mails coming from the Debian Bug Tracking System
- <item><tt>bts-control</tt> : reply to mails sent to
+ <item><tt>bts</tt>: mails coming from the Debian Bug Tracking System
+ <item><tt>bts-control</tt>: reply to mails sent to
<email>control@bugs.debian.org</email>
- <item><tt>summary</tt> : automatic summary mails about the state of a package
- <item><tt>cvs</tt> : notification of cvs commits
- <item><tt>upload-source</tt> : announce of a new source upload that
+ <item><tt>summary</tt>: automatic summary mails about the state of a package
+ <item><tt>cvs</tt>: notification of CVS commits
+ <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)
- <item><tt>katie-other</tt> : other mails from ftpmasters
+ <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")
+ <item><tt>default</tt>: all the other mails (those which aren't "automatic")
</list>
<tag><tt>keyword <srcpackage> [<email>]</tt>
<tt>X-Unsubscribe</tt>.
<p>
Here is an example of added headers for a source upload notification
-on the <package>dpkg</package> package :
+on the <package>dpkg</package> package:
<example>
X-Loop: dpkg@&pts-host;
X-PTS-Package: dpkg
<sect1 id="pts-cvs-commit">Forwarding CVS commits in the PTS
<p>
-If you use a publically accessible CVS repository for maintaining
+If you use a publicly accessible CVS repository for maintaining
your Debian package you may want to forward the commit notification
to the PTS so that the subscribers (possible co-maintainers) can
closely follow the package's evolution.
<p>
-It's very easy to setup. Once your cvs repository generates commit
+It's very easy to setup. Once your CVS repository generates commit
notifications, you just have to make sure it sends a copy of those mails
to <tt><var>srcpackage</var>_cvs@&pts-host;</tt>. Only people who
accepts the <em>cvs</em> keyword will receive the notifications.
to <tt>ftp-master</tt>. Instead, upload the package to
<ftpsite>non-us.debian.org</ftpsite>, placing the files in
&non-us-upload-dir; (again, both <ref id="dupload"> and <ref
-id="dput"> can do this for you if invocated properly). By default,
+id="dput"> can do this for you if invoked properly). By default,
you can use the same account/password that works on
<tt>ftp-master</tt>. If you use anonymous FTP to upload, place the
files into &upload-queue;.
<p>
Bug fixes to unstable by non-maintainers are also acceptable, but only
as a last resort or with permission. The following protocol should
-be respected to do an NMU :
+be respected to do an NMU:
<p>
<list>
<item>
which simply check out and attempt to auto-build packages which need
to be ported. There is also an email interface to the system, which
allows porters to ``check out'' a source package (usually one which
-cannot yet be autobuilt) and work on it.
+cannot yet be auto-built) and work on it.
<p>
<package>buildd</package> is not yet available as a package; however,
most porting efforts are either using it currently or planning to use
<tt>Maintainer:</tt> field, although it can take a few hours after the
upload is done. If you do not expect to upload a new version for a while,
you can use <ref id="pkg-tracking-system"> to get the bug reports. However,
-make sure that the old maintainer is not embarassed by the fact that
+make sure that the old maintainer is not embarrassed by the fact that
he will continue to receive the bugs during that time.
to the good documentation and so on). If the same report comes up
again and again you may ask yourself if the documentation is good
enough or if the program shouldn't detect its misuse in order to
-give an informatory error message. This is an issue that may need
+give an informative error message. This is an issue that may need
to be brought to the upstream author.
<p>
If the bug submitter disagree with your decision to close the bug,
he may reopen it until you find an agreement on how to handle it.
If you don't find any, you may want to tag the bug <tt>wontfix</tt>
to let people know that the bug exists but that it won't be corrected.
-If this situation is inacceptable, you (or the submitter) may want to
+If this situation is unacceptable, you (or the submitter) may want to
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).
the <file>changelog</file>). This is particularly useful if you
are several developers working on the same package.
<item>
-Once a corrected package is availabe in the <em>unstable</em>
+Once a corrected package is available in the <em>unstable</em>
distribution, you can close the bug. This can be done automatically,
read <ref id="upload-bugfix">.
</enumlist>
<file>debian/patches</file> directory and to apply them on the fly at
build time. The package <package>dbs</package> provides an
implementation of such a system, you just have to build-depend on dbs to
-be able to use its functionnalities. The package
+be able to use its functionalities. The package
<package>hello-dbs</package> is a simple example that demonstrates how to
use <package>dbs</package>.
<p>
-Additionnaly, dbs provides facilities to create the patches and to keep
+Additionally, dbs provides facilities to create the patches and to keep
track of what they are for.
<sect1 id="multiple-binary">Multiple binary packages
to provide several flavors of the same software (examples are the
vim-* packages) or to make several small packages instead of a big one
(it's interesting if the user doesn't need all the packages and can thus
-save some diskspace).
+save some disk space).
<p>
The second case can be easily managed by <prgn>dh_install</prgn> (from
<package>debhelper</package>) to move files from the build directory to
<sect1 id="bpp-other-specific-practices">Other specific packages
<p>
-Several subsets of packages have special subpolicies and corresponding
-packaging rules and practices :
+Several subsets of packages have special sub-policies and corresponding
+packaging rules and practices:
<list>
<item>
Perl related packages have a <url name="perl policy" id="&url-perl-policy;">,
<package>libdbd-pg-perl</package> (binary perl module) or
<package>libmldbm-perl</package> (arch independent perl module).
<item>
-Python related packages have their python policy :
+Python related packages have their python policy:
&file-python-policy; (in the python package).
<item>
Emacs related packages have the <url id="&url-emacs-policy;"
Java related packages have their <url id="&url-java-policy;"
name="java policy">.
<item>
-Ocaml related packages have their ocaml policy : &file-ocaml-policy; (in
-the
ocaml package). A good example is the <package>camlzip</package>
+Ocaml related packages have their ocaml policy: &file-ocaml-policy; (in
+the
<package>ocaml</package> package). A good example is the <package>camlzip</package>
source package.
</list>
non-interactive installations in the future.
<p>
Debconf is a great tool but it is often badly used ... many common mistakes
-are listed in the <manref name="debconf-devel" section="8"> manpage.
+are listed in the <manref name="debconf-devel" section="8"> man page.
It is something that you must have read if you decide to use debconf.
<!--
-->
<sect id="misc-advice">
- <heading>Miscellaenous advice</heading>
+ <heading>Miscellaneous advice</heading>
<sect1 id="writing-desc">
<heading>Writing useful descriptions</heading>
<p>
For example, apart from the usual description that you adapt from the
upstream <file>README</file>, you should include the URL of the
-website if there's any. If the package is not yet considered stable
+web site if there's any. If the package is not yet considered stable
by the author, you may also want to warn the user that the
package is not ready for production use.
<p>
Last but not least, since the first user impression is based on
-that description, you should be careful to avoid english
+that description, you should be careful to avoid English
mistakes. Ensure that you spell check it.
-<prgn>ispell</prgn> has a special option (<tt>-g</tt>) for that :
+<prgn>ispell</prgn> has a special option (<tt>-g</tt>) for that:
<example>ispell -d american -g debian/control</example>
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 FTP admins will also have to
+(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
~ianmdlvl / developers-reference.git / commitdiff