豊洲のteamLab Planets TOKYOに行きました。事前予約必要、1人3,200円、全部見るのに1時間くらいです。もっとゆっくり見ることもできます。空いていれば当日予約でも何とかなります。
ユーザーがスマホのアプリを使って光らせることができる作品、
水の中に入る作品、
人と共に踊る鯉によって描かれる水面のドローイング - Infinity
などなど、全て体験型の作品で、大人も子供も楽しめると思います。
写真をもっと撮りたかったのですが、全体的に暗く、スマホで写真を撮るのは難しいですね……。
仮想通貨奉納祭(サイトへのリンク)に行きました。
場所は、中野区の川島商店街です。今までは普通に地元のお祭りをやっていたようです。今年はデジタルハリウッド大学院がコラボして奇祭となりました。
地元の人との温度差とか、デジハリの人たちだけ浮いてしまい、おかしな雰囲気になるのでは……、と勝手に心配していましたが、実際見てみると、地元の人たち(たぶん)も楽しそうでした。特に未来を担うお子様たちにウケていたのは素敵です。
日本のお祭りの寛容さはすごいですね。今年限りなのかな?来年もやるんですかね?
目次: 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の成功可否が変わるはずです。
家のLenovo製ノートPC(ThinkPad E480)のキーボードは、左端から「Fn, 左Ctrl」という変な順で並んでいます。ThinkPadを使い続けていたせいか、この変な並びで打ち慣れてしまいました。
一方、会社の東芝製ノートPCはCtrl, Fnという順に並んでいて、左CtrlのつもりでFnを連打してしまい、イライラします。
デスクトップ用のキーボードも東芝と同じ並びで、打ち間違えそうに思いますが、なぜか打ち間違えません。この現象は自分でも謎でしたが、改めてCtrlの打ち方を確認してみると、
こんな感じで押していることがわかりました。写真で示すと、
X座標的にはTabキーの右端辺りが近いです。つまりノートもデスクトップも関係なく、ほぼ同じ場所を押していた、というオチでした。
特にこの位置を意識して押しているつもりはありませんが、変なLenovoキーボードと、標準キーボードの双方に鍛えられた結果なんですかね??
一方、東芝キーボードの場合、この位置はFnの左端に相当します。なるほど、打ち間違える訳だよ。
メモ: 技術系の話はFacebookから転記しておくことにした。一部修正。
目次: 電池
以前(2019年10月27日の日記参照)購入した、単三電池4本を使うモバイルバッテリーをしばらく使ってみました。
使用する電池はアルカリ電池ではなく、ニッケル水素電池です。満充電のニッケル水素電池4本を使います。充電対象はKindle Fireです。
充電が止まったときの「モバイルバッテリー全体の電圧」「充電量」「各電池の電圧」を測りました。
全体電圧 | 充電量 | 電池1 | 電池2 | 電池3 | 電池4 | 備考 |
---|---|---|---|---|---|---|
3.96V | 1397mAh | 0.55V | 1.13V | 1.13V | 1.00V | |
4.51V | 1191mAh | 1.13V | 1.13V | 0.89V | 1.12V | Panasonic 2000mAhの電池 |
3.68V | 1346mAh | 0.62V | 0.45V | 1.13V | 1.13V | Panasonic 1900mAhの電池 |
4.59V | 1400mAh | 1.14V | 1.13V | 1.10V | 1.10V | エネループ1900mAh |
4.59V | 1368mAh | 1.12V | 1.14V | 1.13V | 1.14V | Panasonic 2000mAhの電池 |
4.51V | 1351mAh | 1.12V | 1.17V | 1.18V | 1.17V | Panasonic 1900mAhの電池 |
大体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晩忘れてた)こともあります。参考程度に見ていただけると嬉しいです。
本日は祝日ですが会社のカレンダーは出勤日です。有休を取る人も多いですが、特に休みたい気分でもなかったので出勤しました。電車がとても空いていましたね。
自動車業界は土日以外を出勤日(=祝日は休みではない)で、盆や正月を長めに休む会社が多いそうです。工場のカレンダーに引っ張られているのかな?
しかし、さすがに東京地域は祝日無しだと誰も働きに来なくなるだろう、とでも思ったか、東京地域ではカレンダーが調整されています。
こんな感じでかなり強引な手段で調整されています。祝日数は年によって変わるため、祝日が多い年は途中で休日数が足りなくなることが容易に予想できると思います。
まさに今年がそうで、ゴールデンウィークに臨時の祝日(天皇即位の日)と、国民の休日(祝日で挟まれた日)が増えたため、休日数が足りなくなってしまったようです。
前提の違うカレンダーをすり合わせた苦労の跡と、無理が祟って破綻している悲しい様が同時に見え隠れしていますね……。
< | 2019 | > | ||||
<< | < | 11 | > | >> | ||
日 | 月 | 火 | 水 | 木 | 金 | 土 |
- | - | - | - | - | 1 | 2 |
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |
合計:
本日: