cdparanoiaがOになっていたのでITAしようと思った。その前にDMで興味がある人がいたので話した結果、光学メディアのツール関係をまとめてteam maintenanceをすることにした。ということでOptical Media Tools Teamを立ち上げてしまった。勢いでやってしまったな…。

• Aliothでプロジェクト申請。git-buildpackageを作るつもりなのでgitを使うよとチェックをいれておく。
• しばらく待つと無事にプロジェクトが作成された。DMをメンバーに足しておいて、MLを作成。このMLのアドレスをMaintainerとして使用する。
• 手元の git リポジトリを git.debian.org にアップロードする。
• パッケージを作ってアップロード

さて、今後チームが機能するかはわからないが枠組みだけは作った。どうなるかねえ…。

• Alioth/PackagingProject
• Alioth/Git

for where in ./ ../ ../../ ../../../ ../../../../ ../../../../../; do
       if [ -e ${where}debian/rules -a -d ${where}debian/patches ]; then
                export QUILT_PATCHES=debian/patches
                break
        fi
done

と ~/.quiltrc に書くとのこと。なんとなくバッドノウハウ臭いが…。

 POP3等のプロキシサーバ。こんなのあるんかいなと思ったらあった。user毎のマップを定義することで複数のPOPサーバへのプロキシとすることも可能。マッピングは単純な静的ファイルや正規表現、あるいはRDBやLDAPなども可能。テスト的に使ってみたが、localhostへ接続しているのに外部のサーバのメールがきちんと読めているのは面白い。

Ruby1.9でコンパイルが通らない。ruby.hを見ると構造体が変更されているようだ。でマクロが導入されたか。ちょいちょいとdepatchを使って修正。勉強になりました。

dh_auto_installとdh_installの違いがなんだろうと調べる。multibinaryのときにdh_auto_installでdestdirを指定して、dh_installで動かす、という理解でいいのだろうか？

DEBUILD_LINTIAN_OPTS=-i

を ~/.devscripts に書いておく。linitianのwarning時のinfoが詳細になるので見落とさんだろう。

ruby・perl・python・javaと4種類作成。

• ruby - cdbs使用。debian/control にrubyのバージョン毎に書かなきゃいけないのが面倒。ディレクトリ構成的に仕方がないのだけど。
• python - cdbs使用。てきとー。
• perl - cdbs。これも適当。
• java - dhで。override_*の使い方がなんとなくわかった。classとjniと二つ作らなきゃいけないのかと。policy読んでもBuild-Dependsとかの定石がいまいちわからん。default-jdk-builddepなんぞ入れるとgcjまで入るがgcjは作らないって。default-jdkでいいのだろうけど…。
  

ruby-pkg-toolsをインストールして cdbs からinclude する。controlにバージョン事に書いていけばいいのだが…。バージョン事にパッケージを作らなきゃいけないのでちょっと面倒。これRubyだけかね？

DebianのパッケージのMaintainerのアドレスをtakaki@debian.orgに変更開始。

qaが短かくなるよ。

• http://qa.debian.org/developer.php?login=takaki

debian-bug.el は Emacs上でBTSを使うツールなのだが、メールを送るときにrmailを使ってしまう。いろいろ問題があってrmailを使ってほしくなかったので変更したかったのだがやりかたがよくわからない。どうも mail-user-agent を設定すればいいというところまではソースから解読できたが、具体的な方法まであと一歩届かず。東京エリアDebian勉強会の資料からやっとやり方のヒントを得られた。答えは以下。

(if (boundp 'mail-user-agent)
    (setq mail-user-agent 'wl-user-agent))
(if (boundp 'read-mail-command)
    (setq read-mail-command 'wl))

/usr/share/doc/wl-beta/README.Debianを参考に。

• http://tokyodebian.alioth.debian.org/pdf/debianmeetingresume2008-natsu.pdf

とは言っても面倒なことはなかった。自分でdebianのpatchとupstreamへのパッチを分離しなけりゃならないのかと思っていたが、自動化してくれるツールがあった。まずはdpatch化を実現するためのdebian/rulesを作成する。dpatch(1)を参考に書き直す。cdbsならもうちょっと楽なのにと思いつつ書き直す。

パッケージのソースを展開した中で

$ dpatch-convert-diffgz  01 debian-patch

以上。

rejectされるのかしらんとかドキドキだったけど、特に問題もなくincmingに入っていった。alphaでFTBFSだってさ、面倒な…。

結構パッケージングに苦労する。以前にちょっとだけ作ってあったのだが、全部きちんとやろうとすると慣れないHaskellのパッケージだから面倒だった。

haskell-devscriptを使うのでcontrolをきちんと書けばいいだけなんだが…。Dependsに必要なものもsubstvarsで置き換えてくれる。ただ、build-depが多くて…。それをきちんと追加する。pbuilderで何回ビルドしたことか、ということ。ま、一回やってしまえばあとは当たり前の作業になるとは思うけど。

家のPCが前から微妙に挙動がおかしかったんだがいろいろ実は壊れていたらしい。どうも妙な具合なのでknoppix使ってxfs_repairをかけたら数十個のファイルが壊れていた。で、気になったのでdebsumsをかけてみた。2600ぐらいのパッケージのうち700ぐらいが何らかの異常があるとかよくわからんことになっていた。

tarとかが壊れていたのが、今までのパッケージ展開の謎の失敗と関係があるのかないのか。

apt-get --reinstall install を使ってパッケージをインストールして debsums でチェックをかけるとかやって大丈夫…なんかな。

新しいパッケージを作ろうとしてdh_make を実行。作られた debian/rules  を見たら。

%:
        dh  $@

いやあ…。世の中進歩したな。

git-buildpackageはデフォルトで親ディレクトリにパッケージを作成する。いまのディレクトリ構成が/path/deb/gbp/package という設定にしているので、パッケージ毎のディレクトリがファイルだらけになって嫌なので一つのディレクトリにまとめてしまいたい。

~/.gbp.confに以下を書いた。

[git-buildpackage]
export-dir = ../build-area/

これで ../build-area にファイルが生成される。

既存のパッケージの気になっていた部分を修正したぐらい。だけど一旦全部 git-buildpackage を使用するようにした。

変換方法は git-import-dscs を使った。これで今までのリビジョンも含めてgit のtreeに変換。git-buildpackage をつかってビルドする。手順は文書を読んでの通り。はまったのはorig.tar.gzを用意せずにいると git-buildpackage が自分でorigを作ってしまう。それがすでにアップロードした orig.tar.gz と微妙に違うためにエラーになってしまう。それは気をつけよう。

LDAPの更新、sshキーの送付、パスワードの設定、Aliothの設定等々。people.debian.orgにログインできたので自分でdebをアップロードしていこう。

苦節5年。というか手続にかかった期間の最長記録になっているな。

いろいろありましたが、Debian Developerになりました。takaki@debian.orgをよろしく。