>>237 pykf, kconv CJKCodecs があるのでいまさらの感じですが、日本語の文字コードを判別する場合に、今だ必須プログラムだと思います。 文字コード変換は、当然 python 標準の CJKCodecs を使うべきです。 なぜ kconv-1.1.8p-3 なのか 1. kconv-1.1.8 C 言語バージョンをなぜ使わないのか C 言語バージョンは落ちると云う話を、昔よく聞きました。情報源は記憶にありません。 現在の安定版は、古いですが 1.1.8p-3 だと考えてます。問題があればパッチを当てることで対処するつもりです。 2. 新しいメンテナの最新版 python-kconv-1.3.1 をなぜ使わないのか 仕様に変更があったのか、動かないと言われたことがあります。またメンテを引き継いだと云われるけど、 http://sourceforge.jp/projects/kconv/ ここを見ると、2003-02-12 のバージョンのまま放置されてます。 どちらも優れたプログラムです。だた本質的に判断できない文字列が存在します。この場合、経験的に pykf は Shft_JIS 側、kconv は euc-jp 側の判断を下すようです。なので、どちらも必要です。適用範囲や対応エンコードも若干異なります。また、これらを利用したプログラムが存在します。たとえば COREBlog や JCodeChanger です。 kconv に関しては、作者が問題ありとしてますので、この辺は考慮しないといけません。 http://apache.noexistent.com/~mak/kconv/kconv/index_jp.html とは云うものの、自分で使った感じでは kconv すばらしいと思ってます。

spec ファイルで python ビルドする時のメモ。 rpm 作成時に、ビルドする場所は ~/rpm/BUILD の下です。そしてインストール場所は別の場所。多くは *.pyc や *.pyo ファイルが出来るのですが、これは少し困ります。インストール後の実行時に例外が起きたりして、エラートレースが表示された場合 ~/rpm/BUILD のディレクトリがまる見えになるからです。本当は実際のインストール場所を表示してほしいです。 python ライブラリの場合は *.pyc, *.pyo は消してしまった方が無難のようです。どうせ import すれば *.pyc は出来ますし、オプティマイズをかけた *.pyo もどれだけ効果があるのか疑わしい。たとえば、こんな記事があります。 http://zenkai.atransia.co.jp/blog/32 python アプリの場合にも、上記のことが云えるのかもしれませんが、独自に手段を用意してるものがあるようです。 skencil の場合には、setup.py に与えるパラメタを、下記のようにすれば良かったです。 ./setup.py install --dest-dir=%{buildroot} --prefix=%{_prefix} zope の場合には ./configure --no-compile と云うオプションがあります。 そしてインストール後に $INSTANCE/bin/compilezpy.py を実行します。

命名法は難しいなー PIL を VineSeed に上げるのに、勝手に python-Imaging と云う名前をでっち上げたのだけど、世間では python-imaging と云うじゃないですか。元もと野良ビルドで python-PIL なんて、何も考えないで付けていたのが遠因。確かに python-Imaging なんて名前は変ですね。そして斬られました;; パッケージ作成ポリシなどと云う哄笑なものを私が考えたのが間違い。python ライブラリの頭には "python-" と付けましょう、などと云うくらいしか頭になかった。元からあるパッケージ名が Imaging なのだから、プレフィックスを付けて、pythin-Imaging だろうと単細胞的な命名。じゃあ本当は Python Imaging Library のパッケージ名はどうすべきなのか。 バージョンの振り方についても Squeak などを考えると、頭が割れそうになるくらい難しいので止めて。たとえば COREBlog を例にしてみれば、バージョン 1.11 の次は 1.2 になってます。これはカンマを少数点と考えてると受け取れます。でも rpm の世界は逆 1.11 > 1.2 です。もちろん、パッケージングは、オリジナルに従属すべきもので、作者に意見を言うべき筋合ではありません。キッパリ。 とか考えてたら、python パッケージングポリシには命名法も必要なんだと、やっと今日解かりました。

python ライブラリのパッケージ作成ポリシーと spec template のセットみたいなものがあるといいかもしれませんね - と言われても、大御所が大勢居られる場に投稿する程の力量はありませんが、 誰かが進めないといけないと思ってるので、少し考えてみます。 python 関連パッケージングの原則は、下記の二つ 1) /usr/lib/python*/site-packages/ の下に入れるもの python ライブラリパッケージや、別ソフトのサブパッケージにかかわらず python の共有ライブラリ扱いは "python-" をプレフィックスとする。できれば、site-packages の下に単一ディレクトリを作りインストールすることが望ましい。 「独立アプリだけどそのライブラリが他から使われることも想定しているものがあったとすると 1) のほうにするという感じでしょうか」 はい、おっしゃる通りに考えてます。 2) 独立した python アプリは、たとえば /usr/lib 配下にまとめて入れるのが原則。 一般のパッケージで python ライブラリを提供するものも、自身のディレクトリ下に置く。 この場合 python ライブラリのバージョンをディレクトリパスなどで固定して指定しない。 一方、このライブラリを利用したい者は、自分でライブラリパスを設定し使用する。 この場合、python ライブラリのシンボリックリンクを参照するような方法でいけないのか考えてます。 python 本体や、関連パッケージが直接 /usr/lib/python*.* をリンクするように考えて作られているので、 少し調べないといけないと思ってます。この辺のことを解かってません。 例えば strings で *.pyc を見ると、ライブラリへのパスが見えるのですよね。 こんなことを考えた動機 1. python のマイナバージョンアップのたびに、関連するパッケージを調べないといけません。 そして一時に、スペック修正したり、リビルドするのは大変。 2. /usr/lib/python*.*/site-packages/ 以下が繁雑になってきたので、整理する必要があると考えた。 そう思うのなら提案すべき。 参考: http://www.python.jp/pipermail/python-ml-jp/2002-August/001762.html

