complete the translation of chinese/devel/testing.wml

1 files changed, 103 insertions, 139 deletions

diff --git a/chinese/devel/testing.wml b/chinese/devel/testing.wml
index 3f26defcca8..53694b5a05d 100644
--- a/chinese/devel/testing.wml
+++ b/chinese/devel/testing.wml
@@ -114,118 +114,91 @@ gzipped</a>］有用的地方：它提供了提示（尽管很简洁），提示
 href="$(DOC)/manuals/developers-reference/pkgs.html#details">\
 开发者参考手册</a>）。</p>
 
-<h3><q>Why is it sometimes hard to get <kbd>Architecture: all</kbd> packages
-into <q>testing</q>?</q></h3>
-
-<p>If the <kbd>Architecture: all</kbd> package is to be installed, it must
-be possible to satisfy its dependencies on <strong>all</strong>
-architectures. If it depends on certain packages which only compile on a
-limited set of Debian's architectures, then it can't do that.</p>
-
-<p>However, for the time being, <q>testing</q> will ignore <kbd>Architecture:
-all</kbd> packages' installability on non-i386 architectures. (<q>It's a
-gross hack and I'm not really happy to have made it, but there you go.</q>
-&mdash;aj)</p>
-
-<h3><q>My package is stalled because it's out of date on some architecture.
-What do I do?</q></h3>
-
-<p>Check the status of your package in the
-<a href="https://buildd.debian.org/build.php">build log database</a>.
-If the package doesn't build, it will be marked as <em>failed</em>;
-investigate the build logs and fix any of the problems that are caused
-by your package's sources.</p>
-
-<p>If you happen to notice that some architectures have built the new
-version of your package, but it isn't showing up in <q>testing</q> scripts output,
-then you just have to be a bit more patient until the respective buildd
-maintainer uploads the files to the Debian archive.</p>
-
-<p>If you notice that some architectures haven't built your new version of
-the package at all, despite the fact you uploaded a fix for an earlier
-failure, the reason is probably that it's marked as waiting for dependencies
-(Dep-Wait). You can also see the list of these so-called
-<a href="https://buildd.debian.org/stats/">wanna-build states</a> to make
-sure.</p>
-
-<p>These problems usually get fixed eventually, but if you've been waiting
-for a longer period of time (say, two weeks or more), notify the respective
-port buildd maintainer if such an address is documented on the
-<a href="$(HOME)/ports/">port web page</a>, or the mailing list of the
-port.</p>
-
-<p>If you have explicitly dropped the architecture from the Architecture list
-in the control file, and the package has been built for that architecture
-before, you will need to request that the old binary package for this
-architecture be removed from the archive before your package can transition to
-testing.  You need to file a bug against <q>ftp.debian.org</q> requesting removal of
-the dropped architecture's packages from the unstable archive.  Generally the
-relevant porting list should be informed as a matter of courtesy.</p>
-
-<h3><q>Are there any exceptions? I'm sure <tt>acmefoo</tt> has just made
-it into <q>testing</q> despite not satisfying all of the requirements.</q></h3>
-
-<p>The release manager can override the rules in two ways:</p>
+<h3><q>为什么有时难以将 <kbd>Architecture: all</kbd> 软件包移动到 <q>testing</q>？</q></h3>
+
+<p>如果要安装 <kbd>Architecture: all</kbd> 软件包，则必须能够满足它在<strong>所有</strong>\
+架构的依赖。如果它依赖于某些只能在 Debian 的特定体系结构上编译的软件包，那么它就不能移动\
+到 <q>testing</q>。</p>
+
+<p>不过，暂时而言，<q>testing</q> 会忽略 <kbd>Architecture: all</kbd> 软件包在非 i386 \
+体系结构上的可安装性。（<q>这是一个非常 hack 的做法，我真的对此感到不高兴，但是您当然\
+可以这样做。</q>&mdash;aj）</p>
+
+<h3><q>因为我的软件包在某些体系结构上已过时，所以它停住了。我该怎么办？</q></h3>
+
+<p>在<a href="https://buildd.debian.org/build.php">构建日志数据库</a>中检查您的软件包的\
+状态。如果该软件包没有被构建出来，那它将被标记为 <em>failed</em>；调查构建日志并修复由您的\
+软件包源代码引起的任何问题。</p>
+
+<p>如果您偶然发现某些体系结构已经构建了您的软件包的新版本，但是未在 <q>testing</q> 脚本\
+的输出中显示出来，那么您只需要耐心一点，等各个 buildd 维护者将文件上传到 Debian 软件\
+档案库。</p>
+
+<p>如果您注意到尽管您已上传了针对较早失败的修复代码，但某些体系架构还是没有构建您的软件包\
+的新版本，那么原因可能是它被标记为等待依赖项（Dep-Wait）。您还可以查看这些被称为 \
+<a href="https://buildd.debian.org/stats/">wanna-build 状态</a>的构建列表来确认。</p>
+
+<p>这些问题通常最终会得到解决，但是如果您等待了较长的时间（例如两周或更长时间），请通知\
+在<a href="$(HOME)/ports/">移植平台网页</a>上列出了地址的对应移植 buildd 维护者或\
+移植平台的邮件列表。</p>
+
+<p>如果您在 control 文件的体系架构列表中明确排除了某个架构，并且之前已为该架构构建了\
+您的软件包，那么您需要请求在您的软件包能过渡到 testing 前从软件档案库中删除该架构的\
+旧二进制软件包。您需要对 <q>ftp.debian.org</q> 提交一个错误报告，要求从 unstable 软件\
+档案库中删除已排除的体系结构的软件包。一般来说，出于礼貌您应当在报告中告知相关的移植列表。</p>
+
+<h3><q>有什么例外吗？我确定尽管 <tt>acmefoo</tt> 不满足所有要求，但它已进入 <q>testing</q>。</q></h3>
+
+<p>发布管理员在两种情形下可以覆盖规则：</p>
 
 <ul>
