つれづれ日記 2005年1月

予定

毎日


2005年1月28日 (金曜日)

22:13:08 # Debian 「そのパッケージのインストールはapt-get installだけでよいです.」 「apt-lineは?」 「mainに入っているので標準でよいよ」. そんな会話をDebian ユーザの間でかわしている場合 Debianをしらない人はどんな顔して聞いていたら良いのだろう?

apt-get は,Debian GNU/Linux で利用するパッケージマネージメントのシステムAPTの 最も基本的なインタフェースの一つ. コマンドラインベースでコマンドを発行するためのもの. apt-get install パッケージ名というように指定すると, 指定した名前のパッケージをインストールしてくれる. dpkgとは違い,該当するパッケージと追加で必要な ファイルをhttp経由などでダウンロードしてくれて, インストール処理をしてくれる. 実際には裏ではdpkgを実行している.

apt-line と呼ばれるのは, apt-getの設定ファイルである/etc/apt/sources.listに記入する設定行. 例えば,deb http://ring.asahi-net.or.jp/archives/linux/debian/debian/ unstable main contrib non-free と指定すると, apt-get updateコマンドを発行してキャッシュを更新したら, apt-get installで指定したサーバからパッケージをダウンロードできるようになる. この行はring serverにあるミラーからhttpで unstableのmain/contrib/non-freeを取得するという意味. 設定についての詳細はman sources.listに詳しい.

今後aptで問題となるのは,パッケージ数が1万を越えたDebianのなかでいかに必要なパッケージを 探索するのか,というインタフェースの部分と,apt-getというインタフェースではないより GUI向けのインタフェースをどう作るか,ということだろう. debconfにはHTTPインタフェースや,GTKインタフェースがあるため, もっとGUIを活用することもできるはずだ.

そんな試み,というかネタの一つでapt-mode.elがあるんですが,まだまだですね.放置中. debconfのemacsフロントエンドとかあるとおもしろいかも.

2005年1月27日 (木曜日)

21:58:01 # Debian 「dpkgで直接パッケージをインストールしてください」. 「めんどくさいなぁ」. そんな会話,Debianユーザの間でないと通じない. dpkgってなんだろう.

dpkgはDebian GNU/Linuxで利用するパッケージマネージメントのソフトウェア. 通常は,インストール済のパッケージの一覧を取得したり(dpkg -l), ファイルの所在(dpkg -S ファイル名)を確認したりするのに利用する. また,deb形式のパッケージのインストールや削除などを実施する際に利用する. dpkgでパッケージをインストールする場合には,ローカルにファイルとしてdebファイルがある際に dpkg -i debファイル名として指定する. そうするとそのdebファイルをインストールしてくれる. 問題となるのは,dpkgを利用する際には, 欲しいパッケージとそれをいれるために必要な依存する追加パッケージをすべて ファイルとして取得しておく必要があること. 次元としては,Red HatのrpmやSolarisのpkgadd,Windowsで 直接.msiを実行したりsetup.exeをダブルクリックするのとだいたい同じ. dpkgのフロントエンドとして, aptを利用すれば,必要なパッケージ名さえ指定すれば, 必要なファイルを全てhttpなどで取得して,dpkgで順番にインストールしてくれる.

wajigや,aptitudeなどのフロントエンドがどんどん発達してきているため, 今後は,dpkgを直接たたくことは少なくなるのではないだろうか. 個人的には,GUIの発展より,よりすくないタイピングで全てを実現できるような 拡張の方向を期待している.

ついでに. dpkgコマンドでファイルを検索する例. どのパッケージにどのファイルがあるのかということを出力してくれる. 同じことをdlocateコマンドでできて,そちらのほうがキャッシュしているため,速い.

[00:20:13]ibookg4:~> dpkg -S bin/sh
xutils: /usr/X11R6/bin/showfont
console-tools: /usr/bin/showcfont
passwd: /sbin/shadowconfig
coreutils: /usr/bin/shred
sharutils: /usr/bin/shar
bash: /bin/sh
console-tools: /usr/bin/showkey
coreutils: /usr/bin/sha1sum
xutils: /usr/X11R6/bin/showrgb
sysvinit: /sbin/shutdown
	

2005年1月26日 (水曜日)

23:21:38 # Debian 「あぁ,そのパッケージね,PTSでトラッキングしてるから大丈夫だよ」. そんなことを言う人が居る. 何が大丈夫なんだろうか? DebianでのPTSってなんだろう?

PTSはpackage tracking systemの略. 各パッケージ毎にパッケージの状況がわかるページがある. 特徴としては, subscribeするという旨をメールすると, そのパッケージに関連したバグ報告などのメールを受信できるようになること. 従来では,メンテナとして,Maintainerフィールドに書いてある人しか パッケージに関してのバグ報告のメールなどは受信できないようになっていた. PTSによってパッケージに関連したバグ報告をメンテナ以外が受信できるようになる. これで,気になるパッケージが今どういう状況で,あのバグがどうなっているのか,逐次報告が受けれるようになる.

