Gentoo Linux @ Floating Log

2009-12-21 (*)

# install-elisp

twitter で install-elisp という、emacs lisp のプログラムをインストールする emacs lisp プログラムに触れていた人がいた(作者っぽい)。 それをインストールする ebuild を書いた。

install-elisp が取ってきたプログラムをインストールする場所は自分で決められるのだが、~/.emacs.d/ に入れるようにサンプルが書いてあったのでその通りにした。 そして、そのことに安堵感を覚える自分がいる。 なぜか。

ホームディレクトリの下はパッケージ管理していないものが置いてあっても自己責任である。 たとえ依存関係を解決してくれなくても、そういうもの、と思うだけである。

翻って、常々気持ち悪いと思う Python の easy_install は、基本的に /usr/lib の下にある site-packages にファイルを置こうとする。 これがいけない(ということに、今回思い至った)。 easy_install のような仕組みは個人的なパッケージ導入に留まっていればいいのであって、システムとしてのパッケージ管理と競合するべきではない。 勿論、依存関係はどこに入れようと同じであるから、機能として重なる部分はあるのでそこは API などで提供して上げるのはいいと思う。 しかし、システムとして提供するものをインストールするのは、他人の領分を侵す行為であると思うのだ。

Windows にパッケージ管理が存在しないのは別問題なので、それは別途対処していただきたい。

posted at 20:50:24    #
 
2009-11-09 (*)

# _PyUnicodeUCS4_Decode

最近、おそらく Python を 2.6.4 に上げてから、Gentoo prefix の eix-sync というか正確にはそれが呼び出している layman がエラーを吐くようになった。 最後だけ貼付けておくと

"/.../usr/lib/python2.6/site-packages/layman/overlay.py", line 111, in read
    + str(error))
Exception: Failed to parse the overlay list!
Error was:
dlopen(/.../usr/lib/python2.6/site-packages/_xmlplus/parsers/pyexpat.bundle, 2):
 Symbol not found: _PyUnicodeUCS4_Decode
  Referenced from: /.../usr/lib/python2.6/site-packages/_xmlplus/parsers/pyexpat.bundle
  Expected in: flat namespace

という感じ。 何かヒントを、と bugzilla を見たら(layman のバグ溜まってるなあ) app-portage/layman-1.1.1: Missing dependancy to pyxml というのがあった。 ああ、pyxml か。 ということで、pyxml だけ再 emerge したら直った。

タイトルでぐぐったら何も出て来なかったので、くだらない話だけど書いておいた。

posted at 10:21:04    #
 
2009-07-14 (*)

# emacs-cvs-23.0.96

放置している間に 23.0.96 までバージョンが上がってきた。 そろそろリリースか? ということで、前回の 23.0.93 の時とほぼ同じように ebuild を修正した。

疑問が1つ。 open -a はどこからアプリケーションを探し出し、どこからアプリケーション名を取得するのか?

man には特に何も書いていないのだが、場所はどこでもよくて、名前はファイル名から、のようだ。 ~/Applications 辺りからシンボリックリンクを張って、複数バージョンを切り替えるようなことを考えていたのだが、シンボリックリンクは見てくれないという実験結果。 シンボリックが駄目ならハードリンク、ということで cp -la した。

あとはフォントが惨めだったので、この辺を参考に

