2006-09-02 (土)
2006-09-04 (月)
■ クロスコンパイル環境の構築 (6)
今まで勘違いしていたが、クロスコンパイルをするためには、 ターゲット用のライブラリもインストールしなければいけないらしい。 gcc のインストール前に libc のライブラリだけはインストールしていたが、 あれはあくまでも最低限の作業だったわけだ。
具体例を挙げると、 libncurses5 に依存するパッケージを PowerPC 向けにクロスコンパイルする場合、 以下のようなパッケージをダウンロードして来る必要がある。
- libncurses5_5.4-4_powerpc.deb
- libncurses5-dev_5.4-4_powerpc.deb
これを以下のように dpkg-cross コマンドを使ってインストールする。
# dpkg-cross -i -apowerpc *_powerpc.deb
この辺の作業は、 セルフコンパイルの場合は apt-get build-dep コマンドを使って一発だが、 クロスコンパイルの場合は手作業で地道にやるしかないので、 必要なライブラリの数が多い場合には大変なことになる。 まぁ、最小インストールした状態からチマチマやったりせずに、 ほとんど全てのライブラリがインストール済み、 のような環境を作ってしまえばいいのだろう。
2006-09-05 (火)
■ Web サーバ (lighttpd) の構築
Wiki の 玄箱/Debian のページに、 以下の作業記録を追加した。
といっても、先日の Debian に lighttpd をインストール のページを玄箱用に書き直しただけだが、これでようやく、 Apache2 を玄箱にインストールした時の作業記録を追いやることが出来た。
FastCGI の設定などについてはまだ書いていないので、 その辺については、とりあえずこちらの、 VMware 上の lighttpd サーバの環境設定 のページを参考にして欲しい。
2006-09-07 (木)
■ クロスコンパイル環境の構築 (7)
いくつかのパッケージのクロスコンパイルを試していたところ、 libgcc1 (>= 1:3.4.1-3) が必要と言われてビルドに失敗するものがある。 不思議に思い、インストールされているパッケージのバージョンを見てみると、 gcc 関連のパッケージはバージョンが 3.3.5 なのに、 libgcc1 だけはバージョンが 3.4.3 のものがインストールされている。 なぜかは知らないが、とにかくそうなっている。
クロスコンパイル用の gcc 一式は、 gcc-3.3 のソースパッケージを使ってビルドした訳だが、 セルフコンパイルと同じ環境にしたければ、 libgcc1 だけのために gcc-3.4 一式もビルドするという、 ２度手間なことをやる必要があるのか…。
ということで、仕方ないので、 クロスコンパイル用の gcc-3.4 のパッケージを作成して、 libgcc1-powerpc-cross のパッケージをインストールし直した。 ファイル置き場 に置いてあるパッケージも差し替えておいた。
しかし、ビルドする直前に gcc-3.4 のセキュリティアップデートが出ていたのは危なかった。 あと少し早くとりかかっていたら、 もう一度ビルドし直す羽目になるところだった。
2006-09-08 (金)
■ dotdeb 版 PHP5 のビルド
Debian sarge 化した玄箱用に PHP 5.1.6 のパッケージが欲しいので、 dotdeb の PHP5 のパッケージを、 ソースからビルドしてみる。 まずは練習ということで、VMware 上の Debian でやってみる。
APT の設定
/etc/apt/sources.list に以下の設定を追加。
deb http://packages.dotdeb.org/ stable all deb-src http://packages.dotdeb.org/ stable all
パッケージのリストを更新。
# aptitude update
必要なパッケージのインストール
PHP5 のビルドに必要なパッケージをインストール。
# apt-get build-dep php5
ただし、以下のパッケージは、 Debian sarge のパッケージと dotdeb のパッケージの両方があるので、 Debian sarge のパッケージを選択的にインストールした。
- libmysqlclient14
- libmysqlclient14-dev
- mysql-common
PHP5 のパッケージのビルド
PHP5 のソースパッケージをダウンロード。
$ apt-get source php5
ソースが展開されたディレクトリに移動し、ビルド開始。
$ cd php5-5.1.6 $ debuild -rfakeroot -us -uc
約40分でコンパイルが終了し、PHP5 のパッケージ群がビルドできた。 しかし、ビルドしたパッケージを Lintian でチェックすると、 以下のエラーが出ている。
E: php5-pear: usr-doc-symlink-without-dependency php5-common E: libapache-mod-php5: FSSTND-dir-in-usr usr/man/
個人的に利用するだけなら無視してもいいと思うが、 配布することを考えるとエラーは取り除いておきたい。 なんとか修正できないだろうか？
2006-09-09 (土)
■ dotdeb 版 PHP5 のビルド (2)
昨日のエラー を修正してみる。
E: php5-pear: usr-doc-symlink-without-dependency php5-common
Lintian の解説 によると、シンボリックリンクの張り方がまずいらしい。 php4-pear_4.3.10-16_all.deb の中身を見てみると、 以下のような違いがあった。
- /usr/share/doc/php-pear のリンク先は php4-common ディレクトリ
- php4-common のパッケージにも依存
これにならって、以下のように修正を加える。
debian/control ファイルに以下のパッチをあてる。
--- debian.orig/control 2006-09-08 22:41:11.000000000 +0900
+++ debian/control 2006-09-09 11:06:24.000000000 +0900
@@ -150,7 +150,7 @@
Package: php5-pear
Architecture: all
-Depends: php5-cli
+Depends: php5-cli, php5-common (>= ${Source-Version})
Suggests: php5-dev
Conflicts: php4-pear
Description: PEAR - PHP Extension and Application Repository
debian/php5-pear.postinst ファイルに以下のパッチをあてる。
--- debian.orig/php5-pear.postinst 2006-09-08 22:41:11.000000000 +0900
+++ debian/php5-pear.postinst 2006-09-09 10:59:56.000000000 +0900
@@ -10,7 +10,7 @@
if [ ! -L /usr/share/doc/php5-pear ]; then
rm -rf /usr/share/doc/php5-pear
- ln -s php5 /usr/share/doc/php5-pear
+ ln -s php5-common /usr/share/doc/php5-pear
fi
exit 0
E: libapache-mod-php5: FSSTND-dir-in-usr usr/man/
Lintian の解説 によると、/usr/man というディレクトリが、 ディレクトリ構造のルールにそぐわないらしい。 ビルドした libapache-mod-php5 パッケージの中身を見てみる。
revulo@debian:~$ dpkg -c libapache-mod-php5_5.1.6-0.dotdeb.2_i386.deb drwxr-xr-x root/root 0 2006-09-08 23:21:53 ./ drwxr-xr-x root/root 0 2006-09-08 23:21:28 ./etc/ drwxr-xr-x root/root 0 2006-09-08 23:21:28 ./etc/php5/ drwxr-xr-x root/root 0 2006-09-08 23:21:28 ./etc/php5/apache/ drwxr-xr-x root/root 0 2006-09-08 23:21:28 ./etc/apache/ drwxr-xr-x root/root 0 2006-09-08 23:21:29 ./etc/apache/conf.d/ -rw-r--r-- root/root 133 2006-09-08 23:21:29 ./etc/apache/conf.d/php5.conf drwxr-xr-x root/root 0 2006-09-08 23:21:54 ./usr/ drwxr-xr-x root/root 0 2006-09-08 23:21:42 ./usr/lib/ drwxr-xr-x root/root 0 2006-09-08 23:21:28 ./usr/lib/apache/ drwxr-xr-x root/root 0 2006-09-08 23:21:56 ./usr/lib/apache/1.3/ -rw-r--r-- root/root 5780232 2006-09-08 23:21:56 ./usr/lib/apache/1.3/libphp5.so -rw-r--r-- root/root 188 2006-09-08 23:21:29 ./usr/lib/apache/1.3/500mod_php5.info drwxr-xr-x root/root 0 2006-09-08 23:21:52 ./usr/lib/php5/ drwxr-xr-x root/root 0 2006-09-08 23:21:47 ./usr/lib/php5/20050922/ drwxr-xr-x root/root 0 2006-09-08 23:21:54 ./usr/share/ drwxr-xr-x root/root 0 2006-09-08 23:21:55 ./usr/share/doc/ drwxr-xr-x root/root 0 2006-09-08 23:21:52 ./usr/bin/ drwxr-xr-x root/root 0 2006-09-08 23:21:43 ./usr/man/ drwxr-xr-x root/root 0 2006-09-08 23:21:58 ./usr/man/man1/ -rw-r--r-- root/root 598 2006-09-08 23:21:43 ./usr/man/man1/phpize.1.gz -rw-r--r-- root/root 764 2006-09-08 23:21:43 ./usr/man/man1/php-config.1.gz lrwxrwxrwx root/root 0 2006-09-08 23:21:55 ./usr/share/doc/libapache-mod-php5 -> php5-common revulo@debian:~$
確かに /usr/man というディレクトリが含まれている。 これを /usr/share/man になるようにすればいいのか？ …いや、違う。 unstable の libapache-mod-php5_5.1.6-1_i386.deb のパッケージと比較してみると、 そもそも /usr/bin や /usr/man というディレクトリが、 このパッケージに含まれているのがおかしい。
ということで、debian/rules ファイルに以下のパッチをあてる。
--- debian.orig/rules 2006-09-08 22:41:11.000000000 +0900
+++ debian/rules 2006-09-09 11:33:32.000000000 +0900
@@ -376,7 +376,9 @@
# move and install -dev files
dh_movefiles --sourcedir=debian/libapache-mod-php5
rm -rf debian/libapache-mod-php5/usr/lib/php5/build/ \
- debian/libapache-mod-php5/usr/include/
+ debian/libapache-mod-php5/usr/include/ \
+ debian/libapache-mod-php5/usr/bin/ \
+ debian/libapache-mod-php5/usr/man/
for i in Makefile.global acinclude.m4 mkdep.awk phpize.m4 scan_makefile_in.awk; do \
chmod 644 debian/php5-dev/usr/lib/php5/build/$$i; \
done
再ビルド
debuild clean してビルドし直そうとしたら失敗したので、 ソースパッケージの展開からやり直す。
$ rm -rf php5-5.1.6 $ dpkg-source -x php5_5.1.6-0.dotdeb.2.dsc $ cd php5-5.1.6
不思議なことに、一旦ファイルを削除したはずなのに、 debian ディレクトリ以下のファイルはパッチ適用済みの状態になっていた。 どこかにキャッシュでもされているのか？ この状態から、もう一度ビルド。
$ debuild -rfakeroot -us -uc
ビルド後に Lintian のチェックが行われたが、 今度は期待通りにエラーが消えてくれていた。
2006-09-10 (日)
■ dotdeb 版 PHP5 のビルド (3)
玄箱/HG で PHP5 のパッケージをビルドしてみる。 基本的には、 昨日と一昨日の手順と同じだが、 ビルドに必要なパッケージのうち、 libming, libming-dev は PowerPC 用のパッケージが用意されていないので、 それを自分でビルドする必要がある。 ただし、libming のソースパッケージの依存関係が間違っていて、 libpng12-dev であるべき箇所が libpng2-dev となっているので、 そのことに留意して作業する。
libming, libming-dev のパッケージのビルド
libming のビルドに必要なパッケージをインストールする。 本来は apt-get build-dep libming で良いのだが、 それだと libpng2-dev パッケージが間違ってインストールされてしまうので、 手作業でインストール。
# aptitude install debhelper swig libungif4-dev libpng12-dev libz-dev
libming のソースパッケージをダウンロード。
$ apt-get source libming
ソースが libming-0.3 ディレクトリに展開されるので、そこに移動。
$ cd libming-0.3
debian/control の Build-Depends: の行を、 以下のように libpng2-dev から libpng12-dev に修正。
Build-Depends: debhelper (>> 3.0.0), swig, libungif4-dev, libpng12-dev, libz-dev
以下のコマンドを実行し、パッケージをビルド。
$ debuild -rfakeroot -us -uc
ビルド後の Lintian のチェックでエラーが出るが、 とりあえず無視して、ビルドしたパッケージをインストール。
# debi
あとは、昨日と一昨日と同様の作業を行い、 約５時間で PHP5 のビルドが完了した。
2006-09-11 (月)
■ dotdeb 版 PHP5 のビルド (4)
ビルドした PHP5 のパッケージをインストールしようとして気付いたが、 php5_5.1.6-0.dotdeb.2_all.deb というパッケージの依存関係がおかしい。
Depends: libapache2-mod-php5 (>= 5.1.6-0.dotdeb.2) | libapache-mod-php5 (>= 5.1.6-0.dotdeb.2), php5-common (>= 5.1.6-0.dotdeb.2)
これだと、Apache 以外の Web サーバを使う場合でも、 問答無用で Apache 用のモジュールがインストールされてしまう。 ということで、unstable の PHP5 のパッケージにならって、 debian/control に以下のパッチをあてる。
--- debian.orig/control 2006-09-10 01:05:51.000000000 +0900
+++ debian/control 2006-09-10 09:13:59.000000000 +0900
@@ -8,7 +8,7 @@
Package: php5
Architecture: all
-Depends: libapache-mod-php5 (>= ${Source-Version}) | libapache2-mod-php5 (>= ${Source-Version}), php5-common (>= ${Source-Version})
+Depends: libapache2-mod-php5 (>= ${Source-Version}) | libapache-mod-php5 (>= ${Source-Version}) | php5-cgi (>= ${Source-Version}), php5-common (>= ${Source-Version})
Description: server-side, HTML-embedded scripting language (meta-package)
This package is a meta-package that, when installed, guarantees that you
have at least one of the four server-side versions of the PHP5 interpreter
修正した後、このパッケージをもう一度ビルドし直し。
$ debuild binary-indep
これでＯＫ。
2006-09-13 (水)
2006-09-15 (金)
■ vim の文字コード自動認識
玄箱のデフォルトのロケールを UTF-8 に設定して使っているが、 文字コードが EUC のファイルを vim で編集しようとすると、 文字化けすることに気が付いた。 あれ？ vim って文字コードの自動認識はしてくれないのか？
調べてみたところ、 ずんWiki の vim のページ に、 文字コード自動認識のための設定が載っていた。 ただ、ちょっと大げさすぎる気がする。 常用するわけではないので、もう少しシンプルな設定で済ませたい。
vim の文字コード設定 のページを読むと、 基本的には、fileencodings に候補の文字コードをずらずら並べればいいようだが、 どの文字コードをどの順番で記述すべきなのかがよく分からない。 ただし、以下のルールは守ったほうが良さそうだ。
- encoding に指定した文字コードは、fileencodings 中に指定しない
- euc-jp は cp932 よりも先に記述する
ということで、設定をしてみた。 vim の設定は、普通は ~/.vimrc に設定するらしいが、 これは全ユーザに共通の設定にしたいので、 /etc/vim/vimrc.local に以下の設定を追加した。
set encoding=utf-8 set fileencodings=ucs-bom,iso-2022-jp,euc-jp,cp932 set fileformats=unix,dos,mac set ambiwidth=double
この設定をした後、EUC で書かれたファイルを読み込んでみたところ、 とりあえず文字化けせずに編集できるようになった。
(追記) fileformats と ambiwidth の設定を追加した (2006/11/18)。
(2009/04/08 追記)
上記のリンク先に、
'fencs' の途中で 'enc' と同じものが登場すると以降の変換試行が行われない
と書かれていますが、少なくとも最近の Vim ではそのような制限はないようです。 上の設定だと、UTF-8 のファイルを SJIS と誤判定することがあったので、 こちらの設定のように、fileencodings に utf-8 も加えた方が良さそうです。
2006-09-20 (水)
■ tdiarysearch による検索機能を追加
ずっと後回しにしていたが、このブログに検索機能をつけてみる。 本当は rast-search を使いたいが、 レンタルサーバで使えるようにするのは大変そうなので、 導入が楽そうな tdiarysearch の方を試してみる。
tDiary のページ から contribパッケージ をダウンロードし、ドキュメントに従ってセットアップしてみた。 しかし、検索を実行すると、内部サーバーエラーとなってしまう。 Web サーバのログを見てみると、こんなメッセージが出ていた。
/var/www/blog/search.rb:129: warning: already initialized constant ERbLight
/var/www/blog/search.rb:143:in `initialize': wrong number of arguments (1 for 0) (ArgumentError)
from /var/www/blog/search.rb:143:in `new'
from /var/www/blog/search.rb:143:in `main'
from /var/www/blog/search.rb:484
対処法はないのかと調べていたところ、 tdiarysearch のページ からダウンロードできるスクリプトの方が、 バージョンが新しいことに気が付いた。 そこで、search.rb を差し替えて試してみたところ、 今度は問題なく実行できた。
サーバへの負荷とかを考えると、 msearch や Rast を使う方が良さそうだが、 とりあえずはこれで十分だろう。
2006-09-22 (金)
■ タグクラウドを表示させる (2)
tdiarysearch について検索している途中で、 なんだか見覚えのあるページにたどり着いたと思ったら、 tDiary 用のタグクラウドプラグインの作者様のページだった。 日記をさっと眺めてみると、 タイミングの良いことにプラグインが更新されていた。
早速プラグインをバージョンアップしてみたところ、 見た目がだいぶ変わってしまった… orz
カテゴリタグが <li> で区切られるようになったのは、 意味からすると正しいと思うが、 おかげで左側のマージンがかなり大きく取られてしまう。 仕方ないので、 外部のスタイルシートを利用するようにプラグインの設定をし、 そちらに以下のような設定を追加した。
ul.tagcloud {
margin: 2px;
}
もう少し調整した方がいいかもしれないが、 とりあえずこれで以前と同じような見た目になった。
2006-09-23 (土)
■ タグクラウドを表示させる (3)
昨日の日記 に hb@smallstyle さんからコメントをいただき、 margin でなく padding を設定したほうがいいのかな？ と思ったので実験をしてみた。 一応、テーマは Default テーマに変更して、 以下の４パターンの設定をスタイルシートに追加してみた。
- .tagcloud ul {padding:0px;}
- .tagcloud ul {margin:0px;}
- ul.tagcloud {padding:0px;}
- ul.tagcloud {margin:0px;}
実は、それぞれの違いをあまり理解していないが、 タグクラウドの左のマージンを消すことができたのは最後の４番の設定だけで、 他の設定だとダメだった。
default.css を見てみたが、 この部分の <ul> タグに関しての設定は特にない。 ということは、 おそらくデフォルトで <ul> タグには左マージンが設定されており、 それを打ち消すためには padding でなく margin を設定する、 ということなのだろう。
あとテーマの種類にもよると思うが、 マージンを 0px にすると窮屈な感じがするので、 やはり 2px くらいにマージン設定するのが良さそうに思う。
（追記）
上の実験は Internet Explorer で表示を確認したのだが、 Firefox で同じ実験をしてみたら、今度は３番の設定以外ダメだった。 うわっ、ブラウザに依存するのか。
ということで、padding と margin の両方の設定を、 以下のようにスタイルシートに追加してやる。
ul.tagcloud {
padding: 0px;
margin: 2px;
}
今度こそ大丈夫、だと思う。
2006-09-27 (水)
■ AMD64 版 Debian 3.1r3 のインストール
AMD64 版 Debian 3.1r3 の netinst CD イメージが出ていた。 3.1r0a というバージョンの時に試したきりだったので、 久しぶりに VMware 上にインストールしてみた。
一応インストールはできたが、途中で問題が２点ほどあった。
- インストールの 2nd Stage が英語表記になる
- インストーラが設定する apt-line が現状にそぐわない
１点目は、以前インストールした時もそうだったが、 カーネルがフレームバッファに非対応だとかなんだとか、 そういった理由だったと思う。 まぁ、これはいいとして、２点目のほうが問題。
http://amd64.debian.net/README.mirrors.html によると、 Debian AMD64 を国内でミラーしているのは、 ftp.jp.debian.org と hanzubon.jp くらいらしいので、 ミラーサーバを尋ねられる箇所では ftp.jp.debian.org を選択した。
ところが、ここでインストーラは、 http://ftp.jp.debian.org/debian/ を見にいってしまう。 AMD64 用のファイルは、http://ftp.jp.debian.org/debian-amd64/ という別のディレクトリの下に置かれているので、当然エラーになる。 将来的には、ディレクトリが統合されたりするのかもしれないが、 現状では、インストール作業がこの箇所でストップしてしまう。
仕方ないので、アーカイブへのアクセス方法を選ぶ箇所では edit sources list by hand を選択し、 以下のように apt-line を書き換えた。
deb http://ftp.jp.debian.org/debian-amd64/debian/ stable main contrib non-free deb http://security.debian.org/ stable/updates main contrib non-free
これでインストール作業が続行できた。
# hb@smallstyle [タグクラウド表示プラグインの仕様変更でご迷惑をおかけしてしまったようで…すみません． タグクラウドの表示ですが，更新..]
# revulo [コメントありがとうございます。 プラグインを使わせて頂いている身としては、迷惑どころか感謝の気持ちで一杯です。 なん..]