「Git でバグを bisect する」の版間の差分

提供: ArchWiki
ナビゲーションに移動 検索に移動
78行目: 78行目:
 
{{Note|キャッシュが有効なのは、''まったく同じ'' ソースをコンパイルするときだけです。また、カーネルを bisect するために {{ic|make clean}} をする必要は ''無い'' ので、 ccache は完全に無駄であることを意味します}}
 
{{Note|キャッシュが有効なのは、''まったく同じ'' ソースをコンパイルするときだけです。また、カーネルを bisect するために {{ic|make clean}} をする必要は ''無い'' ので、 ccache は完全に無駄であることを意味します}}
   
  +
== パッケージの復元 ==
== Restoring package ==
 
   
  +
元のバージョンのパッケージに戻すには、[[pacman]] を使ってリポジトリからパッケージをインストールします。
Reverting to an original version of the package can be done by installing the package from repositories with [[pacman]].
 
   
 
== See also ==
 
== See also ==

2022年2月8日 (火) 01:33時点における版

Mesa や Linux カーネルなどのプロジェクトで発生したバグを報告する際、 問題のあるコミットが何であるかを確認するために、最後に動作した既知のバージョン と問題のある新しいバージョンとの間でバイセクトを行うよう求められることがよくあ ります。Arch では、AUR の機能のおかげで、これは非常に簡単に行うことができます。

古いリリースに戻す場合

問題を引き起こしているのが新しいパッケージのリリースであることを確認することは有用かもしれません。Arch での パッケージのダウングレード は、古いバージョンのパッケージがシステムにキャッシュとして保存されていれば、簡単に実行できます。

ノート: 古いバージョンで問題が解決されたとしても、それはプログラムのバグではなく、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
ノート: そうでなければ、あなたが行ったすべての変更を削除してしまうので、-e という接頭辞をそのままにしておくことが非常に重要です

新しいパッケージがインストールされたら、以前発見したエラーをテストすることができます。前のセクションで行ったディレクトリに戻ります。

$ cd src/git_root

問題が発生した場合は、リビジョンが不良であったことを伝えてください:

$ git bisect bad

問題が発生しなかった場合は、リビジョンが良かったことを伝えてください:

$ git bisect good

そして、このセクションの冒頭で説明したことをもう一度行い、git bisect が問題のあるコミットを指定するまで繰り返します。

ノート:
  • git bisect コマンドを発行した後に、make clean を実行する必要があるかもしれません。
  • 実際にゼロまでのステップ数をカウントダウンするので、最初の悪いコミットを指定するまで止めないことが重要です。

ビルドの高速化

より小さなカーネルを構築する

modprobed-db を使ってローカルシステムに必要なモジュールだけをビルドしたり、 make localmodconfig によってカーネルビルド時間を短縮することができます。もちろん、例えばネットワークの問題をデバッグするためのサウンドドライバなど、無関係なドライバを完全に削除することも可能です。

キャッシュ

gcc を使ってビルドされた大きなプロジェクトを二分する場合、 ccache を有効にすることでビルド時間を短縮できるかもしれません。しかし、キャッシュの効果を実感できるまでには、何度かビルドを繰り返す必要があるかもしれません。キャッシュがヒットする可能性は、一般に切断点間の距離が短くなるにつれて高くなります。

ノート: キャッシュが有効なのは、まったく同じ ソースをコンパイルするときだけです。また、カーネルを bisect するために make clean をする必要は 無い ので、 ccache は完全に無駄であることを意味します

パッケージの復元

元のバージョンのパッケージに戻すには、pacman を使ってリポジトリからパッケージをインストールします。

See also