LibreOfficeのバグ報告方法

From The Document Foundation Wiki
< QA‎ | BugReport
Jump to: navigation, search
本ページはGlobal Wikiからの有志による翻訳ページです。未翻訳があることや内容が古い場合があります。最新化、翻訳にご協力お願いします。
日本語独自の情報についてまとめることを目的として、日本語コミュニティによって運営されているページとして 日本語コミュニティ独自ページ があります。
URLが wiki.documentfoundation.org/JA で始まっていて、カテゴリーがJAのページです。
そちらもご利用ください。

素晴らしい第一歩!

あなたは LibreOffice に対して重要な貢献をしようとしています。明確なバグレポートは開発者を支援するためにはとても重要なのです。ご協力ありがとうございます! 作業を簡単にするために、皆様の助けになるようないくつかのヒントをお伝えします。
バグトラッキングツールにまだ追加されていないバグを登録することは非常に重要です。
皆さんの問題がすでにバグとして報告されていることもありますが、そのときは有益なコメントを加えることもできるでしょう。それについては: Most Frequently Reported Bugs for LibreOffice (LibreOffice もっともよくレポートされるバグ; 英語) をご覧ください。


次のページもバグレポートの登録の参考になります。

(このセクションの下の方にも素晴らしい詳細があります。)

一般的な情報

バグ報告が目指す唯一のゴールは、当該の不具合を 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 で報告することができます。


Bugzilla でのバグ報告手順

  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 データベースに登録されます。


追加のヒント

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


Ubuntuでのバグの報告

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

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


バグ報告内容の詳細説明

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

  • 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に添付できなければ試験的アップロードページを使うことができます。

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


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

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

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.

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

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

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

Mac OS X でデバッグ情報を取得する方法

デバッグ情報はなぜアプリケーションがクラッシュしたりフリーズしたりしたかを解析するためにとても有用です。Mac OS X では、追加のソフトウェアをインストールすることなく、標準のデバッグ情報をとても簡単に取得することができます(この情報は単純なスタックトレースで、シンボル情報は欠落していますが、にもかかわらずとても有用です)。

厳密なやり方は Mac OS X のバージョンおよび設定で変わりますが、一般的には次のようにしてデバッグ情報を得ることができます。

  • アプリケーションがクラッシュしたとき、Mac OS X は「LibreOffice が予期しない理由で終了しました。」というダイアログを表示し、Apple にレポートを送るかどうかを聞いてきます。「レポート...」 と書かれたボタンを推してください。「LibreOffice の問題レポート」というもっと大きなダイアログが開きます。「問題の詳細およびシステム構成」の下に、技術的な詳細からなる長いテキストが記入されたエディットフィールドがあります。この長いテキストをクリックし、⌘ Cmd+a を押してテキストを全選択し、⌘ Cmd+cでコピーして、何らかのテキストエディター (Apple の TextEdit など) に移動して ⌘ Cmd+v を押してテキストを貼ります。それからこのテキストを新規のファイルとして保存します。プレインテキスト (.txt) が最もよい形式でしょう。このファイルをバグレポートに添付してください (Apple にレポートを送る必要は ありません。「問題レポート」ウィンドウでは「送信しない」 ボタンを押しましょう)。
  • アプリケーションがハングしたりフリーズ (固まった) りしたとき、⌘ Cmd+Alt+Esc を押すことで強制的に終了できます。Mac OS X は「アプリケーションの強制終了」というタイトルのダイアログウィンドウを表示し、どのアプリケーションを終了したいか聞いてきます。リスト中のどのアプリケーションがハングまたはフリーズしたかを知るには、「応答なし」と出ているものがヒントです。それを選択して「強制終了」ボタンを押してください。システム設定にもよりますが、Apple にレポートを送るかどうか聞かれるでしょう。送る、と答えたら、先ほどの「問題レポート」ウィンドウと同じ物が出ますので、同様にデバッグ情報のテキストをコピーしてセーブすることができます。

注意:システム設定あるいはユーザー設定によっては、Apple へのレポートを行うかを聞かれたり聞かれなかったりします。もしかしたらこれらのダイアログは admin ユーザーでログインしないと利用できないかもしれません。

Linux でバックトレースを得る方法

バックトレースはアプリケーションがクラッシュしたりフリーズしたりした原因を解析するのに非常に有用な情報です。以下の手順で取得できます:

  1. 存在するなら、libreoffice*-debuginfo パッケージをインストールしてください (Debian、Ubuntu およびその派生系では、パッケージ名は libreoffice-dbg です)。もしこのパッケージがなければバックトレースは少し有用でなくなりますが、それでもまだなにかの情報を提供してくれる可能性があります。
  2. 端末 / シェルを起動します (いくつかのディストリビューションでは Ctrl+Alt+T を押せばよいです)。
  3. soffice --backtrace を起動します。
  4. クラッシュするバグを再現してみます。もしハングアップする場合は - アプリケーションをハングさせておいて、他のコンソールから pkill -15 soffice.bin と叩くことで強制的にクラッシュさせることができます。
  5. 得られた gdbtrace.log ファイルをバグレポートに添付します。

strace ログを取得する方法 (Linux)

strace はあるプロセスが発行したシステムコールのトレースです。ファイル I/O に関係したような不具合があった場合、OS レベルで何が起きているかを確実に知る方法となります。また、プログラムが何を実行しようとしてハングしたかを見つける手軽な方法ですし、LibreOffice が実行されているシステムの情報を得ることもできます。

  1. 端末を起動します。
  2. soffice --strace を実行します。
  3. 不具合を再現させます。
  4. ログを圧縮します: bzip2 strace.log
  5. strace.log.bz2 ファイルを、バグレポートに添付します。

valgrind ログを取得する方法 (Linux)

valgrind ログは他の方法では実に発見が難しい、隠れたメモリ破壊のエラーを追いかける非常に有用なものです。CPU をエミュレートすることによって情報を集めるので、ちょっとした問題としてはコードの実行が80倍ほど遅くなることで、ちょっと遅すぎると感じることでしょう。良い点としては他の方法では見つけ出せない不具合を発見できることで、ピンポイントで不具合箇所を発見できるので開発者が修正するのが容易であることです。遅さを我慢してくれることは大歓迎です。Valgrind はまた、しばしば正の誤検知 (訳注:誤っていない部分を誤りと判定すること) もします。

  1. libreoffice*-debuginfo パッケージをインストールします。(お使いの Linux ディストリビューションで提供されているなら)
  2. valgrind パッケージをインストールします。
  3. 端末を起動します。
  4. soffice --valgrind >& /tmp/valgrind.log
  5. 我慢してください ... 80倍というのは大層な遅さです ... 不具合を再現します。
  6. /tmp/valgrind.log をバグレポートに添付します。