2011年06月11日

Linux kernel 2.6.38.bpo使用版 Squeeze amd64 d-iイメージ

Debianのビルド・テスト用のマシン環境を高速なものにリプレースしたので、久しぶりにバックポートインストーラを作りました。Debian GNU/Linux 6.0 Squeeze向けの最初のリリースです。

ダウンロードはいつものようにこちらから。

  • Debian 6.0.1ベースです。
  • カーネルには現在backportsとして提供されている最新のLinuxカーネル2.6.38.bpo.2を採用しています。

Debian-Installer自体にファームウェアファイルを読み込む機構が備わっているので、このリリースではnon-freeファームウェアについてはISOイメージ内に含んでいません。見つからないファームウェアの読み込みを参照して、tar.gzまたはzip形式のファームウェアファイルアーカイブをUSBメモリなどに展開して用意してください。また、WiFiのWPAサポートはこのリリースにはまだ実装していません。

では、Debianをお楽しみください!

2011年01月16日

「第72回東京エリアDebian勉強会、2011年1月勉強会」に行ってきた

忙しい中ではあったんだけど、東京エリアDebian勉強会に久々に参加した(本当は前回も参加したかったのだが、動きが取れなかった…)。(別記事で詳細説明する予定の)CAcert.orgのAssurerとしての任務遂行という目的もある。

18:00に少し遅れる程度で到着の予定だったものの、鉄道の人身事故の影響を受けたのとその際の判断が悪かったのもあって、会場到着ははるかに遅れての19:00過ぎ。事前課題紹介のセッションは完全に終わっていて、上川さん(@dancerj)による「Debian勉強会アンケートシステム」からの参加となった。

Debian勉強会アンケートシステムは、その名のとおりこの東京エリアDebian勉強会の参加登録システムとセットとして、実施後に自動送付されるアンケート収集に使われるようになっている(どちらもGoogle App Engine上)。皆ブログなどは書かなくなり、感想や記録はtwitterで済ませるようになっているけど、セッションへのフィードバックをどうするかというのは問題だよね、ということがこのシステム導入の理由とのことだ。

勉強会実施後に、各参加登録者にはアンケートページの固有URLが送られる。UIは(登録と同様に)簡素すぎるきらいはあるが、「N/A(参加しなかったなど)」「すごくよくない」「よくない」「どちらでもない」「よかった」「素晴しい、他人にも薦めたい」を各セッションにつき採点できる。微妙にNew speak風なのがおもしろい。「どちらでもない」があるとそこにまとまりやすいので、取ってしまったほうがよいのでは、という意見もあった。

このシステム自体はデータとしてはCSVを吐き出すのみで、統計計算は担わない。今のところは統計解析ソフトウェアのRで処理するようにしているようだ。「NAも入れちゃっているので適切ではないが…」という上川さんの発言に対しては、「RならNAと入れればそのまま欠損値として扱ってくれるよ」という参加者からの回答がある。Rは機能豊富で強力ではあるけれども、どうも記憶に留めにくいところがあるので、ぜひ『The R Tips』などを購入して手元に置いておきたい(EPUBも作ろうと思えば作れそうではあるなぁ…とりあえず自分用に作っておこうかな)。

続いては、話題のKinectを使った山田さん(@tyamadajp)によるハックデモ。これはとても面白かった。ライブラリとしてOpenNIとNITEを使い、ジェスチャをイベントと組み合わせてプレゼン画面のスクロールを行うというデモからの開始。最初の認識で苦戦したり、動きは見てもキーイベントと連携するジェスチャとは認識してくれなかったり、といったトラブルはあれど、Kinectの可能性はとてもよくわかる。手を振る、押す/引く、といった基本ジェスチャ(10種類)のみであれば、NITEの提供する範囲でごく簡単に記述(C言語)できるようだ。何より(山田さんがすごいということもあるが)これがごく短期間のハックで実装されているというのが素晴しい。どれだけの人間を認識できるかという実験では、4人まではとりあえずいけるようだ。Microsoft謹製の成果物では上半身だけでも認識できるなど、まだまだ隠れた差異はある(ドキュメントも不足しているらしい)が、映画『マイノリティリポート』のように両手の動きでぬるぬると動くUIがごく当たり前に実現する日も遠くないのではないかと思った。Youtubeなどを見るとすごく面白そうなことをやっている人たちがいるねぇ……。

時間の押している中、最後にやはり山田さんによるCAcert Assuranceのお話。手短にCAcertのポイント申請手続き方法の説明と、3月5日にCAcert.orgのトレーナを招聘しての公式トレーニングイベントをオープンソースカンファレンス(早稲田)の1セッションで行い、その夕にポイント取得のためのサイン(署名・本人確認)会を開催すると発表された。私はCAcertのExperienced Assurer(上級ポイント提供可能者)であり、このトレーニングイベントにも協力するつもりだ。後日正式な発表があると思うが、ある程度人が集まらないと——特にAssurer予備軍になる人が集まらないと成功とは言えないので、今後いろいろと広報していかなければいけないな。

閉会後に、宴会はご欠席というUbuntu Japanese Teamの村田さんと、GPGサイン交換およびCAcert.org署名受け取りを済ませる。宴会はどこだっけ、とりあえず「割烹」と呼んでよさそうな高級そうなところだった。座席が禁煙で食事の味をじっくり楽しめるのもいい。お魚中心ながら途中で重いのがほしくなって鳥唐とか揚げ出し豆腐とか頼んでました、ごめんなさい。CAcert.orgサイン会は宴席で、ということで乾杯前にサイン、一口飲んではサイン、ちょっと食べてはサイン、と宴席サイン会はAssurerには負荷が高すぎる、という結論に達した…。23時前に解散。CAcertに関する作業について山田さんといろいろ打ち合わせ。帰路は列車トラブルに巻き込まれることもなく、無事帰宅。翌日に、早速届いていたアンケートへの回答、GPG署名やCAcert.orgのポイント付与を完了。

2010年05月22日

Debian SqueezeでのGhostscriptフォント設定方針

リリース準備中のDebian GNU/Linux次期安定版「Squeeze」での小目標として、「defomaの廃止」というものがあります。その作業の一貫として、defomaを使用していたGhostscriptのフォント設定の新機構を実装・アップロードしました。 Lennyからのアップグレードでdefomaにいろいろと調整を加えていたユーザや、CJK(Chinese Traditional/Chinese Simplified/Japanese/Korean)フォントをGhostscriptに提供したいという開発者はこの変更に注意が必要です。

[経緯]

「defoma」(Debian Font Manager)は、2000年に日本人Debian Developerのtakeさんが開発したDebian向けのフォント管理機構です。TrueTypeやType1/CIDなどのベクタフォントパッケージにヒントファイルを持たせることで、Xフォント、TeXプレビューア、fontconfig、Ghostscriptといった各種のソフトウェアでのフォント設定およびデフォルト選出を統括しようという野心的な試みです。アプリケーションごとのフォント管理がバラバラで、それぞれの設定もわかりにくかった時代に、defomaは有効なソリューションでした。特にtakeさんの保守していたGhostscriptパッケージにとっては欠かせないコンポーネントです。

しかし、takeさんが就職後にDebian活動に時間を割けなくなり、後を引き継いだAngus Leesも2006年半ばを最後に保守が見られなくなると、Perlで記述されたdefomaソースコードのわかりにくさとバグの多さのためにDebianにとって重荷となっていきました。アプリケーションでのフォント管理も、fontconfigを使用するものが多くなり、レガシーなものはGhostscriptほかごくわずかとなりました。また少なくとも日本語についてはalternativesシステムでデフォルトの明朝/ゴシック書体を示すttf-japanese-mincho.ttf/ttf-japanese-gothic.ttfが提供されるようになったことで、defomaを使う意義はほとんどなくなっていました。

このため、Squeezeではdefomaを削除しようという運動がpkg-fonts-develチームを中心に起こり、各フォントパッケージからは次々とdefomaのヒントファイルが削除されます。しかし、GhostscriptについてはCJK方面以外にはほぼ影響がないため、誰にも顧みられていない状況でした。このままリリースされて後から品質の問題になるのを防ぐため、筆者は今年の1月に、defomaに代わってGhostscript向けのみのシンプルなヒントファイルを関連するCJKフォントパッケージのみが提供する仕組みをプロポーサルとして提出しました。

このプロポーサルはpkg-fonts-develではあまり反応を得られなかったのですが、特に大きな反対はなく、またその後Changwoo RyuやAndrew LeeなどのCJK系のDebian Developerに質問して得られた回答を受けて、5/18〜5/19にかけてパッチ提案およびNMUに踏み切りました。現在、Sidにはすべての変更が反映され、5/30にはSqueezeに反映される見込みです。

[仕組み]

Ghostscript向けの新しいフォント管理は、/etc/ghostscript/cidfmap.d/と/etc/ghostscript/fontmap.d/に置かれたヒントファイルと、ghostscriptパッケージのupdate-gsfontmapコマンドからなります。update-gsfontmapコマンドは、ヒントファイルを単にまとめてそれぞれcidfmapとFontmapという名前で/var/lib/ghostscript/fontsディレクトリに置くだけです。前者はCIDマップ(実際にはTrueTypeを含む。日本語等のCJKフォントはこちらを使います)、後者は欧文Type1マップです。

日本語用のデフォルト設定はgs-cjk-resourceパッケージが提供する/etc/ghostscript/cidfmap.d/90gs-cjk-resource-japan1.confで、PostscriptおよびAdobe Acrobatの主要フォントを定義しています。

/Japanese-Mincho-Regular << /FileType /TrueType /Path (/usr/share/fonts/truetype/ttf-japanese-mincho.ttf) /SubfontID 0 /CSI [(Japan1) 4] >> ;
/Japanese-Gothic-Regular << /FileType /TrueType /Path (/usr/share/fonts/truetype/ttf-japanese-gothic.ttf) /SubfontID 0 /CSI [(Japan1) 4] >> ;
/Ryumin-Light /Japanese-Mincho-Regular ;
/Adobe-Japan1 /Japanese-Mincho-Regular ;
/HeiseiMin-W3 /Japanese-Mincho-Regular ;
/GothicBBB-Medium /Japanese-Gothic-Regular ;
/Adobe-Japan1-Bold /Japanese-Gothic-Regular ;
/HeiseiKakuGo-W5 /Japanese-Gothic-Regular ;

ローカルの設定を定義したいときには、90よりも若い番号(10local.confなど)のファイルを同ディレクトリに作成してください(Postscriptのルール上、始め(小さい番号)に書いたものが後(大きい番号)からのものに優先されます)。例を次に示します。

/Jun101-Light << /FileType /TrueType /Path (/usr/share/fonts/opentype/A-OTF-Jun101Pro-Light.otf) /SubfontID 0 /CSI [(Japan1) 0] >> ;

フォントパッケージ提供者は、独自のヒントファイルを提供し、Ghostscriptで使用できるように登録できます。今のところ番号のポリシーは設定していませんが、50番台あたりを使うのが妥当かと思います。パッケージでは、ヒントファイルを/etc/ghostscript/cidfmap.d/または/etc/ghostscript/fontmap.d/にインストールするようにし、postinstとpostrmでそれぞれupdate-gsfontmapを起動するようにします。

postinst
#!/bin/sh
 ...
case "$1" in
  configure)
    if [ -x /usr/sbin/update-gsfontmap ]; then
      update-gsfontmap
    fi
  ...

postrm
#!/bin/sh
 ...
case "$1" in
  purge|remove)
    if [ -x /usr/sbin/update-gsfontmap ]; then
      update-gsfontmap
    fi
  ...

[ユーザは?]

特にこれまでGhostscriptに調整を加えた覚えのないユーザは、新しいghostscript、gsfonts、gs-cjk-resource、cmap-adobe-japan1のパッケージをインストールすることで、自動でttf-japanese-mincho.ttf、ttf-japanese-gothic.ttfをデフォルトの明朝/ゴシックフォントとして利用するようになります。Squeeze新規インストールの場合にはIPA明朝/ゴシックになるはずです。

ttf-japanese-mincho.ttfおよびttf-japanese-gothic.ttfのリンク先フォントを変更するには、update-alternativesコマンドをroot権限で使用します。

# update-alternatives --display ttf-japanese-mincho.ttf ←現在の状態を調べる
ttf-japanese-mincho.ttf - auto mode
  link currently points to /usr/share/fonts/opentype/ipafont/ipam.ttf
/usr/share/fonts/opentype/ipafont/ipam.ttf - 優先度 100
/usr/share/fonts/truetype/sazanami/sazanami-mincho.ttf - 優先度 50
Current 'best' version is '/usr/share/fonts/opentype/ipafont/ipam.ttf'.

# update-alternatives --config ttf-japanese-mincho.ttf ←設定を変更する
There are 2 choices for the alternative ttf-japanese-mincho.ttf (providing /usr/share/fonts/truetype/ttf-japanese-mincho.ttf).

  Selection    Path                                                    Priority   Status
