毎日
2005年2月24日 (木曜日)
07:55:55 # Life Planetを整備してみました． Planet Debian-JPをplanet-jp.debian.netで見れるようにしてみました． これでvisibilityが向上したのであとはどれだけメンバーを追加できるかですね．
08:26:47 # Life Rでグラフをつくる例，面白い．
2005年2月20日 (日曜日)
16:41:34 # Life 第１回東京エリアDebian勉強会報告． 昨日はDebian勉強会でした． 楽しかったのでまた次回もぜひ．
- 部屋が1階から4階に変わったので前回も参加したひとのほとんどは迷ったそうです．
- まず，Debian勉強会についての説明と前回の報告概要．
- Debian Weekly News Trivia Quiz. 最高点数は２４点でその次は２０点くらいの方が数人いらっしゃったと思います．
- やまねさんのBTSの使い方についての熱い説明．reportbugは便利だなぁ，という印象です． debbugs-elって誰もつかっていないんじゃないの？という雰囲気だったのでどきどき． 私はたしかパッチを書いた記憶が．．．つかっていないわけではないので． ただ，バグをファイルするときにはつかっていなくて，バグの検索とかにだけ利用しています．
- debhelperについての上川の話し．dh_makeについて説明をしてDebian packageのソースの基本的な構造まで説明しました．
- Debianの新しいユーザをターゲットにした手法についてのグループワーク． 出て来たネタは「ISO取得改革：ISOを取得しているOSなので顧客説得力が増大」「見ためFedora，中身はDebian」「インストーラがゲームになっていて，ゲームの進行によってインストールの成否が決まってしまう．ゲームの対策本とかもでて今までにない層にひろまる」でした． 見ためFedora，中身はDebianについてはやまねさんがすでに実践されているようなので期待．
- Keysignの方法について説明，Keysignの儀式をしました．
- 前回朝までしたらしんどかったので，宴会は午前3時に解散しました．
- 次回は３月１３日の朝を予定．
今回はプロジェクターを借りたので，iBookから表示できるようにがんばってみようと試してみたんですが，画面らしいものが出るところまでは言ったのですが，なんか画面が黄色くなってしまうので，断念． 参考: ibookで外部ディスプレイに表示させるためのハック． Xの設定例．
会計，結果として赤字にはなっていないのでよいかな．
| 科目 | 出費 | 回収 |
| 資料コピー15人分 | 3969 | |
|---|---|---|
| うまい棒 | 100 | |
| 会場代 | 1500 | |
| 勉強会費 500x12 | 6000 | |
| 宴会 | 27641 | |
| 宴会代 4000x7 | 28000 |
2005年2月17日 (木曜日)
08:15:20 # Life Maintainer scriptの実行順序についてMargaが記述した説明． Debian Weekly Newsで見ました． 流れが図になっていてすばらしい． 図にしてみるとdpkgによりパッケージのアップグレード処理は複雑だ，ということが一目でわかりますね．
土曜日はDebian勉強会ですね． 〆切は今日の夜24:00までなので，よろしくおねがいします．
2005年2月16日 (水曜日)
07:47:51 # Debian 「このバージョンでしか試していないからDependsは(= 3.5.1-1)でいいよね」 「そんなことされたらこまるよ，勘弁してください」． そんな会話，それなりに経験を積んだDebian開発者でないとわからない． Dependsってなんだろう．
Debianパッケージの依存関係を表現するフィールドの一つがDepends. あるパッケージをインストールする際に他のパッケージが必須である場合にパッケージ名を記述する． またバージョンの範囲の指定がある場合は，指定を追加できる． 例えば，pbuilderパッケージを利用する際に，debianutilsパッケージが必要なのだが， 利用している機能はdebianutils 1.13.1以降でないと存在しないので， Dependsフィールドにdebianutils (>= 1.13.1)と記述してある．
このフィールドを拡大解釈すると，「依存しているパッケージがバージョンアップしたあとも自分の パッケージと連係して動くという保証はないから，今動作を確認したこのバージョンのみにDependsしたい」 ということも言える． しかし，そうすると依存関係が更新されるたびに更新する必要がでてくるパッケージが生まれてしまう． また，testingに入る際にも依存関係の両方がtestingの条件を満たして同時に入る必要がでてしまう． 現実的に考えると，アップグレードなどもしにくくなるため，運用上， バージョンを=で指定してのDepends関係は 基本的には同じソースパッケージから生成したバイナリパッケージ間，もしくはそれと同等な ものに限られている．
ただ，依存している先のパッケージがあたらしくなって，パッケージが動作しなくなった場合の チェックというのは現在ユーザが偶然試して発見することに依存しているので， なんらかの変更管理の方法というのは必要になって来るだろう． ただ，Debianは規模が大きすぎるので実装方法については検討が必要だ．
2005年2月13日 (日曜日)
17:58:23 # Debian 「Conflictsにバージョン指定で書くのはよくないんだ，ポリシーにも書いてあるよ」． 「へぇ，そうなの？」 という会話を見ても，Debianを知らない人にはわからない．
Debianパッケージが持つ依存関係のフィールドの一つにConflictsがある． そのフィールドには，同時にインストールしてはならないパッケージの名前の一覧がある． aptやdpkgなどのパッケージ管理ツールはその情報を利用してくれる．
Debianにおいて， 依存関係を指定する際に，このパッケージは必須ではないのだが，このバージョン以上でないとまずい，という場合の依存関係の書き方が一番難しい． そのパッケージのバージョン以降で修正された機能が連係に必要，という場合など， Dependsで指定してしまうとそのパッケージをインストールしないという選択ができなくなるからだ． ここで，強制的に過去のバージョンがインストールできないようにConflictsフィールドに過去のバージョンが入らないように Conflicts: パッケージ (<< バージョン)と指定してしまうと，一旦そのパッケージを削除してからインストールするという処理が必要になる．
事前にそのConflictされているパッケージをバージョンアップすることでも，削除することでも満たせる依存関係であるなら， 削除するという選択は理にかなっている． しかし，こういう状況において，依存関係を設定した開発者側が求めているのはそういうことでなく， 最低限このバージョンのこの機能が提供されている必要がある，ということだ．
今後はそういうケースが劇的に増えることがあれば何らかの新しいフィールドを導入することになるだろう．
2005年2月11日 (金曜日)
15:36:04 # Life 長い旅行の後なので時差惚けかつ放心状態です． とりあえず旅行中に出会ったWashington D.C.の人達にバッチでGPG署名処理して送る．
2005年2月7日 (月曜日)
12:13:45 # Life ここ数日のdebian-devel@jpでの検討事項として， デフォルトの日本語入力をeggからyc-elに変更 してみようという話がある． canna側としては，デフォルト設定にてinetをenableにしたくないのだが， taskで入るeggが，inet接続を必要としている． inetを使わないことにするための 最後の障害として存在するのがeggであるのなら，eggをデフォルトのインストールから除外したい． yc-elをデフォルトにすることでそれが達成できるのであれば，それはそれでよい． yc-elをデフォルトにするのであれば，language-envとtaskselに変更が必要な気がする． むとうさんはその両方を変更できるらしい． さて，何が必要なのだろうか．
武藤さんの日記に御指摘があったので，訂正．
2005年2月5日 (土曜日)
22:23:38 # Debian 「Dependsが足りないからエラーが出る．これはseriousなバグだな．」 そんなクレームを付けられたとしても，Debianを知らない人には意味が分からない． Dependsが足りないってどういう意味だろう．
Debian のパッケージにある制御情報の一つがDepends. 実行する際に必要なパッケージの一覧をそこに記述しておくと， インストールの際にapt等のツールが必要なパッケージが存在することを保証してくれる． パッケージビルド時に共有ライブラリの情報など一部の情報は自動で取得できるが， 多くの部分，Dependsフィールドの維持はメンテナの手作業に頼っている． アプリケーションを動作させた場合にこのパッケージがないと正常に動作しない，ということが 判明したら随時そのパッケージをDependsフィールドに追加する． メンテナ側のその地道な努力によって，apt-get install するだけで動作する パッケージが生み出される．
ときどきパッケージ側では回避できない問題というのは発生する． たとえば，自動で共有ライブラリの依存関係情報は取得できるが， 共有ライブラリパッケージ側の仕様変更などが発生した場合には， プログラムが実行できない状況が生まれる． そういう状況を防ぐための経験を集めたものが，上川作のlibpkg-guide. 今後もいろいろな問題が発生すると思うが，それをまとめたドキュメントとして維持したいものだ．
共有ライブラリの問題の例
$ cat a.c
main()
{
test();
}
$ cat b.c
test()
{
}
共有ライブラリが見付からないときのエラー出力例:
$ gcc -shared b.c -o libb.so $ gcc -L /test -l b a.c $ ./a.out ./a.out: error while loading shared libraries: libb.so: cannot open shared object file: No such file or directory
共有ライブラリの仕様が変わったために，シンボルが見付からなくなった場合のエラー出力例
$ vi b.c でシンボル削除 $ gcc -shared b.c -o libb.so で再度共有ライブラリのみをコンパイルしてみてから $ LD_LIBRARY_PATH=. ./a.out ./a.out: relocation error: ./a.out: undefined symbol: test
2005年2月4日 (金曜日)
10:54:55 # Debian 「仮想パッケージを設定して，ProvidesとConflictsを設定すればよいよ」． 「あぁ，そうしたらこれらの同時に一つしかインストールできなくできるね」． そんな会話をしているDebianハッカーたちがいたとしても，一般人にはわからない． ProvidesとConflictsってなんだ？
Debianのパッケージの制御情報には依存関係が記述できる． その依存関係にはDependsや，ProvidesやConflictsなどがある． Providesフィールドは指定した仮想パッケージ名を提供しているということを示す． また，Conflictsで指定したパッケージとは同時にインストールできない． 複数の同じ機能を提供するパッケージがあり，そのうちの一つだけしかインストールできないという 条件はProvidesとConflictsを同じ値にしておくことによって実現できる． ある一つのパッケージが自分がProvidesにより提供する仮想パッケージ名に Conflictsで衝突していると宣言しても，自分自身に対しては衝突しないと定義されている から，そのパッケージ自体はインストールできる． 同じパッケージをProvidesしている他のパッケージがアンインストールされることになる．
共有ライブラリの開発用のファイルで，複数のバージョンがある場合によく使われる． libsomething2-dev とlibsomething3-devというパッケージがあった場合に， 多くの場合実行時に必要なバイナリの互換性はなく，ファイルも衝突しないのだが， ソースコードから利用するファイルや，.soのシンボリックリンク，.aのアーカイブファイルなどは 同じファイル名であることが多い． その場合には，libsomething-devを両方のパッケージからProvides: libsomething-dev, Conflicts: libsomething-dev で 宣言することにより，同時には一つしかインストールされないという状況をつくり出せる．
この設定は比較的わかりにくいため， できることならalternativesの活用やプラグインシステムを 活用して，複数のパッケージのうちの一つしかインストールできないという状況はできるだけ避けたい． この依存関係条件を利用するのは共有ライブラリの開発用パッケージの場合だけにしたいものだ．
12:30:28 # Life やまねさんがgnome-translationにメールをなげられていたようだ． しかし，あまり反応が無いみたい． 以前私がgnome関係の翻訳をこっそりとがりがりとやっていたときには， さっぱりcoordinationしていない感じだったので他の人と作業が衝突しまくっていた． gnomeの翻訳関連では，相花さんという凄い人がいて， 壮絶な量の翻訳をなさっている．
そういえば，二週間後にDebian勉強会ですね． まだまだ，と思ってたらもうすぐかも． キーサインパーティーをしたいのだけど，どこで実施しようかなぁ．．
2005年2月3日 (木曜日)
22:41:27 # Debian 「lintianとlindaはよいといってくれているの？」 「一つだけwarningが出るけど，それは必要なものなので大丈夫です」 時々sponsorする人とされる人の間でそんな会話がかわされる Debianを知らない人にはさっぱりわからないlintianって何だろう．
lintianは，Debianパッケージが正常にパッケージされているのかということを 既知のよくある間違いに関してチェックしてくれるツール． パッケージの説明文がテンプレートのままだったり，メンテナの名前が間違っていたり， changelogファイルがなかったりという間違いについて検出してくれる． lintianは基本的にはDebian policy に関してチェックして， できるところについてがんばって見てくれる． lindaはperlで実装されているlintianをpythonで実装しなおしたもので 2年前くらいに出て来た．当時はlintianの開発が停滞していたので 必要性が感じられたが今の存在意義は微妙． 今はlintianはひとりで担当しているのではなく，メンテナのグループがあって 活発に更新されているみたい． 今はとりあえずみんなlintianとlinda両方実行しているのかな？ debuildはデフォルトではlindaではなくlintianを実行する．
今後もlintianは活発にメンテナンスされていき，既知のよくある問題に対してのチェックが 増えて行くだろう． そして，新人デベロッパーもすでにデベロッパーをしている人達からlintian必須とのことを 伝えられているので，最低限のQAの機能としてうごいてくれるのではないだろうか． 最近はすでにpdebuildしか使っていないという人も多いみたいなので， pdebuild/lintianでそれなりにチェックできているのだろう．
まだまだ自動化してチェックできる問題というのはあるはずなので， いかにデベロッパに負担をかけずにチェックを自動化するか， というのが今後の課題だ．
2005年2月2日 (水曜日)
23:06:29 # Debian 「メンテナにはまだなっていないけど，Sponsor uploadしてもらえばいいじゃん」． そういうアドバイス，Debianの開発体制に詳しくないとわからないかもしれない． Sponsor upload ってなんだろう
Debianには，Developer というステータスがある． Debian gpg keyringに登録されている人のことで， パッケージを直接アップロードしたらDebian Archiveに反映される人達． だいたい世界で1000人程度の人が居る． しかし，そのステータスに至る前にはNew Maintainerとしてのプロセスを経る期間があり， すぐにDebian Archiveへの直接の貢献ができるわけではない． Developerとして参加できる前の人がDebian Archiveにパッケージをアップロードするには すでにDeveloperである人がSponsorという形式で代理アップロードする． Developerが，Developerでないひとが作成した パッケージを確認し，Developerの鍵で署名してアップロードする．
Sponsor関連については，活発にdebian-mentorsメーリングリストにて議論されている． 今後も，New Maintainerが増えていくことによりSponsor活動が広まるだろう． Sponsorの要件についてもはっきりとしたポリシーをうちたてる必要が出るかも知れない．
なお，sponsorする側として現状署名するのにどのコマンドをつかったらよいか迷うところだが， IRCできいたところ，broonieとtbm曰く，-kを使えとのこと． debsign -k ですね．
気づいたらFront Deskにメンバーが追加されていて Front Desk の作業の概要についてのドキュメントができていますね．よいことだ．
2005年2月1日 (火曜日)
21:56:41 # Debian 「今日のunstableはapt-get upgradeではアップグレードしきれないから，apt-get dist-upgradeでアップグレードしないと．」「え，でもそれってリスキーだから僕は手動で」． そんな会話を交わしているDebianな人達がいたとしても， Debianをつかったことのない人には意味がわからない．
Debianはunstable distributionというのを一日一回リリースしている． そして，最新バージョンにアップグレードするのに多くのひとはapt-get upgradeコマンドを利用しているらしい． apt-get には，upgradeというコマンドとdist-upgradeというコマンドがあり， upgradeコマンドはできるだけ既存のパッケージを既存のままで依存関係をみたしつつアップグレードさせようとする． dist-upgradeコマンドはそういう制約はなく， 依存関係が必要とするものであれば， 新規のパッケージを導入したり既存のパッケージを削除したりして， 最新版にアップグレードする．
dist-upgradeの危険なところは，依存関係に問題がある場合， 多くのパッケージを削除してしまったり，影響が大きい事． 通はapt-get dist-upgrade -s コマンドで シミュレーションし，影響を確認してから実行する． 手間をおしまないのであれば，apt-get upgradeして held-backと表示されるアップグレードされない パッケージをそれぞれひとつづつapt-get install してみるのも手だろう．
apt-get を直接利用しているからでてくるこういう話題も， 今後aptのインタフェースがいろいろと出て来たら聞けなくなるのかも知れないなぁ．
apt-get でheld-backになっている例
# apt-get upgrade パッケージリストを読みこんでいます... 完了 依存関係ツリーを作成しています... 完了 以下のパッケージは保留されます: alsa-base gaim gettext gimp gimp-data kernel-image-2.6.8-powerpc openoffice.org openoffice.org-debian-files openoffice.org-l10n-ja
パッケージが削除されるだろうdist-upgradeのシミュレーションをした結果出力例．
# apt-get dist-upgrade -s | grep ^Remv Remv gimp (2.2.3-1 Debian:unstable)
Junichi Uekawa
$Id: 200502.html.ja,v 1.23 2005/02/26 09:18:30 dancer Exp $