path: root/russian/Bugs/Developer.wml

#use wml::debian::template title="Debian BTS — информация для разработчика" NOHEADER=yes NOCOPYRIGHT=true
#include "$(ENGLISHDIR)/Bugs/pkgreport-opts.inc"
#use wml::debian::translation-check translation="40a57e26c62893be7c80d82f1772999f68d51179" maintainer="Lev Lamberov"

<h1>Информация по использованию системы отслеживания ошибок для сопровождающих
пакетов и разбирающихся с ошибками</h1>

<p>Сначала сообщение об ошибке, которое отправил пользователь,
отправляется как обычное почтовое сообщение на адрес <code>submit@bugs.debian.org</code>, сообщение должно содержать
строку <code>Package</code> (дополнительную информацию см. в <a href="Reporting">инструкции по отправке отчётов об
ошибках</a>). Здесь ему присваивается номер,
затем происходит отправка подтверждения о его
получении пользователю, после чего оно пересылается в список
<code>debian-bugs-dist</code>. Если строка
<code>Package</code> содержит имя пакета, и для этого пакета известен сопровождающий, то
ему также будет отправлена копия этого сообщения.</p>

<p>Строка <code>Subject</code> будет содержать добавление вида
<code>Bug#</code><var>nnn</var><code>:</code>, а поле <code>Reply-To</code>
будет включать как отправителя сообщения, так и адрес
<var>nnn</var><code>@bugs.debian.org</code>.</p>

<ul class="toc">
  <li><a href="#closing">Как закрыть сообщение об ошибке</a></li>
  <li><a href="#followup">Последующие сообщения</a></li>
  <li><a href="#severities">Уровни важности</a></li>
  <li><a href="#tags">Метки в сообщениях об ошибках</a></li>
  <li><a href="#forward">Запись о том, что сообщение об ошибке было перенаправлено</a></li>
  <li><a href="#owner">Изменение ответственного за исправление</a></li>
  <li><a href="#maintincorrect">Неправильно указанные сопровождающие пакетов</a></li>
  <li><a href="#requestserv">Переоткрытие, переназначение и управление ошибками</a></li>
  <li><a href="#subscribe">Подписка на сообщения об ошибках</a></li>
  <li><a href="#subjectscan">Более или менее устаревшие возможности</a></li>
  <li><a href="#x-debian-pr">Устаревшая возможность <code>X-Debian-PR: quiet</code></a></li>
</ul>


<h2><a name="closing">Как закрыть сообщение об ошибке</a></h2>

<p>Сообщения об ошибках Debian должны быть закрыты после исправления
проблемы. Проблемы в пакетах могут считаться исправленными только после
того, как пакет, в котором ошибка исправлена, попадает в архив Debian.</p>

<p>Обычно закрывать сообщение об ошибке должен тот, кто послал
сообщение, или сопровождающий(ие) соответствующего пакета. Есть
исключения из этого правила, например, если в сообщении об ошибке
пакет не указан или указан общий псевдопакет. Также сообщение об
ошибке может быть закрыто любым участником, если эта ошибка касается
<strong>осиротевшего</strong> пакета, или если сопровождающий пакет
забыл закрыть это сообщение об ошибке. Очень важно указать версию, в
которой ошибка была исправлена. Если есть сомнения, не закрывайте
ошибку, а сначала попросите совета в списке рассылки debian-devel.</p>

<p>Сообщения об ошибках должны закрываться путём отправки письма по
адресу <var>nnn</var><code>-done@bugs.debian.org</code>. Тело сообщения
должно содержать объяснение того, как исправлена ошибка.</p>

<p>При работе с сообщениями об ошибках, полученными от системы отслеживания
ошибок, для закрытия ошибки достаточно нажать кнопку Ответить (Reply) в своей
почтовой программе, а затем в поле <code>Кому</code>(To) поставить
адрес <var>nnn</var><code>-done@bugs.debian.org</code> вместо
<var>nnn</var><code>@bugs.debian.org</code>
(адрес <var>nnn</var><code>-close</code> является псевдонимом
адреса <var>nnn</var><code>-done</code>).</P>

<p>Когда вы закрываете ошибку, где применимо, проставляйте строку
<code>Version</code> в <a href="Reporting#pseudoheader">псевдозаголовке</a>
вашего сообщения, чтобы система отслеживания ошибок знала, какой из выпусков
пакета содержит исправление.</p>

<p>Человек, закрывший ошибку, человек, который отправил сообщение об этой
ошибке, и список рассылки <code>debian-bugs-closed</code> будут извещены
об изменении состояния ошибки. Отправителю сообщения и в список рассылки
также будет направлено содержимое сообщения, посланного по адресу
<var>nnn</var><code>-done</code>.</p>


<h2><a name="followup">Последующие сообщения</a></h2>

<p>После пересылки сообщения об ошибке, в поле <code>Reply-To</code> системой
отслеживания ошибок будут включены адрес отправителя и адрес ошибки
(<var>nnn</var><code>@bugs.debian.org</code>). Пожалуйста, имейте в виду, что это
два разных адреса.</p>

<p>
Любой разработчик, желающий ответить на сообщение об ошибке, просто
отвечает на сообщение, не меняя заголовок <code>Reply-To</code>. Это
<strong>не приведёт</strong> к закрытию ошибки.

<p><em>Не используйте</em> <q>ответить всем</q> (reply to all) или <q>followup</q>
в вашей почтовой программе, если вы не хотите исправить список
получателей вручную. В частности, смотрите, чтобы вы не отправляли последующие
сообщения на адрес <code>submit@bugs.debian.org</code>.</p>

<p>
Для того чтобы сообщения попали в систему отслеживания ошибок, они могут
быть отправлены на следующие адреса:
</p>

<ul>
<li>
<var>nnn</var><code>@bugs.debian.org</code> — такие сообщения также высылаются
сопровождающему пакета и пересылаются на адрес <code>debian-bugs-dist</code>,
но <strong>не</strong> тому, кто прислал отчёт об ошибке;
</li>
<li>
<var>nnn</var><code>-submitter@bugs.debian.org</code> — эти сообщения также высылаются
тому, кто прислал отчёт об ошибке, и пересылаются на адрес <code>debian-bugs-dist</code>,
но <strong>не</strong> сопровождающему пакета;
</li>
<li>
<var>nnn</var><code>-maintonly@bugs.debian.org</code> — эти сообщения высылаются только
сопровождающему пакета, <strong>не</strong> тому, кто прислал отчёт об ошибке, и
не на адрес<code>debian-bugs-dist</code>;
</li>
<li>
<var>nnn</var><code>-quiet@bugs.debian.org</code> — эти сообщения лишь
добавляются в систему отслеживания ошибок (как и все приведенные выше) и
<strong>не</strong> высылаются больше никому.
</li>
</ul>

<p>Более подробно о том, как с помощью заголовков сообщения подавить
отправку подтверждений или отправить по какому-то адресу копию сообщения
об ошибке, см. <a href="Reporting">инструкцию по составлению сообщений
об ошибках</a>.</p>


<h2><a name="severities">Уровни важности</a></h2>

<p>Система отслеживания ошибок записывает уровень важности каждого сообщения
об ошибке. По умолчанию этот уровень имеет значение <code>normal</code>, но
его можно перекрыть, явно указав уровень важности в строке <code>Severity</code>
в псевдозаголовке при отправке сообщения (см.
<a href="Reporting#pseudoheader">инструкции по созданию сообщений об ошибках</a>),
или использовав команду <code>severity</code>
<a href="#requestserv">сервера управления запросами</a>.</p>

<p>Уровни важности могут принимать следующие значения:</p>

<dl>
<dt><code>critical</code></dt>
<dd>когда ошибка делает нерабочим несвязанное друг с другом программное
обеспечение (или даже всю систему), или вызывает серьёзные потери данных,
или создаёт дыру в безопасности системы при установке пакета.</dd>

<dt><code>grave</code></dt>
<dd>когда ошибка ставит под вопрос возможность использования пакета или
большей его части, или приводит к потере данных, или создаёт дыру в
безопасности, которая открывает доступ к учётным записям пользователей,
использующих пакет.</dd>

<dt><code>serious</code></dt>
<dd>когда ошибка представляет собой <a
href="$(DOC)/debian-policy/">важное нарушение политики
Debian</a> (грубо говоря, когда нарушены директивы <q>must</q> или <q>required</q>) или,
по мнению сопровождающего пакета или человека, ответственного за выпуск в целом, не позволяет
включить этот пакет в выпуск дистрибутива.</dd>