-  <li>They can decide that the breakage caused by the installation of a new
-      library will make things better rather than worse, and let it go in
-      along with its flotilla of dependents.</li>
-  <li>They can also manually remove packages from <q>testing</q> that would be
-      broken, so that new stuff can be installed.</li>
+  <li>他们可以断定，由于安装新依赖库而导致的损坏将使事情变得更好而不是更糟，因此让其与\
+  其依赖的软件包一起进入。</li>
+  <li>他们也可以从 <q>testing</q> 中手动删除可能会损坏的软件包，以便可以安装新软件包。</li>
 </ul>
 
-<h3><q>Can you provide a real, non-trivial example?</q></h3>
-
-<p>Here's one: when the source package <tt>apache</tt> is installed into
-<q>testing</q>, along with its binary packages <tt>apache</tt>,
-<tt>apache-common</tt>, <tt>apache-dev</tt> and <tt>apache-doc</tt>, the
-old version is removed.</p>
-
-<p>However, all Apache module packages depend on <code>apache-common (&gt;=
-<var>something</var>), apache-common (&lt;&lt; <var>something</var>)</code>,
-so this change breaks all of those dependencies. Consequently, all Apache
-modules need to be recompiled against the new version of Apache in order
-for <q>testing</q> to be updated.</p>
-
-<p>Let's elaborate on this a bit further: after all of the modules have been
-updated in unstable to work with a new Apache, the <q>testing</q> scripts try
-<tt>apache-common</tt> and find out that it breaks all the Apache modules
-because they have <code>Depends: apache-common (&lt;&lt; <var>the current
-version</var>)</code>, and then try <tt>libapache-<var>foo</var></tt> to find
-out that it doesn't install because it has <code>Depends: apache-common (&gt;=
-<var>the new version</var>)</code>.</p>
-
-<p>However, later they'll apply a different logic (sometimes prompted by a
-manual intervention): they'll ignore the fact <tt>apache-common</tt> breaks
-stuff, and keep going with things that work; if it still doesn't work after
-we've done everything we can, too bad, but maybe it <strong>will</strong>
-work. Later they'll try all the random <tt>libapache-<var>foo</var></tt>
-packages and see that they indeed work.</p>
-
-<p>After everything's been tried, they check how many packages have been
-broken, work out if that's better or worse than what there was originally
-and either accept everything or forget about it. You'll see this in
-<tt>update_output.txt</tt> on <q><code>recur:</code></q> lines.</p>
-
-<p>For example:</p>
+<h3><q>你能否提供一个真实且重大的例子？</q></h3>
+
+<p>这有一个例子：当源码包 <tt>apache</tt> 与其二进制软件包 <tt>apache</tt>、\
+<tt>apache-common</tt>、<tt>apache-dev</tt> 和 <tt>apache-doc</tt> 一起安装到 \
+<q>testing</q> 时，旧版本将被删除。</p>
+
+<p>但是，由于所有 Apache 模块软件包都依赖于 <code>apache-common (&gt;=
+<var>something</var>)、apache-common (&lt;&lt; <var>something</var>)</code>，所以这个\
+更改将破坏所有这些依赖关系。因此，需要为新版本的 Apache 重新编译所有 Apache 模块，以便 \
+<q>testing</q> 能够更新。</p>
+
+<p>让我们再详细说明一下：在所有模块都更新到 unstable 以与新 Apache 一起工作后，\
+<q>testing</q> 脚本尝试移动 apache-common，并发现由于模块有 <code>Depends: apache-common
+(&lt;&lt; <var>the current version</var>)</code>，所以它破坏了所有 Apache 模块的依赖关系，\
+接着尝试移动 <tt>libapache-<var>foo</var></tt> 并发现由于它有 <code>Depends: apache-common
+(&gt;=<var>the new version</var>)</code> 所以不能被安装。</p>
+
+<p>不过，接下来他们将使用不同的逻辑（有时需要人工干预）：他们将忽略 <tt>apache-common</tt> \
+损坏东西的事实，并继续进行可行的工作；如果在我们竭尽所能后它仍然无法正常工作，那就太糟糕了，\
+但也许它<strong>能</strong>正常工作。稍后，他们将尝试所有随机的 \
+<tt>libapache-<var>foo</var></tt> 软件包，并发现它们确实可行。</p>
+
+<p>在尝试了所有方法之后，他们将检查损坏了多少个软件包，计算它是比原始软件包好还是更坏，\
+然后接受或忽略所有更新。您能在 <tt>update_output.txt</tt> 中的 <q><code>recur:</code></q> \
+行看到此内容。</p>
+
+<p>例如：</p>
 
 <pre>
          recur: [<var>foo</var> <var>bar</var>] <var>baz</var>
 </pre>
 
