Bugzilla/Bug report guide/ru

From Gentoo Wiki
Jump to:navigation Jump to:search
This page is a translated version of the page Bugzilla/Bug report guide and the translation is 45% complete.
Outdated translations are marked like this.
Other languages:

This article explains how to report bugs on the Gentoo Bugzilla.

See Bugzilla/Guide for the recommended method of reporting bugs for Gentoo.

Лучшие практики

  • Перечитайте текст отчета перед отправкой; текст нельзя отредактировать впоследствии. Текст отчета об ошибке, как правило, немедленно отправляется по электронной почте множеству людей. Напишите отчет ясно, на чистом языке; избегайте разговорной лексики. Подсказка: Представьте, что у вас есть только один шанс в вашей жизни, чтобы написать этот очень важный отчет об ошибке. Вы должны понимать, что получатель может прочитать по-английски, но это может быть не его родной язык.
  • Поищите дубликаты, перед созданием нового бага.
  • Не отклоняйтесь от темы — сообщение об ошибке предназначено для технических отчетов, а не для болтовни. Оставьте её для каналов поддержки (форумы, IRC и списков рассылок).
  • Подтверждайте существование проблемы только один раз — обычно это означает, что не должно быть более одного сообщения об ошибке для каждого пакета. если вы и кто-то другой сообщите дважды о той же самой проблеме, это не поспособствует её решению. Однако, если ваша система очевидно отличается от системы подтвердившего ошибку, и это имеет значение, тогда добавьте эту информацию.
  • Открывайте один отчёт для каждой проблемы — если ваша проблема не обсуждается в отчете, поищите отчет, имеющий к ней отношение или создайте новый. Не захватывайте другие отчеты об ошибках.
  • Никаких разговоров в TRACKER bugs — эти отчеты являются мета-отчетами. Если вы хотите добавить полезную информацию, добавьте ее в подходящий суб-отчет или создайте новый отчет.
  • Дополнительно: консультанты Gentoo также могут оказывать коммерческую поддержку для решения ошибок и написания ebuild.
  • Прикрепляйте файлы журналов к отчёту об ошибке, если отчёт описывает проблемы, появляющиеся во время выполнения или установки.

Пакеты/ebuild

Вы должны всегда добавлять информацию о системной конфигурации в баг. Для этого создайте новое вложение (attachment) и вставьте содержимое:

user $emerge --info > /tmp/emerge--info.txt

Сообщите об ошибке во время сборки (emerge failed)

Используйте кнопку Add an attachment под текстовым полем описания, чтобы прикрепить файлы в bugzilla.

Сообщите об ошибках во время выполнения

Файлы и информация, представляющая интерес, в порядке приоритета:

  • Точная версия пакета в заголовке отчета, например sys-apps/package-2.3-r4 аварийно завершается с ошибкой: Не могу продолжать...
  • Описание проблемы, чтобы другие могли ее воспроизвести:
    • Как запускается программа (в консоли, в терминале, в качестве демона, в каком уровне запуска и так далее)
    • Какие ошибки выводятся
    • Что заставляет программу аварийно завершаться, неправильно работать, не запускаться
    • Есть ли возможность обойти проблему?
    • Последняя версия пакета, которая работала нормально, если таковая была
    • Какие изменения привели к тому, что программа перестала работать?

Прикрепите (attach) логи к сообщению об ошибке

Сообщить о новой версии; новая версия программы доступна какое-то время

  • Выполните поиск в Bugzilla перед тем, как отправлять запрос на новую версию – существует ли открытый баг? Было ли недавно обновлено локальное дерево Portage; присутствует ли новая версия в Portage?
  • Избегайте запросов новых версий после нулевого дня с выпуска релиза (подождите по крайней мере 48 часов после сообщения о выпуске)
  • Была ли новая версия действительно выпущена разработчиками, или она только отмечена в дереве исходных кодов? В некоторых проектах новую версию в дереве отмечают задолго до официального выпуска.
  • Обязательно отметьте, если новая версия компилируется и хорошо работает на вашей архитектуре. Любая другая полезная информация, которую вы предоставите, весьма приветствуется.
  • Добавьте ссылку на web-сайт проекта.
  • Предоставьте список исправленных ошибок и новых возможностей (иногда называемый changelog) или ссылку на него
  • Запишите заголовок в формате app-editors/vim-12.3.5 version bump

Не обязательно

  • Требуются ли изменения в ebuild? (изменение зависимостей, удаление устаревших patch-файлов)
  • Если новая версия не требует изменения содержимого файла ebuild, отметьте это
  • Протестируйте файл ebuild в локальном оверлее перед тем как прикрепить и отправить его
  • Предоставьте патчи для предложенных изменений файла ebuild, по желанию, с объяснением изменений (имя файла должно соответствовать новому номеру версии, не старому)
  • Предоставьте дополнительные файлы (initd, unit-файлы) в качестве отдельных прикреплений (по необходимости)
  • Не вставляйте файлы ebuild или другое содержимое, относящееся к ним, прямо в комментарии; используйте прикрепления