この流れは,Maintainer/uploaderフィールドに受け継がれていった. Uploaderに追記するのは,いわゆるコミット権を持つということなので, 開発に積極的に参加し,認められる必要があるが, PTS自体は開発者指向でなくても利用できるため, ユーザ側からの活用もできるのではないだろうか.

RSSなどの新しいプロトコルが普及しているので,今後は,メール以外のインタフェースでの展開もできそうだ.

2005年1月25日 (火曜日)

23:39:40 # Debian 「ビルドされるときのアーキテクチャ名ってどうやったらわかるの?」「dpkg-architectureを使えばよいんじゃない?uname -m だとクロスコンパイルとかができないからね.」 とか言われてもよくわからない.dpkg-architectureとは何者なのだろう.

DebianのArchitectureの名前は,実は一般的に言われているuname -mの名前と違う. また,コンパイルする環境によってuname -mの値は変わる. たとえば,最近のCeleron CPUが動いているマシンの場合,DebianとしてのArchitecture はi386なのに,uname -mはi686になる. また,GCCから見たマシンは,powerpc-linuxになる.

[23:45:45]ibookg4:~> dpkg --print-architecture
powerpc
[23:45:49]ibookg4:~> uname -m 
ppc
[23:45:52]ibookg4:~> gcc -dumpmachine
powerpc-linux
	

dpkg-architectureは, その情報を扱うためのインタフェース. Debianで利用しているArchitecture 情報とGCCが利用しているArchitecture 情報を提供してくれる. debian/rulesの中で DEB_BUILD_ARCH = dpkg-architecture -qDEB_HOST_GNU_ARCH のようにして使い,コンパイルオプション等を決定する.

このプログラムはもともとhurd-i386という移植プロジェクトで安定してコンパイルができるようにと 考えられたもの.hurd-i386は,DebianのArchitecture名がCPU名でない例. 現状ほとんどのプログラムはuname -mdpkg --print-architectureの 代わりにdpkg-architectureを使うように変更されているはず. 今後は組み込み用途のCPUへのクロスコンパイルへの要望が増えるにしたがって よりクロスコンパイルできやすいようにDebianが変わっていくのではないだろうか?

クロスコンパイルの際の設定については,「えびめも」ページにメモがある. ただ,これだけではダメで,cross用のパッケージを生成する手順がどっかにあるはず. ひさしぶりにえびめもを読んだら面白くて読み込んでしまった...ひぃ. 安定したクロスコンパイルの方法を確立するのは今後の課題. クロスコンパイル用のツールチェインのバイナリパッケージを提供するとか, できるといいんだけどなぁ... あと,pbuilderでクロスコンパイルできるようにすると楽なんだけどなぁ.

2005年1月24日 (月曜日)

00:13:28 # Debian 「全部のArchitectureでビルドできていないからリリースはできませんよ」. そんなふうに叱られても,こまっちゃう. DebianでいうArchitectureってなんだろう.

Debian GNU/Linuxはいろいろな種類のCPUで動作する. そのCPUのことをArchitectureという. CPU以外の部分についてはsub-architectureという分類をする方針になっていて, CPUが実行できるコードが同じものについては一つのArchitectureとして扱う. たとえば,m68kというArchitectureには,MacとAMIGAが含まれる. この二つのコンピュータの構成は大きく違うが,同じm68k CPUを利用しているために 同じArchitectureに分類される. DebianのバイナリはArchitecture毎に分類されていて, 各アーキテクチャ用に.debファイルが提供される. 現在Debianには,10種類程度のアーキテクチャがあり,その一覧はportsのページに載っている. 開発者が自分の利用している Architecture でコンパイルしたバイナリとソースをアップロードすると builddが残りの Architecture のためにビルドしてくれる. testingの要件として, 以前ビルドできていたArchitectureに関しては, ビルドできなくなった場合には,そのパッケージはうけいれないというものがあり, そのため,開発者は全 Architecture でコンパイルが通るように力をそそぐことになる. 結果としてほとんどのパッケージが常に全 Architecture でビルドできているという状況が生まれる.

今後もさらに怪しいアーキテクチャが生まれて行くだろう.特に,FreeBSDカーネルや GNU/Hurdへの移植版アーキテクチャなどがリリースされた暁には メンテナへの負荷もさらに高まるだろう. ここまでくると,問題の優先度合の調整や,さらなる問題のトラッキングの自動化などが求められる.

00:48:33 # Life cvsのタグの使い方をわすれていたので,CVS/Entriesを編集してしのぐ.困った.

08:26:54 # Life aptitudeについてえとーさんの語りによるとaptitudeは apt-get に加えて,依存関係を満たすために自動でインストールしたパッケージ というものを必要無くなった際には削除してくれる機能もあるという. つまり,deborphanやdebfosterで補完していた機能を自分で正確に実装してくれるらしい. aptitudeというとGUIにばかり目がいくが,そういうところもあるらしい. 実はとても便利かも知れない.

21:27:48 # Life 思い付きで始めのに気が付いたら一月以上続いている Debian用語集シリーズですが,そろそろネタがきれてきました. 「これを忘れていないか?」「この言葉わからないぜ」という御指摘などありましたら,よろしくお願いします.

2005年1月23日 (日曜日)

