先週木曜にUbuntu 13.10がリリースされました。そこで今回は新しいリリースにアップグレードしたり、新しいリリースをインストールする前にまず行う「リリースノートの確認」とそれに伴う既知の問題点の調べ方について解説します。

リリースノートの位置づけ

Ubuntuは誕生から9年間、19回にわたるリリースにおいて、2回の例外（6.06が8ヵ月で、6.10が4ヵ月）を除いて6ヵ月ごとのリリースを守ってきました。リリーススケジュールを優先させる都合上、リリース前に発見された不具合であっても修正されずにリリースされることがUbuntuにはままあります。もちろん影響範囲が大きい不具合については、リリース前に対応できるように開発リソースの配分が行われます。しかしながら最終的なリリース日程を変えることはほとんどなく、リリース後のアップデートで修正することが一般的です。

そのため、Ubuntuにおける「リリースノート」は新機能や仕様変更の案内だけでなく、リリース時点で存在する既知の不具合をユーザに連絡し、場合によってはアップグレードのタイミングを遅らせることを促す、という重要な役割も存在します。

これが、リリースされる度に「まずはリリースノートを読みましょう」と何度も周知される理由の1つです。

リリースノートができるまで

Ubuntuのリリースノートには、特別に決まった作成過程は存在しません。過去の例を振り返ってみると、まずベータリリースあたりで、前回のリリースノートを複製し、古い記述を削除、バージョン名を修正します。その後、リリース直前まで各チームが大きな新機能や機能変更情報を追加したり、不具合情報を追記するという形が一般的です[1]⁠。

記述する情報の取捨選択は、各チームに任されます。記述内容も記述者任せで、とくに「既知の問題点」については、チケットの説明やタイトルをかなり大雑把に要約しただけのものが大半です。12.04の頃にはリリースノート用のプロジェクトを立てて、リリースノートに記述が必要そうな不具合はそのプロジェクトにもチケットを登録し、チケットの中でリリースノート用の文章を考える、という運用も行われていましたが、13.10の時はとくに使われませんでした。

つまり残念なことに、リリースノートの品質はリリースによってかなり波が存在します。

本家のリリースノートは、Wikiで作成されています。大抵の場合は開発コード名の下に「ReleaseNotes」をつけた名前が使われます。たとえば先週リリースされたUbuntu 13.10（コード名：Saucy Salamander）の場合は、次のような名前で作成されました。

https://wiki.ubuntu.com/SaucySalamander/ReleaseNotes

Ubuntu以外のフレーバーについては、フレーバー毎の方針に任せています。Kubuntuは別サイトでリリースノートを作成していますし、Xubuntuなどは上記リリースノートのサブページを作成しています。

日本語版リリースノート

Ubuntuのリリースノートの重要性を鑑みて、Ubuntu Japanese Teamではできるだけ早く日本語版のリリースノートを提供できるよう、リリース日は昼夜を問わず作業を行っています（注2、注3⁠）⁠。

翻訳は正式なリリースアナウンスが流れてから開始しています。これはリリースアナウンスが流れる前後はリリースノートがかなり頻繁かつ大幅に更新されることが理由で、翻訳リソースをできるだけ最新のリリースノートに投入するために、そのような措置を行っているのです。

日本語版のリリースノートは大抵の場合、本家ページのサブページとして作成しています。

https://wiki.ubuntu.com/SaucySalamander/ReleaseNotes/Ja

さらに日本語版のリリースノートにはただの本家の翻訳だけではなく、「⁠日本語翻訳版独自の記述」として、日本語環境にまつわる情報も掲載しています。Ubuntu上で日本語を使う人にとって必要となる機能（とくに日本語入力やフォントまわり）の仕様変更や不具合、回避策の手順などが詳しく書いてありますので、新しいリリースへのアップグレード前には必ず読むようにしておきましょう。

リリースノートの翻訳自体はWikiにログインできるアカウントがあれば誰でも参加可能です。ただし通常のUIやドキュメントの翻訳と比べると、英語ネイティブでない人が書いた査読を経ていない文章、「⁠とりあえず注意書きとして書いた」という感じのメモ、不具合チケットのコメントからの抜粋、などを書いた人の意図や元々のチケットの内容を調べ、推測しながら翻訳しなくてはならないため、難易度はかなり高くなります。いきなり翻訳をはじめるよりは、まずは他の人が翻訳した内容が正しいかどうかの確認からはじめると良いでしょう。

翻訳の手順はリリース毎に若干異なります。公式のWikiページはリリース直後はとてもとても、とっても重いので、一時的に別のWikiにデータを退避して行うこともあります。このため翻訳を行いたい場合は、はじめに日本語版リリースノートのどこかに書いてある手順や注意書きを参照してください。

この「注意書き」は、Wikiページの上部もしくはソースに書くようになっています。通常のページの上部や下部に手順や注意書きが見当たらないようなら、ページのヘッダにある「その他のアクション＞Wikiテキスト」からページのソースを表示してください。「⁠編集」を選んでしまうと一時的にページの編集がロックされてしまいますので、本当に編集するとき以外は使わないようにしてください。もし間違って選んでしまったら、編集ページにある「キャンセル」ボタンを押しましょう。

