コグノスケ

Gitの小技、コミットID取得

最近、会社でCI/CDで自動化のマネごとを始めました。といっても大したことはなくて、ビルドしてDebianやRPMパッケージを作って、Webサーバーにぶっこむだけです。

Nightlyビルドのパッケージを作成する際に、パッケージ名の最後にGitのコミットIDを付加しようと思ったのですが、方法が分かりません。調べてみるとrev-parseというコマンドを使うそうです。知らなかった。

$ git rev-parse HEAD

5ab7d0ae0c170fc0409d564fe945aac5ce54f86c

$ git rev-parse --short HEAD

5ab7d0ae0c1

ID全部だと長すぎるため --shortオプションを使うとより良いです。

linux-nextの不思議なバージョン情報

Linuxというかlinux-nextですが、リポジトリ内のファイルをオリジナルから変更してビルドした場合、バージョン情報の最後に -dirtyが付きます。あれはどうやっているのだろう？？と気になりました。

Makefileを眺めていると、scripts/setlocalversionというスクリプトでローカルバージョンを付与しているように見えます。

試しにcleanなリポジトリでscripts/setlocalversionを実行すると、-next-20191009のようなlocalversionのみ（※）が表示され、ファイルを適当に書き換えてから実行すると、-next-20191009-dirtyになりました。このスクリプトで当たりっぽいです。

もしLinux Upstreamカーネルで試す場合は、CONFIG_LOCALVERSION_AUTOをyにして、make prepareを実行する必要があります。そうしないとscripts/setlocalversionを実行しても "+" しか表示されません。

（※）この文字列はトップディレクトリのlocalversion-nextというファイルに書いてあります。

Gitの小技、リポジトリ変更を検知

スクリプトsetlocalversionを追いかけてみるとgit --no-optional-locks status -uno --porcelainで変更を検知して、-dirtyを出力するかどうか決めていました。オプション --porcelainのヘルプを見ると「スクリプトなどで処理しやすい形式でstatusを出力する」とのことです。へえー、こんなのあるんだ。初めて知りました。

オプション --no-optional-locksはロックを取らずに実行するという意味です。ヘルプ曰く、バックグラウンドでstatusを実行する際に、他のgit statusプロセスと衝突するので、指定した方が良いとのこと。手動で使うことはなさそうだし、気にしなくて良いでしょう。

オプション-unoは --untracked-files=noの省略形です。効果は実際に見た方が早いです。以下をご覧ください。

#### scripts/setlocalversionを書き換え

$ vim scripts/setlocalversion

#### 未追跡ファイルaaaを作成

$ touch aaa

上記の変更を加えたうえで、オプション -unoなし、オプション -unoありで、それぞれ実行してみます。

$ git status --porcelain

 M scripts/setlocalversion
?? aaa


$ git status -uno --porcelain

下記と同じ

$ git status --untracked-files=no --porcelain

 M scripts/setlocalversion

見た目で明らかだとは思いますが、オプション -unoが指定されていない場合は、未追跡のファイルaaaも表示されますが、-unoを指定すると未追跡のファイルは無視します。

スクリプト内でGitリポジトリが変更されたか？されていないか？を判定する必要は、普通の人はほぼ無いと思うんですけど……、もし必要が生じたら、sedとかgrepとかでゴチャゴチャやらずに、オプション --porcelainを使いましょう。

イコライザー

普段ヘッドフォンを使っているのですが、若干、低音が足りないなと思うことがあります。

Windows標準のBass Boostは設定項目が2つと大変シンプルでわかりやすいですが、音の歪みを防止するためなのか、Boostを有効にすると音が全体的に小さくなってしまうのが辛いところです。

Bass Boost

最大値は24dBですが、最大値に設定しようものなら非常に音が小さくなります。良いヘッドフォンアンプを持っていればアンプ側で音量を上げれば良いですが、PCのヘッドフォン端子に直接ヘッドフォンを接続している場合は、ボリュームを最大にしても聞こえなくなる可能性があります。

Bass Boostの設定画面

