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 0% complete.
Other languages:
English • ‎italiano • ‎русский • ‎中文(中国大陆)‎ • ‎日本語 • ‎한국어


  • 提出前に文章を再読しましょう 提出後に文章を編集することはできません。また、バグ報告のすべての文章は通常即座にeメールで多くの人々に送信されます。正確にそして綺麗な言葉で書き、口語的な文章は避けましょう。ヒント:あなたが人生の中でたった一度だけこの非常に重要なバグ報告を書く機会があると想像してください。受信者が英語を読めることは知っているでしょう、しかし英語は彼らの母語ではありません。
  • 重複がないか探しましょう 新しいバグを作る前に。
  • Stay on topic - A bug ticket is used for technical reports and chitchat should be avoided. Keep them in the support channels (forums, IRC or mailing lists).
  • Confirm the existence of a problem only once. - It does not help solving the problem, if you and another person report it twice. But if your and the confirmer's systems differ in an obvious way and that would be helpful to know, add this information.
  • Open one bug ticket per topic - Usually this means not more than one package and one bug per ticket. If your problem is not discussed on a bug, search for one related to your issue or create a new report. Do not hijack bugs.
  • No talk on TRACKER bugs. - Those bugs are meta bugs. If you want to add useful information, add them to a related sub bug or create a new bug.
  • Optional: Gentoo consultants provide also commercial support for bugs and ebuilds.
  • Attach the logs to the bug ticket if the ticket is about problems during runtime or installation.



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


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



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

Report a version bump; a newer upstream release is available since a while

  • Search Bugzilla before posting a bump request - is there already a bug open? Has the local Portage tree been synced lately; is it already in Portage?
  • Avoid zero-day bump requests (wait at least 48 hours after the release announcement)
  • Has it actually been released by upstream sources, or is it just marked in the source tree? Some projects mark a release in the tree long time before it is officially released.
  • Be sure to mention if it compiles and runs well on your arch. Any other helpful information you provide is most welcome.
  • Add a link to the upstream website
  • Give a link or list of fixed bugs or new features (sometimes called changelog)
  • Write a summary in the form 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.

Request for a new package; ebuild request

If you request a new ebuild for a software to be added to portage, you must find or become a maintainer for the package.

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.

Package XY should be marked stable

If a package is building and working without problems on the system for more than 30 days and it isn't yet marked as stable you can create a stable request.


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.

See also