2017年8月21日月曜日

華麗なるLINUXの世界9 〜助けてガチKGB、ウチのMinGWちゃんが息をしていないの!〜

Здравствуйте! イポンスキーの諸君、元気かな?
今日は元気なちびっこから届いたメールを紹介しようと思う。

助けてガチKGB、ウチのMinGWちゃんが息をしていないの!

ぐわっはっはっはっは!実に面白いジョークではないか
MinGWとはこのへん参照→リンク(wiki)
要はwindowsでC言語の勉強がしたい。
そこでMinGWを入れたが動かないらしい。

さて、このちびっこの主張ではここのHPを見ながら
MinGWを設定したらしい。
エラー内容としては「パスが通らない」
まあ、そもそもMinGW自体クソなのでこんなもので
ドハマりするとか「田舎道でボットン便所に墜落しました」
なみのマヌケっぷりだ。
しかしJavaその他の勉強でもパスを通す作業は出てくる。
MinGWはクソだから捨てるにしても
「パスが通らないとはこれいかに?」と思った。

どうせ○○でしょ?と適当にエスパー返信をしてみたが
ロクな返事が返ってこないw
逆質問して確認・再確認をした後でないと
回答すらできないようなガバガバ質問はクソだ。
まして、逆質問してやったのに回答すらしないとか
こいつはCIAの回し者か?と思っていたが
ちょうど私自信windowsを用意して
色々潜入工作をする仕事があったので
そのついでにMinGWを入れてみた

驚いた

なんと、マジでパスが通らない。
まあ、ガチKGBのスーパーテクニックで
何が悪いのかすぐに見破って設定してやったが。