------------------------------------------------------------
* 0            /usr/share/fonts/opentype/ipafont/ipam.ttf               100       auto mode
  1            /usr/share/fonts/opentype/ipafont/ipam.ttf               100       manual mode
  2            /usr/share/fonts/truetype/sazanami/sazanami-mincho.ttf   50        manual mode

Press enter to keep the current choice[*], or type selection number: ←Selection列の数字を入れる

以上、Squeeze以降でのGhostscriptのフォント設定について説明しました。ghostscriptについてはメンテナではないものの、バグの状況はウォッチしていますので、何か問題を発見したらDebianバグ追跡システムに報告してください。

2010年02月06日

Debian JP LDAPとGPG署名メールによる自動処理

Debian JP Project で管轄しているサーバのユーザ管理は、LDAPというディレクトリサービスが担っています。 これまでこの保守は鵜飼さんが担当されていて、管理するマシンも鵜飼さんの自宅サーバだったために協業もしにくい状況だったのですが、もともと忙しいところにGoogleに入られてからはますます多忙を極めて手が回らなくなってきていたため、チームによる引き継ぎが必要となっていました。

LDAPの場合はFTPと違ってサービス内容はそれほどおおがかりなものが必要ないことから、仮想化環境に引越そうという話はずっとあったものの、仮想化の親環境の準備で伸び伸びになっていました。しかし、前回のBug Squash Party@Debian勉強会で必要な設定作業を完了して目途が立ったため、移行の手続きをいろいろと進め、一部の作業については自動化できるようにしました。 仮想化環境はG15アソシエーションによるスポンサードです。

LDAPのサーバにはOpenLDAPを使用しています。古いバージョンからの移行の苦労についてはBug Squash Partyの記事に書いたとおりですが、ひとまずこれは移行できました。

LDAPの運用では、LDAPサーバのアカウント情報に直接(あるいはせいぜいキャッシュ程度)アクセスして認証等を行う設計が多いと思われますが、Debian JPの場合はLDAPサーバが単一障害点にならないよう、定期的なアカウント情報伝播を行っています。

具体的にはLDAPサーバdb.debian.or.jp側でアカウント系のファイル(passwd/shadow/group/alias/sshpubkeys)を生成し、これを*.debian.or.jpの各サーバがrsync+sshで取得して使用します。passwd/shadow/groupについてはlibnss-dbを使います。/var/lib/misc内で平文ファイルからBerkeley DBに変換して、nsswitch.confで参照します(「passwd: compat db」のようにする)。aliasについてはnewaliasesを実行するだけですね。sshについてはDebian.orgでは単純に上書きしちゃっているのですが、Debian JPでは鵜飼さんのスクリプトでもうちょっと高度にいじっています。Debian JPの会員はマシンアクセス権限のある正会員と、メール転送のみの賛助会員に分かれており、これはLDAPのフィルタリングで対処します。このあたりはshスクリプト+Makefileで自動化されています。libnss-dbは便利なので、覚えておくとよいでしょう。似た仕組みは私はオフィスネットワークでも流用しています。

LDAP情報の変更については、人手を介するのをできるだけ排除し、ユーザができることはユーザに任せるポリシーを取ることにしました。とはいえ、それなりのユーザ認証は必要です。Debian.org/Debian JPで一番信用のある本人証明といえばGnuPGです。Debian.orgではこれを使って各種の設定をメールベースで行えるようになっているので、Debian JPでも真似てみることにしました。Debian.orgでの処理システムは私もアクセスできない領域にあるので、次に示していくような、私の独自設計です。まぁちゃんと動いてはいるみたいなのでよしとしましょう :-)。

メールベースの前に、とりあえずLDAPサーバにログインしてパスワードを変えるところから始めることにしました。ログインできる時点で認証は済んでいる(というか不正ログインされるようだったらもう「終わってる」のでそこで騒いだところであまり意味がない)ので、単純にldappasswdを動かすだけです。ただ生のldappasswdはDN情報や各種オプションをずらずら書かなければならず面倒すぎる、かといってPAMを使うのもあまり良い思い出がない(サーバが何らかの事情で止まるといろいろ悲しいことになる)、ということでラッパーで包むことにしました。

!/bin/sh
ME=$(whoami)
ldappasswd -x -W -D "uid=${ME},ドメイン" "uid=${ME},ドメイン" -S

単純ですね。Debian JPのアカウントDNはuid名と同じなのでこんな感じで出来上がりです。 これをdebianjp-ldappasswdというコマンドで/usr/local/binに突っ込んでおきました。 ldappasswdの問題としてはpasswdのように旧→新ではなく新→旧とパスワードを尋ねるのがちょっとややこしいのですが、これは目をつむることにします。

さて、メールベースの実装です。Rubyでフィルタスクリプトを作りました。ライブラリとしてはlibldap-rubyと標準net/smtp程度です。

一番簡単なパスワード変更(リセット)から考えます。簡単というのは、リクエストコンテンツを解析しなくてもとにかくランダムパスワードを作って割り当て、それを返せばいいからです。 ランダムパスワードはldappasswdコマンドでもできますが、慣れているmakepasswdコマンド(パッケージ)を使うことにしました。makepasswdはランダムなパスワードとそれをハッシュ化した値の両方を出力してくれるので、こういった処理を作るのに便利です。 管理者DNでバインド済みのldap.modifyを使って指定のuidのuserPasswordエントリをハッシュ値で変更し、パスワードをuid@debian.o.jに返すだけです(リクエストメールのFromではありません)。

さて、「指定のuid」を判断し、確かに変更してよいことを決めるために本人証明が必要になります。 ユーザ側は「echo "Please change password" | gpg --clearsign -a | mail dbadmin+password|email|ssh@db.debian.or.jp」の書式でメールを送ります。

もともと鵜飼さんが作っていた署名認証スクリプトもあった(クリア署名だけでなくMIME署名にも対応)のですが、スクリプトが多段になってわかりにくくなりそうだったので、類似のものを実装しました。

  1. 送られたファイルはまずgpg --verifyを行い、鍵リングにあるGPG鍵での正しいGPG署名かを検証します。ただ、RubyのネイティブGPGライブラリはいまいちわかりにくかったので、popen呼び出しというちょっとしょぼいコードになっています。
  2. verifyに成功したら、そのID部分を取り出し、鍵リングに対してそのフィンガープリントを要求します(gpg --fingerprint ID)。
  3. LDAPサーバのユーザ情報にはGPG IDではなく、フィンガープリントのほうが格納されています。ldap.searchを使って、調べたフィンガープリントを探します。
  4. マッチしたら、そのuid属性を取得します。

SSH公開鍵と転送設定はコンテンツを解析しなければならないので、パスワードよりは少し面倒です。とはいえ、単純なフォーマット(SSH公開鍵は各鍵を1行ずつ並べたもの、転送設定は転送先アドレスを記述したもの)なので、これについては特に説明するまでもないでしょう。中身を解析し、ldap.modifyで取り込みます。sshrsaauthkeyエントリは複数持てるのですが、ldap.modifyはどっちにしても(単一値でも)配列渡し限定なので特別な処理はあまりありません。ただ、解析の際にSSH2鍵のフォーマットになっているかどうかは確認するようにしています。転送設定も、validなメールアドレスかどうかの確認をしています。

なお、GPGの処理は重いので、実際にはメールが来るたびに即時処理をするということはせず、一旦スプールディレクトリに置きます。これはprocmailのMHフォルダ形式保存指定(「パス/.」)で済みます。スプール内のファイルを定期処理する際、無駄な処理にならないように、適切な宛先か、署名っぽいものが付いているかを調べてから、実際のGPG処理に移るようにしています。メール処理の振り分けも、Postfixのrecipient_delimiter機能(アカウント名+付値 でも届くようにする)と、procmailが活躍します。単純化した.procmailrcはこんな感じ。

SHELL=/bin/sh
#LOGFILE=/tmp/procmail.log ←デバッグ用

:0 :
* ^To: .*dbadmin\+(password|ssh|email)@db\.debian\.or\.jp
スプールパス/.

:0 :
/dev/null ←ひっかからなければ即ステ

スプールの定期処理はこんな感じ。

#!/bin/sh
find スプールパス -name "[0-9]*" -exec スクリプトファイル {} \;

ということで、最後に全体図を示してまとめとしましょう。procmailのようなMDAの応用方法を覚えておくと、メールベースの自動処理を構築するのに役立ちます。procmail自体は変態言語なので面倒なところもありますが、maildropやrdeliverなどもあるので、試してみるとよいでしょう。

Debian JP LDAPとGPG署名メールによる自動処理(図)

2010年01月24日

第60回東京エリアDebian勉強会 Debian Bug Squash Party

2010年最初となる東京エリアDebian勉強会で今回は東大にてDebian Bug Squash Partyが開催されていたため、途中までですが参加してきました。

朝9時に東京大学先端科学技術研究センター3号館に集合。前回TeXユーザの集いのときは迷って遅刻しかけたくらいだったのですが、今回はiPhoneに誘導されてずいぶん早く到着してしまい、しばらく散歩をして時間を潰すことに。先端研側は学生がほんとにいない…。会場担当の荒木さんと合流して入室し、無線の準備ができるまで久々にイーモバイルを使って接続。

9時前には幹事の岩松さんをはじめ、ぼちぼちと揃いました。岩松さんと荒木さんによる開会挨拶とガイダンスを経てBSP開始。各自持ち寄りで飲み物やおやつが用意されました。線としては会場回線を使ってのWifi 11a/g、岩松さんの持ってきたWimax(pocket Wifiのように接続する)の2種。VAIO Type Z+Debianの私の環境では、11aではAPに接続はできるもののAPにすらping通らずという不思議な状態に。11gのほうは使えたのでこちらを使っていました。東大のネットワークは速いです。

今回のBSPはDebian.orgのSqueezeに向けたバグ修正が主ターゲットなのですが、私のほうはDebian JPのリリースクリティカルとも言うべき問題の解決作業を行っていました。すなわち、鵜飼さん依存の脱却。特に問題なのがLDAPと鍵管理で、鵜飼さん以外にはrootを持ちづらい環境にこれらの情報が置いてあるため、g15.jpの仮想化内環境に移行することが前々から予定されていたのです。

手始めに、g15.jp自体がEtchだったため、まずはこのアップグレード作業(9:41-11:30)。荒木さんに以前にNOCで付けてもらっていたシリアルを使ったコンソールの挙動が若干謎だったのですが、とりあえずシリアルコンソールが必要になってしまうような緊急事態になることもなく、無事にアップグレードを完了しました。

次に、仮想環境のセットアップ。OpenVZの仮想マシンを1つ追加し、設定を行っていきます。テンプレートのダウンロード、マシン作成、メモリ・ネットワークやディスクパラメータの調整。 とりあえず基本環境自体は手慣れているのでさっくり(11:40-12:15)なのですが、問題はここから。

鵜飼さんの管理しているLDAPはだましだまし保持しているバージョン1.2で、現行のOpenLDAP 2.4.11とはだいぶ違っています。1.2の頃は適当なエントリをどんどん作って使えたのですが、2からはスキーマファイルをちゃんと定義してあげないと怒られます。無視するオプションもないことはないのですがそれも気持ち悪いので、ちゃんとスキーマを書くことにしました。 まずは現在使用している属性の洗い出しを行い、バージョン2にデフォルトで用意されている属性で同じものがあるか、ない場合は移行できる属性があるかの照合。続いて、新規に起こすスキーマの書式の調査。

この辺りで中間発表の時間(12:30くらい?)。今のところは皆細かなバグ取り作業や調査がメインで、Debian RCバグの作業はあまり進んでいない模様。荒木さんや八重樫さんらと共に駒場の学食で昼食を取りました。台湾ラーメンなかなか辛くて侮れず。学食は安くていいですね。駒場のは充実しています。近くでは院試も行われていました。部屋に戻ってから、八重樫さん、山田さん、杉浦さん、小池さんとGPGサイン交換を実施。

引き続き午後の作業です(14:00-)。昼過ぎからは参加者が続々と増えてきて(特にGentooは3名)、なかなか盛況となりました。

私のほうは、スキーマファイルの書式をだいたい理解したので、試行錯誤しつつ実際にローカルスキーマを作成。LDAPの検索はオブジェクトクラスの階層をちゃんと見ているということがわかったりしました。つまり、Aを継承したBというクラスを作った場合、objectclass=Aを探索するとBも出ます。Debian JP用のLDAPのオブジェクトクラスとしては正会員、Debian.org会員、賛助会員、システムユーザの4つのクラスを用意したかったのでまず正会員クラスを作って残り3つはそこから当初継承していたのですが、これだとまずい結果となるわけですね。4つの親となるベースクラスを作ってそこから全部継承するように変更することで、期待どおりの結果となりました。ここまでできたら、あとは旧環境からLDAP情報を引き出し(rootもないしLDIFで生成する方法も使えなさそうなので、ldapsearchのベタ結果を取得)、それを変換して新環境に突っ込みます。所詮1回きりの作業なので、変換についてはあまり完璧なのを作ることは求めず、Rubyで書いて途中でエラーが出たら元データなりコードなりを修正し、というように進めました。古いデータにはいくつか属性の欠損が見られました(ほとんどは賛助会員ですが)。

