Operation Normal ?

2007年の夏に PCLinuxOS 2007 を初めて導入して以降、12年近くメインの OS として PCLinuxOS を使ってきましたが、この度、Mageia へ移行しました。現在 β2 段階の Mageia 7 が正式リリースされてからにしようかとも考えたのですが、待ち切れずに現行の 6.1 で移行してしまいました。7 が正式リリースされれば速やかに更新するつもりです。

Mageia は今までもリアル環境にインストールしてサブ的な OS として使ってきましたが、これからはメインの OS として使っていくことになります。PCLinuxOS は当面はサブ的な OS として使っていくつもりですが、将来的にはリアルな環境からは消えることになるかもしれません。

拙作の PCLinuxOS 用の野良リポジトリについては現状のまま維持し続けるつもりです。気が向けばパッケージの更新なども行うかもしれません。

一方の Mageia 6.1 用の野良リポジトリに関しては 7 のリリースまでは更新していくつもりですが、7 の野良リポジトリに付いては全くの未定です。

下記のパッケージを 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 にしておけば、あるいはライブラリのコンフリクトについてもう少しだけ配慮してもらえていたら問題は発生しなかったはずで非常に残念です。