その過程で改めてwindowsってほんと使えねえよなあ
と実感した。
そこでクリーンインストールしてからパスの設定
までの様子を動画で記録して公開しようと思った。
しかしaviutlがまたクソすぎて泣けてきたので動画公開はヤメ。
スクショのみでの説明にする。
環境的には
windows 10 enterprise 32bit 評価版
intel i3 4370
4GB RAM
ちなみにMinGWは32bit版しか無いらしい。
今時32bit OSとかほんと頭悪いなーw
さて、これがインスコ直後のwin10
私がよくやる設定から作業開始。まずはインデックスを切る。
エクスプローラー開いて PC開いてCドライブで右クリック
プロパティで左クリック
「このドライブ上の...インデックスをつける」のチェックを外す
「変更をドライブ...ファイルに適用する」のチェックが
付いた状態で下のOK押す。
これは続行
エラーは「すべて無視」
windowsの存在そのものがエラーだっつーのw
これでようやく作業開始
普通は数分かかるはずなのでしばらく放置
まあ、私は放置せずに作業しちゃうけどw
コンパネ→カテゴリ→小さいアイコン
マウス→ポインタオプション→速く→OK
エクスプローラーに戻って、
上の「表示」→右のオプション→「フォルダーと検索のオプションの変更」
上の「表示」→「登録されている拡張子は表示しない」
ここのチェックを外す→OK
ここらで適当に必要そうなソフトを拾っておく
winrar vlc chrome massigra...
最低でもこの程度は入れないと
標準アプリがあまりにゴミすぎて使い物にならないと思う
そして忘れてはならないのが問題のMinGW
広告まみれの画面でとりあえず保存
さて、インデックス外すのがまだ終わらないので
気晴らしに壁紙検索中。
では、vlcその他入れた後で問題のMinGWインスコ開始
とりま、実行。
MinGWのバージョンは0.6.2か。
それはいいとしてbetaとか書いてあるんだが(笑
まあ、どうでもいい。
windowsそのものがベータ版以下の欠陥OSだからw
下のinstall押す
インスコ先は普通はCドラ直下だろう。
変えたい人は変えてからcontinue押す
しばらくダウソ作業で待機後、下のcontinueが押せるようになったら押す
installation managerと称する画面が出てくる
ここで欲しいものは"mark for installation"のチェックを付ける
先程のHPの説明ではmingw32-baseとmingw32-gcc-g++を
チェックすると書いてあった。
g++と書いてある時点でピンと来る人は来るが
実はこれはCのコンパイラを入れている訳ではない。
C++のコンパイラを入れている。
C++はCの拡張言語。C++の中にCが含まれる。
(厳密にはそうとも言い切れない)
fortranとかadaは別の系列の言語。
入れても使うつもりも無いからHPの指示どおりに設定
installation → update catalogue
apply
ダウソ中
成功。close さあ、ここからパスを通す作業に入る
まず根本的な所から間違っている人がいるので説明しておく。
パスとはpath 間違っても、passではない
ディレクトリツリーの中のどこに目的のファイルが存在するか
という、いわば住所・番地である。
ディレクトリツリーとは、ザックリと
「うぃんどーずの中」と言い換えてもあまりハズレではない。

windows(を含むOS)の中にはあまりにも大量の
ファイルだのプログラムだの有象無象が山盛りすぎて
何がどこにあるのかwindows自身が把握しきれない
という状況になっている。

そこで特定のパス、特定の番地だけは事前登録をしておく。
どこにあるんだかワケワカメなプログラムの実行指示が
出された場合は「事前登録済み」の番地だけを
検索しましょうというルールにしてある。
これなら探索先がごく一部に絞れる=早い=うれしい
この「事前登録作業」の事を「パスを通す」と称する。
パスという環境変数の中に
希望のディレクトリを追加するという作業だ。

これなら何万か何十万か数える気すら起きない大量のファイルを
1個1個シラミ潰しに検証するという無駄を防ぐ事ができる。

例えるならば、郵便局のバイト君のようなもの。
日本全国の1億ウン千万人の住所と勤務先と帰省先とカノジョの家と元カノの家と・・・なんて覚えられる訳がない。
ましてや海外とか含めたら真剣に無理。

しかし、どこぞのKYな客が住所無しの宛名だけの手紙を
出してきたとする。この時にどうするか?
郵便局なら普通に「宛先不明」で差出人に突き返せばいい。
これがパソコンでのパスが通らないor通っていない状態。
コマンドプロンプトでのエラーメッセージとしては

xxxxは、内部コマンドまたは外部コマンド、操作可能なプログラムまたはバッチファイルとして認識されていません。

↑これに相当する。
郵便局なら客が宛名の書き直しでもしてくれるんだろう。
まあ、クソクレーマーが怒鳴り込んでくれば
営業妨害で警察でも呼べばいい。
しかし、ぱそこんは住所の書き直しを誰がするのか?
まさか、windows自身ですら把握しきれない
ウン十万のファイルの名前と所在を
ユーザー(おめーだよw)が丸暗記するのか?

対処法はいくつかある。windowsの設定では
カレントディレクトリは必ず確認するという仕様になっている。
カレントディレクトリは特別扱いであり、
パスを事前追加する必要がない。
だからC言語の学習をソースの保存先含めてすべて
C:\MinGW\bin 直下で行ってしまう。
まあ、これは頭の悪いやり方だw
要は先程から話題になってる事前登録とやらを
すればいいんだろ?という話だ。そこで作業開始。
コンパネ→システム→システムの詳細設定
システムのプロパティの詳細設定タブが開く→環境変数
→xxxのユーザーの環境変数のPath選んで下の編集押す
変数値にmingwのインスコ先を追記する
インスコ段階で変更していないならc:\mingw\binのはず
セミコロンを忘れないという所がポイント
OK→OK→OKで画面閉じる

人によっては「え?そのPATH簡潔すぎない?」と
驚く人もいるらしい。

ハッキリ言っておきます。これがwindowsの標準であり
これと違うパスが設定されていたとするなら
アナタのぱそこんはゴミです。
(いや、実はメーカー製ぱそこんは大部分が
このゴミに該当するんだがw)

このへんのPATHの問題は実はぐぐると時々出てくる
WindowsでPATHをサクッと設定する方法とWindowsのPATHは時々地獄リンク

Windowsのパスの長さ制限に引っかかったので短くしてみたリンク

環境変数のサイズやPATHの長さ制限に注意 (1/2)リンク

windowsのパスは一体何文字まで耐えられるのか?
これはぐぐっていても複数のサイトがちぐはぐな数値を並べている。
私の予想ではそもそもMSが手抜きで作っているから
誰も明確な数値を知らない。
例えばここでは
Microsoft* Windows* マシンでは、PATH 環境変数のサイズの上限は 2047 文字 (Microsoft Windows* 7 以降では 4095 文字に変更可能。ただし、システムの再起動が必要。) に制限されています。
と主張する。

ところがMSのHPですら「文字数制限は無いけど32K」と
矛盾した回答を平然と出しているのはどう説明するのか?
せめて制限があるのか無いのかそれぐらいハッキリさせてくれ
→参考リンク

で、この珍回答のソースはどうもMSのdeveloper centerの
environment variablesの項目らしい→リンク

リンク先によると
The maximum size of a user-defined environment variable is 32,767 characters. There is no technical limitation on the size of the environment block. However, there are practical limits depending on the mechanism used to access the block. For example, a batch file cannot set a variable that is longer than the maximum command line length.
Windows Server 2003 and Windows XP:  The maximum size of the environment block for the process is 32,767 characters. Starting with Windows Vista and Windows Server 2008, there is no technical limitation on the size of the environment block.
・・・アホか。

で、環境変数の中でもPATHに限っては
やっぱ2047文字ですとか何とか書いてある→リンク
じゃあ、2047文字までは許容されるんだな?と思ったら
さっき紹介したここでは1024文字に切り捨てられたという
被害報告が上がってたりする
こことかこことか見ていると、どうもこれは
コマンドプロンプトの制限であってPATHの制限ではない
可能性がある。

能力はある。けど、使いこなせない。
ちなみにその有る有るうるさい能力とやらが
一体いくらなのか誰も知らない
・・・バカですか?

エスキモーの冷蔵庫じゃあるまいし、
使えもしないクソ機能を抱え込んでこいつは一体何がしたいのか?
毎度毎度そうだ。MSのやる事は矛盾だらけで
方向性がグチャグチャで真面目な奴ほどバカを見る。

ああ、ついでに私のユーザー名がabcと見えてしまっているが
こんなもの屁でもない。
私は評価版なせいでしょっちゅうOS再インスコするし
その度にユーザー名も変えているw
ユーザー名に個人情報突っ込むとかドシロウト。
そもそもwindows使ってる時点で十分終わってるとも言うw
ましてユーザー名に全角文字使うとか更にバカ
海外製のソフトだとパスに全角文字が入るとコケるものがある。
まあ、要はそのソフトがクソなんだけどw

ついでにコレ参照
私はwin自体評価版だし評価版のダウソの時に
入力する情報もこの程度だ。
え?いやいや、虚偽の申告なんかしていませんとも
たまたまこの瞬間ハッキングされてキーボードが暴走したんです。
だからハッキング怖いなあ ( ノД`)怖いよ…ママンッ
という意味でスクショ保存しておいただけですけど
それが何か?

・・・さて、ここまでが「通常の」設定作業である。
ぐぐればこんなものいくらでも出てくる。
私がわざわざブログ記事を書くのは
能書き通りの通常の設定が通用しない場面に
私自身が遭遇したからだ。

私自信は今回のブログ記事を書くにあたり
win10を3回クリーンインスコしてmingwのインスコも
パスの設定も3回試している

実は3回とも挙動が違っている
ここから導かれる唯一の答えは「windowsがクソ」

1回目はパスを設定したがどうしても通らなかった
メール相談の中でバックスラッシュ(円マーク)が
おかしいという話題が出ていた。
そこからピンと来た私はエクスプローラーのアドレスバーから
フルパスをコピペして環境変数に設定した。その結果成功。
キーボードから入力しようが
エクスプローラーのアドレスバーからコピろうが
バックスラッシュはバックスラッシュだ。
なぜ意味不明な違いが生じる?

ちなみにlinuxユーザーでしかもUSキーボード使いの
私が検証しているのだから
実はバックスラッシュと、ただのスラッシュを間違えたとか
そんなアホウな事はあり得ない。

まさか、こんなクソな事が起きるとは思っていなかったから
1回目は作業過程を一部しか録画しなかった。
しかもついでにコーデック適当に選んだら
予想外に動画のサイズが大きくなってこれは失敗したと思った。
だから一度全プロセスを録画し直ししようと思った。

2回目はOSクリーンインスコ直後から作業を録画開始。
しかし、困ったことにパスが普通に通ってしまった。
何事もなくここのHPで書かれている作業通りに成功。

なぜだ?と思って3回目に挑戦。

3回目もOSクリーンインスコ直後から作業を録画開始。
そして、試してみると「パスが通らない」謎の症状再発。
この時私は
「カレントディレクトリではgccが動く=パスが通る」
というwinの仕様の確認を行い
cd .\..
で1個上のディレクトリに移動してエラーの発生を確認した。
「なるほど。決定的瞬間を捉えたぞ」と喜びながら
home直下でどうなるか見ようと思って
(linux的表現で言えばc:\users\%USER%でのエラーも録画しておこうと思ったという事)
コマンドプロンプトを一旦閉じた。
コマンドプロンプトを開き直ししたら・・・
なんとパスが通ってしまうではないか。

べつにOS再起動も何もしていない。
作業手順だって同じHP見ながら、同じ人間がやっている訳だ。
違う結果が出る方がおかしい。
ましてOSのバージョン違いとかPC環境の違いとか全く無い。
4回目、5回目もやれば何か珍動作が観察できるのかもしれないが
こんな不安定極まりないゴミOSと
これ以上つきあうつもりもない。だから作業は打ち切り。

安物の製品とか扱っているとよくあるパターンだ。
例えばrealtekのNICなんかまさにそう。
The RealTek Network Adapter/Controller was not found. If Deep Sleep Mode enabled Please Plug the Cable
このエラーでぐぐってみたらいい。
真剣に脳味噌が腐っているとしか思えない珍理論を
トクトクと語っているバカが後を絶たない。
ハッキリ言っておくがこのエラーの対処法と称して
書いてある内容は9割がただのウソ。
アンタのゴミぱそこんがソレで復活したんだとしても
それはアンタのぱそこんがゴミというそれだけの話。
ウソをウソであると見抜けない人にぱそこんを使う事は難しいww

要はrealtekが安物で不安定 手抜き製品だという事。

そしてwindowsも同じ事。
こんなパクリで安物で不安定極まりなくて
スパイウェアまがいの欠陥品をイルミの忠犬が作っていて
しかもイスラエル支援だの何だの散々やらかしてくれている
という事実・・・それに対して少しは思う所はないのか?
こんなゴミが世界シェアナンバーワンという事実を
少しは真剣に考えた方がいい。

潰してやる。winもMSもこの私が潰してやる。

最後はお約束のひと言をオナシャス
「黒幕はキリスト教徒!」

2017年8月6日日曜日

華麗なるlinuxの世界8 〜燃えよ! ibus-mozcカスタマイズ道!〜

さて、いまだ「うぃんどうず」とかいう
ゴミOSからのアクセスが後を絶たない当ブログだが(苦笑
忘れた頃に華麗なるlinuxの世界のパート8を書きたい。

今回は一気にレベルを上げて中級者向けの記事を書く。
linuxそのものを含むフリーソフトの特徴のひとつは
改変ができるという事だ。

linuxの世界はうぃんどうずのボンクラの世界とは違う。
うぃんどうずに不平不満は人一倍のくせに
結局何もしない、できない、バカどもとは違う。
linuxの世界では文句があるなら自分で作ってしまうという
荒業が許される。

ソフトが無いのなら自分で作ればいいのに
(某マリー=アントワネット)
もちろん、ゼロから作るのは時間も手間もかかって大変だ。
最初は、既存のソフトを部分的に改変するのがよいかと思う。

(ここにおいて、"プログラミングぐらいwinでもできますけど?"
という反論は一気にトーンダウンする。
既存のソフトのパクリ上等というオープンソースの世界と
裁判覚悟でなければパクリなんかできないwinの世界
初心者にやさしいのはどちらか?)

その過程で開発ツールやソースコードの取扱いを勉強すれば
将来的なステップアップに役立つはずだ。

今回はibus-mozcを取り上げる。
まずはこれのどこに不満があるか?という問題点を書く。

私自身はUS配列のキーボードを使っている。
この条件でibus-mozcを使うと困る事がある。
入力をibus-mozcに切替えると最初は「直接入力」になる。
これは単に半角英数を打つのと同じだ。

日本語を入力しようと思った

だからibus-mozcに切り替えた(キーボードのsuper + space)

しかし英語入力のままである

切り替えた意味ねえじゃん!

という問題だ。
どうもJISキーボードを使う場合だとまた違う対応があるようだが
私のようなUSキーボードの場合は、この後に

マウスを持つ

画面右上の「A」の所をクリック

input modeをクリック

hiraganaをクリック

準備おk

ここまでやって初めて日本語が打てる。これは邪魔くさい。
文字入力はキーボードで行う作業だ。
だったらキーボード操作だけで文字入力ができたっていいはずだ。
それなのにマウスで3箇所もクリックするのは馬鹿らしい。

(注意 私はlinuxは基本的に英語でインストールしている
日本語でインストールすると表記が違うかもしれない)

日本語を入力しようと思った

(1)だからibus-mozcに切り替えた(キーボードのsuper + space)

(2)マウスを持って

(3)画面右上の「A」の所をクリック

(4)input modeをクリック

(5)hiraganaをクリック

準備おk

・・・上記の5段階が

日本語を入力しようと思った

(1)だからibus-mozcに切り替えた(キーボードのsuper + space)

準備おk

・・・1段階になったらいいよね?という話だ。
通常のibus-mozcの3倍以上の速度で準備が済めば
シャア大佐にも勝てるかもしれない
もしくはトランザム
でなければ人類の未来ガー イノベイターガー

元々この記事はある人のブログ記事を元ネタにしている。
しかし2017年8月時点でそのブログそのものが削除されている。
しかも元記事自体、内容が古くなってしまっている。
(記事内容そのものはコピペで保存してある)
「古い」の具体的内容は、元記事の公開後に、
ibus-mozcがバージョンアップされた事が原因。
ibus-mozcのソースコードが変わってしまっている。
だから「○○行目の○○を、○○に修正」という
肝心要の内容が違ってきてしまっている。
もうひとつは、fedoraがyumからdnfへ移行したのが原因。
yumで書いてある箇所をdnfに直さないといけない。
だから私自身がfedora26で実際に検証した結果を踏まえて
最新版に修正した情報を公開する事に意味はあると思う。

では、早速、その新手順を解説しよう
想定する環境はfedora 26 64bit gnome版

尚、fedora 26はインストール直後から日本語が入力できる。
設定画面で"japanese (kana kanji)"を選べば良い。
settings -> region&language -> input sources -> 「+」
だからインストール直後で、
まだ、ibus-mozcの修正作業が終わっていない段階で
何かググりたい事があっても日本語は使える。

しかし、
「え?じゃあ、そもそもibus-mozcいらなくね?」
という事にはならない。
"japanese (kana kanji)"では漢字変換がバカなので
うぃんどうず並みに誤変換を連発する。
だからibus-mozcを使いたい。

尚、"input sources"の、"japanese"は違う。これは別物。
これはキーボード配列がJISになるだけで日本語入力はできない。

では、以下に作業内容を解説付きで書く。
基本的に青字の所をコピペすればいい。
バージョンの数字等細かい所が変わる事はよくあるので
エラーが出るようなら解説部分でも見て
「これは何の作業をしているのか?」を考えれば
どうにかなるはず。

$ su // 管理者権限取得
# dnf update // とりあえずアップデート

この後、普段の私はibus-mozcよりも先に色々インストールする。
例えばclangとかvlcとかその他多数。
その時にrpmfusionが必須。参考リンク
最近unitedrpmsもいいかなあと悩み中。
ひとつにはunitedrpmsを入れるとunrarが簡単に入るから。

しかしrpmfusionとunitedrpmsは相性が悪いかもと
指摘するHPがある。参考リンク
一体何の話だろう?と見てみるとこのへんの事みたい。
新版が出た時のアップグレードに問題が出たらしいが
本当にrpmfusionとunitedrpmsの共存が悪いのかどうかは
ブログの筆者自身ちゃんと調べてはいない。

OSのアップグレードってべつにfedoraに限らず
winでも評判悪いので、この記事がどこまで信用できるのか不明。
私がrpmfusionとunitedrpmsを両方入れた感じでは
一応動く。即座に不具合が出るわけではなさそう。

# dnf groupinstall -y development-tools gcc-c++ rpm-build
// 開発ツールインスコ
# exit // 一般ユーザーにもどる
$ cd ~ // ホームに戻る(べつにこれは必須ではない)
$ dnf download --source ibus-mozc
// これはyum時代は
// yumdownloader --source ibus-mozc
// と打っていた内容。ソースをダウソしている。
$ rpm -ivh mozc* //rpmインスコ
// ここで下記のような警告が大量に出るが全部放置する。
// warning: user mockbuild does not exist - using root
// warning: group mockbuild does not exist - using root

// 次に必要なもの=依存関係を準備する
// 依存関係というのは
//「風呂を沸かすなら、まずは湯船に水貯めなきゃダメだろ?」
//「目玉焼き作りたいならフライパンぐらい買ってこいよ」
// みたいなもの
// 直接的な目的とは別物であったとしても
// 準備として必要なものが依存関係。
// ちなみにここまでの手順が済んでいれば
~/rpmbuild/SPECS/mozc.spec
// ↑ここに依存関係の記述がある。
// Requires:xxx等と書いてあるのがソレだ。
// しかし、1個1個手作業で拾い集めなくても一括ダウソができる。

# su // また管理者になった
# dnf builddep mozc-2.20.2677.102-1.fc26.src.rpm
// これで依存関係が一括ダウソされる
// yum時代にはyum-builddep mozc-2.20.2677.102-1.fc26.src.rpm
// と書いたであろう内容だ。
// dnf移行済みのfedora26ではyum-builddepはエラーが出る
// bash: yum-builddep: command not found...
// 先程のyumdownloaderもそうだがdnf移行にしてから
// fedoraのコマンドが色々変わっている。
// 勿論、これは将来的にcentosがdnf移行するという意味もあるので
// https://fedoraproject.org/wiki/Yum_to_DNF_Cheatsheet
// こういう所↑などを参照しておくのがよい

# exit // 一般ユーザーに戻る
$ cd ~/rpmbuild/SPECS
$ rpmbuild -bp mozc.spec
// これでソース展開&パッチ適用&適用済みソースが
// ~/rpmbuild/BUILD/mozc-2.20.2677.102/ 以下に展開。
// 最後に「+ exit 0」が表示されれば正常終了
$ cd ~/rpmbuild/BUILD/
$ cp -r mozc-2.20.2677.102/ mozc-2.20.2677.102.org/
// オリジナルのソースを保存
$ cd ~/rpmbuild/BUILD/mozc-2.20.2677.102
$ nano ./unix/ibus/property_handler.cc
// ここからソース改変 下記のグレー背景部分がソース。
// 編集に使うのはnanoに限らずvimでもemacsでも何でもいい
  // Some users expect that Mozc is turned off by default on IBus 1.5.0 and later.
  // https://github.com/google/mozc/issues/201
  // On IBus 1.4.x, IBus expects that an IME should always be turned on and
  // IME on/off keys are handled by IBus itself rather than each IME.
  #if IBUS_CHECK_VERSION(1, 5, 0)
  const bool kActivatedOnLaunch = true;
// 83行目のここをtrueにする
  #else
  const bool kActivatedOnLaunch = true;
// ここは元々true
  #endif // IBus>=1.5.0

$ cd ~/rpmbuild/BUILD/
$ diff -aurN mozc-2.20.2677.102.org mozc-2.20.2677.102 > hiragana.patch
// 差分パッチの作成
// これを作らないとビルドの過程で勝手にソースが元に戻る
// 名前はなんでもいい。unko.patchでもgachi-kgb.patchでもいい
// ただ、後の作業で必要になる名前なので
// 最低限、名前を覚えておくこと
$ mv hiragana.patch ~/rpmbuild/SOURCES 
// 先程のパッチを移動
$ cd ~/rpmbuild/SPECS
$ nano mozc.spec
// 再度ソースの編集
  # Public Domain
  Source2: http://www.post.japanpost.jp/zipcode/dl/kogaki/zip/ken_all.zip
  Source3: http://www.post.japanpost.jp/zipcode/dl/jigyosyo/zip/jigyosyo.zip
  Source4: ibus-setup-mozc-jp.desktop
  Patch0: mozc-build-ninja.patch
  ## to avoid undefined symbols with clang.
  Patch1: mozc-build-gcc.patch
  Patch2: mozc-build-verbosely.patch
  Patch3: mozc-build-id.patch
  Patch10: hiragana.patch
// 51行目にこれ(↑)追加 Patch10の数字は何でもいい
// 他(Patch1/Patch2/Patch3)と重複してなけりゃおk
(ソース中略)
  %prep
  %setup -q -c -n %{name}-%{version} -a 2 -a 3
  %patch0 -p1 -b .0-ninja
  #%%patch1 -p1 -b .1-gcc
  %patch2 -p1 -b .2-verbose
  %patch3 -p1 -b .3-build-id
  %patch10 -p1 
// 96行目にこれ(↑)追加 
// ここも何でもいい。但し、なんでもいいと言っても
// 51行目と一致はさせること
参考 http://d.hatena.ne.jp/cactusman/20080315/p1

// rpmbuild -bb コマンドでソースをビルドして
// Binary RPM を作成するが、ビルド中に
// "/usr/lib64/qt-3.3/bin/rcc"を実行しようとして
// "No such file or directory"が出る。
// その対策として"/usr/bin/rcc"を参照するよう事前に環境変数を操作
$ export QTDIR= QTINC= QTLIB=
$ PATH=/usr/bin:$PATH
$ cd ~/rpmbuild/SPECS
$ rpmbuild -bb mozc.spec 
// ビルド実行。最後に"+ exit 0"が出れば正常終了
# rpm -evh --nodeps mozc ibus-mozc
// 古いibus-mozc削除
// もちろんこれはソース改変無しの、
// ノーマルibus-mozcをインスコしていた場合のみに必要な作業
# cd ~/rpmbuild/RPMS/x86_64
# dnf install mozc-2.20.2677.102-1.fc26.x86_64.rpm ibus-mozc-2.20.2677.102-1.fc26.x86_64.rpm
// dnf installはいんたーねっつからダウソする時以外でも使える。
// 今回のケースではローカルでビルドされた.rpmを
// インスコしている。yumでは"yum localinstall"していた。
// ちなみに"yum localinstall"をdnfでどう書くんだろう?
// とぐぐるとここが見つかる
//  Please implement "yum localinstall" feture to dnf
//  dnfに「yum localinstall」の機能をつけてください
// という2013年4月のbugzilla記事だ
// ここでAles Kozumplikを名乗る人物が
// This was the reason why I removed localinstall.
// と言い出している。
// 「ええ、俺様がlocalinstallを消しましたけどそれが何か?」
// と平然と語るこの人物。何者?と思って調べると
// 実はredhatの社員でdnfを書いた張本人。
// ガチの「中の人」だったりするw

再起動してsetting -> region&languageで選び直しして終了。

最後はお約束のひと言をオナシャス
「黒幕はキリスト教徒!」