KDE 4.13難航

Qt 5.3.0のbuildは，

export CFLAGS="-O2 -march=i486 -mtune=i686"
export CXXFLAGS="-O2 -march=i486 -mtune=i686"
export OPENSOURCE_CXXFLAGS="-O2 -march=i486 -mtune=i686"
./configure \
 -confirm-license \
 -opensource \
 -prefix /usr/lib/qt5 \
 -system-libpng \
 -system-libjpeg \
 -system-zlib \
 -system-sqlite \
 -plugin-sql-sqlite \
 -plugin-sql-mysql \
 -dbus \
 -nomake examples \
 -no-separate-debug-info \
 -no-pch

という，SLackwareのQt4.xのオプションから，エラーがでるものを外して，２台で試し，１台でOKでした．もう１台は，ネット検索であちこち見つかるように，webkitのbuildができません．

ネット検索で解るように，webkitを外すオプションはありません^^; やむなく，qtwebkitとそのexmampleのサブディレクトリーをどかして^^; build成功しました．

しかし，KDE 4.13はうまくいきません．kdelibsで必須となるAtticaがbuildできません．情報を収集してみます．Qt 5.2.xに退化させた方がいいのかな．

KDE 4.13は要Qt5

しばらくKDE 4.12のupdateをサボっていたら，KDE 4.13がリリースされていたので，あいまにインストールして見ることにしました．

それで，KDEの関連ソフトのupdateから始めましたが，ひとつのソフトは，CMakeが古いといって，エラーを出します．CMakeをgitレポジトリーから最新のものをpullしてインストールしたら，3.0になりました．この件は解決．

また，Sopranoかなんかをbuildしているときに，ECMがないというので，調べてみたところ，これもKDEのサポートソフトウェアで，extra-cmake-modulesというもので，KDEのgitレポジトリーにありました．これも解決．

で，まあ，いつものこんな調子で必要な条件を満たすべく，git pullしたり，cmakekdeしたり，時には，git cloneして，関連ソフトがそろったので，buildのディレクトリーと，インストール先の/opt/kde4を削除して，KDEの一番根幹であるkdelibsのbuildをはじめました．

そしたら，atticaがないとほざきます．atticaのソースディレクトリーに行ってcmakekdeすると，Qt 5がないといいます．

いままで，Qt 4でやってきましたが，KDE 4.13からは要Qt 5のようです．

ということで，一息入れてから，Qt 5のbuildをしてみます．Qt 4と同じやり方で行くといいんですが^^;

あくまでこのサイトに書いてある情報の利用は自己責任でお願いします．

追記

要Qt5は間違いです．

WordPress 3.9, GoogleDriveその後

WordPressが3.9になりました．

GoogleDriveのMac OS X用は相変わらず，正常に動いているなと思っていたら，またシンクロしなくなったりと，何ともあてになりません．ファイルの更新後にアイコンが動くか確認して，変化がないときは，GoogleDriveをいったん終了して，再起動しています．

DokuWikiの導入は，頓挫してます^^;

Too Big To Fail

大きければ良いってもんじゃないって事を実感しました．

今回のOpenSSLの史上最悪のセキュリティーホール対策の話です．まあ，私が運営しているサイトなんか，意図的なクラックの対象にはならないと思いますが，そのうちネットをクロールしながら，総当たり的にクラックするツールなりウィルスが発明されて，どんなサイトも攻撃対象になり得ますので，対策を取っておきました．

対策の第一は，OpenSSLのupdateです．ふだんからソースからbuildしてますので，たいした手間ではありませんでした．

そして，サーバーの秘密鍵の更新です．サーバーの秘密鍵が盗まれても何の形跡も残らない，というこで，完全を期すならば，OpenSSLのupdateのあとにこの鍵の更新をすることが推奨されています．

証明書は，私の利用しているところは有効期限が半年なので，5か月内外で更新していますが，秘密鍵そのものは滅多に作り直すものでは無くて，タイムスタンプを見たら，どのサイトのものも2006年作成でした．で，自分のメモにしたがってやってみました．

メモには，キーのサイズを4096にするとあるのですが，前にキーを作ったのは，８年も前ですから，この際8192にしてみました．

私が管理しているサイトでは，httpd(HTTPS)の他，imapd(IMAPS)とsendmail(STARTTLS)がこの秘密鍵とそれぞれの証明書を使用しています．それら３つのサービスの秘密鍵と証明書を更新してデーモンを再起動しました．

httpdに関しては何ら問題がありませんでしたが，IMAP(IMAPS)とSMTP(STARTTLS)で接続できないとか認証エラーがクライアントから出ます．

昨夜から今朝までさんざん悩んで，sendmailをソースから再ビルドしたり，SASLのパスワードを設定し直したりしてみましたが，ちっとも症状は変わりません．ふと思いついて，

sendmail error 8192

で検索したらありました．キーサイズは4096までじゃないとsendmailのSTARTTLSは正常に動作しないようです．この他，IMAPS対応のメールクライアントやデーモン，プラグインでもNGなものがあるようです．

Heartbleed
ただし，HTTPSは正常に機能していましたが，DAVは動かなくなっていました．

プロ野球って変だなぁ

たぶん，「公式戦」といいながら，大きさの違うフィールドで行うスポーツって，野球以外にないですね．

それが野球だと言ってしまえばそうなのかもしれません．リケ男として昔から感じているのは，球場の「狭い広いで有利不利があるのではないか」ということです．

こういう話に対して，野球通の理科系頭でない人は「狭い広いがあっても対戦する両者の条件は同じ」といいます．しかし，原則全試合の半分は自分の球場でやるわけですから，同じリーグ６球団のうち１球団だけ狭い（あるいは広い）球場を使っていれば，それに特化した野球をすることでずいぶん違った結果になると思います．

私は，これまでの観測として，狭い球場を本拠地としているほうが有利と考えています．それを何とか証明できるとおもしろいんですけど．

球場の広さは大きなファクターであるにもかかわらず，球場の広さは自称なんですよね．第三者機関が計測したものではない．「世界標準の野球」とかいうんだったら一度きっちり測って公表する必要があると思います．

たとえば，素人が考えても，３階席にポンポンホームランが入る京セラドーム大阪（大阪ドーム）が，自称通り，「両翼100 m、中堅122 m、左右中間116m」あるとは考えられません．