X-Git-Url: http://www.chiark.greenend.org.uk/ucgi/~ianmdlvl/git?a=blobdiff_plain;f=pkgs.dbk;h=4eab6a4c06ee8a5a06e00428098f7894d3b8efc7;hb=d56885ae301bd74a864e1f111e7d0564bd177a06;hp=38256bfe2cd3b863ca1c524d883ed59d105c846f;hpb=7347b8fe6bde56036f349496304bca972f7035ee;p=developers-reference.git

diff --git a/pkgs.dbk b/pkgs.dbk
index 38256bf..4eab6a4 100644
--- a/pkgs.dbk
+++ b/pkgs.dbk
@@ -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, preferably by filing a ticket in
+their Request Tracker.
+See <ulink url="http://wiki.debian.org/rt.debian.org#Security_Team"></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>
@@ -1237,7 +1246,7 @@ chapter gives guidelines on what to do in these cases.
 <title>Moving packages</title>
 <para>
 Sometimes a package will change its section.  For instance, a package from the
-`non-free' section might be GPL'd in a later version, in which case the package
+<literal>non-free</literal> section might be GPL'd in a later version, in which case the package
 should be moved to `main' or `contrib'.<footnote><para> See the <ulink
 url="&url-debian-policy;">Debian Policy Manual</ulink> for
 guidelines on what section a package belongs in.  </para> </footnote>
@@ -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 the <literal>non-free</literal> section 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>