これはイマイチだなあってことで、代わりを探していましたら、VLC Playerのイコライザはシンプルデザインかつ設定の幅が広くて、とても良かったです。

VLCイコライザの設定画面

全体の音量（Preamp）と、各帯域ごとの音量を別々に調整できるので、WindowsのBass Boostに似た設定もできる（Preampを下げ、80Hz帯を上げる）し、音が歪むのもお構いなしの設定にもできます。あまりやりすぎるとバリバリ言い始めるのでほどほどに、ですけど。

線形探索と2分探索の話

Twitterで線形探索と2分探索の性能逆転ポイントはどこか？という話をしていて、気になったので測ってみました。

線形探索と2分探索は、要素数をNとしたとき、処理量オーダーでいうとO(N) とO(logN) となり、圧倒的に2分探索が速いです。ただし処理量オーダーによる比較は、Nが十分に大きい場合に成り立ちます。Nが極端に小さい場合は線形探索が2分探索と同等、もしくは、勝ってしまう領域があるのではないか？という話です。

結論だけ先に言えば2分探索の圧勝でした。かなりNを小さく（100程度）しないと、線形探索に勝ち目はなかったです。個人的にはN=1000〜2000程度ならば線形探索が勝つ予想をしていましたが、全くそんなことはなかったです。2分探索スゴい。

探索速度検証

検証方法ですが、線形探索（lsearch）を実装して、Cライブラリ（GNU libc 2.29）に実装されている2分探索（bsearch）と速度を比較しました。線形探索lsearchのAPIは2分探索と揃えています。

処理の概要は下記の通りです。探索の対象は同じものを使っています。

• 要素数Nの配列を作る
• 配列を乱数で埋める
• 配列をソートする（bsearchはソート済みの配列にしか使えない）
• 2分探索（bsearch）をM回実行する、時間を測る
• 線形探索（lsearch）をM回実行する、時間を測る

ソースコードは下記のとおりです。

#include <stdio.h>
#include <stdlib.h>
#include <time.h>
#include <sys/time.h>

int comp(const void *key, const void *val)
{
	int k = *(int *)key;
	int v = *(int *)val;

	return k - v;
}

void *lsearch(const void *key, const void *base,
	      size_t nmemb, size_t size,
	      int (*compar)(const void *, const void *))
{
	void *v = (void *)base;
	size_t i;

	for (i = 0; i < nmemb; i++) {
		if (compar(key, v) == 0)
			return v;
		v += size;
	}

	return NULL;
}

int main(int argc, char *argv[])
{
	int *array, *keys;
	int **fb, **fl;
	size_t n, kn, i;
	struct timeval start_b, end_b, ela_b;
	struct timeval start_l, end_l, ela_l;

	if (argc < 3) {
		fprintf(stderr, "usage:\n\t%s n loop\n", argv[0]);
		return -1;
	}

	n = atoi(argv[1]);
	kn = atoi(argv[2]);
	if (n == 0 || kn == 0) {
		fprintf(stderr, "usage:\n\t%s n loop\n", argv[0]);
		return -1;
	}

	srand(time(NULL));

	array = (int *)malloc(n * sizeof(int));
	keys = (int *)malloc(kn * sizeof(int));
	fb = (int **)malloc(kn * sizeof(int *));
	fl = (int **)malloc(kn * sizeof(int *));

	for (i = 0; i < n; i++) {
		array[i] = rand() % (int)n;
	}
	for (i = 0; i < kn; i++) {
		keys[i] = rand() % (int)n;
	}

	qsort(array, n, sizeof(int), comp);

	gettimeofday(&start_b, NULL);
	for (i = 0; i < kn; i++) {
		fb[i] = bsearch(&keys[i], array, n, sizeof(int), comp);
	}
	gettimeofday(&end_b, NULL);
	timersub(&end_b, &start_b, &ela_b);

	gettimeofday(&start_l, NULL);
	for (i = 0; i < kn; i++) {
		fl[i] = lsearch(&keys[i], array, n, sizeof(int), comp);
	}
	gettimeofday(&end_l, NULL);
	timersub(&end_l, &start_l, &ela_l);

	for (i = 0; i < kn; i++) {
		if (fb[i] && fl[i] && *fb[i] == *fl[i])
			continue;

		if (fb[i] != fl[i])
			printf("diff %d: key:%d, fb:%d, fl:%d\n",
				(int)i, keys[i],
				(fb[i]) ? *fb[i] : -1,
				(fl[i]) ? *fl[i] : -1);
	}

	printf("n:%d, loop:%d, bin: %d.%06d[s], lin: %d.%06d[s]\n",
		(int)n, (int)kn,
		(int)ela_b.tv_sec, (int)ela_b.tv_usec,
		(int)ela_l.tv_sec, (int)ela_l.tv_usec);

	return 0;
}

