Замечание: оригинал этого документа новее, чем перевод.

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

Сначала сообщение об ошибке, которое отправил пользователь, отправляется как обычное почтовое сообщение на адрес [email protected], сообщение должно содержать строку Package (дополнительную информацию см. в инструкции по отправке отчётов об ошибках). Здесь ему присваивается номер, затем происходит отправка подтверждения о его получении пользователю, после чего оно пересылается в список debian-bugs-dist. Если строка Package содержит имя пакета, и для этого пакета известен сопровождающий, то ему также будет отправлена копия этого сообщения.

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

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

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

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

Сообщения об ошибках должны закрываться путём отправки письма по адресу nnn[email protected]. Тело сообщения должно содержать объяснение того, как исправлена ошибка.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В настоящий момент метки могут принимать следующие значения: patch, wontfix, moreinfo, unreproducible, help, security, upstream, pending, confirmed, ipv6, lfs, d-i, l10n, newcomer, a11y, ftbfs, fixed-upstream, fixed, fixed-in-experimental, potato, woody, sarge, etch, lenny, squeeze, wheezy, jessie, stretch, buster, bullseye, bookworm, trixie, forky, sid, experimental, sarge-ignore, etch-ignore, lenny-ignore, squeeze-ignore, wheezy-ignore, jessie-ignore, stretch-ignore, buster-ignore, bullseye-ignore, bookworm-ignore, trixie-ignore forky-ignore . Дополнительная информация о метках:

patch
Когда в журнал ошибок включена заплата или какой-либо другой простой способ исправления ошибки. Если это заплата, но она не исправляет ошибку адекватно или создаёт другие проблемы, эту метку использовать нельзя.
wontfix
Когда ошибка неисправима. Такое возможно, потому что, например, нужно выбирать между двумя взаимоисключающими способами исправления, но сопровождающий пакета и отправитель сообщения об ошибке не могут сойтись во мнении о том, какой способ выбрать; или потому что изменение поведения вызовет другие, более серьёзные проблемы для остальных; или по другим причинам.
moreinfo
Когда ошибка не может быть идентифицирована, пока отправитель сообщения не предоставит больше информации. Такая ошибка будет закрыта, если отправитель не предоставит достаточную информацию в ближайшие (около месяца) сроки. Обычно такое происходит с сообщениями об ошибках, которые имеют содержание типа: Это не работает. Что не работает?
unreproducible
Когда ошибка не может быть воспроизведена в системе сопровождающего пакета. В таких случаях для диагностирования наличия проблемы нужна помощь третьей стороны.
help
Сопровождающий просит о помощи в работе с этой ошибкой. Либо у сопровождающего нет необходимых навыков для исправления данной ошибки, и он хотел бы поработать над исправлением совместно с кем-то ещё, либо у сопровождающего нет времени, и он хотел бы передать кому-нибудь работу над этой задачей. Данная ошибка не подходит начинающим, если она не помечена меткой newcomer.
newcomer
Данная ошибка имеет известное решение, но сопровождающий хочет, чтобы его реализовал кто-то другой. Это идеальная задача для новых участников, которые хотели бы помочь Debian, либо для тех, кто хочет улучшить свои навыки.
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
Ошибка связана с локализацией пакета.
a11y
Ошибка связана со специальными условиями для людей с ограниченными возможностями. В частности, касается удобства использования для людей, которые полагаются на вспомогательные (или другие адаптационные) технологии для использования системы/пакета.
ftbfs
Пакет не может быть собран из исходного кода. Если ошибка привязана к пакету с исходным кодом, то этот пакет не может быть собран. Если ошибка привязана к двоичному пакету, то не могут быть собраны связанные с ним пакеты с исходным кодом. Эта метка применима к нестандартным сборочным окружениям (например, при использовании значения поля Build-Depends из экспериментального выпуска), но важность в таком случае должна быть ниже serious (release critical).
potato, woody, sarge, etch, lenny, squeeze, wheezy, jessie, stretch, buster, bullseye, bookworm, trixie, forky, sid, experimental
Это метки дистрибутивов, и у них есть два значения. Если метка устанавливается для ошибки, то это означает, что ошибка может касаться только конкретного выпуска (хотя она может быть и в других дистрибутивах, если установлены метки других дистрибутивов), а иначе здесь применяются обычные правила buggy/fixed/absent. Также эта ошибка не попадёт в архив, пока не будет исправлена в этом выпуске.
sarge-ignore, etch-ignore, lenny-ignore, squeeze-ignore, wheezy-ignore, jessie-ignore, stretch-ignore, buster-ignore, bullseye-ignore, bookworm-ignore, trixie-ignore forky-ignore
Эта критичная для выпуска ошибка будет проигнорирована при конкретном выпуске. Эта метка должна использоваться только менеджерами выпуска. Не устанавливайте её самостоятельно без их явного разрешения.

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

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

Запись о том, что вы передали сообщение об ошибке

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

Убедитесь, что поле Кому (To) вашего сообщения авторам содержит только адрес(а) автора(ов); поместите адрес отправителя сообщения об ошибке и адреса nnn[email protected] и nnn@bugs.debian.org в поле Копия (CC).

Попросите автора сохранять при ответе адрес nnn[email protected] в поле Копия (CC), для того чтобы система отслеживания ошибок сохранила этот ответ вместе с первоначальным сообщением об ошибке. Эти сообщения только сохраняются, но не пересылаются; чтобы послать обычное сообщение, пошлите его также на nnn@bugs.debian.org.

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

Вы также можете управлять информацией переслано на (forwarded to) путём отправки сообщений на адрес [email protected].

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

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

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

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

То, что сопровождающий пакета указан неправильно, обычно вызвано тем, что сопровождающий недавно сменился, а новый сопровождающий ещё не выложил новую версию пакета с изменённым управляющим полем Maintainer. Это будет исправлено при выкладывании пакета. Кроме того, сопровождающие архива могут изменить запись о сопровождающем пакета вручную, например если пересборка или новое выкладывание пакета в скором времени не ожидается. По поводу таких изменений связывайтесь с [email protected].

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

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

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

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

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

Подписаться на сообщения об ошибке можно, выслав электронное письмо на адрес nnn[email protected]. Тема и текст письма игнорируются. Когда сообщение обработается, пользователям придёт запрос на подтверждение, на который они должны ответить, чтобы сообщения о данной ошибке начали приходить к ним.

Можно также отписаться от сообщений об ошибке. Это можно сделать, послав письмо на адрес nnn[email protected]. Тема и текст письма вновь игнорируются. Пользователям придёт запрос на подтверждение, на который они должны ответить, если они хотят отписаться от сообщений об ошибках.

По умолчанию адрес, на который будет произведена подписка, берётся из поля From. Если вы хотите подписать другой адрес, вы должны закодировать этот адрес в запросе о подписке. Такой запрос должен иметь форму: nnn-subscribe-localpart=example.com@bugs.debian.org. В этом примере запрашивается подписка адреса [email protected] на ошибку 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 <[email protected]>

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