2015-06-06

Arch LinuxでSkypeがクラッシュする

Skypeがクラッシュして全く開けなくなった。一瞬ウィンドウが開いて、すぐ閉じる感じ。

すでにバグ報告は上がっていた。

FS#45204 : [lib32-qt4] [skype] Skype immediately crashes after launch

lib32-qt4をlib32-qt4-4.8.7-1からlib32-qt4-4.8.6-4へダウングレードすればいいらしい。

$ sudo pacman -U /var/cache/pacman/pkg/lib32-qt4-4.8.6-4-x86_64.pkg.tar.xz

Arch Linuxかわいい。

追記 2015/06/06 23:00

lib32-qt4-4.8.7-2がマッハで来たので、直った。

2015-06-05

KeePassXのデータベースがコンフリクトした話

僕はパスワード管理にKeePassXを使ってる。

そのデータベースファイルがコンフリクトするという地獄みたいなことが起きた。

f:id:terut:20150605104240p:plain

経緯

Dropboxで*.kdbファイルを同期して、Win/Mac/Linuxで参照できるようにしてるんだけど、Arch LinuxのDropboxがいつからか常駐しなくなってて、それを直したタイミングで*.kdbファイルがコンフリクトしてしまった。

Dropboxのファイルはコンフリクトすると、競合コピー（confliected copy）とかってファイルを新たに作るので、自分でマージする必要がある。

*.kdbのコンフリクトは色んな理由でやっかいで、だいぶ辛かった。

KeePassには同期機能があるっぽくて、KeePass使えば解決じゃんみたいな話かも知れないんだけど、家のメインマシンがLinuxだったこともあって、KeePass 2.0が使えなかったか何かでKeePassXを採用してた経緯がある。

KeePassってMacOSXとWinでデータベースファイルの拡張子が違ったりしてたような記憶があるんだけど、今どうなってるんだろ？そもそも僕の勘違いで違わないのかな？？

競合した内容を調査

当然、マージするには競合した内容を知る必要がある。

*.kdbはマスターパスワードをつかって暗号化されてるので、そのままで差分を知ることはできない。

どうやって差分を知るかというと、エクスポート機能を使ってテキストファイルかXMLファイルに吐き出すか、GUI上から超神技「目grep」を使うしかない。

僕みたいな一般人はエクスポート機能を使ってdiffを叩くなりするのがよさそうなんだけど、問題としてアホみたいに差分が出る。

実際見てみたけど、はっきり言って絶望しかない。

絶望した結果

golangを勉強してたので、XMLをパースして同じアイテムの差分を見て教えてくれるコマンドラインツールを書いた。

golangで書いておくと、WinでもMacOSXでもLinuxでも簡単に使えるやんけと思ったので、ちょうどよかった。

とりあえずどのアイテムがコンフリクトしてるのかが分かれば幸せになれそうだったので、その程度の作り込みしかしてない。

こんな感じでマスターにあるやつとコンフリクトしたやつのアイテム名が出る。

<a href="https://github.com/terut/kdb-diff">terut/kdb-diff</a>github.com

まとめ

だいぶニッチだけど、golang書く練習になってよかった。

コンフリクト解消して幸せになろうな。

2015-05-28

あなたとFacebook、今すぐサブミッション

Facebook

Facebook Graph API 2.0に完全に切り替わって1ヶ月が経とうとしている。

Facebookのフィードに投稿するには、publish_actionsというパーミッションが必要なのだが、切り替わりに際し、パーミッションを聞くためにFacebookへのレビューが必須になった。つまりレビューが通らなければ、そもそもユーザにパーミッションを求められないという話だ。で、そのレビューを通して、知見を得たので残しておく。

やること

今回、ガイドラインやドキュメント、FAQを読みながらやったことは以下のような感じ。はっきり言って大量にありすぎて、日本語訳作ってもすぐ腐ると思うので、原文を参照するのが好ましい思った。

Facebookの定めるガイドラインを読む（必要になるタイミングでパーミッションダイアログを出すとかPrefillをするなとかタグ付けするユーザを簡単に選択・削除できるようにしろとかある）
ガイドラインを守って実装する
レビューの手順は明確にスクリーションショットを使いながら、どんなアクションを使うのかということまで説明する（書き方のヘルプリンクがあるので参考にする）
レビューの際、レビュアーは自前でいくつかテストアカウントを持っているので、テストユーザ（オプションの項目）でテストして欲しければ、明記する

レビューの環境

