09/04/24 23:04:49
>>552
> >>535 どうでもいいけど動かない環境を維持する意味が不明だ。
> 最新版にしたらおかしくなった。だから戻した。それでいいじゃん。
> 解決能力がないんだったらデフォルトのセッティングをかえるべきではない。
> だから>>535がintelも含めて安定動作するようになってもhal無しで運用すべきではないってことだ。
何が言いたいのかさっぱりわからん。
>> 535 が言っているのは
・hal の有無にかかわらず最新の intel ドライバではうまく動作しない
・古いドライバでも hal ありだと不都合がある
・hal 無し＆古いドライバだと動く
ということだろ。
568:名無しさん＠お腹いっぱい。
09/04/25 22:32:05
>>526
遅レスでなんだが、
> 特に動画関係はdbus使ってんだろ。
動画再生がdbus必須なら、dbus対応していないマシンに ssh -Y
とかで入って mplayer とかで再生したら何が起きるの？
569:名無しさん＠お腹いっぱい。
09/04/25 22:41:26
うちゅうのほうそくがみだれる
570:名無しさん＠お腹いっぱい。
09/04/25 23:01:13
だいうちゅうがこっぱみじんになる
571:名無しさん＠お腹いっぱい。
09/04/26 14:15:34
firefox3-develが来たので入れてみたが、既存のfirefox3を上書きしやがったｗｗ
別名や別ディレクトリで入れてくると思い込んでいた…
572:名無しさん＠お腹いっぱい。
09/04/26 14:43:01
なにもかも>>571がCONFLICTS=を入れろっていうsend-prをしないせい
573:名無しさん＠お腹いっぱい。
09/04/26 15:07:39
>>572
CONFLICTS=～じゃないだろ
574:名無しさん＠お腹いっぱい。
09/04/26 15:51:34
MOZILLA_SUFX=3をMOZILLA_SUFX=3-develとかにすれば上書きは回避できそうな気がする。
575:名無しさん＠お腹いっぱい。
09/04/26 17:53:59
>>571
いままでもそんな選択的portsはけっこうあったろうに、なんで別だと思い込んでんだよｗｗ
576:名無しさん＠お腹いっぱい。
09/04/27 13:21:25
俺用メモ
URLﾘﾝｸ(www.sic.shibaura-it.ac.jp)
URLﾘﾝｸ(d.hatena.ne.jp)
URLﾘﾝｸ(www.karashi.org)
URLﾘﾝｸ(www.archivum.info)
Packageとdistfilesのサーバをつくるにゃ
どれくらいHDDに領域を確保すればいいのやら
577:名無しさん＠お腹いっぱい。
09/04/27 13:47:51
問題になるほどサイズないだろ
578:名無しさん＠お腹いっぱい。
09/04/27 14:46:17
とりあえず */*/distinfo のSIZEを重複なしに足したら75GBくらい。
579:名無しさん＠お腹いっぱい。
09/04/27 14:46:57
たったの75GBか…ゴミめ
580:名無しさん＠お腹いっぱい。
09/04/27 14:47:34
7yen/GB
581:名無しさん＠お腹いっぱい。
09/04/27 15:50:31
>>578
全部入れるとするとそれだけ必要なんですか
自前でPackageとdistfilesのサーバをつくるときって
たいていは頻繁に使うパッケージだけを置いておくだけでいいんですよね？
2万以上のportsを全部自前でミラーリングしてきて
管理している猛者っているのかな・・・
582:名無しさん＠お腹いっぱい。
09/04/27 20:25:41
firefox3を3.0.9に上げたらcore吐くようになったぜ
583:名無しさん＠お腹いっぱい。
09/04/27 21:57:42
scimを消したら動くようになった
入れ直してみるかな
584:名無しさん＠お腹いっぱい。
09/04/27 23:33:57
helper-manager が core を吐くしな
585:名無しさん＠お腹いっぱい。
09/04/27 23:50:15
そいつは、俺の経験では、
・NISを使わないようにすると吐かなくなることもある
・-DWITH_DEBUGでコンパイルすると吐かなくなることもある
その他、誰かのブログによると、
・try_dlopen() の結果をエラー扱いにすると吐かなくなる
・kdmとの実行順序を変えると吐かなくなる
・pthreadがらみか
あと、1.4.[89]あたりのコメントによると、
・module.unload()をしない（または遅らせる）と吐かなくなるかも
pthreadがらみが濃厚。後は誰かよろしく。
586:名無しさん＠お腹いっぱい。
09/04/28 07:36:38
>>583
ずいぶん前からGTKのアプリとscim-anthyでcoreを吐く場合があったので、色々調べてたんだけど、
scimやらなんやらのコンパイルオプション(-O, -O2 とか）で吐かなくなったり吐いたり、かなり微妙なタイミングで起きてる模様。
scimの作者に連絡したけど、返信来ず。
間違ってるかもしれんしうろ覚えだけど、scimがマルチスレッドで動いていて、スレッド間の微妙なタイミングで
起こってたかもしれない。
587:名無しさん＠お腹いっぱい。
09/04/28 07:51:18
根本的な解決法じゃないけど、gcc34 でコンパイルすると helper-manager はコア吐かなくなった。
588:名無しさん＠お腹いっぱい。
09/04/28 09:56:30
>>582
これか?
www.mozilla-japan.org/security/announce/2009/mfsa2009-23.html
Firefox 3.0.9 で行われたセキュリティ問題の修正のひとつによって、
一部のユーザが頻繁にクラッシュに遭遇するというリグレッションが生じてしまいました。
589:名無しさん＠お腹いっぱい。
09/04/28 10:04:05
>>588
なるほど。
ただ、そもそも起動途中に落ちるので、リグレッション以前の状態だったんだけど、
scimのコンパイルしなおしで回避できた。
あと、gcc34はscim-helper-manager問題に確かに効果あるみたい。
そういえばgtkがらみのアプリのcoreが10個ぐらいホームにあったよ。
これも全部scimがらみだったのか、gcc34版をしばらく使ってみる。
590:名無しさん＠お腹いっぱい。
09/04/29 10:52:28
PC-BSD 7.2Rをインストールしたら、デフォルトの環境で普通にYouTubeやら
ニコニコ動画が見れて感動した。
Flash9が実用上問題無い程度に使える。
PC-BSDってFlash関連で何か特別なチューニングしているの？
これに対してFreeBSD 7.2-PRERELEASEで、最新のportsから、
Firefox3やらFlash9 をインストールして、YouTubeやニコニコ動画を見ると
フリーズすることが多い。
普通のFlashを使っているWebページは大丈夫なんだが。
591:名無しさん＠お腹いっぱい。
09/04/29 11:00:02
>>590
あ、PC-BSDって7.1Rなのな。
592:名無しさん＠お腹いっぱい。
09/04/29 11:31:27
>>590
adobeと契約してるから
593:名無しさん＠お腹いっぱい。
09/04/29 12:06:06
それはLinux版の再配布契約をしたってだけで、
FreeBSDで安定動作するプレーヤーの供給とかじゃないでしょ？
594:名無しさん＠お腹いっぱい。
09/04/29 14:21:34
>>590
一体何を比べてるのか判るように書くべき。
595:名無しさん＠お腹いっぱい。
09/04/29 17:22:04
>>590
多分、PC-BSD はそういうあれこれが安定してるバージョンで
パッケージにしてるんじゃないかな？
ports の最新がいつも安定して動作するバージョンであるとは
限らない。
596:名無しさん＠お腹いっぱい。
09/04/29 18:14:52
意外と8.0-CURRENTからlinux emuをMFCしていたりして。
597:名無しさん＠お腹いっぱい。
09/04/29 19:05:50
現実問題としてFlash9,10に関してはLinux版よりWin版をwine上で使う方が確実じゃないのか?
598:名無しさん＠お腹いっぱい。
09/04/29 21:04:31
一旦は youtube もニコ動も動いてたけど最近「最新の
flash を入れろ」って言われて動かない。どうも
firefox3 と flash の関係がよくわからないんだよな。
nspluginwrapper が何してるのかもわからないし、
後藤さんのページ見て linux_base も fc8 にしたけど、
後から UPDATING みて後悔してるところだ。
ダウングレードしたら動くかな…。
599:名無しさん＠お腹いっぱい。
09/04/29 21:16:35
>>598
OVERRIDE_LINUX_BASE_PORT=f9
OVERRIDE_LINUX_NONBASE_PORTS=f8
で、
firefox-3.0.10,1
linux-flashplugin-10.0r22
で見れてるよ。
nspluginwrapper -i /usr/local/lib/npapi/linux-flashplugin/libflashplayer.so
やり直してみたら
600:名無しさん＠お腹いっぱい。
09/04/29 21:16:43
ちょっと前から fc8 にして、flash9 で使えてたんだが、本日トラブった。
linux-flashplugin-9.0r159 、音が出ない。
アップデートする前までは問題なかったんだが。
flash7 にすれば音は出るんだけど、ニコ動がダメなんだよな...
601:名無しさん＠お腹いっぱい。
09/04/29 21:22:30
jail で GEOM (geli) を使って jail を暗号化された 1 つのファイルにする
メリットってなんでしょう ?
602:名無しさん＠お腹いっぱい。
09/04/29 23:20:01
想像だけど、jail閉じたら、ファイルを1個持ち運べば別の場所で同じjail動かせて、
持ち運びが安全だからって感じじゃないかなぁ
603:601
09/04/30 00:24:34
なるほど、利便性という面ですね。確かにそういうのはありそうかも。
セキュリティ的な面ではどうなんでしょう。
ホスト環境に (一般ユーザで) 侵入されても jail の中身が見えないから
少し安心、とか ?
604:名無しさん＠お腹いっぱい。
09/04/30 01:28:01
jailが動いてたら普通にマウントしてるし、
jailの/のパーミッションを落とすわけにいかないから、
一般ユーザでも見れてしまうでしょ。
605:名無しさん＠お腹いっぱい。
09/04/30 01:31:09
>>600
もうFedoraCoreは存在しませんよ
606:名無しさん＠お腹いっぱい。
09/04/30 07:47:37
>>604
あ、そうなの ? てっきり 1 ファイルになるから VMware のようにホスト環境の
ファイルシステムからは 1 ファイルとしてしか見えなくて、jail 内の
ファイルを見るには ssh なりなんなりで入ってじゃないと見れないのかと
思った。
607:名無しさん＠お腹いっぱい。
09/04/30 09:30:52
>>605
あー fc8 じゃなくて f8 ね
608:名無しさん＠お腹いっぱい。
09/04/30 18:37:12
send-prしようと思ってたNEW PORTをdaichiタンに取られたぜ
まだ完全解凍じゃないよな
609:名無しさん＠お腹いっぱい。
09/04/30 20:19:20
>>599
> nspluginwrapper -i /usr/local/lib/npapi/linux-flashplugin/libflashplayer.so
> やり直してみたら
うーん、それっぽいスクリプト用意してて駄目だったけ
ど、手作業でやったらうまくいった。なんでだろ？
ま、動いたからいいや。
610:名無しさん＠お腹いっぱい。
09/04/30 22:42:29
scimに嫌気がさしたのでibusにしてみた
core吐かない
611:名無しさん＠お腹いっぱい。
09/04/30 23:01:35
ibus-skk誰か作って
612:名無しさん＠お腹いっぱい。
09/04/30 23:02:05
俺もｷﾎﾞﾝﾇ
613:名無しさん＠お腹いっぱい。
09/05/01 00:30:08
今更だけど、なんで scim のバグがとれにくいのか思い出した。
-g つけてコンパイルすると、core 吐かなくなるからだ。
ほんと微妙なタイミングでバグってるんだろうな…
で、printf とか使って、一行ずつ各値を表示させて null とかないか調べてたんだけど、
それもタイミングを変えてしまうので、結局どこが原因なのか突き止められなかった。
ほんとはもっといい方法があるんだろうけど…
614:名無しさん＠お腹いっぱい。
09/05/01 01:43:28
>>613
> -g つけてコンパイルすると、core 吐かなくなるからだ。
> ほんと微妙なタイミングでバグってるんだろうな…
gcc なら -g でタイミングが変わるような改変は無いは
ずだけど…（そもそもコード自体に変化は無いと思う）。
考えられるとしたら（UNIX のメモリイメージには明る
くないけど） rodata な部分への参照が何らかのタイミ
ングではみ出していて、デバッグ情報のおかげでそれが
はみ出さなくて済んでいるとか？
615:名無しさん＠お腹いっぱい。
09/05/01 01:49:47
シンボル情報の無い core で落ちた辺りのアセンブリコー
ドをメモっておいて、シンボル情報のある方で objdump
--disassemble して比較するとか。
といってもリロケーション情報が無いから難しいか…。
gdb プログラム
で起動しておいて break main して run すると main
入り口で止まるから、その状態で disassemble するっ
てのは？
616:名無しさん＠お腹いっぱい。
09/05/01 01:50:58
-gをつけるのと-O,-O2を取るのを区別せずに言ってるだけかも
617:名無しさん＠お腹いっぱい。
09/05/01 01:54:38
>>614
そうなんすか。そうかも知れんす。っていうか自分もその辺全然知らないんで…
まあでもそんな感じなんすよ。
bus error だったか、segmentation fault だったか、それさえ忘れてしまいましたし…
でも何かそんな感じなんすよね…
618:名無しさん＠お腹いっぱい。
09/05/01 02:05:20
>>615
確か大体どの部分で落ちるかは確か見当がついていたので、
その辺になると一行ずつ実行させるようにgdbでやってたんですが、
もううろ覚えで何か分からんのですけど、確か並行するスレッドの方に問題がありそうな気がして、
結局難しすぎて止めたような記憶が…
今となってはちょっと確かめる時間もないので、なんもできないんすよね…
ちなみに自作のGTKプログラムと合わせてデバッグしてたんすが、
こうすると確実に落ちるってのが分かっていたので、まだ分かりやすかったんですけどね…
619:名無しさん＠お腹いっぱい。
09/05/01 02:48:00
>>618
> 確か並行するスレッドの方に問題がありそうな気がして、
スレッド毎にコンテキストは別なんだから普通は落ちた
方だけ気にすればいいはずだよ（間接的に他のスレッド
が影響しているとしても、「X であるはずの値が X で
ない」みたいなのは落ちたスレッドで観察されてるはず
だし）。
> こうすると確実に落ちるってのが分かっていた
この時点で send-pr すべきだったね…。この時メール
送ったのならメールで残ってない？