<dt><code>important</code></dt>
<dd>когда ошибка сильно сказывается на возможности использования пакета,
но не делает его полностью непригодным.</dd>

<dt><code>normal</code></dt>
<dd>значение по умолчанию, которое применимо к большинству ошибок.</dd>

<dt><code>minor</code></dt>
<dd>когда ошибка не представляет проблемы при использовании пакета и
легко исправима.</dd>

<dt><code>wishlist</code></dt>
<dd>для любых запросов о тех или иных возможностях, а также для любых
ошибок, которые очень трудно исправить из серьёзных технических соображений.</dd>
</dl>

<p>Определённые уровни важности рассматриваются как
<em><a href="https://bugs.debian.org/release-critical/">блокирующие выпуск</a></em>,
что означает, что ошибка окажет влияние на возможность включения пакета в стабильный
выпуск Debian. На данный момент это уровни <strong>critical</strong>,
<strong>grave</strong> и <strong>serious</strong>. Полное описание правил
установки этих уровней важности см. в списке <a
href="https://release.debian.org/testing/rc_policy.txt">блокирующих выпуск ошибок
для следующей версии дистрибутива</a>.</p>

<h2><a name="tags">Метки в сообщениях об ошибках</a></h2>

<p>Каждая ошибка может иметь несколько меток из списка ниже.
Эти метки отображаются на странице списка ошибок пакета, а также в полном журнале ошибки.
</p>

<p>Метки могут быть установлены путём включения строки <code>Tags</code> в
псевдозаголовке при отправке сообщения об ошибке (см.
<a href="Reporting#pseudoheader">инструкции по созданию сообщений об ошибках</a>),
или при использовании команды <code>tags</code>
<a href="#requestserv">сервера управления запросами</a>. Метки могут
разделяться запятыми, пробелами или и теми, и другими.</p>

<p>В настоящий момент метки могут принимать следующие значения: <bts_tags>. Дополнительная
информация о метках:</p>

<dl>

<dt><code>patch</code></dt>
 <dd>Когда в журнал ошибок включена заплата или какой-либо другой простой
 способ исправления ошибки. Если это заплата, но она не исправляет
 ошибку адекватно или создаёт другие проблемы, эту метку использовать
 нельзя.</dd>

<dt><code>wontfix</code></dt>
 <dd>Когда ошибка неисправима. Такое возможно, потому что, например, нужно
 выбирать между двумя взаимоисключающими способами исправления, но сопровождающий
 пакета и отправитель сообщения об ошибке не могут сойтись во мнении о
 том, какой способ выбрать; или потому что изменение поведения вызовет другие,
 более серьёзные проблемы для остальных; или по другим причинам.</dd>

<dt><code>moreinfo</code></dt>
 <dd>Когда ошибка не может быть идентифицирована, пока отправитель сообщения
 не предоставит больше информации. Такая ошибка будет закрыта, если
 отправитель не предоставит достаточную информацию в ближайшие (около месяца)
 сроки. Обычно такое происходит с сообщениями об ошибках, которые имеют
 содержание типа: <q>Это не работает</q>. Что не работает?</dd>

<dt><code>unreproducible</code></dt>
 <dd>Когда ошибка не может быть воспроизведена в системе сопровождающего пакета.
 В таких случаях для диагностирования наличия проблемы нужна помощь
 третьей стороны.</dd>

<dt><code>help</code></dt>
 <dd>Сопровождающий просит о помощи в работе с этой ошибкой.
 Либо у сопровождающего нет необходимых навыков для исправления данной
 ошибки, и он хотел бы поработать над исправлением совместно с кем-то ещё,
 либо у сопровождающего нет времени, и он хотел бы передать кому-нибудь работу
 над этой задачей. Данная ошибка не подходит начинающим, если она не помечена меткой
 <code>newcomer</code>.</dd>

<dt><code>newcomer</code></dt>
 <dd>Данная ошибка имеет известное решение, но сопровождающий хочет, чтобы
 его реализовал кто-то другой. Это идеальная задача для новых
 участников, которые хотели бы помочь Debian, либо для тех, кто хочет
 улучшить свои навыки.</dd>

<dt><code>pending</code></dt>
 <dd>Решение этой проблемы найдено, и в ближайшее время на сервер будет
 загружена обновлённая версия.</dd>