コピペしていたり、エラー処理が甘かったり、適当な書き方で申し訳ないですが、性能比較が目的なのでそこは見逃していただくとして。測ってみるとこんな結果になりました。

環境はRyzen 7 2700, Debian 10 (Linux 5.2.0-3-amd64) です。コンパイラはgcc 9.2.1で、最適化レベルは -O2 です。

$ for i in 1 `seq 25 25 500`; do ./a.out $i 1000000; done

n:1, loop:1000000, bin: 0.001702[s], lin: 0.001710[s]
n:25, loop:1000000, bin: 0.019114[s], lin: 0.011656[s]
n:50, loop:1000000, bin: 0.022469[s], lin: 0.018549[s]
n:75, loop:1000000, bin: 0.026413[s], lin: 0.023774[s]
n:100, loop:1000000, bin: 0.028008[s], lin: 0.028900[s]
n:125, loop:1000000, bin: 0.029601[s], lin: 0.034308[s]  ★この辺りで逆転される★
n:150, loop:1000000, bin: 0.030671[s], lin: 0.040280[s]
n:175, loop:1000000, bin: 0.031898[s], lin: 0.045664[s]
n:200, loop:1000000, bin: 0.032771[s], lin: 0.048153[s]
n:225, loop:1000000, bin: 0.033985[s], lin: 0.052148[s]
n:250, loop:1000000, bin: 0.034322[s], lin: 0.055871[s]
n:275, loop:1000000, bin: 0.034761[s], lin: 0.059935[s]
n:300, loop:1000000, bin: 0.035766[s], lin: 0.065683[s]
n:325, loop:1000000, bin: 0.036407[s], lin: 0.070435[s]
n:350, loop:1000000, bin: 0.037010[s], lin: 0.072971[s]
n:375, loop:1000000, bin: 0.036926[s], lin: 0.077805[s]
n:400, loop:1000000, bin: 0.037422[s], lin: 0.082656[s]
n:425, loop:1000000, bin: 0.037844[s], lin: 0.086240[s]
n:450, loop:1000000, bin: 0.038894[s], lin: 0.089354[s]
n:475, loop:1000000, bin: 0.038516[s], lin: 0.093286[s]
n:500, loop:1000000, bin: 0.038590[s], lin: 0.100021[s]

結果の見方ですが、最初のn: は配列の要素数です。次のloop: は何回検索するかを表しています。bin: は2分探索bsearch、lin: は線形探索lsearchを表し、それぞれloop回実行し終わるまでの時間を出しています。

線形探索と2分探索の逆転ポイントは実行するたびに割とズレますが、N=500にもなれば、もはや線形探索に勝ち目はありません。2分探索強いです。

ループ回数を増やしても大勢に影響はありませんが、ループ回数を増やすほどlsearchがわずかに有利になるようです。N=1のときlsearchが勝つことが多いので、関数の呼び出しコストが低いのかも？

個人的に予想していたN=1000〜2000のレンジでは、線形探索は桁違いに遅かった（2分探索の10倍近く時間がかかる）です。私の予想は当てにならんなあ。

天皇誕生日の移動

以前対応した（2018年10月12日の日記参照）カレンダーの設定が間違っていたので、修正しました。具体的には下記のとおりです。

• 2018年まで12/23: 祝日、おなじみ天皇誕生日
• 2019年12/23: 祝日ではない、天皇誕生日は2019年は存在しない
• 2020年から2/23: 祝日、新しい天皇誕生日