07:32:18 # Life whizzytexを久しぶりに使っているといろいろとはまる. texファイルの中にある %; whizzy で設定しようとしてもうまく設定できていないっぽい. ここを解析している部分は emacs lispとbash scriptが連係している部分で,デバッグするのが面倒だ. 久しぶりすぎて何をしているのか思い出せない. .whizzytexrcを作成して設定するとなんとか動くようだ.うーん.面倒だが こっちで回避. あと,adviでどうも日本語が出ないとおもったら,jsarticleを使っているかららしい. jsarticleを利用しているとjisとjisgというフォントを必要とする. それは,標準のmin とgothではないため,Debianのadviの標準の設定では無理. 以前大浦さんがはまったところにはまったようだ. ptex-jisfontsで提供されているフォントはadviで利用できない状況にあるらしい. \documentclass[mingoth]{jsarticle}と指定するとminとgothで 文書が書けるらしいので,それでとりあえずは回避する.

2005年1月22日 (土曜日)

21:54:39 # Debian 「IRCでの議事録をおくります」.そんなことを言われて すごい長いテキストファイルをおくられても普通の人はなんのことやら分からない. IRCってなんだろう.

IRCはテキストベースのチャットのためのプロトコル. Debian Projectでほぼ公式に使われているリアルタイムのコミュニケーションチャンネル. IRC自体はテキストベースの会議室プロトコルで, チャンネルとよばれる単位で会議室が分けられる. AIMなどと同じ要領なのだが,それらは個人対個人の通信を主眼としているのだが, こちらは大人数で話ができるようになっている. Debian Developer向けの#debian-devel チャンネルには 常に100人以上の開発者が居るし, ユーザ向けの#debianチャンネルにはユーザが多数常駐している. Debianとして使っているIRCネットワークは二つあり, irc.oftc.netと,irc.debian.orgからつながるネットワークがある. 現在両方とも利用されている. irc.oftc.netのほうが新しいが歴史的な経緯からirc.debian.orgはFreenetを指している. 今は分割してしまっているので,誰がどのチャンネルに居るのか,ということを調査して, そのネットワークに接続する必要がある. 今確認したところ,#debian-develチャンネルには,irc.debian.orgでは300名程度,irc.oftc.netでは100名程度接続していた.

IRCは,特有のnetsplitという現象があり, ネットワークの混雑などの影響により,会話が断絶されることがある. 今後はより安定したチャンネル,もしくはより安定したプロトコルへの変更が望まれる.

21:58:31 # Life RSSを出力されるようになったということで, hemamuさんの日記をこっそりとplanetに追加.

2005年1月20日 (木曜日)

19:19:37 # Debian 「make-kpkgでカーネルをビルドすると楽だよ」. そういうアドバイスをもらってもDebian以外には通用しない. make-kpkgってなんだ?

make-kpkgはLinuxカーネルをコンパイルする際に利用できるツール. Debianのkernel-packageパッケージに入っていて, Linuxカーネルのソースコードから, カーネルのDebianパッケージを生成する処理を自動化してくれる. 使い方については簡単にまとめているページがあるのでそちらをどうぞ. 今は,Linuxカーネルのみしか対応していないが, 今後はおそらく他のカーネルにも対応するだろう. 意外と使っていない人が多いが,Debianを使っているのなら便利なので利用すべき. ただ,他のディストリビューションなどでは利用しないプログラムなので, そこが難しい. 誰かrpm版とか作ってくれるとよいのにね.

2005年1月19日 (水曜日)

22:04:29 # Debian 「メーリングリストを読んでる?あのパッケージすごくねぇ?」「あぁ,あれね.凄いよね.」 そんな語らい,Debianを知らない人には全く通じないかもしれない.

Debian Projectの公式な情報交換方法は,メーリングリスト. メーリングリストを介して情報の交換をする. Debian Projectで利用できるメーリングリストは ウェブで公開されており,さらに 誰でもメールが投稿できる設定になっている. このため,広告メールなどが大量に来る. また,メールの量も多く,大量にメールが流れているため, 全てを把握するのは難しい. 全開発者が参加しているメーリングリストはdebian-devel-announceだけ. 多くの開発者が参加しているのはdebian-devel, ユーザが参加しているのは,debian-user. それ以外のメーリングリストはより技術的に細分化された目的のために開設されている.

誰でも投稿できるメーリングリストは広告メールなどが大量に流れるため, いつまでもこのシステムが維持できるとは思えない.現状はspamassassinなどで 力で力に対抗している形になっている. 今後は,よりメールの投稿者に負荷をかけずに,読む人にも負荷をかけない, サーバにも負荷をかけない方式に変更するのではないだろうか.

2005年1月18日 (火曜日)

20:00:32 # Debian 「期間中にvoteしてください」. そんなアナウンスが流れる. DebianでVoteしているときって何しているの?