いくつか方法があって、一番良さそうなのはTest Appを使うこと。昔はTest Appという機能がなく、テスト用に単独のFacebookアプリを作ってテスト環境を作っていたが、それが本番に紐づく形で用意できるようになったので、それを使ってテスト環境を作り、それをレビューしてもらえばいいかもしれない。僕のケースではテストユーザの場合のみ、機能を解放するような仕組みを作って、それでレビューしてもらったので、上記の方法でやる機会があって成功したら教えて欲しい。

起こったこと

2回ぐらいリジェクトされた。そして毎回同じメッセージで、どこを直していいのか分からない。

f:id:terut:20150528230202p:plain

ヘルプを見ると、例えばログインできないなどの理由でレビューができなかったといった場合に返される結果らしい。だがしかし、ログインできているし、管理者権限であればレビューがいらないので、機能を使えている。

で、どこか違反してたらもう少し詳しい結果が返ってくるはずなので、レビューすらされていないと考え、ひたすらレビューのための手順を詳しく用意し、スクリーンショットを追加した。さらに3回ほどレビューに出したけど、リジェクトされて絶望しかない。

とにかく全く意味不明で、ドキュメントを読み直しても、手の打ちようがなかった。

ちなみにコンタクト用のボタンが用意されてはいるが、どうも広告出したりしないと使えないとのこと。これに関しては僕は聞いただけなので、よく分からない。

結果

Facebook上にはFacebook Developer CommunityというFacebook Groupが存在していて、その中には中の人がいることが分かった。 Facebookのドキュメントにはそこに尋ねてみろとの勧めがあったので、尋ねることにした。

投稿すると中の人からレスがあった。

やあ xxx, 君たちのように間違った 'general issues' メッセージでリジェクトされてるアプリがいくつかあって、Fixするために動いてるから解決したら君に連絡するよ。（超意訳）

超ウケない。

その後、数時間して直したからダッシュボード見てくれって言われたらレビュー通ってた。

教訓

Facebookでの問題はFacebook Development GroupというFacebook Groupに入って聞くのが良い。

タイトルはあなたとJava、いますぐダウンロードに強い影響を受けた結果です。

2015-05-01

続・Arch Linux曰く、Something has gone wrong

先日、Arch Linux曰く、Something has gone wrong - 解せぬ日記でArch Linuxがぶっ壊れた話をしたんだけど、またぶっ壊れた。

原因はやはりnvidiaの349.16-1のパッケージ群っぽい。

よかろう、ならばダウングレードだと思ったんだけど、今回は詰んでいた。

なぜなら他にもアップグレードが来ていて、全部一緒にアップグレードした結果、linux-4.0系が入り、nvidiaの346.59-1はlinux-3.20以下という依存関係を持っていたためだ。

nvidia-349.16-2が来てたもんで、直ってんじゃないのとノリで上げてしまった。

ということで、本格的に格闘することにした。

対処法

ログの見方などは前回、説明した通りにやればよい。

で、今回はちょっと詳細にArch Linuxの公式のBBSやバグトラッカーなどを読んでいった。

すると、microcodeのアップデートする必要がありそうなことが分かった。

https://bbs.archlinux.org/viewtopic.php?pid=1522487#p1522487

理由は以下の通り。

https://bbs.archlinux.org/viewtopic.php?pid=1522675#p1522675

読むのが面倒くさい人のために簡単にまとめると、nvidia-libglの496.16-1にHLEの命令セットが導入されたためで、microcodeのアップデートによってHLEの命令セットを無効化することができるという感じだった。

CPUはHaswellを使ってて、Intel TSXはHLEのインターフェースを提供するらしいが、命令自体はエラッタのため、無効化されたとのことだった。

北森瓦版 - “Haswell”のTSX命令にエラッタが発見され、無効化される処置がとられる

無効化はmicrocodeによって行われたりするみたいで、BIOSのアップデートなどで提供されるらしいのだけど、Linuxなどではブート後にアップデートする仕組みを用意してるらしい。

ただ、あるバージョン以降、自動でアップデートしなくなったので、自分でパッケージを入れる必要がありそうだった。

とまあ、色々調べては見たものの、正直、練度が足りなすぎてホエーってなってる。

あくまで推測にすぎないとのことだが、fixしたよーとの報告も多々あったので、実際に試してみた。

作業ログ

前回の話でLive USBなどが必要という話はしたので、Live USBをブートしたところからやっていく。今回はintel-ucodeというパッケージをインストールするのだけど、/boot/intel-ucode.imgができるのでbootもマウントしておく。

ここを見ながらやるとよい。

Microcode - ArchWiki