16:30過ぎにmasterqさんからlintian freeにしたuimができたという連絡を受け、スポンサーアップロードを実施。 LDAPのほうは、LDAPデータベースを使って各種の情報を展開するスクリプトが新環境でも動作するように調整作業を行いました。

そうこうしているうちに、私のほうはタイムアップ(17:00)。残りは帰宅してから。uimアップロード時に付けたサインをわざわざobsoleteなほうでやってしまい、蹴られてしまっていました。あうあう。再アップロードしてACCEPTED。LDAPは調整作業をだいたい完了し、あとは運用周りの実験を今後引き続き行うことにしました。可能なら今月中に完全移行させたいと思っています。

2010年01月21日

HPデスクトップに付いている15 in 1メディアスロットを認識させる(メモ)

オフィスで使っているHP Pavilion m9680jpにはCF/SD/MSなどを入れられるメディアスロットが付いている。5インチベイにあるが実際にはUSBデバイス。

Bus 008 Device 002: ID 0bda:0152 Realtek Semiconductor Corp. Mass Stroage Device

で、こいつはLinuxをそのまま起動して使っているとCFスロットしか認識されない。これまでネットワーク越しにばかりファイルをやり取りしていたので使う場面がなかったんだけど、たまたまデジカメのメモリスティックを開こうとして難儀した。当座は人からリーダを借りてしのいだのだが、機構は同じはずだし何か方法はありそうだよな、と調査。

結論としては、usb_storageにdelay_useオプションでたとえば値に10とか指定すればいいらしい。おぉ、見える、見えるぞ!

Host: scsi8 Channel: 00 Id: 00 Lun: 00
  Vendor: Generic- Model: Compact Flash    Rev: 1.00
  Type:   Direct-Access                    ANSI  SCSI revision: 00
Host: scsi8 Channel: 00 Id: 00 Lun: 01
  Vendor: Generic- Model: SM/xD-Picture    Rev: 1.00
  Type:   Direct-Access                    ANSI  SCSI revision: 00
Host: scsi8 Channel: 00 Id: 00 Lun: 02
  Vendor: Generic- Model: SD/MMC           Rev: 1.00
  Type:   Direct-Access                    ANSI  SCSI revision: 00
Host: scsi8 Channel: 00 Id: 00 Lun: 03
  Vendor: Generic- Model: MS/MS-Pro        Rev: 1.00
  Type:   Direct-Access                    ANSI  SCSI revision: 00

/etc/modprobe.d/usb_storageにも記述しておいた。

options usb_storage delay_use=10

2010年01月10日

Subject: Changes for Squeeze in Debian Installer

d-d-aにfjpから。

Lennyの後にd-iに加えられた重要な変更のまとめ。これらはすでにdaily/weeklyなビルドイメージで利用できる。なお、注意点としてdaily/weeklyのイメージを使えるアーキテクチャはi386/amd64/armel/sparcで、それ以外は現在、古いか利用できないか壊れている。

Recommendsなパッケージのインストール。Lenny以前のインストーラではRecommendsの依存関係のパッケージをインストールしていなかったが、Squeeze以降ではデフォルトでRecommends依存パッケージをインストールする。ブートパラメータかプリシードでオフにすることは可能。

言語/国/ロケールの選択の変更。localechooserコンポーネントに改良を加えた。 localechooserは言語、場所(国)、ロケールを尋ねるが、その聞き方をより良くした。 言語に英語、ドイツに居住(タイムゾーンの判定)、ロケールにen_GB.UTF-8、という選択ができる。 追加ロケールの生成はexpertモードのみ。

言語/国/ロケールの柔軟なプリシーディング。Lenny以前はロケールしかプリシードできなかったのを改善した。

ミラー選択の改良。oldstableおよびアーカイブリリースをサポートした。そのミラーで利用可能なリリースだけを表示するようにした。コードネームと利用可能なリリースセットを表示するようにした。デフォルトリリースが利用できないときに警告するようにした(これまでは別のリリースに黙ってフォールバックしていた)。選択されたミラーの完全性の確認を改良した。

「UTC」タイムゾーンの選択。expertモードのみで利用可能。

パーティショナー(partman)の変更。ext4ファイルシステムをサポート。RAID/LVM/cryptoの設定をより簡易にし、パーティションに事前に使用方法を定義する必要がなくなった。

その他の変更。インストールされたシステムでは(console-tools+console-dataの代わりに)console-setupを使うようになった。x86ではgrub-pc(grub2)がデフォルトになった。armelではMarvellのKirkwoodプラットフォームとIntel Storage System SS4000-Eをサポート。Lennyインストールの互換サポート(カーネルはLennyのを使うので2.6.26になる)。

2010年01月02日

Ghostscript 8.70でのCJK表示 (メモ)

Debianのghostscriptに関しては、cmap-adobe-*でごちゃごちゃやるよりも、CMapについてはpoppler-dataにまとめたほうがよいと思う。gs-cjk-resourceも同じようなファイルを持っているのだがどうもわかりにくい。で、cmap-*とgs-cjk-resourceとdefoma(こいつが一番問題だ)を本当に捨てられるのか、試行錯誤中。

Debianのghostscript 8.70~dfsg-2ではまだfontconfig(FAPI)を使うようになっていない模様。この場合は次のような挙動になっていた。

  • 基本Postscript欧文Type1フォント(Nimbusなど): /var/lib/defoma/gs.d/fonts/Fontmapの参照マップから検索される。マップのファイル名はパスが付いていないので同一ディレクトリから検索される。defomaを使っている場合は/usr/share/fonts/type1/gsfontsの各pfbフォントへのシンボリックリンクが貼られているので、ここから拾われる。実際のところFontmapがなくても、最終的には/usr/share/fonts/type1/gsfontsが探索されてちゃんと処理されるけれども、ちょっと気持ちが悪いので絶対パス参照にしたFontmapを用意して、gsパスに入れるのがいいだろう。結局varかetcに何らかのファイルを置く必要がありそうだ。
  • CJK TT/OTFフォント: 昔Turbo/Axeで開発したらしきCIDFnmapやその他の修正は「パッチ当たらないので捨て」とchangelogに書かれていた(まぁよくあるパターン)。CMapは/usr/share/ghostscript/8.70/Resource/CMapが使われる。現在は/var/lib/defoma/gs.d/CMapへのシンボリックリンクになっていて、この中にcmap-adobe-*の各ファイルへのリンクがベタで置かれている。サブディレクトリは使えない。poppler-dataのファイルを流用できるが、ベタでリンクし直す必要がある。マッピングのキモは検索パスにもなっている/var/lib/defoma/gs.d/fontsのcidfmap。フォント定義、エイリアスの両方が記述されている。書式はこちらが参考になった。OTFはTT機能部分だけを使うことになる。defomaは動的にこれを生成しているが、fontconfigを使って何か……ということになったら結局似たものを作ることになっちゃいそう。静的でいいなら/Ryumin-Light、/GothicBBB-Medium、/Adobe-Japan1、/HeiseiKakuGo-W5Hにttf-japanese-mincho/gothic.ttfとでも書いちゃうという(ひどい)手もある。

レンダラにFreeTypeを使う「FAPI」という機構もある。DebianのデフォルトはOFF。FT_BRIDGEパラメータをDEB_BUILD_OPTIONSに付けて再ビルドすると有効になる。が、これで動かすのはどうもよくわからなかった。fontsにFAPIcidfmap、FAPIconfig、FAPIfontmapの3つのファイルを置いて調整するようなのだが、文字のないPSですら起動しない。単にレンダラなだけでFreetypeのフォント名が使えるわけでもないし、メリットがわからない。

FAPI/fontconfigはとりあえず無視? CJKについては、cmap-*/gs-cjk-resourceは捨ててpoppler-dataに統一してもよさそう(gs-cjk-resourceのSMgoJが気になるが)。ただし、ghostscript用にCMapのベタ展開と、cidfmapの何らかの管理は必要。poppler-dataでやる話ではないので、何か別のパッケージを用意する必要がある(gs-cjk-resourceを作り変える?でもupstreamとは何の関係もないものになるので、名前を変えたほうがいいのではないか)。欧文Fontmapについてはgsfontsかghostscriptかで面倒を見るのがよさそう。

もうちょっと見てみた(2010.1.2 16:16)。また別にfontconfigを使う箇所があって、これはHAVE_FONTCONFIGフラグでデフォルトで有効になっており、FT_BRIDGEとは関係ない。設定はbase/gp_unix.cに反映され、fontconfigで管理しているフォントファミリとスタイルからPSフォント名をマングルして生成するmakePSFontNameという関数が有効になる。また、unix_fontenum_tというfontconfig接続構造体が追加され、gp_enumerate_fonts_init関数にはfontconfigの設定を読み込んでフォント一覧を取得するコードが追加される(エイリアスは読まれるんだろうか?デバッガで追わないとよくわからない)。gp_enumerate_fonts_next関数には順次フォントを読んでmakePSFontNameを使いPSフォント名とパスを返すコードが入ってるっぽい。gp_enumerate_fonts_free関数には掃除コードが追加。

結局、代表PSフォントのエイリアスをやってくれるわけではないっぽいので、これは引き続きfontconfigにエイリアスマップを記述することになりそう。逆に言えばこれだけが現状の問題?本当にfontconfigの探索がうまくいくか実験してみよう……。

……だめげ。和文については、makePSFontNameで「VLゴシック-Unknown」とか返してきちゃってる。LANG=Cにすれば一応英語名が先に返るようにはなる。欧文についても、gp_enumerate_fonts_nextで実ファイルしか探さないので、fontconfigでのエイリアスは効果がないっぽい(エイリアスはFontmapかcidfontmap側)。しかしそもそもPSファイルでPSフォント名をどのように書いても、ファイルが読まれないっぽい感じ。

2009年12月31日

Lenny d-i 2.6.32カーネル

いつものように。 久々のアップデート。Debian 5.0.3ベースにしてカーネルをunstableから持ってきたほかは特に変更はありません。あと、ブート時にvga=normalだと止まるマシンが多いようなのでsqueezeと同様にvga=788にしておきました。良いお年を。

2009年10月25日

署名鍵取得

TypeZのSSD(SONY純正サムソンのではなくて、IntelのX25M)が壊れてしまったので、別環境で作業中。GPGの秘密鍵(C452E0FC)だけはバックアップしていたのだが、公開鍵にこれまで署名してもらったものが未適用。自分の公開鍵はキーサーバーに随時アップロードしていたので、これにまず同期してから、各署名をダウンロード。1ライナー。

gpg --keyserver wwwkeys.eu.pgp.net --recv-keys $(LANG=C gpg --list-sigs C452E0FC | grep "User ID not found" | ruby -e 'ARGF.each{|l| puts l.sub(/^sig (2|3)?\s+/, "").split(" ")[0]}' | sort | uniq | xargs)

2009年10月15日

Debianのwebwml CVSをgitで処理する (コミッタと内部処理編)

翻訳作業者編に引き続き、今度は、どうやって実装しているのかなどに興味のある方向けのお話。まずは概念図。

                  +-------------+ パッチメール送付
                  |HTTPユーザ環境| → debian-wwwメーリングリスト
                  +-------------+
                    ↑ clone/pull
git.debian.or.jp ----------------+ clone/pull +-------------+
|  CVS→gitの同期(cron)          |  →         |sshユーザ環境|
|  gitリポジトリの提供(ssh, HTTP) | ←         +-------------+
+--------------------------------+ push
    push↑ ↓pull
kmuto環境 ------------------------------+
|  gitリポジトリのクローン(ssh)          |
|  git→CVSの同期(webwml-patch-commmit) |
+---------------------------------------+

作成したコードはSubversionリポジトリ「https://svn.debian.or.jp/repos/webwml-sync/trunk」にある。

git.debian.or.jp上で行う「CVS→gitの同期」は、syncというシェルスクリプトとwebwml-git-committer.rbというRubyスクリプトが担当している。準備としては、作業ディレクトリ上に、Debian.orgのCVSリポジトリをread only(pserver)経由でwebwmlという名前で置き、同期用にGitリポジトリからクローンした作業ツリーをwebwml-gitworkという名前で同様に置く。

そして、syncスクリプトで、CVSとGit作業ツリーをまず最新に更新し、CVS内のファイルをrsyncに-uオプションを付けて同期処理をする。続いてwebwml-git-committer.rbスクリプトをGit作業ツリーに対して実行し、追加されたものを調査する。既存ファイルの更新や削除であればgitが面倒を見てくれるのだが、新規についてはこちらで指示しなければならない。git ls-filesを使えばリポジトリ管理外のものが?マークで表されるので、これを新規ファイルと見なしてgit addで追加する。ここまでできたら、git commitの-aオプションでまだステージしていない残存ファイル、つまり既存ファイルが更新されたものや削除されたものを含めて全部コミットする。最後にpushを実行してリポジトリに反映し、CVS→gitの処理は完了だ。syncはヒューリスティックに15分ごとにcron実行させている。一応安全のためにロックなども作るようにしている。