(when (= emacs-major-version 23)
  (set-default-font "Courier-14")
  (modify-all-frames-parameters (list (assq 'font (frame-parameters)))) ;複数フレームに対応
  (set-fontset-font
   (frame-parameter nil 'font)
   'katakana-jisx0201
   '("Hiragino Maru Gothic Pro" . "iso10646-1"))
  (set-fontset-font
   (frame-parameter nil 'font)
   'japanese-jisx0212
   '("Hiragino Maru Gothic Pro" . "iso10646-1"))
  (set-fontset-font
   (frame-parameter nil 'font)
   'japanese-jisx0208
   '("M+1MN+IPAG" . "iso10646-1"))
  (set-fontset-font
   (frame-parameter nil 'font)
   'latin-iso8859-1
   '("courier" . "iso-10646-1"))
)

を .emacs に書いておく。 必要に応じて他の言語のフォントも指定しておくべきなのだろうが、この方法以外に簡単な方法があるのではないかという疑念(半分は期待)ゆえに今はこれぐらい。

posted at 00:40:48    #
 
2009-06-27 (*)

# 軽自動車 進化の半世紀

桂木洋二+GP企画センター「軽自動車 進化の半世紀」グランプリ出版(2008)。 何の意味も脈絡もなく、軽自動車の歴史を繙く。 戦前の小型車からスバル360とかアルトとかワゴンRとか時代を画した車種に触れながら淡々と現在まで語り通すという、どう考えても飽きが来そうな本だが意外に最後まで眠くもならずに読めた。

posted at 23:47:28    #
 
2009-05-05 (*)

# 続 Emacs 入れ替え

Emacs.app は動いているのだが、eselect emacs に何も現れない⇔$EPREFIX/usr/bin に emacs がない、という状況になっていることに気付いたのでもう少しどうにか。

make install に直接 exec_prefix を指定した。 $EPREFIX/usr/bin/emacs は使えるようになったが、警告が出る。

Warning: arch-dependent data dir ((ソースを展開した所)nextstep/Emacs.app/Contents/MacOS/libexec/emacs/23.0.93/i686-apple-darwin9/) does not exist.

libexec は exec_prefix では変わらないのか。 仕方ないので、libexecdir も同様に直接指定。 …ダメか。 この文字列はバイナリに埋め込まれているので、configure の段階で何かしないといけない。 思いっきり場当たり的な手として、configure した後の src/epaths.h の文字列を置換する。

他に何か見つけたらまた直すけど、当面これでしのげるんじゃないかな。

試したい人は http://bitbucket.org/mft/mft_experimental
からどうぞ。

posted at 16:49:20    #
 
2009-05-03 (*)

# Emacs 入れ替え

Emacs を入れ替えた。

きっかけは、liblockfile のアップデートに失敗したから。 これ自体は Gentoo Bug #268225 で解決したが、そもそも apple が OS X に付属させている emacs ではこのライブラリを使っていないので依存させない実験をしたかったのだ。 どうせ ebuild をいじってコンパイルし直すなら、23.0.9x にしよう、と。

まず、emacs-cvs パッケージだが、prefix ツリーには 23.0.9999-r1 しかない。 これは CVS から直接チェックアウトして…というもので、スナップショットの 23.0.9x 用は本来別に存在する。 ということで、ecopy =app-editors/emacs-cvs-23.0.93 で Gentoo Linux のツリーから取り込むのが最初。 で、当然、Mac に対応するコードはない。

今度は emacs-22.3-r2.ebuild から関係ありそうな部分を emacs-cvs-23.0.93.ebuild に取り入れて、emerge。 …と素直にいかなかった理由は aqua USE フラグが package.use.mask ファイルでマスクされていたから。 取れる対策は二つ: package.use.mask ファイルを編集してしまう、または aqua でない USE フラグを使う。 後で sync することを考えると後者がいいだろう。 じゃあ carbon で。

emerge してみる。 その途中画面で configure の結果が出るが、GUI 関係のものが何も選ばれていない雰囲気だったので、一度止める。 試しにソースが展開されているディレクトリで configure --help してみたら、--with-carbon の無いことが発覚。 一方 --with-ns に Cocoa が云々との記述が。 時代は Carbon ではなく Cocoa だ、と。 不安だったのでググってもみる。 まあその方向でいいらしい。

ということで、USE フラグを carbon から cocoa に変えて、configure に渡すオプションを --with-carbon から --with-ns に。 --enable-carbon-app はよく解らないのでコメントアウトして、多分こっちがいいだろうと --disable-ns-self-contained を加えておく。 Emacs.app の中に何でもかんでも詰め込まないようにするオプション。

さあこれで、とはいかないのが厳しいところ。 emerge の途中でソースディレクトリの何もかもが消えて無意味なシンボリックリンクだけが残った。 経験のない壊れ方だ。

ebuild コマンドで configure, compile, install と順に実行すると、install でこの現象が起こることが判った。 試しに compile まで済ませた段階から直接 make install をすると、消えない。 DISTDIR=${D} という常套句が余計ってこと?

しばらく悩んで、emake の前に make install しておく、という荒っぽい解決を思いつく。 ひとまず、これで emerge が終了するところまでこぎつけた。 (本当は make install までは必要ないので、後で make install-arch-dep に限定した。)

さて、できあがった Emacs.app は? と探してみたが見当たらない。 それもそのはずで、ソースを展開したディレクトリのサブディレクトリに作られることになっていた。 そして、このソースを展開したディレクトリは emerge が成功すると削除されてしまうのだ。 それならば、インストールディレクトリを別途指定すればいいはず、という期待も裏切られる。 実は configure スクリプトの中で、Emacs.app の作成場所はソースを展開したディレクトリ下の nextstep に決められてしまっていて動かせない。 さすがに configure.in の編集という方向は気が向かないので、できあがったものを削除される前に移動しておく、という方法を選択した。

長かったが、これで動く emacs-23.0.93 が手に入った。 (ついでに、liblockfile も既に依存から無くなっていたのでその実験は必要なかった。)

いままでの Carbon Emacs とキーバインドが違っていて、meta キーが option に割り当てられている。 今まで meta キーだった command は super?

posted at 08:25:52    #
 
2009-04-27 (*)

# オーバーレイを bitbucket に

自分の prefix オーバーレイを整理して bitbucket.org に置いた。

http://bitbucket.org/mft/mft_experimental

という情報をここに書いて、誰か見る人がいるのだろうか。

posted at 22:05:04    #
 
2009-04-17 (*)

# FAILED prerm は気にしなくてもいい

EAPI="prefix" がなくなった新しい prefix 用の portage で、EAPI="prefix" 時代にインストールしたパッケージをアンインストール(あるいはパッケージの更新)すると出る次のようなメッセージ:

!!! FAILED prerm: $EPREFIX/var/db/pkg/category/package/EAPI
Unable to do any operations on 'category/package', since it's EAPI is higher than this portage version's. Please upgrade to a portage version that supports EAPI 'prefix 0'.

は特に問題ないらしい。

posted at 11:54:56    #
 
2009-04-13 (*)

# Python 2.6 すら時期尚早

マスクが外れたと思って、嬉々として python-2.6.1-r1 を入れて python-updater で関連モジュールも全部 2.6 向けに入れ替える。

PyDS が動きません。 メタクラスに渡すものが間違っているとか何とか、ssl モジュールで死ぬ。

gae 関係のファイルを編集しようとしたら、django で None に代入しようとしているとか何とか、SyntaxError が出た。

という感じで、仕方ないので暫定的に 2.5 に戻す。

% eselect python set 1
% python-updater --old-version 2.6
posted at 17:02:08    #
 
2009-04-08 (*)

# X のキーボード設定

prefix でなく Gentoo Linux の話。 マシンは ThinkPad X61。

最近、X 1.5 が stable に下りてきて、eselect news でアップデートを促しているので、流れに乗る。 その news ではガイドを読んでくれというので一応読む。 大筋で「最近の X は HAL が面倒見てくれるから config いらずでちょーハッピー」みたいな内容。 ガイドを書いた人は HAL を当然のように見なしているが、(USE フラグに hal を追加して)インストールして、/etc/init.d/hald start しておく必要があった。

xorg.conf はどけておいても立ち上がって普通に使えそう。 とりあえず立ち上げてみてそう思ったのは事実。 が、問題があって、キーボードが us だということ。 慣れればそれでも何とかなりそうな気もするが、日本語変換がどうするのか判らなかったので、jp に戻したい。 そこでググった結果が Xorg7.4のキーボード設定をkwsk その3。 曰く~/.xinitrcに以下の行を加える。
setxkbmap -rules xorg -layout jp -model jp106 -option ctrl:swapcaps

問題解決。 と思いきや、カーソルキーが利いてない。 上の設定をする前は確かに使えたはず。 そこからは試行錯誤。 model を thinkpad にしてみたりは余計で、 結局ただ rules を evdev に変えれば良かったようだ。 ということで、最終的に ~/.xinitrc に

setxkbmap -rules evdev -layout jp -model jp106
posted at 23:56:00    #
 
2009-03-14 (*)

# ghostscript-gpl

ghostscript-esp がマスクされて、ghostscript-gpl に移行しなければならない状況になった。 しかし、x86-macos キーワードがまだ加えられていない。 試しに手元で package.keywords に入れて emerge してみたら、エラーが出た。 煩わしい。

原因は make so だ。 ちょっと古いけど gs-devel の過去ログから引用。

the autoconf build only supports 'make so' on linux. You'll have to use macosx.mak or copy the shared library linking flags from macos-fw.mak.

[gs-devel] libgs 8.50 build failure on Mac Os X
posted at 15:21:52    #
 
2008-12-28 (*)

# dev-lang/ruby-1.8.6_p287-r10

OS X では ext/readline でこける。 ぐぐったら、--with-readline-dir を付けるといいらしい、と幾つかのサイトで言われていた。

ebuild ファイルの econf の前に
myconf="--with-readline-dir=${EPREFIX}/usr ${myconf}"
を入れてみた。

直った。 仕組みは判らないけど直った。

posted at 15:28:16    #
 
2008-12-12 (*)

# dvcs と eselect

mercurial で管理している Python のパッケージがある。 仮に hoge だとしよう。

あるとき、少し手の込んだ変更を試したい、と思い隣に clone して huga とした。 ところが、Python のパッケージ名としては依然として hoge を使いたいのである。 そこで、元々の hoge を hogehoge として、hoge は huga へのシンボリックリンクとした。

そんなとき、hoge のユーザーがパッチをくれた。 もちろん実体が huga である現在の hoge も元の hoge のクローンから派生しているのだからそこでマージすることはできる。 しかし、huga の変更が生きるかどうか判らないので、やはり元の hoge にパッチを当てて確認するのが筋だろう。 そこで、hoge のシンボリックリンクを hogehoge に張り替えた。

こんなことを繰り返すことになったとしよう。 そのうち、クローンも増え始める。

状況の細部を無視すると、していることは「複数バージョン」をシンボリックリンクで「切り替える」ことだ。 それはどこかで聞いたことがあるシナリオだ。 eselect だ。

Gentoo を使っていない人のために説明すると、eselect とは元々 gcc だの binutils だの emacs だのの複数バージョンをインストールして使い分けたい人のために用意されている機構である。 昔はそういう要望に各パッケージが適当に対応していたが、その内インターフェイスを統一しようということになって出てきたもの、だと思う。

ということで、hoge.eselect ファイルを作る。 Gentoo のツールらしく、eselect ファイルも基本的に bash スクリプトである。 /usr/share/eselect/modules にいくつかファイルがあるので、真似をすれば大して難しくない。 そして作った hoge.eselect を /usr/share/eselect/modules に置く。 と、こんな感じで使える。

% eselect hoge show
Current target of hoge:
  huga      
% eselect hoge list
Available hoge targets:
  [1]   hogehoge
  [2]   huga *
% eselect hoge set 1
Switching hoge to hogehoge ...
%

まとめ: dvcs のクローンリポジトリを eselect で切り替えることができる。

他の人はどうやってこういう切り替えを実現しているのだろう。 特に Gentoo 以外の人は (多分似たような目的のツールがあるのだろうとは思うが)。

posted at 16:00:16    #
 
2008-10-12 (*)

# 偶数

Gentoo bugzilla の番号が偶数ばかり発行されるようになったようだ。 調べてみると(暇だな)、240457 は存在するが、240459 は「invalid Bug ID」と言われるので、境目はここらしい。 10月8日から?

posted at 02:10:24    #
 
2008-09-23 (*)

# sys-devel/gcc-apple-4.2.1_p5564

checking size of void *... configure: error: cannot compute sizeof (void *)
See `config.log' for more details.
make[2]: *** [configure-stage2-gcc] エラー 77
make[2]: ディレクトリ `/Users/tetsushi/Gentoo/var/tmp/portage/sys-devel/gcc-appl
e-4.2.1_p5564/work/build' から出ます
make[1]: *** [stage2-bubble] エラー 2
make[1]: ディレクトリ `/Users/tetsushi/Gentoo/var/tmp/portage/sys-devel/gcc-appl
e-4.2.1_p5564/work/build' から出ます
make: *** [bootstrap] エラー 2

訳わからんところで止まるなあ。 void * のサイズが判らないってどういうこと?

今使っている gcc-apple は 4.0.1_p5484 で、openssh 5.1_p1 のビルドに SSP がないと上手くいかない風なので、gcc のバージョンを上げてみようと思った訳だが、 そこから駄目とは。 原因を調べるのもかったるいなあ。

posted at 23:15:28    #
12月 2009
   1 2 3 4 5
6 7 8 9101112
13141516171819
20212223242526
2728293031  
11月
2009
 1月
2010

自宅 PC に入れている Linux ディストリビューション。(GentooTMGentoo Technologies, Inc. の商標です。)

Feed Icon Letterimage

Python
Desktop
Server

© 2009, Matsui Fe2+ Tetsushi