Debian Projectでは,選挙の際や,正式な手続きをとってものごとを決定したい場合には, 投票を実施する.その処理をvoteとよび, それ専用のメーリングリストdebian-voteがある. 投票の開始や投票する内容についての議論の期間の開始や終了については debian-devel-announceメーリングリストに宣言が流れる. Debian Developerになると投票する権利が生まれ, gpg鍵で署名したメールを投票用メールアドレスに送信することにより, 投票が実施できる. 投票された票を処理するのは, 投票処理用のプログラム (昔はDebvoteというプログラムを使っていた). そのプログラムが署名を検査して,優越したものがどれであるかという結論を出す. Debianの投票でおもしろいのは,択一式ではなく,優先順位を付けて投票するということ. そして,その優先順位を総合して「この項目はこの項目よりもこれだけ優先投票があった」という マトリックスを出して投票結果を出す.

択一式の選択では,最高の項目しか選択できないため, 論理が少し難しいが,今後は,Debianで利用している投票方法がより広まるのではないだろうか.

しかし,投票の際にしか触らないDevoteeプログラムがDebianパッケージになってくれる日は来るのだろうか. 個人で利用する際も,gpgのキーリングさえ作ればメールベースでの投票式の意志決定ができるため 便利なんじゃないだろうか.

2005年1月17日 (月曜日)

05:53:24 # Debian 「aliothにプロジェクトを作ったよ」.そんなこと言われてもどこの話しをしているのかわからない. aliothって何?

aliothとは,DebianでホスティングしているGforceシステム. sourceforgeのようなシステムをDebian専用に構築している. Debian専用のパッケージについての共同開発や, 共同作業をするためにパッケージング用のファイルをCVSレポジトリで管理する場合などによく利用できる. Debian Developerであれば,だれでも利用でき, なおかつDebian developerでなくても利用できるという特徴があり, Debian Developerにこれからなろうとする人であっても利用ができる.

Debianのパッケージは過去にはある一つのパッケージは一人のメンテナという制度が大半だったが, 最近は,メンテナが複数いるケースが出て来ている. そのような場合のための共有レポジトリとして利用できる. Maintainerフィールドに書いてある名前が主のメンテナだとしたら,Uploaders: フィールドに書いてある名前が共同メンテナ.また,Maintainerフィールドに書いてある名前自体がメーリングリスト であったりする場合もあるが,その場合責任の所在がよくわからないのが微妙.

今後はよりパッケージの共同メンテナンスがすすむことと思われる. 一人でメンテしているよりも複数でわいわいとメンテするほうが楽しかったり, 反応しやすかったりする. 決定権が誰が持っているか,などの問題も多くあるのだが, メリットのほうが多いのではないだろうか. この点については時間が判断してくれるだろう.

06:05:16 # Life Debian勉強会の予定を更新. 次回のDebian勉強会のネタについてタイトルだけではなんとも分かりにくいので, こういう話しをします,という宣言もこめて, 概要を追記しました. あと,前回のえとーさんの感想を捕捉.

2005年1月16日 (日曜日)

16:47:34 # Debian 「debhelperって魔窟だよね」.そんな言い訳がある. Debian Developerにしか通用しないそんな言い訳.どういうつもりなのか知りたい?

debhelperとは,Debian のパッケージシステムの定型的な部分をスクリプトとして分離したスクリプト集. たとえばファイルをコピーするだとか,ドキュメントをコピーするだとか, ファイルの所有者権限を設定するだとかいう処理を担当するスクリプトがたくさんある. 各スクリプトはdh_で始まる名前で, パッケージをビルドするためのスクリプトであるdebian/rulesの中から呼び出される. 例えば,dh_installmanはmanpageファイルを指定したら,結果のdebファイルをインストールしたら それっぽいディレクトリにインストールされるような場所にコピーしてくれる. このように目的に応じてスクリプトとして抽象化することの利点としては,たとえば ポリシーの変更が発生し,manpageの配置する場所が変わったとしても スクリプトだけを変更しておけばよいということになる. また小さな仕事のみをする各スクリプトが分離しているのは, 設定ファイルベースの巨大なスクリプトプログラムが動作するよりも, 単純なプログラムをdebian/rulesからメンテナが駆動するほうがメンテナンス性と複雑性が 低減するという考え. あらゆることをするスクリプトというのがdebhelperの前には存在しており,それがdebmake (debstd). debstdの失敗から学び,Debhelperを統合する形で開発がすすめられているのが cdbs. 今後は,debhelper はdebhelperとして開発が進み, 統合ビルド環境としては,cdbsが展開していくだろう. しかし,Debianのほとんどのパッケージはdebhelperを利用しているため, まだまだこれからもdebhelperはつかわれていくだろう.

dpatchなどのパッチ管理ツールを統合してくれているcdbsの今後がたのしみだ.

2005年1月15日 (土曜日)

10:59:22 # Debian 「Trust pathが無いよ」. そんな断りの言葉がある. Debian界隈でしか通じない,そんな言葉の意味を知りたい.

Trust Pathとは,GPGの鍵の信頼の経路の事. その鍵はその人のものであるということを信頼していることの表明として署名(Keysigning)をする. また,自分が署名した鍵の所有者が署名した鍵については,そこに至るまでの署名の経路みたいなものができたと考える. 知り合いが知り合いだという人についてそれなりな価値を見出す. そのような知り合いつながり経路のことをTrust Pathというみたいだ.