詳細は内閣府のサイトに掲載されています。特に2019年と2020年に関しては休日の一覧が載っていて、とてもわかりやすいです。

ニッケル水素電池の使い道

目次: 電池

家にはニッケル水素電池がたくさん（15本くらい、※1）あって使い道がなくて困っていたのですが、停電時にモバイルバッテリーにすれば良いのでは？と思い立ち、OwltechのOWL-DBU1という製品（製品サイトへのリンク）を買いました。

乾電池4本で5V 1A出力が可能な製品です。最近のスマホはバッテリー容量が大きく、乾電池2本を使う製品ですと満足に充電できません。その点、この製品は乾電池が4本使えるのでGood です。

不満な点は専用ケーブル（硬い、短い）でないと充電開始しないことです。専用ケーブルをなくすとゴミと化します。

（※1）いきなり電池を15本買ったわけじゃなくて、買ったものもあるし、家電に付属していたものもあって、じわじわ増えて今の数です。

乾電池タイプのモバイルバッテリーとニッケル水素電池

乾電池を使うタイプのモバイルバッテリー製品は、アルカリ電池（1.5V）が前提で、ニッケル水素電池（1.2V）は想定されていないことが若干心配だったんですが、残念ながらこの製品もニッケル水素電池が苦手そうです。

アルカリ乾電池を使うと4.9V 0.9Aくらいでほぼ定格出力しますが、ニッケル水素電池だと4.5V 0.8Aくらいまで電圧低下します。どちらも無負荷ならば5Vですから、ニッケル水素の電圧の低さが悪さをしているように思います。

OWL-DBU1にニッケル水素電池を使って充電中

上記の写真で充電しているデバイスはZenfone 4なんですけど、よくこの出力で充電できますね。期待している電圧より10％も低い（5Vを期待している）のに……。逆に凄いな。

充電効率はいかほどか？

充電できなくなった段階で、USB電力計は約1000mAhを表示していました。電圧が5Vでなくても、正確に測れているのかわかりませんが、表示を信じれば4.4V 1000mAh = 4.4Whくらい放電した計算です。

また、充電前の電池の電圧は1.23Vで、充電後の電池の電圧は1.15Vくらいでした（負荷30Ω）。ニッケル水素電池の終止電圧は1.0Vですから放電しきっていません（※2）。つまり、電池の表面に書いてある容量（1900mAh）は発揮できて「いません」。

ニッケル水素電池は1本1.2V 1900mAh = 2.28Wh、4本で9.12Whなので、48.2％しか使えておらず大変効率が悪いように見えますが、先も書いた通り終止電圧まで放電していないことによるロスと、DC-DC変換のロスがあるので、この数字だけ見て製品が悪いとは言えません。

乾電池タイプのモバイルバッテリーを使う場合、ニッケル水素電池からエネルギーを絞り切ることを目指すより、電池の数に物を言わせてガンガン入れ替えていく運用の方があっていそうですね。

（※2）終止電圧1.0Vに達した後、充電せずに放置すると完全放電してしまい電池がかなり傷むらしいので、使い切る前に止まってくれた方が嬉しい仕様だと思います。

出勤日

本日は祝日ですが会社のカレンダーは出勤日です。有休を取る人も多いですが、特に休みたい気分でもなかったので出勤しました。電車がとても空いていましたね。

自動車業界のカレンダー

自動車業界は土日以外を出勤日（＝祝日は休みではない）で、盆や正月を長めに休む会社が多いそうです。工場のカレンダーに引っ張られているのかな？

しかし、さすがに東京地域は祝日無しだと誰も働きに来なくなるだろう、とでも思ったか、東京地域ではカレンダーが調整されています。

• 盆と正月の休みを廃止する
• 廃止にした日数分、年始の祝日から割り付ける
• 年間休日数はどちらのカレンダーも同じ

こんな感じでかなり強引な手段で調整されています。祝日数は年によって変わるため、祝日が多い年は途中で休日数が足りなくなることが容易に予想できると思います。

