青木さん、林さん
お返事どうもありがとうございます。
chrootは以前よく使っていたので、sbuildがやってることはなんとなく 想像つきます。ただちょっとsbuildコマンド経由での環境構築やパッケージ ビルドでつまずいてしまいました。コマンドを使いこなすにはもうちょっと 時間が必要そうです。
問題を林さんに特定していただいたので、今回は手っ取り早く、meson buildの Wrap dependency system[1]を使い、gi-docgen 2023.3 でのエラーを再現でき ました。libhinawa同様、libhinokoコード中の`Since: x.y.` となっている 箇所が問題でした。`Since: x.y` と末尾のピリオドを削ると、エラー抑制でき ました。
アップストリーム側のバグということで、近日中に新リリースを出そうと思い ます。ご協力どうもありがとうございました。
[1] https://mesonbuild.com/Wrap-dependency-system-manual.html
On Thu, Dec 14, 2023 at 07:22:34PM +0900, Kentaro Hayashi wrote:
林です。
2023年12月13日(水) 7:51 Takashi Sakamoto o-takashi@sakamocchi.jp:
坂本です。 (C.C. 林さん)
先日、libhinoko[1]というパッケージをITP[2]しまして、無事にスポンサーが 得られ、testing/ustableに収録されました[3]。それからしばらく経ってFTBFSの レポート[4]が届いてしまい、対応を検討しているところです。
想像するにビルドサーバーのパッケージ構成が変わり、libhinokoのビルドが エラーするようになったのだと考えています。ちょうど同じ時期にITPした libhinawaもFTBFS[6]してるっぽくて、ログをみると"gi-docgen 2023.3"が 原因っぽいなぁというところまでは検討がついてます。
gi-docgenでのバージョンのパースがどこかの時点でより厳密になったせいみたいです。
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1058535#10
例えば、libhinawaではsrc/hinawa_enum_types.hがひっかかっていました。 libhinawa 4.0.0-2で修正しています。
相談したいのは、このFTBFSをもたらしたパッケージ構成を手元でちょうど 再現する方法についてです。たぶんpbuilderを使うことになるのだと思うの ですが、「ちょうど再現する」というあたりで自信がないです。手順等 ご存知の方がいらっしゃいましたら、教えていただけると助かります。
再現自体は以下のような手順でできるかと思います。 ビルドログを見る限り、libhinawaと同じようにSince:のところをなおせばよいはず。
$ docker rum --rm -it debian:sid # apt install -y devscripts # sed -i -e 's/Types: deb/Types: deb deb-src/' /etc/apt/sources.list.d/debian.sources # apt update # apt build-dep -y libhinoko # apt source libhinoko # cd libhinoko-1.0.0 # debuild -us -uc
それでは。
Takashi Sakamoto