KeN's GNU/Linux Diary

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バグ追跡システムに報告してください。

リンク | Debian | コメント (1) | TrackBackリンク

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 | コメント (0) | TrackBackリンク

第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は調整作業をだいたい完了し、あとは運用周りの実験を今後引き続き行うことにしました。可能なら今月中に完全移行させたいと思っています。

リンク | Debian | コメント (0) | TrackBackリンク

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

リンク | Debian | コメント (0) | TrackBackリンク

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になる)。

リンク | Debian | コメント (1) | TrackBackリンク

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フォント名をどのように書いても、ファイルが読まれないっぽい感じ。

リンク | Debian | コメント (0) | TrackBackリンク

Lenny d-i 2.6.32カーネル

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

リンク | Debian | コメント (4) | TrackBackリンク

署名鍵取得

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)

リンク | Debian | コメント (0) | TrackBackリンク

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 | コメント (1) | TrackBackリンク

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
でびあんぐる
オーム社 / ￥ 2,520

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

入門Git
濱野 純(Junio C Hamano)
秀和システム / ￥ 2,310

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

リンク | Debian | コメント (1) | TrackBackリンク

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]

リンク | Debian | コメント (0) | TrackBackリンク

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

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

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