日本語WikiはGrubの設定の部分が古くて、コードや上記Wikiを見ると最新版のGrubではintel-ucodeの対応はすでに入っているため、インストールしたらgrub-mkconfigを実行すればよくなってる。

root@arch$ mount /dev/sda6 /mnt
root@arch$ mount /dev/sda5 /mnt/boot
root@arch$ mount /dev/sda2 /mnt/boot/efi
root@arch$ arch-root /mnt

sh-4.3$ export LANG=en_US.UTF-8
sh-4.3$ pacman -Ss intel-ucode
sh-4.3$ grub-mkconfig -o /boot/grub/grub.cfg

あとはこれで再起動すれば無事にエラーは解消して、いつもの画面に会える。

まとめ

Arch Linuxは相変わらずkawaii。

nvidiaのパッケージが対応しない限り、nvidiaのパッケージはアップデートできず、アップデートが億劫になるので、対応したほうがよいように思う。

あとCPUのこととか、Linuxのこととか知らなすぎて辛い。

2015-04-24

Arch Linux曰く、Something has gone wrong

Arch Linux

Arch Linuxはローリングリリースを採用しているので、カジュアルにガンガン、パッケージのアップデートが来る。常に最新のものが提供され、最新こそ安定ぐらいの勢いを感じるわけだけど、たまーにぶっ壊れる。

そして今日もぶっ壊れた。

Archぶっ壊れて爆笑してる pic.twitter.com/N6NNyHMonP
— レベルがあまりに低い (@terut) April 23, 2015

体感では壊れることは滅多にないし、ググッて解決方法が見つからない、またはArch Linuxのオフィシャルなサイトにバグ情報が上がってないことは、もっとない。

が、今日は見当たらなかったので、そんな時どうするかというのを残しておく。

必要となるもの

壊れた時のために、Arch LinuxのLive USBなどが必要。OSが入っているパーティションをマウントして原因を探るために、用意しておいたほうがいいと思う。

対処法

まずはLive USBを挿し、UEFIの設定画面からLive USBを起動する。

起動したら、OSが入ってるパーティションをマウントし、Arch用のコマンドでchrootする。

root@arch$ mount /dev/sda6 /mnt
root@arch$ arch-chroot /mnt

sh-3.2$
# LANG=ja_JP.UTF-8だと化けてメッセージが見れない
sh-3.2$ export LANG=en_US.UTF-8

これで、普段使っているOSのログなどが見れるようになるので、ログを眺める。

# -b はブート時のログを見るもので、-1をつけると1回前のログが見れる
$ journalctl -b -1

眺めてると、NVIDIAのロードのあたりでコケてそうな雰囲気だったので、壊れる前にアップグレードしたNVIDIA関連のパッケージが悪さをしてるんだろうと当たりをつけた。

ということで、アップグレードしたパッケージをダウングレードする。

公式Wikiでは推奨していないし、依存を壊さないよう細心の注意を払う必要がある。またダウングレードする前に、バグ報告にちょっとでも時間を割いてくれるとうれしそうな雰囲気だった。

# 更新したパッケージを確認する
$ ls -lat /var/cache/pacman/pkg/ | head -10

# cacheから依存関係があるものをすべてダウングレード
$ pacman -U /var/cache/pacman/pkg/nvidia-346.59-1-x86_64.pkg.tar.xz /var/cache/pacman/pkg/nvidia-utils-346.59-1-x86_64.pkg.tar.xz /var/cache/pacman/pkg/nvidia-libgl-346.59-1-x86_64.pkg.tar.xz

今回はNVIDIAの349.16-1のパッケージが悪さをしていたようで、ダウングレードした結果、無事起動するようになった。

まとめ

同じような現象が起きた人の参考になれば最高。

Arch Linuxかわいいよ、Arch Linux。

2015-01-07

MacOSX（Yosemite）でシステム終了をフックする

MacOSX

Mac OSXのログアウトのフックを実現したくて、launchdを使ってbashのプロセス常駐させてtrapしたけど、blockせずにログアウトしていった。非常に味わい深い。

LoginHook、LogoutHookを使ってscript走らせればいいじゃんってドキュメントはいっぱい見つかるんだけど、2014年の9月頃にはすでにdeprecatedだって言われてて、Launch Daemons、Launch Agentsを使ってくれよなってAppleのドキュメントは言ってる。

Daemons and Services Programming Guide: Customizing Login and Logout

ただ、最初に言ったようにblockせずにソッ閉じされる。

解決方法

