Operation Normal ?

下記のパッケージを nora セクションに投入しました。

ibus-1.5.20-2

• ソースを 1.5.20 へ更新しました。

• 最初にビルドした際に、"IBus の設定" が日本語表示されないという問題が出ました。調べたところ、"IBus の設定" を起動するシェルスクリプトである /usr/bin/ibus-setup で、環境変数 IBUS_LOCALEDIR が正しく設定されていない事が原因だと判りました。なぜこれが正しく設定されていなかったのかは不明です。

  取りあえず当面の回避策として、ビルドオプションの '--localedir' を新たに追加して明示的にロケールディレクトリを指定することにしました。

下記のパッケージを nora セクションに投入しました。

jdim-0.1.0-7.20190304

• 最新のリビジョンを用いてビルドしました。
• "filezilla をインストールしている環境で gnutls 関係で問題が起きる可能性" で書いた経緯により、前版で適用していた TLS 証明書のエラー対策用のパッチを削除しました。

【 2019年7月6日 追記 】

filezilla-3.43.0-2 以降からソースコードからビルドしたものが提供されるようになったため、このエントリーで書いた問題は発生しなくなりました。

----- 追記ここまで -----

［現象］

filezilla をインストールしている環境では、gnutls を利用しているソフト（例: corebird, jdim）で TLS 証明書に関するエラーが発生する可能性があります。

下図は Twitter クライアントの corebird での例ですが、「受け付けられない TLS 証明書です」というエラーが発生して Twitter に全くアクセスできなくなっています。

［原因］

filezilla パッケージによってインストールされる /usr/lib/libgnutls.so.30 と、lib64gnutls30 パッケージによってインストールされている /usr/lib64/libgnutls.so.30 がコンフリクトするためです。

［対策］

以下のいずれかの方法で問題を回避できます。

• filezilla パッケージを削除する。
• filezilla パッケージによってインストールされた /usr/lib/libgnutls.so.30 を削除する。（これが無くても filezilla は正常に動作します。間違っても /usr/lib64/libgnutls.so.30 の方を削除しないこと！）
• 自前で filezilla をソースコードからビルドする。

［経緯＆考察＆愚痴］

冒頭で書いた corebird のエラーに、一昨日の夜に気が付きました。普段は wine 経由で Saezuri を使用しているので何時からこのエラーが発生していたのかは不明です。で、TLS 証明書絡みのエラーと言えば 先のエントリー で書いた JDim でも発生していたので、根本原因を突き止めるべく、仮想環境に新たに PCLinuxOS をインストールして調べてみました。

まず、インストール直後の環境では問題は発生しないことを確認。そこから私が日頃使っているアプリを一つ一つインストールしては問題が発生していないかを確認しながら環境を整えて行きました。結果、かなり時間がかかりましたが filezilla が原因であることを突き止めました。

ソースパッケージを調べるまで知らなかったのですが、PCLinuxOS の filezilla パッケージはソースコードからビルドしているのではなくて、開発元が 64bit Linux 用として配布している tar 玉を引っ張ってきてそのまま /usr 下に展開しています。それ故、tar 玉に同梱されている libgnutls.so.30 が /usr/lib 下に配置されることとなり、問題を引き起こす原因になりました。

さらに、filezilla パッケージでは後処理部分の %post が存在せず ldconfig コマンドが実行されない為、filezilla だけをインストールした直後には問題が発覚せず、その後に ldconfig を実行するパッケージをインストールした段階で初めて問題が表面化するという時限爆弾のオマケ付きです。

実際、上記の仮想環境での調査過程でも filezilla のインストール直後には気付かず、その後に幾つかのパッケージをインストールした段階で初めて問題が発覚したので、発覚直前にインストールした他のパッケージが原因ではないかと最初は疑ってしまいました。

なお、filezilla をインストールすると libgnutls.so.30 以外にも libgmp.so.10 , libhogweed.so.4 , libnettle.so.6 が /usr/lib 下に配置されますが、これらと同名のライブラリが lib64gmp10 と lib64nettle6 のパッケージがインストールされている環境では /usr/lib64 下に存在しており、libgnutls.so.30 と同様にコンフリクトする状態となります。これがどのような問題を引き起こすのか、あるいは起こさないのかは不明ですが、予防措置として私はこれらのファイルも削除しました。（削除しても filezilla は問題なく動作しています）

また、JDim で TLS 証明書のエラーが出た時には filezilla パッケージが原因だとは夢にも考えていなかったので、JDim 側の問題ではないのにもかかわらず、JDim の開発者のお一人の ma8ma さんには --with-default-trust-store-file オプションの追加 という労力を強いることになってしまったことを心より深くお詫び致します。

PCLinuxOS では filezilla の他にも Firefox や LibreOffice などのようにビルドに大きなリソースを要するパッケージではソースコードからのビルドは行なわずに、開発元が配布しているバイナリーな tar 玉を利用しています。開発にかかわる人的リソースが少ない零細ディストリビューションではそれも有りかなと個人的には思っています。

ただしそれは「他の部分に無用な影響を及ぼさにように配慮した上で」という前提条件付きなはずです。今回の filezilla に関して言えば、tar 玉の展開先を /usr ではなくて /usr/local にしておけば、あるいはライブラリのコンフリクトについてもう少しだけ配慮してもらえていたら問題は発生しなかったはずで非常に残念です。

下記のパッケージを nora セクションに投入しました。

jdim-0.1.0-6.20190224

• 最新のリビジョンを用いてビルドしました。

• 環境によっては https://github.com/ https://i.imgur.com/ 上の画像を開こうとした際に、
  JDSSL::connect(gnutls) *** Handshake failed: Error in the certificate verification
  という gnutls 絡みのエラーが出るという問題に対処するための応急的なパッチを適用しました。

  このパッチでは、PCLinuxOS でインストールされている x.509 証明書の位置 (/etc/pki/tls/cert.pem) を明示的に指定することでエラーを回避しています。

  なおこのパッチは、
  JDim GnuTLSを使って自前で用意した証明書でhostnameを検証するパッチ
  を基にして作成しました。

下記のパッケージを nora セクションに投入しました。

marisa-0.2.4-3

• libkkc や libkkc-data に必要となる marisa ですが、ruby が 2.6.1 へ更新された影響により公式リポジトリから削除されました。（将来復活するのかどうかは不明）
  このため ruby-2.6.1 を用いて再ビルドしたものを投入しました。

libkkc-0.3.5-10.git20180801

libkkc-data-0.2.7-4

• どちらも上記の marisa-0.2.4-3 を用いて再ビルドしました。
  なお marisa が公式リポジトリから削除されたことにより、libkkc 関連のパッケージも全て公式リポジトリから削除されています。

jdim-0.1.0-2.20190129

• 最新のリビジョンを用いてビルドしました。