まさに今年がそうで、ゴールデンウィークに臨時の祝日（天皇即位の日）と、国民の休日（祝日で挟まれた日）が増えたため、休日数が足りなくなってしまったようです。

前提の違うカレンダーをすり合わせた苦労の跡と、無理が祟って破綻している悲しい様が同時に見え隠れしていますね……。

ニッケル水素電池と電池式モバイルバッテリー

目次: 電池

以前（2019年10月27日の日記参照）購入した、単三電池4本を使うモバイルバッテリーをしばらく使ってみました。

使用する電池はアルカリ電池ではなく、ニッケル水素電池です。満充電のニッケル水素電池4本を使います。充電対象はKindle Fireです。

充電が止まったときの「モバイルバッテリー全体の電圧」「充電量」「各電池の電圧」を測りました。

大体1300mAh〜1400mAhくらい充電できるようです。電圧は結構変動するので何とも言えませんが、4.4V * 1400mAh = 6.16Whくらいですかね。ニッケル水素電池は1本1.2V 1900mAh = 2.28Wh、4本で9.12Whなので、67.5％くらい活用できている計算でしょうか。前回は1000mAhくらいで止まっていました、あれは運が悪かったのかな？？

長い時間放置すると、1つの電池に負荷が偏って電圧が極端に下がる様子も見えます。二次電池はあまり深く放電させると電池を傷めるので、充電が止まったら、即停止させた方が電池には良さそうです。USB電力計を持っていないと、充電が止まったかどうかわからないのが難点ですけども。

ちなみに電圧に関しては測定はあまり厳密ではありません。充電が止まって（＝充電電流が0.00Aになった時点）から、すぐに停止した（4, 5番目辺り）ものもあれば、放置してしまった（3番目は1晩忘れてた）こともあります。参考程度に見ていただけると嬉しいです。

FnキーとCtrlキー

家のLenovo製ノートPC（ThinkPad E480）のキーボードは、左端から「Fn, 左Ctrl」という変な順で並んでいます。ThinkPadを使い続けていたせいか、この変な並びで打ち慣れてしまいました。

一方、会社の東芝製ノートPCはCtrl, Fnという順に並んでいて、左CtrlのつもりでFnを連打してしまい、イライラします。

デスクトップ用のキーボードも東芝と同じ並びで、打ち間違えそうに思いますが、なぜか打ち間違えません。この現象は自分でも謎でしたが、改めてCtrlの打ち方を確認してみると、

Lenovoの場合（1枚目）

Ctrlの左端、Fnとの境目近くを押している

デスクトップの場合（2枚目）

Ctrlの右端、Windowsキーとの境目近くを押している

こんな感じで押していることがわかりました。写真で示すと、

Lenovoの場合

デスクトップの場合

X座標的にはTabキーの右端辺りが近いです。つまりノートもデスクトップも関係なく、ほぼ同じ場所を押していた、というオチでした。

特にこの位置を意識して押しているつもりはありませんが、変なLenovoキーボードと、標準キーボードの双方に鍛えられた結果なんですかね？？

一方、東芝キーボードの場合、この位置はFnの左端に相当します。なるほど、打ち間違える訳だよ。

メモ: 技術系の話はFacebookから転記しておくことにした。一部修正。

独自のaptサーバー - その6 - ソースコードパッケージの配布

目次: apt

今までの設定によって、独自のaptサーバーからバイナリパッケージを配布することができるようになりました。実はaptにはもう1つ大事な機能があります。ソースコードパッケージの配布です。

ご存知かもしれませんがapt-get source hogehogeと実行するだけで、パッケージのソースコードを取得できてしまう、便利な機能です。今回はこの機能を使えるようにaptサーバーを設定します。

テスト用のパッケージ準備

前回はDockerの *.debをコピーして流用しましたが、Dockerはソースコードパッケージを公開していないので、別の手法を取りましょう。

DebianにはHello Worldを表示するプログラムがあります。パッケージ名は何の捻りも無いhelloです。まずはhelloパッケージのソースコードを取得します。

$ apt-get source hello

