パッケージにアップロード権限をつけてもらう
この記事は、Debian/Ubuntu JP Advent Calendar 2012 の何日目かの記事です。
2013 年の 11 月末から、Debian Maintainer (DM) によるパッケージアップロードの権限付与方法が変更されました。
通常、DM は自力でパッケージを Debian 公式アーカイブにアップロードすることはできず、Debian Developer (DD) にスポンサーとして代理アップロードしてもうら必要があります。
これまでは、debian/control ファイルに DM-Upload-Allowed (DMUA) フィールドを記述したパッケージを、スポンサーの DD に代理アップロードしてもらうことで、そのパッケージに限ってはそれ以後の自力アップロードができるようになっていました。
今回の変更により、DMUA フィールドは廃止され、debian/control に記述があろうとなかろうと意味をもたなくなりました。これからは、許可情報はパッケージ自体ではなくアーカイブサーバ側に移されており、そのデータを更新するには、dak コマンドを使用することになります。
dak コマンドは、所定のフォーマットで作成したテキストファイルをアーカイブにアップロードすることで実行されますので、やはりアップロード自体は DD に依頼する必要があります。
Archive: ftp.debian.org Uploader: DD のメールアドレス Action: dm Fingerprint: DM の GPG フィンガープリント Allow: パッケージ名 (スペース区切りで複数可)
上記の通り、書式自体はとても簡単なので、DM が依頼する時は単純に自分のフィンガープリントと対象のパッケージ名だけを伝えるだけで十分かもしれません。ただ、DD 本人はこの変更の当事者ではないので、新しい dak コマンドのことをそもそも知らない可能性もあります。
ですので、依頼する場合は、上記のフォーマットをつけた上で、「gpg 署名してアップロード」することを依頼するとスムーズになると思います。最初の debian-devel-announce のリンクを付記しておいてもよいでしょう。
依頼を受けた DD は、依頼内容通り権限をつけてよいと判断したら、dak コマンドのファイルに gpg 署名したものを、dput コマンドなどを使ってアーカイブにアップロードすることになります。
アーカイブ上でコマンドが無事実行されると、次のような結果通知メールが、DD と DM に送付されますので、内容を確認しておきましょう。
Subject: Results of processing (DD の名前)-(適当な数字).dak-commands > Action: dm > Fingerprint: C11CA58C0175C240D58C30C8D27DDE1140A2F113 > Allow: mypackage Fingerprint: C11CA58C0175C240D58C30C8D27DDE1140A2F113 Uid: lurdan@gmail.com Allowed: mypackage
では皆さま、年末年始も happy hacking!
puppet リファレンスを emacs でひく
最近年をとったせいか、細かいことはすぐに忘れてしまうようになりました。
そんなわけで、puppet の manifest を書いていてよく遭遇する、「このリソースで使えるパラメータって何だっけ」と思う瞬間をemacs にサポートさせることにしました。
puppetlabs から puppet-mode がリリースされているので、それに付け加えるような形にしています。
https://github.com/lurdan/puppet-syntax-emacs
ロードパスの通ったところに github から clone してください。ちょっと準備が必要なので、まずは WWW::Mechanize と Web::Scraper を使える perl を用意して、次のコマンドを実行してください。
$ mkdir ~/.emacs.d/tmp $ ./puppet-doc-indexer.pl > ~/.emacs.d/tmp/puppet-doc-index.el
これによって、キーワードとその URL の対応データが作成されます。
次に .emacs ですが、私の設定は、ほぼ下記のような感じです。使うだけなら require してM-x puppet-doc でもいいのですが、w3m と popwin も組合せた方が便利かと思います。
(require 'puppet-mode) (require 'puppet-flymake) (require 'puppet-doc) ;; Ctrl + F1 でドキュメントを表示 (add-hook 'puppet-mode-hook '(lambda () (define-key puppet-mode-map (kbd "<C-f1>") 'puppet-doc) )) ;; ドキュメントの表示は popwin-w3m で行う (require 'popwin-w3m) (defadvice puppet-doc (around puppet-doc-popwin-w3m activate) (let ((browse-url-browser-function 'popwin:w3m-browse-url)) ad-do-it)) (push '("^http://docs.puppetlabs.com/references/latest/.*$" :height 0.4) popwin:w3m-special-display-config)
手前味噌ですが、以前書いた flymake 用の設定とこれを組み合わせることで、かなり気持ちよくpuppet manifest を書いてくことができます。emacs で puppet 書いてる人が世の中にどれくらいいるというのか……という思いもありますが、該当する方は一度お試しください。
いつになるかはわかりませんが、puppet doc -rdoc コマンドで作成した in-house resource の参照もできるようにしたいと思います。便利に読めるようになれば、ドキュメントを書くモチベーションにつながる、はず……多分……きっと……。
C なんて読めなくても succor.el を使ってみる
kansai-emacs#x04 に参加して、r_takaishi さんの succor.el に感銘を受けたので、頑張って手元で使えるようにセットアップしてみました。
succor.el というのは、ひらメソッドによるコードリーディングのメモを emacs + org-modeでつけることができるようにする、というもので、必要なものは、
です。詳細は r_takaishi さんのサイトでうどん食べればわかります。
global の exuberant ctags プラグインを有効化する
succor.el では global の GTAGS を利用しているのですが、残念ながら、global は対応している言語がとても切ない感じで、私が読みたいコードには使えません。
次善の策として、global のプラグイン機能で exuberant ctags を流用できるようにしてみることにします。
ただ、残念なことに debian に入っている global はバージョンが古く、しかもプラグインが有効になっていないので、パッケージを作り直す必要があります。
といっても、configure に --with-exuberant-ctags=/usr/bin/ctags-exuberant を追加してリビルドするだけ (というと語弊があるけど) なので簡単です。私は global-6.1 版としてパッケージを作り直しました。
パッケージができたらおもむろにインストールし、/usr/share/doc/global から gtags.conf を適当なところ (ここでは $HOME) にコピーすれば準備完了です。
cd cp /usr/share/doc/global/examples/gtags.conf.gz $HOME gunzip gtags.conf.gz
プラグインを利用して GTAGS を作成するには、読みたいコードのツリーに移動して、
gtags --gtagsconf=$HOME/gtags.conf --gtagslabel=exuberant-ctags
とすれば OK です。私は puppet のツリーで試してみましたが、ぱっと見た感じでは問題なく作成されているようです。
succor.el の設定
基本的な設定は succor.el に付属の README にも書かれていますが、そのままだと、手元ではうまく動いてくれませんでした。理由はよくわからないのですが、ノートを保存するディレクトリとして、コメント ("ノートを保存するディレクトリ") を使おうとするんですよね。というわけで、とりあえずこんな感じにしてみました。
;(auto-install-from-url "https://github.com/takaishi/succor/raw/master/succor.el") (autoload-if-found 'succor-mode "succor" "" t) ;ノートを保存するディレクトリ (setq *succor-directory* (expand-file-name "~/.succor/")) ;ノートファイルが使う拡張子 (setq *succor-file-extension* ".org") ;(setq *succor-current-project* nil) ;(setq *succor-work-directory* nil) ;(setq *succor-note-window* nil) (setq gtags-mode-hook '(succor-mode))
普通はファイルの拡張子別にフックをかけて gtags-mode を有効化するものらしいですが、私の場合は今のところ succor.el を使う時 = global を使う時、なので、gtags-mode にフックをかけて succor-mode を有効化するようにしてあります。
succor-mode を呼んだときに gtags-mode を自動で、の方が自然かなぁとも思うのですが、その方針だとうまく動かせなかったので、gtags-mode が提供している hook を利用する方法に逃げました。
また、最初の使用時に ~/.succor が存在しない場合にディレクトリが作れなかったので、断腸の思いで少しだけ本体にも手を入れました。
diff --git a/succor.el b/succor.el index f7cbfac..62cf3f6 100644 --- a/succor.el +++ b/succor.el @@ -43,7 +43,7 @@ (setq *succor-work-directory* (concat *succor-directory* *succor-current-project* "/")) (unless (file-exists-p *succor-work-directory*) - (make-directory *succor-work-directory*)) + (make-directory *succor-work-directory* t)) (ad-activate-regexp "gtags-find-tag-after-hook") (ad-activate-regexp "gtags-pop-stack-after-hook")))
しばらくコードを読むときはこれを使ってみて、succor.el 的な exuberant ctags の互換性を試してみようと思います。
C-c C-r succor-capture (現在行についてノートをとる)
M-t gtags-find-tag (関数にジャンプしてノートを開く)
C-t gtags-pop-stack (関数にジャンプしてノートを開く)
yaskkserv パッケージの更新
yaskkserv の開発元で google japanese input へのプロキシ機能を追加するアップデートが行われました。ということで、早速 (sid の) パッケージを更新してみました。
手元で簡単に試しただけですが、google japanese input へのプロキシはなかなか便利で、辞書で見つからなかった単語をうまく変換してくれます。みなさんも是非使ってみてください。
さて、パッケージの更新に際して、yaskkserv の辞書設定方法 (/etc/default/yaskkserv の記述方法) を少し変更しました。
ざっくりとした変更内容は下記の通りです：
- パッケージされた辞書とユーザ辞書の指定を分離
- update-skkdic-yaskkserv がユーザ辞書も自動で更新
基本的には、/etc/default/yaskkserv に定義しているシェル変数をあれこれ変更するだけなのですが、パッケージの更新時によしなにマージされたりするわけではないので、これまでに激しくカスタマイズしている方は注意が必要です。
(apt-get の前に /etc/default/yaskkserv をバックアップしておいて、パッケージが新版のファイルと置きかえた後で手調整するのが無難かと思います)
パッケージ辞書の指定
変数名を PKG_DICS に変更しました。指定方法はこれまでと同じです。
ユーザ辞書の指定
新しく、LOCAL_DICS 変数を追加しました。ユーザ辞書を使う場合は、この変数の値として辞書のソースファイルへのフルパスを列挙するようにしてください。これまで、DICS にユーザ辞書を設定していた人は、設定をこちらに移動するとよいでしょう。
update-skkdic-yaskkserv の挙動
これまでは、パッケージ辞書の変換だけを行っていましたが、/etc/default/yaskkserv を読んで、設定されているユーザ辞書もあわせて変換するようにしました。
一度ユーザ辞書を指定しておけば、パッケージの更新時に自動的に再生成されますし、ユーザ辞書を更新した後で update-skkdic-yaskkserv を手動で実行すればすぐに反映されますので、多少はラクになるのではないかと思います。
アップロードの壁
少しずつバグもたまってきていたので、手持ちのパッケージをちょこちょこと直して更新しようとしてるのだけど、
どれもこれもうまくいかなくて困ったなぁ、という話。しばらく放置して頭冷した方がいいのかなぁと思いつつ、
そうすると単に頭から抜けていくだけだよなという気もするのでもにょもにょ。
とりあえず、自分の状況整理もかねて、現状をメモしておく。解決したら追記するつもり。
yaskkserv の場合
せっかく DM になったんだし、更新は自分で put してみよう、と思ったのが運のつき……だったのかはともかく、我ながらアホなミス連発で今のところまだアップロードできず。
経過はこんな感じ。
- 1st try
- changelog のメールアドレスが普段のものでなくて、自動生成された USER@localhost になっているのを見逃していた。当然アップロードは REJECT された
- 2nd try
- changelog を修正して再挑戦。なぜか dupload がコケて upload できず。キューに 0 byte のゴミファイルが残ってにっちもさっちもいかなくなる。wimax 経由で接続が不安定だった？
- 3rd try
- ゴミを消してもらって(？)、今度は自宅の回線で試行するも、やはり dupload がこけて失敗。キューにゴミが (ry
dupload.conf の設定を mentors と比べると、Passive FTP の設定有無 (mentors にはつけてた) だけが違う。のでこれが原因か？ でもそれだと最初に (REJECT されたものの) アップロードできた理由がわからなくなるなぁ。
20110715追記
ゴミを消してもらって、Passive FTP をつけることで、アップロード自体はようやく成功した。でも謎の理由で REJECT されるので、まだキューには入ってくれませんな。現状でも機能はするしもういいか、という気分。
yatex の場合
結構前に mentors に放り込んではいたものに追加のバグ修正をほどこして、メンターにアップロード依頼して終わり、というつもりでいたら。
- 1st try
- mentors に upload していた orig.tar.gz のチェックサムが以前のものと違うということで REJECT。パッケージいじってる時にどこかで間違えて orig.tar.gz を再生成してしまってたらしい (どこでやらかしたかは不明)
- 2nd try
- アーカイブに入っている orig.tar.gz を apt-get source して、もう一度ビルドし直したものを mentors に再 upload。メンターから「なおってない」とダメ出しをくらう
何がマズいのかわからん orz
20110715追記
わざわざエントリまでして頂いたので、細かく履歴をとって再挑戦。
~/deb $ ls | grep yatex yatex ~/deb $ apt-get source yatex パッケージリストを読み込んでいます... 完了 依存関係ツリーを作成しています 状態情報を読み取っています... 完了 注意: 'yatex' パッケージは以下の場所の 'Git' バージョン制御システムで保守されています: git://git.debian.org/users/lurdan-guest/yatex.git 376 kB のソースアーカイブを取得する必要があります。 取得:1 http://ftp.jp.debian.org/debian/ sid/main yatex 1.74+dfsg1-1 (dsc) [1,218 B] 取得:2 http://ftp.jp.debian.org/debian/ sid/main yatex 1.74+dfsg1-1 (tar) [362 kB] 取得:3 http://ftp.jp.debian.org/debian/ sid/main yatex 1.74+dfsg1-1 (diff) [12.9 kB] 376 kB を 0秒 で取得しました (970 kB/s) dpkg-source: info: extracting yatex in yatex-1.74+dfsg1 dpkg-source: info: unpacking yatex_1.74+dfsg1.orig.tar.gz dpkg-source: info: unpacking yatex_1.74+dfsg1-1.debian.tar.gz dpkg-source: info: applying debianize-dfsg dpkg-source: info: applying debianize-fhs dpkg-source: info: applying debianize-iceweasel dpkg-source: info: applying info-fix dpkg-source: info: applying info-dir ~/deb $ rm -rf yatex-1.74+dfsg1/ yatex_1.74+dfsg1-1.d* ~/deb $ ls | grep yatex yatex yatex_1.74+dfsg1.orig.tar.gz ~/deb $ md5sum yatex_1.74+dfsg1.orig.tar.gz ea8123d9972a2ac8c9a41633dd2a03cb yatex_1.74+dfsg1.orig.tar.gz ~/deb $ sha1sum yatex_1.74+dfsg1.orig.tar.gz bb57f463cda40f7d24fd2a5bcaba0a385f91ce39 yatex_1.74+dfsg1.orig.tar.gz ~/deb $ sha256sum yatex_1.74+dfsg1.orig.tar.gz 190d0ff572f50191c5c48b3707aa1d7f2ce370cf79bc4122b9f67cfd0ea28926 yatex_1.74+dfsg1.orig.tar.gz ~/deb $ cd yatex ~/deb/yatex $ debuild -I.git -i.git -sa -k40a2f113 snip ~/deb/yatex $ cd .. ~/deb $ ls | grep yatex yatex yatex_1.74+dfsg1-2.debian.tar.gz yatex_1.74+dfsg1-2.dsc yatex_1.74+dfsg1-2_all.deb yatex_1.74+dfsg1-2_amd64.build yatex_1.74+dfsg1-2_amd64.changes yatex_1.74+dfsg1.orig.tar.gz ~/deb $ md5sum yatex_1.74+dfsg1.orig.tar.gz ea8123d9972a2ac8c9a41633dd2a03cb yatex_1.74+dfsg1.orig.tar.gz ~/deb $ sha1sum yatex_1.74+dfsg1.orig.tar.gz bb57f463cda40f7d24fd2a5bcaba0a385f91ce39 yatex_1.74+dfsg1.orig.tar.gz ~/deb $ sha256sum yatex_1.74+dfsg1.orig.tar.gz 190d0ff572f50191c5c48b3707aa1d7f2ce370cf79bc4122b9f67cfd0ea28926 yatex_1.74+dfsg1.orig.tar.gz ~/deb $ grep orig.tar.gz yatex_1.74+dfsg1-2.dsc bb57f463cda40f7d24fd2a5bcaba0a385f91ce39 362256 yatex_1.74+dfsg1.orig.tar.gz 190d0ff572f50191c5c48b3707aa1d7f2ce370cf79bc4122b9f67cfd0ea28926 362256 yatex_1.74+dfsg1.orig.tar.gz ea8123d9972a2ac8c9a41633dd2a03cb 362256 yatex_1.74+dfsg1.orig.tar.gz ~/deb $
うんうん、ビルドの前後でも変化ないし、.dsc ファイルの記載とも一致してますね。では、ということで mentors に put。
~/deb $ dupload -t mentors yatex_1.74+dfsg1-2_amd64.changes dupload note: no announcement will be sent. Checking signatures before upload......signatures are ok Uploading (ftp) to mentors.debian.net:/ [ job yatex_1.74+dfsg1-2_amd64 from yatex_1.74+dfsg1-2_amd64.changes yatex_1.74+dfsg1-2_all.deb, size ok, md5sum ok, sha1sum ok, sha256sum ok yatex_1.74+dfsg1-2.debian.tar.gz, size ok, md5sum ok, sha1sum ok, sha256sum ok yatex_1.74+dfsg1.orig.tar.gz, size ok, md5sum ok, sha1sum ok, sha256sum ok yatex_1.74+dfsg1-2.dsc, size ok, md5sum ok, sha1sum ok, sha256sum ok yatex_1.74+dfsg1-2_amd64.changes ok ] Uploading (ftp) to mentors (mentors.debian.net) + FTP passive mode selected [ Uploading job yatex_1.74+dfsg1-2_amd64 yatex_1.74+dfsg1-2_all.deb 257.2 kB, ok (3 s, 85.74 kB/s) yatex_1.74+dfsg1-2.debian.tar.gz 12.8 kB, ok (2 s, 6.39 kB/s) yatex_1.74+dfsg1.orig.tar.gz 353.8 kB, ok (4 s, 88.44 kB/s) yatex_1.74+dfsg1-2.dsc 1.8 kB, ok (1 s, 1.85 kB/s) yatex_1.74+dfsg1-2_amd64.changes 2.6 kB, ok (2 s, 1.30 kB/s) ] ~/deb $ echo $? 0 ~/deb $
よしよし、うまくいったね。mentors.debian.net を見てもちゃんと反映されてる。ちょっと食事に外出して、戻ったら
わざわざ反応をくれた Ansgar さんへの返事もかねてチェック依頼のメールを書こう。
……というわけでメールした。後は祈るばかり。
emacs-calfw の場合
ITP 出して、メンターとやりとりの上ほぼ完成したかと思ったらそうは問屋が卸してくれないわけで。
- 1st try
- 最初のバージョンを作成して mentors に upload。いろいろ改善コメントをもらう
- 2nd try
- コメント内容を反映するなどして修正したバージョンを mentors に upload ……しようとするも、通知メールも来ないしリストにも出てこない
dupload は upload 無事完了したぜって顔をしてるので、どうも mentors 側で処理されていないっぽい……？ でも yatex や yaskkserv は今でも mentors に問題なく upload できるのに、emacs-calfw だけ、しかも何の通知もなく闇に消えるのはドユコト……？
というわけでこれも何がマズいのかわからん orz
20110715追記
今日試したらちゃんと mentors 側での処理も走った模様。さっぱり原因がわからん……。けど、ひとまずメンターのチェック待ち。
flymake for puppet
少し探してみたけど見つからなかったので書いてみた。
puppet のメッセージがエスケープシーケンスを含んでいるのと、チェック用コマンドの生成で少しハマったけど、とりあえず望み通りの動作はするようになった。
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;; flymake for puppet (require 'flymake) (defcustom flymake-puppet-err-line-patterns '(("err: Could not parse for environment .+: \\(.+\\) at \\(.+\\):\\([0-9]+\\)" 2 3 nil 1)) "Regexp matching Puppet error messages.") (defconst flymake-allowed-puppet-file-name-masks '(("\\.pp$" flymake-puppet-init)) "Filename extensions that switch on flymake-shell mode syntax checks.") (defun flymake-puppet-init () (let* ((temp-file (flymake-init-create-temp-buffer-copy 'flymake-create-temp-inplace)) (local-file (file-relative-name temp-file (file-name-directory buffer-file-name)))) (list "puppet" (list "parser" "validate" local-file)))) ;2.7 or later ; (list "puppet" (list "--parseonly" local-file)))) ; 2.6 (defun flymake-puppet-load () (interactive) (defadvice flymake-post-syntax-check (before flymake-force-check-was-interrupted) (setq flymake-check-was-interrupted t)) (ad-activate 'flymake-post-syntax-check) (setq flymake-allowed-file-name-masks flymake-allowed-puppet-file-name-masks) (setq flymake-err-line-patterns flymake-puppet-err-line-patterns) (flymake-mode t)) (add-hook 'puppet-mode-hook 'flymake-puppet-load)
H な TeX のエラーに出会った時の対処
dvipdfmx を使って TeX 文書を PDF に変換していると、ghostscript がアップデートされるたびに高確率で H なエラーに遭遇する。TeX エロい。*1
世間でも同様の目にあっている方は多数おられるようで、Free Dynamic DNS(DDNS) by POP3,IMAP4,FTP,HTTP-BASIC for Home Server, VPS | MyDNS.JPといった記録をありがたく参考にさせてもらうのだけど。
ただ、他のディストリならともかく、debian で /usr 配下のファイルを手編集とか邪道すぎてありえない、絶対他の場所で override できるはずだ、と思って探してみた。
まぁ予想通り /etc/texmf/ というディレクトリがあって、内容はこんな感じになっている。
% ls /etc/texmf
dvi2ps dvips hyphen.d tex texmf.cnf updmap.d xdvi
dvipdfm dvipsj language.d texdoc texmf.cnf.ucf-old vfontmap.d
dvipdfmx fmt.d metafont texdoctk texmf.d web2c
よしよし texmf.cnf だな、と思いかけたものの、texmf.d があるので、「あぁ、texmf.cnf は自動生成か、あぶないあぶない変更したはずの設定を上書きされて発狂するところだった」と気付く。
% grep CMAPFONTS /etc/texmf/texmf.d/* 85Misc.cnf:CMAPFONTS = .;$TEXMF/fonts/cmap//
% sudo update-texmf[TAB連打] update-texmf update-texmf-config
なるほど。
というわけで、85Misc.cnf に ghostscript の font パスを追記してから、
sudo update-texmf-config
して、無事解決することができた。TeX に愛があれば /usr/share/doc や man も確認しとくべきなんだろうけど……まぁない袖はふれないよね。
