「Git でバグを bisect する」の版間の差分
(一部翻訳) |
(→より小さなカーネルを構築する: 削除。「カーネル」へ移動済み。) |
||
| (2人の利用者による、間の5版が非表示) | |||
| 37行目: | 37行目: | ||
== Bisecting == |
== Bisecting == |
||
| + | PKGBUILD のあるディレクトリに戻ります。前のセクションで説明したディレクトリにまだいる場合は、次のように実行できます: |
||
| − | Change back into the directory with the PKGBUILD. If you are still in the directory mentioned in the previous section this can be accomplished like so: |
||
$ cd ../.. |
$ cd ../.. |
||
| + | これで、パッケージの特定のリビジョンを再構築してインストールできます: |
||
| − | You can now rebuild and install the specific revision of the package: |
||
$ makepkg -efsi |
$ makepkg -efsi |
||
| + | {{Note|そうでなければ、あなたが行ったすべての変更を削除してしまうので、{{ic|-e}} という接頭辞をそのままにしておくことが非常に重要です}} |
||
| − | {{Note|It is very important to keep the {{ic|-e}} prefix intact as otherwise it will remove all the changes you have made.}} |
||
| + | 新しいパッケージがインストールされたら、以前発見したエラーをテストすることができます。前のセクションで行ったディレクトリに戻ります。 |
||
| − | Once the new package is installed you can test for your previously discovered error. Return to the directory you were in the previous section: |
||
$ cd src/''git_root'' |
$ cd src/''git_root'' |
||
| + | 問題が発生した場合は、リビジョンが不良であったことを伝えてください: |
||
| − | If you encountered your problem, tell that the revision was bad: |
||
$ git bisect bad |
$ git bisect bad |
||
| + | 問題が発生しなかった場合は、リビジョンが良かったことを伝えてください: |
||
| − | If you did not encounter your problem, tell that the revision it was good: |
||
$ git bisect good |
$ git bisect good |
||
| + | そして、このセクションの冒頭で説明したことをもう一度行い、git bisect が問題のあるコミットを指定するまで繰り返します。 |
||
| − | Then do as described at the beginning of this section again and repeat until git bisect names the troublesome commit. |
||
{{Note| |
{{Note| |
||
| + | * git bisect コマンドを発行した後に、make clean を実行する必要があるかもしれません。 |
||
| − | * You may need to run a make clean after issuing the git bisect command. |
||
| + | * 実際にゼロまでのステップ数をカウントダウンするので、最初の悪いコミットを指定するまで止めないことが重要です。 |
||
| − | * It will actually count down the number of steps all the way down to zero, so it is important not to stop until it actually names the first bad commit. |
||
}} |
}} |
||
| − | == |
+ | == ビルドの高速化 == |
| − | === |
+ | === キャッシュ === |
| + | {{ic|gcc}} を使ってビルドされた大きなプロジェクトを二分する場合、 [[ccache]] を有効にすることでビルド時間を短縮できるかもしれません。しかし、キャッシュの効果を実感できるまでには、何度かビルドを繰り返す必要があるかもしれません。キャッシュがヒットする可能性は、一般に切断点間の距離が短くなるにつれて高くなります。 |
||
| − | You can shorten kernel build times by building only the modules required by the local system using [[modprobed-db]], or by {{ic|make localmodconfig}}. Of course you can completely drop irrelevant drivers, for example sound drivers to debug a network problem. |
||
| + | {{Note|キャッシュが有効なのは、''まったく同じ'' ソースをコンパイルするときだけです。また、カーネルを bisect するために {{ic|make clean}} をする必要は ''無い'' ので、 ccache は完全に無駄であることを意味します}} |
||
| − | === Ccache === |
||
| + | == パッケージの復元 == |
||
| − | If you are bisecting a large project built using {{ic|gcc}}, it might be possible to reduce build times by enabling [[ccache]]. It may take several build iterations before you start to see benefits from the cache, however. The likelihood of cache hits generally increases as the distance between bisection points decreases. |
||
| + | 元のバージョンのパッケージに戻すには、[[pacman]] を使ってリポジトリからパッケージをインストールします。 |
||
| − | {{Note|Ccache is effective ''only when'' compiling ''exactly identical'' sources. And to bisect the kernel, it is ''not'' necessary to do {{ic|make clean}}, meaning ccache is a complete waste.}} |
||
| − | == |
+ | == 参照 == |
| + | * [https://git-scm.com/docs/git-bisect-lk2009.html git bisect によるリグレッションとの戦い] |
||
| − | Reverting to an original version of the package can be done by installing the package from repositories with [[pacman]]. |
||
| − | |||
| − | == See also == |
||
| − | |||
| − | * [https://git-scm.com/docs/git-bisect-lk2009.html Fighting regressions with git bisect] |
||
* {{man|1|git-bisect}} |
* {{man|1|git-bisect}} |
||
* [[Gentoo:Kernel git-bisect]] |
* [[Gentoo:Kernel git-bisect]] |
||
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 を使ってリポジトリからパッケージをインストールします。