<dt><code>fixed</code></dt>
 <dd>Когда ошибка исправлена или отработана (например, через выкладывание
 сопровождающим новой версии), но осталось что-то, для чего нужно найти решение.
 Эта метка заменяет использовавшийся ранее уровень важности <q>fixed</q>.</dd>

<dt><code>security</code></dt>
 <dd>Когда ошибка описывает проблему безопасности в пакете (например,
 неправильные права, дающие доступ к данным, которые не должны быть
 доступны; переполнения буфера, позволяющие людям управлять системой
 в тех случаях, когда они не должны иметь возможность делать это;
 уязвимость к DoS атакам (отказ в обслуживании), которую нужно исправить, и т.д.).
 Большая часть ошибок безопасности должна иметь уровень важности
 critical или grave.</dd>

<dt><code>upstream</code></dt>
 <dd>Когда данная ошибка применима к исходным текстам пакета, полученным
 от автора.</dd>

<dt><code>confirmed</code></dt>
 <dd>Сопровождающий исследовал пакет, понял сообщение об ошибке и в целом
 согласен с ним, но пока не исправил ошибку (использование этой метки
 необязательно; она предназначена в основном для сопровождающих,
 которым нужно работать с большим количеством открытых ошибок).</dd>

<dt><code>fixed-upstream</code></dt>
 <dd>В новой версии программы ошибка исправлена, но пакет по какой-либо
 причине ещё не обновлён (вероятно, чересчур сложно перенести
 изменения на старую версию, или же ошибка слишком незначительна, чтобы
 этим заниматься).</dd>

<dt><code>fixed-in-experimental</code></dt>
 <dd>Ошибка исправлена в версии пакета, находящейся в экспериментальном
 дистрибутиве, но пока ещё не включённой в нестабильный дистрибутив.</dd>

<dt><code>d-i</code></dt>
 <dd>Ошибка связана с разработкой программы установки Debian. Ожидается,
 что эта метка будет использоваться, если ошибка затрагивает разработку
 программы установки, но сообщение об ошибке относится к пакету, не являющемуся
 непосредственной частью программы установки.</dd>

<dt><code>ipv6</code></dt>
 <dd>Ошибка связана с поддержкой протокола Интернет (Internet Protocol, IP)
 версии 6.</dd>

<dt><code>lfs</code></dt>
 <dd>Ошибка связана с поддержкой больших файлов (более 2 ГБ).</dd>

<dt><code>l10n</code></dt>
 <dd>Ошибка связана с локализацией пакета.</dd>

<dt><code>a11y</code></dt>
 <dd>Ошибка связана со специальными условиями для людей с ограниченными возможностями.
 В частности, касается удобства использования для людей, которые полагаются на
 вспомогательные (или другие адаптационные) технологии для использования системы/пакета.</dd>

<dt><code>ftbfs</code></dt>
 <dd>Пакет не может быть собран из исходного кода. Если ошибка привязана к
  пакету с исходным кодом, то этот пакет не может быть собран. Если ошибка привязана
  к двоичному пакету, то не могут быть собраны связанные с ним пакеты с исходным кодом.
  Эта метка применима к нестандартным сборочным окружениям (например, при использовании
  значения поля Build-Depends из экспериментального выпуска), но важность в таком случае должна
  быть ниже serious (release critical).</dd>

<dt><bts_release_tags></dt>
 <dd>Это метки дистрибутивов, и у них есть два значения. Если метка
  устанавливается для ошибки, то это означает, что ошибка может
  касаться только конкретного выпуска (хотя она может быть и в других дистрибутивах,
  если установлены метки других дистрибутивов), а иначе здесь применяются
  обычные правила buggy/fixed/absent. Также эта ошибка не попадёт в архив,
  пока не будет исправлена в этом выпуске.</dd>

<dt><bts_release_ignore_tags></dt>
  <dd>Эта критичная для выпуска ошибка будет проигнорирована при
  конкретном выпуске. <strong>Эта метка должна использоваться только менеджерами выпуска.
  Не устанавливайте её самостоятельно без их явного разрешения.</strong></dd>

</dl>

<p>Некоторая информация о метках, относящихся к конкретному дистрибутиву:
  метки -ignore позволяют
  игнорировать ошибку с целью разрешить пакету попасть в тестируемый
  дистрибутив. Метки выпуска указывают, что ошибка не должна попасть в архив до тех пор,
  пока она не будет исправлена во всех присвоенных выпусках.
  Метки выпуска также указывают, что данная ошибка есть только в заданных
  выпусках. (Другими словами, ошибки <strong>нет</strong> ни в одном выпуске,
  <strong>не</strong> присвоенном данной ошибке; в противном случае применяются
  обычные правила found/fixed.)
