How to Report Bugs in LibreOffice

From The Document Foundation Wiki
< QA
Jump to: navigation, search
This page is a translated version of the page QA/BugReport and the translation is 11% complete.

Outdated translations are marked like this.
本ページはGlobal Wikiからの有志による翻訳ページです。未翻訳があることや内容が古い場合があります。最新化、翻訳にご協力お願いします。
日本語独自の情報についてまとめることを目的として、日本語コミュニティによって運営されているページとして 日本語コミュニティ独自ページ があります。
URLが wiki.documentfoundation.org/JA で始まっていて、カテゴリーがJAのページです。
そちらもご利用ください。
Other languages:
العربية • ‎Deutsch • ‎Ελληνικά • ‎English • ‎español • ‎français • ‎galego • ‎italiano • ‎日本語 • ‎Nederlands • ‎português do Brasil • ‎русский • ‎Türkçe • ‎中文(中国大陆)‎ • ‎中文(简体)‎ • ‎中文(台灣)‎

Glad you made it here. You are about to make an important contribution to LibreOffice. A good bug report is very helpful for our developers. Below, you'll find some guidance to make this process easier.

一般的な情報

バグ報告が目指す唯一のゴールは、当該の不具合を LibreOffice スタッフが再現できるようにすることです。したがって、起きた不具合そのものについては最小限に、再現手順についてより多くの情報を書くようにしてください。

  1. その不具合は本当にバグなのでしょうか? LibreOffice を使っていて困ったことがあったら、公式 LibreOffice ドキュメント にあるユーザードキュメントを読んでみてください (訳注:日本語版は存在しないので、OpenOffice.org日本ユーザー会の出版事業の成果物などを検討したり、書籍の購入を検討してもよいでしょう)。それでもまだ助けが必要なら、LibreOffice利用者メーリングリスト(日本語/英語) や Ask.Libreoffice/Ask.Libreoffice (英語) に質問してみてください。
  2. もし不具合がどのコンポーネントにあるか確信がないなら、Libreoffice コンポーネントを選んでください。バグトリアージを行う人があとで適切なものに変更します。詳しい情報は "BugTriage" をご覧ください。もし優先度が高い問題 (パーツが破損している、リグレッション、など) ならば、べテランユーザーが当該バグをFindTheExpert ページに掲載されている開発者に割り当てます。
  3. もし起票したレポートに適切な時間内 (致命的 (critical) なバグならば 24 時間以内、改善要求 (enhancement request) なら 14 日以内) に誰も反応しなかったら、バグが再現していないかどうかLibreOffice利用者メーリングリスト(日本語/英語) や #libreoffice IRC channel (英語) で聞いてみるとよいでしょう。
  4. 複数の不具合は、別個にバグレポートを作成してください!異なる根本原因による別々の不具合は、異なる人の手により、異なるバージョンで、時間をおいて修正されるかもしれません。このような状況を単一のバグレポートで追跡するのは無理です。
  5. LibreOffice のバグは直接 Bugzilla で報告することができます。


Class of Bugs Where to file the bug
LibreOffice Extensions With the extension author
TDF/LibreOffice Infrastructure (websites, mailing lists, etc.) Redmine
Building LibreOffice Developer mailing list
LibreOffice Unit Tests Developer mailing list

Bugzilla でのバグ報告手順