-<p>basically says <q>having already found that <var>foo</var> and
-<var>bar</var> make things better, I'm now trying <var>baz</var> to
-see what happens, even though that breaks things</q>. The lines of
-<tt>update_output.txt</tt> that start with <q><code>accepted</code></q> indicate
-things that appear to make things better, and <q><code>skipped</code></q> lines make
-things worse.</p>
+<p>基本上是说，<q>已经发现 <var>foo</var> 和 <var>bar</var> 使事情变得更好，我现在正在\
+尝试 <var>baz</var> 看看会发生什么，即使那会损坏东西</q>。在 <tt>update_output.txt</tt> \
+中以 <q><code>accepted</code></q> 为开头的行表示使事情变得更好的东西，\
+<q><code>skipped</code></q> 行表示使事情变得更坏的东西。</p>
 
-<h3><q>The <tt>update_output.txt</tt> file is completely unreadable!</q></h3>
+<h3><q><tt>update_output.txt</tt> 文件是完全不可读的！</q></h3>
 
-<p>That is not a question. ;-)</p>
+<p>这不是问题。;-)</p>
 
-<p>Let's take an example:</p>
+<p>让我们举个例子：</p>
 
 <pre>
  skipped: cln (0) (150+4)
@@ -233,55 +206,46 @@ things worse.</p>
      * i386: ginac-cint, libginac-dev
 </pre>
 
