春らしい花粉に苛まれる日も増え、日本にもたくさんの「新人さん」が発生する季節を迎えました。新しい職場や研究室によっては、新人の最初の作業として「自分用の作業PCにLinuxディストリビューションをインストールする」というイベントに遭遇するかもしれません。

今回は「Ubuntuをインストールしたは良いものの、早速見つけた不具合をどう報告・修正していいのかわからない。（⁠ここには各自お好きなソフトウェアを入れてください）ならわかるのに⁠」⁠、そんな風に考えられる活きの良い「新人さん」に向けて、Ubuntuの不具合報告について紹介しましょう。

ちなみに正真正銘の初心者向けのUbuntu講座については、過去に次のような記事を書いていますのでそちらもご参照ください。

• 第463回「新学生・新社会人向けのUbuntuデスクトップ講座2017」
• 第466回「新学生・新社会人向けのUbuntuサーバー講座2017」

また、Ubuntuの不具合報告の中心となる「Launchpad」については、少し昔（15年前）に書かれた第44回「Launchpadの使い方」も参考になります。

何の不具合なのか・再現性はあるのかを確認する

当たり前のことではありますが、何の不具合なのか（そしてそもそも不具合なのかどうか）がはっきりしないと、何を調査・修正すれば良いかがわかりません。よってまずは不具合の大本となるソフトウェアを突き止めましょう。Ubuntuの場合、ソフトウェアを指定せずに報告することも可能ではありますが、特定できていたほうが修正に向けてのゴールが近くなります。

また、再現性があるかどうかで調査の難易度はぐっと変わります。どのような構成で、どのようなソフトウェアを動かしていたときに、どのような手順を実施すれば不具合を発生させられるかを明確にすることをおすすめします。できれば手順もよりコンパクトで再現性の高いものにしておくと、より良い報告になります。

特定の手順を踏むと、特定のアプリケーションが確実に落ちる、なんて不具合なら報告も楽になります。ただし後で紹介するように、Ubuntuにはソフトウェアがクラッシュしたら自動的に障害情報を収集・報告する「apport」という仕組みが備わっているため、とりあえずはこれにお任せすることになるでしょう。

特定のソフトウェアがはっきりしていたら、それに紐づくパッケージ名を調べましょう。Ubuntuの不具合報告は、パッケージ単位での報告となります。たとえば特定の実行ファイルだとわかっているなら、次のようなコマンドでパッケージ名がわかります。

$ dpkg -S 実行ファイル名

もし見つからないようなら、フルパスで検索しましょう。ちなみに最近のUbuntuは、「⁠/bin」や「/sbin」は「/usr/bin」や「/usr/sbin/」へのシンボリックリンクになっています。しかしながらパッケージ側はこのパス変更に追随できていないものも多く、「⁠/usr/bin/foo」としてインストールされているけれども、パッケージデータ上は「/bin/foo」を使っているというケースも存在するのです。よって「dpkg -S /usr/bin/foo」で見つからない場合は、「⁠dpkg -S /bin/foo」も試してみてください。これは将来的なリリースでは解消される見込みです。

この手順で判明したのは「バイナリパッケージ名」です。Ubuntuでも採用しているDebianパッケージは、特定のソースパッケージから複数のバイナリパッケージをビルドする形態を採用しています。よってバイナリパッケージには、元となるソースパッケージが存在します。不具合を報告する場合は、このソースパッケージの名前が必要となるのです。

ソースパッケージ名の確認方法は簡単です。次のように「apt show バイナリパッケージ名」を実行してみましょう。

$ apt show バイナリパッケージ名
Package: バイナリパッケージ名
Version: バージョン
Priority: important
Section: editors
Source: ソースパッケージ名
Origin: Ubuntu
（以下略）

「Source:」フィールドにソースパッケージの名前が書かれています。もし「Source:」がない場合は、「⁠バイナリパッケージ名＝ソースパッケージ名」となります。

既知の不具合か探してみよう

パッケージ名がわかったら、次は既知の不具合か調べてみましょう。もしかしたらそこに回避策も載っているかもしれません。Ubuntuの各パッケージの不具合報告は次のURLにまとめられています。

https://bugs.launchpad.net/ubuntu/+source/ソースパッケージ名

この不具合報告は、優先度・チケット番号の順でソートされています。最新の報告を読みたいなら「Order by」のところの「Number」をクリックしてください。またクローズされているチケットも見たいのであれば、「⁠Advanced search」から「Status」にある「Fix Released」やそれ以外もチェックを入れて、「⁠Search」ボタンを押しましょう。

もし、明確なエラーメッセージがわかっているのであれば、メッセージで検索したほうがはやい場合もあります。Googleだと次のような内容で検索すると良いでしょう。

"エラーメッセージをダブルクオーテーションでくくる" site:bugs.launchpad.net