現在のDebianはおそらく4人経由したらどのDebian Developerでも会った事がある,という程度の 計算になる.今後もDebianの規模の拡大とKeysigningの活動の中でその程度のTrust Pathの維持は継続できるではないだろうか.

11:22:27 # Life Debian勉強会の会場を変更しました. 同じ建物の若干広めの部屋に変更しました.定員30人です.

2005年1月14日 (金曜日)

07:42:41 # Debian 「Keysigningしましょう」. そんな誘いの言葉,君はのれるかい? Debian界隈でよくささやかれる口説き文句,Keysigningって何?

Keysigningとは,お互いのGPGの鍵に対して署名をすること. 署名は,相手の鍵が本当に相手のものであることを確認するという目的で行なわれる. 鍵を署名する条件として相手のメールアドレスが正当であることと, フィンガープリントが相手の主張するものと一致している事, そして自分の信頼できる公的期間の発行する写真つきの証明書によって その人がそういう名前で存在しているということが確認できている事がある. つまり,gpg --fingerprintコマンドで出力される各主要な項目について 相手から直接伝えてもらうという行為を経て署名に至る.

$ gpg --fingerprint cd3756f4
pub  1024D/CD3756F4 2000-04-29 Junichi Uekawa <dancer@debian.org>
                指紋 = 17D6 120E 4455 1832 9423  7447 3059 BF92 CD37 56F4
uid                            Junichi Uekawa <dancer@netfort.gr.jp>
sub  1024g/32E6C032 2000-04-29
	

実際のKeysigningをする会場ではパスポートを持った人々がわらわらと集まり,お互いに fingerprintの書いた紙を交換しあい,呪文のように「これは私で,これが私のフィンガープリントです」という宣誓文 をとなえる,一見異様な空間になる. ただ,この証明を経ることによって,メールを出している人が自分である,ということが証明しやすくなる. 特にDebianの場合には,New MaintainerとなってDebian Developerへの道をあゆむ場合には必須の手順.

最近はあまり東京でKeysigning Partyをしていないみたいなので, できるだけ開催して,日本の中のtrust pathを改善したい.

2005年1月13日 (木曜日)

06:53:10 # Debian 「incomingにあるからとってきて試してみて」. そんなこと言ってもDebianに詳しい人じゃないと何をいっているのかさっぱりわからない. incomingって何?

incomingとは,Debian Archiveに対してアップロードされたパッケージが, Debian Archiveにとりいられる前の状態にあるパッケージが公開されているところ. incoming.debian.orgとして一般に公開されている. ここにあるパッケージが一日一回のバッチ処理の際にDebian Archiveにとりいれられ, 次の日のunstableのパッケージとしてひろくユーザが利用できるようになる. incomingから直接パッケージをとって来てインストールすることも可能で, そうすると一日待つのではなく,15分待てば処理できるという利点がある. da-katieのcheckedディレクトリの中身がincomingとして見えているらしい.

incomingの存在意義はバグ報告者が問題修正のレポートを受けたらすぐに その修正が実施できていることを確認できる,などが考えられる. まだしばらくはDebian Archiveにパッケージをとりこむバッチ処理の頻度が大幅に増えるという ような変更が発生することは無いと思われるため,incomingは今後も使われるだろう.

2005年1月12日 (水曜日)

07:04:29 # Debian 「今日のBritneyでtestingに入るよ」. なんて言われてもDebianを知らない人には通じない. Britneyって誰だ?

Britney は Debian 'testing' を管理するためのスクリプトで, 一日に一回実行される. unstableに入っているが,testingに入っていないパッケージについて, 各パッケージにファイルされている「深刻な」バグの数, 各アーキテクチャのビルド状況などを鑑みて,指定した日数(urgency=lowであれば10日)経過しており, バグの状況が安定しているようであり,依存するパッケージがすでにtestingに存在すれば, 自動的にtestingにリリースしてくれる, 自動リリース管理ツール. testingはBritneyというバッチ処理でリリース管理がなされているというわけ. Britneyの出力は testingの頁 からリンクされている update excusesにあり, どのような問題があり,あるパッケージがtestingに入らないという判断がなされたのか,という ことが書いてある. この状況を把握しやすいようにいろいろな人がスクリプトを書いており,そのウェブフロントエンド へのリンクが,developer.phpには集約されている. 今後はさらにメンテナの視点から,この問題があるので,ここを直す必要がある,という ところまでおとしこんで表示してくれるようなインタフェースへと発展できるだろう. Britneyについては,パッケージ数,アーキテクチャ数が膨大になってきているため,処理時間がどんどん長くなり 今後は何らかの対策をうたないと一日でバッチが終らなくなる事が予想される.

しかし,ユーザが出したバグ報告を機械的に処理して実装しているtesting distributionがここまで運用できているというのは凄いのではないかな.

2005年1月11日 (火曜日)

08:02:21 # Debian 「Keyringにまだ入っていないからアップロードできないんですよ」. そんな言い訳,Debianを知らない人には通用しない. Keyringってなんだ?