最近 COREBlog ユーザが激増してるようです。 とりあえず Vine では Python/Zope 環境のベースは出来てると思いますが、python ライブラリのインストールで嵌まる話しをたまに見かけます。たとえば psycopg, pykf, kconv, PIL などですが。なので、必要な python ライブラリは VineSeed に上げることにしました。Zope のプロダクトに関しては、相変わらず、自分でどうぞと云うスタンスです。 とりあえず Zope と COREBlog を問題無くインストールでき、ZMI でプロダクト開発できる環境を作りたいなと思ってますが、今のままでは python ライブラリ関連が繁雑になりそうな気がしてます。整理する案を後で書きますので、よろしく御指導ください。

kernel-smp-2.4.30 にアップ。2.6 までの繋ぎと云うことなので、そろそろなのか? 1. 今まで append="apm=power-off" が必要だったけど、いらなくなったみたい。ちゃんと電源落ちます。 2. lm-sensors モジュールが 2.9.1 にアップ。試してみようかな? 3. 関係無いけど、何時の間にか、gnome-2.10 がちゃんと動くようになっていました。こちらは落ちません;; (パワーマネージメントに関しては linux 本家で揉めてたみたいだけど kernel-2.6 では落ち着いたのかな?) この二日、夏場に向けて、マシンの掃除とか雷対策などしてました。部屋のゴミ捨てたら、大分風通しも良くなりました。 もし lm-sensors 使えるなら嬉しいな。去年は挫折してるので。

apt-get したら sylpheed フォルダツリーのフォントが元の(大きい)サイズに戻ってしまった。 1.9.8 でツリー表示を GtkCTree クラスから GtkTreeView に変更したためらしい。 .sylpheed-2.0/gtkrc を次のように変更したら、"Arial 9" で表示されました。 ----------------------------------------- style "small" { font_name = "Arial 9" } #class "GtkCTree" style "small" class "GtkTreeView" style "small" ----------------------------------------- http://www.gtk.org/tutorial/sec-gtksrcfileformat.html

最近 gnome で落ちること多いです。と云っても gnome 使い出したのは最近ですが。 1. RADEON7000 + DVI + FlexScanL365 の相性が悪いのは有名な話し。 2. PEN4 のHT (インチキ SMP) + kernel-smp + acpi も怪しい (append="noapic acpi=off" にしたけどダメ) 3. RADEON ドライバで DRI エラーが出る。(xorg.conf で DRI を disable にした) 4. gnome-2.10 は発展途上。 5. python-2.4 になった。 などが原因かもしれない。まだ落ちます。gnome 立ち上がってしばらく経つとマシンごと落ちています。 ノートブック (VAIO) の方はまだ落ちたことありません。 X11 の不具合か gnome アプリが acpi 突っつくためかと推測したのですが、今のところ原因不明です。 と云うわけでメインの作業はやっぱり安定してる WindowMaker 環境でおこなってます。

>>232:原因はたぶん X11 関連と云うことにして置きます。 あたしも、どうもそのような気がします。 さっき、apt-get dist-upgrade したら、XOrg 関連がガラガラ up してから、挙動が安定してます。 ＃　ノーチラス君が、「 "applications:///Office" は正しい場所ではありません。 」 ＃　なんて言って、言うこと効いてくれないので、メインメニューの設定を変えられない。 ＃　これも、Gnome-2.10 が up された辺りからだもんねー。

>>225, 226 gnome 起動してパニックになったのは python-2.4 のせいでは無いようです。現在メインマシンでもちゃんと gnome 立ち上がっています。パニックになって以来、vine サイトから apt-get しただけで、python 関連はいじってません。原因はたぶん X11 関連と云うことにして置きます。 VineSeed では python に依存するパッケージが大分少なくなったようです。main で調べた範囲では authconfig, kudzu, libuser, libxml2, libxslt,newt, rpm だけでした。以前よりずっと減ってます。 もともと、基本ライブラリ→アプリケーションライブラリ→ツールライブラリ という関係にあるはずなので、メインにあるパッケージが python に依存してる状態が不自然だったのかもしれません。gnome が進化して tkinter を使ったツールが減ったのが大きいのかなとも思います。 特に問題が無ければ、python-2.4.1 と既にビルド済みの rpm を明日 upload します。