Reading package lists... Done
Need to get 733 kB of source archives.
Get:1 http://ftp.jp.debian.org/debian testing/main hello 2.10-2 (dsc) [1335 B]
Get:2 http://ftp.jp.debian.org/debian testing/main hello 2.10-2 (tar) [726 kB]
Get:3 http://ftp.jp.debian.org/debian testing/main hello 2.10-2 (diff) [6132 B]
Fetched 733 kB in 1s (1155 kB/s)
dpkg-source: info: extracting hello in hello-2.10
dpkg-source: info: unpacking hello_2.10.orig.tar.gz
dpkg-source: info: unpacking hello_2.10-2.debian.tar.xz


$ ls

hello-2.10                  hello_2.10-2.dsc
hello_2.10-2.debian.tar.xz  hello_2.10.orig.tar.gz

取得したソースコードからDebianパッケージを作成します。helloに限りませんがapt-get sourceで取得したソースコードは、Debianパッケージ作成のための様々な設定が既に済んだソースコードですので、単にdebuildを実行するだけでパッケージが作成できます。簡単ですね。

$ cd hello-2.10

$ debuild -uc -us

...

$ cd ../

$ ls

hello-2.10                     hello_2.10-2_amd64.buildinfo
hello-dbgsym_2.10-2_amd64.deb  hello_2.10-2_amd64.changes
hello_2.10-2.debian.tar.xz     hello_2.10-2_amd64.deb
hello_2.10-2.dsc               hello_2.10.orig.tar.gz
hello_2.10-2_amd64.build

作成されたファイルのうち、*.debがバイナリインストール用のパッケージ、*.dscと *.tar.* つまりtarballがソースコードインストール用のパッケージです。ソースコードをaptサーバーから配布する場合は *.dscとtarballの両方が必要です。

パッケージの配置、設定ファイルの作成

下記のようにstableにはバイナリパッケージのみを配置し、testingにはバイナリパッケージと、ソースコードパッケージの双方を配置します。

理由は、あとでapt-get sourceするときに比べやすいからです。期待する結果はstableを使うと失敗し（ソースコードパッケージが見つからない）、testingを使うと成功することです。

$ tree linux

