RC bug #688233 の対応として dpkg-maintscript-helper mv_conffile を使って upload。
結構大きく変えたし、もう数日 unstable で揉まれるまで unblock request は待っておこうかな。
mozc、uim-chewing の両方で対応していただけた。あとしばらく様子を見てアップグレードにかかわる BTS がなければ unblock request を出そう。
予想通りというかなんというか RC bug #688233 にちょっと問題があった。ローカルの新しいパッケージのアップグレードテストが piuparts でどうもうまくいかない。指摘されてることは再現できたけど、それがきちんと直せてるかどうかうまく調べられてない。
piuparts でローカルの新しいパッケージのアップグレードテストをするときの仕組みを考えてみた。
まず、/tmp/debian/ ディレクトリ以下に作成した新しいパッケージを置く。
% ls -la /tmp/debian
合計 17148
drwxr-xr-x 4 dai dai 980 10月 18 02:00 .
drwxrwxrwt 16 root root 480 10月 18 02:10 ..
-rw-r--r-- 1 dai dai 12996 10月 18 01:52 libuim-custom2_1.8.1-4_amd64.deb
-rw-r--r-- 1 dai dai 287084 10月 18 01:52 libuim-data_1.8.1-4_amd64.deb
-rw-r--r-- 1 dai dai 136774 10月 18 01:52 libuim-dev_1.8.1-4_amd64.deb
:
ダミーのレポジトリを作る。
for i in main contrib non-free; do
for j in sid squeeze; do
k=/tmp/debian/dists/${j}/${i}/binary-amd64
mkdir -p ${k}
touch ${k}/Packages
gzip ${k}/Packages
done
done
新しいパッケージ用の Packages ファイルを生成する。
cd /tmp/debian apt-ftparchive packages . | gzip -c >! ./dists/sid/main/binary-amd64/Packages.gz
これで piuparts を実行する。
sudo /bin/rm /tmp/libuim-data.log ; \
sudo piuparts \
--skip-logrotatefiles-test \
--warn-on-others \
--warn-on-leftovers-after-purge \
--no-eatmydata \
-b /var/cache/pbuilder/base-squeeze.tgz \
--list-installed-files \
-l /tmp/libuim-data.log \
--do-not-verify-signatures \
-m http://ftp.jp.debian.org/debian \
-m file:/tmp/debian \
--bindmount /tmp/debian \
-d squeeze \
-d sid \
--apt libuim-data=1:1.8.1-4
--do-not-verify-signatures : サインしていないレポジトリで停止してしまうことを防ぐ。
-m file:/tmp/debian --bindmonut /tmp/debian : chroot 内からレポジトリが見えるように。なお、/tmp/debian 以下を CWD とするプロセスがいた場合、kill されたうえに piuparts がエラーで終了することに注意。
本当はもっといいやりかたがあるような気がするけど...。
mv_conffile は移動先にもファイルがないといけないようなので(類例: #665813)、touch して作ることにして対処。けど、直前で uim-module-manager で作成してるはずなんだけどな。今度は piuparts でローカルの新しいパッケージのアップグレードテストをしたので大丈夫のはず。
先走って 1.8.2 と 1.8.3 を upstream ブランチに入れて master ブランチにマージしてしまっていたので、debian/1%1.8.1-3 タグから debian/1%1.8.1 ブランチを分岐してそちらを更新した。
今 testing は freeze されてるので、unstable からパッケージが自動で落ちることはない。unstable から testing にパッケージを入れるにはリリースチームに連絡して unblock してもらう必要がある。受け入れ可能なパッケージはかなり限定される。と、その決まりや手順はどこに書いてあるんだろうと探してようやく見つけた。> Wheezy Freeze Policy
unblock request を BTS に登録するには、
% reportbug release.debian.org
で 8 (unblock) を選択し、対象のパッケージとヴァージョンを入力すれば、テンプレートを作ってくれる。
Subject: unblock: uim/1:1.8.1-4 Package: release.debian.org User: release.debian.org@packages.debian.org Usertags: unblock Severity: normal Please unblock package uim (explain the reason for the unblock here) (include/attach the debdiff against the package in testing) unblock uim/1:1.8.1-4
理由を埋めて、debdiff を入れて送信すればいいのかな。debian-release に流れているメールや release.debian.org 仮想パッケージバグのレポートを見たところ、そんな感じでいいみたい。
これで uim 1:1.8.1-4 の unblock request を出すときに慌てないで済むかな。
unblock request 下調べ編のつづき。testing-proposed-updates に入れるには、
% reportbug release.debian.org
で 5 (pu) を選択し、対象のパッケージとヴァージョンを入力すれば、テンプレートを作ってくれる。
Subject: pu: package uim/1:1.8.1-4 Package: release.debian.org User: release.debian.org@packages.debian.org Usertags: pu Severity: normal (please explain the reason for this update here)
理由を埋めて、debdiff を入れて、Subject: と Usertags: の pu を tpu に変えて BTS に登録して、許可が出たら testing でビルドしてアップロードすればいいのかな。reportbug の選択肢に tpu があると思ったらなかったので。
uim 1:1.8.1-4 が 5日経ったので、unblock request 下調べ編 で調べた通り、#691218 で unblock request を出した。
ふと見たら im-config 0.18 が testing 入りしていたので、#300486 と Bug 39242 - no easy way to wait until uim-xim is ready を閉じた。
uim/uim/issues/13 にてもっともな理由が説明されたため #472515 を閉じた。
下調べ編と実践編を紹介してみた。> [RFC] pre approval unblock request (hyperestraier)
まず unstable に入れていい？と聞くときは通常の unblock request の Subject: に pre-approve をつけるといいみたい。
| 前 | 2012年 10月 |
次 | ||||
| 日 | 月 | 火 | 水 | 木 | 金 | 土 |
| 1 | 2 | 3 | 4 | 5 | 6 | |
| 7 | 8 | 9 | 10 | 11 | 12 | 13 |
| 14 | 15 | 16 | 17 | 18 | 19 | 20 |
| 21 | 22 | 23 | 24 | 25 | 26 | 27 |
| 28 | 29 | 30 | 31 | |||
[amd64 | audacious | comp | debian | gkrelluim | kip | misc | movie | research | rime | unicon | vdr | work | えふえふ]
書いてる人: dai
パッチ等(無保証)