エラーメッセージで検索する場合、タイムスタンプ等を省いておきましょう。たとえば、次のようなエラーメッセージを検索する場合に、いくつかのポイントが存在します。

 4月 03 17:27:30 nuc pulseaudio[2680]: org.freedesktop.DBus.Properties.Get
  /org/bluez/hci0/dev_20_74_CF_BC_96_A7/sep1/fd0 Volume failed:
  org.freedesktop.DBus.Error.InvalidArgs: No such property 'Volume'

上記は本来1行なのですが、説明しやすいように長い行を折り返しています。

まず最初の「4月 03 17:27:30 nuc」は、実行した時刻とマシン名であり、他のユーザーのエラーメッセージと一致することはほぼありません。よってこれは省きます。次に2行目の「/org/bluez/hci0/dev_20_74_CF_BC_96_A7/sep1/fd0」も、絵単語ではない英数字の羅列になっていることから、システム固有の文字列っぽく見えます。そうすると検索する際は次のようにすれば良さそうです。

"org.freedesktop.DBus.Properties.Get" "Volume failed: org.freedesktop.DBus.Error.InvalidArgs: No such property 'Volume'"

ダブルクオーテーションでくくった文字列をふたつにしましたが、Googleなら間を「*」とワイルドカードにしてしまう方法もあります。

「site:bugs.launchpad.net」で見つからないようであれば、「⁠site:ubuntu.com」も試してみてください。メーリングリストやフォーラムの議論が得られることもあります。どちらも見つからなければ「site:」以降をなくしてしまって、いろんなサイトを見てみる方法もあります。もちろんソフトウェアの開発サイトを確認するのも重要です。

特に一般的なエラーであれば、ArchWiki（日本語版）にはドンピシャリな回答が載っていることも多いです。「⁠Arch」と名前が付いていますが、Arch Linuxに限らずあらゆるLinuxのユーザーに恩恵と知識を与えてくれる、聖典のような存在です。

ここまで調べても情報が見つからなければ、自分で不具合を報告することになります。

まずはアップストリームへの報告を検討しよう

Ubuntuは様々なソフトウェアの集合体です。リポジトリから提供されるソフトウェアは、それぞれ開発元が存在し、それに対してUbuntuはUbuntu向けのパッチを当ててパッケージングしています。このときあるパッケージの開発元を、Ubuntuでは「アップストリーム（upstream）」と呼びます。

見つけた不具合がもしアップストリームでも（つまり最新版のUbuntuのパッチが当たっていないソフトウェアでも）発生するようであれば、まずはアップストリームへ報告することを検討してください。これは次の利点が存在します。

• アップストリームの開発者のほうがそのソフトウェアに詳しいため、より「正しい」解決策を導ける可能性がある
• アップストリームで修正されると、Ubuntu以外のユーザーも恩恵を受けられる

ただし次のような問題もあります。

• Ubuntu固有の事象かもしれないため、アップストリームの開発者の環境では再現できない可能性がある
• アップストリームの修正がUbuntuに反映されるまでタイムラグがある

前者の問題については、報告時に再現環境を明示していれば、開発者側で汲み取ってくれるケースも多いです。ただしできれば、アップストリームの最新版でも再現するかどうかを確認しておいたほうが話がスムーズに進みます。また、Ubuntuのバージョンが古く、最新版では解決済みというケースもあります。この場合は、Ubuntuに該当するパッチを取り込むよう依頼する手順が必要です。

後者のほうがより影響が大きな問題でしょう。アップストリームの新しいバージョンで修正されたとしても、それが取り込まれるのはUbuntuの開発版だけです。いくつかの例外はあるものの、Ubuntuはリリース後にソフトウェアのバージョンをあげることはありません。もし修正した内容を、Ubuntuのリリース済みのバージョンにも適用したい場合は、不具合を修正する必要最小限のパッチを作成し、それを取り込む必要がでてきます。

Ubuntuで不具合を報告するには

さて、ようやくUbuntuへ不具合を報告する時間です。報告方法は次の3パターン存在します。

• クラッシュ時に表示されるインターフェースから報告する
• ubuntu-bugコマンドを使って特定のパッケージについて報告する
• LaunchpadのWeb UIから報告する

順番に見ていきましょう。

クラッシュ時に表示されるインターフェースから報告する

Ubuntu上のソフトウェアがクラッシュするとLinuxカーネルの/proc/sys/kernel/core_patternという仕組みを経由して、Apportによって障害情報が収集されます。これは/var/crash以下にアーカイブされて保存されますが、Ubuntuデスクトップの場合、次のような画面が表示されて、障害情報を報告可能です。

ここで「送信」ボタンを押すと、障害情報がUbuntuに報告されます[1]。この時のデータは、セキュリティ脆弱性のヒントになるかもしれないため、一旦プライベートな情報として権限を持った人しかアクセスできない状態になります。また、同じクラッシュ情報はある程度まとめられるようです。この流れで報告されたエラーは「https://errors.ubuntu.com/」として、概要や報告数を確認可能です。

「送信しない」ボタンを押しても、「⁠/var/crash」に情報が残っていたら「ubuntu-bug /var/crash/クラッシュファイル」で送信が可能です。また中身の閲覧も可能になっています。

