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

Сначала сообщение об ошибке, которое отправил пользователь, отправляется как обычное почтовое сообщение на адрес submit@bugs.debian.org. Здесь ему присваивается номер, затем происходит отправка подтверждения о его получении пользователю, после чего оно пересылается в список debian-bugs-dist. Если отправитель включил в сообщение строку Package с именем пакета, и известен сопровождающий этого пакета, то ему также будет отправлена копия этого сообщения.

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

Как закрыть сообщение об ошибке

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

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

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

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

Когда вы закрываете ошибку, где применимо, проставляйте строку Version в псевдо-заголовке вашего сообщения, чтобы система отслеживания ошибок знала, какой из выпусков пакета содержит исправление.

Лицо, исправившее ошибку, лицо, которое отправило сообщение об этой ошибке и список рассылки debian-bugs-closed будут извещены об изменении состояния ошибки. Отправителю сообщения и в список рассылки также будет направлено содержимое сообщения, посланного по адресу nnn-done.

Последующие сообщения

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

Если разработчики захотят ответить на сообщение об ошибке, то они могут просто нажать кнопку ответа (что не приведёт к закрытию ошибки).

Система отслеживания ошибок получит сообщение на адрес nnn@bugs.debian.org и передаст его сопровождающему пакета, сохранит его в конце журнала, который ведётся по данной ошибке, и кроме того перешлёт его в список debian-bugs-dist.

Сообщения, отправленные по адресу nnn-submitter@bugs.debian.org, переправляются непосредственно отправителю ошибки и копией помещаются в систему отслеживания ошибок. Сопровождающему пакеты сообщение не отсылается.

Если вы хотите отправить последующее сообщение, которое не должно попасть в debian-bugs-dist, то вы можете сделать это, отправив его на адрес nnn-quiet@bugs.debian.org или nnn-maintonly@bugs.debian.org. Почта, поступившая на адрес nnn-quiet@bugs.debian.org сохраняется в системе отслеживания ошибок, но не доставляется по каким-то отдельным адресам или в списки рассылки. Почта, поступившая на адрес nnn-maintonly@bugs.debian.org, сохраняется в системе отслеживания ошибок и доставляется только сопровождающему пакета.

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

Более подробно о том, как с помощью заголовков сообщения подавить отправку подтверждений или отправить по какому-то адресу копию отчёта об ошибке, см. инструкцию по составлению сообщений об ошибках.

Уровни важности

Система отслеживания ошибок записывает уровень важности каждого сообщения об ошибке. По умолчанию этот уровень имеет значение normal, но его можно перекрыть, явно указав важность сообщения при его отправке, в псевдо-заголовке, в поле Severity (см. инструкции по созданию сообщений об ошибках), или использовав команду severity сервера управления запросами.

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

critical
когда ошибка делает нерабочим несвязанное друг с другом программное обеспечение (или даже всю систему), или вызывает серьёзные потери данных, или создаёт дыру в безопасности системы при установке пакета.
grave
когда ошибка ставит под вопрос возможность использования пакета или большей его части или приводит к потере данных, или создаёт дыру в безопасности, которая открывает доступ к учётным записям пользователей, использующих пакет.
serious
когда ошибка представляет собой важное нарушение политики Debian (грубо говоря, когда нарушены директивы must или required) или, по мнению сопровождающего пакета или человека, ответственного за выпуск в целом, не позволяет включить этот пакет в выпуск дистрибутива.
important
когда ошибка сильно сказывается на возможности использования пакета, но не делает его полностью непригодным.
normal
значение по умолчанию, которое применимо к большинству ошибок.
minor
когда ошибка не представляет проблемы при использовании пакета и легко исправима.
wishlist
для любых запросах о тех или иных возможностях, а также для любых ошибок, которые очень трудно исправить из-за малого обсуждения возникшей проблемы.

Определённые уровни важности рассматриваются как блокирующие выпуск, что означает, что ошибка приведёт к исключению пакета из стабильного дистрибутива Debian. На данный момент это уровни critical, grave и serious. Полное описание правил установки этих уровней важности см. в списке блокирующих выпуск ошибок в Lenny.

Метки в сообщениях об ошибках

Каждая ошибка может иметь несколько наборов меток или не иметь их совсем. Эти метки отображаются в списке ошибок, когда вы смотрите страницу пакетов или полный журнал ошибок.

Метки могут быть установлены путём включения строки Tags в псевдо-заголовок, при отправке сообщения об ошибке (см. инструкции по созданию сообщений об ошибках), или при использовании команды tags сервера управления запросами. Метки могут разделяться запятыми, пробелами или и тем, и другим.

Метки в настоящий момент могут принимать следующие значения:

patch
Когда в журнал ошибок включена заплата или какой-либо другой простой способ исправления ошибки. Если это заплата, но она не исправляет ошибку адекватно или создаёт другие проблемы, эту метку использовать нельзя.
wontfix
Когда ошибка неисправима. Такое возможно, потому что, например, нужно выбирать между двумя взаимоисключающими способами исправления, но сопровождающий пакета и отправитель сообщения об ошибке не могут сойтись во мнении о том какой способ выбрать; или потому что исправление этой ошибки приведёт к изменению в поведении, ухудшению или проблемам в других случаях и т.д.
moreinfo
Когда ошибка не может быть идентифицирована, пока отправитель сообщения не предоставит больше информации. Такая ошибка будет закрыта, если отправитель не предоставит достаточную информацию в ближайшие (около месяца) сроки. Обычно такое происходит с сообщениями об ошибках, которые имеют содержание типа: Это не работает. Что не работает?
unreproducible
Когда ошибка не может быть воспроизведена в системе сопровождающего пакета. В таких случаях для диагностирования наличия проблемы нужна помощь третьей стороны.
help
Сопровождающий просит помощи в исправлении этой ошибки.
pending
Решение этой проблемы найдено, и в ближайшее время на сервер будет загружена обновлённая версия.
fixed
Когда ошибка исправлена или отработана (например, через выкладывание сопровождающим новой версии), но осталось что-то, для чего нужно найти решение. Эта метка заменяет использовавшийся ранее уровень важности fixed.
security
Когда ошибка описывает проблему безопасности в пакете (например, неправильные права, дающие доступ к данным, которые не должны быть доступны; переполнения буфера, позволяющие людям управлять системой в тех случаях, когда они не должны иметь возможность делать это; уязвимость к DoS атакам (отказ в обслуживании), которые нужно исправить и т.д.). Большая часть ошибок в безопасности имеет уровень важности critical или grave.
upstream
Когда данная ошибка применима к исходным текстам пакета, полученным от автора.
confirmed
Сопровождающий пакет исследовал, понял отчёт об ошибке и в целом согласен с ним, но пока не исправил ошибку (использование этой метки необязательно, она предназначен, в основном, для сопровождающих, которым нужно работать с большим количеством открытых ошибок).
fixed-upstream
В новой версии программы ошибка исправлена, но пакет по какой-либо причине ещё не обновлён (вероятно, чересчур сложно перенести изменения на старую версию или они слишком незначительны, чтобы этим заниматься).
fixed-in-experimental
Ошибка исправлена в версии пакета, находящейся в экспериментальном дистрибутиве, но пока ещё не включённой в нестабильный дистрибутив.
d-i
Ошибка связана с разработкой программы установки Debian. Ожидается, что эта метка будет использоваться, если ошибка затрагивает разработку программы установки, но отчёт об ошибке относится к пакету, не являющемуся непосредственной частью программы установки.
ipv6
Ошибка связана с поддержкой протокола Интернет (Internet Protocol, IP) версии 6.
lfs
Ошибка связана с поддержкой больших файлов (более 2 ГБ).
l10n
Ошибка связана с локализацией пакета.
potato
Когда ошибка специфична для выпуска potato.
woody
Когда ошибка специфична для дистрибутива woody.
sarge
Это метка дистрибутива, для неё есть два значения. Если она устанавливается для ошибки, то это означает, что ошибка может касаться только sarge (хотя она может быть и в других дистрибутивах, если установлены метки других дистрибутивов), а иначе здесь применяются обычные правила buggy/fixed/absent. Также эта ошибка не попадёт в архив, пока не будет исправлена в sarge.
sarge-ignore
Эта блокирующая выпуск ошибка при подготовке выпуска sarge должна игнорироваться. Эта метка должна использоваться только менеджером выпуска. Не устанавливайте её самостоятельно без его явного подтверждения.
etch
Это метка дистрибутива, для неё есть два значения. Если она устанавливается для ошибки, то это означает, что ошибка может касаться только etch (хотя она может быть и в других дистрибутивах, если установлены метки других дистрибутивов), а иначе здесь применяются обычные правила buggy/fixed/absent. Также эта ошибка не попадёт в архив, пока не будет исправлена в etch.
etch-ignore
Эта блокирующая выпуск ошибка при подготовке выпуска etch должна игнорироваться. Эта метка должна использоваться только менеджером выпуска. Не устанавливайте её самостоятельно без его явного подтверждения.
lenny
Это метка дистрибутива, для неё есть два значения. Если она устанавливается для ошибки, то это означает, что ошибка может касаться только lenny (хотя она может быть и в других дистрибутивах, если установлены метки других дистрибутивов), а иначе здесь применяются обычные правила buggy/fixed/absent. Также эта ошибка не попадёт в архив, пока не будет исправлена в lenny.
lenny-ignore
Эта критичная для выпуска ошибка будет проигнорирована при выпуске lenny. Эта метка должна использоваться только менеджерами выпуска. Не устанавливайте её самостоятельно без их явного разрешения.
squeeze
Это метка дистрибутива, для неё есть два значения. Если она устанавливается для ошибки, то это означает, что ошибка может касаться только squeeze (хотя она может быть и в других дистрибутивах, если установлены метки других дистрибутивов), а иначе здесь применяются обычные правила buggy/fixed/absent. Также эта ошибка не попадёт в архив, пока не будет исправлена в squeeze.
squeeze-ignore
Эта критичная для выпуска ошибка будет проигнорирована при выпуске squeeze. Эта метка должна использоваться только менеджерами выпуска. Не устанавливайте её самостоятельно без их явного разрешения.
sid
Это метка дистрибутива, для неё есть два значения. Если она устанавливается для ошибки, то это означает, что ошибка может касаться только sid (хотя она может быть и в других дистрибутивах, если установлены метки других дистрибутивов), а иначе здесь применяются обычные правила buggy/fixed/absent. Также эта ошибка не попадёт в архив, пока не будет исправлена в sid.
experimental
Это метка дистрибутива, для неё есть два значения. Если она устанавливается для ошибки, то это означает, что ошибка может касаться только experimental (хотя она может быть и в других дистрибутивах, если установлены метки других дистрибутивов), а иначе здесь применяются обычные правила buggy/fixed/absent. Также эта ошибка не попадёт в архив, пока не будет исправлена в experimental.

