- githubでfork→作業→commit→rebaseでまとめる→push→GitHubでpull request
- git rebase -i [対象commitのhash] → 対象commitのhash~現在までがでてくる
- でてくるエディタで、pickをsquash にすると、その変更と直前の変更をまとめる
参考リンク
参考リンク
Debian wheezy の webkitgtk-3.0 で、$.ajax を async: true で呼びまくるとFDがリークするっぽい。
ちなみにPyGIから使用している。
まだちゃんと検証はしてないので嘘かも。
サイネージというほどのものではないけど、それ的なもののソフトウェアをつくるために、X上で外部プロセスのウィンドウをいじってどうにかするみたいなのを探した。
いろいろ当り最終的にlibwnckを見つけた。ウィンドウマネージャの操作ライブラリ。Pythonバインディングのpython-libwnckもある。
import wnck, gtk screen = wnck.screen_get_default() screen.force_update() windows = screen.get_windows()
これでウィンドウリスト (WnckWindowのリスト) が得られる。これに対して、
w = windows[0] w.get_name() # Window Name w.get_application().get_name() # Application Name w.get.get_class_group().get_name() # Class Name
こんな感じで情報を取得し、
w.set_geometry(wnck.WINDOW_GRAVITY_CURRENT, wnck.WINDOW_CHANGE_X | wnck.WINDOW_CHANGE_Y, 100,100,0,0) w.set_title("新しいタイトル") gdk_w = gtk.gdk.window_foreign_new(w.get_xid()) gdk_w.set_decorations(0) # デコレーションの削除 # 反映させる gtk.gdk.window_process_all_updates() gtk.gdk.flush()
こんな感じにウィンドウが操作できる。
ちなみに、python-wnckを使用するWebアプリをuwsgi上で動かしたらこんな感じのエラーが出てしばらくこまった。
172.29.4.50 - - [12/Mar/2014:22:59:39] "GET /info HTTP/1.1" 200 4 "" "Mozilla/5.0 (X11; Linux x86_64; rv:27.0) Gecko/20100101 Firefox/27.0" [pid: 15271|app: 0|req: 6/6] *.*.*.* () {32 vars in 508 bytes} [Wed Mar 12 22:59:39 2014] GET /set_center/info => generated 4 bytes in 6 msecs (HTTP/1.1 200) 4 headers in 138 bytes (1 switches on core 0) Wed Mar 12 22:59:41 2014 - !!! uWSGI process 15270 got Segmentation Fault !!! Wed Mar 12 22:59:41 2014 - *** backtrace of 15270 *** Wed Mar 12 22:59:41 2014 - uwsgi(uwsgi_backtrace+0x25) [0x431ea5] Wed Mar 12 22:59:41 2014 - uwsgi(uwsgi_segfault+0x21) [0x431f81] Wed Mar 12 22:59:41 2014 - /lib/x86_64-linux-gnu/libc.so.6(+0x324f0) [0x7fa477a794f0] Wed Mar 12 22:59:41 2014 - /usr/lib/libstartup-notification-1.so.0(sn_xcb_display_new+0x109) [0x7fa47201fa89] Wed Mar 12 22:59:41 2014 - /usr/lib/libstartup-notification-1.so.0(sn_display_new+0x2d) [0x7fa47201fb3d] Wed Mar 12 22:59:41 2014 - /usr/lib/libwnck-1.so.22(wnck_screen_get+0x117) [0x7fa474660617] Wed Mar 12 22:59:41 2014 - /usr/lib/python2.7/dist-packages/gtk-2.0/wnck.so(+0xa809) [0x7fa4748ac809] Wed Mar 12 22:59:41 2014 - /usr/lib/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x56fd) [0x7fa47521d04d] Wed Mar 12 22:59:41 2014 - /usr/lib/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x5b7b) [0x7fa47521d4cb] Wed Mar 12 22:59:41 2014 - /usr/lib/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x848) [0x7fa47521e2e8] Wed Mar 12 22:59:41 2014 - /usr/lib/libpython2.7.so.1.0(+0xa6917) [0x7fa475274917] Wed Mar 12 22:59:41 2014 - /usr/lib/libpython2.7.so.1.0(PyObject_Call+0x4e) [0x7fa475303d3e] Wed Mar 12 22:59:41 2014 - /usr/lib/libpython2.7.so.1.0(+0x184810) [0x7fa475352810] Wed Mar 12 22:59:41 2014 - /usr/lib/libpython2.7.so.1.0(PyObject_Call+0x4e) [0x7fa475303d3e] Wed Mar 12 22:59:41 2014 - /usr/lib/libpython2.7.so.1.0(PyEval_CallObjectWithKeywords+0x47) [0x7fa475304647] Wed Mar 12 22:59:41 2014 - /usr/lib/libpython2.7.so.1.0(PyInstance_New+0x7b) [0x7fa4752ec58b] Wed Mar 12 22:59:41 2014 - /usr/lib/libpython2.7.so.1.0(PyObject_Call+0x4e) [0x7fa475303d3e] Wed Mar 12 22:59:41 2014 - /usr/lib/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x2a57) [0x7fa47521a3a7] Wed Mar 12 22:59:41 2014 - /usr/lib/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x5b7b) [0x7fa47521d4cb] Wed Mar 12 22:59:41 2014 - /usr/lib/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x848) [0x7fa47521e2e8] Wed Mar 12 22:59:41 2014 - /usr/lib/libpython2.7.so.1.0(+0xa6917) [0x7fa475274917] Wed Mar 12 22:59:41 2014 - /usr/lib/libpython2.7.so.1.0(PyObject_Call+0x4e) [0x7fa475303d3e] Wed Mar 12 22:59:41 2014 - /usr/lib/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x2a57) [0x7fa47521a3a7] Wed Mar 12 22:59:41 2014 - /usr/lib/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x848) [0x7fa47521e2e8] Wed Mar 12 22:59:41 2014 - /usr/lib/libpython2.7.so.1.0(+0xa6917) [0x7fa475274917] Wed Mar 12 22:59:41 2014 - /usr/lib/libpython2.7.so.1.0(PyObject_Call+0x4e) [0x7fa475303d3e] Wed Mar 12 22:59:41 2014 - /usr/lib/libpython2.7.so.1.0(+0x184810) [0x7fa475352810] Wed Mar 12 22:59:41 2014 - /usr/lib/libpython2.7.so.1.0(PyObject_Call+0x4e) [0x7fa475303d3e] Wed Mar 12 22:59:41 2014 - /usr/lib/libpython2.7.so.1.0(+0x11c1ac) [0x7fa4752ea1ac] Wed Mar 12 22:59:41 2014 - /usr/lib/libpython2.7.so.1.0(PyObject_Call+0x4e) [0x7fa475303d3e] Wed Mar 12 22:59:41 2014 - /usr/lib/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x2a57) [0x7fa47521a3a7] Wed Mar 12 22:59:41 2014 - /usr/lib/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x848) [0x7fa47521e2e8] Wed Mar 12 22:59:41 2014 - /usr/lib/libpython2.7.so.1.0(+0xa6806) [0x7fa475274806] Wed Mar 12 22:59:41 2014 - /usr/lib/libpython2.7.so.1.0(PyObject_Call+0x4e) [0x7fa475303d3e] Wed Mar 12 22:59:41 2014 - /usr/lib/libpython2.7.so.1.0(+0x184810) [0x7fa475352810] Wed Mar 12 22:59:41 2014 - /usr/lib/libpython2.7.so.1.0(PyObject_Call+0x4e) [0x7fa475303d3e] Wed Mar 12 22:59:41 2014 - /usr/lib/libpython2.7.so.1.0(+0xcbdf6) [0x7fa475299df6] Wed Mar 12 22:59:41 2014 - /usr/lib/libpython2.7.so.1.0(PyObject_Call+0x4e) [0x7fa475303d3e] Wed Mar 12 22:59:41 2014 - /usr/lib/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x27dd) [0x7fa47521a12d] Wed Mar 12 22:59:41 2014 - /usr/lib/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x5b7b) [0x7fa47521d4cb] Wed Mar 12 22:59:41 2014 - *** end of backtrace *** Wed Mar 12 22:59:41 2014 - DAMN ! worker 2 (pid: 15270) died :( trying respawn ... Wed Mar 12 22:59:41 2014 - Respawned uWSGI worker 2 (new pid: 15296)
最初はなんかcherrypyかuWSGIのスレッドが有効になっちゃってて変な事がおこっているかと思ったけど、どうやらPython初期化後にforkしてからGTKとかX11のAPI使っているから発生しているよう。(断定的に調べていないので違うかも。)
uWSGIのlazyオプションを指定するとfork後の初期化になるようなので、それで改善した。
いろいろとパッケージアップデートしたらGDMで「Oh no」画面が出てログインできずに。
とりあえずログを見る。
# cat /var/log/Xorg.0.log ・・・ [ 184.547] (II) NOUVEAU(0): [XvMC] Extension initialized. [ 184.547] (==) NOUVEAU(0): DPMS enabled [ 184.547] (II) NOUVEAU(0): RandR 1.2 enabled, ignore the following RandR disabled message. [ 184.547] (--) RandR disabled [ 184.550] (EE) AIGLX error: dlopen of /usr/lib64/dri/nouveau_dri.so failed (libLLVM-3.1.so: cannot open shared object file: No such file or directory) [ 184.550] (EE) AIGLX: reverting to software rendering [ 184.550] (II) AIGLX: Screen 0 is not DRI capable [ 184.550] (EE) AIGLX error: dlopen of /usr/lib64/dri/swrast_dri.so failed (libLLVM-3.1.so: cannot open shared object file: No such file or directory) [ 184.550] (EE) GLX: could not load software renderer [ 184.550] (II) GLX: no usable GL providers found for screen 0 [ 184.553] (II) NOUVEAU(0): NVEnterVT is called. [ 184.580] (II) NOUVEAU(0): Setting screen physical size to 677 x 381 [ 184.580] resize called 2560 1440 ・・・
どうやらlibLLVM-3.1.soの読み込みに失敗している模様。まずそれが存在しているか、またldconfigで検索できるか確認する。
# locate libLLVM-3.1.so /usr/lib32/llvm/libLLVM-3.1.so /usr/lib64/llvm/libLLVM-3.1.so # ldconfig -p | grep libLLVM-3.1 (※なし) #
存在はしているようだけど、ldconfigで検索できていないっぽい。
とりあえずld.so.confに追加する。(今回は /etc/ld.so.conf.d/05llvm.conf として追加した)
追加したあとにldconfigも忘れずに。
# cat /etc/ld.so.conf.d/05llvm.conf /usr/lib32/llvm /usr/lib64/llvm # ldconfig
これでgdmをリスタートしたら直った。
# systemctl restart gdm
めでたし。
これはパッケージか何かのバグだろうか。
それとも何か設定が違っていたのだろうか。。。
Gentoo Linuxのネットブート関連のメモ。squashfs+aufsでブートするまで。
いろいろなwebサイト (Gentoo Linux ドキュメント – Gentooを用いたディスクレスノード, Gentoo Wiki Archives – HOWTO_Gentoo_Diskless_Install, etc.) を参考に、GentooのPXEブートにトライしていたが、どうもうまく行かず。
手始めにGentoo LiveのCDからgentoo.igz, gentoo (カーネル), image.squashfs をコピーして、そいつらを使って
APPEND initrd=gentoo-live/gentoo.igz ip=dhcp loop=gentoo-live/image.squashfs looptype=squashfs root=/dev/ram0 real_root=/dev/nfs nfsroot=172.29.4.10:/server/tftp udev nodevfs dodmraid cdroot
的な感じにしてトライ。
が、ブートできない。nfsマウントまで行かなかった。順次追っていく。
まずネットワークにつながっていないようだった。なのでまず現在動いている3.8.4のkernelとinitramfsをコピーして、LiveCDのgentoo, gentoo.igzと置き換えてみた。ネットワークドライバ (e1000e と r8169も一応) もちゃんとinitramfsに入れて。
→しかし起動せず。
仕方ないのでinitramfsのinitスクリプト色々見つつ、パラメータを追っていくとどうやらip=パラメータを指定しているとネットワークの設定 (udhcpc) が走らないようだったので、 APPENDパラメータの ip=dhcp を消した。
→とりあえずDHCPとnfsマウントまでできた。
あとはsquashfs+aufsで起動するようにする。aufsのパッチがデフォルトではカーネルに入って無いのでemerge aufs3する。後はカーネル起動時のパラメータにaufsを追加してOK。最終的にpxelinux.cfg/default の指定は下みたいな感じになった。
KERNEL boot/kernel-genkernel-x86_64-3.8.4-gentoo INITRD boot/initramfs-genkernel-x86_64-3.8.4-gentoo APPEND loop=images/gentoo-20130405.squashfs looptype=squashfs root=/dev/ram0 real_root=/dev/nfs nfsroot=xxx.xxx.xxx.xxx:/server/tftp udev nodevfs dodmraid cdroot aufs
ip=dhcpがいらないということに気づくまではしばらくつまづいて時間を食った。
まぁともかく、これで晴れて自在なイメージファイルでGentooをネットブートできるようになりました。めでたしめでたし。
(From: http://forums.fedoraforum.org/archive/index.php/t-270436.html)
ひさびさにemerge worldをしたあと、例のごとくいろいろと不具合が起こるわけですが。
今回は日本語入力にそれなりにハマる。これはもう英語で過ごせというお告げか。
さすがにそれは無理なのでとりあえず調べてみる。
ibus-daemonのログをとってみる。起動したままibusのバックエンドをAnthyとそうじゃないやつで切り替えてみる。
$ killall ibus-daemon $ ibus-daemon -v IBUS-Message: 22:06:40.512056: Engine xkb:us:altgr-intl:eng is already registered by other component Traceback (most recent call last): File "/usr/share/ibus-anthy/engine/main.py", line 26, in <module> import ibus ImportError: No module named ibus
どうやらibusのPythonモジュール読み込み失敗しているらしい。とりあえずemergeしてみる。
# emerge -av ibus * IMPORTANT: 8 news items need reading for repository 'gentoo'. * Use eselect news to read news items. These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R ~] app-i18n/ibus-1.4.99.20121006 USE="X dconf gconf gtk gtk3 introspection nls python -deprecated {-test} -vala" 0 kB
pythonは入ってるから大丈夫なはずなんだけどなぁ、と思ったけどふと「-deprecated」が怪しく感じてonにしてemergeした。
そしたら無事ibus-anthy自体は動くようになった。
ここからさらに。なぜかGnome 3.6での「Zenkaku_Hankaku」キーがショートカットとして使えない。
いろいろと探すと、VineSeedにそれらしいパッチがあった。
http://riksun.riken.go.jp/archives/Linux/vine/VineSeed/SRPMS.main/gnome-settings-daemon-3.6.3-1vl7.src.rpm
こんなかにある「gnome-settings-daemon-3.6.3-input-source-switch-zenkaku-hankaku.patch」を当てるverのebuildを作成してre-emergeしてみたが、ダメだった。
仕方ないので、xbindkeysを使用して無理やり解決。
まず切り替えスクリプトの用意。
(/usr/sunaga-lab/bin/switch-ibus-method)
#!/bin/bash ENGINE=`ibus engine` if [ s$ENGINE != "santhy" ]; then ENGINE="anthy" else ENGINE="xkb:jp::jpn" fi ibus engine $ENGINE
次にxbindkeysの設定。
$ emerge xbindkeys ... $ cat .xbindkeysrc "/usr/sunaga-lab/bin/switch-ibus-method" Mod2 + Zenkaku_Hankaku
あとは.xprofileにxbindkeysを追加して終わり。
とりあえず使えるようになった。初回だけちょっともたつくけど。仕方ない。