本日の野良リポジトリ (2014-07-13)
下記のパッケージを nora セクションに投入しました。
- mozc-1.15.1834.102-1
-
- ソースを 1.15.1834.102 (r271) へ更新しました。(Mozc release history)
【注意】このパッケージをインストール後は、念の為にシステムを再起動してください。（このパッケージのインストール後に、Synaptic が起動しなくなるケースが有るようです）
- ソースを 1.15.1834.102 (r271) へ更新しました。(Mozc release history)
PCLinuxOS | comments (15) | -
コメント
>Synaptic が起動しなくなるケースが有るようです
にアップデート後になったんだけど、もしかして前のソースでも同様のケースが有ったんだろか?
Synaptic 何度起動させようとしてもダメでOS再起動させたら問題なくなったんでつよね
原因はよく分からないのですが、mozc が「rootでは動作しない仕様」であることと何か関係があるのかなと邪推しています。
ってことは、ユーザーが ibus とか fcitx で mozc 使ってて システムでもーにしちゃったら影響受けんでつかね?
いや、rootでmozcを選択していても動作しないというだけで、その事が個々のユーザーの権限で動作しているアプリに影響を及ぼすとは考えにくいのよね。
ただ、Synapticはroot権限でしか動作しないから、その点では影響を受けるのかもしれない。
（よく分かっていないから全く明後日な話をしている気がしないでもない(；´Д｀)
>(よく分かっていないから全く明後日な話をしている気がしないでもない(;´Д`)
ダイジョブ！ とむきゃっとさん以上に理解してないおいらが明々後日な話な話をしながら明後日の方向向いてるだけだからー(｡+･`ω･´)ｷﾘｯ
それがね、端末で su で root に権限昇格するでしょ。
その後にね、端末上で mozc で日本語入力できちゃうのよね。
勿論、root でログインした場合には mozc での日本語入力は全くできないのは上に書いた通り。
ここら辺りの動作の違いが私のスキルではよーわからんのです(・_・;)
でも何か違うような気がする・・・
流れとしては、
1.ninjaという存在が全くわかっていなかった為,当初戸惑いました。
これは,tomcatさんの説明により明確にわかりました。
2.出来ればdepot_toolsを使ったbuildにしたかった為,少し苦しみました。僕の場合,spec fileにはあえて
export PATH="$PATH":`pwd`/depot_tools
を設定せず、まず端末より
$ export PATH="$PATH":`pwd`/depot_tools
あとは $ env|grep qt-3.3 にて環境変数を変更することにより,ソースを弄る必要はありませんでした。すなわちパスを通した状態でninja?はうまく走りました。
3.最後に苦しんだ部分(mozc_server等が動かない件）は単純に定義が指定出来ないと信じこんでいた部分が,実際には全く問題なく定義指定が可能でして（汗,現在もMozc-1.15.1834.102で記載しています。
4.mozc-build-verbosely.patchの存在は気になります。buildが通らないことからコメントにしましたが,tagohさんがどう対応されるかでfcitx-mozcをbuildしアップしようと考えています。
以上となります。本当にご迷惑をお掛けしました。わたしはほぼFedoraを主に使っていますが,tomcatさんの記事はよく拝見しています。
また教えていただけると幸いです。では失礼いたします。
失礼ながら、ビルドの前に Mozc のサイトの ReleaseHistory に目を通しておられれば、ninja に関してお気付きになられていたはずです。
> 僕の場合,spec fileにはあえて
> export PATH="$PATH":`pwd`/depot_tools
> を設定せず、まず端末より
> $ export PATH="$PATH":`pwd`/depot_tools
> あとは $ env|grep qt-3.3 にて環境変数を変更することにより,ソースを弄る必要はありませんでした。
> すなわちパスを通した状態でninja?はうまく走りました。
※「env|grep qt-3.3 にて環境変数を変更」の意味がよく分からないのですが、これは Fedora 独特の "おまじない" か何かでしょうか？
Twitter でのやり取りの当初から勘違いをされていたようですが、私が SPEC 中で記述しているのは
export PATH="$PATH":`pwd`/build_tools
です。
これは depot_tools から
ninja
ninja-linux32
ninja-linux64
ninja-mac
ninja.exe
の5つのファイルを取り出して来て、mozc のソースの build_tools ディレクトリ下に置いているからです。
※ build_tools ディレクトリ下に置いたのは私の勝手な判断であり、「このディレクトリでなければならない」ということではありません。
※ Linux でのビルドには ninja-mac や ninja.exe は必要ありませんが、一応置いてあります。
今回は作成されたパッケージを配布されるお積もりは無いようなので問題ないと思いますが、お書きになっている手法で作成されたパッケージの配布はされない方が良いと思います。
なぜなら、事前に PATH を通す必要があるなど、SPEC ファイルの記述だけでビルドが完結していないからです。
その手法で作成されたパッケージを配布した場合、第三者がそのソースパッケージを用いてリビルドしようとしてもエラーを吐きます。
例外は、
(1) 手元に最新の depot_tools を取得してあり、なおかつ、そこにパスが通っている環境
(2) 既にシステムに ninja パッケージがインストールされている環境
このどちらかの条件を満たす第三者のみがリビルドに成功するでしょう。
配布されているソースパッケージから作成者と同一のバイナリーを生成できないとなれば、最悪の場合、「バイナリーに何か良からぬものを仕込んでいるのではないか？」という様なあらぬ疑いを受けかねません。
どの様な環境の第三者であってもリビルド可能なパッケージとする為には、
(1) Fedora が提供している ninja を使ってビルドする
(2) mozc のソースに depot_tools で提供されている ninja のファイルを同梱する
(3) depot_tools で提供されている ninja のファイルを単独で tar 玉にし、mozc のビルド時に展開する
のいずれかの方法を取る必要があると思います。
※「第三者が検証可能（リビルドできる）」というのは、何処の誰だかよく分からない人間が作成している野良パッケージを公開・配布する上では、とりわけ重要な点だと私は考えています。
> mozc-build-verbosely.patchの存在は気になります。buildが通らないことからコメントにしましたが
そのパッチの内容を見ましたが、ビルドの際に make に対して冗長 (verbose) モードにするオプションである V=1 を与える為のものですね。
今回のバージョンからビルドには make に替わって ninja が使用されていますから、このパッチ自体が意味のないものになっています。
Twitter の方で、「何故 depot_tools の ninja を使おうと思ったのか？」という意味の質問を受けましたが、それに対する返答を最後に書きます。
通常であれば、
BuildRequires: ninja
を SPEC ファイルに追記してディストリビューションが提供している ninja パッケージを用いるのでしょう。
実際、PCLinuxOS でも公式リポジトリで提供されている ninja をインストールすれば問題なくビルドできます。
では何故に私がディストリビューションが提供している ninja を使わずに、わざわざ depot_tools の ninja を使ってビルドする様にしたのか？
これは mozc のビルドに必要とされる protobuf や gyp に関する経験から来ています。
新しいバージョンの mozc がリリースされた場合、ディストリビューションが提供している protobuf や gyp の各バージョンが、mozc の DEPS に記載されている要求バージョンに満たない場合が時としてあるのです。
特に PCLinuxOS ではその傾向があります。その為、現在の拙作のパッケージでは、mozc のソースに同梱されている protobuf や gyp を使ってビルドする様にしています。
その様な経験から、将来それと同じことが ninja でも起きる可能性を最初から排除するために、depot_tools の ninja を用いてビルドすることを選択したのです。
ディストリビューションが提供している ninja を使うか、それとも depot_tools の ninja を使うかはパッケージャーの判断次第だと思います。
ただ Fedora では protobuf も gyp も Fedora 自身で提供しているパッケージを使用してビルドしている様ですから、ninja に付いても Fedora が提供しているパッケージを使用してビルドすることを公式パッケージのパッケージャーさんは選択されるのではないかと予想します。
ご不快にしてしまった部分をまずお詫びいたします。
> 失礼ながら、ビルドの前に Mozc のサイトの ReleaseHistory に
> を通しておられれば、ninja に関してお気付きになられていたは > ずです。
申し訳ありません。
> 「env|grep qt-3.3 にて環境変数を変更」の意味がよく分から
> いのですが、これは Fedora 独特の "おまじない" か何かでしょう
> か？
から
> ※「第三者が検証可能（リビルドできる）」というのは、何処の
> 誰だかよく分からない人間が作成している野良パッケージを公
> 開・配布する上では、とりわけ重要な点だと私は考えています。
に関しまして。
僕はFedoraのパッケージしかしたことがなかったのですが,
例え
$ rpmbuild -ba mozc-1.15.1814.102-1.fc20.src.rpm（公式）
にて,mozc.specを使用しbuildしてもFedoraでは,そのままbuildは不可能です。
例 SIOS "OSSよろず" ブログ出張所
http://sios-oss.blogspot.jp/2012/10/rpm-3.html
上記のようにpathを整理する必要がある為,僕は今までpathが正しくない場合,端末上で設定することが普通なのだと思っていました。よって,depot_tools のpathに関しても,「パッケージをする際にセットすればいい」と判断しました。
tomcatさんのコメントを読み,なるほど！と思ったことは,わかっているからbuild前に環境変数をセットする,ではなく誰でもSPEC ファイルの記述だけでビルドが完結出来るように心がける精進が必要なのだと感じました。
Fedora公式SPECファイルはそもそも何故誰でもすぐにビルドが出来ない仕様なのか？はわかりませんけど,tomcatさんに質問していて噛み合わなかった部分,そしてご不快にさせてしまった部分は僕の変な慣れだと思います。
> Twitter の方で、「何故 depot_tools の ninja を使おうと思っ
> たのか？」
の部分も僕なりに理解出来ました。PCLinuxOSの要求バージョンを考慮されている部分が大ですよね。Fedoraのspecにて今回僕はprotobufをカットしましたが, gypがないとかなり辛いと判断しています。
アップに関しては,再度考えますし,FC20 FC19 FC21(x86_64 i686 ibus-mozc fcitx-mozc) すべて対応させるのはマンパワー的に無理を感じています。ここもやる気の問題だと思っていますが。
本当にすみませんでした。
$ rpmbuild -ba mozc-1.15.1814.102-1.fc20.src.rpm（公式）誤
$ rpmbuild -ivh mozc-1.15.1814.102-1.fc20.src.rpm（公式）正
$ rpmbuild -ivh mozc-1.15.1814.102-1.fc20.src.rpm 誤
$ rpm -ivh mozc-1.15.1814.102-1.fc20.src.rpm 正
> にて,mozc.specを使用しbuildしてもFedoraでは,そのままbuildは不可能です。
とのことでしたので、Fedora 20 LXDE (64bit) をインストールして確認してみました。
確かに仰るように「そのままbuildは不可能」で、エラーを吐きました。
でもこのエラーは、システムに gcc-c++ がインストールされていないことが原因でした。
つまり、SPEC ファイル中に
BuildRequires: gcc-c++
が記述されていないことが原因です。
恐らくはパッケージャーさんの凡ミスだと思われます。
gcc-c++ をインストールしてしまえば、後は無事にビルドが完了してパッケージが作成されました。
ビルドの前に環境変数をセットする必要は全くありませんでした。
と言いますか、例としてご提示になったページの情報は今となってはいささか古いのではないかと思いますよ。
それに現在の mozc は qt-3.x.x ではなくて qt-4.x.x を要求しますしね。
ついでに言っておきますと、Fedora の SPEC では
BuildRequires: openssl-devel
が指定されていますが、mozc では 1.15.1785.102 から openssl は不必要になっています。
Fedora では何故にビルド時に環境変数や Path の調整が必要になるのかずっと疑問だったのですが、これで理解できました。
従って前のコメントでの、
「例としてご提示になったページの情報は今となってはいささか古いのではないか」
という発言は取り消します。m(_ _)m