もちろんリリース後であっても、誤字・脱字を見つけた時はUbuntu Japanese Teamのメーリングリストなどで報告してもらえると大変助かります。

リリースノートの使い方

リリースノートにはおもに次の4つの情報が掲載されています。

• 新リリースの入手方法
• 新機能
• 既知の問題点
• 日本語版独自の情報

最初の「新リリースの入手方法」はリリース毎に大きく変わるものではありませんし、変わる場合は新機能のほうに掲載されるでしょうからそれほどじっくり読む必要はありません。

「新機能」は今回のリリースで大きく変わったところだけでなく、毎回のリリースでバージョンだけ変更しているテンプレート部分などがあります。デスクトップ版とサーバ版、両方に共通する部分、でセクションを分けているので、気になったところだけを読むようにすれば良いでしょう……と言いたいところなのですが、ここに既知の不具合に関する情報や古いバージョンからアップグレードする場合の注意点などが掲載されることもあるので、必ず一通り目を通すようにしておきましょう[4]⁠。

「既知の問題点」と「日本語版独自の情報」は前節でも述べたように、リリースノートの最も重要な部分です。ここは関係あるかないかに関わらず、一度は読むようにしてください。「⁠既知の問題点」については、Ubuntuのチケット管理システムでもある「Launchpad」のチケット番号が一緒に記載されています。既に解決されたかどうかは、チケットのそのリリース用のステータスが「Fix Released」になっているかどうかで判断できます。チケットステータスの変更をメールで受信したい場合は、Launchpadにログインした状態でそのページにアクセスし、ページ右側の中程にある「You are not directly subscribed to this bug's notifications.」というリンクをクリックすることで情報通知を有効にしてください。

もしリンクが有効になっておらず番号だけ記載されている場合は、面倒ではありますがURLを手動で入力してください。たとえばチケット番号が「123456」であれば、以下のURLを入力することで、そのチケットにアクセスできます。

https://bugs.launchpad.net/bugs/123456

いつアップグレードするべきか

リリースノートを読んで次に行うことは、「⁠アップグレードするべきかどうか」の判断です。

リリースノートには特段問題が見受けられなかったのであれば、アップグレードに向けて準備をはじめても良いでしょう。ただしすぐにアップグレードボタンを押すのは、事を急ぎすぎているかもしれません。新リリースの直後は、利用者がぐっと増えるため、開発版のとき以上にいろいろな不具合が発見・報告されます。これらのリリース後に発見された不具合は、そのほとんどがリリースノートには反映されません。本当にアップグレードしても問題ないかどうかは、サブPCや仮想マシンなどで評価するように心がけましょう。それが面倒な場合は、リリースから1ヵ月ぐらい待つのも良いでしょう。大きな不具合については、だいたいそれくらいの間に修正されます。

もちろん、既にサブPCや仮想マシンなどでしっかりと評価済みである、どうしても使いたい新機能がある、リリース前後に見つかった問題点を解決し貢献したい、といった場合は積極的にアップグレードを行っても良いでしょう。

普段から日本語Remixを利用している場合は、まず日本語Remixがリリースされるまで待つようにしましょう。日本語Remixはリリース版イメージをベースに作成されますが、その過程で新たな問題が見つかり、対策が必要な場合もあります。日本語Remixがリリースされるということは、ある程度それらの問題にケリがついている状態でもあるので、アップグレードするかどうかの1つの指針になるでしょう。

アップグレードを遅らせる場合、「⁠サポート期間」についても注意が必要です。Ubuntu 13.04からは通常のリリースのサポート期間が9ヶ月に短縮されました。これはつまり13.04のサポートは、2014年の1月に切れるということです。13.04の利用者は否が応でも来年の1月には13.10へとアップグレードをする必要があることを覚えておいてください。

そもそもアップグレードではなく、新規にインストールするという方法もあります。この方法には、古い設定や普段使っていないパッケージが一掃されてPCの中身がすっきりする[5]⁠、半年に一度バックアップを取るという癖が付く、というメリットがあります。逆に、設定やパッケージのインストールをやり直さなくてはいけない[6]⁠、バックアップ漏れがあれば回復できない[7]⁠、ボタン1つで済むアップグレードに比べると手間がかかる、といったデメリットも存在しますので、個人の用途や時間、気力にあわせて判断しましょう。

新機能や変更点の調べ方

リリースノートにはすべての新機能が網羅されているわけではありません。とくに標準ではインストールされないパッケージの情報は、個別に調べる必要があります。

日本語で情報収集したい場合は、リリース前後のUbuntu Weekly TopicsやRecipeがおすすめです。Topicsにはおもに新機能が導入されるまでの経緯や議論の内容、Recipeには新機能の基本的な使い方が掲載される傾向があります。

