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

diff --git a/pkgs.dbk b/pkgs.dbk
index 2acdf5c..4eab6a4 100644
--- 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, 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>
@@ -2294,7 +2337,7 @@ In any case, it is a bad idea to automatically put all team members in the
 a false sense of good maintenance. For the same reason, team members do
 not need to add themselves to the <literal>Uploaders</literal> field just because they are
 uploading the package once, they can do a “Team upload” (see <xref
-linkend="nmu-team-upload"/>). Conversely, it it a bad idea to keep a
+linkend="nmu-team-upload"/>). Conversely, it is a bad idea to keep a
 package with only the mailing list address as a <literal>Maintainer</literal> and no
 <literal>Uploaders</literal>.
 </para>
@@ -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