no ski, no life

At last, my vaio type-p gets VT capability. Thanks to Microsoft and Sony!

Oct 29 22:33:03 localhost kernel: CPU1: Intel(R) Atom(TM) CPU Z540   @ 1.86GHz stepping 02
Oct 29 22:33:03 localhost kernel: kvm: enabling virtualization on CPU1
Oct 29 22:33:03 localhost kernel: CPU1 is up

I'll go to Japan Linux symposium Tokyo 20009 today.

I wrote a tiny experimental script named gktool.py to get and set secret (password) in gnome-keyring based on gksearch.py I wrote in the past and it is available from my github repo: gktool.py.

Sony Vaio Type-P has a VT-capable CPUs:</>

[root@localhost ~]# cat /proc/cpuinfo  | grep vmx
flags           : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx constant_tsc arch_perfmon pebs bts pni dtes64 monitor ds_cpl vmx est tm2 ssse3 xtpr pdcm lahf_lm tpr_shadow vnmi flexpriority
flags           : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx constant_tsc arch_perfmon pebs bts pni dtes64 monitor ds_cpl vmx est tm2 ssse3 xtpr pdcm lahf_lm tpr_shadow vnmi flexpriority
[root@localhost ~]#

But, unfortunately, they, SONY, disabled it and there's no BIOS option to enable it. And, to make things worse, SONY locked it and we cannot enable it by accessing msr with msr-tools

References: Enable VT-X on Mac Pro (Early 2008) - KVM, [Sony-vaio-z-series] Poor BIOS Memory Remap and VT support, HOWTO: Enable Intel VT on Sony VAIO notebook with AMI Aptio EFI BIOS - Tips - Levicki's Tech Spot - levicki.net.

P.S. VT 関連情報はないが、日本語の情報なら: VAIO type Pのまとめ Wiki にも。

I bought new libretto^H^H^H^H Vaio Type P aa(VGN-P90HS) and it finally arrived last week. I installed Fedora 11 alpha in it with the live usb image converted from the live DVD ISO image by livecd-iso-to-disk and it pretty works fine. I give some notes here for the record.

I need to edit /boot/grub/grub.conf and specify the root partition by label because the initrd image cannot detect / (lv_root) by UUID (default) for some reason:

 title Fedora (2.6.29-0.66.rc3.fc11.i686)
        root (hd0,0)
        kernel /vmlinuz-2.6.29-0.66.rc3.fc11.i686 ro vga=0x367  root=LABEL=F11-Alpha-i686-L rhgb quiet
        initrd /initrd-2.6.29-0.66.rc3.fc11.i686.img

X works but the default driver "vesa" automatically detected by X, feels very slow. So I switched to "fbdev" (xorg.conf). Its performance is still not good enough but we unfortunately have to wait until the driver gets ready (see Intel GMA 500 (Poulsbo) graphics on Linux: a precise and comprehensive summary as to why you’re screwed for more info).

I customized keymaps: /etc/hal/fdi/policy/10-keymap.fdi and arranged /tmp on ramdisk (and TMPDIR=/tmp/$USER):

# /etc/fstb:
tmpfs    /tmp    tmpfs   defaults,size=512m,noatime,mode=1777 0 0

Add to this, I customize firefox to make it saving cache under /tmp; add "browser.cache.disk.parent_directory" key (about:config) and set its value to "/tmp/$USER".

I keep maintain my user-level configurations (Configurations for ssh, gnupg, screen, vim, zsh, firefox, mutt, etc.) in $HOME/repos/config.git/. All I had to do for user-level configuration is just copying that dir and run "make" to setup appropriate symlinks (e.g. ln -s $HOME/repos/config.git/core/ssh $HOME/.ssh).

Today, I completely removed /etc/X11/xorg.conf at last.

[ssato@localhost policy]$ ls /etc/X11/xorg.conf
ls: cannot access /etc/X11/xorg.conf: No such file or directory
[ssato@localhost policy]$

I did not need to do anything except for a hal configuration:

[ssato@localhost policy]$ pwd
/etc/hal/fdi/policy
[ssato@localhost policy]$ ls
10-keymap.fdi
[ssato@localhost policy]$ diff -u \
> /usr/share/hal/fdi/policy/10osvendor/10-keymap.fdi 10-keymap.fdi
--- /usr/share/hal/fdi/policy/10osvendor/10-keymap.fdi  2008-12-22 09:19:30.000000000 +0900
+++ 10-keymap.fdi       2009-02-11 11:01:41.000000000 +0900
@@ -18,6 +18,8 @@
 
       <merge key="input.xkb.layout" type="string">us</merge>
       <merge key="input.xkb.variant" type="string" />
