Add instructions how to mark a non-free package as auto-buildable.

[developers-reference.git] / pkgs.dbk

diff --git a/pkgs.dbk b/pkgs.dbk
index e98b54e47784de104c0e13ed5b8e32b0e3e31215..6846e24c98b53a7ac7735643ad26c7396990a519 100644 (file)
--- a/pkgs.dbk
+++ b/pkgs.dbk
@@ -174,7 +174,7 @@ output a very verbose description of the problem.
 </para>
 <para>
 Normally, a package should <emphasis>not</emphasis> be uploaded if it causes
-lintian to emit errors (they will start with <literal>E</literal>).
+<command>lintian</command> to emit errors (they will start with <literal>E</literal>).
 </para>
 <para>
 For more information on <command>lintian</command>, see <xref
@@ -841,14 +841,22 @@ fixing them themselves, sending security advisories, and maintaining
 <para>
 When you become aware of a security-related bug in a Debian package, whether or
 not you are the maintainer, collect pertinent information about the problem,
-and promptly contact the security team at
-&email-security-team; as soon as possible.  <emphasis
-role="strong">DO NOT UPLOAD</emphasis> any packages for <literal>stable</literal>
-without contacting the team.  Useful information includes, for example:
+and promptly contact the security team, preferedly by filing a ticket in
+their Request Tracker.
+See <ulink url="http://wiki.debian.org/rt.debian.org#SecurityTeam"></ulink>.
+Alternatively you may email &email-security-team;.
+<emphasis role="strong">DO NOT UPLOAD</emphasis> any packages for
+<literal>stable</literal> without contacting the team.  Useful information
+includes, for example:
 </para>
 <itemizedlist>
 <listitem>
 <para>
+Whether or not the bug is already public.
+</para>
+</listitem>
+<listitem>
+<para>
 Which versions of the package are known to be affected by the bug.  Check each
 version that is present in a supported Debian release, as well as
 <literal>testing</literal> and <literal>unstable</literal>.
@@ -1151,12 +1159,13 @@ uploads.
 </listitem>
 <listitem>
 <para>
-Unless the upstream source has been uploaded to <literal>security.debian.org
-</literal> before (by a previous security update), build the upload <emphasis
-role="strong">with full upstream source</emphasis> (<literal>dpkg-buildpackage
--sa</literal>).  If there has been a previous upload to
-<literal>security.debian.org</literal> with the same upstream version, you may
-upload without upstream source (<literal>dpkg-buildpackage -sd</literal>).
+Unless the upstream source has been uploaded to
+<literal>security.debian.org</literal> before (by a previous security update),
+build the upload <emphasis role="strong">with full upstream source</emphasis>
+(<literal>dpkg-buildpackage -sa</literal>).  If there has been a previous
+upload to <literal>security.debian.org</literal> with the same upstream
+version, you may upload without upstream source (<literal>dpkg-buildpackage
+-sd</literal>).
 </para>
 </listitem>
 <listitem>
@@ -1278,7 +1287,7 @@ short summary of the reason for the removal request.
 <replaceable>[architecture list]</replaceable> is optional and only needed
 if the removal request only applies to some architectures, not all. Note
 that the <command>reportbug</command> will create a title conforming
-to these rules when you use it to report a bug against the 
+to these rules when you use it to report a bug against the
 <literal>ftp.debian.org</literal> pseudo-package.
 </para>
 
@@ -1862,6 +1871,35 @@ role="package">ftp.debian.org</systemitem>.
 </para>
 </section>
 
+<section id="non-free-buildd">
+<title>Marking non-free packages as auto-buildable</title>
+<para>
+By default packages from non-free are not built by the autobuilder
+network (mostly because the license of the packages could disapprove).
+To enable a package to be build you need to perform the following
+steps:
+</para>
+<orderedlist numeration="arabic">
+<listitem>
+<para>
+Check whether it is legally allowed and technically possible
+to auto-build the package ;
+</para>
+</listitem>
+<listitem>
+<para>
+Add <literal>XS-Autobuild: yes</literal> into the header part
+of <filename>debian/control</filename> ;
+</para>
+</listitem>
+<listitem>
+<para>
+Send an email to &email-nonfree-release; and explain why the
+package can legitimately and technically be auto-built.
+</para>
+</listitem>
+</orderedlist>
+</section>
 </section>
 
 <section id="nmu">
@@ -1946,6 +1984,11 @@ to the maintainer to react (for example, by uploading to the
 <itemizedlist>
 <listitem>
 <para>
+Upload fixing only release-critical bugs older than 7 days, with no maintainer activity on the bug for 7 days and no indication that a fix is in progress: 0 days
+</para>
+</listitem>
+<listitem>
+<para>
 Upload fixing only release-critical bugs older than 7 days: 2 days
 </para>
 </listitem>
@@ -2392,7 +2435,7 @@ more information about the usual problems which may be causing such troubles.
 </para>
 <para>
 Sometimes, some packages never enter <literal>testing</literal> because the
-set of inter-relationship is too complicated and cannot be sorted out by the
+set of interrelationship is too complicated and cannot be sorted out by the
 scripts.  See below for details.
 </para>
 <para>
@@ -2596,11 +2639,8 @@ tests include this package.  Hints from the release team are processed
 before or after this main run, depending on the exact type.
 </para>
 <para>
-If you want to see more details, you can look it up on
-<filename>merkel:/org/&ftp-debian-org;/testing/update_out/</filename> (or
-in <filename>merkel:~aba/testing/update_out</filename> to see a setup with
-a smaller packages file).  Via web, it's at <ulink
-url="http://&ftp-master-host;/testing/update_out_code/"></ulink>.
+If you want to see more details, you can look it up on <ulink
+url="http://&ftp-master-host;/testing/update_output/"></ulink>.
 </para>
 <para>
 The hints are available via <ulink