Запрос на добавление нового пакета; запрос ebuild файла

Если вы хотите добавить в Portage новый ebuild для какой-либо программы, вам нужно найти куратора (maintainer) для пакета, либо самому им стать:

  • Включите в отчет ссылку на веб-сайт разработчиков
  • Включите в отчет ссылку или список возможностей программы
  • Укажите предварительную категорию и имя пакета для ebuild в строке темы, например «media-gfx/inkscape ebuild request»
  • Предоставьте файл ebuild и патчи, оттестированные в локальном оверлее (помощь в этом можно получить на IRC или на форумах)

If no bug report exists for the package, you can file a bug report under the Gentoo Linux project and the component New package.

The Summary of your bug report should list a (preliminary) package atom category/package, perhaps with a -VERSION suffix, followed by a canonical short description of the package (the DESCRIPTION variable in an ebuild). It is important to disambiguate the name of the new package: if upstream uses different names for the same software, perhaps an abbreviation as well as the full name, you should mention both (all) of these in the Summary so that other people can find bug reports about the same software. If several (groups of) people track different bug reports about virtually the same ebuild request, this will duplicate the effort of ebuild research and development, and will divide people who have a common interest.

You should link to the upstream website (the HOMEPAGE variable in an ebuild) using the URL field. You should provide a list of features in the Description of the bug report. This may well be taken directly from the upstream website or from a manual or other documentation, and could be used later for the longdescription tag in metadata.xml.

You can attach an ebuild and related files that should go into the portage tree directly to the bug report, or you can use the See also field to refer to a git pull request.

You can help develop the package by setting up a local overlay with your ebuilds, metadata, patches and other auxiliary files. If you need technical support with your ebuild development, many people would be glad to help.

Пакет XY следует отметить как стабильный

Совет
For developers, the devmanual has more extensive information on stable requests.

Если пакет собирается и работает без проблем более 30 дней, но все ещё не отмечен как стабильный, то вы можете создать запрос на стабилизацию:

Everybody can request a stabilization. Users do not need to worry about filling all fields or details in the bug. The maintainer (or Proxied Maintainer) will CC the arches.

To request stabilization of a package, file a new bug under the Stabilization component taking care to complete two special bug fields:

  • Package list - a fully qualified package per line, optionally followed by a space-delimited list of architectures to target. If no architecture list is provided, all architectures in CC are assumed. Formerly, this field was called Atoms to stabilize and contained fully qualified atoms, which is also still supported.
  • Runtime testing required - indicates if additional runtime testing should be performed beyond build and tests passing. If undefined the arch tester should use their best judgement

Examples:

Summary foo-libs/libbar-1.2.3 stabilization request
CC amd64 x86
Runtime testing required No
Package list foo-libs/libbar-1.2.3 (old syntax, still supported: =foo-libs/libbar-1.2.3)
Explanation
  • foo-libs/libbar-1.2.3 will be stabilized for amd64 and x86
  • Build and tests passing is sufficient to stabilize
Summary app-foo/bar-1.2.3 and app-foo/baz-4.5.6 stabilization request
CC amd64 arm x86
Runtime testing required Yes
Package list app-foo/bar-1.2.3
app-foo/baz-4.5.6 amd64 x86
Explanation
  • app-foo/bar-1.2.3 will be stabilized for amd64, arm, and x86
  • app-foo/baz-4.5.6 will be stabilized for amd64, and x86
  • It is requested additional runtime testing of the package is performed after it is merged

Ядро

Файлы и информация, представляющая интерес для отчетов об ошибках ядра, в порядке приоритета:

  • Какая версия ядра используется, на какой архитектуре, например gentoo-sources-3.4.2-r2 на x86_64
  • Файл конфигурации ядра следует прикрепить к отчету (/usr/src/linux/.config)
  • Список всех устройств в системе можно получить с помощью команды lspci -k
  • Следует прикрепить файлы журналов ядра, содержащие информацию о его инициализации (/var/log/dmesg или /var/log/messages)
Заметка
Может потребоваться осуществить kernel git-bisect для определения плохих патчей.

Supplemental information for bug reports

Information when needed How to collect
SRC_URI reachable? download failed GENTOO_MIRRORS="" ebuild foo-1.2.ebuild fetch
OpenGL version Games with OpenGL glxinfo -B
linked libraries Dependency is missing Add missing dependency, compile, check with lddtree

Trackers

Tracker-Bugs are virtual bugs to cluster bugs with the same topic.

Смотрите также

External references

Retrieved from "https://wiki.gentoo.org/index.php?title=Bugzilla/Bug_report_guide/ru&oldid=1271885"