Gitリポジトリでは今のところ複雑な処理はかけていない。HTTP向けも単にリポジトリのbareを外に見せているだけ。フックとしてpost-receiveでプッシュされたコミットメールをdebian-wwwメーリングリストに送るのと、post-updateでHTTP向けにgit-update-server-infoを実行しているくらい。今後はパスのチェックやエンコーディングテストなども入れたほうがよいかとは思っている。

さて、翻訳作業者にいただいた成果は、速やかにCVSに反映したい。 プッシュされたものならプルで、パッチなら適用・コミット・プッシュして、CVSに反映したいコミット履歴ができたとしよう。Debian.orgの(Aliothにあるリポジトリにssh経由で書き込み可能な)CVSツリーをwebwml、Gitの作業ツリーをwebwml-work、パッチ準備ディレクトリにpatches、パッチ済みディレクトリにpatchedといった形で用意しておく。

ここでwebwml-patch-commitの出番となる。これはシェルスクリプトで(Rubyで最初書いていたのだけれど、外部コマンドをたくさん呼ぶならシェルスクリプトのほうが扱いやすいという判断に至った)、履歴からパッチを生成し、パッチの確認・CVSへの適用・コミットをインタラクティブに進めていくもの。

実行すると、CVSとGitの最新への更新を行った後、指定のGit履歴ハッシュ値(lastcommitというファイル、または引数で指定)をgit format-patchに-oオプションでパッチ生成ディレクトリ指定を付けて渡す。format-patchは指定の履歴「より後」のコミットを「数値-*.patch」のファイル名で作ってくれる。

後は、各パッチの処理。先頭行にパッチ作成者情報があるので、これを見てCVS→Gitの同期に使っているエージェントコミッタだったらそのパッチは無視する(「パッチ済み」に移動する)。 そうでないなら、まずはパッチをCVSに適用テスト(patch --dry-run)してみる。ここでエラーが出たら実行自体を止めるか、そのパッチは保留にして先に進むかを選ぶことになる。

正常に適用できるようなら、コミットログと「適用する」「適用しない(保留)」「パッチをページャで表示」「適用しない(適用済みに移動)」の質問を提示して(実際には「Apply? [y/n/p/s]」と簡略化してるけど)、処理をコミッタが決める。普通は「適用する」を選ぶことになるわけだが、これでCVSにパッチが適用され、Gitに入れたコミットログをそのまま使ってCVSをコミットする。適用したパッチは「パッチ済み」ディレクトリに移動。Gitで行われたファイルの追加/削除については、git whatchangedを使って5列目がAあるいはDかどうかを調べて判断している。

「パッチ済み」のものは同時にその履歴ハッシュ値をlastcommitに書き込むようにしている。こうすることで、次回webwml-patch-commitを実行するときにどこまで処理していたかを確認に回る必要がなくなるわけだ。

仕組みとしてはだいたいこれでおしまい。日本語限定というわけではなく、変数targetlangをいじればほかの言語にも流用できるようにしてある。万が一のときを考えて、foolproof的な仕組みはいくつか入れているし、今後も追加したいと考えているけど、シェルスクリプトだとそろそろ厳しいなぁと感じるのも事実。数日で作ったにしてはちゃんと機能しているし、コミッタとしての作業はずっと楽になったし、翻訳作業者も広く募れる体制になったし、とりあえずは良かった、Git万歳ということで。

Debianのwebwml CVSをgitで処理する (翻訳作業者編)

Debian.orgのWebサイトのコンテンツ「webwml」の管理は、いろいろなしがらみから未だにCVSを採用している。Subversionなどの別のSCMにしようという提案は何度か行われてはいるものの、作業には管理チームの手助けが必要なほかに、各翻訳作業者(世界各国各言語)がそのSCMになじめるかという問題があり、なかなか実行には踏み切れていないというのが現状だ。

しかし、翻訳やコミットをしている立場からすると、CVSはつくづく扱いづらい。何をするにもサーバに問い合わせるから遅く、コミッタ権限を持っていないとパッチなりファイルなりを送り付ける以外何もできない。コミッタ側もそのパッチ処理がだるいので億劫になる。

ということで、CVSと同期したGitリポジトリを作って翻訳作業者に公開し、コミットされたものをCVSに半自動でコミッタ(私)が順次処理できるような仕組みを作ってみた。Gitは分散環境に適したSCMで、リポジトリへの書き込み権限を持たない作業者でもローカルなコンテンツ管理を行える(たとえばネットワークから切断された環境でも履歴やコミットを利用できる)。

翻訳作業者がDebian JP Projectのメンバなら(sshで入ることのできるアカウントを持っているなら)、次の書式でツリーをクローンできる(gitスイートはgit-coreパッケージに入っている)。

$ git clone ユーザ名@git.debian.or.jp:/git/webwml.git

englishとjapaneseを格納したwebwmlディレクトリができるので、このjapaneseのほうで作業していけばよいわけだ。翻訳では先頭行の#use wml::debian::translation-checkの値を英語版のCVSリビジョンに合わせる必要があるが、これはenglish下の同名ファイルの最終行に書かれているはず。たとえば翻訳追従系の作業なら、1つのファイルの作業が終わるたびに、

$ git add ファイル名パス
$ git commit -m "sync with 原文リビジョン"

を繰り返していく。変更内容を読み返したいなら、「git diff」や「git log」などを使う。詳細については参考文献を参照いただきたい。 ひととおり作業に区切りができたらこれをgit.debian.or.jpにプッシュする。

$ git push

これで、これまでに行ったコミットがgit.debian.or.jpに送られ、Debian JP Projectのdebian-wwwメーリングリストにコミットログが流れて、後はCVSコミッタの処理待ちとなる。本当はレビューのプロセスも入れたいところだけど(たとえばドラフト用のブランチ切って、レビューアがレビューしてmasterへマージ、とするとか)、今のところはアジャイルに即コミット、間違いがあれば後で更新という形で進めている。 逆に作業ツリーの中身をgit.debian.or.jpのものと同期するには、次のようにpullすればいい。

$ git pull

Debian JP Projectメンバでない場合、つまり直接クローンやコミットをできない場合は、Web経由でクローンし(プッシュはできない)、パッチを適宜debian-wwwメーリングリストに送付いただくことになる。Web経由でのクローンの書式は次のとおり。webwml-gitという作業ツリーができる。

$ git clone http://git.debian.or.jp/git/webwml-git.git

プッシュができないだけで、作業ツリーの編集やコミットは自由にできる。同期は先と同様に「git pull」。 行った変更からパッチを生成するには、git format-patch(またはgit-emailパッケージのgit send-email)を使う。git format-patchを次のように実行すると、git.debian.or.jpのほうにまだマージされていない部分についてのパッチファイル(*.patch)がコミットごとに用意されるので、このパッチファイル群を添付などで送ればいい。メール本文の中に入れるとエンコーディングが変わるなどしてコミッタ側で扱いづらいので、添付ファイルのほうが望ましい。

$ git format-patch origin

なお、debian-wwwメーリングリストはsubscribeしているメールアドレスでないと投稿はできないようになっているので注意されたい。

ここまでの内容で、翻訳作業者はひととおりのことができるようになるはず。 翻訳作成・更新待ちのものについては、Debian.org Web Japanese translation statusなども参照するとよいだろう。



/

Git初心者にお勧めできる入門書。Gitのエッセンスはすべてここに込められている。



/

奇しくも同名になってしまったものの、こちらはGit開発者濱野氏ご自身による1冊。『入門git』では省略している内部構造や各種のコマンド、フックについても詳細に解説している。『入門Git』を『入門git』と並べて持っておきたい。

2009年08月19日

Subject: FTP Team changes

joergからd-d-a、8月15日。

Alexander 'Tolimar' Reichle-Schmehl、Chris 'lamby' Lamb、Torsten 'twerner' Werner、Barry 'bdefreese' deFreeseがFTPチームに加盟。

[すばらしい。DebConfでの呼び掛けが功を奏した? NEWパッケージのレビューについても進展があるといいね。-kmuto]

Subject: Introducing http://news.debian.net

anaからdebian-projectに。8月3日。

http://news.debian.net/をセットアップ完了。 Debian Projectに関する情報の広報やリンクを掲載していく予定。 開発者/ユーザ向けにあなたが興味深いと思ったニュースを投稿したいなら、http://news.debian.net/submit-news/を参照してお好きな方法で。 このサービスを始めた動機については リンク [hatena] | Debian

Subject: Bits from the release team and request for discussion

d-d-aにリリースマネージャのlukから。7月30日。

リリースチームにAdam D. Barratt(adsb)、Felipe Augusto van de Wiel(faw)、Jurij Smakov(jurij)がリリースアシスタントとして加入。

次のリリースゴール(RCバグを付けてでも達成するもの(※条件等の詳細は原文参照))を設定。

上記のとおりkfreebsd-i386とkfreebsd-amd64がリリースアーキテクチャ候補に追加された。 現時点ではこれらのアーキテクチャのバグはRCとは見なされず、testingミグレーションにも影響しない。alphaとhppaはリリース対象落ちの危険水域で、移植担当者に質問中。

時間ベースのフリーズを導入。次期リリースの開発サイクルを向上させるものと期待。時間ベースの「リリース」はリリースの品質を落とさないためにもDebianでは行わず、リリースの準備ができたときにリリースする。フリーズのタイミングを12月にした理由としては、DebConf期間中を避け、過去のEtchとLennyが年の始めにリリースされたというサイクルに合わせたから。1年単位のリリースサイクルは短すぎ、3年単位は長すぎてセキュリティサポートも大変。よって2年単位がベストと判断した。

コミュニティからのフィードバックと定めたリリースゴールに基づき、やはり2009年12月にフリーズする。今後主だったチームに、このタイムラインが彼らの計画・スケジュールにフィットするかどうかを問い合わせていく。8月末までにはこの処理を終えて新しい計画を皆さんにお伝えできると期待している。

リリースサイクルのうちの困難な部分が始まった。また共に作業することを楽しもう。Debianがその称賛を受けている、高品質で安定したリリースを生み出そう。

[このあとすぐにMeikeがプレスとしてリリースゴールの内容を出してる……DD同士の議論はまとまらないだろうというのもわかるんだけど、公式な声明として出すには早すぎる感じはあるね。i18n関係でも知己のfawがリリースアシスタント入り。がんばるなぁ。私は今回はリリースヘルパーくらいの作業はしたいけど。 -kmuto]

Subject: Debian decides to adopt time-based release freezes

ちょっとずつannounce系の処理。Meike Reichleより(って夫妻でプレスチームなのか)、7月29日に。海外メディアなどでわりと報道されたので、そこそこ知っている方も多いかと。

Debian Projectは今後、リリース物のフリーズを、2年単位——奇数年の12月というサイクルの時間ベースにすることを決定。つまり、次期リリース物Squeezeのフリーズは2009年12月となり、そのリリースは翌年前半、2010年春の予定となる。

(これまでの曖昧なフリーズタイミングから)時間ベースのフリーズに移行することで、Debian ProjectはDebianの時間ベースのリリースへの一歩を踏み出したと言える。新しいフリーズポリシーにより、ユーザはリリースの時期を予測できるようになり、Debian開発者は長期的計画にのっとって作業できるようになるだろう。2年単位のリリースサイクルは大規模で破壊的な変更にも耐え得、ユーザの不便を軽減するにも足りる。フリーズの見込みができることで、結果的にフリーズ期間の短縮にもなるはずだ。

Debian Lennyのリリースは2009年2月であり、次のリリースDebian GNU/Linux 6.0(コードネームsqueeze)が登場するまでの約1年の寿命となるが、これは今後のタイムスケジュールでの唯一の例外である。長期的計画を考えている組織やユーザのために、Debian Projectは現リリースのDebian GNU/Linux 5.0 Lennyから2つ先のリリース予定のDebian GNU/Linux 7.0へのアップグレードも可能にすることを約束する。

フリーズまでの時間は短いが、Debian Projectはいくつかの大きなゴールを達成できることを期待している。最も重要なのは、multi-archサポート(64ビットマシン環境で32ビット版パッケージのインストールができるように改良する)と、起動プロセスの最適化(高速化と高信頼性)だ。

この新しいフリーズポリシーは、スペインCaceresで開催されたDebian Projectの年度カンファレンス「DebConf」にて提案され、参加したプロジェクトメンバによって賛同された。

[ということで、そのあと「聞いてねぇよ」「なんでdevel-announceじゃなくてプレスから全体アナウンスなんだ」とかフレームになってたわけだが(リリースマネージャのLukの発表の場にもいたけど、賛同というよりも「マジッスカ」という雰囲気が漂ってた)。時間ベースのフリーズにするのはようやくか、という気はする。Ubuntuとの兼ね合いを考えて開始時期をこうしたというのはちょっと引っかかるけど、いずれにしても単に「機能フリーズ」の話であってクオリティにかかわらず「リリース」しちゃえという話ではない。「2年とほんの720日ほどでリリースしました!」なんてことのないようにしたいね。7.0アップグレードについては聞き漏らしたのかなぁ、覚えがない。-kmuto]