AppleScriptは実は簡単にApplicationにできる。普通にdialogとか出すだけでも可能っぽい。 AppleScript Editorでnotification出すコードを書いて保存時にFile FormatをApplicationにすればいい。

そこで、AppleScriptでApplicationを作って、StartupItemsに登録して、常駐させることにした。ログアウト時にはApplictionの終了イベントが来るはずで、夜フクロウとか使ってる人は分かると思うけど、終了時にダイアログが出てログアウトをblockする。なので、Applicationに終了イベントをフックする処理をAppleScriptで書いて、ダイアログを出すようにした。

on quit
  display dialog "退勤すんの？" buttons {"Yes", "Not yet"} default button "Not yet"

  if button returned of result is "Yes" then
    --change next row.
    do shell script "/usr/bin/say goodbye"
    continue quit
  else if button returned of result is "Not yet" then
    continue quit
  end if
end quit

アプリを作ってgithubに上げといたから、使いたければ使ってください。アプリ自体は2014年の9月頃に作ったものだけど、Yosemiteでも問題なく動いてるぞい。

https://github.com/terut/logouthook

2014-12-19

Rubyのモジュールでextend self

Ruby

冷静になってゆっくり理解すれば、そりゃそっかという話なんだけど、Railsプロジェクトのコードでめっちゃ混乱したので、書いておく。

TL;DR

extend selfは特異クラスへのincludeと等価というのがミソ。

混乱したコード

目にした瞬間これ本当に大丈夫なのかと思ったコード。

class ApplicationController < ActionController::Base
  # something

  class << ActionController::HttpAuthentication::Digest
    # seconds_to_timeoutを書き換えたい
    def validate_nonce(secret_key, request, value, seconds_to_timeout=60*60)
      # somthing
      super
    end
  end
end

このコードを見て、いやいやそりゃ大丈夫でしょと思う人はそっとタブを閉じるといい。

僕はというとあれ、superってどういうこと？ってなった。 Digestの特異クラス定義式を使って特異クラスにメソッドを追加しているのだけど、superをcallしてもメソッドが見つからず探索は終了しないかという疑問だ。つまり、メソッドは上書きされるはずではないかと思った。

ただこのコード、こいつ動くぞ！って驚きと共に動いていた。

そこでDigestの定義を見てみる。そうすると、モジュール自身に対してextend selfで定義してあった。

module ActionController
  module HttpAuthentication
    module Digest
      extend self

      # somthing

      def validate_nonce(secret_key, request, value, seconds_to_timeout=5*60)
        # something
      end
    end
  end
end

それでもなぜメソッドが上書きされないのかとか思っていたが、冒頭に書いたとおり、このモジュール自身に対してのextend selfが今回のミソで、これにより上書きされないようになる。より理解を深めるために、簡略化したコードで考える。

簡略化したコード

上記で説明したコードの周りを調べて簡略化すると次のようになる。 AがActionController::HttpAuthentication::DigestでHogeがApplicationController、hogeがvalidate_nonceといった感じ。

module A
  extend self

  def hoge
    puts "A" 
  end 
end

class Base
  def call
    A.hoge
  end 
end

class Test < Base
  class << A
    def hoge
      puts "test"
      super
    end 
  end 
end

Test.new.call

実行すると次のような結果だ。

$ ruby test.rb
test
A

superによりちゃんとメソッドがcallされていることが分かる。これを理解するために書き換えをしてみる。

module A
  #extend self

  class << self
     include A
  end

  def hoge
    puts "A" 
  end 
end

class Base
  def call
    A.hoge
  end 
end

class Test < Base
  class << A
    def hoge
      puts "test"
      super
    end 
  end 
end

Test.new.call

$ ruby test.rb
test
A

これを見ると謎が解ける。特異クラス定義式で定義されたhoge メソッドとモジュールのincludeによって定義されたhoge メソッドという関係なので、特異クラス定義式のhoge メソッドが先に呼ばれ、あとからモジュールで定義されたhoge メソッドが呼ばれるというわけだ。

モジュールのincludeに関してはメタプログラミング Rubyとか見ながら、自分で試してみるとモジュールのincludeによってモジュールが継承チェーンに挿入されていることが分かると思う。

まとめ

extend selfは怖くない。

includeうんぬんの辺りがわからない人はメタプログラミング Rubyを読みましょう！

メタプログラミングRuby

作者: Paolo Perrotta,角征典
出版社/メーカー: アスキー・メディアワークス
発売日: 2010/08/28
メディア: 大型本
購入: 18人クリック: 533回
この商品を含むブログ (125件) を見る