これはディストリビューション/パッケージマネージャー Advent Calendar 2013 17日目の記事です。 Debianの安定版(stable)と呼ばれるものは、一度リリースされると致命的なバグやセキュリティに問題がない限り、ソフトウェアのメジャーバージョンが上がることはありません。またリリース間隔が不定期なため、状況によっては古いソフトウェアを使い続けることになります。これはメリットであり、デメリットでもあります。 安定板でも新しいパッケージを使いたい、という要望に応えたものがbackportsです。かつてはwww.backports.orgで非公式サービスとして提供されていましたが、現在では公式なものとして扱われています。 どのようにしてbackportsにパッケージをアップロードするのかは、http://backports.debian.org/Contribute/に基本的にはすべて記述されています。ここでは実体験を交えて説明します。 ACL(Access Contorol List)への追加リクエスト Debian開発者であれば、backportsのACLに自分のIDを追加してもらうだけでアップロードができるようになります。ACLの追加は自力ではできないので、RT(Request Tracker)にチケットを作成してリクエストをします。 チケットの作成はメールで行います。backports@rt.debian.orgあてに”Debian RT”という文字列を含んだメールを送ることで、その内容がチケットになります。以下は私が出したメールの例です backportsに関する情報を得るために、debian-backports MLも購読しておきましょう。 さて、チケットを作って待つこと一週間、何も動きがありませんでした。催促の意味を込めて、次のようなメールをMLに投げました。 するとすぐACLに追加され、チケットはresolvされました。これでdebian/changelogのdistributionの項目に”wheezy-backports”などとしたパッケージを通常のincomingサーバーにアップロードすれば、backportsに登録されるようになります。 Debian開発者ではない人がアップロードをしたい場合は、sponsorを探す必要があります。debian-backports MLでsponsorを募集してみましょう。アップロード先にはhttp://mentors.debian.net/等を利用しましょう。 パッケージの作成 いよいよパッケージのbackportをやります。まず対象となるソフトのソースを入手しましょう。 dgetはdpkg-sourceまで実行してソースコードを展開してくれるので、次はdebian/changelogを更新します。dchには親切にも–bpoというbackportsのポリシーに合わせてバージョン番号を上げる機能がついているので、これを使います。 これで自動生成されるエントリーは以下のようになります。wheezyのdchはデフォルトでsqueeze向けのbpo情報を埋め込みます。 今回はwheezy向けにパッケージを作るので、バージョンとディストリビューションを修正します。 bpo60+1をbpo+72と、現在のwheezyのバージョン番号に合わせました。ディストリビューションもsqueeze-backportsからwheezy-backportsに変えました。 さて、実際にビルドしてみましょう。ビルドには、きれいな(純粋にwheezyのパッケージだけで構成された)環境の利用が推奨されています。pbuilder等の利用を検討しましょう。pbuilderの使い方については、今回ここでは行いません。 上記の例では、まず実環境でビルドしてdscファイルを生成し、それをもとにpbuilderでビルドを行っています。これでビルドに成功すれば、晴れて完成です。 足りないパッケージも作る 完成に見えたこのbackports用パッケージですが、実はこれだけではwheezyで動きません。mikutterのビルド自体はwheezyでできるのですが、インストールしてみといくつかのパッケージがwheezyに存在しないため、エラーになります。 ruby-addressableとruby-oauthはwheezyにもあるようですが。残りは存在しないようです。足りないパッケージを同様にしてbackport化しましょう。 debuildを実行するときには、-Fオプションを忘れないようにしましょう。初回のアップロード時にはupstreamのソースコードも必要だからです。 一通りのパッケージをインストールし、動作することが確認できたら、いよいよアップロードです。 stableが大好きな皆さんはbackportsを活用してゆきましょう。
Month: 12月 2013
git-builpackageを使う(Debian/Ubuntu JP Advent Calendar 2013)
これはDebian/Ubuntu JP Advent Calendar 2013 11日目の記事です。 Debianではパッケージを管理する際に、オリジナルのソースコードの上にdebianというディレクトリを作成し、その下にDebian固有のパッケージングに関する情報を記録してゆくようになっています。 かつてはこのファイルの管理はそう大変なことではありませんでした。しかし現在のDebianはoldstable, stable, testing, unstableという4つ(場合によってはexperimentalを含めた5つ)のdistributionを同時に管理しなければなりません。こうなると、やはりバージョンコントロールシステムが使いたくなるところです。 そのためのパッケージのひとつがgit-buildpackageです。名前の通りSCMにgitを使います。この記事ではその解説を行います。他にもsvnやcvs, bzrに対応したものがありますが、それぞれ設計思想から異なるのでここでは触れません。個人的にはsvn-buildpackageも使ってはいます。 ソースコードのインポート 一番最初に行うのは、すでにあるdeb用ソースコード一式のインポートです。これにはgit-import-dscコマンド(あるいはgit-import-dscs)を使います。 これでパッケージ名(この場合hallo)のディレクトリが作成され、そこがgitリポジトリになります このようにインポートされたdebianバージョンとupstreamのタグが作成されます。内容を更新し、新しいバージョンをリリースする際には同様に新しいdebianバージョンのtagを生成することになります。 変更 適当に変更をしてみます。このあたりは普通のgitリポジトリを扱うのと変わりはありません。 テストビルド 修正をコミットする前にテストビルドをするには、git-buildpackage build –git-ignore-newを実行します。–git-ignore-newオプション以外はdebuildと同じです。 問題がなければ、親ディレクトリにパッケージと各種ファイルが生成されます。これでよいと思ったら普通にgit commitしましょう。 リリース向けビルド リリース用のビルドは–git-tagオプションを付けることでできます 新しく作ったdebian versionのタグができていることが確認できます。 参考 PackagingWithGit (Debian Wiki)
HTMLタグを含むpoファイルからプレーンテキストにまで加工して形態素解析にかけてみてtypo等を見つける (Doc-ja Advent Calendar 2013)
これはDoc-ja Advent Calendar 2013 5日目の記事です。 www.gnu.orgでは、現在GNU website Japanese Translation Teamにてチーム体制でwebの翻訳を進めています。実態はほとんどgniibeさん一人で、私は今のところ翻訳チェックぐらいしかできていませんが… gnu.orgのwebはメッセージの中にHTMLタグも含んだ状態で、poファイルによって管理されています。レビューをする上では、なかなか扱いにくい形式です。 そこで、私は一度poから日本語訳文のテキストを生成し、もう少し見やすくした状態でレビューをしています。この記事では、その方法を紹介します さらに、結果を形態素解析にかければ、若干typo等が見つけやすくなります 今時の形態素解析器はできるだけ細かく分解する方向の実装・辞書が多いので、KAKASIなどを使った方がよいかもしれません。