Git でバグを bisect する - 版の履歴

AshMyzk: /* より小さなカーネルを構築する */ 削除。「カーネル」へ移動済み。

2023-11-14T13:36:52Z

より小さなカーネルを構築する: 削除。「カーネル」へ移動済み。

← 古い版		2023年11月14日 (火) 22:36時点における版
67行目:		67行目:

	== ビルドの高速化 ==		== ビルドの高速化 ==

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

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

	=== キャッシュ ===		=== キャッシュ ===

AshMyzk: AshMyzk がページ「Bisecting bugs with Git」を「Git でバグを bisect する」に移動しました: ページ名を翻訳

2023-11-14T13:31:57Z

AshMyzk がページ「Bisecting bugs with Git」を「Git でバグを bisect する」に移動しました: ページ名を翻訳

← 古い版	2023年11月14日 (火) 22:31時点における版
(相違点なし)

Kgx: /* See also */ 翻訳

2022-02-07T16:34:47Z

Kgx: /* Restoring package */ 翻訳

2022-02-07T16:33:24Z

Restoring package: 翻訳

← 古い版		2022年2月8日 (火) 01:33時点における版
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 ==

Kgx: /* Speeding up builds */ 翻訳

2022-02-07T16:32:33Z

Speeding up builds: 翻訳

← 古い版		2022年2月8日 (火) 01:32時点における版
66行目:		66行目:
	}}		}}

	== ~~Speeding up builds~~ ==		== ビルドの高速化 ==

			=== より小さなカーネルを構築する ===
	=== Building smaller kernel ===

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

	=== ~~Ccache~~ ===		=== キャッシュ ===

			{{ic\|gcc}} を使ってビルドされた大きなプロジェクトを二分する場合、 [[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.

			{{Note\|キャッシュが有効なのは、''まったく同じ'' ソースをコンパイルするときだけです。また、カーネルを bisect するために {{ic\|make clean}} をする必要は ''無い'' ので、 ccache は完全に無駄であることを意味します}}
	{{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.}}

	== Restoring package ==		== Restoring package ==

Kgx: /* Bisecting */ 翻訳

2022-02-07T16:29:43Z

Bisecting: 翻訳

← 古い版		2022年2月8日 (火) 01:29時点における版
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.
	}}		}}

Kgx: 一部翻訳

2022-02-07T16:25:51Z

一部翻訳