DebianでKeyringというと,Debian Keyringのこと. Debian Keyringとは,Debian Developerの公開鍵だけを保持している PGP/GPGキーのデータベース. このKeyringに鍵が入っていると,Debian Developerとして認定されていることになり, パッケージをその鍵で署名している場合のみdinstallが Debian archiveにパッケージをインストールしてくれる. このKeyringに追加されるには,New Maintainerとしての処理を経て DAMが承認,作業する必要がある. Keyring 自体も,Debian Packageとなっていて, debian-keyringという名前で配布されている. 中身をみると,すでに8MBくらいのファイルサイズである. この後は開発者が増大するにつれて,さらに大きなリストになるだろう.

$ ls -l /usr/share/keyrings/
合計 9192
-rw-r--r--  1 root root 8563189 2004-07-06 05:39 debian-keyring.gpg
-rw-r--r--  1 root root  821211 2004-07-06 05:39 debian-keyring.pgp
-rw-r--r--  1 root root    1890 2004-07-06 05:39 debian-role-keys.gpg
	

Debian勉強会でお会いした方のキーを署名するのを忘れていたのを思い出したので,sign. Debian Developerは他の開発者と出会ったら,署名の交換をする. それは,メールなどでしかコミュニケーションがとれない環境において,直接あったことにより その人がその当人である,ということを証明するための手段. KeysigningはDebianの重要なインフラだ.

ちょっと気になったので,MSDを調べる. どれくらいGPGの信頼パスがつながっているのか,というランクが出ている. 今上川はDebian Project内部では25位.世界ランク167位,らしい. 気が付いたらHironobu SUZUKIさんを越えていた. 信頼パスがあるということは多分よいことなのだろう. しかし,MSD=3ということは,GPGを使っている人なら誰であっても知り合いの知り合いの知り合い,ということか?本当か?

2005年1月10日 (月曜日)

09:46:23 # Debian 「0回目東京エリアDebian 勉強会報告」.ということで,報告します. 1回目としては会場の確認が主目的でしたが,いざやってみると資料の作成とか,結構手間がかかりますね. 作成した資料をコンビニで300枚くらい(11x23くらい)コピーするのが面倒でした.次からはコピー専門店あたりで お任せにしたいところ.詳しいかたいらっしゃいましたらぜひ教えてください.

当日の勉強会の参加者は21人でした. 受付は松山さんにお願いしました.ちょっと分かりにくかったかも. 個人で会場は借りていたので, 建物の入ったところにあった案内板には「上川」とだけ書いてあったので,主催者の名前を 知らないとわからないですね. 会議室の前にあったホワイトボードにはDebian勉強会と(松山さんが)書いておきました.

今回0回目だから人が多かったのか,それとも次からは人が溢れ出てしまうのか, 今回の会場は21人でほぼ満員でした.定員は27人のはずです. 宴会場はつなげればおそらく30人くらいまでいけそうなので, 大丈夫かな?

なお,参加者の方で,感想文などありましたら,リンクさせていただきたいので, メールにて御一報ください.

今回やってみたんですが,プロジェクターとかって実際必要ないかな? 参加者の感想を聞いてみたい所です.

2005年1月9日 (日曜日)

12:45:08 # Debian 「Build失敗したよ」.なんて言ってもDebianを知らない人にはその悔しさはわからないかもしれない.

Buildするという行為はDebianにおいて,ソースパッケージからバイナリパッケージを作成する手続きをさす. Debian用のソースパッケージには,Debianのビルド用のファイルがdebian/ディレクトリ以下に追加されており, debian/rulesというmakefileにしたがってアプリケーションのコンパイル/リンクやドキュメントファイルの 処理生成などが行なわれる. debian/rules build; fakeroot debian/rules binary等と指定すればビルドできるようになっているはずだが, 入力するのが面倒なので,dpkg-buildpackagedebuildコマンドを利用する. debuildコマンドはdpkg-buildpackageのラッパーでdevscriptsに入っている. よく観察してみるとDebianパッケージを年中作っている人達はキーボードのb,d,e,i,l,uの文字が薄くなっているはずだ,と 思ったら,自分のキーボードで一番薄いのは,x,c,n,m,k,l だった.

debuildには,emacsのフロントエンドもあり,devscripts-elに入っている. それをインストールするとM-x debuildでdebuildが動作する. エラーが発生したときなど,該当する行に飛ぶためのemacsの機構などが利用できて便利. なんて便利なんだ,と思ったら二年前に自分で書いたプログラムだったのをすっかり忘れていた

. 今後はさらにいろいろと発展させて,emacsでキー入力されるたびにバックグラウンドでdebuildするような リアルタイムインクリメンタルdebuildシステムだったり, debuildするたびにユニットテストをしてくれるようなシステムがほしい. debuildしてテストせずにdputすると,誰もテストせずにパッケージをリリースしたことになる. そんな状況は好ましくない. できるだけ労力をかけず,テストができる環境が今後望まれる.

12:49:43 # Life audacityを使って音源を編集してみる.1GBの音源なので,sweepとかではロードできない. しかし,録音音源のゲインがそもそも小さすぎたので,ノイズが大きすぎて何も聞き取れない...