-<p>This means that if <tt>cln</tt> goes into <q>testing</q>, <tt>ginac-cint</tt>
-and <tt>libginac-dev</tt> become uninstallable in <q>testing</q> on i386.
-Note that the architectures are checked in alphabetical order and only the
-problems on the first architecture with problems are shown &mdash; that's why
-the alpha architecture is shown so often.</p>
-
-<p>The <q>got</q> line includes the number of problems in <q>testing</q> on the
-different architectures (until the first architecture where a problem is
-found &mdash; see above). The <q>i-45</q> means that if <tt>cln</tt> would go into
-<q>testing</q>, there would be 45 uninstallable packages on i386. Some of the
-entries above and below <tt>cln</tt> show there were 43 uninstallable
-packages in <q>testing</q> on i386 at the time.</p>
-
-<p>The <q>skipped: cln (0) (150+4)</q> line means that there are still 150
-packages to go through after this package until this check of all packages
-is completed, and that 4 packages have been found already that won't be
-planned to be upgraded because they would break dependencies. The <q>(0)</q> is
-irrelevant, you can safely ignore it.</p>
-
-<p>Note that there are several checks of all packages in one <q>testing</q>
-script run.</p>
-
-<p><em>Jules Bean initially assembled the frequently asked questions and
-answers.</em></p>
+<p>这意味着，如果 <tt>cln</tt> 进入 <q>testing</q>，那 <tt>ginac-cint</tt> 和 \
+<tt>libginac-dev</tt> 会成为 i386 架构的 <q>testing</q> 中无法安装的软件包。请注意，\
+脚本按字母顺序检查体系架构，并且仅显示第一个有问题的体系架构中的问题 &mdash; 这就是\
+为何如此频繁地显示 alpha 架构的原因。</p>
+
+<p><q>got</q> 行包括在不同体系架构（到第一个发现问题的体系架构 &mdash; 见上文）上的 \
+<q>testing</q> 的问题数量。<q>i-45</q> 意味着如果 <tt>cln</tt> 能进入 <q>testing</q>，\
+那在 i386 上会出现 45 个无法安装的软件包。<tt>cln</tt> 上方和下方的一些条目显示：\
+此时在 i386 上的 <q>testing</q> 有 43 个无法安装的软件包。</p>
+
+<p><q>skipped: cln (0) (150+4)</q> 行意味着在完成对所有软件包的检查之前，仍有 150 个\
+软件包需要通过检查，并且已经找到了 4 个不打算更新的软件包，因为它们会破坏依赖。<q>(0)</q> \
+是无关紧要的，您可以放心地忽略它。</p>
+
+<p>请注意，在一个 <q>testing</q> 脚本运行中对所有软件包进行了多次检查。</p>
+
+<p><em>Jules Bean 最初组织了常问问题和解答。</em></p>
 # Created: Sat Dec  8 12:44:29 GMT 2001
 
-<h2>Additional information</h2>
+<h2>附加信息</h2>
 
-<p>The following pages provide additional information about the current state
-of testing and the migration of packages from unstable to testing:</p>
+<p>以下页面提供了有关当前 testing 的状态以及软件包从 unstable 到 testing 的迁移的附加信息：</p>
 
 <ul>
-<li>Statistics on binary packages that are out of date for
+<li>过时二进制软件包的统计：
 <a href="https://release.debian.org/britney/testing_outdate.txt">testing</a>,
 <a href="https://release.debian.org/britney/stable_outdate.txt">stable</a>
-<li>Dependency problems in
+<li>查看依赖问题：
 <a href="https://qa.debian.org/debcheck.php?list=INDEX&amp;dist=testing">testing</a>,
 <a href="https://qa.debian.org/debcheck.php?list=INDEX&amp;dist=stable">stable</a>
-<li>Nice <a href="https://release.debian.org/migration/">web front-end</a> to
-help you find out why packages are being held out of testing
+<li>不错的 <a href="https://release.debian.org/migration/">web 前端</a>，可帮助您找出\
+软件包无法移动到 testing 的原因
 </ul>
 
-<p>You might be interested in reading an older
-<a href="https://lists.debian.org/debian-devel-0008/msg00906.html">explanation
-email</a>. Its only major flaw is that it doesn't take the package pool
-into account, because that was implemented by James Troup after it was
-written.</p>
+<p>您可能有兴趣阅读旧的<a 
+href="https://lists.debian.org/debian-devel-0008/msg00906.html">解释电子邮件</a>。\
+它唯一的主要缺点是其没有考虑到软件包池，因为软件包池是由 James Troup 在该邮件被编写\
+之后实现的。</p>
 
-<p>The testing code is available from
-<a href="https://release.debian.org/britney/update_out_code/">ftp-master</a>.</p>
+<p>testing 代码可从 \
+<a href="https://release.debian.org/britney/update_out_code/">ftp-master</a> 取得。</p>
 
-<p><em>Anthony Towns takes credit for the implementation of testing.</em></p>
+<p><em>Anthony Towns 因实现 testing 而获得赞誉。</em></p>