KeN's GNU/Linux Diary

Bug#292330: project: UTF-8 as default

ja_JP.UTF-8はsargeではちょっと時期尚早ぽかったのでやらなかったけど、etchまでにはやりたいですな(いつだ)。すでに作ってしまった日本語EUCファイル名を救うようなツールとかがあるといいかも。

tagohさんからconvmvというのがあるよ、ということで。debもすでにあった。

	 USAGE: convmv [options] FILE(S)
	-f enc     encoding *from* which should be converted
	-t enc     encoding *to* which should be converted
	-r         recursively go through directories

chasen

同音で表記の違っているのを探すのに使えないかな。

ということで、1ライナー。

stripsgml < *.sgml ref/*.sgml |LANG=C sed -e 's/[[:print:]]//g'|chasen|awk '{print $1 "\t" $2}'|sort|uniq -c|sort -k 3

stripsgmlの部分はまぁどうでもよいわけだが、要は標準入力→英語モードで英数字記号を除去(日本語と制御文字が残る)→形態素解析→余分なカラムを取る→まず1カラム目(表記)でソート→同じ行をまとめ、カウントも付ける→読みでソート→標準出力に出力という流れ。

結果はこんな感じ(抜粋)。

	    161 与え    アタエ
	      1 与えよ  アタエヨ
	      1 あたえる        アタエル
	     34 与える  アタエル
	      8 あてはまら      アテハマラ
	      1 あてはまり      アテハマリ
	     13 当てはまり      アテハマリ
	      1 当てはまる      アテハマル
	      2 有り得  アリエ
	      1 ありえる        アリエル
	      1 言い換える      イイカエル
	      6 言い替える      イイカエル

XEmacs + VMware

警告が出るのは、

xmodmap -e "remove lock = Control_L"

のようなことを実行すればとりあえずは回避可能？場当たり対処ですが。

なんかdebian-develかdebian-xでxkbがうんぬんという話をしていた気がする なぁ…。ctrl:nocapsだったり、KDEのキーボード設定を使っていたり、VMware と行き来したりするとどうもひどい目にあうらしい。

これですかね。altwinのほうの話では

A workaround you can use if your application has not yet been fixed is to set the altwin:super_win XKB option. To try it out, run the command setxkbmap -option "altwin:super_win"*. To make the change permanent, run dpkg-reconfigure xserver-xfree86 as root, and add altwin:super_win to your configured XKB options when prompted.

なので、ctrl:nocapsも似たようなものかな。

で、workaroundじゃない解決はやはりXEmacs側を直せということらしい。

インストールマニュアルpo版

Frans Popから「どうよ？」と尋ねられていたのにようやく返事(d-doc@jpの意見を待ってたりもしてたので)。

結論から言うとネガチブ。日本語がちゃんと通ってpo処理できるいいツールがあまりないし、文脈依存で訳したいときにparaで切ってしまったpoは向かないと思う。なお、訳注で新規段落を入れると以降ぜんぶずれてしまうというオマケ付き。

アップロード箇所

実際にdakとか動かしていろいろわかってきたことですが、dput/duploadの送付ディレクトリはuncheckedに直に行ってるわけではなさそうです。

debianqueued(ソースはproject/ディレクトリにある)がアップロードディレクトリを監視していて、簡易チェックに成功するとuncheckedに入ってるというようになっているかと。

アップロードすると「uploadができたよ」という旨のメールが最初にくるはずですが、これがdebianqueuedからきているものです。debianqueuedのチェックとしては、サインされているかchangesにあるものがちゃんとあるかといったものですね。ダメならさっさと削除しているようです。このおかげで、このあとの「重い」処理がいくらか軽減されますし、queueの中をやっぱり消したい！とメンテナが思ったときに自分で処理(コマンドファイルのアップロードで)できるというメリットがあります。debianqueuedはcronではなくデーモンであり、各ファイルごとに一定の待ち時間を持たせています。

チェックに成功するとuncheckedに入り、これをdakスイートのjenniferがcronで処理してはじめてaccept/reject/newのメールを送ると。accept/reject/newはそれぞれまた別のツールで適切に処理します。

britneyが重いのは、こいつはtesting処理なので、膨大なパッケージ群の中からtesting落ちに必要な各パッケージの相互依存関係をチェックするなどタイヘン。いろいろ軽くなるように前段階でパッケージの情報を持たせるなどしてるんですが、それでもキツイのでしょう。実際のところまだ手元でtesting処理には成功していないので、どの程度重いのかはよくわかりませんが。ソースを見た限りではなんかシチメンドーくさそうなことをしてるなぁという感じ(笑)。