Confirm that it really is a bug. Most of the time, a bug is something that makes the software behave in a way that a reasonable user would not want it to behave. This includes the software not doing what you want it to do, doing what you never asked it to do, or just plain crashing under normal use. Going behind the scenes, a bug may be something that causes the software to take a lot longer and use a lot more resources doing stuff than it should.

  1. 新規にバグ報告をする前に、バグ報告の詳細 ページで、正しいサブコンポーネント (各コンポーネントの見出しに続くサブコンポーネント名をクリックすると、現在報告されているバグのリストが開きます) で同種のバグ報告がすでにされているか確認してください。ⓘを押すと予想されるサブコンポーネントを見つけてくれます。Bugzilla のページ末尾にある Edit Search を押すと、望むように検索を変更することができます。
  2. そのバグがリストに存在しないようなら、新たな報告を始めましょう。バグ報告の詳細 で、適切なサブコンポーネントの '►' をクリックすることで、必要とされる Bugzilla の報告ページを開けます。(適切なサブコンポーネントを選ぶことができなければ、 "for all other ..." をクリックしてください)
    それから:
    1. LibreOffice のバージョンを選びます
    2. お使いのオペレーティングシステムを選びます
    3. Bug Reportバグ報告の詳細 を参照しながらバグ報告を書きます
    4. 報告に見合う重要度 (Severity) を決めてください。blocker を選んでも早く解決されるというわけではないので、もしバグ報告の経験があまりないならそのままにしておくとよいでしょう
    5. バグ報告ページの "possibly related Bugs (もしかしたら関連のあるバグ)" をチェックし、更に Duplicates Table も確認して、その問題が本当にまだ報告されていないのか確認します
  3. Submit ボタンを押すと、報告は Bugzilla データベースに登録されます。


At a certain point what look like bugs are actually more like feature requests, where we know how the software should work in an ideal world, even though the feature we want hasn't been built yet. Fortunately, you don't have to worry that much about separating bugs from feature requests. If it's something that interferes with normal, valid use of the application, report it as a bug.

It helps a lot if you know your way around LibreOffice, though, so you have a good sense of what normal, valid use is. You don’t want to spend a lot of time reporting what you think are bugs when the issue is that you don’t know how to use a certain feature yet. Consider reading the user documentation, and use the apps a lot so you become familiar with what they normally do.

追加のヒント

  • もし Bugzilla バグ追跡システムがとても厄介だとか理解が難しいと思われた場合、LibreOffice利用者メーリングリスト(日本語/英語) や LibreOffice フォーラム (日本語)/(英語) で聞いてみてもよいですし、もちろん、アシスタント の利用を試してみてもよいでしょう。


But let’s say what you found really does look like a bug. Here’s what to do next:

  1. Take notes so you don’t forget something that was going on around the time the bug appeared. What were you doing, what did you expect to happen, and what actually happened? How did you know something was wrong? Can you reproduce the bad behavior?
  2. Check for similar, existing bug reports:
    1. Go to Components, and select the appropriate component (or subcomponent).
    2. If you selected a component: select the appropriate subcomponent, or Extended Help if you don’t see the subcomponent on that page.
    3. If you selected Extended Help: select the appropriate subcomponent, or the [1] at the bottom of the list if you did not find or do not know the appropriate subcomponent.
    4. You will see a list of bugs with that subcomponent. At the bottom of the page, select Edit Search. There, you can modify the search according to your needs.
    5. If you find a bug report that concerns your problem, you can contribute to it. If you don’t find a bug report that concerns your problem, file a new bug report.
  3. If the bug only occurs on Ubuntu or is related to printing, go to #More Information.
  4. After all that, if it does not look like there is a bug report about this issue, follow the instructions at #Submitting a bug.

Ubuntuでのバグの報告

File a separate bug report for each bug you run into, even if the symptoms from a user’s point of view seem identical. Different problems with different roots that appeared in different LibO versions might have to be fixed by different people, for different versions, and at different times. It is impossible to track that in a single bug report.

Ubuntu特有のバグを報告するには、まず現在の課題一覧を確認した上で:

  • Ubuntu 10.04やUbuntu 10.10ではLibreOfficeはサポートされていません。Upstream である LibreOffice 自身にバグ報告するか、Natty (11.10) 以降に更新してください。

If you are prompted to sign in, log in with your Bugzilla account.

  • Ubuntu 11.04以降では、アプリケーション ▸ アクセサリ ▸ 端末 (アクセサリをクリックする必要はないでしょう)で端末ウィンドウを開いて (訳注:Unity デスクトップの場合は Ctrl + Alt + T で端末を開く方が簡単でしょう) ubuntu-bug libreoffice ↵ Enter と入力してから、プロンプトの指示に従って報告します。またはこのフォームを使用します。
  • Ubuntu以外のオペレーティングシステムでも起きるバグについては、この方法ではなく、前述した方法で報告してください。
    LibreOfficeをどのようにインストールしたか、どのようなプラットフォームを使用しているか(32ビットか64ビットか)などの詳細を忘れずに入力してください。

In Component, choose the component.


バグ報告内容の詳細説明

以下の情報があると問題を再現したり場所の特定をしやすくなるのでバグ修正も早くなるでしょう:

If there is a Sub-component section, select the subcomponent.

  • Component(コンポーネント)Version(バージョン)Initial Status(初期状態)Severity(深刻度)を正確に埋めてください。 バグ報告の詳細 ページのヒントに注意するようにお願いします。
  • さらに、例えばx86_64openSUSE 11.2とか32-bit Windows 7のように、システムのバージョンとアーキテクチャをプルダウンから選んでください。
    • Linuxであれば、例えばKDEとかGNOMEのようなデスクトップ環境も選んでください。
  • LibreOfficeのバージョン。例えば 3.2.0 のような形式です。"ヘルプ/LibreOfficeについて"のダイアログで確認してください。もしLinux でビルド済みLibreOfficeを使っているなら、パッケージ管理システムでのLibreOfficeパッケージの正確なバージョンを教えてください。Windowsであれば、インストーラーの正確なファイル名と、それをどこからダウンロードしたかをお知らせください。
    • インストールして使っているロケール(UIの言語や、ドキュメントの言語)に関する情報も有益かもしれません。
    • 32ビットのLibreOfficeを64ビットの(Linux)システム上で使っているかどうか。
    • オフィシャルなLibreOfficeビルドでないのであれば、どのソースパッケージか。
  • 報告する問題の Summary(概要) を意味のあるものにするようご協力をお願いします。例えば「LibreOffice Writer 3.4.5 の問題」はとても悪い例です。ほとんどすべてのバグ報告は「問題」に関するものであり、Product(プロダクト)LibreOffice、Version(バージョン)「3.4.5」、Component(コンポーネント)「Writer」はすでに選択してわかっているので、この例文はなにも有益な情報を含んでいないことになります。よいサマリーとしては、バグ報告の詳細 にある擬似キーワードを使った「UI FILESAVE:プログレスバーがない」のようなものになります。追加でいくつか例を:
    • 悪い例: "File is broken" (「ファイル」メニューがおかしい)
    • 良い例: Menu File ▸ Save as not available (greyed out) (メニューの ファイル ▸ 別名で保存 が使えない(グレーアウトしている))