13:09:46 # Life 昨日はDebian 勉強会参加ありがとうございました. 結局満員になりましたね.当初4時間は長いかな,と思っていましたが,終ってみると,私は短いと感じました. 終了時間が遅かったので,10名ほどで朝まで宴会でした.

東京エリアというよりも,関東エリアの方々にお集まり頂きました.恐縮.東京から来ている方は実は半分くらいしかいませんでした...

今朝の打合せと今回の結果の内容を反映して次回の案内を修正しました. よろしくお願いします.

19:17:13 # Life 中野さんの日記をKatteni Planet Debian頁に追加したかったので, HNSの出力を解析するようなpythonコードを書く. 予想していたよりも簡単に何かが書けた.

しかし,追加したあとに実はrssありました,と言われてしまった...

2005年1月8日 (土曜日)

10:26:43 # Debian 「直してduploadしといた」.「んなこと言われても今すぐ修正がほしいんだけど」. そんな状況,Debianを知らない人には理解できない.

Debianのパッケージを開発者の環境からDebian の中央FTPサーバ(ftp-master) にアップロードすることを duploadという.これはduploadというプログラムがあり,そのプログラムを利用すると アップロード作業が簡易に実施できるようになっていたからという経緯がある. duploadコマンドはすでにアップロードした形跡がないか,などのチェックをしてから, ftp-masterに送信し,uncheckedというディレクトリに移動します. そのディレクトリをkatie(dinstall)が15分に一回チェックして, インストールしてよいものだという判定をしたら,installというディレクトリに移動する. そのディレクトリからDebianとしてapt-getでインストールできるようなアーカイブに 移動するのは,一日に一回のバッチ処理の時. また,実際問題として,ftp-masterが更新されてから各ミラーに反映が開始するので, duploadしてからユーザに到着するまでには一日以上かかることがあり得る. 今はduploadプログラムの代替として,dputプログラムを使う人が増えてきたと思われるため, 今後はdputした,というセリフに変わって行くのだろう. 今後,開発者が修正を出してからユーザに到達するまでの時間は短縮されるのだろうか.

duploadは署名のチェックをしないそうです.dputはしてくれるのだそうな. 最近dupload使っていないので,失敗,失敗.

さらに,武藤さんによると dupload/dputしてからはuncheckedには直接いかず,一時的なディレクトリにおかれ, debianqueuedが最低限のチェックをしてから,uncheckedに移動する,とのことでした. ところで,それって,FTP upload queueの話しでは? 今は直接sshではログインできないけど,多分昔は直接uncheckedに置けたような...

10:46:41 # Life RSSが欲しいという要望がどっかであったので(ところで僕の名前間違っているんだけど.少なくとも,ウエクサではない),katteni debian planetの頁に生成したRSSへのリンクをはっておいた. ただ,なんというか,出力している内容がなんとなく変なので,問題があるかも. 気が向いたら直します.

20:57:01 # Life 0回目 Debian 勉強会,バックアップリストアの話をしたところ, ネットワーク監視についての話をその後にした.

2005年1月7日 (金曜日)

07:45:11 # Debian 「Build-depが足りないからbuildできないじゃないか」. そんなつっこみをいれられてもDebianを知らない人にはなんの意味かわからない.

Debianのソースパッケージの制御ファイルには「Build-Depends」というフィールドがある. そのフィールドの事をBuild-Depと省略して表現する. ソースパッケージをコンパイルする際にDebianのBuild-Essential(ビルドに最低限必要な環境)に入っていないパッケージを必要とする場合には, 必要になるパッケージの一覧をBuild-Dependsに記述する. そうすることで,dpkg-buildpackageなどのツールは依存関係を確認してから ビルド処理を行なう. また,sbuildやpbuilderなどのビルド専門ツールは, 実際にbuild-dependsのフィールドを解析して 必要なパッケージをインストールしてからパッケージをビルドする. ビルドした結果としてバイナリパッケージができる. しかしながら,Build-Depの記述が不正確だと,何かがたりなくて ビルド結果がおかしかったり途中でエラーが発生したりする. そのような状況をBuild-Depが足りないからbuildできない状態と呼ぶらしい.

現状Build-Depに必要な項目についてはメンテナが手作業で探求している. dpkg-genbuilddepsツールなどを利用して自動でリストを生成することも可能だが, 実際にビルド処理を実行して, ビルド処理の中で利用しようとしたファイルの一覧を作成するため,本当に必要なのかどうかについては結局 手動で確認する必要がある.また,各実行コマンドの依存する 共有ライブラリや,スクリプトの利用するスクリプト言語環境も出力してしまうみたいなので, そういうものも除外する必要がある. 今後も手動での操作が必要になってくる分野だろうと思われる. しかし,dpkg-genbuilddepsが意外とまともに動くのにびっくり.

dpkg-genbuilddepsをdshに対して走らせてみた出力例:

The following files did not appear to belong to any package:
/usr/lib/perl/5.8
/usr/lib/locale/locale-archive
/usr/bin/cc
/usr/share/perl/5.8
/etc/alternatives/cc
/etc/ld.so.conf
Packages needed:
  file
  gettext
  libdshconfig1
  locales
  libc6-i686
  perl-base
  dsh
  debhelper
  fakeroot
  libmagic1
  libdshconfig1-dev
	