</p>

<p>
  Метки выпуска <strong>не</strong> должны использоваться, если желаемого
  эффекта можно достичь установкой правильной версии, так как
  их требуется добавлять и удалять вручную. Если не уверены, что требуется
  метка выпуска, обратитесь к администраторам Debian BTS
  (<email "owner@bugs.debian.org">) или команде выпуска за советом.
</p>

<h2><a name="forward">Запись о том, что вы передали сообщение об ошибке</a></h2>

<p>Когда разработчики пересылают сообщения об ошибках разработчикам
первоначальных пакетов с исходными текстами (из которых и получаются пакеты
Debian), они должны пометить это в системе отслеживания ошибок
следующим образом:</p>

<p>Убедитесь, что поле <code>Кому (To)</code> вашего сообщения авторам содержит
только адрес(а) автора(ов); поместите адрес отправителя сообщения об ошибке и адреса
<var>nnn</var><code>-forwarded@bugs.debian.org</code> и
<var>nnn</var><code>@bugs.debian.org</code> в поле <code>Копия (CC)</code>.</p>

<p>Попросите автора сохранять при ответе адрес
<var>nnn</var><code>-forwarded@bugs.debian.org</code> в поле <code>Копия (CC)</code>,
для того чтобы система отслеживания ошибок сохранила этот ответ вместе с первоначальным
сообщением об ошибке. Эти сообщения только сохраняются, но не пересылаются; чтобы послать
обычное сообщение, пошлите его также на
<var>nnn</var><code>@bugs.debian.org</code>.</p>

<p>Когда система отслеживания ошибок получает сообщение на адрес
<var>nnn</var><code>-forwarded</code>, она отмечает соответствующую ему
ошибку как пересланную на адрес(а) в поле <code>Кому (To)</code> этого
сообщения, если только ошибка уже не помечена как пересланная.</p>

<p>Вы также можете управлять информацией <q>переслано на</q> (forwarded to)
путём отправки сообщений на адрес
<a href="server-control"><code>control@bugs.debian.org</code></a>.</p>


<h2><a name="owner">Изменение ответственного за исправление</a></h2>

<p>В случаях, когда ответственным за исправление ошибки является человек,
не являющийся сопровождающим пакета (например, если пакет сопровождается
несколькими людьми), может быть полезно отметить это в системе отслеживания
ошибок. С этой целью ошибка может иметь ответственного за исправление.</p>

<p>Ответственный за исправление может быть указан в поле <code>Owner</code>
псевдозаголовка сообщения об ошибке (см. <a href="Reporting#pseudoheader">\
инструкции по составлению сообщения об ошибке</a>), или с помощью команд <a
href="#requestserv">сервера управления</a> <code>owner</code> и
<code>noowner</code>.</p>


<h2><a name="maintincorrect">Неправильно указанные сопровождающие пакетов</a></h2>

<p>То, что сопровождающий пакета указан неправильно, обычно вызвано тем,
что сопровождающий недавно сменился, а новый сопровождающий ещё не
выложил новую версию пакета с изменённым управляющим полем
<code>Maintainer</code>. Это будет исправлено при выкладывании пакета.
Кроме того, сопровождающие архива могут изменить запись о сопровождающем
пакета вручную, например если пересборка или новое выкладывание пакета
в скором времени не ожидается. По поводу таких изменений связывайтесь с
<code>override-change@debian.org</code>.</p>


<h2><a name="requestserv">Переоткрытие, переназначение и управление ошибками</a></h2>

<p>Существует возможность переназначить сообщения об ошибках на другие пакеты;
переоткрыть ошибочно закрытые сообщения об ошибках; изменить указанную в
сообщениях информацию о пересылке (если есть); изменить уровень важности или
название сообщения; изменить ответственного за исправление ошибки; слить несколько
сообщений или, наоборот, разделить их; записать версии пакетов, в которых были найдены
ошибки и в которых они были исправлены. Всё это делается путём отправки
почтовых сообщений на <code>control@bugs.debian.org</code>.</p>

