speak there of issues that are discussed in
&email-debian-private;. There's another channel for this
purpose, it's called <literal>#debian-private</literal> and it's protected by
-a key. This key is available in the archives of debian-private in
-<filename>master.debian.org:&file-debian-private-archive;</filename>,
-just <command>zgrep</command> for <literal>#debian-private</literal> in all
-the files.
+a key. This key is available at
+<filename>master.debian.org:&file-debian-private-key;</filename>.
</para>
<para>
There are other additional channels dedicated to specific subjects.
<title>The ftp-master server</title>
<para>
The <literal>&ftp-master-host;</literal> server holds the canonical copy of
-the Debian archive. Generally, package uploads go to this server; see
-<xref linkend="upload"/>.
+the Debian archive. Generally, package uploaded to &ftp-upload-host;
+end up on this server, see <xref linkend="upload"/>.
</para>
<para>
It is restricted; a mirror is available on <literal>merkel</literal>.
If you need to use a Version Control System for any of your Debian work,
you can use one the existing repositories hosted on Alioth or you can
request a new project and ask for the VCS repository of your choice.
-Alioth supports CVS (alioth.debian.org), Subversion
+Alioth supports CVS (cvs.alioth.debian.org/cvs.debian.org), Subversion
(svn.debian.org), Arch (tla/baz, both on arch.debian.org), Bazaar
(bzr.debian.org), Darcs (darcs.debian.org), Mercurial (hg.debian.org) and Git
(git.debian.org). Checkout <ulink url="&url-alioth-pkg;" /> if you plan
to maintain packages in a VCS repository. See <xref linkend="alioth"/> for
information on the services provided by Alioth.
</para>
-<para>
-Historically, Debian first used <literal>cvs.debian.org</literal> to host
-CVS repositories. But that service is deprecated in favor of Alioth.
-Only a few projects are still using it.
-</para>
</section>
<section id="dchroot">
<title>The Debian archive</title>
<para>
The &debian-formal; distribution consists of a lot of packages
-(<filename>.deb</filename>'s, currently around
-&number-of-pkgs;) and a few additional files (such as
-documentation and installation disk images).
+(currently around &number-of-pkgs; source packages) and a few additional
+files (such as documentation and installation disk images).
</para>
<para>
Here is an example directory tree of a complete Debian archive:
<para>
In the first days, the Linux kernel was only available for Intel i386 (or
greater) platforms, and so was Debian. But as Linux became more and more
-popular, the kernel was ported to other architectures, too.
+popular, the kernel was ported to other architectures and Debian started
+to support them. And as if supporting so much hardware was not enough,
+Debian decided to build some ports based on other Unix kernels, like
+<literal>hurd</literal> and <literal>kfreebsd</literal>.
</para>
<para>
-The Linux 2.0 kernel supports Intel x86, DEC Alpha, SPARC, Motorola 680x0 (like
-Atari, Amiga and Macintoshes), MIPS, and PowerPC. The Linux 2.2 kernel
-supports even more architectures, including ARM and UltraSPARC. Since Linux
-supports these platforms, Debian decided that it should, too. Therefore,
-Debian has ports underway; in fact, we also have ports underway to non-Linux
-kernels. Aside from <literal>i386</literal> (our name for Intel x86), there
-is <literal>m68k</literal>, <literal>alpha</literal>,
-<literal>powerpc</literal>, <literal>sparc</literal>,
-<literal>hurd-i386</literal>, <literal>arm</literal>,
-<literal>ia64</literal>, <literal>hppa</literal>,
-<literal>s390</literal>, <literal>mips</literal>,
-<literal>mipsel</literal> and <literal>sh</literal> as of this writing.
-</para>
-<para>
-&debian-formal; 1.3 is only available as <literal>i386</literal>. Debian
+&debian-formal; 1.3 was only available as <literal>i386</literal>. Debian
2.0 shipped for <literal>i386</literal> and <literal>m68k</literal>
-architectures. Debian 2.1 ships for the <literal>i386</literal>,
+architectures. Debian 2.1 shipped for the <literal>i386</literal>,
<literal>m68k</literal>, <literal>alpha</literal>, and
-<literal>sparc</literal> architectures. Debian 2.2 added support for the
-<literal>powerpc</literal> and <literal>arm</literal> architectures.
-Debian 3.0 added support of five new architectures: <literal>ia64</literal>,
-<literal>hppa</literal>, <literal>s390</literal>, <literal>mips</literal>
-and <literal>mipsel</literal>.
+<literal>sparc</literal> architectures. Since then Debian has grown hugely.
+Debian 5 supports a total of twelve architectures: <literal>alpha</literal>,
+<literal>amd64</literal>, <literal>arm</literal>,
+<literal>armel</literal>, <literal>hppa</literal>,
+<literal>i386</literal>, <literal>ia64</literal>, <literal>mips</literal>,
+<literal>mipsel</literal>, <literal>powerpc</literal>,
+<literal>s390</literal>, <literal>sparc</literal>.
</para>
<para>
Information for developers and users about the specific ports are available at
<literal>binary</literal> packages.
</para>
<para>
-Source packages consist of either two or three files: a
-<filename>.dsc</filename> file, and either a <filename>.tar.gz</filename> file
-or both an <filename>.orig.tar.gz</filename> and a
-<filename>.diff.gz</filename> file.
+Depending on the format of the source package, it will consist
+of one or more files in addition to the mandatory <filename>.dsc</filename>
+file:
+<itemizedlist>
+<listitem><para>with format “1.0”, it has either a <filename>.tar.gz</filename>
+file or both an <filename>.orig.tar.gz</filename> and a
+<filename>.diff.gz</filename> file;</para></listitem>
+<listitem><para>with format “3.0 (quilt)”, it has a mandatory
+<filename>.orig.tar.{gz,bz2,lzma}</filename> upstream tarball,
+multiple optional <filename>.orig-<replaceable>component</replaceable>.tar.{gz,bz2,lzma}</filename>
+additional upstream tarballs and a mandatory
+<filename>debian.tar.{gz,bz2,lzma}</filename> debian
+tarball;</para></listitem>
+<listitem><para>with format “3.0 (native)”, it has only
+a single <filename>.tar.{gz,bz2,lzma}</filename> tarball.</para></listitem>
+</itemizedlist>
</para>
<para>
-If a package is developed specially for Debian and is not distributed outside
-of Debian, there is just one <filename>.tar.gz</filename> file which contains
-the sources of the program. If a package is distributed elsewhere too, the
-<filename>.orig.tar.gz</filename> file stores the so-called <literal>upstream
-source code</literal>, that is the source code that's distributed by the
-<literal>upstream maintainer</literal> (often the author of the software).
-In this case, the <filename>.diff.gz</filename> contains the changes made by
-the Debian maintainer.
+If a package is developed specially for Debian and is not distributed
+outside of Debian, there is just one
+<filename>.tar.{gz,bz2,lzma}</filename> file which contains the sources of
+the program, it's called a “native” source package. If a package is
+distributed elsewhere too, the
+<filename>.orig.tar.{gz,bz2,lzma}</filename> file stores the so-called
+<literal>upstream source code</literal>, that is the source code that's
+distributed by the <literal>upstream maintainer</literal> (often the
+author of the software). In this case, the <filename>.diff.gz</filename>
+or the <filename>debian.tar.{gz,bz2,lzma}</filename> contains the changes
+made by the Debian maintainer.
</para>
<para>
The <filename>.dsc</filename> file lists all the files in the source package
</para>
<para>
The <link linkend="testing">testing</link> 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 new packages
+automatically by taking packages from <literal>unstable</literal> if they
+satisfy certain criteria. Those criteria should ensure a good quality for
+packages within <literal>testing</literal>. The update to <literal>testing
+</literal> is launched twice each day, right after the new packages
have been installed. See <xref linkend="testing"/> .
</para>
<para>
<section id="s4.6.4.2">
<title>More information about the testing distribution</title>
<para>
-Packages are usually installed into the `testing' distribution after they have
-undergone some degree of testing in unstable.
+Packages are usually installed into the <literal>testing</literal> distribution
+after they have undergone some degree of testing in <literal>unstable</literal>.
</para>
<para>
For more details, please see the <link linkend="testing">information about
<title>Experimental</title>
<para>
The <literal>experimental</literal> distribution is a special distribution.
-It is not a full distribution in the same sense as `stable' and `unstable' are.
+It is not a full distribution in the same sense as <literal>stable</literal>,
+<literal>testing</literal> and <literal>unstable</literal> are.
Instead, it is meant to be a temporary staging area for highly experimental
software where there's a good chance that the software could break your system,
or software that's just too unstable even for the <literal>unstable</literal>
space on <literal>people.debian.org</literal>.
</para>
<para>
-When uploading to unstable a package which had bugs fixed in experimental,
-please consider using the option <literal>-v</literal> to
-<command>dpkg-buildpackage</command> to finally get them closed.
+When uploading to <literal>unstable</literal> a package which had bugs fixed
+in <literal>experimental</literal>, please consider using the option
+<literal>-v</literal> to <command>dpkg-buildpackage</command> to finally get
+them closed.
</para>
</section>
<title>Release code names</title>
<para>
Every released Debian distribution has a <literal>code name</literal>: Debian
-1.1 is called `buzz'; Debian 1.2, `rex'; Debian 1.3, `bo'; Debian 2.0, `hamm';
-Debian 2.1, `slink'; Debian 2.2, `potato'; Debian 3.0, `woody'; Debian 3.1,
-sarge; Debian 4.0, etch. There is also a ``pseudo-distribution'', called
-`sid', which is the current `unstable' distribution; since packages are moved
-from `unstable' to `testing' as they approach stability, `sid' itself is never
-released. As well as the usual contents of a Debian distribution, `sid'
-contains packages for architectures which are not yet officially supported or
-released by Debian. These architectures are planned to be integrated into the
-mainstream distribution at some future date.
+1.1 is called <literal>buzz</literal>; Debian 1.2, <literal>rex</literal>;
+Debian 1.3, <literal>bo</literal>; Debian 2.0, <literal>hamm</literal>;
+Debian 2.1, <literal>slink</literal>; Debian 2.2, <literal>potato</literal>;
+Debian 3.0, <literal>woody</literal>; Debian 3.1, <literal>sarge</literal>;
+Debian 4.0, <literal>etch</literal>; Debian 5.0, <literal>lenny</literal>
+and the next release will be called <literal>squeeze</literal>.
+There is also a ``pseudo-distribution'', called
+<literal>sid</literal>, which is the current <literal>unstable</literal>
+distribution; since packages are moved from <literal>unstable</literal> to
+<literal>testing</literal> as they approach stability, <literal>sid</literal>
+itself is never released. As well as the usual contents of a Debian
+distribution, <literal>sid</literal> contains packages for architectures which
+are not yet officially supported or released by Debian. These architectures
+are planned to be integrated into the mainstream distribution at some future
+date.
</para>
<para>
Since Debian has an open development model (i.e., everyone can participate and
-follow the development) even the `unstable' and `testing' distributions are
-distributed to the Internet through the Debian FTP and HTTP server network.
-Thus, if we had called the directory which contains the release candidate
-version `testing', then we would have to rename it to `stable' when the version
+follow the development) even the <literal>unstable</literal> and <literal>
+testing</literal> distributions are distributed to the Internet through the
+Debian FTP and HTTP server network. Thus, if we had called the directory which
+contains the release candidate version <literal>testing</literal>, then we
+would have to rename it to <literal>stable</literal> when the version
is released, which would cause all FTP mirrors to re-retrieve the whole
distribution (which is quite large).
</para>
The archive maintenance software will also send the OpenPGP/GnuPG signed
<filename>.changes</filename> file that you uploaded to the appropriate mailing
lists. If a package is released with the <literal>Distribution:</literal> set
-to `stable', the announcement is sent to
+to <literal>stable</literal>, the announcement is sent to
&email-debian-changes;. If a package is released with
-<literal>Distribution:</literal> set to `unstable' or `experimental', the
-announcement will be posted to &email-debian-devel-changes;
-instead.
+<literal>Distribution:</literal> set to <literal>unstable</literal> or
+<literal>experimental</literal>, the announcement will be posted to
+&email-debian-devel-changes; instead.
</para>
<para>
Though ftp-master is restricted, a copy of the installation is available to all
<programlisting>
$delay = ($ENV{DELAY} || 7);
$cfg{'delayed'} = {
- fqdn => "&ftp-master-host;",
+ fqdn => "&ftp-upload-host;",
login => "yourdebianlogin",
incoming => "/org/&ftp-debian-org;/incoming/DELAYED/$delay-day/",
dinstall_runs => 1,
</para>
</section>
-<section id="madison">
-<title>The <command>madison</command> utility</title>
+<section id="dak-ls">
+<title>The <command>dak ls</command> utility</title>
<para>
-<command>madison</command> is a command-line utility that is available on
-<literal>&ftp-master-host;</literal>, and on the mirror on
-<literal>&ftp-master-mirror;</literal>. It uses a single argument corresponding
-to a package name. In result it displays which version of the package is
-available for each architecture and distribution combination. An example will
-explain it better.
+<command>dak ls</command> is part of the dak suite of tools, listing
+available package versions for all known distributions and architectures.
+The <command>dak</command> tool is available on <literal>&ftp-master-host;
+</literal>, and on the mirror on <literal>&ftp-master-mirror;</literal>.
+It uses a single argument corresponding to a package name. An example will
+explain it better:
</para>
<screen>
-$ madison libdbd-mysql-perl
-libdbd-mysql-perl | 1.2202-4 | stable | source, alpha, arm, i386, m68k, powerpc, sparc
-libdbd-mysql-perl | 1.2216-2 | testing | source, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc
-libdbd-mysql-perl | 1.2216-2.0.1 | testing | alpha
-libdbd-mysql-perl | 1.2219-1 | unstable | source, alpha, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc
+$ dak ls evince
+evince | 0.1.5-2sarge1 | oldstable | source, alpha, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc
+evince | 0.4.0-5 | etch-m68k | source, m68k
+evince | 0.4.0-5 | stable | source, alpha, amd64, arm, hppa, i386, ia64, mips, mipsel, powerpc, s390, sparc
+evince | 2.20.2-1 | testing | source
+evince | 2.20.2-1+b1 | testing | alpha, amd64, arm, armel, hppa, i386, ia64, mips, mipsel, powerpc, s390, sparc
+evince | 2.22.2-1 | unstable | source, alpha, amd64, arm, armel, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc
</screen>
<para>
In this example, you can see that the version in <literal>unstable</literal>
differs from the version in <literal>testing</literal> and that there has
-been a binary-only NMU of the package for the alpha architecture. Each version
-of the package has been recompiled on most of the architectures.
+been a binary-only NMU of the package for all architectures. Each version
+of the package has been recompiled on all architectures.
</para>
</section>
</listitem>
</varlistentry>
<varlistentry>
+<term><literal>buildd</literal></term>
+<listitem>
+<para>
+Build failures notifications sent by the network of build daemons, they contain
+a pointer to the build logs for analysis.
+</para>
+</listitem>
+</varlistentry>
+<varlistentry>
<term><literal>default</literal></term>
<listitem>
<para>
<term><literal>summary</literal></term>
<listitem>
<para>
-Regular summary emails about the package's status. Currently, only progression
-in <literal>testing</literal> is sent.
+Regular summary emails about the package's status, including progression
+into <literal>testing</literal>,
+<ulink url="&url-dehs;">DEHS</ulink> notifications of
+new upstream versions, and a notification if the package is removed or
+orphaned.
</para>
</listitem>
</varlistentry>
</listitem>
<listitem>
<para>
+<literal>buildd</literal>: build failures notifications from build daemons
+</para>
+</listitem>
+<listitem>
+<para>
<literal>default</literal>: all the other mails (those which aren't automatic)
</para>
</listitem>
</section>
<section id="alioth">
-<title>Debian's GForge installation: Alioth</title>
+<title>Debian's FusionForge installation: Alioth</title>
<para>
Alioth is a Debian service based on a slightly modified version of the
-GForge software (which evolved from SourceForge). This software offers
+FusionForge software (which evolved from SourceForge and GForge). This software offers
developers access to easy-to-use tools such as bug trackers, patch
manager, project/task managers, file hosting services, mailing lists, CVS
repositories etc. All these tools are managed via a web interface.
url="http://&lists-host;/debian-devel-announce/2002/10/msg00018.html"></ulink>.
</para>
</section>
+<section id="gandi">
+<title>Gandi.net Hosting Discount</title>
+<para>
+As of November 2008, Gandi.net offers a discount rate on their VPS
+hosting for Debian Developers. See
+<ulink url="http://&lists-host;/debian-devel-announce/2008/11/msg00004.html"></ulink>.
+</para>
+</section>
</section>
~ianmdlvl / developers-reference.git / blobdiff