<!entity % commondata SYSTEM "common.ent" > %commondata;
<!-- CVS revision of this document -->
- <!entity cvs-rev "$Revision: 1.104 $">
+ <!entity cvs-rev "$Revision: 1.105 $">
<!-- if you are translating this document, please notate the CVS
revision of the developers reference here -->
<!--
id="&url-gpl;" name="the GNU website">. You can also obtain it by
writing to the &fsf-addr;.
- <toc detail="sect2">
+ <toc detail="sect1">
<chapt id="scope">Scope of This Document
<p>
<p>
Be very careful with your private keys. Do not place them on any
public servers or multiuser machines, such as
-<tt>master.debian.org</tt>. Back your keys up; keep a copy offline.
+<tt>&master-host;</tt>. Back your keys up; keep a copy offline.
Read the documentation that comes with your software; read the <url
id="&url-pgp-faq;" name="PGP FAQ">.
<p>
&email-debian-private; unless it is really necessary. Moreover, do
<em>not</em> forward email from that list to anyone. Archives of this
list are not available on the web for obvious reasons, but you can see
-them using your shell account on <tt>master.debian.org</tt> and looking
+them using your shell account on <tt>&master-host;</tt> and looking
in the <file>~debian/archive/debian-private</file> directory.
<p>
&email-debian-email; is a special mailing list used as a grab-bag
<sect1 id="servers-master">The master server
<p>
-<tt>master.debian.org</tt> is the canonical location for the Bug
-Tracking System (BTS). 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
+<tt>&master-host;</tt> is the canonical location for the Bug Tracking
+System (BTS). 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>master.debian.org</tt>.
+All Debian developers have accounts on <tt>&master-host;</tt>.
Please take care to protect your password to this machine. Try to
avoid login or upload methods which send passwords over the Internet
in the clear.
<p>
-If you find a problem with <tt>master.debian.org</tt> such as disk
+If you find a problem with <tt>&master-host;</tt> such as disk
full, suspicious activity, or whatever, send an email to
&email-debian-admin;.
<sect id="archive">The Debian archive
<p>
The &debian-formal; distribution consists of a lot of packages
-(<tt>.deb</tt>'s, currently around &number-of-pkgs;) and a few
+(<file>.deb</file>'s, currently around &number-of-pkgs;) and a few
additional files (such documentation and installation disk images).
<p>
Here is an example directory tree of a complete Debian archive:
&sample-dist-dirtree;
<p>
As you can see, the top-level directory contains two directories,
-<tt>dists/</tt> and <tt>pool/</tt>. The latter is a “pool” in which the
+<file>dists/</file> and <file>pool/</file>. The latter is a “pool” in which the
packages actually are, and which is handled by the archive maintenance
database and the accompanying programs. The former contains the
distributions, <em>stable</em>, <em>testing</em> and <em>unstable</em>.
Each of those distribution directories is divided in equivalent
subdirectories purpose of which is equal, so we will only explain how it
-looks in stable. The <tt>Packages</tt> and <tt>Sources</tt> files in the
-distribution subdirectories can reference files in the <tt>pool/</tt>
+looks in stable. The <file>Packages</file> and <file>Sources</file> files in the
+distribution subdirectories can reference files in the <file>pool/</file>
directory.
<p>
-<tt>dists/stable</tt> contains three directories, namely <em>main</em>,
-<em>contrib</em>, and <em>non-free</em>.
+<file>dists/stable</file> contains three directories, namely <file>main</file>,
+<file>contrib</file>, and <file>non-free</file>.
<p>
In each of the areas, there is a directory for the source packages
-(<tt>source</tt>) and a directory for each supported architecture
-(<tt>binary-i386</tt>, <tt>binary-m68k</tt>, etc.).
+(<file>source</file>) and a directory for each supported architecture
+(<file>binary-i386</file>, <file>binary-m68k</file>, etc.).
<p>
-The <em>main</em> area contains additional directories which holds
+The <file>main</file> area contains additional directories which holds
the disk images and some essential pieces of documentation required
for installing the Debian distribution on a specific architecture
-(<tt>disks-i386</tt>, <tt>disks-m68k</tt>, etc.).
+(<file>disks-i386</file>, <file>disks-m68k</file>, etc.).
<sect1>Sections
There are two types of Debian packages, namely <em>source</em> and
<em>binary</em> packages.
<p>
-Source packages consist of either two or three files: a <tt>.dsc</tt>
-file, and either a <tt>.tar.gz</tt> file or both an
-<tt>.orig.tar.gz</tt> and a <tt>.diff.gz</tt> file.
+Source packages consist of either two or three files: a <file>.dsc</file>
+file, and either a <file>.tar.gz</file> file or both an
+<file>.orig.tar.gz</file> and a <file>.diff.gz</file> file.
<p>
If a package is developed specially for Debian and is not distributed
-outside of Debian, there is just one <tt>.tar.gz</tt> file which
+outside of Debian, there is just one <file>.tar.gz</file> file which
contains the sources of the program. If a package is distributed
-elsewhere too, the <tt>.orig.tar.gz</tt> file stores the so-called
+elsewhere too, the <file>.orig.tar.gz</file> file stores the so-called
<em>upstream source code</em>, that is the source code that's
distributed from the <em>upstream maintainer</em> (often the author of
-the software). In this case, the <tt>.diff.gz</tt> contains the
+the software). In this case, the <file>.diff.gz</file> contains the
changes made by the Debian maintainer.
<p>
-The <tt>.dsc</tt> lists all the files in the source package together
+The <file>.dsc</file> file lists all the files in the source package together
with checksums (<prgn>md5sums</prgn>) and some additional info about
the package (maintainer, version, etc.).
<p>
The directory system described in the previous chapter is itself
contained within <em>distribution directories</em>. Each
-distribution is actually contained in the <tt>pool</tt> directory in the
+distribution is actually contained in the <file>pool</file> directory in the
top-level of the Debian archive itself.
<p>
To summarize, the Debian archive has a root directory within an FTP
server. For instance, at the mirror site,
<ftpsite>ftp.us.debian.org</ftpsite>, the Debian archive itself is
contained in <ftppath>/debian</ftppath>, which is a common location
-(another is <tt>/pub/debian</tt>).
+(another is <file>/pub/debian</file>).
<p>
A distribution is comprised of Debian source and binary packages, and the
-respective <tt>Sources</tt> and <tt>Packages</tt> index files, containing
+respective <file>Sources</file> and <file>Packages</file> index files, containing
the header information from all those packages. The former are kept in the
-<tt>pool/</tt> directory, while the latter are kept in the <tt>dists/</tt>
-directory of the archive (because of backwards compatibility).
+<file>pool/</file> directory, while the latter are kept in the <file>dists/</file>
+directory of the archive (for backwards compatibility).
<sect2 id="sec-dists">Stable, testing, and unstable
<p>
There are always distributions called <em>stable</em> (residing in
-<tt>dists/stable</tt>), one called <em>testing</em> (residing in
-<tt>dists/testing</tt>), and one called <em>unstable</em> (residing in
-<tt>dists/unstable</tt>). This reflects the development process of the
+<file>dists/stable</file>), one called <em>testing</em> (residing in
+<file>dists/testing</file>), and one called <em>unstable</em> (residing in
+<file>dists/unstable</file>). This reflects the development process of the
Debian project.
<p>
Active development is done in the <em>unstable</em> distribution
updates are tested very carefully and have to be introduced into the
archive individually to reduce the risk of introducing new bugs. You
can find proposed additions to <em>stable</em> in the
-<tt>proposed-updates</tt> directory. Those packages in
-<tt>proposed-updates</tt> that pass muster are periodically moved as a
+<file>proposed-updates</file> directory. Those packages in
+<file>proposed-updates</file> that pass muster are periodically moved as a
batch into the stable distribution and the revision level of the
stable distribution is incremented (e.g., ‘3.0’ becomes
‘3.0r1’, ‘2.2r4’ becomes ‘2.2r5’, and
directories and scripts that are installed both on <tt>&ftp-master-host;</tt>
and <tt>&non-us-host;</tt>.
<p>
-Packages are uploaded by all the maintainers into an <tt>unchecked</tt>
+Packages are uploaded by all the maintainers into an <file>unchecked</file>
directory. This directory is scanned every 15 minutes by the katie script
that verifies the integrity of the package and the cryptographic
signature. If the package is considered ready to be installed, it
-is moved into an <tt>accepted</tt> directory. If it is the first upload of
-the package then it is moved in a <tt>new</tt> directory waiting an
+is moved into an <file>accepted</file> directory. If it is the first upload of
+the package then it is moved in a <file>new</file> directory waiting an
approval of the ftpmasters. If the package contains files to be installed
-"by-hand" is is moved in the <tt>byhand</tt> directory waiting a manual
+"by-hand" is is moved in the <file>byhand</file> directory waiting a manual
installation by the ftpmasters. Otherwise, if any error has been detected,
-the package is refused and is moved in the <tt>reject</tt> directory.
+the package is refused and is moved in the <file>reject</file> directory.
<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
in the Debian archive. This happens only once a day, the package
is then removed from incoming and installed in the pool along with all
the other packages. Once all the other updates (generating new
-<tt>Packages</tt> and <tt>Sources</tt> index files for example) have been
+<file>Packages</file> and <file>Sources</file> index files for example) have been
made, a special script is called to ask all the primary mirrors to update
themselves.
<p>
-All debian developers have write access to the <tt>unchecked</tt>
+All debian developers have write access to the <file>unchecked</file>
directory in order to upload their packages, they also have that access
-to the <tt>reject</tt> directory in order to remove their bad uploads
-or to move some files back in the <tt>unchecked</tt> directory. But
+to the <file>reject</file> directory in order to remove their bad uploads
+or to move some files back in the <file>unchecked</file> directory. But
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
<p>
-The <tt>unchecked</tt> directory has a special <tt>DELAYED</tt>
+The <file>unchecked</file> directory has a special <file>DELAYED</file>
subdirectory. It is itself subdivised in nine directories
-called <tt>1-day</tt> to <tt>9-day</tt>. Packages which are uploaded in
+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.
This is done by a script that is run each day and which moves the
packages between the directories. Those which are in "1-day" are
-installed in <tt>unchecked</tt> while the others are moved in the
-adjacent directory (for example, a package in <tt>5-day</tt> will
-be moved in <tt>4-day</tt>). This feature is particularly useful
+installed in <file>unchecked</file> while the others are moved in the
+adjacent directory (for example, a package in <file>5-day</file> will
+be moved in <file>4-day</file>). This feature is particularly useful
for people who are doing non-maintainer uploads. Instead of
waiting before uploading a NMU, it is uploaded as soon as it is
-ready but in one of those <tt>DELAYED/x-day</tt> directories.
+ready but in one of those <file>DELAYED/<var>x</var>-day</file> directories.
That leaves the corresponding number of days to the maintainer
in order to react and upload himself another fix if he is not
completely satisfied with the NMU. Alternatively he can remove
the NMU by himself.
<p>
The use of that delayed feature can be simplified with a bit
-of integration with your upload tool, the following addition to
-the <prgn>dupload</prgn> configuration file should be
-considered.
- <p>
+of integration with your upload tool. For instance, if you use
+<prgn>dupload</prgn> (see <ref id="dupload">), you can add this
+snippet to your configuration file:
<example>
$delay = ($ENV{DELAY} || 7);
$cfg{'delayed'} = {
- fqdn => "ftp-master.debian.org",
+ fqdn => "&ftp-master-host;",
login => "yourdebianlogin",
incoming => "/org/ftp.debian.org/incoming/DELAYED/$delay-day/",
visibleuser => "yourdebianlogin",
method => "scpb"
};
</example>
- <p>
-<prgn>dupload</prgn> can now be used to easily upload a package
-in one of the delayed directories :
+Once you've made that change, <prgn>dupload</prgn> can be used to
+easily upload a package in one of the delayed directories:
<example>DELAY=5 dupload --to delayed <changes-file></example>
<sect id="testing-scripts">
<package>devscripts</package> package. It can be easily put in a crontab
to keep someone informed of the progression of his packages in testing.
<p>
-The <tt>update_excuses</tt> file does not always give the precise reason
+The <file>update_excuses</file> file does not always give the precise reason
why the package is refused, one may have to find it by himself by looking
what would break with the inclusion of the package. The <url
id="&url-testing-faq;" name="testing FAQ"> gives some more information
<sect1 id="pkg-info-web">On the web
<p>
Each package has several dedicated web pages that contains many
-informations. First <tt>http://&packages-host;/<package></tt>
-will let you discover a presentation of each version of the package
-available in the various distributions. It includes its description,
-the dependencies and some links to download the package.
+informations. <tt>http://&packages-host;/<var>package-name</var></tt>
+will display each version of the package
+available in the various distributions. The per-version detailed
+information includes the package description,
+the dependencies and links to download the package.
<p>
The bug tracking system sorts the bugs by package, you can
watch the bugs of each package at
-<tt>http://&bugs-host;/<package></tt>.
+<tt>http://&bugs-host;/<var>package-name</var></tt>.
- <sect1 id="madison">The madison utility
+ <sect1 id="madison">The <prgn>madison</prgn> utility
<p>
<prgn>madison</prgn> is a command-line utility that is available
on both <tt>&ftp-master-host;</tt> and <tt>&non-us-host;</tt>. It
<p>
Assuming no one else is already working on your prospective package,
you must then submit a bug report (<ref id="submit-bug">) against the
-pseudo package <tt>wnpp</tt>
+pseudo-package <package>wnpp</package>
describing your plan to create a new package, including, but not
limiting yourself to, a description of the package, the license of the
prospective package and the current URL where it can be downloaded
For more information on <prgn>lintian</prgn>, see <ref id="lintian">.
<item>
Downgrade the package to the previous version (if one exists) — this
-tests the <tt>postrm</tt> and <tt>prerm</tt> scripts.
+tests the <file>postrm</file> and <file>prerm</file> scripts.
<item>
Remove the package, then reinstall it.
</list>
<sect1>Generating the changes file
<p>
When a package is uploaded to the Debian FTP archive, it must be
-accompanied by a <tt>.changes</tt> file, which gives directions to the
+accompanied by a <file>.changes</file> file, which gives directions to the
archive maintainers for its handling. This is usually generated by
<prgn>dpkg-genchanges</prgn> during the normal package build process.
<p>
<p>
The first time a version is uploaded which corresponds to a particular
upstream version, the original source tar file should be uploaded and
-included in the <tt>.changes</tt> file. Subsequently, this very same
-tar file should be used to build the new diffs and <tt>.dsc</tt>
+included in the <file>.changes</file> file. Subsequently, this very same
+tar file should be used to build the new diffs and <file>.dsc</file>
files, and will not need to be re-uploaded.
<p>
By default, <prgn>dpkg-genchanges</prgn> and
<p>
If no original source is included in the upload, the original
source tar-file used by <prgn>dpkg-source</prgn> when constructing the
-<tt>.dsc</tt> file and diff to be uploaded <em>must</em> be
+<file>.dsc</file> file and diff to be uploaded <em>must</em> be
byte-for-byte identical with the one already in the archive.
<sect3 id="upload-stable">Uploading to <em>stable</em>
<p>
Uploading to <em>stable</em> means that the package will be placed into the
-<tt>proposed-updates</tt> directory of the Debian archive for further
+<file>proposed-updates</file> directory of the Debian archive for further
testing before it is actually included in <em>stable</em>.
<p>
Extra care should be taken when uploading to <em>stable</em>. Basically, a
<sect2 id="upload-ftp-master">Uploading to <tt>ftp-master</tt>
<p>
To upload a package, you need a personal account on
-<ftpsite>ftp-master.debian.org</ftpsite>, which you should have as an
+<ftpsite>&ftp-master-host;</ftpsite>, which you should have as an
official maintainer. If you use <prgn>scp</prgn> or <prgn>rsync</prgn>
-to transfer the files, place them into <tt>&us-upload-dir;</tt>;
+to transfer the files, place them into &us-upload-dir;;
if you use anonymous FTP to upload, place them into
-<ftppath>/pub/UploadQueue/</ftppath>. Please note that you should transfer
+&upload-queue;. Please note that you should transfer
the changes file last. Otherwise, your upload may be rejected because the
archive maintenance software will parse the changes file and see that not
all files have been uploaded. If you don't want to bother with transferring
the changes file last, you can simply copy your files to a temporary
directory on <tt>ftp-master</tt> and then move them to
-<tt>&us-upload-dir;</tt>.
+&us-upload-dir;.
<p>
<em>Note:</em> Do not upload to <tt>ftp-master</tt> cryptographic
packages which belong to <em>contrib</em> or <em>non-free</em>. Uploads of
id="upload-non-us">). Furthermore packages containing code that is
patent-restricted by the United States government can not be uploaded to
<tt>ftp-master</tt>; depending on the case they may still be uploaded to
-<tt>non-US/non-free</tt> (it's in non-free because of distribution issues
+<file>non-US/non-free</file> (it's in non-free because of distribution issues
and not because of the license of the software). If you can't upload it to
<tt>ftp-master</tt>, then neither can you upload it to the overseas upload
queues on <tt>chiark</tt> or <tt>erlangen</tt>. If you are not sure
whether U.S. patent controls or cryptographic controls apply to your
package, post a message to &email-debian-devel; and ask.
<p>
-You may also find the Debian packages <package>dupload</package> or
-<package>dput</package> useful
-when uploading packages. These handy programs are distributed with
-defaults for uploading via <prgn>ftp</prgn> to <tt>ftp-master</tt>,
-<tt>chiark</tt>, and <tt>erlangen</tt>. They can also be configured to
-use <prgn>ssh</prgn> or <prgn>rsync</prgn>. See <manref name="dupload"
-section="1">, <manref name="dupload" section="5"> and <manref name="dput"
-section="1"> for more information.
+You may also find the Debian packages <ref id="dupload"> or
+<ref id="dput"> useful
+when uploading packages. These handy programs help automate the
+process of uploading packages into Debian.
<p>
-After uploading your package, you can check how the archive maintenance
-software will process it by running <prgn>dinstall</prgn> on your changes
-file: <example>dinstall -n foo.changes</example>
+After uploading your package, you can check how the archive
+maintenance software will process it by running <prgn>dinstall</prgn>
+on your changes file: <example>dinstall -n foo.changes</example>.
+Note that <prgn>dput</prgn> can do this for you automatically.
<sect2 id="upload-non-us">Uploading to <tt>non-US</tt> (pandora)
<p>
As discussed above, export controlled software should not be uploaded
to <tt>ftp-master</tt>. Instead, upload the package to
<ftpsite>non-us.debian.org</ftpsite>, placing the files in
-<tt>&non-us-upload-dir;</tt> (both <ref id="dupload"> and <ref
-id="dput"> can be used also, with the right invocation). By default,
+&non-us-upload-dir; (again, both <ref id="dupload"> and <ref
+id="dput"> can do this for you if invocated 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 <ftppath>/pub/UploadQueue/</ftppath>.
+files into &upload-queue;.
<p>
You can check your upload the same way it's done on <tt>ftp-master</tt>,
with:
<sect2>Uploads via <tt>chiark</tt>
<p>
If you have a slow network connection to <tt>ftp-master</tt>, there are
-alternatives. One is to upload files to <tt>Incoming</tt> via a
+alternatives. One is to upload files to <file>Incoming</file> via a
upload queue in Europe on <tt>chiark</tt>. For details connect to
<url id="&url-chiark-readme;">.
<p>
via anonymous FTP to <url id="&url-upload-erlangen;">.
<p>
The upload must be a complete Debian upload, as you would put it into
-<tt>ftp-master</tt>'s <tt>Incoming</tt>, i.e., a <tt>.changes</tt> files
-along with the other files mentioned in the <tt>.changes</tt>. The
-queue daemon also checks that the <tt>.changes</tt> is correctly
+<tt>ftp-master</tt>'s <file>Incoming</file>, i.e., a <file>.changes</file> files
+along with the other files mentioned in the <file>.changes</file>. The
+queue daemon also checks that the <file>.changes</file> is correctly
signed with GnuPG or OpenPGP by a Debian developer, so that no bogus files can find
their way to <tt>ftp-master</tt> via this queue. Please also make sure that
-the <tt>Maintainer</tt> field in the <tt>.changes</tt> contains
+the <tt>Maintainer</tt> field in the <file>.changes</file> contains
<em>your</em> e-mail address. The address found there is used for all
replies, just as on <tt>ftp-master</tt>.
<p>
maintenance software when it runs (usually once a day). You just need to use
a recent <package>dpkg-dev</package> (>= 1.4.1.2). The mail generated by
the archive maintenance software will contain the OpenPGP/GnuPG signed
-<tt>.changes</tt> files that you uploaded with your package.
+<file>.changes</file> files that you uploaded with your package.
Previously, <prgn>dupload</prgn> used to send those announcements, so
please make sure that you configured your <prgn>dupload</prgn> not to
send those announcements (check its documentation and look for
Double check that your patch doesn't have any unexpected side effects.
Make sure your patch is as small and as non-disruptive as it can be.
<item>
-Upload your package to incoming in <tt>DELAYED/7-day</tt> (cf.
+Upload your package to incoming in <file>DELAYED/7-day</file> (cf.
<ref id="delayed-incoming">), send the final patch to the maintainer via
the BTS, and explain him that he has 7 days to react if he wants to cancel
the NMU.
Make sure your source package is correct. Do <tt>dpkg-source -x
<var>package</var>.dsc</tt> to make sure your source package unpacks
properly. Then, in there, try building your package from scratch with
-<tt>dpkg-buildpackage</tt>.
+<prgn>dpkg-buildpackage</prgn>.
<item>
Make sure you don't ship your source package with the
<file>debian/files</file> or <file>debian/substvars</file> files.
was removed because <tt>libfoo13</tt> supersedes it) or closed if the
software is simply no more part of Debian.
- <sect2>Removing packages from <tt>Incoming</tt>
+ <sect2>Removing packages from <file>Incoming</file>
<p>
-In the past, it was possible to remove packages from <tt>incoming</tt>.
-With the introduction of the New Incoming system this is no longer
+In the past, it was possible to remove packages from <file>incoming</file>.
+However, with the introduction of the new incoming system, this is no longer
possible. Instead, you have to upload a new revision of your package with
a higher version as the package you want to replace. Both versions will be
installed in the archive but only the higher version will actually be
won't indicate the bug number).
<p>
If the package is especially crucial to Debian, you should instead submit
-a bug against <tt>wnpp</tt> and title it <tt>RFA: <var>package</var> --
+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
<url id="&url-bts;" name="Debian bug tracking system (BTS)"> for your
packages. The BTS contains all the open bugs against your packages.
You can check them by browsing this page:
-<tt>http://&bugs-host;/yourlogin@debian.org</tt>.
+<tt>http://&bugs-host;/<var>yourlogin</var>@debian.org</tt>.
<p>
Maintainers interact with the BTS via email addresses at
-<tt>bugs.debian.org</tt>. Documentation on available commands can be
+<tt>&bugs-host;</tt>. Documentation on available commands can be
found at <url id="&url-bts;">, or, if you have installed the
<package>doc-debian</package> package, you can look at the local files
&file-bts-docs;.
<file>changelog</file>.
<p>
If you want to close bugs the old fashioned, manual way, it is usually
-sufficient to mail the <tt>.changes</tt> file to
+sufficient to mail the <file>.changes</file> file to
<email>XXX-done@bugs.debian.org</email>, where <var>XXX</var> is your
bug number.
with the bug 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
-<tt>http://&bugs-host;/your-email@your-isp.com</tt>.
+<tt>http://&bugs-host;/<your-email>@your-isp.com</tt>.
<sect1 id="submit-many-bugs">Reporting lots of bugs at once
<p>
simply remind someone that a new upstream version is available
and that you need it.
<p>
-Whatever the reason, it is a pain to lookup the email address of the
-maintainer of the package that you are interested in. Fortunately, you
-can use a simple email alias : <tt><package>@&packages-host;</tt>.
-<tt><package></tt> can be the name of a source or a binary package.
+Looking up the email address of the maintainer for the package can be
+distracting. Fortunately, there is a simple email alias,
+<tt><package>@&packages-host;</tt>, which provides a way to
+email the maintainer, whatever their individual email address (or
+addresses) may be. Replace <tt><package></tt> with the name of
+a source or a binary package.
<p>
You may also be interested by contacting the persons who are
subscribed to a given source package via <ref id="pkg-tracking-system">.
-You can do so by using the <tt><package>@&pts-host;</tt>
+You can do so by using the <tt><package-name>@&pts-host;</tt>
email address.
the package meets minimum Debian standards. That implies that you
must build and test the package on your own system before uploading.
<p>
-You can not simply upload a binary <tt>.deb</tt> from the sponsoree. In
+You can not simply upload a binary <file>.deb</file> from the sponsoree. In
theory, you should only ask only for the diff file, and the location of the
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 he hasn't
-altered the upstream files in the <tt>.orig.tar.gz</tt> file that he's
+altered the upstream files in the <file>.orig.tar.gz</file> file that he's
providing.
<p>
Do not be afraid to write the sponsoree back and point out changes
<p>
Once the package meets Debian standards, build the package with
<example>dpkg-buildpackage -us -uc</example> and sign it
-with <example>debsign -m your@email.com <var>changes file</var></example>
+with <example>debsign -m <your-email-addr> <changes-file></example>
before uploading it to the incoming directory.
<p>
-The Maintainer field of the <tt>control</tt> file and the
-<tt>changelog</tt> should list the person who did the packaging, i.e. the
+The Maintainer field of the <file>control</file> file and the
+<file>changelog</file> should list the person who did the packaging, i.e. the
sponsoree. The sponsoree will therefore get all the BTS mail about the
package.
<p>
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 <tt>apt-cache show <var>package_name</var></tt>.
+command <tt>apt-cache show <package-name></tt>.
<sect id="dpkg-dev">
thing as <package>dupload</package>, but in a different way. It has
some features over <package>dupload</package>, such as the ability to
check the GnuPG signature and checksums before uploading, and the
-possibility of running <tt>dinstall</tt> in dry-run mode after the
+possibility of running <prgn>dinstall</prgn> in dry-run mode after the
upload.
<package>debget</package> is a package containing a convenient script
which can be helpful in downloading files from the Debian archive.
You can use it to download source packages, for instance (although
-<tt>apt-get source <var>package</var></tt> does pretty much the same
+<tt>apt-get source <package-name></tt> does pretty much the same
thing).
~ianmdlvl / developers-reference.git / commitdiff