Значения последних 8, относящихся к конкретному дистрибутиву, меток недавно изменились. Метки -ignore позволяют игнорировать ошибку с целью разрешить пакету попасть в тестируемый дистрибутив. Метки выпуска указывают, что ошибка не должна попасть архив до тех пор, пока она не будет исправлена во всех присвоенных выпусках. Метки выпуска также указывают, что данная ошибка есть только в заданных выпусках. (Другими словами, ошибки нет ни в одном выпуске, не присвоенной данной ошибке; в противном случае применяются обычные правила поиска/исправления.)

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

Записи, помещаемые вами в сообщение об ошибке

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

Убедитесь, что поле Для (To) вашего сообщения содержит только адрес(а) автора(ов); затем поместите в поле CC адрес отправителя сообщения об ошибке и адреса nnn-forwarded@bugs.debian.org и nnn@bugs.debian.org.

Попросите автора сохранить при ответе в поле CC адрес nnn-forwarded@bugs.debian.org, для того, чтобы система отслеживания ошибок сохраняла этот ответ вместе с первоначальным сообщением об ошибке. Эти сообщения будут только зарегистрированы, но не посланы; чтобы послать обычное сообщение, пошлите его на nnn@bugs.debian.org.

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

Вы также можете управлять информацией пересылка для (forwarded to) путём отправки сообщений на адрес control@bugs.debian.org.

Изменение ответственного за исправление

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

Ответственный за исправление может быть указан в поле Owner псевдо-заголовка отчёта об ошибке (см. инструкции по составлению отчёта об ошибке), или с помощью команд сервера управления owner и noowner.

Неправильно указанные сопровождающие пакетов

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

Переоткрытие, переназначение и управление ошибками

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

Формат этих сообщений описывается в другом документе, доступном на сайте, или в файле bug-maint-mailcontrol.txt. Текстовую версию этого документа можно получить написав слово help в сообщении по адресу, указанному выше.

Подписка на сообщения об ошибках

Система отслеживания ошибок даёт возможность отправителям ошибок, разработчикам и другим заинтересованным третьим лицам подписаться на отдельные ошибки. Эта возможность может быть использована желающими держать ошибку на виду, не подписываясь на пакет через PTS. Все сообщения, принятые на nnn@bugs.debian.org, посылаются подписчикам.

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

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

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

Более или менее устаревшие возможности

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

Похожая схема функционирует и для адресов maintonly, done, quiet и forwarded, обрабатывая сообщения, тема (Subject) которых соответствует nnn-куда-то@bugs.debian.org.

Обычные сообщения, полученные по адресам forwarded и done — т.е., не содержащие номер ошибки в адресе и без номера ошибки в теме (Subject) будут отмечены как хлам (junk) и оставлены на несколько дней, а затем удалены.

Устаревшая возможность X-Debian-PR: quiet

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

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

Другие страницы системы отслеживания ошибок:

Debian BTS administrators <owner@bugs.debian.org>

Debian bug tracking system
Copyright © 1999 Darren O. Benham, 1997, 2003 nCipher Corporation Ltd, 1994-1997 Ian Jackson.