Momonga Linux Part 3
>>230 ありがとうございます。 avahi と hal は動くようになりました。 今度は acpid の起動が失敗するようになりました。 acpid: can't open /proc/acpi/event: Device or resource busy orz ps ax してみると hald-addon-acpi: listening on acpi kernel interface /proc/acpi/event って出るから、 acpid はもう要らないのかしらん。 >>231 > 今度は acpid の起動が失敗するようになりました。 > acpid: can't open /proc/acpi/event: Device or resource busy > 新しい hal に合わせて acpid も起動順が変更されています。 最新の acpid なら問題は出ないはず。 >さて、今の私のグチャグチャな環境を少しでもマトモにするには、何をすればイイでしょうか。 svn up して、最低、二周以上、オモコンを回した方が。 推奨されない option ですが、-i で、パッケージをインストールしながらビルドします。 フルビルドには良いでしょう。 >>233 うーん、オモコンフル回転は、このマシンでは無理っす。仕事に使っているもんで。 仕事用のマシンを別に用意してやればよいのですが、仕事もソコソコ忙しくて手が回らない。 仕事用のマシンで OmoiKondara -i inkscape をやった私がアホでした。今の所仕事に支障は 無いので、しばらく様子見です。 なお dosemu に関しては、devel の glibc を rpm -Uhv --force で入れたら動くようになりました。 しかし ・ldconfig が segmentation fault するのは治りません… ・rpm の db が頻繁に壊れるのも治りません… これらの問題が無ければ、devel にある *.rpm を片っぱしから rpm -Uhv --force で入れ直す ところなんですが。 さてウチのボロボロ環境についてはペンディングにするとして、 もうひとつ気になっていることがあります。やたらディスクアクセスが多いことです。 まず第一原因は trackerd でしょう。デスクトップ検索は、今のところ要らないのでこれは切る ことにしました。gnomeなどは使っていないので、手で .config/tracker/tracker.cfg を編集し、 EnableIndexing=false としてあります。 (私は runlevel 3 から startx で fvwm を使っているのですが、どこに trackerd を使う設定があるんでしょう?) さて trackerd のインデクシングが(たぶん)無くなったにも拘らず、まだディスクアクセスが起きます。 どうやらfirefox3の起動中に起きるようです。firefox3(?)は一体何をしているんでしょう。firefox 自身の動作がたびたび固まって数十秒ほど待たねばなりません。 >>235 fvwm が見ているか見ていないかは知りませんが、 GNOME や KDE では /etc/xdg/autostart/trackerd.desktop これが、login 時に trackerd を自動起動します。 /etc/xdg/autostart/tracker-applet.desktop これがアプレットの起動ファイル。 設定は $ tracker-preferences ですか。 使わないならアンインストールしちゃって良いのでは。 firefox は使っていないので分かりません。 tracker をアンインストールすると、依存性などから evince とかまで抜き取られます。 evince は使うこともあるので、単に tracker を使わない設定にしました。 firefox3 を起動して、単にこの Momonga板だけを表示させておき、topでメモリやCPUの 使用状況を眺めていると、時々 firefox が上に上がってきます。瞬間的に CPU 100% なんて こともあり、一体何をやってんだコイツ、と思ってしまいます。firefoxは軽さが身上だったのに、 最近は重くなりましたねえ… そもそもメモリ搭載量はいくつなのよ? 256MBしかないとか言うんじゃないよね。 なんか、Linuxはメモリ消費量が少なくてよいとか言ってた時代もあったが、そんなのは 遥か昔の事だ。今時だと推奨は1GB以上だろ。 firefoxがたまにおかしくなるのは今に始まった話でもないが。 trackerに含まれてるライブラリが、nautilusに要求されてたから、 yumで削除しようとしたら芋づるで大変な事になりそうだな。 やはり236の方法で使わない様にすべきか。 えーと firefox のディスクアクセスの件ですが、firefox3 では有名みたいですね。 攻撃・偽装サイトのデータベースを作っているらしいです。 設定→セキュリティ→ □表示中のサイトが攻撃サイトである疑いがある場合は警告する □表示中のサイトに偽装サイトの疑いがある場合は警告する のチェックをはずしたらディスクアクセスは無くなるようです。 あるいはdbファイルを ramdisk に置いて高速化している人も居るみたい。 firefox3 urlclassifier3.sqlite で検索すると出てきます。 >>233 acpid の情報、ありがとうございました。 >>236 /etc/xdg/autostart/ と tracker-preferences についてご教示、ありがとうございました。 tracker-preferences は tracker パッケージには入っていなくて、 tracker-search-tool パッケージ の方に入っているようですね。私の環境では、依存性のために tracker パッケージだけしかインストール されていなかったので、最初は入っていませんでした。man page だけはナゼかありました^^ >>229 >>234 の ldconfig の件も解決しました。 /var/cache/ldconfig/aux-cache を削除したら 治りました。きっとアップデートのとき、後処理のスクリプトが何かの理由で失敗したのでしょう。 rpm の db が壊れたときかも知れません。pre,preun,post,postun などのスクリプトが失敗している のが他にもありそうです。根本解決はクリーンインストールしか無いのでしょうね…。 めんどくさいなあ… nVidiaのGeForce FX5200を使ってます。 nVidia製のドライバを入れてあります。 今日の夕方は起動できたのですが、 先ほど夜に起動させようとしたところ、 udevの起動が終わってディスプレイがグラフィカルになった時から進まなくなりました。 マウスが写り、ローディング中のアイコン(winでいう砂時計)のまま コンソールウィンドウ(?)が表示されなく、2分や3分ほど待っても決して進む事はありませんでした。 (xorg.confのDriverに"nvidia"でも"nv"としても同様にストップしました) ただの一度、nvidiaと指定して古いカーネルを使った時だけ udevの後グラフィカルなコンソールに移らずにCUIでinitが進みログインまで行きました。 その後Driverを"nv"に書き換えstartxをするとGUIに移りました。 その後再起動させてしまい、ログインする事ができなくなりました。 どうにもしようが無くなったので結局KNOPPIXを使ってバックアップを取り、入れ直しました。 /var/log/messagesは退避させたのですが、 このような時はどのログを読めばよいのでしょうか。 恥ずかしい限りですが また再現したので今度はもう少し待ってみた所 画面が移り変わりました 完全に再現できたので書き込み致します 結論から書きますと、rootの規定言語を日本語にすると起動時間が長くなるみたいです 始めはどの部分で時間がかかってるのか分からなかったので bootchartを使ってどの部分で時間がかかってるのかを計る事にしました↓ 起動が長い方 http://uploader.jpn.org/up/10mb/src/houji0014.png.html 起動が短い方 http://uploader.jpn.org/up/10mb/src/houji0015.png.html ※画像が大きいのでjpg直リンしない所を借りました runlevel3で起動するとすんなり起動できたのでその辺りを考えると どうもrhgbあたりが良くないのかなーと予想し またrhgbが日本語になっていたのでrootの言語を日本語から英語に戻したところ 起動時間が劇的に縮まりました たったこれだけのことでした、失礼しましたf(^^; firefoxには firemacs という extension があり、Emacs ライクなキー操作が可能になります。 ところが Momonga の firefox では、 firemacs のバージョンが 3.x になったときから firemacs が効かなくなっていました。firefox2 でも、firefox3-beta5 でも、使えませんでした。 さてこのたび firefox-3.0 の正式リリースに伴ない、firefox3の公式ビルドをダウンロードして 起動してみると、firemacs はちゃんと使えます。という事は、Momonga におけビルドでどこかを いじっているために firemacs が使えなくなっているということになります。firefoxに詳しい方、 何か解決策はありませんでしょうか。 なお debian 方面で firefox の名称を Iceweasel に変更したために、やはり firemacs が 動かなくなった、と聞いた事があります。 >>247 × Momonga におけビルドで ○ Momonga におけるビルドで >>247 Iceweasel という名前で動かないのなら、 BonEcho でも Minefield でも動作しないかも。 >>247 firemacs.jar の中の init.js を下みたいにしたら動いたよ 9c9 < ua.search('Firefox/3|Iceweasel/3') > 0 ? 3 : --- > ua.search('Firefox/3|Iceweasel/3|Minefield/3') > 0 ? 3 : >>250 情報ありがとうございます。 すると firefox2/Mo4 で firemacs3.x が動かなかったのはどうしてなんでしょうね。 >>251 >>250 は firefox 3 の場合しか書いてない firefox 2 の場合を考えると、init.js の変更はこうなる 8,9c8,9 < var firefoxVersion = ua.search('Firefox/2|Iceweasel/2') > 0 ? 2 : < ua.search('Firefox/3|Iceweasel/3') > 0 ? 3 : --- > var firefoxVersion = ua.search('Firefox/2|Iceweasel/2|BonEcho/2') > 0 ? 2 : > ua.search('Firefox/3|Iceweasel/3|Minefield/3') > 0 ? 3 : Mo4のfirefox2は BonEcho だったのですか! スッキリしました。ありがとうございます。>>252-253 fvwm使っています。fvwm を 2.5.x にするため、fedora の Everything にあった srpm をビルドしてみました。 ( fedora10 のfvwm.specを使っていますが、fedora9 も fvwm-2.5.x系(2.5.24)です。f9もf10も同じようにビルドできます。) # Mo5 の ToDoList には載っていませんでしたが、Everything ディレクトリにあって Fedora ディレクトリに # 無いものは対象外でしょうか?? ☆☆☆ Moの trunk に無く、追加する必要のあったパッケージ ☆☆☆ (これは fedora10 ではなく fedora9 から入れた ) fvwmが直接 require しているものとして perl-File-MimeInfo-0.15-2 更にこれをビルドするために perl-Devel-Symdump-2.07-5 perl-File-BaseDir-0.03-2 perl-File-DesktopEntry-0.04-6 perl-Pod-Coverage-0.19-3 perl-Test-Pod-1.26-4 perl-Test-Pod-Coverage-1.08-5 を入れる必要がありました。Mo5にも入れて頂けると幸いです。 >>255 fedora10 ってのは、もちろん devel の事っす。 >更にこれをビルドするために > >perl-Devel-Symdump-2.07-5 >perl-File-BaseDir-0.03-2 >perl-File-DesktopEntry-0.04-6 >perl-Pod-Coverage-0.19-3 >perl-Test-Pod-1.26-4 >perl-Test-Pod-Coverage-1.08-5 > >を入れる必要がありました。Mo5にも入れて頂けると幸いです。 ありゃ、このうち >perl-Devel-Symdump-2.07-5 >perl-Pod-Coverage-0.19-3 >perl-Test-Pod-1.26-4 >perl-Test-Pod-Coverage-1.08-5 は既に入っていましたね。失礼しました。 Mo-trunk の inkscape-0.46 の関数プロットにあるバグ。inkscape の trunk では修正されていますが、 inkscapeの次のリリースは未だ先だと思うので… # diff -u /usr/share/inkscape/extensions/funcplot.py.orig /usr/share/inkscape/extensions/funcplot.py --- /usr/share/inkscape/extensions/funcplot.py.orig 2008-06-27 02:07:22.000000000 +0900 +++ /usr/share/inkscape/extensions/funcplot.py 2008-06-27 02:07:58.000000000 +0900 @@ -114,7 +114,7 @@ dx0 = (x1 - x0)/ds dy0 = (y1 - y0)/ds else: # derivative given by the user - dx0 = 0 # Only works for rectangular coordinates + dx0 = 1 # Only works for rectangular coordinates dy0 = fp(xstart) # Start curve @@ -138,7 +138,7 @@ dx1 = (x1 - x2)/ds dy1 = (y1 - y2)/ds else: # derivative given by the user - dx1 = 0 # Only works for rectangular coordinates + dx1 = 1 # Only works for rectangular coordinates dy1 = fp(x1) # create curve a.append([' C ', うーむ、2chだとスペースが削除されてしまうので diff がそのままでは使えんな。>>258 と入力で出力時にスペースに変わる こんな感じに連ねる事もできる こうか? --- /usr/share/inkscape/extensions/funcplot.py.orig 2008-06-27 02:07:22.000000000 +0900 +++ /usr/share/inkscape/extensions/funcplot.py 2008-06-27 02:07:58.000000000 +0900 @@ -114,7 +114,7 @@ dx0 = (x1 - x0)/ds dy0 = (y1 - y0)/ds else: # derivative given by the user - dx0 = 0 # Only works for rectangular coordinates + dx0 = 1 # Only works for rectangular coordinates dy0 = fp(xstart) # Start curve @@ -138,7 +138,7 @@ dx1 = (x1 - x2)/ds dy1 = (y1 - y2)/ds else: # derivative given by the user - dx1 = 0 # Only works for rectangular coordinates + dx1 = 1 # Only works for rectangular coordinates dy1 = fp(x1) # create curve a.append([' C ', >>258 trunkにcommitしました。ありがとうございました。 >>257 perl-File-BaseDir perl-File-DesktopEntry この2つは trunk に入れたよ。 >>265 ありがとうございます。 あと fedora の fvwm-2.5.x をビルドするには BuildRequires: libstroke-devel readline-devel libpng-devel fribidi-devel のうち libstroke が Moには入っていないので、これも入れて頂けるとありがたいです。 # libstroke は自分の所では半年前に入れたので、>>255-257 のときには気付かなかった。 正直に「fvwm2 を fvwm-2.5.26 にしてくれ」と書けばよいのですが、一応 2.5.x は fvwmの 開発バージョンなので、控えております。 なお最近の fvwm では、わざわざ fvwm2 と名乗るのは止めて、単に fvwm と名乗っています。 # fvwm1 なんて、いつの時代の話だよ… ようやくchroot下でのビルド手法を「発見」したのですね。 Mo4 on ThinkPad X40 の sleep (suspend to memory) の話。 無線LANは使っていないのでカードに給電していない (インジケータが点灯しない) のだが、 sleep から目覚めたあとに 無線LANカードのインジケータが点灯してしまう。けっこう電力を 消費するようで、キーボードが暖かくなる。 kernel-2.6.21 まではこののようにはならなかったのだが、kernel-2.6.23 からこうなった。 devel の kernel-2.6.25 でも改善しなかった。/etc/pm/sleep.d/ 下のスクリプト内で /sbin/ip link set dev wlan0 up /sbin/ip link set dev wlan0 down とすることで給電を切れている模様 (インジケータが消えるだけだが) で、一応回避できて いるので、まあ何と言うことも無いのだが、 スレが過疎っているようなので何となく。 X40 使っていますが。 無線、入れっぱなしだな... >>271 ath0 だったのが、いつの間にか wlan0 になってるんですが、何かご存知? >>272 対応 module が ath_pci と ath5k の二種類あるので、その差かも。 実は、少し前に Atheros のカードを抜いて、Intel の 2945ABG に 換えちゃったので、これ以上は追えません。 $ pkg-config --libs gtk+-2.0 Package xcb-xlib was not found in the pkg-config search path. Perhaps you should add the directory containing `xcb-xlib.pc' to the PKG_CONFIG_PATH environment variable Package 'xcb-xlib', required by 'X11', not found と出てしまうのですが pkg-configでgtk-2.0のインクルードファイルのパスやライブラリのパスを取得するには 他に何か入れなければいけないパッケージでもあるのでしょうか? pkg-config --list-all でも同様のエラーが表示されます 追記ですみません 関係あるか分かりませんが $ rpm -qa | grep libxcb libxcb-1.0-1m.mo4 です >>276 ありがとうございます >274より先に進みました しかしその後もfontencを入れるよう要求されたりして、結局 ptg-config --list-all が最後まで出力されないですね… Momongaでgtk-2.0など何かしらの開発してる人はどうやっているんでしょうか >>277 OmoiKondara回してるから、develパッケージはほとんど入ってるな〜 >>279 いや、今回のは、develパッケージのRequiresだから、、、 gtk+-2.0.pcのRequires:をspecでRequres:してないので、、、 >>281 trunkは修正済です。。。完全とは言いきれませんが。。。 今、Mo5リリースに向けて集中してるので、 STABLE_4の修正はおそらく実施しないと思います。 PPTPのクライアントは、どのパッケージに入っていますか? 本家鯖に5が追加されてましたけど 5が正式にリリースされるのは何月ぐらいになりますか? >>284 今alpha2だから、9月ごろじゃね? >>285 ありがとうございます、今から楽しみですね やはり大抵の人は設定を弄って4からアップデートするんでしょうか? >>286 http://developer.momonga-linux.org/wiki/?Momonga4%2B+%A4%AB%A4%E9+dist+%A4%D8sync まぁ、人柱乙と言うべきか、、、 ・ バージョンに問題があるパッケージを削除 ・ yum upgradeを実行 ・ upstartの設定変更 これぐらいでうまく行けば良い方です。xorg.conf関係の調整がこれ以降に発生してます。 >>287 > xorg.conf関係の調整がこれ以降に発生してます。 Mo4のときに Section "Device" Identifier "Videocard0" Driver "i810" EndSection だったが、i810 を intel にする必要があったな。 クリーンインストールでの環境移行のノウハウを持つべきだと思ってはいるのだけど、 毎年アップグレード+自力調整で何とか切り抜けている。 Mo5 Alpha2 ですが、acpid のログが出力されません。 /var/log/messages には簡単なものは出力されていますが、 Mo4では /var/log/acpid にもっと詳しいのが出力されていました。 alpha/alpha2 ってパッケージ数が少ないんですね。 yumのレポジトリを development と alpha の両方を有効にしておくと 「develにあってalphaに無いパッケージ」が大量にあることがわかる。 vlcが入ってなかったりするし、Mo4と比べてもパッケージが少ないと思われる。 これでアップグレードインストールをしようとすると、あらかじめ抜いておく 必要のあるパッケージが色々出てきてメンドクサイのですが… betaやRCでは devel並のパッケージ数になるのでしょうか? それとも Mo5 の 収録パッケージは基本的にalpha2と同程度になるのでしょうか? ちなみに次のは、alpha2にアップグレードしたマシンで数えたものです。 (installed には野良ビルドも含まれます。) $ yum list | grep installed | wc 1083 3249 87723 $ yum list | grep alpha2 | wc 503 1508 40743 $ yum list | grep development | wc 4300 12880 348300 スペースが削除されて見づらいな。 $ yum list | grep installed | wc 1083 3249 87723 $ yum list | grep alpha2 | wc 503 1508 40743 $ yum list | grep development | wc 4300 12880 348300 290です。どうやら私は momonga/test/5-Alpha2/ しか見ていなかったようですね。 momonga/5/Everything には (今のところ Alpha-1 のようですが) 全部あるみたい。 $ yum list | grep base | wc 3802 11387 307962 $ yum list | grep alpha2 | wc 1199 3596 97119 Alpha2 の hplip,hpijs について。hplip-2.8.2.tar.gz には ppd ファイルとしてたとえば hplip-2.8.2/ppd/hp-psc_2500_series-hpijs.ppd なんてのが用意されているけれど、/usr/share/foomatic/db/source/PPD/HP/ 以下に hp用の ppd をインストールしてくれる hpijs-2.8.2-2m.mo5.i686 には hp-psc_2500_series-hpijs.ppd が見当たりません。 hp-setup でセットアップしようとすると ppdファイルが無くて困ったのですが、 WEBブラウザで cups にアクセスして設定したら ppdファイルは見つかりました。 お騒がせしました。m(_,_)m opfc-ModuleHP-1.1.1-9m に入っている ipa フォントは /usr/share/fonts/ipa-mincho/ipam.ttf などの位置にありますが、 /usr/share/ghostscript/conf.d/cidfmap.ja.ipa 内の記述は /usr/share/fonts/truetype/japanese/ipam.ttf になっています。 /usr/share/fonts/truetype/japanese/ 以下の指定は古いバージョンのものですね。 しかし ipa のフォントのディレクトリを細かく分けたのはなぜ? ipaで1つのディレクトリにした方がわかりやすいと思うのですが。 sazanami-fonts-gothic sazanami-fonts-mincho に習っただけ。深い意味はなし。 trunk の opfc-ModuleHP は修正されたようですが、他にも /usr/share/fonts/truetype/japanaese/ 以下の フォントを参照しているファイルがあります。trunk で grep -r truetype pkgs | grep japanese | grep -v \.svn したものから anaconda/OBSO/ 以下を除外したものを掲げます。 ================================================================================= anaconda/anaconda-11.2.0.66-upd-instroot.patch:+usr/share/fonts/truetype/japanese/M+1P+IPAG.ttf anaconda/anaconda-11.4.0.36-upd-instroot.patch:+usr/share/fonts/truetype/japanese/M+1P+IPAG.ttf anaconda/anaconda-11.4.0.15-upd-instroot.patch:+usr/share/fonts/truetype/japanese/M+1P+IPAG.ttf anaconda/anaconda-11.4.0.70-upd-instroot.patch:+usr/share/fonts/truetype/japanese/M+1P+IPAG.ttf anaconda/anaconda-11.3.0.50-upd-instroot.patch:+usr/share/fonts/truetype/japanese/M+1P+IPAG.ttf anaconda/anaconda-11.4.0.27-upd-instroot.patch:+usr/share/fonts/truetype/japanese/M+1P+IPAG.ttf mythtv/mythtv.spec:ln -s %{_datadir}/fonts/truetype/japanese/kochi-gothic-subst.ttf %{buildroot}%{_datadir}/mythtv/kochi-gothic-subst.ttf mythtv/mythtv.spec:ln -s %{_datadir}/fonts/truetype/japanese/kochi-mincho-subst.ttf %{buildroot}%{_datadir}/mythtv/kochi-mincho-subst.ttf grass-i18n/grass-i18n.spec:%global ipa_fontdir %{_datadir}/X11/fonts/truetype/japanese-ipa ghostscript/cidfmap.ja.ipa:/IPA-Gothic << /FileType /TrueType /Path (/usr/share/fonts/truetype/japanese/ipag.ttf) /CSI [(Japan1) 6] >> ; ghostscript/cidfmap.ja.ipa:/IPA-Gothic-JaH << /FileType /TrueType /Path (/usr/share/fonts/truetype/japanese/ipag.ttf) /CSI [(Japan2) 0] >> ; ghostscript/cidfmap.ja.ipa:/IPA-Mincho << /FileType /TrueType /Path (/usr/share/fonts/truetype/japanese/ipam.ttf) /CSI [(Japan1) 6] >> ; ghostscript/cidfmap.ja.ipa:/IPA-Mincho-JaH << /FileType /TrueType /Path (/usr/share/fonts/truetype/japanese/ipam.ttf) /CSI [(Japan2) 0] >> ; ghostscript/cidfmap.ja.ipa:/IPA-PGothic << /FileType /TrueType /Path (/usr/share/fonts/truetype/japanese/ipagp.ttf) /CSI [(Japan1) 6] >> ; ghostscript/cidfmap.ja.ipa:/IPA-PGothic-JaH << /FileType /TrueType /Path (/usr/share/fonts/truetype/japanese/ipagp.ttf) /CSI [(Japan2) 0] >> ; ghostscript/cidfmap.ja.ipa:/IPA-PMincho << /FileType /TrueType /Path (/usr/share/fonts/truetype/japanese/ipamp.ttf) /CSI [(Japan1) 6] >> ; ghostscript/cidfmap.ja.ipa:/IPA-PMincho-JaH << /FileType /TrueType /Path (/usr/share/fonts/truetype/japanese/ipamp.ttf) /CSI [(Japan2) 0] >> ; ghostscript/ghostscript.spec: %{_datadir}/fonts/truetype/japanese \ ghostscript/cidfmap.ja:/IPA-Gothic << /FileType /TrueType /Path (/usr/share/fonts/truetype/japanese/ipag.ttf) /CSI [(Japan1) 6] >> ; ghostscript/cidfmap.ja:/IPA-Gothic-JaH << /FileType /TrueType /Path (/usr/share/fonts/truetype/japanese/ipag.ttf) /CSI [(Japan2) 0] >> ; ghostscript/cidfmap.ja:/IPA-Mincho << /FileType /TrueType /Path (/usr/share/fonts/truetype/japanese/ipam.ttf) /CSI [(Japan1) 6] >> ; ghostscript/cidfmap.ja:/IPA-Mincho-JaH << /FileType /TrueType /Path (/usr/share/fonts/truetype/japanese/ipam.ttf) /CSI [(Japan2) 0] >> ; ghostscript/cidfmap.ja:/IPA-PGothic << /FileType /TrueType /Path (/usr/share/fonts/truetype/japanese/ipagp.ttf) /CSI [(Japan1) 6] >> ; ghostscript/cidfmap.ja:/IPA-PGothic-JaH << /FileType /TrueType /Path (/usr/share/fonts/truetype/japanese/ipagp.ttf) /CSI [(Japan2) 0] >> ; ghostscript/cidfmap.ja:/IPA-PMincho << /FileType /TrueType /Path (/usr/share/fonts/truetype/japanese/ipamp.ttf) /CSI [(Japan1) 6] >> ; ghostscript/cidfmap.ja:/IPA-PMincho-JaH << /FileType /TrueType /Path (/usr/share/fonts/truetype/japanese/ipamp.ttf) /CSI [(Japan2) 0] >> ; ghostscript/FAPIcidfmap.ja:/IPA-Mincho << /Path (/usr/share/fonts/truetype/japanese/ipam.ttf) /CIDFontType 0 /FAPI /FreeType /CSI [(Japan1) 6] >> ; ghostscript/FAPIcidfmap.ja:/IPA-Gothic << /Path (/usr/share/fonts/truetype/japanese/ipag.ttf) /CIDFontType 0 /FAPI /FreeType /CSI [(Japan1) 6] >> ; ghostscript/FAPIcidfmap.ja:/IPA-PMincho << /Path (/usr/share/fonts/truetype/japanese/ipamp.ttf) /CIDFontType 0 /FAPI /FreeType /CSI [(Japan1) 6] >> ; ghostscript/FAPIcidfmap.ja:/IPA-PGothic << /Path (/usr/share/fonts/truetype/japanese/ipagp.ttf) /CIDFontType 0 /FAPI /FreeType /CSI [(Japan1) 6] >> ; ghostscript/FAPIcidfmap.ja:/Adobe-Japan1 << /Path (/usr/share/fonts/truetype/japanese/ipam.ttf) /CIDFontType 0 /FAPI /FreeType /CSI [(Japan1) 6] >> ; ghostscript/FAPIcidfmap.ja:/Adobe-Japan2 << /Path (/usr/share/fonts/truetype/japanese/ipag.ttf) /CIDFontType 0 /FAPI /FreeType /CSI [(Japan2) 0] >> ; ghostscript/FAPIcidfmap.ja:/Ryumin-Light << /Path (/usr/share/fonts/truetype/japanese/ipam.ttf) /CIDFontType 0 /FAPI /FreeType /CSI [(Japan1) 6] >> ; ghostscript/FAPIcidfmap.ja:/GothicBBB-Medium << /Path (/usr/share/fonts/truetype/japanese/ipag.ttf) /CIDFontType 0 /FAPI /FreeType /CSI [(Japan1) 6] >> ; kagemai/momonga-kagemai-0.8.4-gdchart.patch:+ :gd_font => '/usr/share/fonts/truetype/japanese/sazanami-gothic.ttf', blender/blender.spec:ln -s /usr/share/fonts/truetype/japanese/sazanami-gothic.ttf %{buildroot}%{_datadir}/%{name}/fonts/bfont.ttf blender/blender.spec: make it symlink to /usr/share/fonts/truetype/japanese/kochi-gothic.ttf) >>295-302 _、_ ( ,_ノ` ) n  ̄ \ ( E) グッジョブ!! フ /ヽ ヽ_// rails-2.1.0でfastladderがうごかなくなっちゃった。 あと、config/initializers/constants.rbには 最大未読数の設定があるので 上書きしないようにしてもらえるとうれしい。 http://developer.momonga-linux.org/wiki/?evdev には「xvkbdのことは man で読め」とあるのですが、Mo5の xvkbdパッケージには man page も無ければ /usr/share/doc/xvkbd もありません。 >>305 バージョンが上がって、man 無くなってるな〜 READMEを読んでください。 >>306 もちろん個人的にはソースをとりよせて解決しましたよーん。 SRPM からビルドすると、BUILDディレクトリにはちゃんと man がありまっせ。 rpmパッケージに入ってくれないという報告でした。 ttp://www.momonga-linux.org/~y/report0/ ttp://www.momonga-linux.org/~y/report0/ おもしろいね。 と書こうとして誤って投稿してしまった。 9/2から5betaが配布されましたが これは正式リリースが出た時にyum updateなどで正式リリースへアップデートできますか? >>312 やれば出来るとおもうが、そういう質問をしているなら 新規インストールマジオススメ。 Compiz用にxorg.confを設定したら画像ビューアのqivが暴走し、閉じれなくなりました。 鯖用にも使ってるんで原因は究明できないで申し訳ないですが。 Load "extmod" か Section "Extensions" Option "Composite" "Enable" EndSection あたりと推測 変更箇所はここを参考にしnvidiaの部分を実行していきました http://developer.momonga-linux.org/wiki/?Compiz+Fusion%A4%CE%BB%C8%A4%A4%CA%FD プロセスを切るとCPUを離してくれますが、画面は残ったままになります。 やはり>314っぽいですね 両方をコメントアウトしたらqivが固まらなくなりましたし、画像が正常に表示されました そして閉じる事もできました。 http://jd4linux.sourceforge.jp/ >(2) 2008年9月中旬に行われた2chの仕様変更によりバージョン 2.0.1 以前のJDでは 2chへの書き込みが出来ないようになっています。 >書き込みを行う場合はバージョン 2.0.2 以降にバージョンアップしてお使い下さい。 という事みたいです。 svnの方は見てないですが、srpmがまだ2.0.1だったので報告だけでも。 >>317 20 日に trunk STABLE_4 ともに jd-2.0.2-1m が投入されています > svn ☆ チン マチクタビレタ〜 マチクタビレタ〜 ☆ チン 〃 ∧_∧ / ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ヽ ___\(\・∀・) < Momonga5リリースマダ〜? \_/⊂ ⊂_ ) \_____________ / ̄ ̄ ̄ ̄ ̄ ̄ /| | ̄ ̄ ̄ ̄ ̄ ̄ ̄| | | 愛媛みかん |/ _ ___ \>,\/ <⌒/ヽ-、_ _ <_/____ノ 10日に起こして。 gimp2.6が出ましたが流石に1週間じゃ入れられないですよね trunkも2.4.7みたいですし Xでの一部のキーコードが、以前と違っているんですが、ウチだけでしょうか。 接続しているキーボードはUS配列のPC用キーボード (IBM・SpaceSaver2)で、USB ではなく PS/2 のもの。 /etc/X11/xorg.conf は Section "InputDevice" Identifier "Keyboard0" Driver "kbd" Option "XkbModel" "pc105" Option "XkbLayout" "us" Option "XkbOptions" "ctrl:nocaps" EndSection と指定しています。 たとえば 右ALT は以前にはキーコードが 113 だったはずですが、いつの間にか 108 が 出るようになっています。前者は /usr/share/X11/xkb/keycodes/xfree86 に記述され、 後者は /usr/share/X11/xkb/keycodes/evdev に記述されています。 他にもキートップ通りに出ないキーがあり、それは setxkbmap -rules evdev -model pc105 -layout us -option "ctrl:nocaps" のように、 -rules evdev を指定して setxkbmap を実行すれば、解消しますが、コード そのものは以前とは違うもののままです。 Xorgに何か仕様変更があったのでしょうか。 なお Mo5RC は新規インストールではなく、Mo4 → devel → Alpha1 → … と yum upgrade で ダラダラ新しくしていったものです。 すみません、 >他にもキートップ通りに出ないキーがあり、それは >setxkbmap -rules evdev -model pc105 -layout us -option "ctrl:nocaps" >のように、 -rules evdev を指定して setxkbmap を実行すれば、解消しますが、コード こっちは勘違いでした。 .Xmodmap による変更を一時的に抑止していたつもりが、実は抑止されていなくて、かつ キーコードの変化のおかげでキーのリマップが意図しないものになっていたのでした。 (.Xmodmap を keysym ではなく keycode で指定していたもので) というわけで、質問は 「XKBのルールセットが、xorg=base=旧xfree86 から evdev に変わった」という事実は あるのか、それともウチの環境が変なのか、どちらなのでしょう? というものです。 >>325 hal, xorg-x11-server, xorg-x11-drv-evdev の三つで 一時的に evdev になりましたが、キーボード認識 特に日本語キーボードで不具合が出たため hal-0.5.11-5m で evdev を利用しないよう、 つまり、従来の xorg.conf を使い xorg=base で動作するよう 戻されました 現在の hal-0.5.11-6m なら、xorg=base な rules で 動くはずです うーんそうですか。むしろ、ウチで変になったのは5RCからなんですが… ( Option "XkbRules" "base" は指定しました ) 不思議なのは追加でつないだUSBキーボードは xorg=base で認識されることです。 二つで違うのが不便なので、USBの方のキーボードドライバを evdev に変えて evdev に 揃えることはできましたが、逆に PS/2 の方はキーボードドライバーを kbd にしても evdev にしても rules が evdevになってしまうので、base=xorg で揃えることが 出来ないでいます。 個人的には、原因さえわかれば、「これからはevdevで揃える」でも構わないんですが… >>327 /usr/share/hal/fdi/policy/10osvendor/10-x11-input.fdi の中身を確認していただけませんか? ttp://developer.momonga-linux.org/viewvc/trunk/pkgs/hal/hal.spec?r1=26763&r2=26885 これを見ていただけるとお分かりになると思いますが、 %post で、パッケージインストール後に、10-x11-input.fdi を ttp://developer.momonga-linux.org/viewvc/trunk/pkgs/hal/10-x11-input.fdi?revision=26885&view=markup これに差し替えて、キーボード認識に hal を利用しなくしました。 この変更が適用されていれば、つまり、上の URL の 10-x11-input.fdi と、 /usr/share/hal/fdi/policy/10osvendor/10-x11-input.fdi が、同じなら、evdev は使われないはずなんですが。 ちなみに、何故、パッケージ本体に含まれるファイルではなく、%post で処理しているか、 というと、anaconda、インストーラで(インストール中に)、hal -> evdev によるキーボード認識を行うためです。 anaconda は、内部的に rpm2cpio でパッケージを展開して利用するだけで、%post などの処理は必要としないので、 このような対応が可能となります。 >>328 /usr/share/hal/fdi/policy/10osvendor/10-x11-input.fdi は新しくなっています。試しに古いのも試してみました。 /usr/share/doc/hal-0.5.11/examples/10-x11-input.fdi.orig が古いやつですよね。問題になっているデスクトップマシン (NECの水冷PC) では [古い 10-x11-input.fdi] PS/2接続もUSB接続もevdevになる。 [新しい 10-x11-input.fdi] PS/2接続はevdevに、USB接続はbaseになる。 という結果になりました。 なお別のマシン (ThinkPad X40) の内蔵キーボードは正しくbaseが使われています。 機械によっては、まだ evdev が使われてしまうんですかねえ。 /usr/share/hal/fdi/policy/10osvendor/ 下のファイルで「evdev」と記述のある ファイルを全部削除しても、やっぱり PS/2 のキーボードには evdev が使われてしまう。 >>329 原因がわかりました。 http://developer.momonga-linux.org/wiki/?evdev の記述に従い、マウスのチルトホイールを利用しようと、USBマウスに対して evdev ドライバを使用していた為に起きていたようです。しかし evdev を使わなくとも、 普通のマウスドライバ ( /usr/lib/xorg/modules/input/mouse_drv.so ) でも チルトホイールは使えるようなので、この evdev を使わないようにしたら、キーボードの ルールセットに base=xorg が用いられるようになりました。 しかしマウスに影響されるというのは、ちょっと納得が行かないな。halの設定によっては 回避できるのかも知れません。 read.cgi ver 07.5.5 2024/06/08 Walang Kapalit ★ | Donguri System Team 5ちゃんねる