linux
|-- conf
|   |-- apt_generate_debian_buster.conf
|   `-- apt_release_debian_buster.conf
`-- debian
    `-- dists
        `-- buster
            |-- pool
            |   |-- stable
            |   |   |-- amd64
            |   |   |   |-- hello-dbgsym_2.10-2_amd64.deb
            |   |   |   `-- hello_2.10-2_amd64.deb
            |   |   `-- source
            |   `-- testing
            |       |-- amd64
            |       |   |-- hello-dbgsym_2.10-2_amd64.deb
            |       |   `-- hello_2.10-2_amd64.deb
            |       `-- source
            |           |-- hello_2.10-2.debian.tar.xz
            |           |-- hello_2.10-2.dsc
            |           `-- hello_2.10.orig.tar.gz
            |-- stable
            |   |-- binary-amd64
            |   `-- source
            `-- testing
                |-- binary-amd64
                `-- source

17 directories, 9 files


#### 参考: ディレクトリ構造を作って、下記のように配置するイメージです。

$ cp *.deb linux/debian/dists/buster/pool/stable/amd64/

$ cp *.deb linux/debian/dists/buster/pool/testing/amd64/
$ cp *.tar.* *.dsc linux/debian/dists/buster/pool/testing/source/

設定ファイルapt_generate_debian_buster.confは前回（2019年8月29日の日記参照、シリーズその5）とほぼ同じであるものの、2つだけ変更が必要です。

1点目はTreeDefault::SrcDirectoryの設定です。ソースコードパッケージ *.dscやtarballが入っているディレクトリを指定します。

2点目はTreeのArchitecturesにsourceというアーキテクチャを加えることです。sourceは特殊なアーキテクチャ名で、ソースコードパッケージが存在することを意味します。

Dir::ArchiveDir ".";
Dir::CacheDir   "dists/buster";
Default::Packages::Compress   ". gzip bzip2";
Default::Packages::Extensions ".deb";
Default::Sources::Compress    ". gzip bzip2";
Default::Contents::Compress   ". gzip bzip2";
Default::FileMode             0644;
TreeDefault::Directory        "dists/buster/pool/$(SECTION)/$(ARCH)";
TreeDefault::SrcDirectory     "dists/buster/pool/$(SECTION)/$(ARCH)";
TreeDefault::Packages         "dists/buster/$(SECTION)/binary-$(ARCH)/Packages";

Tree "dists/buster" {
    Sections "stable testing";
    Architectures "amd64 source";
};

もう一つの設定ファイルapt_release_debian_buster.confは、その2（2019年8月11日の日記参照）で紹介した内容から、変更不要です。一応、再掲しておきます。

APT::FTPArchive::Release {
    Architectures "amd64";
    Components "stable";
    Label "Test Label";
    Origin "Test";
    Suite "buster";
};

パッケージ管理情報を更新して署名を付けるまでの操作イメージは、前回（2019年8月29日の日記参照、シリーズその5）と似ていますが、ちょっと違うので下記に全て載せます。

export TARGET=debian
export DIST=buster
export ARCH=amd64

for SECT in stable testing
do
    mkdir -p /var/www/linux/${TARGET}/dists/${DIST}/${SECT}/binary-${ARCH}
    mkdir -p /var/www/linux/${TARGET}/dists/${DIST}/${SECT}/source
    mkdir -p /var/www/linux/${TARGET}/dists/${DIST}/pool/${SECT}/${ARCH}
    mkdir -p /var/www/linux/${TARGET}/dists/${DIST}/pool/${SECT}/source
done


### *.debファイルをコピーする（モジュールによってコピー元は違うと思うので、これは一例）
### cp *.deb /var/www/linux/${TARGET}/dists/${DIST}/pool/${SECT}/${ARCH}

### *.dsc, tarbellをコピーする（モジュールによってコピー元は違うと思うので、これは一例）
### cp *.dsc   /var/www/linux/${TARGET}/dists/${DIST}/pool/${SECT}/source
### cp *.tar.* /var/www/linux/${TARGET}/dists/${DIST}/pool/${SECT}/source


### Packages, Contents, Sourcesファイルを作る
### linux/debianの下でapt-ftparchiveを実行しないと *.debが見つからないといわれる

cd /var/www/linux/${TARGET}
find . -name "Contents-*" -or -name "Contents-*.*" | xargs rm -f
find . -name "Packages" -or -name "Packages.*" -or -name "packages-*.db" | xargs rm -f
find . -name "Sources" -or -name "Sources.*" -or -name "sources-*.db" | xargs rm -f
find . -name Release -or -name Release.gpg -or -name InRelease | xargs rm -f
apt-ftparchive generate ../conf/apt_generate_${TARGET}_${DIST}.conf


### Releaseファイルを作る
### linux/debian/dists/busterの下でapt-ftparchiveを実行しないと、
### 後ほどapt-getを実行した際にパッケージが見つからないといわれる

cd /var/www/linux/${TARGET}/dists/${DIST}
apt-ftparchive release -c=../../../conf/apt_release_${TARGET}_${DIST}.conf . > Release


### Releaseファイルに署名する

echo -n "abcd1234" | gpg --batch --passphrase-fd 0 --pinentry-mode loopback --clearsign -o InRelease Release
echo -n "abcd1234" | gpg --batch --passphrase-fd 0 --pinentry-mode loopback -abs -o Release.gpg Release
chmod 644 Release InRelease Release.gpg

GnuPGの鍵ファイルの作成と、aptへの登録方法については、その3（2019年8月12日の日記参照）をご参照ください。

動作確認

用意したhelloのパッケージと、設定ファイルを使ってapt-ftparchiveを実行すると、下記のようにリポジトリ情報が生成されるはずです。

$ tree linux

linux
|-- conf
|   |-- apt_generate_debian_buster.conf
|   `-- apt_release_debian_buster.conf
`-- debian
    `-- dists
        `-- buster
            |-- InRelease
            |-- Release
            |-- Release.gpg
            |-- packages-amd64.db
            |-- pool
            |   |-- stable
            |   |   |-- amd64
            |   |   |   |-- hello-dbgsym_2.10-2_amd64.deb
            |   |   |   `-- hello_2.10-2_amd64.deb
            |   |   `-- source
            |   `-- testing
            |       |-- amd64
            |       |   |-- hello-dbgsym_2.10-2_amd64.deb
            |       |   `-- hello_2.10-2_amd64.deb
            |       `-- source
            |           |-- hello_2.10-2.debian.tar.xz
            |           |-- hello_2.10-2.dsc
            |           `-- hello_2.10.orig.tar.gz
            |-- sources-stable.db
            |-- sources-testing.db
            |-- stable
            |   |-- Contents-amd64
            |   |-- Contents-amd64.bz2
            |   |-- Contents-amd64.gz
            |   |-- binary-amd64
            |   |   |-- Packages
            |   |   |-- Packages.bz2
            |   |   `-- Packages.gz
            |   `-- source
            |       |-- Sources
            |       |-- Sources.bz2
            |       `-- Sources.gz
            `-- testing
                |-- Contents-amd64
                |-- Contents-amd64.bz2
                |-- Contents-amd64.gz
                |-- binary-amd64
                |   |-- Packages
                |   |-- Packages.bz2
                |   `-- Packages.gz
                `-- source
                    |-- Sources
                    |-- Sources.bz2
                    `-- Sources.gz

