「Git でバグを bisect する」の版間の差分
(一部翻訳) |
(→Bisecting: 翻訳) |
||
| 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. |
||
}} |
}} |
||
2022年2月8日 (火) 01:29時点における版
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 が問題のあるコミットを指定するまで繰り返します。
Speeding up builds
Building smaller kernel
You can shorten kernel build times by building only the modules required by the local system using modprobed-db, or by make localmodconfig. Of course you can completely drop irrelevant drivers, for example sound drivers to debug a network problem.
Ccache
If you are bisecting a large project built using 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.
Restoring package
Reverting to an original version of the package can be done by installing the package from repositories with pacman.