「Git でバグを bisect する」の版間の差分
細 (AshMyzk がページ「Bisecting bugs with Git」を「Git でバグを bisect する」に移動しました: ページ名を翻訳) |
(→より小さなカーネルを構築する: 削除。「カーネル」へ移動済み。) |
||
67行目: | 67行目: | ||
== ビルドの高速化 == |
== ビルドの高速化 == |
||
− | |||
− | === より小さなカーネルを構築する === |
||
− | |||
− | [[modprobed-db]] を使ってローカルシステムに必要なモジュールだけをビルドしたり、 {{ic|make localmodconfig}} によってカーネルビルド時間を短縮することができます。もちろん、例えばネットワークの問題をデバッグするためのサウンドドライバなど、無関係なドライバを完全に削除することも可能です。 |
||
=== キャッシュ === |
=== キャッシュ === |
2023年11月14日 (火) 22:36時点における最新版
Mesa や Linux カーネルなどのプロジェクトで発生したバグを報告する際、 問題のあるコミットが何であるかを確認するために、最後に動作した既知のバージョン と問題のある新しいバージョンとの間でバイセクトを行うよう求められることがよくあ ります。Arch では、AUR の機能のおかげで、これは非常に簡単に行うことができます。
古いリリースに戻す場合
問題を引き起こしているのが新しいパッケージのリリースであることを確認することは有用かもしれません。Arch での パッケージのダウングレード は、古いバージョンのパッケージがシステムにキャッシュとして保存されていれば、簡単に実行できます。
git からのパッケージの構築
bisect を行うには、git からパッケージのバージョンをビルドする必要があります。これは AUR から -git パッケージをビルドすることで実現できます。
bisect のセットアップ
パッケージのビルドが成功したら、src/
ディレクトリ内の git ルートディレクトリに移動する必要があります。git ルートディレクトリの名前は、多くの場合pkgname
と同じです。(または接尾辞 -git
を除いたもの)
$ cd src/git_root
そこから、bisecting するプロセスを開始できます:
$ git bisect start
次のコマンドは、bisecting する場所を指定するために使用できるすべてのタグを表示します:
$ git tag
前の例に続いて、バージョン oldver は機能したが、newver は機能しなかったと想定します。
$ git bisect good oldver $ git bisect bad newver
良いバージョンと悪いバージョンのタグが付けられたので、コミットのテストに進むことができます。
Bisecting
PKGBUILD のあるディレクトリに戻ります。前のセクションで説明したディレクトリにまだいる場合は、次のように実行できます:
$ cd ../..
これで、パッケージの特定のリビジョンを再構築してインストールできます:
$ makepkg -efsi
新しいパッケージがインストールされたら、以前発見したエラーをテストすることができます。前のセクションで行ったディレクトリに戻ります。
$ cd src/git_root
問題が発生した場合は、リビジョンが不良であったことを伝えてください:
$ git bisect bad
問題が発生しなかった場合は、リビジョンが良かったことを伝えてください:
$ git bisect good
そして、このセクションの冒頭で説明したことをもう一度行い、git bisect が問題のあるコミットを指定するまで繰り返します。
ビルドの高速化
キャッシュ
gcc
を使ってビルドされた大きなプロジェクトを二分する場合、 ccache を有効にすることでビルド時間を短縮できるかもしれません。しかし、キャッシュの効果を実感できるまでには、何度かビルドを繰り返す必要があるかもしれません。キャッシュがヒットする可能性は、一般に切断点間の距離が短くなるにつれて高くなります。
パッケージの復元
元のバージョンのパッケージに戻すには、pacman を使ってリポジトリからパッケージをインストールします。