ちなみに毎回障害情報を送信するかどうか聞かれたくない場合は、次のコマンドで問い合わせを無効化できます。

$ gsettings set com.ubuntu.update-notifier show-apport-crashes false

そもそも障害情報を収集したくない場合は、/etc/default/apportのenabledを「0」にしてください。

# set this to 0 to disable apport, or to 1 to enable it
# you can temporarily override this with
# sudo service apport start force_start=1
enabled=0

変更後に「sudo systemctl restart apport.service」で設定が反映されます。

ubuntu-bugコマンドを使って特定のパッケージについて報告する

クラッシュしない不具合についても、ubuntu-bugコマンドで報告できます。この場合は、再現手順等を自分でまとめて報告する必要があります。

まず、あらかじめ「Launchpad」のアカウントを作成しておいてください。この先、報告に必要になります。LauchpadのアカウントはUbuntu SSOとして提供されており、Ubuntuの各種サービスで共通して利用できますし、Launchpadのアカウントを作ってCode of ConductにサインすればPPAというパッケージリポジトリも使えます。Ubuntuをよく使うのであれば作成しておいて損はないでしょう。

アカウントを作成したら、問題となるソフトウェアのPID（プロセスID）やパッケージ名を指定して、次のように報告します。

$ ubuntu-bug PIDもしくはパッケージ名

すると管理者権限を要求したあとに、システム情報を収集し、次のようなダイアログが立ち上がります。

ここで送信ボタンを押すと、ウェブブラウザーが開き、Launchpadの報告画面に遷移します。

タイトルを入力して「Next」ボタンを押すと、似たような不具合タイトルをリストアップしてくれるので、同じ不具合か確認しておきましょう。もし同じ不具合がなければ、「⁠No, I need to report a new bug」ボタンを押します。

不具合の概要は、他の開発者が最初に参考にする情報です。情報は多すぎず少なすぎず、さらにわかりやすく英語で書いておくことが求められます。とは言うものの、最初は塩梅がわからないでしょう。画像にざっくりとテンプレートを書いておいたので、そちらも参照してください。

「This bug is a security valnerability」は、明らかにセキュリテ脆弱性であり、その再現手順等の公開がためらわれる場合にチェックを入れます。問題なければ「Submit Bug Report」を押して報告完了です。

ちなみにubuntu-bugコマンドは、サーバー版でも利用可能です。この場合、情報をアップロードしたあとに報告用のURLが表示されます。あとはそのURLに任意のマシンのブラウザーからアクセスすればOKです。

LaunchpadのWeb UIから報告する

ubuntu-bugコマンドを使わずに直接Web UIから報告することも可能です。ただし、これは「どのパッケージの問題かがはっきりしており」なおかつ「システム情報等がなくても簡単に再現可能」な場合にのみ限定してください。その判断は正しく行うのはおそらく難しいと思うので、自分で報告して自分でパッチ作って、自分で修正パッケージを作成できる場合に限定されるでしょう。

不具合を報告する場合、次のようなURLにアクセスします。

https://bugs.launchpad.net/ubuntu/+source/ソースパッケージ名/+filebug

あとのUIはubuntu-bugを使った時と同じです。

報告したそのあとは

不具合報告は重要です。SNSに不具合をツイートするだけで、修正されることはまずありません。もし修正されたのだとしたら、開発者がよほどそのSNSが大好きか、ものすごく運が良かった特殊ケースと考えるべきです。そんなところで限りある運を使い果たすぐらいなら、個々のソフトウェアの正しい手順を踏んで、不具合を報告しましょう。

多少手順を踏み外していても、誠実な対応を心がければ、大抵の開発者は笑ってフォローしてくれます[2]。それよりは報告されることが重要なのです。

ただし残念なことに、たとえ完璧な報告であっても、報告しただけで作業が止まってしまうことも多々あります。その場合は、たとえばアップストリーム側で修正した際のコミットがわかっているならそのURLを貼り付けたり、Ubuntuコミュニティのメーリングリストやフォーラムで「不具合らしきものを見つけたので報告してみた。この先どうすれば良いだろうか？」と相談を持ちかけてみるもの良いかもしれません[3]。日本語で相談したければ、Ubuntu Japanese LoCo Teamのメーリングリストに投げかけてみましょう。

もっと強力な手段は、自分で修正してしまうことです。これは慣れるまで相応の時間がかかりますが、慣れてしまえばそれなりに応用が効くノウハウとなります。まずは対象となるソフトウェアについてある程度の状況を把握し、次にUbuntuの（Debianの）パッケージング手法について学ぶことになります。後者については、まず「Debian新メンテナーガイド」を軽く読むところから始めるか、各種イベント・勉強会で詳しそうな人を捕まえて相談にのってもらう方法もあります。

いずれにせよ、「⁠不具合とはそう簡単には修正されないもの」と思える心の余裕（と顧客への説得力やガチャ運）が重要です。