2009年08月01日

Debconf9から帰宅

ラコルーニャ〜マドリード〜カセレスのDebconf9〜マドリードという2週間の旅から帰りました。すばらしい体験。詳細は後日。ちなみにマドリードは2009年7月時点ではまったくといっていいほど平和(ちょっと危なそうなところは感覚でわかるはず)。Barajas空港はあいかわらずダメ…。タイ航空で行ったんだけど、バンコクのスワンナプーム空港もだいぶひどかった。

2009年06月28日

Lenny d-i 2.6.30カーネル+ファームウェア版

いつものように

bnx2、bnx2xのサポートを強化。HCLデータベースでの2.6.29→2.6.30差分を見てみるとほかにもNIC絡みでいろいろ追加されている模様。あと、Lenny 5.0.1にしたのでインストールでミラー選択したときに失敗する/止まることもなくなったはず。前のバージョンで仮想マシンのIDEディスク環境だとディスクを認識できなくて謎だったんだが、ide-diskドライバの名前が変わってたのか。

ちなみに0627イメージから、ext4に対応してみたよ。bootパーティションに使うといろいろ不幸なことが起きるので注意。

2009年05月07日

Subject: Misc developer news (#15)

developer newsの翻訳コーディネートって最近止まってるのかな。原文のほうは#15がhertzogから4月28日に。

3つのメジャーデスクトップに大規模アップデート。Xfce 4.6、KDE 4.2.2がunstableに。GNOME 2.26も近日中に行われる。

DebianのコラボレーションサイトAliothのLennyへのアップグレードが完了。gforgeはFusionForge 4.7に切り替え。問題があったらsiteadminプロジェクトのサポートチケットをopenするように。SSHのタイムアウトが発生する場合は、SSHクライアントの設定ミスが考えられる。Aliothはfail2banを使ってるので、頻繁にログイン失敗、たとえば登録していない鍵で何度も試行しようとするとブロックされる。

wiki.debian.orgをMoinMoin 1.7に移行(Dembach Goo Informaticsのマシンと帯域のスポンサーにより、ホストも変わった)。新機能がいろいろある。また、httpsログインができるようになった。

wanna-buildチームからのちょっとしたお知らせ。wanna-buildへのリクエストおよびautobuildに関するその他についての連絡アドレスdebian-wb-team@lists.debian.orgを用意した。また、Kurt Roeckxがamd64以外にもその他すべてのアーキテクチャについてのwanna-buildデータベースへの変更権限を持ったこともアナウンスされた。sbuildのバージョンもアップグレードされた。powerpc、hppa、i386に新builddマシンを追加した。

メーリングリストアーカイブからのspam除去。アーカイブの「Report as Spam」報告をレビューするシステムを用意した。アーカイブから除去する作業に協力いただくにはdebian.orgメールアドレスが必要。お持ちでない場合はリストアーカイブをチェックしてspamに「Report as Spam」ボタンを押していただきたい。Wikiも用意している。

グループウェアの議論のためのメーリングリスト。Debianのグループウェア群の開発者のメーリングリストcalendarserver-discuss@lists.alioth.debian.orgを作成した。グループウェアのサーバやクライアントを保守しているかそれに興味があるならぜひ購読を。たとえば新しいバージョンのテストを求めるためのアナウンスの場などに使用できる。

2009年04月23日

Input Hotplug Guide

X.orgの新しい入力デバイスホットプラグ機構についての説明がDebian WikiのInputHotplugGuideにまとめられている。ここんところ忙しくてまだsidにしてないので使ってないけどなー。適当に超訳してみた。

はじめに

X.org X サーバは最近、入力サブシステムに重要な改良を施しました。最も重要なのは入力ホットプラグ (input-hotplugging, 以降 i-h) で、X サーバにデフォルトでないキーマップを xorg.conf に指定しなくても正しい設定で機能するというものです。 この新しいシステムは hal および dbus に基づいているので、外部ツールのようなものが必要になるのではないかと懸念される人もいらっしゃるでしょう。 X サーバはそういったプログラムを使うことなしにこれまで動作してきたので、これはもっともな疑問です。 このドキュメントの最初のパートでは、新しい入力システムの原理、どのような問題を解決するか、どのようにそれが機能するか、について説明したいと思います。 なによりも重要なメッセージは、新しい入力サブシステムは、その機能性を倍加させるというより、ホスト OS に基づいて構築されており、ハードウェアに問い合わせ、相互作用するための標準化されたインターフェイスを使うことで OS を単純化させられるということです。 このドキュメントの 2 番目のパートは、必要に応じてどのようにシステムを設定するかを説明する HOWTO です。

原理

X.org の長期的目標

X.org プロジェクトは XFree86 プロジェクトから連綿と続いてきたコードベースを受け継ぎました。 最大の制約は、私たちが今日亨受しているフリーソフトウェア環境が提供されていないような、多種多様に異なる UNIX 間での絶対的な移植性が過去に必要とされていたことです。 そのため、X は自身で、システムバスの走査からハードウェアの駆動まで、何でもこなさなければなりませんでした。 要するに、これは OS の上に乗っかった OS だったのです。

設立以来の X.org の最重要目標の 1 つは、この類の振舞いを止めることで X を今風なものに引き上げることでした。 今日私たちはカーネルから起こされた完全にオープンな OS を手にしており、古い UNIX は死あるいは死に瀕していることから、このビジョンにのっとって多くの段階を踏んできました。 古いモノリシックな X のコードベースは適切な形に分割され、その特別なビルドシステムもほぼ標準の autotools に移行しました。 加えて、X は古い /usr/X11R6 ディレクトリを去って、ほかの通常のソフトウェアピース同様に FHS の世界に入りました。 X サーバの特別なローダシステム (そう、自前のローダを持っていたのです!) は、標準化された ELF 形式で置き換えることで、スクラップにされました。 PCI バス操作コードは削除され、今ではサーバは、OS に PCI デバイスを照会するのに外部の libpciaccess を利用します。 linux では、これは単に標準化インターフェイスの /sys を見るだけです。

これらの開発のすべては、X を、偏執的な独立独行の部外者ではなく、ホスト OS の良き市民として振る舞うようにするという目標に沿っています。新規の移行は、Kernel Mode Setting (KMS) および GEM メモリマネージャという形でビデオドライバの大部分をカーネルに移動することで現在のシステムの公開性のメリットを活用すべく実際始められたのです。

基本入力

前述したことから推測されるとおり、古い入力ドライバ (keyboard/kbd、mouse、その他) は、実際にハードウェアを駆動するためにそれについての完全な知識を持っていなければなりませんでした。 自前でこの作業を行っていたので、必要なサポートを提供するのにホスト OS を当てにする必要はありませんでした。 しかし、ホスト OS がフリーで提供する事柄を亨受できず、ホスト OS 上で利用可能な機能を重複して実装しなければならなかったのです。

evdev ドライバはこれを変える最初のステップでした。 evdev は一般の I/O を操作するためのフレームワークです。 このフレームワークはカーネルが特定のデバイスの詳細を扱うようにし、またユーザスペースのプログラムがそれとインターフェイスを持つことができるようにします。 X サーバが evdev ドライバを使うと、すべての実ハードウェアの操作がその属するカーネルに事実上移動します。 カーネルは、マウスボタンやホイール機能のような事象についての情報を提供することもでき、最適なドライバのものと同等の柔軟性を X サーバに与えます。 これは、大きく簡易化、保守容易化された X 側でのドライバを提供するので、 明確に責任範囲が分割され、X サーバが OS の良き市民となります。 総合的に言えば、evdev を使うことは、システムの複雑さを軽減することにつながります。 これらの利点から、現在の Linux 上での X サーバのデフォルトは、evdev を使います。 そのため、evdev でキーマップを提供するという変更は、xbindkeys や xmodmap を使って作成したカスタムマッピングを使っている人にとって少々不安をかきたてたようです。 この場合に必要なのは、単に新しいキーコードに再マップすることだけです。 無論、これは私たちが予知可能な未来において再び起こるかもしれない問題の類ではありませんが、evdev に切り替えることで真の利益を得るために、10年に一度払うだけの価値はあります。

hal、dbus、console-setup

この時点で、システムにいくつかの大きな改善はなされましたが、その他のいろいろな問題はまだ残っています。 まず、真っ先に挙げられるのが、デフォルトの 'us' マップを使いたくないときキーマップを設定するのに xorg.conf がまだ絶対に必要とされていることです。 Debian は、キーマップをユーザに尋ねてそれを適切に設定するための大きなシェルスクリプトを持ち続けなければなりません。 この情報は、キーマップについての別個の設定を持つコンソールとも重複します。 2 つが同期しないとしたら、これは明らかに問題を引き起こします。

加えて、ホットプラグは十分にサポートされているとは言い難いものでした。 Linux カーネルは、すべてのデバイスイベントを単一のデバイスインターフェイスに多重化することでホットプラグを透過的に管理できます。 これは多くの人にとって十分よく動作していたので、これが機能しないというのはどうにも不愉快なことでした。 X サーバはカーネルがその裏で何をしているかについてわからなかったので、結局デバイス単位の設定を管理することはできませんでした。 そのため、デフォルトに適合しないか xorg.conf でまだ設定していないデバイスがホットプラグされると、前述のような同じ問題にまい戻らされました。

これらの問題の両方を解決するために、1 つの概念的解決がありました: それは、X サーバが、デバイスが何か、どのように固有の扱いをすべきかをホスト OS に尋ねることです。 たとえばデバイスがマウスなら、拡張ボタンはどうなっているでしょうか? デバイスがキーボードなら、キーマップには何を使うべきでしょうか? サーバが情報を取得できるなら、それ自身で設定を持つ必要はもはや不要です。 この情報を持つ単一の場所を持ち、すべてのアプリケーションが X サーバと同じやり方でそれに照会できるので、これはシステム全体の複雑性を軽減します。

Linux でこの問題を取り扱う方法が、hal を使うことです。 hal は多くの人にとっては神秘の代物ですが、その概念はとても単純です。 hal は udev 経由でのデバイスの作成/削除のためにカーネルを監視します。 イベントを検出すると、関係するイベントを dbus 経由で送出します。 X サーバは、現在検出されているすべての入力デバイスの一覧を取得するために、起動時に dbus 経由で hal に照会することができます。 hal は、固有のデバイス単位のプロパティをエンコードした一連の xml ファイル (.fdi) で構成されたデータベースから成る追加のプロパティを持っています。 そのため、特定のデバイス情報のために不明瞭な C コードを編集する代わりに、人間が読める形式で記述され、hal を各ユーザにぴったりくっつけることができます。 このもっとも重要な部分は、この情報は xorg.conf にある必要がなく、つまり誰かがインストール時に xorg.conf を書くたびに毎回再入力することが不要であるということです。 サーバはただ暗黙に hal 経由でシステムから情報を取得します。 加えて hal は、xorg.conf 形式ではできない、すべてのマウスに何かさせるといったグループ設定も可能です。 サーバは、入力ホットプラグが稼働できるよう、dbus に接続したままにして hal を監視し続けることもできます。

最後のひとかけは、console-setup です。このドキュメントの目的として、console-setup はシステムワイドなキーマップ設定の面倒を見ます。 各ユーザはコンソールを持ちますが、すべてのユーザが X を使っているとは限らず、この責任を担当すべき適切なところは console-setup です。 console-setup は現在、インストール時に xorg.conf を読んで、もし存在するならそれをシステムワイドなキーマップの設定に使います。 これは過去の設定が移行で失われないことを保証します。 console-setup はそれから hal にキーマップが何かを伝え、これによって hal は X サーバからの照会を受けたときにそれを伝えることができます。 これで、xorg.conf にキーマップを含める必要がなくなり、システム全体の単一の場所 (/etc/default/console-setup) で設定するだけとなって、X サーバがほかのアプリケーションと同様に単にそれを使うようになります。

まとめ

入力サブシステムの改良の目標は、標準化された OS サービスを利用して Xorg コードベースと OS の双方の複雑さを軽減すると同時に、重要な新しい機能性を提供することでした。 これらの目標の両方は達成されました。 現在では、コンソールと X で別々に設定する代わりに、システムワイドなキーマップを設定する単一の場所があります。 加えて、デバイスのホットプラグは完全にサポートされ、X サーバはそれを完全に亨受できています。 最後に、ドライバごとの C のコードや独自の xorg.conf ファイルでの多数の情報を再エンコードする代わりに、X サーバは hal のデータベースで提供されるデバイス固有のプロパティを利用できます。 X.org と X Strike Force は、これらが、過去の低い機能性や不自由さを乗り越えて進み続けるために X が必要としていた、大きな進歩を表していると信じています。 以降のセクションは、あなたがこのシステムを最良に使うのを助けるべく設計されました。

HOWTO

キーボード

アップグレード時に、hal および console-setup が xserver-xorg の依存/推奨によって持ち込まれます。

console-setup は、既存の xorg.conf からキーボードレイアウト情報を集めます。そのため、/etc/default/console-setup の以下のような行を得られるはずです。 これを手で修正してもかまいません。

$ grep -C 3 -i xkb /etc/default/console-setup
# The following variables describe your keyboard and can have the same
# values as the XkbModel, XkbLayout, XkbVariant and XkbOptions options
# in /etc/X11/xorg.conf.
XKBMODEL="pc105"
XKBLAYOUT="fr"
XKBVARIANT="latin9"
XKBOPTIONS="lv3:ralt_switch"

console-setup の用意ができると、hal はそこから情報を集めます。アップグレードされていないときには、hal の再起動 (/etc/init.d/hal restart) が必要かもしれません。 その後 lshal を実行すると、正しいキーボードレイアウトを報告するはずです。

$ lshal | grep xkb            
  input.xkb.layout = 'fr'  (string)
  input.xkb.model = 'pc105'  (string)
  input.xkb.options = 'lv3:ralt_switch'  (string)
  input.xkb.rules = 'base'  (string)

入力デバイスが検出されると、X サーバは hal から情報を取得します。 /var/log/Xorg.0.log に次のように示されます:

(II) config/hal: Adding input device Dell Dell USB Keyboard
(**) Dell Dell USB Keyboard: always reports core events
(**) Dell Dell USB Keyboard: Device: "/dev/input/event9"
(II) Dell Dell USB Keyboard: Found keys
(II) Dell Dell USB Keyboard: Configuring as keyboard
(II) XINPUT: Adding extended input device "Dell Dell USB Keyboard" (type: KEYBOARD)
(**) Option "xkb_rules" "evdev"
(**) Option "xkb_model" "pc105"
(**) Option "xkb_layout" "fr"
(**) Option "xkb_variant" "latin9"
(**) Option "xkb_options" "lv3:ralt_switch"

別のレイアウトに切り替えるために、/etc/hal/fdi/policy/ への新しい *.fdi ファイルとしていくつかの上書きルールを追加できます。たとえば、ドイツ語レイアウトを取得するには次のようにします:

<?xml version="1.0" encoding="UTF-8"?>
<deviceinfo version="0.2">
  <device>
    <match key="info.capabilities" contains="input.keys">
      <-- Enforce XkbLayout=de and XkbVariant empty -->
      <merge key="input.xkb.layout" type="string">de</merge>
      <merge key="input.xkb.variant" type="string" />
    </match>
  </device>
</deviceinfo>

異なるレイアウトの異なるキーボードを保有しているなら、そのうちの 1 つにレイアウトを変更するためだけのいくつかの "マッチ" ルールを追加する必要があるかもしれません。 fdi ファイルを追加 / 変更したあとに hal を再起動することを忘れないでください!

マウス

マウスについてはずっと簡単で、すべきことは何もなく、evdev が自動でロードされます。

タッチパッド

synaptics タッチパッドを使っているのなら、マウスとして利用できるはずです。ただし、hal はタッチパッド能力があることも報告します:

$ lshal
[...]
udi = '/org/freedesktop/Hal/devices/platform_i8042_i8042_AUX_port_logicaldev_input_0'
[...]
  info.capabilities = {'input', 'input.mouse', 'input.touchpad', 'access_control'} (string list)

よって、xserver-xorg-input-synaptics がインストールされていると、(/usr/share/hal/fdi/policy/20thirdparty/11-x11-synaptics.fdi ファイルのおかげで) hal に evdev の代わりに synaptics ドライバをロードするよう伝えられます。

HAL を無効にする

xorg.conf の ServerFlags セクションで AllowEmptyInput および AutoAddDevices を off にすると、そうなります。

デバイスを無視する

Xorg があなたの入力デバイスの何かを使おうとするのを望まない場合、かつては xorg.conf にそれについて記述しないというだけで済んでいました。今では、hal がサーバにすべてのデバイスを伝え、それらすべてがデフォルトで有効になります。これを無効にするには、次のようにします:

<match key="info.product" contains="myname">
  <remove key="input.x11_driver"/>
</match>

"myname" を何にするかを調べるには、lshal を使います。

FDI ファイルの記述

ドキュメントは http://cgit.freedesktop.org/xorg/xserver/plain/config/x11-input.fdi を参照してください。hal パッケージの /usr/share/doc/hal/examples/10-x11-input.fdi にある例も利用可能です。

参照

Peter Hutterer の blog、特に この投稿この投稿を参照してください。

これと類似のドキュメントはArch linuxのこのページを参照してください。

madduck は、どのようにデフォルトのオプション、レイアウト、バリアントを超えて XKB を拡張するかについての簡単なライトアップを保有しています。

著者

このドキュメントの寄稿には、Julien Cristau、BriceGoglin、Peter Hutterer、DavidNusinow がかかわりました。

XStrikeForce/InputHotplugGuide (最終更新日時 2009-04-20 04:20:44 更新者 KenBloom)
[翻訳: Kenshi Muto, kmuto at debian.org]

2009年04月11日

第17回オープンソーステクノロジー勉強会 at GREE

「今年は人脈を増やす」が目標だったのにあまり実践できてなかったので、仕事が一段落ぎみなのをいいことに、ちょうどDebian JPのやまねさんと岩松さんが話すというGREE主催のオープンソーステクノロジー勉強会に参加してきた。GREEはDebianサーバをたくさん使ってる(中身や今後についても懇親会でいくつかお聞きしたけど、まだ秘密にしておいてね、だそうで)。

GREEの入っている黒崎ビル、六本木一丁目側からのエレベータで登ると受付側じゃなくて裏口になっているというのは罠。GREEの一井さんに「お待ちしていました!」とおっしゃられてしまったのだけど、開場時間から後方で座ってまったりしてました、アヒャヒャ。 詳細なレポートについては参加者からのご報告ページでまめな方々が記述されているのでそちらをご参照(このblossxomからTB飛ばす方法がわからない…)。立ち見含め、かなりの人数が入っていた。

やまねさんが「Debianは簡単です!」というGoogleの(だいぶ怪しい)検索統計に基づいたネタをアスキーアート込みで振り、岩松さんがDebianのNMプロセスがいかに困難であったかをこんこんと説明し、再びやまねさんに戻ってDebianの組織構成やリリースマネージメントなどを紹介。どうみてもこの感想は「パブリックイメージは簡単なんだけど、かかわると難しくておっかない」です、本当にありがとうございました。参加者にとってタイトル内容から個々に推測した期待とのギャップは大丈夫だったんだろうか…。

持ってきた『Release It!』3冊はやまねさん、GREE社さんに献本させていただいて、1冊は懇親会でじゃんけんプレゼントに(元HDD計測系の方が当選)。いい本なので宣伝してやってください。

懇親会ではGREEの方々、IPA出向中のよ。氏、わりと何度か会ってるような気がするけど実はまだサイン交換してなかった前田さん、久々のあやさんや山本くん(結局sysfsマウントで動いた?)のほか、CUPS翻訳でかかわりのあったRICOHの方とか、来年GREE入社予定の学生さんとか、初めてだけどもキーサインしてみたいという方とか、ライターの方とか、そのうちお仕事一緒にするかもしれないMySQLの方とか、といろいろな人たちと名刺交換してなかなか有意義な成果。おかげでピザとビールは少ししか取れなかった気もするが。学生さんにはいろいろ偉そうなことを言った気がするので、自分ももっと実践するようにしよう(笑)。そうそう、やまだあきら先生の「入門Debianパッケージ」はGREE社内のバイブルらしいです。



/


/

2009年04月06日

kfreebsd-* らしい

Joergがblogで報告してるように、新アーキテクチャとしてkfreebsd-i386とkfreebsd-amd64がDebianミラーに収録され、unstableとexperimentalでのパッケージ配布も始まった。

さて、GNU/kFreeBSDはsqueezeでの公式アーキテクチャになるだろうか? JPでは誰かkFreeBSD触ってる人いたっけかな。

2009年04月03日

Debian GNU/Linux device driver check & report version 2.0

「lspci -n」の結果を貼り付けるだけでLinuxドライバの対応状況がわかるWebサービス、「Debian HCL - Debian GNU/Linux device driver check page」について、一昨日から懸案の改良に着手しました。

これまでのものは結果の表示後に結果投稿した先はwilikiに送っていたのですが、マシン名をずらずらと並べているだけで探すにはわかりにくく、調査ページと別々になっているためにいまいち有用性の低いものとなってしまっていました。

今回のバージョンでは下記のような改良を施しました。皆様の情報をお寄せください。

ここ最近読んだ書籍から学んだいろいろなことを実装に反映してみました。



/

この書籍でプレースホルダ+トランザクションの有用性を再認識した気がします。ちなみに編集組版を担当してたりします。



/

監訳なので手前味噌っぽいですが、これは本当に本当に良い本です。問題のまったく出ないエンタープライズサービスというものを作るというのは不可能だけれども、もし問題が出たときにどうすればそれを最小化できるかということに重点が置かれています。主にJava言語でのお話が多いですが、考え方自体は言語・サービスによらず通用すると思います。何より文章がとても美しい本です(レビューアも豪華です)。本書のプラクティスからは、サーバの負荷を上げないためのキャッシュ活用。各ページのコンテンツはDBのデータから静的に作るようにして、軽量なeRubyページで取りまとめと翻訳を実行させています。投稿されたデータもすぐにデータベースに反映せず、キューに入れてバッチ処理します(なぜかDBIのトランザクションが変になることがあるのですが…)。キューの処理はcronで半自動です。



/

本アプリケーションはRestfulではないのですが、WebアプリケーションにおけるサービスベースのURL構成概念を参考にしました。ベンダとモデルからなるURLは、Apacheのmod_rewriteを使ってeRubyのパラメータとして渡しています。書籍のほうはおもしろいところもあるんですが、わりと退屈なところも多いです(誤字もちらほら)。4ページくらい読んでは寝る、の繰り返しです…。

今後の改良予定は下記のとおり。ぼちぼちとやっていくつもりです。ご意見などあればお寄せください。

2009年03月16日

Subject: Section changes in the archive

debian-devel-announceに、ftpmasterのJeoergから。

debian-develでの議論を経て、パッケージのセクションを数個追加することが決定した。debtagsのほうが長期的ソリューションとしてはベターであるものの、まだ完全にはセクションを置き換えるには至っていない。

まずはもう使われていないセクションbase(昔のインストーラによって使われていたもの)を削除した。

次に、下記の新しいセクションを追加し、該当パッケージを移動した。変更したい/すべきと思われるパッケージがあるときにはoverride-change at debian.orgまで連絡されたい。次のミラーパルスで反映される。

セクションを決めるにあたっての順位は次のとおり。debug > doc > localization > 言語固有 (>インタプリタ) > アプリケーション固有 > 一般

……言語関連が一気にセクション分けされたなぁ。

2009年03月10日

SONY TypeZのLinuxハックが進んでいたらしい

sony-laptopでまだ使えないホットキーはなんとかならんかね、とうろうろしていたらlaunchpadで「Sony Vaio Z-seires Laptop」プロジェクトが立ち上がってて、ハックが進められていた。

ホットキーについては普通のカーネルと同様にまだ音量コントロールしかできないんだけど、その代わりにSTAMINA/SPEEDを切り替える……というよりNVIDIAをoffにすることができるようにはなったらしい。

Sony Vaio Z21VN/X Installation OpenSuse 11.1ページからsony-laptop-zseries-0.6.tar.bz2を取得し、make、make install。Debianのカーネル2.6.28向けに普通にビルドできた。

「echo 0 > /sys/devices/platform/sony-laptop/bluetoothpower」でBluetoothの給電を止められる。 「echo stamina > /sys/devices/platform/sony-laptop/speed_stamina」でスタミナモード(NVIDIA off)。echo speedとやればスピードモード。ランプは一応切り替わるけど、この状態でintelドライバ設定にしたXを起動してみたらやはりIntelのほうが使われちゃった。本当に効いてるのだろうか?

ということでNVIDIAは実際のところどうでもいいので、staminaの状態で実行。ACを外し、Bluetoothは上記のとおりOFFにし、無線もドライバを外して(ifaceを落としてもドライバ抜くまで割り込みがかかってる)、画面を暗め設定(ホットキーが使えないのでGNOMEの明るさ設定)、powertopで推奨されるものを全部実行。powertopでのバッテリ駆動時間が7時間と出てきて、最初計測ルーチンが新しいドライバで壊れたのかと思ったのだが、消費電力量も8〜9Wしか消費しなくなっている。8Wで定常化できるなら11時間くらい持つらしいけど、さすがにそれだと何もできないので、エディタでちょこちょこ作業するとしてだいたい6〜7時間くらいを目途と考えるべきか。新しいsony-laptopにする前(NVIDIAにも通電されていた?)には18〜20Wくらいだった気がするので、すばらしすぎる改善。もともとのバッテリのカタログスペックでは7〜11時間らしいので、ようやくWindowsに近づくスペックになってきた?無線をONにしても5時間は持ちそうな雰囲気。

ホットキーのほうもモチベーションの高い人たちががんばってるようなので期待大(むしろ自分でもハックしろ、か)。

2009年03月08日

Lenny d-i 2.6.28カーネル+WPAサポート+ファームウェア版

英語のほうには書いておいたので知ってる人は知ってると思うけど、Backported d-i images archiveにLenny d-i 2.6.28版を置きました。

これでLenny標準の2.6.26では有線も無線も動いてくれないVAIO TypeZとかにそのままインストールできます。カーネルはunstableのものと同一。ファームウェアはUbuntuパッケージから借りてちょっといじったもの。WPA(-PSK)サポートは以前にdebian-bootにパッチが出されていたものを適用してみたのですが、ipw2100なLet's Noteでやってみた限りではどうもうまく動いてない感じもします。解析用のツールをなんも入れてないのでこういうときは不便ですな。

2009年02月25日

Subject: DebConf10 to take place in New York City, USA

ちょっと発表が早いような気もするが、来年2010年のDebconfはニューヨークの開催が決定した、とmadduckから公式に発表された。

なお、今年開催のDebconf 9はスペインExtremadura Caceresにて、7月24日金曜日に始まり、30日木曜日に終了を予定。

……うーん、NYCか。私の郵送で返送したI-94Wはちゃんと処理されたのかね、というのが気になる。異常に厳格なくせにかなりいい加減というのがUSの困ったミスマッチさだのぅ。さて、Debconf 9もどうするかな…。

2009年02月16日

Subject: Debian GNU/Linux 5.0 released

ということで、2009年2月14日にDebian GNU/Linuxのメジャーバージョンアップである「Debian GNU/Linux 5.0」コードネーム「Lenny」(トイストーリーの双眼鏡)がリリースされました。CD/DVD/ブルーレイイメージの準備もできています。

一番遅い時間帯でも15日になっていた気がしますが、プレスリリース日付も「Sat, 14 Feb 2009 22:58:48 -1100」となっているのでOKらしいです。Ganneffによればミラーは14日に反映されていてCDやWeb更新は残務だからオケ、とか。lukやHEといったリリースチーム、ftpmastersに感謝。

Etch以降はsources.listに「stable」ではなく「etch」のように書いていたので、stableが入れ換わってcron-aptがエラいことに!という事態はあまりないかと思います。PINで「testing」のように付けていた場合は「stable」に変えないといけないので注意(PINではコードネームは使えない)。EtchからLennyへの更新方法についてはnoritadaくんらががんばって訳したリリースノートの「etchシステムのアップグレード」をよく読んでください。

リリースと同時に、次の安定版候補であるtesting、コードネーム「squeeze」(三つ目のエイリアン)の開発も始まりました。testing落ちする前の先端不安定版unstable、コードネーム「sid」も活発にアップロードが再開しており、先端ユーザーお待ちかねの阿鼻叫喚がこれから大いに期待されそうです。HEはリリースマネージャを降りて、squeezeではAdeodatoがリリースマネージャを担当するとのこと。

また、新しいパッケージをstableに移植するbackports.orgも、Lenny向けのパッケージの受け付けを開始したそうです。Lenny a Halfも始動するとのことで、Lennyでは対応できないような新しいマシンのサポートも今後期待できるでしょう。

なお、今回のリリースを最後に、armアーキテクチャはarmelアーキテクチャに置き換えられることになりました。すでにunstable/testingからは消えており、Lenny a Halfでも対応されることはないとのことです。リリースチームを応援すべく数年にわたってarm builddを運用してきましたが、このリリースをもってマシンの火を消すことにします(Netwinderなのでarmelでは対応していない)。どなたかこのarmマシン(評価ボード(ミニタワーケース)、StrongARM-110 ARMv4 150MHz、256Mメモリ、80G IDE x2(MD RAID1)、S3 VGA)を再利用したいという方はいらっしゃいますかね? 特になければいずれ廃棄ということにします。

2009年02月15日

lv rsync-ftpsync.log.0

receiving incremental file list
./
Archive-Update-in-Progress-rietz.debian.org
README
README.html
dists/
dists/Debian5.0 -> lenny
dists/README
dists/oldstable -> etch
dists/oldstable-proposed-updates -> etch-proposed-updates
dists/proposed-updates -> lenny-proposed-updates
dists/stable -> lenny
dists/stable-proposed-updates -> lenny-proposed-updates
dists/testing -> squeeze
dists/testing-proposed-updates -> squeeze-proposed-updates
 ...
Number of files: 481874
Number of files transferred: 503
Total file size: 328196843922 bytes
Total transferred file size: 146710116 bytes
Literal data: 5287084 bytes
Matched data: 141423032 bytes
File list size: 14082610
File list generation time: 3.082 seconds
File list transfer time: 0.000 seconds
Total bytes sent: 147091
Total bytes received: 19487176

sent 147091 bytes  received 19487176 bytes  688921.65 bytes/sec
total size is 328196843922  speedup is 16715.51

2009年02月03日

Subject: Release update: deep freeze, planned dates, and remaining bugs

一昨日d-d-aにdatoから。

ディープフリーズ
ご存じのように、インストーラチームが(最終版と期待したい)LennyインストーラRC2をリリースした。イメージをどしどしテストいただきたい。前回のリリースアップデートの計画にのっとると、今こそディープフリーズのときだ。つまり、testingに統合するパッケージはRCバグを修正するもののみとなる、ということだ。それ以外のunblockリクエストは、(よほどリリースチームが時間を割いて耳を傾けるべきことではない限り)送らないこと(このアナウンス前にunblockリクエストを送っていて忘れられてそうであれば、元のメールに速やかにフォローアップを出してほしい)。同時に、フリーズになるまで例外を許容するパッケージについての"フリーズ例外"ヒントファイルも閉じた。1197の例外が自動で受け付けられ、うち983がLennyに統合されてる。
スケジュール
予定では2月14日をリリース目標としている。たくさんの関係チームと連絡を取り、この日付でだいたい行けそうと踏んでいる。エラッタとしては済まない重大な問題が見つかったり、技術的にこの日のリリースに望めない(マシンがクラッシュしたとか、ね)ということがない限りはこの日でいくつもりだ。その他の間に合わない修正についてはr1で、ということになる。RCバグの修正をポイントリリースに入れたいというときには私たちに連絡してほしい。一例として、新しいアーカイブ鍵がd-i rc2イメージに間に合わなかったので、Lennyインストーラで次のtesting(コードネームsqueeze)をインストールしようとしたときに問題となってしまう。5.0r1でこれを更新予定だ(なお、これはd-iの話なだけで、アーカイブのdebian-archive-keyringのほうは更新されてる)。また、追加のハードウェアサポートのために「Lenny and a half」リリースもSqueezeリリースサイクルの途中で提供するつもりだ。
残存RCバグ
現在、Lennyに影響してunstableでも直っていないRCバグのリストを処理中だ。can-defer(r1で修正予定、ほとんどのバグがこれであることを期待したい)、will-remove(パッケージの削除。バグ持ちのまま収録するほうが収録しないよりもたちが悪い場合)、is-blocker(絶対に修正しなければならないもの)のコメントを付けている。できるだけないほうがよいが、is-blockerタグを付けたものについては-develにも投げるようにしてる。ラベリングについて不満があれば-releaseに論理的な理由を提出すること。can-deferやwill-removeバグを修正することは大歓迎だ。リストを見て「これはブロッカーだ」とあなた自身が思って修正したり誰かに修正させることはとても素晴しい。できるだけすべての修正がLenny r0で行われるようにしたいと思う。RCバグの修正についてunblockリクエストを送る必要はないが、unblockについての明確な承認がほしければリクエストしてもよい。RCバグを修正できなくても、リリースノート作成を支援することはできるだろう。助力要請は11月に送られており、コーディネータが翻訳作業のためにフリーズする前の、これがパッチを送る最後の機会となる。

(ということで、ようやくLennyリリースが現実的になってきた。とはいえ私自身は何も用意できそうもないんだけど…。)

2009年01月12日

Subject: New Technical Committee Members

bdaleからd-d-a宛てのアナウンス。

Anthony TownsがDebian技術委員会を辞職し、Russ AllberyとDon Armstrongが新たに加わったようだ。

よって、現在のメンバーはBdale Garbee(議長)、Andreas Barth、Ian Jackson、Steve Langasek、Manoj Srivastava、Russ Allbery、Don Armstrongとなる。

Donとは面識あるけど、Russとはまだだな。

2008年12月31日

Subject: Results for General Resolution: Lenny and resolving DFSG violations

先日のvoteの結果が出てた。

vote 002のほうは、選択肢2、DAMを交じえて継続議論 に。まぁ順当だな。

膨大な選択肢のあったvote 003のほうは、選択肢5.、バイナリブロブを特に証明のない限りGPLに応じているものと仮定する、に。最も原理主義色の強かった選択肢1(すべてフリーになるまでリリースしない)は全選択肢にbeatされてるので、Debianが原理主義でがんがらじめ、という偏見は当たらないんじゃないかな。とはいえ、こういう投票になること自体が原理主義的なのかもしれないけど。

選択肢が多かったぶん意見が分散してしまったけど、「ウダウダ議論するよりさっさとリリースしようぜ」というのが投票したメンバの大方の意思表明で、改訂条項制限が付けられていたから今回はできなかったけどファームウェアもDFSGでの配布でいいんじゃね?というのも透けて見える(Debianがこういうのに拘泥して、もっと気楽にやってるUbuntuのほうばかりがもてはやされるのはそう良い状況じゃないし。フリーは大切だしファームウェアばかりにメーカーが走ったらフリーOS全体にとって不幸になり得るんだけど)。

なお、一般決議が乱立した反省で、決議案を出すにあたって賛同者定足を設けて揃わなければ決議には持っていかないようにしよう、という議論が今行われてる。manojは今回の投票の混乱の責任と「Debianから脱退しろ」みたいなことを言われて(これは脳内ソースみたいだけど)事務局長を辞職。Bdaleが臨時で代行して、後任を募ってる模様。

2008年12月24日

Subject: Release Update: d-i RC2 and deep freeze; handling of remaining RC bugs; *-reports and release notes

(kmuto: 最近は私はwmlの更新くらいしかDebianにかかわれてません。本業で忙しすぎ…。)

(kmuto: さて、12月14日にLukからd-d-aにLennyリリース進捗アナウンスが出ていた。順調に遅れてますな。)

数ヶ月報告できなくてすまなかった。現在不足しているものとその進捗を明白にしようとしていた。で、その間にはunblockリクエストの山に埋もれてた。

ミッシングピース。現時点でLennyのパズルを組み立てる上で不足してるのはインストーラの最終バージョンだ。-bootチームが(クリティカルな問題が出なければ最終となる)2ndリリース候補配布に向けて準備を進めている。

ディープフリーズ。d-i RC2リリース後、ディープフリーズに入る。これは、パッケージメンテナにとって重大な結果となる。d-i RC2後のunblockリクエストは、RCバグの修正のみが許され、ほかは認められない。それ以前のリクエストについては順次ベストエフォートで処理してる。進捗を聞きたいときには新しいメールスレッドを起こさないように。

RCバグの数。ディープフリーズの段階で、Lennyに関係するRCバグがまだいくつかあるはず。リリースチームはリストに従ってリリースに向けた適切な解決を適用する(可能であればd-i最終版後2週間で)。つまり、リリースチームはLennyのために絶対に解決しなければならないバグの「短いリスト」を持っていて、それ以外の多数については「無視」「ダウングレード」「削除」といった手立てをとるということだ。ただし、これはRCバグ修正をやめるということじゃない。できる限りの努力はしよう。リリースチームはRCバグを修正するすべてのアップロードをレビューして、時間内にtestingにマージすることを保証する。適切な修正方法が存在するなら、短いリストにはなくてLennyのリリースに間に合わなかったバグは、ポイントリリースで直すこともできる。

アップグレード/インストールレポート、リリースノート。この分野では協力求む。たとえば、Lennyがほぼ最終の形になったらシステムをLennyにアップグレードし、upgrade-reportsパッケージへのバグ報告によって発生したあらゆるトラブルを伝える。新しいシステムにインストールするなら、DebianインストーラRC2(またはデイリービルド)をテストするのが最も歓迎される。通常、問題についてはinstallation-reportsパッケージにバグ報告されたい。完全なセキュリティサポートは(Lennyリリースまでにunstable経由で行われるカーネルアップデートを除き)セキュリティチームによってすでに提供されている。また、これらのバグ報告、特にupgrade-reportsに報告されたものを処理してくれる助力を求めている。協力の意思のある方はぜひ今すぐ始めてほしい! 何がアップグレードでまずいかを明らかにして適切なパッケージにバグを報告するか、問題についてまたは回避策をリリースノートに文書化する。

ファームウェアについての全体決議。リリースに向けての計画にあたって、潜在的にリリース作業を混乱させるかもしれない進行中の投票がある。リリースチームはプロジェクトの意思から乖離したことはないと信じる。このGRで我々が間違っていると言われるようであれば、我々は真摯に受け止め、正しく、GRの結果を無視することなく計画を進める。

(kmuto: ——ということで、Lennyリリースは年越しは確定か。d-iリリースマネージャのOtavioが戻ってくるのが1月頭なので、早くて1月末、まぁまぁ現実的には2月というところですかね。)

2008年12月12日

Subject: [Debconf-announce] DebConf 9 to take place in Extremadura, Spain in July 2009

madduckからdebconf-announce。

Extremaduraで開催されるDebconf 9の日程が決まったようだ。

1月に参加可否をとりあえず決めないといけないのか。ぼさまのところには遊びに行けるかなぁ…。

2008年11月30日

General Resolution: vote 002 Project membership procedures, vote 003 Lenny and resolving DFSG violations

そろそろdiscussion periodになりそうな投票情報。12月から投票になりそうかな。かいつまんだ超訳なんで、Debian Developer=投票者は原文を参照のこと。

vote 002は前にJoergが出してけっこうな騒動になっていたプロジェクトのメンバシップについて。選択肢は以下。

  1. Debianプロジェクトは、多くのコントリビュータがDebianの体制の中では活動していないためにプロジェクトの協力が限定的であることを認識している。コントリビュータをもっとプロジェクトの中へと巻き込む方法についてのアイデアを展開したJoerg Jaspertに感謝するが、debian-devel-announceメーリングリストに投稿された提案はまだ完成しておらずコミュニティ大半の支持が得られているとは言い難い。DAMおよびすべてのコントリビュータを迎えて今後プロジェクトのほかのメンバーと密接に協業するためのアイデアを募り、新しいブラッシュアップした提案を将来投稿したい。よって、メンバシップに関する変更は、GRによるプロジェクトでの合意後に実装されるべきである。
  2. Debianプロジェクトは、GRにより、debian-develo-announceメーリングリストで提案されたDeveloper Statusの実装を、提案の合意が取れるか実装されるべき提案を定義する投票があるまで延期することをDAMに求める。
  3. Debianプロジェクトは、GRにより、debian-develo-announceメーリングリストで提案されたDeveloper Statusの実装を延期することをDAMに求める。

なんかまだ錯綜していてどのChoiceも同じようなものになってる。結局投票もやる意味ないような…。

vote_003は主にファームウェア絡みのDFSG解釈とLennyでの対処について。

  1. 社会規約の再確認: 我々の優先事項はユーザとフリーソフトウェアコミュニティである。我々は100%フリーのオペレーティングシステムを提供すると約束している。これら2つについて、我々はnon-freeをDebianの一種として過去にリリースしたが、進展もなされてきた。我々はDebianオペレーティングシステムのフリーバージョンを提供する時期にきており、オペレーティングシステムをフリーにする努力を達成できるまでLennyのリリースを遅らせる。
  2. プロプライエタリなファームウェア付きのLennyリリースを認める: 我々の優先事項はユーザとフリーソフトウェアコミュニティである。我々はカーネルのファームウェア問題について進展があることがわかっている。過去に未解決であったほとんどの問題は前回のstableリリース時点で整理された。ただカーネルソースについての新たな問題が最近持ち上がっており、これらの問題はまだ対応されていない。我々は、Etchリリースで配布されたDebianのカーネルにおける自由への歩みが、Lennyにおいても後退のないことを保証している。我々は時間ベースのLennyリリースをその他の問題よりも優先したい。そのため、ソースのないファームウェアの削除をベストエフォートな処理とし、ファームウェアをDebian Lennyの一部として配布することを当面許可する。
  3. DFSG違反ながらLennyリリースを認める: 我々の優先事項はユーザとフリーソフトウェアコミュニティである。我々はカーネルのファームウェア問題の多くに進展があることを知っているが、まだ完全には整理されていない。我々は、Etchリリースで配布されたDebianのカーネルにおける自由への歩みが、Lennyにおいても後退のないことを保証している。我々は時間ベースのLennyリリースをその他の問題よりも優先したい。そのため、ソースのないファームウェアの削除をベストエフォートな処理とする。
  4. リリースチームにDFSG違反を許可するかどうかの権限を与える: 我々の優先事項はユーザとフリーソフトウェアコミュニティである。しかし、リリース真近にある状況では、決定は、いかにstableリリースを高品質で提供するか、問題のあるソフトウェアの使用を最小限にするかに当てられるべきである。我々のコア開発者とリリースチームの前に1つのみならぬ地雷原があることがわかっている。Developerとしての我々は、ゴールに向かうためにリリースチームを信頼し続け、決定に権限が必要なときにケースバイケースの決定を行う権限があることを承認する。
  5. ブロブを特に証明のない限りGPLに応じているものと仮定する: 我々の優先事項はユーザとフリーソフトウェアコミュニティである。我々はカーネルのファームウェア問題について進展があることがわかっている。過去に未解決であったほとんどの問題は前回のstableリリース時点で整理された。ただカーネルソースについての新たな問題が最近持ち上がっており、これらの問題はまだ対応されていない。我々は、Etchリリースで配布されたDebianのカーネルにおける自由への歩みが、Lennyにおいても後退のないことを保証している。我々は時間ベースのLennyリリースをその他の問題よりも優先したい。そのため、ソースのないファームウェアの削除をベストエフォートな処理とし、ファームウェアをDebian Lennyの一部として配布することを当面許可する。ファームウェアはDFSGに準拠したライセンスの下でupstreamから配布されているものとする。
  6. ファームウェアのソース要件を除外する: ファームウェアはマイクロコードやルックアップテーブルのようなデータであり、コンポーネントが機能するためにハードウェアコンポーネントにロードされる。ホストCPUで実行するコードではない。不幸なことにそのようなファームウェアは、それがどのような働くのかやどうハードウェアと連携するのかを知る手掛りとなるソースもドキュメントもないブロブと呼ばれる形で配布される。このようなファームウェアをDebianから除くと、我々はそのようなデバイスを必要とするユーザに我々のシステムをインストールできなくしたり、無駄な手間をかけることになる。Debianにおけるファームエワはソース必須でないものとする。ソースおよびドキュメント付きのファームウェアが望ましいが必須要件ではないことにする。ただしDFSGに定められた我々のオペレーティングシステムのその他の自由要件は必須とする。そのようなファームウェアは我々の公式インストールメディアの一部となることができ、そうすべきである。

最後の提案はまっとうではあるが原理主義からは反発も大きそう。とりあえずCMapをnon-freeからmainにする技を誰か考えてください。ルックアップテーブルデータなのでmainでいいだろと言ってたmhatta先生、どうしますかね。

2008年11月22日

GNU dbm(gdbm)のデータを変換する

Gaucheで書かれたWikiシステムのwilikiを活用してるのだが、x86アーキテクチャな旧マシンからx86-64アーキテクチャな新マシンへデータを移行しようとして、バックエンドデータベースのGNU dbmのデータがアーキテクチャ依存のために動かなくなってしまった。

ということで、RubyのPStoreを中間データにするようなダンプ/リストアツールを作成。rubyパッケージとlibgdbm-rubyパッケージを入れるだけで動くはず。gdbm_dump.rbは

#!/usr/bin/ruby
#  Copyright 2008 Kenshi Muto <kmuto@debian.org>
require 'pstore'
require 'gdbm'

if ARGV.size != 2 || !File.exists?(ARGV[0]) || File.exists?(ARGV[1])
  STDERR.puts "gdbm_dump.rb {GDBM file} {DUMP file}"
  exit(1)
end

db = PStore.new(ARGV[1])
gdbm = GDBM.new(ARGV[0])

db.transaction do
  gdbm.each_pair do |key, value|
    db[key] = value
  end
  gdbm.close
end

gdbm_restore.rbは

#!/usr/bin/ruby
#  Copyright 2008 Kenshi Muto <kmuto@debian.org>
require 'pstore'
require 'gdbm'

if ARGV.size != 2 || !File.exists?(ARGV[1]) || File.exists?(ARGV[0])
  STDERR.puts "gdbm_restore.rb {GDBM file} {DUMP file}"
  exit(1)
end

db = PStore.new(ARGV[1])
gdbm = GDBM.new(ARGV[0])

db.transaction do
  db.roots.each do |key|
    gdbm[key] = db[key]
  end
  gdbm.close
end

ダンプしたいアーキテクチャのほうで「gdbm_dump.rb GDBMファイル名 PStoreファイル名」を実行。PStoreファイルを新アーキテクチャのほうにコピーし、新アーキテクチャで「gdbm_restore.rb GDBMファイル名 PStoreファイル名」を実行してGDBMファイルを生成する。

2008年11月14日

Subject: Debian Installer lenny release candidate 1

(d-iチームのotavioからdebian-devel-announceへのアナウンス。)

Debianインストーラチームは、本日(11月13日)、Debian GNU/Linux Lenny向けのインストーラの最初のリリース候補を発表する。今回のリリースにおけるインストーラの改善点は次のとおり。

既知の問題点は以下のとおり。既知の問題の詳細については、errataを参照のこと。

バグの発見や今後のインストーラの改善のためには、あなたの協力が欠かせないので、ぜひ試して報告してほしい。インストールCD、DVD、その他のメディア(USB、ネットワークインストール等)、errata、その他必要な情報は、DebianインストーラのWebサイトhttp://www.debian.org/devel/debian-installer/を参照されたい。

今回のリリースに協力いただいたすべての方々に感謝する。

――ということで、今回はメッセージ翻訳くらいしか手伝えてません…。テストもできていないので、日本語まわりの状況、特にグラフィカルインストーラで文字化けや欠けがないか、標準またはデスクトップを選択した状態でインストールして環境的に不具合がないか(そもそもちゃんと依存関係のトラブルなしにインストールできるか)といったあたりをテストして成功にせよ失敗にせよ疑似パッケージinstallation-reportsに報告してくださる方を募ります。

2008年10月22日

Bug#502959 general: raff.debian.org uses non-free software

aurel32のはネタなのか本気なのかよくわからんので困る。

Package: general
Severity: serious
Justification: DFSG

raff.debian.org uses a Compaq Smart 5i RAID card. A flash memory is used
to store the firmware. While the firmware is freely downloadable (as in
beer) on HP website [1], we don't have the corresponding source code.

I suggest that someone works with HP to get the corresponding source
code. Until we found a solution, I recommend we simply shutdown the
machine.

[1] http://h20000.www2.hp.com/bizsupport/TechSupport/SoftwareDescription.jsp?lang=en&cc=us&prodTypeId=329290&prodSeriesId=374803&prodNameId=266599&swEnvOID=4004&swLang=8&mode=2&taskId=135&swItem=MTX-3d1aaa0b48c04b628789e598d3

Subject: Bug Sprint - Oct 25 to Oct 30 - Register and eat cookies

jossからdebian-devel-announceに。

lennyはリリースに本当に間近だ。ただ、現時点では100近くのRCバグが残っており、当初BSPで気合いのあった人たちも段々気力が尽きてきてるようだ。

今回のバグスプリントは、「100人の開発者が5日かければ100のRCバグをクローズできる」というものだ。RCバグの修正とは、次のいずれかだ。

RCバグを修正するパッチを3ヶ月以上前に書いて修正する人が「WINNER」となるだろう。WINNERとリリースマネージャには、特典としてボランティアとRCバグを5日以内に直せなかった奴らから自家製クッキーを受け取る権利がある。

ルールと碑銘はhttp://wiki.debian.org/BugSprintに。今すぐ名前を書いてクッキーをゲットしよう!

2008年09月23日

Subject: DELAYED queue and upload hostname, Subject: ssh.upload.debian.org

ganneffから2通、d-d-aに。

まずは1通目。 遅延キューがこれまでのgluck.d.oからftp-master.d.oで担うようになった。近日中に現在のgluck.d.oの遅延キューサービスは終了予定。*.commandsコマンドファイルでも操作できる。

DEFERREDキューの概要はhttp://ftp-master.debian.org/deferred.htmlで見ることができる。

また、ftp-master.debian.orgに変えて「ftp.upload.debian.org」というアップロードキュー用のホスト名を用意した。以後のアップロードではこのホストを利用するようdputあるいはduploadの設定を変更するのが望ましい(こういうシンボリック名を使うことで、管理上楽)。

続いて2通目。ssh経由でのパッケージアップロード用に、ssh.upload.debian.orgというホスト名を用意した。アップロードは/srv/upload.debian.org/UploadQueueに配置する。このアップロードキューを使うと、アップロードした者は1通以上のメールを受け取り、同時にキューデーモンはファイルをftp.upload.debian.orgに移動する。ssh.upload.d.oは.commandsファイルも受け付ける。DELAYEDキューはサポートされないので、必要ならftpを使うこと。