Summary(概要)を文字列で検索しやすくするために「doesn't」や「isn't」のような短縮形を避けて、代わりに、「does not」や「is not」のような完全形を使ってください。
もし報告がクラッシュまたはLibreOfficeの反応停止(ハング)に関するものであれば、これらのバグが追跡しやすいように、Summary(概要)の行(バグの「見出し」)にCRASHという単語を付記するようお願いします。
  • 問題の再現手順 重要かもしれないことはどんなにささいなことでも記載するようお願いします。その問題を簡単に再現できる手順の一例を記述してください。手順に番号をつけることで、他のユーザーに対してあなたが観測したものを参照しやすくできます。より正確にするには:
    • 悪い例:"Open document" (ドキュメントを開く)
    • 良い例:"In new empty LibO Spreadsheet document, use menu 'File -> Open (LibO dialog) - file type "Text documents" -> select attached sample document -> double click'" (「新規の空のLibreOfficeスプレッドシートについて、メニューの 「ファイル -> 開く (ダイアログを表示) - ファイルの種類「文書ドキュメント」 -> 添付のサンプルドキュメントを選択 -> ダブルクリックで開く」)
    • 問題を正しく記述してください。
      • 悪い例: "Formatting not correct" (フォーマットが違う)
      • 良い例: "I expect xxx because of yyy, but I see zzz" (yyy なので xxx になると思っていたが、結果は zzz だった)
  • その他の有益な詳細情報 (スクリーンショット、ドキュメントのサンプル、backtrace、straceなど)。特定の OS (Windows, Mac, Linux) でしか起きない不具合であれば、LibreOffice あるいはその他で特別な設定をしていないかどうかを書いてください。スクリーンショットがあれば完璧です。(Drawを使って) コメントをつけたり関連する箇所にマークをつけたり編集するとより有益になります。バグ tdf#51162 - FORMATTING: In Format Cells, setting the border's line width does not affect all borders 」における 添付ファイルが理想的な例です。
  • 添付ファイル(サンプルドキュメント等)
    • もし一つ以上のスクリーンショットを添付する場合は(DRAWドキュメントにコピーペーストして)一つのドキュメントにまとめてPDFとして添付してください。各スクリーンショットにはそれが何を示すのかを説明する簡単なコメントをつけてください。
    • もし一つ以上のファイル(例えばテスト用のサンプル一式など)を添付したければ、すべてのドキュメントを一つのzipファイルにしてそのzipを添付してください。
    • もし添付ファイルが大きすぎて(1MB以上で)Bugzillaに添付できなければ試験的アップロードページを使うことができます。

注記: スクリーンショットをとる場合、言語を英語にしておいてくれると開発者は助かります。ツール -> オプション -> 言語設定 -> 言語 で変更できます。

  • Avoid posting “me too” comments which contain no additionally useful information.
    The exception to this is when you comment on a bug that has been UNCONFIRMED so far. In that case, please provide reproduction steps (or confirm the ones given by the original reporter) and move the issue to status NEW. Note that if there are no clear reproduction steps, the issue might quickly move back to NEEDINFO, so finding a good and simple reproduction scenario is essential.
  • Refrain from adding comments along the line of “we have 1000 seats here and only this bug prevents us from migrating”, as it contains no additional information relevant to QA or to the priority of the issue.

LibreOffice is open source and your help in fixing issues that are relevant to your particular situation is most welcome. You can:

  • Employ and/or teach your own developers to work on LibreOffice. We are most happy to mentor them: see the developer’s pages.
  • Fund individuals or companies to work on specific issues - see the list of certified developers.
  • Contact The Document Foundation to help you if you have only a small amount of funding, and want to collaborate, coordinate or pool your resources with others in the same situation to fund specific fixes or enhancements.

開発者に追加の情報を提供する - 上級編

Minimum requirements

  1. OS/LibreOffice version;
  2. enumerated reproducible steps;
  3. simple attachments where appropriate; and
  4. observed/expected results.

Describing a bug report in paragraphs of text is one of the most common problems. Developers do not have the time to read paragraphs of text. Clear, succinct, enumerated steps are always better.

Windows でバックトレースを取得する方法

One report should only have a single bug in it. Grouping bugs, or listing a whole list of issues with a single document, is utterly unhelpful. In order to find developers to tackle issues, it is best to give them a single issue to focus on. They are unlikely to take on a bug that has multiple issues listed

Now, there are installers of the development debug version of LibreOffice available along with a test symbol server containing the corresponding debugging symbols. Read How to get a backtrace with WinDbg to set the debugging environment.

All bug reports should have at minimum:

現在、デバッグシンボルを含んだテストシンボルサーバーと共に、LibreOfficeの開発デバッグ・バージョンのインストーラーがあります。デバッグ環境を設定するため、How to get a backtrace with WinDbg(英語) を読んでみてください。

最終的には、クラッシュ情報をどうやって取得して開発者に送るかは、このビデオを見ることができます。

Adding a lot of extra details that aren’t relevant is another common problem. Examples include:

コピーしたテキストを新たなドキュメントに貼ってからそれをバグレポートに添付するのを忘れないでください。これによりバグが読みやすくなり、また Bugzilla のクエリーの結果に意味のないものが交じることを防いでくれます。