<p><a href="server-control">Формат этих сообщений</a> описывается в другом
документе, доступном на сайте, или в файле <code>bug-maint-mailcontrol.txt</code>.
Текстовую версию этого документа можно получить, написав слово <code>help</code>
в сообщении по адресу, указанному выше.</p>

<h2><a name="subscribe">Подписка на сообщения об ошибках</a></h2>

<p>Система отслеживания ошибок даёт возможность отправителям ошибок, разработчикам и
другим заинтересованным третьим лицам подписаться на отдельные ошибки. Эта возможность
может быть использована желающими держать ошибку на виду, не подписываясь на
пакет через <a href="https://tracker.debian.org">Систему отслеживания
пакетов Debian</a>. Все сообщения, принятые
на <var>nnn</var><code>@bugs.debian.org</code>, посылаются подписчикам.</p>

<p>Подписаться на сообщения об ошибке можно, выслав электронное письмо на адрес
<var>nnn</var><code>-subscribe@bugs.debian.org</code>. Тема и текст письма
игнорируются. Когда сообщение обработается, пользователям придёт запрос на подтверждение,
на который они должны ответить, чтобы сообщения о данной ошибке начали приходить
к ним.</p>

<p>Можно также отписаться от сообщений об ошибке. Это можно сделать, послав письмо
на адрес <var>nnn</var><code>-unsubscribe@bugs.debian.org</code>. Тема и
текст письма вновь игнорируются. Пользователям придёт запрос на подтверждение,
на который они должны ответить, если они хотят отписаться от сообщений об ошибках.</p>

<p>По умолчанию адрес, на который будет произведена подписка, берётся из поля
<code>From</code>. Если вы хотите подписать другой адрес, вы должны закодировать этот адрес
в запросе о подписке. Такой запрос должен иметь форму:
<var>nnn</var><code>-subscribe-</code><var>localpart</var><code>=</code><var>example.com</var><code>@bugs.debian.org</code>.
В этом примере запрашивается подписка адреса <code>localpart@example.com</code>
на ошибку <var>nnn</var>. Знак <code>@</code> должен быть заменён на знак
<code>=</code>. Подобным образом делается и отписка:
<var>nnn</var><code>-unsubscribe-</code><var>localpart</var><code>=</code><var>example.com</var><code>@bugs.debian.org</code>.
В обоих случаях тема и текст письма будут пересланы на адрес внутри запроса для подтверждения.</p>

<h2><a name="subjectscan">Более или менее устаревшие возможности</a></h2>

<p>Сообщения, которые приходят на <code>submit</code> или <code>bugs</code>,
и у которых Тема (Subject) начинается с <code>Bug#</code><var>nnn</var>,
будут считаться посланными на адрес <var>nnn</var><code>@bugs.debian.org</code>.
Оба этих варианта оставлены для обратной совместимости при пересылке со
старых адресов и отлавливают последующие сообщения, отправляемые на
<code>submit</code> по ошибке (например, при использовании Ответить всем (Reply to
All)).</p>

<p>Похожая схема функционирует и для адресов <code>maintonly</code>,
<code>done</code>, <code>quiet</code> и <code>forwarded</code>,
обрабатывая сообщения с соответствующей Темой (Subject) как посланные на
<var>nnn-что-то</var><code>@bugs.debian.org</code>.</p>

<p>Обычные сообщения, полученные по адресам <code>forwarded</code> и
<code>done</code>&nbsp;&mdash; т.е. не содержащие номер ошибки в
адресе&nbsp;&mdash; и без номера ошибки в Теме (Subject), будут отмечены как
<q>хлам</q> (junk) и оставлены на несколько недель, но никак не будут обработаны.</p>


<h2><a name="x-debian-pr">Устаревшая возможность <code>X-Debian-PR: quiet</code></a></h2>

<p>Она использовалась для того, чтобы система отслеживания ошибок не
делала дальнейшую пересылку сообщений, пришедших на адрес
<code>debian-bugs</code> и у которых есть строка
<code>X-Debian-PR: quiet</code> в реальном заголовке.</p>

<p>Теперь эта строка игнорируется. Отправляйте ваше сообщение
на адрес <code>quiet</code> или <var>nnn</var><code>-quiet</code> (или
<code>maintonly</code> или <var>nnn</var><code>-maintonly</code>).</p>

<hr />

#use "otherpages.inc"

#use "$(ENGLISHDIR)/Bugs/footer.inc"