CONFIG_SND_SOC_INTEL_BYT_MAX98090_MACH=mはすでにdeprecatedで代わりの奴が有効になっているのをコメント追加。whizzytexのパッチをもうひとつ取り込み忘れてたので作業。まだtestingに前のが落ちてないので待ち。昨日のjdパッケージの削除依頼が実行されてた。早いなー。ruby-bcatパッケージの削除もその日のうちだったし。
systemdの脆弱性の話で「gccの-fstack-clash-protectionオプション指定してるディストリビューションは影響受けない」という話があって「これ、適用しないの？」と聞いたら該当のバグ登録を教えてもらった。subscribeして様子見しよう。
ubuntu-keyringパッケージのdebcont templateのレビューを反映した。なるほどなー
ubuntu-keyring、ubuntu-archive-keyringをtransitional package にすべきと言われてなるほどなーとなったので更新して再度NEW queueへ
grcompiler、4.2.7以降のがテストこけちゃうのでtest failureをreportした
curlが最新にならないかなぁ、というつぶやきを見かけたので、前のBTSのpushの意味も兼ねてバグ登録した
nadokaが古いままでwatchもエラーになっていたので、重い腰を上げて更新しておいた。前のメンテナの安井さんにも連絡済み。
whizzytexのパッチを取り込み忘れてたので作業。まだtestingに前のが落ちてないので待ち。
jruby-joniパッケージがFTBFSになってる？なぜだ… org.jcodings.exception.CharacterPropertyException: invalid character property name <graphemeclusterbreak=emodifier>と出てくるのでその辺りから検索したけど、よくわからんよね…issue登録だけしておいた
$ grep emodifier -r ./
./src/org/joni/Parser.java: static final byte[]Grapheme_Cluster_Break_E_Modifier = "graphemeclusterbreak=emodifier".getBytes();
気になったのでgem2debのテンプレートからruby-interpreterを削除するMRを送っておいた
武藤さんがDDを引退されたので、その引き継ぎとしてmltermパッケージの今後のsponsor uploadを引き受けることになった。
whizzytexパッケージをアップロード。作業自体は以前にあらかたしていた。
問題だったのはautopkgtest。ファイルを開くだけでwhizzytex-modeを実行しないとテストの意味がないのでemacs --script test.el test.texのようにしてtest.elの中で以下のようにするなどした。
(find-file (nth 0 command-line-args-left))
(whizzytex-mode 1)
その後、どうやっても1つ目のテスト以外コケるな…と思ったら、もともとのtestfileファイルにtypoがあってtest.texとすべきところをtest.txtになってて、存在しないファイルなのでコケるという…ターミナル中で実行した時はbashの補完だったから気づかなかったよ…
ruby-bcatへの依存、ずっと前から要らなくなっていたようだ…見落としてた。これでCIが通るようになるはず。
ruby-bcatをRMしてもいいんじゃないか。ざっくりapt-rdependsした結果では依存はないし、codesearch.debian.netの検索結果もそれらしいものはない。grep-dctrlでも同様なので、RM依頼を登録$ grep-dctrl -FBuild-Depends ruby-bcat -sPackage /var/lib/apt/lists/*Sources
Package: ruby-aruba
libmojo-ioloop-readwriteprocess-perlパッケージが入ってくれたので、手元のos-autoinstをmaster HEADに更新。予想通りだが、i386でのエラーは変わらず…。
ubuntu-keyringパッケージのdebconf template査読が返ってきてたので、mergeしないと…。
だいぶ前にjdがクラッシュするよ、とlaunchpadの方でレポートがあった（けど、debianからsyncしてるだけだからあんまり見ないんだよね、launchpad…ログインするのも手間だし）のだけど、その後のreplyに何の返答もない。それでいて「Debian/Ubuntuのパッケージはメンテされてない」とか言いふらすのは止めてほしいよね…（こちらとしては、そもそも2ch（今は5chなんだっけ）の方で仕様変更が云々あって見ない＆使わない状態が続いてるのに加えて、upstreamに動きがないためにチェックする機会も無かったのだ）。で、forkだと思しきrepositoryの方では名称変更が検討されてたので、パッケージにしたいなーというのは伝えておいた。
Valid-Until: Tue, 15 Jan 2019 20:29:52 UTCのようにValid-Untilがあるのが普通と思ったが、Stretchだとないな…「存在しなければOKを返す」が必要そうだ。git-buildpackageによるpatchへの変更が入ってた…取り除いてsecurity-masterへアップロード。snapperパッケージのbug triage
moreinfoタグ付けて「もっと詳しくー」と書いたのに何も有用な話が無いバグを閉じたdebootstrapの変更をpush「test/ 以下で実行されることを前提として, 相対パスで必要なライブラリを読み込んでいたりする gem とか?」ということやね。
ruby-netrcパッケージについてrequire_relative に書き換えて実施してみる。あとで結果確認しよう…昨日のos-autoinst、対象アーキテクチャを絞ったつもりで忘れてた…アップロード…ぬぉぉ i386アーキテクチャでFAIL: 01-test_needle.tとテストに失敗するぞ…、手元のsbuildでも同じだ…以前は問題なく通ってたのにどうなってんだ？
not ok 14 - found area is the original one too
# Failed test 'found area is the original one too'
# at ./01-test_needle.t line 73.
# got: '944'
# expected: '108'
うーん。
とはいえ、upstreamでは直ってるかもしれないよな、と１年間タグが打たれてないupstream HEADをmergeしてビルドする…とテストがコケまくる。一つは依存関係のパッケージが無かったのでいれたのだけど、もう一つのMojo::IOLoop::ReadWriteProcessはパッケージ自体がDebianのリポジトリにない…仕方がないからdh-make-perlで手元で作ってITP(intend to package)して、アップロードした。
で、libmojo-ioloop-readwriteprocess-perlパッケージをテスト環境のchrootに突っ込んでビルドの様子見るか…としたら、やっぱりFAIL: 03-testapi.tとエラーが出る。
^* matches null string many times in regex; marked by <-- HERE in m/^* <-- HERE \.t|^data\/tests\/*|^fake\/tests\/*/ at /usr/lib/x86_64-linux-gnu/perl5/5.28/Devel/Cover.pm line 379.
Can't locate Test/Exception.pm in @INC (you may need to install the Test::Exception module) (@INC contains: .. ../ppmclibs ../ppmclibs/blib/arch/auto/tinycv .. ../ppmclibs ../ppmclibs/blib/arch/auto/tinycv /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.28.1 /usr/local/share/perl/5.28.1 /usr/lib/x86_64-linux-gnu/perl5/5.28 /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl/5.28 /usr/share/perl/5.28 /usr/local/lib/site_perl /usr/lib/x86_64-linux-gnu/perl-base) at ./03-testapi.t line 14.
BEGIN failed--compilation aborted at ./03-testapi.t line 14.
FAIL 03-testapi.t (exit status: 2)
あー Test/Exception.pmが見つけられないのか。libtest-exception-perlパッケージを入れる…お、テストは全部通った！と思いきや
make check-local
make[4]: Entering directory '/build/os-autoinst-4.5.1527308405.8b586d5.20190104'
./tools/tidy --check
--- ./t/16-send_with_fd.t 2019-01-04 11:55:46.000000000 +0000
+++ ./t/16-send_with_fd.t.tdy 2019-01-06 13:43:40.463129038 +0000
@@ -33,7 +33,7 @@
shutdown($ask, 2);
my @cmsg = $msg->cmsghdr();
- my $fd = unpack('i', $cmsg[2]);
+ my $fd = unpack('i', $cmsg[2]);
POSIX::write($fd, $msg->buf(), 4)
|| die "Failed to write echo to pipe: $!";
RUN tools/tidy script before checkin
make[4]: *** [Makefile:1457: check-local] Error 1
なんじゃこりゃー。tools/tidyスクリプトによるチェックがcheck-localターゲットで走って、修正が加わってないのがエラーになるという…なんでupstream側で対処してないんだよ。もういい、今日はここまで。openSUSEのtrackerに報告しておく。ついでにtag打って、も。