← 古い版		2022年2月8日 (火) 01:25時点における版
2行目:		2行目:
	[[Category:バージョン管理システム]]		[[Category:バージョン管理システム]]
	[[en:Bisecting bugs with Git]]		[[en:Bisecting bugs with Git]]
			Mesa や Linux カーネルなどのプロジェクトで発生したバグを報告する際、問題のあるコミットが何であるかを確認するために、最後に動作した既知のバージョンと問題のある新しいバージョンとの間でバイセクトを行うよう求められることがよくあります。Arch では、[[AUR]] の機能のおかげで、これは非常に簡単に行うことができます。
	Often when reporting bugs encountered with projects such as Mesa or Linux kernel, a user may be asked to bisect between the last known version that worked for them and the newer version which is causing them problems in order to see what is the troublesome commit. On Arch this can be done fairly trivially thanks to the functionality of the [[AUR]].

			== 古いリリースに戻す場合 ==
	== Reverting to an older release ==

			問題を引き起こしているのが新しいパッケージのリリースであることを確認することは有用かもしれません。Arch での [[パッケージのダウングレード]] は、古いバージョンのパッケージがシステムにキャッシュとして保存されていれば、簡単に実行できます。
	It might be useful to confirm that it is the new package release that is causing the problem. [[Downgrading packages]] on Arch can be accomplished trivially as long as an older version of the package is still stored as cache on your system, or you can use [[Arch Linux Archive]].

			{{Note\|古いバージョンで問題が解決されたとしても、それはプログラムのバグではなく、Arch が提供するパッケージの問題である可能性があります}}
	{{Note\|Even if the older version fixes the problem it is still possible that is not a bug within the program, but a problem with the packages as provided by Arch.}}

			== git からのパッケージの構築 ==
	== Building package from git ==

			bisect を行うには、[[git]] からパッケージのバージョンをビルドする必要があります。これは [[AUR]] から ''-git'' パッケージをビルドすることで実現できます。
	In order to bisect we are going to need to build a version of package from [[git]]. This can be accomplished by building the ''-git'' package from the [[AUR]].

			== bisect のセットアップ ==
	== Setting up the Bisect ==

			パッケージのビルドが成功したら、{{ic\|src/}} ディレクトリ内の git ルートディレクトリに移動する必要があります。git ルートディレクトリの名前は、多くの場合{{ic\|''pkgname''}} と同じです。(または接尾辞 {{ic\|-git}} を除いたもの）
	Once package is successfully built you need to change into the git root directory in the {{ic\|src/}} directory. The name of the git root directory is often the same as {{ic\|''pkgname''}} (or without the {{ic\|-git}} suffix):

	$ cd src/''git_root''		$ cd src/''git_root''

			そこから、bisecting するプロセスを開始できます:
	From there you can start the process of bisecting:

	$ git bisect start		$ git bisect start

			次のコマンドは、bisecting する場所を指定するために使用できるすべてのタグを表示します:
	The following command will show you all the tags you can use to specify where to bisect:

	$ git tag		$ git tag

			前の例に続いて、バージョン ''oldver'' は機能したが、''newver'' は機能しなかったと想定します。
	Following on from the earlier example, we will assume that the version ''oldver'' worked for us while ''newver'' did not:

	$ git bisect good ''oldver''		$ git bisect good ''oldver''
	$ git bisect bad ''newver''		$ git bisect bad ''newver''

			良いバージョンと悪いバージョンのタグが付けられたので、コミットのテストに進むことができます。
	Now that we have our good and bad versions tagged we can proceed to test commits.

	== Bisecting ==		== Bisecting ==

Kgx: 英語版から転載

2022-02-07T16:12:54Z

英語版から転載

新規ページ

[[Category:パッケージ管理]]
[[Category:バージョン管理システム]]
[[en:Bisecting bugs with Git]]
Often when reporting bugs encountered with projects such as Mesa or Linux kernel, a user may be asked to bisect between the last known version that worked for them and the newer version which is causing them problems in order to see what is the troublesome commit. On Arch this can be done fairly trivially thanks to the functionality of the [[AUR]].

== Reverting to an older release ==

It might be useful to confirm that it is the new package release that is causing the problem. [[Downgrading packages]] on Arch can be accomplished trivially as long as an older version of the package is still stored as cache on your system, or you can use [[Arch Linux Archive]].

{{Note|Even if the older version fixes the problem it is still possible that is not a bug within the program, but a problem with the packages as provided by Arch.}}

== Building package from git ==

In order to bisect we are going to need to build a version of package from [[git]]. This can be accomplished by building the ''-git'' package from the [[AUR]].

== Setting up the Bisect ==

Once package is successfully built you need to change into the git root directory in the {{ic|src/}} directory. The name of the git root directory is often the same as {{ic|''pkgname''}} (or without the {{ic|-git}} suffix):

$ cd src/''git_root''

From there you can start the process of bisecting:

$ git bisect start

The following command will show you all the tags you can use to specify where to bisect:

$ git tag

Following on from the earlier example, we will assume that the version ''oldver'' worked for us while ''newver'' did not:

$ git bisect good ''oldver''
$ git bisect bad ''newver''

Now that we have our good and bad versions tagged we can proceed to test commits.

== Bisecting ==

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 ../..

You can now rebuild and install the specific revision of the package:

$ makepkg -efsi

{{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''

If you encountered your problem, tell that the revision was bad:

$ git bisect bad

If you did not encounter your problem, tell that the revision it was good:

$ git bisect good

Then do as described at the beginning of this section again and repeat until git bisect names the troublesome commit.

{{Note|
* 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.
}}

== 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 {{ic|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 {{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.

{{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.}}

== Restoring package ==

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}}
* [[Gentoo:Kernel git-bisect]]

← 古い版		2022年2月8日 (火) 01:34時点における版
82行目:		82行目:
	元のバージョンのパッケージに戻すには、[[pacman]] を使ってリポジトリからパッケージをインストールします。		元のバージョンのパッケージに戻すには、[[pacman]] を使ってリポジトリからパッケージをインストールします。

	== ~~See also~~ ==		== 参照 ==

	* [https://git-scm.com/docs/git-bisect-lk2009.html ~~Fighting regressions with~~ git bisect]		* [https://git-scm.com/docs/git-bisect-lk2009.html git bisect によるリグレッションとの戦い]
	* {{man\|1\|git-bisect}}		* {{man\|1\|git-bisect}}
	* [[Gentoo:Kernel git-bisect]]		* [[Gentoo:Kernel git-bisect]]