Ubuntuの標準インターフェースはUnityになりましたが、各種アプリケーションがGNOMEベースであることには変わりありません。そのため、GNOMEのリリースノートも、新機能情報のソースとしては有効でしょう。ただし、最近のUbuntuは最新のGNOMEではなく、1つか2つ前のリリースをベースに、バージョンの異なるアプリケーション群を組み合わせて使っているため、参照するリリースノートを間違えないようにしてください。このあたりは第293回「Ubuntu GNOME 13.10の変更点」の説明が参考になるでしょう。同様にKubuntuならKDEの、XubuntuならXfceのリリースノートも確認すると良いでしょう。

英語でも良いのであれば、Ubuntuメンバーのブログ集である「Planet Ubuntu」やUbuntuニュースサイトとしては定番の「OMG! Ubuntu」や「Web Upd8」「⁠iloveubuntu」もおすすめです。

個別のソフトウェアの変更点を知りたい場合は、採用されているバージョンを調べて、ソフトウェアのWebサイトで変更履歴を確認します。個々のリリースで採用されているバージョンを調べる方法はいくつかありますが、まずはそのソフトウェアの「パッケージ名」を知る必要があります[8]⁠。

一番かんたんなのは、Ubuntuパッケージ検索で検索する方法です。このサイトではパッケージ名だけでなく、ファイル名の一部でも該当するパッケージを検索できます。

実行コマンド名やファイルパスがわかっているのであれば、端末からdpkgコマンドを用いてパッケージ名を検索できます。たとえば次のコマンドを実行することでevinceコマンドを提供しているパッケージ名は「evince」であることがわかります。

$ dpkg -S `which evince`
evince: /usr/bin/evince

特定のファイルを検索対象にしたい場合は、「⁠`which evince`」の部分をファイルのフルパスに変更してください。

パッケージ名がわかれば、あとはUbuntuパッケージ検索でそのパッケージのページを開き、ページ右上から調べたいリリース名を選べば、バージョンを確認できます。そのバージョンを元に、ソフトウェアのサイトで変更履歴などを確認すると良いでしょう。ちなみにパッケージのページの右側にある「Ubuntuでの変更履歴」はパッケージに関する変更履歴です。ソフトウェアのそれとは若干異なりますので注意してください[9]⁠。

未知の問題に遭遇したら

アップグレード後に、不幸にもリリースノートに掲載されていない不具合に遭遇した場合はどうすれば良いのでしょうか？

もし使用中にクラッシュダイアログが表示されたのなら、そのままデータを送信しましょう。若干の時間はかかりますが、Launchpadのアカウントさえあれば、自動的に必要なデータを収集し、アップロードしてくれます。もし同じような不具合を誰かが報告済みなら、そのチケットを表示してくれますので、「⁠リリースノートの使い方」のときと同じように情報を通知を有効にすれば良いでしょう。

もし何も表示されない場合やそもそも起動できない場合は、GNOME端末からコマンドを使った起動を試してみましょう。この場合実行コマンドと適切なオプションを知っておく必要がありますが、うまくいけば解決のヒントとなるエラーメッセージが表示されるかもしれません。

エラーメッセージがわかれば、あとはGoogleで検索するだけです。運が良ければ対応策も入手できるかもしれません。ヒット数が多いようなら、検索単語に「site:launchpad.net」や「site:askubuntu.com」を追加してみましょう。前者はUbuntuのチケット管理システムでもあるLaunchpadの情報のみを、後者はUbuntuの半公式Q＆AサイトであるAskUbuntuの情報のみを検索してくれるので、よりUbuntuに関連した情報を入手できます。

GNOME端末にはエラーメッセージが表示されないようであれば、ログも調べて見ると良いでしょう。たいていのログは「/var/log/」以下やホームディレクトリ以下に保存されます。たとえば次のコマンドを実行すれば、/var/log以下にあるファイルのうち5分以内に更新されたファイルのリストを取得できるので、それらのファイルにエラーログが残っていないか確認してみると良いでしょう。

$ sudo find  /var/log -mmin -5 -ls
3408360  460 -rw-r-----   1 syslog   adm        465029 10月 20 20:44 /var/log/syslog
3408955    8 -rw-r-----   1 root     adm          6369 10月 20 21:02 /var/log/cups/access_log
3410796   16 -rw-r-----   1 syslog   adm         14763 10月 20 21:06 /var/log/auth.log
3408747   48 -rw-r--r--   1 root     root        47055 10月 20 20:27 /var/log/Xorg.0.log

同様の不具合が報告されていないのであれば、Ubuntu Japanese TeamのWikiにある手順を参考にLaunchpadへの不具合報告を試してみましょう。

さいごに

「リリースノート」は情報の宝庫です。これはUbuntuに限らず、あらゆるプロジェクトに通じる話でもあります。新しいソフトウェアに触れてみるときや新しいバージョンを試してみるときに「リリースノート（Release Notes⁠）⁠」や「変更履歴（ChangeLog⁠）⁠」に目を通す癖をつけておけば、不具合に遭遇して時間を潰してしまう可能性がぐっと減るだけでなく、すごい便利な新機能と出逢える（ことがある）というおまけも付きます。

限りある人生を豊かに暮らすためにも、リリースノートは積極的に活用していきましょう。