Bugzilla/バグ報告ガイド

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 55% complete.
Other languages:

この記事では Gentoo Bugzilla 上でバグを報告する方法について説明します。

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

ベストプラクティス

  • 提出前に文章を再読しましょう 提出後に文章を編集することはできません。また、バグ報告のすべての文章は通常即座にeメールで多くの人々に送信されます。正確にそして綺麗な言葉で書き、口語的な文章は避けましょう。ヒント：あなたが人生の中でたった一度だけこの非常に重要なバグ報告を書く機会があると想像してください。受信者が英語を読めることは知っているでしょう、しかし英語は彼らの母語ではありません。
  • 重複がないか探しましょう 新しいバグを作る前に。
  • 本筋から離れないように - バグチケットは技術的な報告のために使われるもので、雑談は控えるべきです。議論はサポートチャンネル (フォーラム、IRC、あるいはメーリングリスト) 内にとどめてください。
  • 問題の存在の確認は一度だけにしてください。 - あなたと他の誰かが二度確認を報告しても、問題解決の役には立ちません。しかし、あなたのシステムと確認者のシステムが明らかに異なっていて、そのことが問題解決に役立ちそうであれば、その情報を追記してください。
  • 1 トピックごとにバグチケットを開いてください - 1 チケットには複数のパッケージや複数のバグを含めないでください。あなたの直面している問題がバグで議論されていないなら、関連しているバグを検索するか、新しい報告を作成してください。バグを乗っ取らないでください。
  • TRACKER バグでは議論しないでください。 - これらのバグはメタバグです。役立つ情報を追記したいときは、関連するサブバグに追記するか、新しいバグを作成してください。
  • 任意: Gentoo consultants はバグと ebuild についての商用サポートも提供します。
  • チケットが実行時またはインストール時の問題についてのものである場合は、バグチケットにログを添付してください。

パッケージ/ebuild

バグレポートにはいつも、あなたのシステム設定に関する情報を追加するべきです。そのためには、新しいattachmentを作成し、次のコマンドの出力結果を貼り付けてください：

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

ビルド時のバグを報告する（emergeの失敗）

bugzilla内のDescriptionのテキストボックスの下にあるAdd an attachmentボタンを使用して、ファイルを添付してください

実行時のバグを報告する

関係するファイルや情報の優先順位：

  • バグレポートのタイトルにあるパッケージの正確なバージョン 例えば sys-apps/package-2.3-r4 crashes with error: Cannot proceed...
  • 他の人がそのバグを再現できるような、問題の説明:
    • どのようにしてプログラムを実行するか（コンソール上で、ターミナル内で、デーモンとして、どのランレベルで、など）
    • エラー出力
    • どうするとプログラムがクラッシュするか、または誤作動するか、あるいは開始しないか
    • 回避策はあるか？
    • もしあれば、正しく機能する最新のバージョンは何か？
    • 何を変えた結果正しく機能しなくなったか？
  • バグチケットにログを追加してください

バージョンバンプを報告する; 新しい上流のリリースからしばらく経ったとき

  • バンプリクエストを送る前に、Bugzilla を検索してください - もう開いているバグはありませんか? ローカルの Portage ツリーは最近同期しましたか? もう Portage に入っていませんか?
  • ゼロデイバンプリクエストはやめてください (リリースのお知らせから少なくとも 48 時間 は待ってください)
  • そのリリースは実際に上流のソースからリリースされていますか? それとも、ソースツリー上でマークされただけだったりしませんか? プロジェクトによっては、ツリー上でリリースをマークしてから公式にリリースするまで長くかかるものもあります。
  • あなたのアーキテクチャ上でコンパイルが通って、うまく動作するか言及するのを忘れずに。その他の役に立つ情報も大歓迎です。
  • 上流のウェブサイトへのリンクを追加してください
  • 修正されたバグまたは新機能のリスト (チェンジログと呼ばれることもあります) へのリンクをください
  • app-editors/vim-12.3.5 version bump の形式でサマリを書いてください

任意

  • Does a simple copy work, or does the ebuild need changes? (changed dependencies, obsolete patch files)
  • Test the ebuild in a local overlay before submitting attachments
  • Provide patches for proposed ebuild edits, with optional explanation of changes (file name should match the new version number, not old)
  • Provide additional files (initd, unit files) as separate attachments (as needed)
  • Do not paste files directly into comments; use attachments.

新しいパッケージをリクエストする; ebuild リクエスト

あるソフトウェアのための新しい ebuild を portage に追加するようにリクエストする場合、あなたがそのパッケージのメンテナになるか、メンテナになる人を探さなくてはなりません。

If a bug report already exists for the package, you can help the effort by keeping information about the package up to date. If you add a -VERSION component to the package atom, then this can be updated with new releases over time while the bug report remains unmaintained to show there is a continuing interest in seeing it integrated into the portage tree.

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.

安定化をリクエストする

ヒント
For developers, the devmanual has more extensive information on stable requests.

A bug ticket can be used for a stable request.

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

例:

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

カーネル

Files and information of interest for kernel bug reports ordered by priority:

  • Which kernel and version is used, on what architecture e.g. gentoo-sources-3.4.2-r2 on x86_64
  • The kernel configuration file should be attached to the bug report (/usr/src/linux/.config)
  • A list of all devices in the system can be acquired with lspci -k
  • Log files during kernel initialization should be attached (/var/log/dmesg or /var/log/messages)
メモ
On request a kernel git-bisect could be done to identify bad patches.

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.

関連項目

  • Attach the logs to the bug ticket — explains how to attach log files to a bug ticket
  • Bugzilla/Guide — covers the recommended method of forensically reporting specific details of bugs within Gentoo.
  • Contributing to Gentoo — explains how users can contribute to the development of Gentoo
  • Support — provide support for technical issues encountered when installing or using Gentoo Linux
  • Troubleshooting — トラブルを解消したり Gentoo のセットアップの際の支障を解決したりするための技術やツールに関する情報を提供しています。

外部参照

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