+
+      <merge key="input.x11_options.XkbOptions" type="string">ctrl:nocaps</merge>
     </match>
   </device>
 </deviceinfo>
[ssato@localhost policy]$ sudo service haldaemon restart
...

Update: I found I don't need to edit /usr/share/hal/fdi/policy/10osvendor/10-keymap.fdi directly. Instead, I copy the modified version as /etc/hal/fdi/policy/10-keymap.fdi. It seems that haldaemon read it and apply custom configurations in it in priority to the default (/usr/share/...).

It seems that I'm listed as one of linux kernel hackers in Japan although I'm even not a C programmer: Japanese Linux hacker (@ 詳解ファイルシステム)

My patch was merged into upstream: [msmtp] Index of /msmtp

The previous patch for mutt does not work actually. And I've been working on fixing it. I've just started investigating how to debug mutt. It would take some time.

Alternatively, there is a way to use gnome-keyring with mutt.

Mutt can execute other external program like this

# imap_pass: read from script's output:
source "~/.mutt/gksearch.py -s -f mutt -t network -a user:USER,server:SERVER,protocol:imaps|"

'|' (pipe) at the end of the line is important. It indicates mutt to execute it. [Mutt manual: 3.24 Reading initialization commands from another file].

The quickly-hacked script, ~/.mutt/gksearch.py is here: gksearch.py. (chmod ao-r,ao-x ~/.mutt/gksearch.py to prevent running it by others.)

Update: I updated my script (gksearch.py) to output results in python string format. The above muttrc code also has to be changed like this:

source "~/.mutt/gksearch.py -f 'set imap_pass = \"%(secret)s\"' -t network -a user:USER,server:SERVER,protocol:imaps|"

It seems that msmtp distributed under GPLv3+ supports Mac OS X keychain. (snip) I updated my patch for msmtp (msmtp-gnome-keyring.patch). It works well and I removed plain password texts from my ~/.msmtprc.

Basically, it does the same thing but it gets much simplified. I choose network password instead of generic secret type to keep secret and its associated parameters; user, server and protocol.

In addition, I noted some code snippets to access gnome-keyring with its python binding below just for the record. There is not much documents for gnome-keyring, so I tried and figured ways to access keyring and control secrets and its associated information out along the way with using ipython.

NOTE: If you try to play with these snippets, I recommend you to backup your keyring before that as my code might make your keyring corrupted.

>>>
>>> import gnomekeyring as gk
>>> import glib
>>>
>>> # Set temporal application name. gnome-keyring requires this.
>>> # (it will be replaced later).
>>> glib.set_application_name("msmtp")
>>>                                     
>>> # get default keyring name. you can also specify it explicitly.
>>> keyring = gk.get_default_keyring_sync()
>>>
>>> # display name for password.
>>> display_name = 'SMTP secret for foo@example.com/smtp.example.com'
>>>
>>> # select type. if you want some kind of "network" password, it seems that
>>> # appropriate type is network_password because it has a schema already.
>>> type = gk.ITEM_NETWORK_PASSWORD
>>>
>>> # just a utility function to create attrs easily.
>>> def parse(s):
>>>    ret = {}
>>>    try:
>>>        ret = dict([(k,v) for k,v in [x.split(':') for x in s.split(',')] if k and v])
>>>    except ValueError:
>>>        pass
>>>    return ret
>>>
>>> # create attrs :: {} (dict)
>>> attrs = {
>>>  'user':None, 'domain':None, 'server':None, 'object':None,
>>>   'protocol':None, 'authtype':None, 'port':None,
>>>}
>>> usr_attrs = parse("server:smtp.example.com,user:foo@example.com,protocol:smtp")
>>> attrs.update(usr_attrs) 
>>>
>>> # Then, set password.
>>> secret = 'xxxxxxxxx'
>>>
>>> # Now it gets ready to add into the keyring. Do it.
>>> # Its id will be returned if success or an excpetion will be raised.
>>> id = gk.item_create_sync(keyring, type, display_name, usr_attrs, secret, False)
>>>
>>>
>>> # you can search it. (results :: [matched_network_password_info_dict, ...]
>>> results = gk.find_network_password_sync(**attrs)
>>> results = gk.find_network_password_sync(user='foo@example.com', 
>>>                      domain=None, server=...)
>>> # r = results[0]
>>> # r.get('item_id'), r.get('secret'), r.get('server'), ....
>>>
>>> # another way.
>>> # NOTE: Returned objects is *different* from the above. (not dict)
>>> results = gk.find_items_sync(type, attrs)
>>> 
>>> if results:
>>>    res = results[0]
>>>    # res.keyring, res.item_id, res.attributes, res.secret
>>>    info = gk.item_get_info_sync(res.keyring, res.item_id)
>>>    # info.get_display_name()
>>>
>>>
>>> # allow application 'msmtp' (/usr/bin/msmtp) to r/w access to this secret.
>>> acontrol = gk.AccessControl(gk.ApplicationRef(), gk.ACCESS_READ | gk.ACCESS_WRITE)
>>> acontrol.set_display_name('msmtp')
>>> acontrol.set_path_name('/usr/bin/msmtp')
>>>
>>> acontrol_list = gk.item_get_acl_sync(keyring, id)
>>> acontrol_list.append(acontrol)
>>>
>>> gk.item_set_acl_sync(keyring, id, acontrol_list)
>>>