17 directories, 33 files

各セクションの下にContentsとPackagesが生成され、さらにSourcesも作成されていることが分かります。ファイルが生成できたら /etc/apt/sources.listにこのサーバーを指定して、apt-get updateを実行します。

deb [arch=amd64] http://192.168.1.1/linux/debian/ buster stable
deb-src http://192.168.1.1/linux/debian/ buster stable
  -> バイナリ（apt-get install hello）はインストールでき、
     ソースコード（apt-get source hello）はインストールできないはず

deb [arch=amd64] http://192.168.1.1/linux/debian/ buster testing
deb-src http://192.168.1.1/linux/debian/ buster testing
  -> バイナリもソースコードもインストールできるはず

うまくいっていれば、セクションをstableとtestingで切り替えたときに、apt-get sourceの成功可否が変わるはずです。

teamLab TOKYO

豊洲のteamLab Planets TOKYOに行きました。事前予約必要、1人3,200円、全部見るのに1時間くらいです。もっとゆっくり見ることもできます。空いていれば当日予約でも何とかなります。

teamLab Planets TOKYO外観

ユーザーがスマホのアプリを使って光らせることができる作品、

The Infinite Crystal Universe

水の中に入る作品、

人と共に踊る鯉によって描かれる水面のドローイング - Infinity

などなど、全て体験型の作品で、大人も子供も楽しめると思います。

写真をもっと撮りたかったのですが、全体的に暗く、スマホで写真を撮るのは難しいですね……。

仮想通貨奉納祭

仮想通貨奉納祭（サイトへのリンク）に行きました。

川島商店街

場所は、中野区の川島商店街です。今までは普通に地元のお祭りをやっていたようです。今年はデジタルハリウッド大学院がコラボして奇祭となりました。

お神輿

地元の人との温度差とか、デジハリの人たちだけ浮いてしまい、おかしな雰囲気になるのでは……、と勝手に心配していましたが、実際見てみると、地元の人たち（たぶん）も楽しそうでした。特に未来を担うお子様たちにウケていたのは素敵です。

日本のお祭りの寛容さはすごいですね。今年限りなのかな？来年もやるんですかね？

apt - まとめリンク

目次: apt

一覧が欲しくなったので作りました。

• 独自のaptサーバー - その1 - ディレクトリ構成
• 独自のaptサーバー - その2 - apt-ftparchiveの設定、実行
• 独自のaptサーバー - その3 - aptの信頼システム
• 独自のaptサーバー - その4 - まとめ
• 独自のaptサーバー - その5 - 複数のセクションに対応する
• 独自のaptサーバー - その6 - ソースコードパッケージの配布