07:56:55 # Life Debian勉強会,申込ありがとうございます. 参加される方には,土曜日にお会いしましょう. どんな人が来られるのか,楽しみです.

2005年1月6日 (木曜日)

05:36:18 # Debian 「dinstallを一日一回だけじゃなくて一時間に一回うごかそうよ」. なんて話しをされてもほとんどの人はわからない. Debianでいうdinstallとはなんだろう.

dinstallはDebian archiveに新規パッケージを導入するために実行されるプログラム, もしくは処理のこと. dinstall というプログラムがあり,それは日本時間の午前4時くらいに毎日実行され, その結果として,Debian Developerがそれまでにアップロードしたパッケージがarchiveに入り, 各FTPサーバに配布される. Debian Developerは,アップロードしたパッケージがインストール可能な状態であるか,という ことをdinstall -n コマンドで確認できたりした. しかし,実は現在再実装され,pythonで書きなおされたdinstall(katie)は15分に一回動作している. そのため,Debian Developerはdinstall -nコマンドを実行せずとも 15分に一回の処理の際に生成される「Accepted」メールを受信して, アップロードしたパッケージがDebian Archiveに追加されるのかということを確認できる. これで,ftpサーバにシェルログインしなくても処理を完了することが可能になる. ただ,現状15分に一回dinstallが動いているが,実際にアーカイブへの反映作業をしているのは, 一日に一回だけで,おそらく日本時間の午前4時くらい. これは,ミラーサーバのシステムに変更が加わっていないことと,他のインフラシステムとの連係もあり, Debian Developerの生活パターンの問題もあり,まだ変更を加えるに至っていない. 今後はもしかすると,一日に二回程度の頻度で実行するようにはなるかもしれない. 一時間に一回はさすがに頻繁過ぎるのではないだろうか. 現状は「今日のunstableは不安定だね」という話し方だったのが, 「15時のunstableは不安定だったね,16時版は良かったよ」という話しになるのだろうか.

おそらく一番のネックはBritneyという遅いバッチジョブがあるらしいので. その実行時間が制約になるのではないだろうか. 今でも遅いのか,実際に何時間くらいかかっているのかは不明.

2005年1月5日 (水曜日)

09:15:36 # Debian 「ftp-masterがREJECTしてきたよ」.そんな嘆きもDebian関係者以外では理解できない. ftp-masterって何者だろう.

ftp-masterは,Debian archiveを管理する人. 一番Debian Developerからみて関連が多いのは, いままでDebianに無かった新しいパッケージが導入される際にそのパッケージを審査し, 配布に適しているかということを調査するという仕事. 配布に関してそのライセンスが適しているのか, DFSGに合致しているのか,という点などを確認する. また,最低限パッケージがまともな形で提供されているのか,というチェックもするみたい. DFSGに合致しているのか,という点については,ITPした際にも確認が入るが, ftp-masterは最終的な判断を下す. 問題となるのは,GPLで配布されているけれどもいろいろなコードがまじりすぎて 本当にGPLなのかわからないようなソースコード.たまにある. おそらくmplayerについては,この点で問題になったのだろうと思われる. またもう一つ問題となるのは,特許や,進行中の訴訟の問題だったりして, DVD Videoのデコーダーや,mp3のエンコーダについてはこれにあたる. ftp-masterは,Debianのミラーサイトの管理者を保護するという観点から 比較的保守的な判断をすることが多く,DVD Videoの暗号解析プログラムや mp3のエンコーダについてはDebianとしては現状配布していない. 今後も微妙な問題についてはいろいろと判断しつづけるのだろう. ただ,ftp-masterはある判断について,なぜなのか, という点についてはなかなか明示してくれない. その点をなんとかしたいものだなぁ...

ftp-masterは昔はJames Troupがほぼ一人でやっていたが, 最近は複数人いるらしい.

2005年1月4日 (火曜日)

09:48:04 # Debian 「DAMが増えたらしいぜ」.そんなニュースが新年早々流れている. そんなことを言われてもDebian関係者以外の人にはなんのことかわからない.

DAMは いままで実質一人しか居なかった. そのため,NMキューの処理をする際に最後のボトルネックになっていた. しかし,1月1日午前1時GMTに 新しいDAMがDPLから委任されたらしい. いままではJames Troup がほぼ一人で担っていた立場だが,Joerg Jaspertが新しく参加することで, 状況が変わることが期待される. すでに新しいDebian Maintainerを登録するという処理('has gone through some applications')も実施したとのことなので,めでたいこと.

10:06:13 # Life 新年あけましておめでとうございます. 今年もよろしくお願いします. 個人的には,自分のDebian関連活動の停滞解消のため,月に一回程度のDebian Meetingを実施することによって 新しい展開をしたいものだ,と思っております.

11:39:31 # web maintenance ウェブのみた目を少し変更. 毎日のエントリーというのを実はこっそりと毎日生成していたのだが, それを若干いじってみた. これでなんとかなるか?


Junichi Uekawa

$Id: 200501.html.ja,v 1.41 2005/02/02 17:23:37 dancer Exp $