幻影師アイゼンハイム (Original title: The illusionist; I prefer this title than Japanese one) will be screened in Japan at last!

During this Golden Week holidays, I worked for a iproute issue. While looking thru the source tree, I made and posted some trivial refactoring patches for current linux kernel. Fortunately, all of these are merged into davem.net-2.6 tree with no objections.

Next, I will work for the original problem and hopefully, I'll make a series of patches for both linux and iproute2 to fix it until next weekend.

TODO: Both thunderbird and gmail web interface have problem on posting patches to lkml, etc. I have to switch to other mailer (how about trying mutt?) can format an inline patch w/o any modifications.

The authors of Real World Haskell are publishing the draft of the book on the web and looks wanting feedbacks: Real World Haskell (beta)

M. I. (Medical Investigation) comes on the air again!

To do some translation reviewing work, I wrote a simple script (extract_terms.py) which extract terms from Japanese text.

Basically, it is a fork of mword. I modified/enhanced and optimized it for my purpose. It is written in Python and uses MeCab to parse Japanese text same as mword, so you need python binding for MeCab (python-mecab in Fedora) to run.

With using it, now I can generate something like a glossary from translated po files automagically like this:

ssato@gescom% make glossary 
Makefile:16: pofiles.mk: そのようなファイルやディレクトリはありません
rm -f pofiles.mk
echo -ne 'pofiles = ' > pofiles.mk
find ../Documentation/XXXX -name '*.po' -printf '%p ' 2>/dev/null >> pofiles.mk
./pocompendium --strip-accel-amp --strip-accel-tilde --strip-accel-under compendium.po -d ../Documentation/XXXX/A ../Documentation/XXXXX/B
./posplit ./compendium.po
po2csv --psyco=full  -i compendium-translated.po -o compendium-translated.csv
processing 1 files...
[###########################################] 100%
./pocsv2translations.py compendium-translated.csv > compendium-translated.translations
./extract_terms.py compendium-translated.translations | sort -r -g -k 2 > glossary.txt
ssato@gescom% sort -k 2 -rn glossary.txt |head
サーバー        447.0
サービス        367.423461417
アドレス        323.332646047
...
ファイル        200.858158908
データ  200.818325857
ネットワーク    155.563491861
ユーザー        144.519894824
ssato@gescom%

Oops, I found a bug duplicates single nouns (! compound noun) twice. I'll fix that asap...

Yesterday, I quickly hacked Graphviz Plugin for trac to add Mscgen, message sequence chart generator, support. Some minor problems remained still, though, it works fine (at least for me). A patch and sample screenshot are here: Ticket#2308: [PATCH] Add mscgen support to GraphvizPlugin.

Systemtap rocks! It helps a lot to find out linux kernel issues.

Do look through usecases and sample codes, read tapsets, documentations and try it out.

何と...

日頃よりシスコをご愛顧頂き誠にありがとうございます。レコードショップ・シスコは今後通信販売に特化し運営させて頂く事となり永らくご利用頂きました店舗は 12 月 10 日を持ちまして閉店とさせて頂きます。

[Cisco Records]

..: Re: License review for new itext version, RH BZ#236309

It seems i18n/l10n-ed (available in Japanese). Cool.