BSD/LinuxでのOffice/Desktop環境を語れ! Part03
釣れますか? , \ ,/ヽ  ̄∨ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ,/ ヽ ∧_∧ ∧∧ ,/ ヽ ( ´∀`) (゚Д゚,,),/ ヽ ( ) (| つ@ ヽ | | | ___ 〜| | ヽ (__)_) |――|. ∪∪ ヽ  ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄| ヽ /⌒\/⌒\/⌒\/⌒\|彡~゚ ゜~ ~。゜ ~ ~ ~ ~~ ~ ~~ ~ ~~ ~~ ~~ ⌒\/⌒\/⌒\/⌒\/⌒\彡 〜 〜〜 〜〜 〜〜 〜 〜 >>100 肝心なことを書き忘れていました。 FreeBSDのX上のGUIなソフトウェアから、プリンタで正常に日本語が 印刷できる状態であれば、Wineで稼働するWindowsソフトウェアから 日本語の横書印刷は、できます。 Wine1.7.11+OpenOfficePortable3.2.0 で、縦書表示、縦書印刷を していましたが、一瞬の輝きだったようで、今では、横書印刷しか できません。 めったに縦書印刷をしないから……、 別にいいですけど!(田中みな実さんぽくむくれた表情)。 Wineで縦書がなかった時代から、縦書表示、縦書印刷ができていた CassavaEditorなら、今でも縦書印刷ができるかもしれません。 FreeBSD での Office 環境を語れ! その2@UNIX https://mevius.5ch.net/test/read.cgi/unix/1107211157/863 https://mevius.5ch.net/test/read.cgi/unix/1107211157/858-n 【指令】お前らの年賀状作成ソフトを報告せよ!@UNIX https://mevius.5ch.net/test/read.cgi/unix/1008926166/228-n ※↑スレのレス245の https://github.com/Torisugari/printha には、期待していたのですが、使ったよ、って記事がないですね。 ※レス228は、執筆者君です。以下のサイトを参照していました。 Linux+Wine+CassavaEditorではがきに宛名印刷する印刷設定の一例 - ぜんざいの耐えがたき甘さ https://sound.jp/zenzai/other/wine-cassava-setting.html GNOME42悪くない 少なくとも近年のFreeBSDのGNOMEらしからぬ仕上がり どうせ誰も使わんのだろうが >>103 追っかけている方はおられるんじゃないですか。 「かけまわる子犬。」氏はKDEを追っかけているし。 FreeBSDのKDEはdiscoverでpkgが扱える様になれば言う事無し 割り込んですいません。自己レスですが。 >>67-71 imm32.dll.soとimm32.dllの件 >>99 >今のWOW64なWineの仕組みだと、FreeBSD/amd64インストール時に >「lib32」を入れておかなくてもよいということです。 以上のレスは、以下のLinux板のWineスレで、理解が深まります。 i386-wineの統合のタイミングは、まさに今だった、 ということかもしれません。 今夜も Wine で乾杯! - 23本目@Linux https://mao.5ch.net/test/read.cgi/linux/1585198566/671-n FreeBSDを語れスレのテンプレで興味を持って来ました このスレは主にFreeBSDでwimeを使っている君と言う方が盛り上げている感じなんですね FreeBSDではどのデスクトップ環境がおすすめですか?推している方がいるようにKDEですか? ん? 語れスレのテンプレ?(ケンモメンぽく) えっ!やだっ!(田中みな実さんっぽく) けっこう活発なラズパイスレと一緒に関連スレになってる! 盛り上げると言うか、 「高スキルユーザさーん! 興味を持ってくださーい!」とか 「FreeBSDのWineで何かあれば、さがわ@sagawa_aki氏にも届け!」という 感じで報告しているだけで。 Linux板にはWineスレがあるんだけれど、FreeBSD特有のWineの話は、 Linuxには関係ないし、「FreeBSD限定のWineスレ」ってほどの 話題もないしね。 「おすすめのデスクトップ環境」って、Linux板文化っぽいね。 Linuxでも有名で、FreeBSDでも、FreshPortsでコミット回数が 多くて、よく使われている感じの、しかも、FreeBSD特有の問題が あれば、回避策が見つかりやすいやつ、で、いいんじゃないかな。 PCでのUnixは、Linuxが当然の前提、って感じなので、 FreeBSDだと……、という事が起こりやすいしね。 例のところを見ると、 「みなさん、普通にリッチなデスクトップ環境を使っているのね」 と思います。 触れないほうがいいかもしれないけれど(注)、リンクを書いておこう。 FreeBSD研究部 https://ja-jp.facebook.com/groups/freebsd.labo.japan/ (注) いいかげんPC-98は捨てろ@UNIX https://mevius.5ch.net/test/read.cgi/unix/1036951410/642-n >>109 > FreeBSD特有のWine 5chブラウザの動作報告などして下さると面白いかも知れないですね 5chなので Windowsの専ブラの動作報告などダサイでしょうから気が向いたらと言う事で 「wimeまとめ」の >>13 の「canna.el」への補足です。 執筆者は、「yc.el」を、現在まで使い続けてきました。 そのため、 >>13 での「canna.el」への言及が、中途半端で甘かった のですが、最近、「Yuuji」氏(注)による、EmacsへのCannaパッチを 知りました。 これが、FreeBSDの、pkg(8)の、flavor(Portsならmake option)の 「emacs-canna」の「もと」なのですね。 emacs23から数えて、13年ほど、まったく気づいていなかった、という 自身の検索の甘さをお詫びします。まことに申し訳ありませんでした。 (注)Twitterを見ると「ものずんごい有名人ではなかろうか」と 思いますが、まったく存じ上げませんでした。 FreeBSD13.0R/amd64で、 Wine(i386-wine-devel-6.12)+wime4.1.4+ATOK17(2004)+emacs-canna-27.2 を、使ってみましたが、 「やだっ! Mule時代みたい! 勘違いしないでね、ほめてるのよ!」 「yc.elでは、変換候補が一斉に出て、Emacsのエコーエリアが 数行ほどになるのに違和感があったのよね!」 と、誰だか分からない物まねをしながらウハウハです。 yc.elより、emacs-cannaのほうが軽いような気もします。 FreeBSDを使っていて良かったなあ、と、思いました。 https://twitter.com/hiroseyuuji/status/1511329334107140101 https://twitter.com/5chan_nel (5ch newer account) >>112 13-stableでpkgのwine6を使ってjanestyle4は動いた。この書き込みはそこから。 >>116 確かに動いた あっさりと https://i.imgur.com/uWiXdbE.jpg それも i386-wine-devel で使ってたやつがそのまんま wime氏、116氏、ありがとう そのうち私も何らかの成果があればご報告差し上げます >>117 自分のレス番間違えてしまった とにかく感謝してます wineは使わないけどV2Cだって13-stableで動くよ。 自分はV2C-Rを使ってて最近V2C/2に移行した。 そうそれ。 JAILで古いportsをビルドしてパッケージだけメイン環境に突っ込んだ。 スクリプトエンジンが変わってて動かんから古いエンジンを突っ込む必要があったり ちょっと手間だったけどV2C/2が快適に動いててこの書き込みしてる。 >>74 これをベースにした合成フォントがportsに来たみたいですよ FreshPorts -- japanese/font-udev-gothic: UDEV Gothic https://www.freshports.org/japanese/font-udev-gothic/ >>122 おおっ! Portsに来たぁぁ! 2つあるのか。明朝はないのね。 ん? 「Nerd Fonts」。「オタク文字」? って何だ? FreshPorts -- japanese/font-udev-gothic: UDEV Gothic https://www.freshports.org/japanese/font-udev-gothic/ FreshPorts -- japanese/font-udev-gothic-nf: UDEV Gothic (Nerd Fonts) https://www.freshports.org/japanese/font-udev-gothic-nf/ >>123 上流リポジトリ https://github.com/yuru7/udev-gothic HackGenの作者さんの様でテキストエディタや端末エミュレータ用の等幅フォントですね ナードフォントというやつは絵文字グリフが充実したフォントらしいです >>124 わざわざレスすいません。 モリサワの「BIZ UD」フォントからのPorts化なのでなく、 「yuru7」氏の二次的成果物(BIZ UD+JetBrains Mono)からの Ports化なんですね。 >>125 と、言われても……、なあ。 連日の長レスの後の短レスの投稿数の多さが恐いと思います。 Windowsは、「データを持って行って」ぐらいでしか 使ったことがないので、理解できませんでした。 今でこそ、Windowsが対応しておかないといけないキーボードは、 日本語か、英語か、ぐらいの選択ですが、昔は、Windowsが対応して おくべきキーボードがたくさんありました。 101/104英語、106/109日本語、PC9801系、AX、J3100(ATコネクタ)、 FM-TOWNS、親指シフト(最近まで現役だったみたい)、かなあ。 Controlキーが、左にしかない場合もあるし、Windowsさんには歴史が あるんだから、ぐちゃぐちゃとは言えないよね。 大昔(MS-DOS時代の話かもしれない)に読んだ、ATOKのバグ出し チーム(だったかな?)の記事。 バグ出しチームは、標準のキー割り当てで変換し(当たり前ですが)、 しかも、変換結果の漢字が何番目に出るかも記憶しているため、 即、変換結果を選ぶことができ、漢字変換が正確で速いのは良いが、 学習機能を使わない状態(無意識に学習機能を使わないようにしていた) だったため、学習機能の向上の役に立たない、ということに気づいた、 という話。 >>113 の件について追加。 FreeBSD13.0R/amd64+Wine(i386-wine-devel-6.12)+ wime4.1.4+ATOK17(2004)+emacs-canna-27.2 の 環境下において。 emacs-canna標準の、canna.el使用時の、漢字変換時に、 ごくまれに、WindowsなATOKの変換候補のGUI表示がされる。 もちろん、そのGUI表示で変換候補を選ぶことはできず、 単に描画されるだけです。 この描画は勝手に消えてくれないので、ATOKのプロパティを 表示(wimectrl -s)させて、プロパティをキャンセルすると、 ATOKのプロパティの描画と一緒に消えてくれます。 ただ、「たまになる」だけで確実に再現させることができません。 「標準のEmacs+yc.el」の時も、ごくごくまれになっていたと 記憶するのですが、条件を思い出せません。 実害はないのですが、一応、そういう現象がある、という事で。 それと、繰り返しになりますが、「標準のEmacs+yc.el」より 「emacs-canna」の方が、軽いように感じます。 「Emacs LispでCanna」と、バイナリで対応の「emacs-canna」なら、 当然かもしれません。 もう「標準のEmacs+yc.el」には戻れません。 >>127 もしご本人が読んだらどんな反応があるか目に浮かぶ様なご回答ですな >>130 恐いのは恐いんですが、悪口ではないんですよ。 ただ、キー割り当てやソフトウェアの挙動には、人間側として 不満があったとしても、よかれと思って考えられた設計思想や、 俗に語られる、タイプライターの配列の話などの、 いまさら変えられない歴史があるし、あえて、人間側が標準状態に 合わせるのも考え方として「ある」という話です。 ATOKのバグ出しチームの話も、「へえ、変換学習をさせなければ 変換先の順番が変わらないのだから、変換作業が速くなるね」と 感心したので、憶えていたのだと思います。 ATOKのスレで、ATOKの新規インストールをしたので、 「これから(自分流の入力をして)辞書を鍛える」というレスが 並んでいた中に、「短文でなく、長文で変換をしたら、文脈に 応じた変換結果になりやすいのに」というレスを見てからは、 執筆者も、文脈を読み取りやすい長さのタイミングで 変換するようになりました。そのレスには感謝しています。 そのスレで言及があった「窓使いの憂鬱」は知っていましたが、 共同使用のPCには入れられないし(共同使用相手がUnix系とは 限らない)、「窓使いの憂鬱」を入れられる環境なら、 Emacsな人なら、xyzzyを入れて「メモ帳」代わりに使っても よいだろうし、Windowsのダイアログ入力のコピペなどの すべてまでも、を、Unixっぽくするのも、どうなのか、 Windowsにおいて、「絶対にマウスを使たくないでござる」は、 難しいだろうな、人間には慣れる能力もあるのに、と、 思ったことがあります。 『UNIXという考え方−その設計思想と哲学』を読んで、 マウス操作もアリ(操作は、なるべく楽をしろ)なのだな、と、 考えを改めた執筆者君でしたー(きょうのわんこ風)。 ありきたりな環境で人並みに過ごすのか、楽をする為に人並み外れた途方も無い時間と労力を費やすのか まさに人それぞれと言う話でござるな まあどっちかというとWindowsならマウス無しのオペレーションも無くはないんだけどね。 > BSD/LinuxでのOffice/Desktop環境を語れ! Part03 GhostBSDのデザイン割と好きなんですが OpenRCに馴染めないのでパーツだけ拝借してそれっぽくしてみました https://i.imgur.com/HmjeR0v.jpg みなさん、フツーにリッチなデスクトップ環境を使っているのね。 計算機資源は、makeやコンパイルに振り向けるべきだよ、 それなら自作PCも安価で済むしね、という貧乏性な執筆者です。 大昔、初めてWindow Managerの仮想デスクトップを使った時は、 「わー、すげー」とか言って、いくつかの窓を仮想デスクトップへ 移動させたが、存在を忘れてシャットダウン。 仮想デスクトップマネージャみたいなものがあっても、 「見えていない物は忘れてしまう」という事に気づいて、 そもそも、仮想デスクトップは使わなくなった。 XのWindow Managerは、ソフトウェアを位置指定(-geometry)して 起動ができるので、「わー、すげー」とか言って、 「Emacsはこの位置で」などと、設定に夢中になったが、 同じソフトウェアを複数起動すると、ピッタリと同じ位置に 起動するので、先に起動していたのを忘れてしまう、という事で、 位置指定もやめた。ダメダメじゃん。 といっても、タイル型のWindow Managerへ行くほどでもないです。 > ※執筆者はC言語もMakefileも理解していない >>140 あははー。 執筆者のスキルを明示するためにサラッと書いたんですが。 前スレにwimeネタを初めて書いた時点で書きましたが、 執筆者は、C言語も、Makefileも、理解していません。 いちおう、見るには見ますが、修正する能力はありません。 ケアレスミス程度なら修正しますが。 さらに言えば、シェルスクリプトも、こみいったものだと、 追いきれず、途中で迷子になります。 wimeや、Wineに対して、*BSD業界の高スキルユーザさんに 興味を持ってほしい、というのは、それが理由なんです。 「FreeBSDでは、動かないんですが」 「さあ? Linuxでは普通に動いてるし」 「え゛え゛!」 って、ありそうでしょ。 執筆者しか、FreeBSDで、Wineが、ないと困るほどの状態で 常用しているユーザはいないのではないか、と思っていましたが、 FreeBSDでWineな方がおられました。 みなさん、WineのFreeBSDでの特有の知見を共有するためにも、 Wineをドンドン使いましょう【PR】。w (URLの後は引用です) https://twitter.com/stackfield_jpn/status/1528331070152019969 stackfield@stackfield_jpn FreeBSDでCarrara 8.5 64bitが動いたな。 wine 6.0な。wine-devel(7.4.1)だと動かんのだがおもしろい話。 8:04 PM · May 22, 2022·Twitter Web App https://twitter.com/5chan_nel (5ch newer account) FreeBSDの使い手でケンモメンねえ まさかとは思うが可能性はゼロじゃねえ vncやxrdpで入ろうとするとconsolekit-daemonがエラー吐きながら1分から2分くらい待たせやがるんだが何事かわかる? 例えばこんなの console-kit-daemon[7641]: WARNING: Error waiting for native console 9 activation: Inappropriate ioctl for device > なぜその吐いたエラーを貼らんのか? 寝起きで思い出した様に書いたから あとconsole-kit-daemonじゃないけど気になったのはこれ xrdp-sesman[1599]: [ERROR] sesman_data_in: scp_process_msg failed xrdp-sesman[1599]: [ERROR] sesman_main_loop: trans_check_wait_objs failed, removing trans dbus-daemon[1440]: [system] Failed to activate service 'org.freedesktop.ConsoleKit': timed out (service_start_timeout=25000ms) dbusが吐いたタイムアウトエラーの後に一応繋がりはするんだけどさ 結局手直しは諦め新規インストール用データセットへinstallworld、設定複製、 chrootして各種パッケージ入れて再起動し一応解決 リフレッシュ出来たと思う事にしました デスクトップ環境にリモートアクセスし操作する為のプログラム そんなこと言い出したらwineの話もアウツでは amd64、i386共に wine-devel-7.8 6.0では起動しなかったbecky2が起動 https://i.imgur.com/4lfNo2n.jpg 互換性が良くなってきている模様 winnyとかFLMASKはwineで動くのかな? 当時?はFLMASKのためだけに、vmwareを入れたりしてたけど FreeBSDのMATEに、 ・mate-desktop/mate-netbook https://github.com/mate-desktop/mate-netbook ・ubuntu-mate/mate-window-applets: Window applets for MATE Desktop https://github.com/ubuntu-mate/mate-window-applets ・ghostbsd/station-tweak: This is Station Tweak, a fork of MATE Tweak. https://github.com/ghostbsd/station-tweak この辺を野良ビルドで入れるのオススメ これのことか GitHubの利用をやめるようオープンソースソフトウェア非営利団体が強く呼びかけ - GIGAZINE https://gigazine.net/news/20220704-software-freedom-conservancy-give-up-github/ ギガジンを鵜呑みにしてしまう人っているのか Software Freedom Conservancyがどんな団体なのか の方がgigazine云々より重要じゃないか? >>143 今、気づきましたが、ハンドル名をコピペミスしている……。 「ERROR: 余所でやってください。[unix]」エラーのため、 書き込みをリトライしていたからだと思います。 >>156 https://www.winehq.org/search?q=atok 上記URLのWineHQ公式のデータベースでは、 2017/07/21にReleasedされたWine2.13で、ATOK2017が、Garbage評価、 という報告が出てきます。 この年度時点で、すでにwimeは熟成した存在で、執筆者君が、FreeBSDで wimeを試した初めてのレスが、前スレに書かれています。 この時点で、wimeに対するLinux業界での喜びの声は、沈静化しており、 執筆者の、Linux板のWineスレへのレスに対しても、「懐かしい」感の あるレスがありました。 たしかに「素」のWineでは、ATOKは動きませんが、 Wine+wime+ATOKで、CannaServerに見える形で動くので 周回遅れでのデータベース登録となっているのも事実です。 ※ATOK2017がwimeで動作するという報告は見あたりませんが。 日本語利用者がこのデータベースを参考にする可能性は、 比較的に低いと思われますが、誤解を生む登録だなあ、 と思います。 日本語を常用利用していない方が登録したのかなあ。 すでに、ずいぶん前から使っている方からすれば、いまさらでしょうが、 Emacs28.1で、文書中の全角空白(2byte空白)が赤のアンダーバーで 表示されるようになりました。 まあ、昔から設定によって全角空白などを表示させることはできましたが、 四角い形状で表示されたりして、執筆者的にはイマイチ感があり、 アンダーバー表示の控えめ感は、ありがたいと感じています。 ただ、Emacsのエコー領域に表示されるCannaの変換候補でも表示されます。 ※emacs-cannaで、canna.elを使用。 不思議なことに、全角漢字の候補のうしろにも表示されています。 漢字は全角なので、まあ、おかしくはないけれど、意味がない、と 思うのですが……、ああーっ!分かったー! 変換候補の一単語ごとの区切りの空白に全角空白を使用しているので、 それに反応して赤のアンダーバーが表示されているんだ! (ヽ´ん`) それぼく ごぶさたしております。 ニュー速(嫌儲)のキャラクターがカワイイので、つい見に行って しまう執筆者君です。 FreeBSD13.1R/amd64を新規インストールしました。 さて、執筆者がアテにしているソフトウェアはWineとwimeです。 WOW64となった現在のFreeBSDのWineでは、 32bit環境の展開で「versions do not match!」>>98 となったり、 wimeのwimectrlで「"libX11.so.6" not found」>>95 >>99 となったりの 過去がありますので、今のところ、FreeBSD13.0R/amd64の 「/var/cache/pkg/」からコピーして保存しておいた 「i386-wine-devel-6.12,1.pkg」を、FreeBSD13.1R/amd64に 「pkg add」で入れて使っていますが、普通に入って、普通に、 i386-wine-devel-6.12が使えています。 wimeのために、FreeBSD13.0R/i386でmakeした「imm32.dll.so」を 「/usr/local/lib32/wine/i386-unix/imm32.dll.so」に置いて wime(FreeBSD13.0R/i386でコンパイルしたもの)が稼働しています。 もちろん、Wineが6系なので、(他のdotファイルでもよいが).cshrcに 「setenv WINEDLLPATH /usr/local/lib32/wine」を設定しています。 こんなこともあろうかと、FreeBSD13.1R/amd64のインストール時の 「Distribution Select」で「lib32」を入れておきました。 FreeBSDのPortsのWineは、公式やLinuxと同じタイミングで、VersionUp する時もあれば、少し対応が遅く、ほぼ固定状態みたいな時があります。 i386-wineの時みたいな感じですが、まあ、ボランティアなので文句は 言えませんね。 余裕ができたらWOW64なWineを試してみます。 FreeBSD13.1R/amd64でのVirtualBOXの話です。 現在のPortsでもpkg(8)の「quarterly」でも、VirtualBOXのVersionは 6.1.36です。 pkg(8)でVirtualBOX6.1.36を入れ、FreeBSD13.1R/amd64をブートすると カーネルメッセージで、 KLD vboxdrv.ko: depends on kernel - not available or version mismatch linker_load_file: /boot/modules/vboxdrv.ko - unsupported file type と言われます。 Solved - Virtualbox kernel module fails to load on FreeBSD 13.1-RELEASE | The FreeBSD Forums https://forums.freebsd.org/threads/virtualbox-kernel-module-fails-to-load-on-freebsd-13-1-release.85191/ 上記URLによると、2022/05/17時点の質問ですが、同じ状況が報告されて いました。FreeBSD13.0でpkgがビルドされたことが原因のようです。 Forumで話題になっているのは6.1.34の頃の話のようですが、 6.1.36の今現在も同様のエラーが執筆者の環境では出ました。 ところが、上記Forumのfyamamoto氏の書き込み通りの手順で問題は 解決されました。 こんなこともあろうかと、FreeBSD13.1R/amd64のインストール時の 「Distribution Select」で「src」を入れておきました。 〔次に続く〕 〔前からの続き〕 fyamamoto氏の手法は、あらかじめpkgで「virtualbox-ose-kmod」を インストールしておき、Portsから「virtualbox-ose-kmod」をmakeし、 カーネルモジュールだけをコピーするという手法で、正直なところ、 「make reinstall」でもいいような、とも思いますが、多少なりとも 時間や、計算機資源などが節約できるという利点があります。 執筆者は「基本的に、pkgでインストールし、一部のファイルだけを、 Portsでコンパイルされたバイナリで差し替えるため、workの下から コピーで持ってくる」という、いかにも情弱っぽい手抜き手法を Wineとwimeのために、とっていましたが、まさか、同じ手法を取る方が おられるとは思いませんでした。本当に驚きました。 fyamamoto氏の後の、mss_cyclist氏の書き込みで、 >I am not sure if this is necessary? >Code: >kldxref /boot/modules とありますが、「kldxref /boot/modules」しておかないと、 warning: KLD '/boot/modules/vboxnetflt.ko' is newer than the linker.hints file warning: KLD '/boot/modules/vboxnetadp.ko' is newer than the linker.hints file とのメッセージが出ます。 執筆者は、FreeBSD13.0R/amd64で、Athlon5350のRadeonR3を amdgpuで使っていましたが、FreeBSD13.1R/amd64では使えませんでした。 詳細としては、 カーネルメッセージの、rc.confの評価あたりで、画面出力がなくなる。 モニターの電源ランプは、画面出力が「ある」状態だが、 実際の画面出力は「ない」。 たんに、「画面出力がないだけなのか」と、かなり時間を置いて 画面出力に頼らずにログイン作業をしてみたが、ログインできないので、 リセットボタンでリブートするしかない。 やってみたこと。 ・「gpu-firmware-amd-kmod-banks」を入れてみた。 結果:状況変わらず。 ・「loader.conf」に「hw.amdgpu.exp_hw_support=1」を追記。 出典:https://running-dog.net/2021/04/post_2429.html 結果:状況変わらず。 〔次に続く〕 〔前からの続き〕 PCIeスロットに、RadeonHD4350(RV710)なビデオカードをさして radeon_drv.soを試してみましたが、 Fetal Server error : no screens found で、Xサーバが起動せず。 しかたがないので、GeForceGT730なビデオカードにさし直し、 pkg(8)から入れた「nvidia-driver-340」で使っています。 NvidiaDriverだと、「/boot/loader.conf」に「nvidia_load="YES"」と 「/etc/X11/xorg.conf」に「Driver "nvidia"」だけで使えるので ラクチンだなあ、と思います。 amdgpuが使えない、という最後の心当たりは、 AHCIブート(BIOSブート)で、FreeBSD13.1R/amd64をインストール しており、「UEFIboot」にしていなかったからかなあ? 、ぐらいです。 こんな風に変わっているよ、という助言などがあれば、 よろしくお願いします。 じゃ、お夜食、食べてきます。 xf86-video-ati/Makefile, xf86-video-amdgpu/Makefile に ONLY_FOR_ARCHS_REASON= KMS is required and currently only available on x86/arm64/powerpc64 なんて書いてあるし xf86-video-amdgpu/pkg-descr に On FreeBSD requires amdgpu KMS driver from graphics/drm-kmod. とあるけど graphics/drm-fbsd13-kmod はインストールしていたのか あと 13.0 から 13.1 にアップグレードしたのなら -kmod は ports で make し直す必要があるかと あわわ。即レス驚きました。ありがとうございます。 >>167 では、前提条件を書くのをコロリと忘れていました。 ○FreeBSD13.1R/amd64はクリーンインストール。 ○amdgpuを使うためにpkg(8)から入れた物は以下。 ・xf86-video-amdgpu-22.0.0 ・drm-fbsd13-kmod-5.4.191.g20220604_1 ・gpu-firmware-amd-kmod-banks-20220511 ○以下の設定をした。 ・rc.confに「kld_list="amdgpu.ko"」 ・xorg.confに「Driver "modesetting"」 ・「#pw groupmod video -m <ユーザ名>」 「drm-fbsd13-kmod」の代わりに「drm-kmod」「drm-54-kmod」も 試しましたが状況は変わりませんでした。 そもそもこれだけ熱心にレポート書いてる人が あんなしょうもない釣りやるとも思えんよね ここの嫌儲民はどちらかと言えばあの >>171 > ・xorg.confに「Driver "modesetting"」 modesetting じゃなくて "amdgpu" ではどうなるの? >>171 まだ 13.0 のサポート期間なので pkg は 13.0 で make されてる >>165 のリンク先にも書いてある > カーネルメッセージの、rc.confの評価あたりで、画面出力がなくなる。 -kmod は pkg じゃなく ports からインストールするように ん? 何か嫌疑が、かかってます? 古くさい釣りAAが貼られていたのも、それがらみですか? 世の中、ヒマ人が多いんですね。 嫌儲板には書いたことはありません。閲覧のみです。 そんなことよりも、wimeを、以下略。 執筆者は、UNIX板では「FreeBSDでwimeを使っている君」で 書き込みをしています。※他の板では書いていません。 仮に、初歩的な質問をする場合で、通りすがりのフリを したくても、即バレてしまう文体なので、恥を忍んで固定名に するつもりです。 Linux板に書く場合も、これからは同様にするつもりです。 それもこれも、すべてwimeの宣伝のためです。 なぜ宣伝するかというと、wimeを、以下略。 さらに書き忘れていた。 執筆者がATIというかAMD系のビデオカードを選好するのは、 コンソールの文字が、クッキリ! ハッキリ! 白が明るい! という、高度成長時代のテレビのCMみたいな好みがあるから、 というのもあるのですが、nvidia-driver使用時の、i386-wineでは、 pkg install後に、「patch-nvidia.sh」を走らせる必要があるから、 というものでした。 まあ、手順が増えると何かのトラブルに合う確率が上がるだろうから、 できれば避けたい、という、実につまらない理由です。 で、i386-wineで「patch-nvidia.sh」を走らせてみると、 nvidia.comから現在自分のPCで稼働している、 pkg(8)のnvidia-driver-340-340.108に対応した、 NVIDIA-FreeBSD-x86-340.108.tar.gzをダウンロードして 以下のように展開する、というものでした。 ※もちろん、最初に走らせるだけでユーザ側での操作はありません。 [前の部分は略] => Extracting NVIDIA-FreeBSD-x86-340.108.tar.gz to /usr/local/lib32... x libnvidia-tls.so.1 x libGL.so.1 x libnvidia-glcore.so.1 => Cleaning up... ===> i386-wine-6.12,1 successfully patched for nvidia-driver-340.108_3 [終了] ファイルの差し替え処理のようです。 日本語入力メソッド総合スレッド@Linux@5ch掲示板 https://mao.5ch.net/test/read.cgi/linux/1472658083/139-140 上記のレスのおかげでwime 4.1.5がリリースされているのを知りました。 新規リリースに気づいていませんでした。ありがとうございました。 上記URLでは「ATOK17」とありますが、ATOK17は、2004年度版となります。 >ATOK17にあわせてATOK28W.IMEからATOK30W.IMEに変更したところ とのレスが正しいとすると、2015年度版(ATOK28)に対する処理を 読み替えて変更した、ということですから、もともとの「ATOK17」表記は、 おそらく「ATOK30」が正しいと推測されるので、ATOK2017での動作報告 かと思われます。 いずれまとめて手順の書き換えをする時用にメモしておこう。 >>15 に上記Linux板のURLを追加のこと、と。 >>174 >まだ 13.0 のサポート期間なので pkg は 13.0 で make されてる そういうものとは、まったく知りませんでした。 今までカーネルモジュールを使うソフトウェアは、あまり使っておらず、 意識していませんでした。 >>>165 のリンク先にも書いてある まことにすいませんでした。 英語なもので、さらっと読み飛ばして、ポイントっぽいところだけを 読んでいました。 >>173 CUIのコンソールの出力がなくなり、CUIのloginまでいけない状態なので、 xorg.confの評価までは、いけていないのです。 drm-fbsd13-kmodをpkg(8)から入れず、Portsから入れてみる。 ○FreeBSD13.1R/amd64はクリーンインストール。 ○amdgpuを使うために入れたもの ・pkg(8):xf86-video-amdgpu-22.0.0 ・ports :drm-fbsd13-kmod-5.4.191.g20220604_1 ※pkg(8)と同じバージョン ・pkg(8):gpu-firmware-amd-kmod-banks-20220511 ・pkg(8):mesa-dri-21.3.8 ※注 ・pkg(8):mesa-libs-21.3.8 ※注 注 https://running-dog.net/2021/04/post_2429.html に 書いてあったのだが、すでに入っていた。 ○以下の設定をした。 ・rc.confに「kld_list="amdgpu.ko"」 ・xorg.confに「Driver "modesetting"」 ・「#pw groupmod video -m <ユーザ名>」 pkg(8)の「drm-fbsd13-kmod-5.4.191.g20220604_1」を、removeし、 portsから「drm-fbsd13-kmod-5.4.191.g20220604_1」を 入れましたが、以下のように状況は変わらずでした。 カーネルメッセージの、rc.confの評価あたりで、画面出力が なくなる。 モニターの電源ランプは、画面出力が「ある」状態だが、 実際の画面出力は「ない」。 で、リセットボタン。 まさか、「1分くらい待つと画面出力が始まる」とかじゃないで しょうね。 いえね、i386を使っていた頃は、VGA表示から精細な表示に 切り替わるのに10秒くらいかかっていたので。 うろ覚えだがgpu firmwareみたいな名前のpkgもportsで作り直しが必要だったような。 WoW64連呼してるのも本当なのかと疑問に思ってる wine/Makefile に # Wine assumes a WoW64 package is available, which is not the case on # FreeBSD yet. と書いてあるから 64bitと32bitを統合したWoW64じゃなくて64bitと32bitを同時に使えるようにした だけなんじゃないかと思うんだが違うんだろうか WoW64には64bit Wine側の対応が必要で64bitだけのWineとは違うはずだから Athlon Athlon5350なのにgpu-firmware-amd-kmod をインストールしているのが間違い 必要なのはgpu-firmware-radeon-kmodの方 分からないのならMeta ports の gpu-firmware-kmod あと -kmod なのだから pkg ではなく ports から試すように(特にトラブってる時には) amdなんて使ってないけどwikipedia見て調べてみた 180 書いたの俺だけどこれは関係無かったか wine 等とまるで関係ないんだがCinnamonが割とまともにつかえる 足りないと思ったものは適宜追加しながらお好きな人はどうぞ ただし画面ロックとシステム情報おまえらはまだダメか ヤらねばヤられる >>175 すいません。 Linux板のWineスレで、すでに「FreeBSDでwimeを使っている君」で 書いていました。 https://mao.5ch.net/test/read.cgi/linux/1585198566/449 >>186 Wineのスレではないので、良さげっぽかったり、便利っぽかったり、な 情報は書いてください。 スレタイは「Office/Desktop環境」となっていますが、 Unix系OSでOfficeソフトを使うような日常生活環境を構築するための 情報交換をしたい、人柱報告(>>4 など)も読みたい、というのが スレの趣旨です。 Desktop環境にしても、LinuxのDistributionにしても、構築する個人や、 コミュニティの好みで構築されているので、長短がありますから。 >>180 >>185 それ、サーバなマザーボードでの構成でしょ。 おそらく、後載せのRadeonR7は、「ダミーが刺さって」とのことから、 ビデオ出力に使わずに、演算に使っているのではないか、と感じました。 執筆者君の環境の場合、VGAを複数認識するような高価な環境ではなく、 ビデオカードをさすと、APU側のビデオ機能は無効になるマザーボードが ある、という、ローエンド環境に、ありがちな環境です。 もちろん、この試行中でも、いちいちビデオカードを外しながら 試していました。 おかげで、アルミ筐体の拡張スロットのネジがゆるくなってきました。 >>183 >64bitと32bitを同時に使えるようにしただけなんじゃ たぶん、そうだと思います。 >>38 >>67 あたりに書きました。 FreeBSDのWOW64なWineとはいっても、FreeBSD/amd64の場合、 そのままでは、64bitなWindowsソフトウェアしか使えません。 32bitなWindowsソフトウェアを使いたい場合は >>69 に 書いたように、シェルスクリプトを走らせて、 ユーザのホームディレクトリの下に 32bitなWine(バイナリ提供の様子)を展開しないと いけませんから。 以下のURLは参考まで。 http://hayabusa6.2ch.net/test/read.cgi/linux/1455088008/51-n https://mao.5ch.net/test/read.cgi/linux/1585198566/442-n https://mao.5ch.net/test/read.cgi/linux/1585198566/679-n なんだか、入門者の犬小屋スレみたいになっていますが、 みなさん、ありがとうございます。 amdgpu、以下の環境で動きました。 >>181 >>184 の通りです。 本当にありがとうございました。 すべては執筆者の、KernelModuleへの理解が足りなかったのが 原因でした。 ・pkg(8):xf86-video-amdgpu-22.0.0 ・ports :drm-fbsd13-kmod-5.4.191.g20220604_1 ・ports :gpu-firmware-kmod(MetaPort) *rc.confに「kld_list="amdgpu.ko"」 *xorg.confに「Driver "amdgpu"」 ※「modesetting」でも動いた。 CUIのコンソール(カーネルメッセージ)の出力が VGAから精細になり、 「やだっ!amdgpu.koとamdgpu_kabini*.koなどのKernelModuleが 正常に読み込まれたんだわっ!」と、誰だか分からない物まねを しました。 やはり、pkg(8)のKernelModuleが、13.0環境で作成されていたのが 問題だったのだと思います。 これなら、RadeonHD4350(RV710)なビデオカードも動くと思います。 ※試していませんが。 入れてて良かった「Distribution Select」で「src」、 「ports」もね! (田中みな実さんぽくキリッとキメ顔) >>189 Linuxの場合と同様64/32bit使用可な環境作って32bitアプリインスコすると ~/.wine/drive_c/Program Files (x86) ディレクトリが出来るのでどうなんでしょうねえ (emulators/i386-wine(含-devel)の頃には起こらなかった挙動) >>182 >>192 執筆者が「その程度のレベル」なのは、 前スレ当時から自己紹介しております。キリッ。 自分でKernelをReConfigureした場合、Ports由来のKernelModuleを 再makeしないといけない、というのは知っていましたが、 「まだ 13.0 のサポート期間なので pkg は 13.0 で make されてる」、 というのは知りませんでしたし、さらに、標準のKernelで「.1」の差が 問題になる、というのも認識していませんでした。 この後に「その程度のレベル」な、謝罪のレスがあります。 >>191 執筆者の試行では、32bit環境の.wineのまま(新規生成していない)で、 WOW64なWineで32bitなソフトウェアが動きました。 WOW64のWineでwinebootで.wineを新規生成すると、「Program Files (x86)」が できていました。 まずは、おわびです(ガバッ、土下座)。 お散歩がてら「さがわ@sagawa_aki」氏のTwitterを見ていると 以下のようなTweetがReTweetされていました。 https://twitter.com/scp1979/status/1547002783227817985 >晋太郎@scp1979 >FreeBSD13.1でWineを起動したら「wine: could not load http://ntdll.so: (null)」と出て起動しなかった。 >ググても解決方法が見つからなかった... >pkg info -D wine を確認したところ、procファイルシステムが必要と書いてあったのでmountしたら起動した。 >#FreeBSD #Wine #備忘録 >8:39 AM ・ Jul 13, 2022・Twitter Web App 執筆者は青ざめました。 「wine: could not load http://ntdll.so: (null)」で このTweetより先に、大騒ぎした張本人だからです。 ※大騒ぎの初出は、以下のURL、2020/12/11(金)。 https://mevius.5ch.net/test/read.cgi/unix/1107211157/919-921 https://mevius.5ch.net/test/read.cgi/unix/1107211157/951 https://mevius.5ch.net/test/read.cgi/unix/1107211157/952-953 https://mao.5ch.net/test/read.cgi/linux/1585198566/449 https://twitter.com/5chan_nel (5ch newer account) で、前スレ951氏助言の 「setenv WINEDLLPATH /usr/local/lib32/wine」との設定をコメントし、 /etc/fstabに「proc /proc procfs rw 0 0」と、設定をして、 winecfgを起動すると、普通にwinecfgが起動しました。 執筆者が、procをマウントしていれば、騒ぐ必要がなかったミスとなります。 前スレの951氏にはWineのソースを調べ、助言レスをさせる、という手間を かけさせて、まことに申し訳ありませんでした。 Linux板のWineスレでも質問をして、申し訳ありませんでした 執筆者の不注意なミスにより、心配した方々に迷惑をかけて、 本当に申し訳ありませんでした。 あれれ? >>195 のWineのエラーメッセージ引用のかぎカッコ中に 「 h t t p : / / 」とありますが、執筆者は書いておりません。 投稿時に自動的についたものと思われます。 >>196 インストールのメッセージくらい読めというところだが 貴方が前スレの992に貼ったFreeBSD Forumsでも そのエラーの回避法としてprocのことが書いてある >>195 当時のリンク先のサイトのレスが書き込まれた日付をよーく見ると良いよ。 ついでにそれがportsに反映された時期も。 四ヶ月後に再度見に行くか?ったらまあしないだろうし そもそも当時の作業者が初耳!してるくらいだから。 あとprocマウントしてても多分そのエラーは当時は出てたと思う。 なんでかっつーと自分のマシンは最初からfdescfsとprocfsはmount済みなんで。 >>198-200 ○「wine: could not load ntdll . so : (null)」と出る件 ※5chに書き込んだ時点でゴミがつくので1byte空白をはさみました 前スレ919(2020/12/11)の執筆者のレス時点では、 https://forums.freebsd.org/threads/i-cant-run-windows-applications-with-wine-64bit.77253/ の、forumsが Oct 8, 2020 (2020/10/08)で、一時的に止まった時点を 執筆者は閲覧し、レスしていました。 Alexander88207氏(i386-wineのコミッタ)の Oct 8, 2020 (2020/10/08)の 書き込み(post-480654)では、 試してみて、同様の結果になる、と、報告しています。 ※執筆者はこの書き込みは見ていました。 それから、ずいぶんたってforumsが動き出しました。 tbyte氏の May 2, 2021 (2021/05/02)の書き込み(post-509356)では、 FreeBSD13のwine-devel-6.4でも同様です(執筆者意訳)、 と報告されています。 grahamperrin氏の Jul 11, 2021 (2021/07/11)の書き込み(post-522107)で、 Alexander88207氏に対して、「Do you still get a null there?」 と返しています。 Alexander88207氏の Jul 11, 2021 (2021/07/11)の書き込み(post-522113)で、 「But the workaround for this error is to mount procfs on /proc.」 と書かれました。(注) 〔次に続く〕 〔前からの続き〕 前スレ992(2021/10/06)の執筆者のレスでは、同じforumsを参照して いましたが、執筆者は、「wine: could not load」の件は、 コロリと忘れていました。 そこで、Alexander88207氏のJul 12, 2021 (2020/07/12)の 書き込み(post-522315)で、 「コンパイル時のバグだけが修正され、実行時のバグは無視されている」 (執筆者意訳)が、執筆者がまとめたレスとして書かれました。(注) 注:おそらく、推測ですが、2021/07/11から2021/07/12の時点では、 Alexander88207氏がコミッタのi386-wineでは、問題に対応済みで 他のコミッタがかかわるwineとは、挙動が違ったのではないだろうか。 Alexander88207氏が「実行時のバグは」とこぼすぐらいですから。 つまり、i386-wineだと /proc をマウント(post-522113)するだけで 動いたのではないだろうか。 もう今は、i386-wineのPortsTreeがないので、FreshPortsを閲覧して 検証することができないのですが。 〔次に続く〕 〔前からの続き〕 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=257105 で、「wine: could not load」の件が報告され、 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=257020 と、関係があると思われていたが、違うようだ、と、なったようだ。 「id=257105」は閉じられて、その後、どうなったかは分からない。 https://www.freshports.org/emulators/wine-devel/ では、31 Aug 2021 07:11:18(2021/08/31) の wine-devel 6.16,1で 「ntdll: Always return a value in get_builtin_init_funcs.」 として問題に対応がなされた。 ……というのが時系列ではないでしょうか。 執筆者は、FreeBSD13.1R/amd64において、FreeBSD13.0R/amd64で 取得しておいた、i386-wine-devel-6.12,1のpkg(8)を「pkg add」で 入れて使っていますが、WINEDLLPATHの環境変数を設定しなくても、 「/proc」のマウントだけで使えています。 「wine: could not load」問題を、まとめれば、ですが、 現在、FreeBSDで、Wineを使うなら「proc」をマウントしておくこと、 ということですね。 執筆者が青ざめて謝罪をした意味はあります。 なぜなら、こんなことでもなければ、執筆者は「proc」をマウント することはなかっただろう、と、思うからです。 試した報告をする方々、助言をくださる方々に感謝します。 〔終了〕 >>202 > もう今は、i386-wineのPortsTreeがないので、FreshPortsを閲覧して > 検証することができないのですが。 パッケージを保存しておいた実機で各種検証する人の書く事とも思えんが >>204 >>205 し、知らなかったんだお……。 FreshPortsでしか見られないと思っていたんだお……。 「その程度のレベル」なんだお……。 「This port and its pre-built binaries」って、そもそもi386-wineは、 バイナリ配布だったのか。jailか何かで、32bit版も同時にmakeしていると 思っていた(注)。 じゃあ、FreeBSDのWOW64なWineで、/home以下に展開される32bit版Wineが バイナリ配布なのも当然なのか。 しかも、i386-wineが、WineHQ公式Versionに追従するのが遅かったのも、 今のWOW64版Wineの追従が、やや遅いのも、バイナリ待ち、すりあわせ、 などの理由で、当然なのか。 >>38 で執筆者は、i386-wineがwineに「吸収」と書きましたが、 今のFreeBSDのWineは、単にwineとi386-wineをたばねたもの、という感じで、 >>183 の印象は正しいようです。 FreeBSDのWineでは、「wow64」の名称は、本物のWOW64ではなく、 単に「どっちも使えますよ」って意味なのかもしれません。 注: i386-wineで32bitなATOKを使う場合、32bitなファイル(imm32.dll.so)に wimeのパッチをあてる必要がありますが、i386-wineは、バイナリ配布の ため、i386-wineのportsでwimeのパッチをあてるのは、そもそも無理だった、 ということになります(手作業でi386-wineと同じ事をするなら別ですが)。 >>14 で、執筆者は、 >※i386-wineで、wimeのパッチがあたるかは、執筆者は未検証。 と、書きましたが、この迂遠な手抜き手法は、そうするしかなかった、と、 いうことになります。 「wine: could not load」の件は、 cgit.freebsd.orgによると、 i386-wineでは、以下のように、2021/07/上旬以降、 直近の動きがないので、すでに対応済みだった可能性があります。 i386-wine-devel 2021-07-08 Update to 6.12 2021-09-30 cleanup: drop support for EOL FreeBSD 11.X i386-wine 2021-07-19 emulators/i386-wine: Update to 6.0.1 2021-09-30 cleanup: drop support for EOL FreeBSD 11.X FreshPortsによると、Wine(i386-wineでないほう)では、 以下あたりで対応されたのかもしれません。 wine-devel 22 Jul 2021(2021/07/22) 6.13,1 wine 26 Jul 2021(2021/07/26) 6.0.1,1 >>206 それが Forum とかでの freebsd の ports は multilib をサポートしてないから という発言につながるわけですな この件について、執筆者自身も、i386からamd64に移行したため、 また、Wine6.x系というくくりなら、必ず発生する、と、思いこんで いたため、混乱していますが、おそらく、 Wine(Alexander88207氏がかかわっていないほう)では、 WINEDLLPATHを設定しないと動かなかったと思われます。 理由は >>200 。 しかし、執筆者の環境のi386-wineでは、WINEDLLPATHを設定しないと 動かなかった、という理由は、たんにprocをmountしていなかったため、 と推測できます。 なぜなら、i386-wine-devel-6.12は、このスレでは >>6 (2021/10/14)氏が、 特に設定せずに動いているから。>>6 の方はprocをmountしていたのだと 思います。 執筆者は >>28 >>29 (2021/11/12)の時点では、procをmountして いませんでした。 さっ! 「死んだ子の年を数える」より、FreeBSDのWOW64なWineの現状を 試さないといけないな。時間ができたら試します。 >>208 あ、連続レス中にはさんでしまった。 >multilib をサポートしてないからという発言に ああ。そういう意味、そういうこと、だったのか。 なんの話だろう、特殊なライブラリ? とか思っていました。 すいません、forumsの内容も、英語のため、精読していませんでした。 そう言えばprocfsはふつうにマウントしてましたねえ と言うか sysutils/desktop-installer でDE入れると勝手に設定されるので >>211 ああ、やっぱり。 「wine: could not load」の件は、まさに「おま環」(お前の環境特有) だった、ということでした。大騒ぎしてすいませんでした。 fstabの見直しで、procfsの設定に追加して、tmpfsに128MBを設定したという、 あつものに懲りてなますを吹くかのような執筆者君です。 あと、i386-wineが出てきた直後ぐらいに、2chで、i386-wineが待てない人用、 として手作業の方法をレスしていた方が、Portsはユーザが、makeしてinstall することができないので、i386-wine的なものに対応しづらい、と 読んだことがあったような気がする。 ※技評のWebの後藤大地氏のFreeBSDの記事で読んだのかもしれない。 Linuxもバイナリ配布が主で、ports的な仕組みからバイナリを作って いるんだろうけど、どうしているのかなあ。 手順の再まとめをする時用にアンカーを打っておこう。 >>12 まず、wime最新の、wime4.1.5の件。 「wime-4.1.5/exe/apisup.c:680: undefined reference to `mempcpy'」 としてgmakeが通りません。 以下、「wime-4.1.5/lib/freebsd.h」より引用。 >#ifndef FREEBSD_MEMPCMP >//いつからかは分からないが、13.1には存在する。 とのことで、組み合わせを試しましたが FreeBSD13.1R/i386ではwime4.1.4のgmakeは通らない。 FreeBSD13.0R/i386ではwime4.1.5のgmakeは通らない。 FreeBSD13.1R/i386でgmakeを通したければwime4.1.5を選択する。 FreeBSD13.0R/i386でgmakeを通したければwime4.1.4を選択する。 という結果になりました。 >>45 などのように、以下のようなエラーが出ることがあります。 gmake[1]: *** 'wimeapi.o' に必要なターゲット 'X11/keysym.h' を make するルールがありません. 中止. gmake[1]: ディレクトリ '/usr/home/ユーザ名/work/wime-4.1.5/so' から出ます gmake: *** [Makefile:12: so] エラー 2 この件は、解決しました。 執筆者の低スキルに由来するはずですが、pkg(8)から入れたWineの バイナリだけでは、wimeは、gmakeが通りません。 PortsでWineをmakeだけ(make installしていない)した場合は、 gmakeが通ります。 おそらく、Wineのmake作業に必要な、依存する何かのパッケージの ある、なし、で、通る、通らない、があるのだと思います。 FreshPortsなどから、依存関係を追っかけると、何が足りずに wimeのgmakeでエラーが出るのか、が判明すると思いますが、 執筆者には知識がないので、これ以上の追求は無理とさせてください。 注意: FreeBSD13.1Rでの一般的な用途で、pkg(8)から各種ソフトウェアを 入れた場合、llvm13が入りますが、Wine7系をPortsからmakeする 場合は、llvm12に依存していますので、あらかじめpkg(8)で入れて おくとよいでしょう。 手順の再まとめ >>12 wimeの件の続き。 wime4.1.5の現在も「wime-4.1.5/io/Makefile」には、 >#amd64でi386-wineを動かしているとき >ifeq "$(WOW64)" "1" >override CC:=$(CC32_ENV) $(CC) >override CFLAGS+=-m32 >override LDFLAGS+=-m32 >#さらにfreebsdのとき。LDFLAGSのlibX11.soのパスを >/usr/local/libから/usr/local/lib32にする。 とありますので、amd64のi386-wineでもgmakeが通ると思います。 いや、まあ、i386-wineは、なくなったんですけどね。 手順の再まとめ >>14 Wineの試行で環境がぐちゃぐちゃになり、不審な動きをするように なったので、「pkg delete -a」でpkg(8)を入れ直しました。 一部はPortsから入れるのですが、以下のようなメッセージが 出ていました。 *現在のFreeBSD13.1R/amd64のpkg(8)の場合 # pkg install virtualbox-ose-kmod-6.1.36 (中略) To avoid crashes due to kernel incompatibility, this module will only load on FreeBSD 13.0 kernels. *現在のFreeBSD13.1R/amd64のPortsの場合 virtualbox-ose-kmod # make install (中略) To avoid crashes due to kernel incompatibility, this module will only load on FreeBSD 13.1 kernels. ちゃんとメッセージが出ていましたね。 >>170 ,174,178,184 の助言と経験のおかげで書くのですが、 新バージョン公開から3か月で、旧バージョンはEnd of Lifeと なりますので、あと少しで、pkg(8)から入るKernelModuleは、 13.1でmakeされたものが提供されることになるでしょう。 FreeBSDでWOW64みたいな動きをするようになったWineとwimeの話です。 現在のFreeBSD13.1R/amd64でのwine-devel7.14(WOW64)で、 32bitなATOKを動かすために、FreeBSD13.1R/i386上でwimeのパッチを あてて、Portsからmakeしても、imm32.dll.soでなく、imm32.dllしか できていないので、amd64のWineには、imm32.dllを持ってきて 配置することになります。 FreeBSD13.1R/amd64のWine7.14では、imm32.dllがある場所は、以下です。 ~/.i386-wine-pkg/usr/local/lib/wine/fakedlls/imm32.dll ~/.wine/drive_c/windows/system32/imm32.dll ※以前にはあった「wine/i386-windows」「wine/i386-unix」は なくなっています。>>29 >>71 そのどちらに置いてもwimeは動きません(パッチがあたっていない状態)。 ただし、FreeBSD13.1R/i386には、 「wine/i386-windows」「wine/i386-unix」があり、 /usr/local/lib/wine/i386-windowsの下にはimm32.dllがある(注) ので、(試していませんが)i386では動くと思われます。 注: pkg(8)標準のimm32.dll(135168byte)と、wimeのpatchを当てた Portsのものとでは、サイズは同じですが、md5は違いました。 再まとめ用: 「wimeのパッチはリネームも編集もせずにそのまま置けばよい」>>11 「Wine7系からはパッチを当てても、imm.c.origとリネームされた オリジナルのソースファイルは残らなくなった」 FreeBSD13.1R/amd64で、wine-devel7.14(WOW64)を入れて、 「/usr/local/share/wine/pkg32.sh install wine mesa-dri」 としてホームディレクトリ以下にWineの32bit環境を展開しよう としたら、なぜか、wine-6.0.4_1,1.pkgをfetchしています。 もちろん、 >wine [wine-6.0.4] and wine64 [wine-7.14] versions do not match! と言われました。「pkg32.sh upgrade」してもupgrade済みとなります。 FreeBSD13.1R/amd64にwine-6.0.4を入れ、同様に32bit環境を展開したら 正常に展開されました。 これだと、wineとi386-wineに分かれていた時と変わりませんね。 Alexander88207氏は、どう思っているのだろう。 >>219 そこは /usr/local/share/wine/pkg32.sh install wine-devel mesa-dri だろ >>128 に、 >FreeBSD13.0R/amd64+Wine(i386-wine-devel-6.12)+ >wime4.1.4+ATOK17(2004)+emacs-canna-27.2 の >環境下において。 >emacs-canna標準の、canna.el使用時の、漢字変換時に、 >ごくまれに、WindowsなATOKの変換候補のGUI表示がされる。 という謎の現象を書きましたが、その後も、ちょくちょく、 その現象は発生していました。 FreeBSD13.1R/amd64 Wine(i386-wine-devel-6.12)(13.0のもの) wime4.1.5(FreeBSD13.1R/i386でgmake) ATOK17(2004) emacs-canna-28.1 の環境下では、今のところ出ていません。 >>219 >>220 あ゛! あ゛! あ゛! 間違っていた! そりゃあ、そうですよね! pkgのメッセージをそのままコピペしただけなんですけどね! いや、言い訳にはならないな! 間違ってました! すいませんでした! 執筆者としては、 FreeBSD13.1R/amd64とwimeによるimm32.dllの問題 >>217 で、 FreeBSDが14などになって、今、取り置きしている、i386-wineが 動かなくなったら、amd64からi386に戻るかもしれません。 Windowsの32bitソフトウェアを使いたいがために、 FreeBSDをi386(Tier2)に戻すのは執筆者ぐらいかと思います。 もっと、FreeBSDでwimeを使う方が増えてくれれば、 執筆者は質問者側に回れるのですが(昔からの野望)。 ただし、以前、試したのですが、Microsoft Office2000添付の IME2000はWineにはインストールできませんでした。 ※wime公式と同じ結果。 知らないかもしれないので書いとくが amd64でi386-wineはビルドできる https://wiki.freebsd.org/i386-Wine >>224 その記事は、昔から知っていたんですが、 ほぼ、理解できていませんでした。 今は、うっすら理解できます。 今のところ、Windows用のフリーのIMEはGoogle日本語入力しかなく、 それなら、mozcを使うだろうしなあ。 関係ないけど、販売版のWnn8もFreeBSDへの対応は遅すぎますし。 WXGも古すぎて動かしづらいしなあ。 まあ、手持ちのWindows用のIME(注)があれば、 ぜひ、wimeを使ってみてください。 wimeへのWineへのパッチは、ほぼATOK用ですから、素のWineで wimeが使える?、との期待が持てます。 注: http://www4.airnet.ne.jp/koabe/com_inet/im/feature4.html http://www4.airnet.ne.jp/koabe/com_inet/im/feature5.html 上記記事によると、Windows用の 3rd PartyのIMEは、 あまり、ないですね。 Windows3.1時代のIMEだと、16bitコードがあると、Wineだけでなく、 DOSBoxも必要になるうえ、動くかどうかも分かりませんし。 そもそも変換効率を上げたいがための、Wine+wime+AOTKなのに、 Windows3.1時代のIMEを試すくらいなら、今どきのUnixな かな漢字変換を使いますよね。 まあ、FepBridgeでDOSのFEPをUnixで、の時代があったとはいえ、 ですが。 >>219 の件、すいませんでした。 ※なぜか、>>98 では wine-develで走らせているのに 「versions do not match!」と言われているな。なぜだろう。 じゃ、夜食を食べてきます。 >>219-222 現在のWineの「versions do not match!」の件。 たしかに、>>98 の時は、wineでも、wine-develでも ダメだったような気がする。 執筆者のスキルは怪しいですから、どなたか、お手すきの時で 結構ですから、Wineを試す時に、32bit環境展開の追試行を してみてくださいませんか。 これからは、i386-wine的なものを実現したければ、 以下のように、自分でなんとかするしかありませんね。 >>224 の https://wiki.freebsd.org/i386-Wine >>212 の「待てない人用」のレス https://peace.5ch.net/test/read.cgi/unix/1390323139/91-n https://toro.5ch.net/test/read.cgi/unix/1371050502/104-n >>227 に追加。 2009年12月16日 FreeBSD/amd64でWineを実行する方法(回避策に近い) https://gihyo.jp/admin/clip/01/fdt/200912/16 ※技評のサイト、見た目が今風に変わりましたね。 Wine on FreeBSD/amd64 - kszk’s blog https://kszk-beta.hatenadiary.org/entry/20111207/1323221938 ※ここも昔、見たような気がする。 FreeBSD Wine Configuration https://linuxhint.com/freebsd-wine-configuration/ ※ここも昔、見たような気がする。 Installing wine under FreeBSD 8 amd64 - jan0schs deck https://makandracards.com/jan0sch/13429-installing-wine-under-freebsd-8-amd64 ※初見のような気がする。 Installing wine under FreeBSD 8 amd64 https://www.jan0sch.de/post/installing-wine-under-freebsd-8-amd64/ ※初見のような気がする。 いつも思うんですが、amd64でi386環境をbuildworldするなら、 単純に、インストーラから、i386のbaseを持ってきて、 展開してもいいのではないかと思う。 やだぁ。こういうこと? しようがないわね(意味深)。 環境:FreeBSD13.1R/amd64 :Wine(i386-wine-devel-6.12)(13.0のもの) :wime4.1.5(FreeBSD13.1R/i386でgmake) :Windows用ATOK17(2004) :emacs-canna-28.1/ng-canna/kinput2 -canna Cannaとして使っているだけなので、ATOKのIMEのパレットは出ません。 もちろん、ATOKが出す変換候補のGUI表示も出ません。 両方とも、むかしは、何かのタイミングで出ることがありましたが、 描画されるだけで機能しません。 この描画は勝手に消えてくれないので、ATOKのプロパティを 表示(wimectrl -s)して終了すると、一緒に消えます。 ※ごくごく、まれに起こる、この現象のためにも、ATOKのプロパティは 機能しないと困るのです(>>95 の理由)。 ATOKのプロパティを表示しながら、漢字変換はできないので、 2枚になりました。 いま気づきましたが、二重敬語の補正の指摘が、左上に出ますが、 表示されるだけなので、指示通りのキー打鍵をしても、 自動的に補正されません。表示されるだけです。 確定などの、次の動作をすると、指摘は消えてくれます。 ※imgurはアカウントを取るのが面倒なのでimepicで。 http://imepic.jp/20220818/059700 http://imepic.jp/20220818/061470 そう言うズレた事やるなら今後俺が何かを手助けする事は無い libX11.so.6 が無いのは解決してなかったのか これは x11/libX11 でインストールされる libxcb, libXau, libXdmcp にも依存してるけど 試してないけど /usr/local/share/wine/pkg32.sh install libX11 で解決しないか あとimm32だけどi386のwineをpkg32.shでインストールした後 パッチをあてたimm32.dllをコピーするんじゃなくて i386のportsで make package でパッチをあてたwineのパッケージをつくって そのi386のwineを /usr/local/share/wine/pkg32.sh add 「パッケージのファイル名」 でインストールしてみたらどうなるの だけど libX11 は mesa-dri の依存関係でインストールされる筈だよな > versions do not match! もし、パッケージマネージャに複数のリポジトリを登録してるなら pkg32.shを呼ぶときにリポジトリを指定しないと混ざって不整合起こす可能性があるよ。 こっちの環境でそれ喰らって少し悩んだけど結局pkgを呼んでるわけだからオプション付けるだけ。 wine-devel 7.8.1でjanestyleの通信回りが動かなかった悲しみ。 >>227 これでいいんか? https://i.imgur.com/gobPqEo.jpg >>231 ここまでの流れをざっと見てみると何がしたいのかサッパリわからんな おまかん自慢? ちゃんと読まないからwineじゃなくてwine-develの事だと分からないんだろ ちゃんと読めば「既存パッケージで32bitアプリも64bitアプリも同時に動かせるのに何故過去の遺産に拘っているのか」 と首を傾げているって事では それは消えた i386-wine-devel のほうが今の wine よりバージョンが上だからでは そして wine-devel(7系?)では imm32.dll.so が無くなったせいなのか wime が動かないと バージョンが上とかじゃないな wimeの作成環境に書いてあるのがwineのstableじゃなくて開発版だから wine-develなのか 検証不可能だが要はこれが望む環境で使えんライブラリであると https://i.imgur.com/JtkfBpN.png 何をゴチャゴチャビルドだのdevelだの書いていると思ったわ /procがどうのこうのだの切り分けが半端だったんだから先ずは不満な人が 既存パッケージで作れる環境でいちから試せば少しでも前進するんじゃね imm32.dll.so と書いてるのはwime君であってwimeの作者じゃないけどな 作者は imm.c にパッチをあてろと書いてるだけ >>242 wine-devel でも imm.c はある というか>>217-218 見るとパッチがあたって無い wine-devel/files に置くんじゃなくて make patch の後手作業でファイルを変更してみたら ソースが無いって話はしてないぞ imm32.dll.so が無くなった でも imm32.dll.so なんて言ってるのはwime君で作者じゃない linux でも7系では imm32.dll.so は無いようだ つまり氏のコレは早とちりか何かと 206 名前:FreeBSDでwimeを使っている君 []: 2022/08/08(月) 20:52:30.49 注: i386-wineで32bitなATOKを使う場合、32bitなファイル(imm32.dll.so)に wimeのパッチをあてる必要がありますが、i386-wineは、バイナリ配布の ため、i386-wineのportsでwimeのパッチをあてるのは、そもそも無理だった、 ということになります >imm32.dll.so あるよ latestの wine-devel-7.14,1 i386のパッケージを展開し確認 quarterly の7.8に同梱されているかはしらん >>248 あ、微妙に違ってた imm32.dll はあるが imm32.dll.so というファイルは無い >>249 >imm32.dll マジックナンバー文字列は「MZ」 作者が書いてるのは imm.c にパッチをあてろ(wime-4.1.5 の環境は wine 7.7) wime君はパッチが影響するのは imm32.dll.so と判断した 6系まではそれでよかったのかもしれないが 7系では imm32.dll.so は無くなった だからファイルをコピーするんじゃなくてパッチをあてた wine 全体をインストールするように>>233 でもよく読んだら wine-devel(7系)ではパッチがあたってない だからとりあえず手作業でファイルを変更してみては >>244 >>248-249 i386 の quarterly の wine-devel-7.8,1.pkg、latest の wine-devel-7.8,1.pkg には無い +MANIFEST にも無い > i386 の quarterly の wine-devel-7.8,1.pkg > には無い +MANIFEST にも無い コレでええの?elfバイナリでは無い様だが https://i.imgur.com/944HNI4.png > latest の wine-devel-7.8,1.pkg 現在pkgに存在しないバージョンの様だが更新していないportsでもつかってんのかな > 現在pkgに存在しないバージョンの様だが更新していないportsでもつかってんのかな コピペミス wine-devel-7.14,1.pkg >>231 twm愛好家なんだ よかったらあっちのスレも盛り上げてよ 13.1-RELEASE-p1 quarterly いつの間にか sysutils/fusefs-smbnetfs がふつうに使える様になっとる クライアントマシンとしてSMB2以降を使いたい人にはオススメ >>232 ん? よく意味が分からないです……。 悪いところがあれば直します。 助言者が欲しくて書いているようなものですから。 >>255 「あっち」? あらやだ、すごいことになってるわ、困ったわね(意味深)。 画像のチカラってすごいのかな(意味深)。 ※こんなボケを書く雰囲気ではないんですけれど一応。 個別にレスできませんが、誤解を解きたいです。 >>239 の通りで、執筆者が今のところ、i386-wine-devel(6.12)を 使うのは、pkg(8)も、Portsも、現在のWineは6.0.4だからです。 なぜ、Wineのdevel版なのか、は、さがわ@sagawa_aki氏の修正が、 即、入っていたりして、新しいからです。 今までWineの「devel」で困ったことは、Wine1系の時に、 まったく動かなかったことが、2度あっただけで、 数日後に即、修正版が出ましたから、 Wineの「開発版」とはいえ、信頼しているから、です。 日本語入力メソッド総合スレッド@Linux@5ch掲示板 https://mao.5ch.net/test/read.cgi/linux/1472658083/30 でも勧めましたし。 >>217 の試行では、wine-devel(7.14)がPortsのVersion でしたので、pkg(8)も、一時的に、latestにしました。 >>244 >imm32.dll.so と書いてるのはwime君であって その通りで、imm32.dll.soとか、imm32.dllとか、 のことを書いているのは執筆者本人のみです。 「wime」ではパッチをあてろとしか言っていません。 >>246 >>251 の通りです。>>217 の繰り返しになりますが、 amd64のpkg(8)のwine-devel(7.14)では、imm32.dllは、 ホームディレクトリ以下の、 ~/.i386-wine-pkg/usr/local/lib/wine/fakedlls/imm32.dll ~/.wine/drive_c/windows/system32/imm32.dll の下にしかなく、ファイルサイズもかなり小さいうえ、 サイズも同じでした。「fakedlls」だからでしょうか。 ※i386のPortsのwine-devel(7.14)では、以下に存在します。 /usr/local/lib/wine/i386-windows/imm32.dll ※アンカーをつけすぎると書き込めないので細切れになります。 〔次に続く〕 〔前からの続き〕 i386で作った(パッチをあてた)imm32.dllの場合、 C言語は読めませんが、imm32.cにパッチ内の文字列が 含まれていたので、imm32.dllには正常にパッチがあたって いると判断しました。 ※以前は、FreeBSDのPortsで「imm.c」にパッチをあてると 「imm.c.orig」などと元のファイルが残りましたが、 今は、残りません。 >>217 の(注)でも書きましたが、i386上での話ですが、 pkg(8)標準のimm32.dll(135168byte)と、wimeのパッチを 当てたPortsのものとでは、サイズは同じですが、md5が 違ったので、正常にパッチがあたったものと考えています。 imm32.dll.soがなくなったのは、Wine7系以降、 「分離作業が行われているから」か、と思います。 >>69 の時点で、 FreeBSD13.0R/amd64で、Wine7.0.r2(WOW64対応版)で wimeを動かそうと試行しました。 >>67 で、 Wineにwimeのパッチ(imm-magic-1.7.3)をあてたのは、 FreeBSD13.0R/i386上のWine7.2(WOW64対応版)です。 その時点で、「imm32.dll.so」でなく、「imm32.dll」が できるようになっていました。 できた「imm32.dll」を、FreeBSD13.0R/amd64上の Wine7.0.r2(WOW64対応版)に持ってきました (少しぐらいのバージョン違いは気にしません)。 〔次に続く〕 〔前からの続き〕 その結果が、>>71 です。 「imm32.dll」は、 /home/ユーザ名/.i386-wine-pkg/usr/local/lib/wine/i386-windows/imm32.dll として置き、wimeにより、ATOKは動きました。 ただし、以下のような問題が生じました。>>95 >>99 ・wimeのwimectrlが("libX11.so.6" not found)のエラーを 出して動かない。 ・文節区切りの変更でWineがエラーを出して停止。詳細は >>96 Wineの64bit/32bitの「versions do not match!」の件は、 Wine7.4(devel版)の時点でも起こっています。>>98 >>233 >>235 >/usr/local/share/wine/pkg32.sh add 「パッケージのファイル名」 i386で作ったパッケージを「/home/ユーザ名/.i386-wine-pkg」 として持って来られるとは思っていませんでした。 >>263 pkg がビルドされているのは13.0R、13.1Rとはコンパイラのバージョンが違うので md5が違うのは当然 >>262 では、肝心なことを書き忘れていました。 ホームディレクトリ以下に展開される32bit環境では、 Wine7.14では、「lib/wine/fakedlls」しかなく、 「lib/wine/i386-windows」はなくなっています。 しかし、Wine7.14をi386でmakeすると、 「i386-windows」は存在します。 >>267 ああ、そうなのか。知りませんでした。 パッチをあてて、オリジナルファイルを残さないのは おかしいですから、なんとなくですが、 そもそも、パッチがあたっていない可能性があります。 FreeBSD13.1R/amd64のpkg(8)は、quarterlyですので、wine-devel-7.8,1で 試したかったのですが、PortsTreeでは、wine-devel-7.14になっています。 portdowngradeをしたのですが、wine-devel-6.4が最新で、7.8には 戻れませんので、wine-6.0.4,1で試行する事にします。 VirtualBOXの、FreeBSD13.1R/i386のPortsから、wine-6.0.4_1,1を makeします。もちろん、wimeのimm-magic-1.7.3をあてます(注)。 make packageし、wine-6.0.4_1,1.pkgをamd64側に持って来ました。 amd64のpkgはwine-6.0.4,1です。 amd64で、pkg installし、>>233 の助言の通り、pkg32.shを走らせます。 /usr/local/share/wine/pkg32.sh add /フルパス/wine-6.0.4_1,1.pkg すると足りないpkg(8)が、たくさんありました。 メッセージで言われる「mesa-dri」の他は、以下、列挙します。 FAudio,desktop-file-utils,fontconfig,gcc11,gnutls,jpeg-turbo, lcms2,libGLU,libXcomposite,openal-soft,vkd3d これだけ入れると自作のwine-6.0.4_1,1.pkgが ホームディレクトリ以下に入りました。 (注)基本に戻るのは大事だと痛感しました。 https://docs.freebsd.org/ja/books/porters-handbook/slow/ によると、やはりパッチは、ファイル名の頭に「patch」とつけ、 「patch-imm-magic-1.7.3」とし、内容も文頭の「wine-1.7.3」 のバージョンを削ったほうがよいようです make後、imm32.c.origが残っており、「+」の行が追加され 「-」の行が削除されていました。 コメント行も追加されていました。>>218 は間違いです。 ※ >>11 再まとめの際は注意。 FreeBSD13.1R/amd64 ・pkg(8)からのwine-6.0.4,1 ・ホームディレクトリ以下の32bitのWineは、 i386でmake packageしたwimeのパッチが あたったwine-6.0.4_1,1.pkg この環境で、32bitなxyzzy.exeが動くのを確認しました。 ※.wineの新規生成はしていない。 この環境で、i386でgmakeしたwime-4.1.5の動作確認です。 ・wimeでの漢字変換はOK。 ・wineの引数でATOK17UT.EXEを指定しての辞書Utilityの起動はOK。 ・「wimectrl -s」による、ATOKのプロパティの起動はダメ。 ld-elf32.so.1: Shared object "libX11.so.6" not found, required by "wimectrl" ※桁折り済み >>233 の助言による、「pkg32.sh install」での libX11,libxcb,libXau,libXdmcp は「already installed」でした。 >>273 wime-4.1.5/io/Makefile の ifneq "$(OS)" "Linux" override LDFLAGS:=$(subst local/lib,local/lib32,$(LDFLAGS)) endif を消してみたらどうなる? wimeのバイナリをi386で作ったのが問題かと、 wimeを、wine-6.0.4と32bit環境が入ったamd64で、gmakeし直しました。 wimeのconf.mkで「"WOW64?=1"」にした場合、 ld: error: unable to find library -lX11 clang: error: linker command failed with exit code 1 (use -v to see invocation) ※桁折り済み となり、gmakeが通りませんでした。 wimeのconf.mkで「"WOW64?=0"」にした場合、gmakeが通りました。 amd64(wine-6.0.4と自前の32bit環境)で、gmakeした wime-4.1.5の動作確認です。 ・「wime -e atok」での起動(CannaServerの起動と同じ)で 以下のように言われる。 0148:err:process:exec_process failed to load L "W:\\bin\\wime.exe.so" error c000035a ※桁折り済み ・wineの引数でATOK17UT.EXEを指定しての辞書Utilityの起動はOK。 ・「wimectrl -s」による、ATOKのプロパティの起動はOK。 amd64で作った「wime.exe.so」は、以下でした。 %file wime.exe.so wime.exe.so: ELF 64-bit LSB shared object, x86-64, version 1 (FreeBSD), dynamically linked, for FreeBSD 13.1, with debug_info, not stripped ※桁折り済み では、と、amd64で、gmakeした、wimeのwime.exe.soを、 i386でgmakeしたもの(動作確認済み)に差し替えてみては どうか、と試しましたが、 「W:\\bin\\wime.exe.so" not supported on this system」 と言われました。 なぜなの? Wine側の64bit/32bitの切り替えに何かがあるのかなあ。 「ld-elf32.so.1: Shared object "libX11.so.6" not found,」 の件がなんとかなれば、とも思います。 i386-wine-develとi386でgmakeしたwime-4.1.5に戻ってきました。 >>274 wime-4.1.5/io/Makefile の ifneq "$(OS)" "Linux" override LDFLAGS:=$(subst local/lib,local/lib32,$(LDFLAGS)) endif をコメントアウトし、i386でgmakeしたバイナリを amd64のWOW64なwine-6.0.4に持ってきました。 ・wimeでの漢字変換はOK。 ・「wimectrl -s」 ld-elf32.so.1: Shared object "libX11.so.6" not found, required by "wimectrl" ※桁折り済み と >>273 と同じ結果となりました。 32bit の libX11.so.6 があるディレクトリを ldconfig -32 で追加したら https://github.com/chriswells0/freebsd-scripts ここの portsfetch で quarterly の ports tree が取得できる wine-devel も 7.8,1 ○漢字変換はできるが、「wimectrl -s」(ATOKのプロパティ起動)で ld-elf32.so.1: Shared object "libX11.so.6" not found, required by "wimectrl" となり、ATOKのプロパティが起動できない件。 環境は >>273 と同じで以下。 FreeBSD13.1R/amd64 ・pkg(8)からのwine-6.0.4,1(WOW64のもの) ・ホームディレクトリ以下の32bitのWineは、i386でmake packageした wimeのパッチがあたったwine-6.0.4_1,1.pkgを /usr/local/share/wine/pkg32.sh add /フルパス/wine-6.0.4_1,1.pkg とした ・wimeはFreeBSD13.1R/i386でgmakeしたwime-4.1.5 〔次に続く〕 〔前からの続き〕 >>278 動きました。 執筆者はwimeを手作業でホームディレクトリに置いて 運用しているのですが、 env LD_32_LIBRARY_PATH=/home/ユーザ名/wime/lib\ :/home/ユーザ名/.i386-wine-pkg/usr/local/lib \ /home/ユーザ名/wime/bin/wimectrl -s ※バックスラッシュで続いています として「.i386-wine-pkg/usr/local/lib」を追加することで、 「wimectrl -s」でATOKのプロパティが起動しました。 FreeBSD特有の話なので、wimeの作者に手間を取らせる質問を しなくて済みました。 みなさん、辛抱強い助言を、ありがとうございました。 本当にありがとうございました。 >>279 知りませんでした。後日、Wine7.x系をやってみます。 書き忘れていました。 >>269 で、 >ホームディレクトリ以下に展開される32bit環境では、 >Wine7.14では、「lib/wine/fakedlls」しかなく、 >「lib/wine/i386-windows」はなくなっています。 と書きましたが、 Wine6.0.4でも「lib/wine/fakedlls」しかありませんでした。 執筆者は、安直に「imm32.dll.so」や「imm32.dll」の ファイルだけを持って来ていましたが、 「パッケージで持ってくればよい」という知見が、 このスレで与えられました。 みなさんありがとうございました。 辛抱した代わりと言ってはなんだがよかったらtwmスレもちょいちょい書いてくれると嬉しい twmというか、ctwmだから、おじゃま虫だなあ。 執筆者君は、ctwm特有のカスタマイズはしないようにして、 すぐにtwmに切り替えられるような.ctwmを書いています。 twmのスレ、見てはいますが、特に書くネタはないなあ。 Windows3.1や、FreeBSDのAfterStep1.4からの慣れで、 「ウインドウを消すバツ(Xのロゴ)が最右端でないと、 使いにくいな」と、思ったことがあり、バツを最右端に する設定を、ググり中に見つけたが、バツを最右端にすると リサイズボタンが使いにくくなるのに気づいて、最右端は リサイズボタンなのだなあ、と、思ったことがあります。 よくあるウインドウのように隅っこでリサイズできると いいんだけど、窓枠が太くなるしなあ。 まあ、気をつけておきます。 それで思い出したけど、最近のGNOME系かな、 ユーザーサイド側の窓の装飾ってどうなの、と思う。 Window Manager を考えなくてもよいので、 管理の負担が減るとか、アプリケーション内の入れ子で 表示しやすい、というのが、あるのかもしれないけれど、 X Window Systemの考え方からは、逆行しているように思う。 もし、ユーザーサイド側の窓の装飾を、流行などで、 コロコロと変えられたら、ユーザ側からは地獄でしょ。 それに、そういう事をすると、逆に古びると思う。 「スマホ風のUIだって、プギャー」って時代も来るだろうし。 >>281 使ってないから知らなかったが net/gitup 見たら gitup.conf.sample に quarterly の設定もあるな ports の更新もこれ使えばいいんじゃね portsfetch でも更新できるから どちらでもいいが 「portsfetch」の、ご紹介ありがとうございました。 ありがたいShellScriptですね。 VirtualBox6.1.36内のFreeBSD13.1R/i386で、portsfetchを 動かしたところ、動作中にリブートがかかりました。 portsfetch内から追加パッケージをインストールしたまま 動かしていたからなのか、負荷がかかりすぎたのか、は 不明です。 ですが、リブート後、再度、portsfetch したら (何かを取得し直しになりましたが)、PortsTreeが quarterlyになりました。 さて、FreeBSDのWine7.8(WOW64)を試しました。 環境:FreeBSD13.1R/amd64 ・pkg(8)からのwine-devel-7.8,1(WOW64) ・HomeDirectory以下の32bitのWine環境(.i386-wine-pkg)は、 i386のPortsでwimeのPatchをあてたwine-devel-7.8,1を make packageし、amd64に持ってきたもの ・wime4.1.5は、FreeBSD13.1R/i386でgmakeしたもの amd64で、pkg(8)から、wine-devel-7.8を入れ、 %/usr/local/share/wine/pkg32.sh install mesa-dri FAudio desktop-file-utils fontconfig gcc11 gnutls jpeg-turbo lcms2 libGLU libXcomposite openal-soft vkd3d %/usr/local/share/wine/pkg32.sh add /フルパス/wine-devel-7.8,1.pkg とし、無事、wime4.1.5は動き、漢字変換できました。 ATOKのプロパティも以下のように 「.i386-wine-pkg/usr/local/lib」を追加して 起動しました。 env LD_32_LIBRARY_PATH=/home/ユーザ名/wime/lib\ :/home/ユーザ名/.i386-wine-pkg/usr/local/lib \ /home/ユーザ名/wime/bin/wimectrl -s 〔次に続く〕 〔前からの続き〕 Wineは、7系からUI(winecfg)が、昔のWindowsのような 灰色から、白に変わったんですね。 普通に漢字変換でき、xyzzyなども起動するのですが、 xyzzy内から、印刷をクリックすると、 「通常使うプリンタが設定されていません」です。 Wineでは、FreeBSD側で正常に印刷できる状態なら、 Wineでも印刷できます。 ※執筆者は昔ながらの「/usr/bin/lp」を使っています。 Wine7.x系からは、変わったようです。 初めて、Wine7.0を試したとき(>>94-96 )も 「通常使うプリンタが設定されていません」 だったのもあり、即、i386-wine-develに戻ったことを 思い出しました。 いろいろとググりましたが、Wine7.x以降での プリンタまわりの変更点は分かりませんでした。 ※Wineのコントロールパネルでは設定できませんしね。 で、Win6.0.4に戻りました。 Win6.0.4では、プリンタは、printcapの設定通りに見えて、 印刷できました。 Wine7.x系で、64bitで動くソフトウェアからの印刷は 試していませんが、32bitWine側で、 「lpd_enable="YES"」とか「/etc/printcap」 みたいなことができれば、使えるような気もします。 参考: Wine - ArchWiki https://wiki.archlinux.jp/index.php/Wine#.E5.8D.B0.E5.88.B7 >win32 prefix で wine アプリケーション (例: MS Word) を使って >プリンター (ローカル・ネットワーク両方) を使用するには >lib32-libcups パッケージをインストールしてください。 ※ArchWikiは良いですよね。 大昔によくあったXでの設定も、ちゃんと載っていますし。 素直に pkg32.sh で cups インストールして設定すればいいと思うが □いまさらながらCUPSを試す 1/3 ※これからは、文章中で人物を「方(かた)」でなく「人(ひと)」と 呼称します。「方(ほう)」と、まぎらわしいためです。 まれに表記の「ゆらぎ」があるかと思いますが、ご容赦願います。 環境:FreeBSD13.1R/amd64 , cups-2.4.2 :LAN接続したBrother社のPostScript互換言語のBR-Script3搭載の 複合機に昔ながらの「/usr/bin/lp」から印刷するという形です。 ※他メーカでも、PostScript互換言語搭載機が存在します。 現在、執筆者は、昔ながらの「/usr/bin/lp」(以下「LPR」とする)を 使って印刷しています。 PostScript互換言語搭載機だと、「/etc/printcap」を ちょこっと書くだけで使えるので便利です。 実際に、Wine6.x系や、libreoffice-7.3.5.2で印刷できる状態です。 「今どきはCUPSだよね」という事で、重い腰を上げ、CUPSを試しました。 ○rc.conf lpd_enable="YES"(/usr/bin/lpの起動)を、CommetOut。 「cupsd_enable="YES"」「cups_browsed_enable="YES"」を追加。 ○サーチパス CUPSが起動しないように、変更してあるパスの 「/usr/bin /usr/local/bin」を 「/usr/local/bin /usr/bin」の、本来の形に変更。 ※CUPSの存在に困って、この入れ替え設定をしている人は、 それなりにおられると思います。 □いまさらながらCUPSを試す 2/3 ○機種名.ppd Brotherのサイトから、MacOS用のppdファイルとされるものを ダウンロードし、 機種名など.dmg→機種名など.pkg→機種名.gz→機種名、の ファイルを抽出します。ついでに機種名.ppdとReNameしておきます。 執筆者はMacOSには、うといので、「機種名など.dmg」から Windows版の「7-Zip Ver22.00」を使用してppdファイルを 抽出しました。 ※ppdファイルは必ず必要というわけではありませんが、 類似型番の機種設定で使うより、気持ちいいと思います。 ※ppdファイルの内容を見て、文書頭にあるパスっぽい部分は MacOS特有のようなので削除しました。 ○CUPS設定手順 ブラウザで「http://localhost:631/ 」を開き、 上のバー状メニューの「Administration」から指定してゆきます。 途中でloginが求められますが、root様を指定してください。 「add」でプリンタが見えますが、「Discovered」で見えた機種名を 選ばないでください。※後でネットワーク接続の設定をするため。 「LPD/LPR Host or Printer」を選び、 Connection:の、lpdと入っている部分を 「lpd://192.168.x.x/binary_p1」とIPアドレスを追加編集します。 下の方の「Or Provide a PPD File:」で、前述のMacOS用ファイルから 抽出したppdファイルを指定します。 □いまさらながらCUPSを試す 3/3 以上の手順で、CUPSで印刷できます。 実際に、leafpadと、libreofficeで、印刷できました。 印刷キューは「http://localhost:631/jobs/ 」で見えました。 参考にしたサイト: HL-5380DN, Debian http://bm.skr.jp/linux/5380dn.html Linux上で印刷する (CUPSを設定する) - Let's Try It! https://www.letstryit.net/2010/03/linux-cups.html FreeBSD10.0システムインストール http://web.cc.yamaguchi-u.ac.jp/ ~hiroshi/FreeBSD/OKI-C610dn.html 5.5 プリンタの設定 | あらかると https://www.starlink.jp/freebsd/freebsd-cups/ □FreeBSDのWOW64な、Wine6.x系、Wine7.x系からの印刷 1/2 *執筆者特有の条件 ・Wine6.0.4、Wine7.8のどちらにもwimeのパッチをあてた i386なpkg(8)を「pkg32.sh install」。 ・Wine6.0.4、Wine7.8のどちらも、i386なpkg(8)の makeオプションは標準のままなので 「CUPS=off: CUPS printing system support」のまま。 *状態 ・LPR(/usr/bin/lp)、CUPSのどちらも、 amd64ネィティブのlibreofficeなどから印刷できるのを 確認済みの状態。 *目標 WOW64なWineで、32bitなWindowsソフトウェアからの印刷をめざす。 「%/usr/local/share/wine/pkg32.sh install」で、指定のpkg(8)を ユーザのホームディレクトリ以下に、ユーザ権限でインストールした うえで、追加として「cups」「cups-filters」をインストールしました。 □FreeBSDのWOW64な、Wine6.x系、Wine7.x系からの印刷 2/2 *Wine6.0.4 LPRで印刷できる。 CUPSでは「通常使うプリンタが設定されていません」。 ※Wine6.0.4では、「lpd_enable="YES"」を切ってあっても 「/etc/printcap」の中身を見てプリンタ名を返しています。 *Wine7.8(wine-devel) LPRで「通常使うプリンタが設定されていません」。 CUPSでも「通常使うプリンタが設定されていません」。 という結果になりました。 32bitなWineを「CUPS=on」でmakeすればいいのかもしれませんが、 そこまでして「CUPS」を使いたいわけではないし……。 Wine7.x系に、特段の思い入れがあるわけでもないし……、 なので、Wineの安定版が7.xになってから試すことにします。 それを思えば、libreofficeは、LPRでも、CUPSでも、印刷できて 偉いなあ、と思います。 じゃ、お夜食を食べてきます。 備忘録。 タイミングで該当バージョンに当たった人がいるかもしれませんが firefox-105は避けた方がよいようです。 Firefox-ESRが105固定になりませんように。 https://mevius.5ch.net/test/read.cgi/unix/1632283136/154-171 Firefoxは常に最新使ってるが105の時も落ちた事はないな なおESRになるバージョンは決まってる https://wiki.mozilla.org/Release_Management/Calendar あ、やっぱり、1つだけの報告の場合、 判断は保留したほうがいいのか。 つい、飛びついちゃうな。 ReleaseCalendarは知りませんでした。 ありがとうございました。 少し前にWine8.0がReleaceされました。 さがわ@sagawa_aki (sagawa_aki/status/1618968131002834944) >Wineの32bitライブラリがUnixシステムの32bitライブラリ >(FreeTypeやGstreamerなど)を使わなくなるので、 >その分のディスクスペースを節約できます。 >将来にディストリビューションがi386パッケージの提供をやめても、 >32bitのコードセグメントを実行する機構を残してくれれば、へっちゃらです。 >10:44 PM ・ Jan 27, 2023 FreeBSDのWOW64なWineが、64bit版Wineと、32bit版Wineを、 たばねた(注1)ような状態(注2)であるのは、 Wineの開発方向を把握した上で、将来的に対応しやすいように 配慮してあるのかもしれません。 「/usr/local/share/wine/pkg32.sh install wine mesa-dri」として、 pkg(8)の指示による、ユーザ実行のShellScriptで、 32bit版のWineを、ユーザのホームディレクトリに インストールしなくてもよくなる方向か、と思います。 注1:別々に存在する物を同時に使えるようにしてある。 注2:Linux版も同様の状態かもしれませんが、執筆者は Linuxを知らないのでわかりません。 ※投稿時に、書き込みの末尾に、自動的にゴミがつくので twitterURLの先頭部分をカットしています。 >>303 参考URL WineHQ - Wine Announcement - The Wine team is proud to announce that the stable release Wine 8.0 https://www.winehq.org/announce/8.0 「Wine 8.0」がリリース 〜LinuxでWindowsのGUIアプリを直接実行できる互換レイヤー - 窓の杜 https://forest.watch.impress.co.jp/docs/news/1473266.html 今夜も Wine で乾杯! - 23本目 https://mao.5ch.net/test/read.cgi/linux/1585198566/744-n >このリファクタリングが完全に完了すると、 >基幹のkernel32.dllやgdi32.dll、user32.dllすら >wineのからwindowsのに差し替えても動作するはずなので、 >理屈の上では互換性がさらに向上するはず (中略) >従来の64bit Linuxで32bitバイナリを動かす仕組みではなく、 >64bitWindowsと同様の仕組みで32bit windowsバイナリを実行できる >新しいWOW64が実装された さがわ@sagawa_aki (sagawa_aki/status/1634408136709918725) >Wine 8以降のコミットをみると、IMM32によるIMEサポートを >加えようとしている様子がうかがえる。 >方針がMLで共有されていないので、先行きは不明だけれど、 >XIMと決別できるといいなあ。 1:17 PM ・ Mar 11, 2023 (全文引用)(改行位置は引用者)(twitterURLの先頭部分をカット) との事で、 うまくゆけば、Wine環境下で動作するWindowsソフトウェアに対して WindowsのIMEを使って入力する事が可能になるかもしれません。 そうなれば、wimeが修正される可能性も、あるかと思われます。 (備考1) 大昔の事で、どこで読んだか忘れましたが、 既知情報として、MicrosoftOffice付属などのMicrosoftIMEは、 Wine環境下にInstallできない(エラー停止)、とされています。 (備考2) Wine8系のportが進まないのか、FreeBSDのVersionUpのタイミングに 合わせるのか、一般ユーザには事情が分かりかねますが、FreshPortsに よると、現時点で、FreeBSDのwine-develは、7.22,1です。 2023/05/31にwime4.1.6がリリースされていました。 「パッチの整理」との事です。 パッチファイルが、WineのVersion別(Wine7.x、Wine8.x)に 増加しています。 wime4.1.6のReadmeの「Wineへのパッチ」を見ると、 Wine7系、Wine8.4までは、必要に応じて各種パッチをあてる必要が ありますが、Wine8.6以降では、パッチは必要なくなります。 ただし、 「wimegtkやwimeximでかな入力をする場合はパッチkanainputを適用」 とのことです。 ※kanainputは、Wine5.8以降、Wine7.7以降、Wine8.3以降の別がある。 単純にCannaとして使う場合、Wine8.6以降の場合、 Wineを自前でmakeする必要がなくなりました。 執筆者としては、とてもうれしいです。 まあ、現在のFreeBSDのwine-develは7.22なんですが。 FreeBSDの場合、64bit版ATOKは、Wine環境下にinstallできない、と、 執筆者は、どこかで読んだような気がするので、実際にその通りなら、 64bit版ATOK用のwimeのtransmsgパッチは、考えなくてもよいと 思います。 いずれ、64bit版ATOKがFreeBSDでの64bitなWine環境下にinstall できるようになってから(ならないかもしれませんが)、 考えればよいでしょう。 いずれにしても、ATOKが32bit版をリリースしなくなったら、 FreeBSDではどうするか、という問題が残ります。 現時点では「ATOK Passport」には、32bit版があります(注)が、 おそらく、Windowsの動きに追従すると思いますので、 32bit版Windowsが完全に消えた場合、ATOKも32bit版が 新規に入手できなくなるかもしれません。 (注) ATOK Passport32bit版のVersionUpが、2023/02/10に、 UpdateModuleが、2022/06/21に更新されている。 前スレッドを事実上の占有状態で消費した事による贖罪の意味で、 執筆者は、次スレッドとして、このスレッドを作成しました。 別にスレッドのヌシというわけではありません。 5ch(2ch)専用ブラウザ分裂がらみの「talk」掲示板のUNIX板には、 このスレッドと同名のスレッド(>>1 のみがある状態)が存在しますが、 執筆者が関与したものではありません。 >>1 のみが、コピーされた形でのスレッドのようです。 「出典」という形で、このスレッドのURLが表記されてはいますが、 著作権的にはどうなんでしょうね。 「出典」には、あたらないように思います。以上です。 32bitWineは少なくとも15、16では動くだろうけど先のことは分からない 15.0が出るとまた方針が変わるかもしれないよと https://cgit.freebsd.org/src/commit/RELNOTES?id=da51a1211dc799fa123f5d7f041eaf83c36f976b 今の流れ的には32bitに関して考慮する必要があるのは主にarmとWineについてで i386自体はもういいだろって感じ 14.0では32bitカーネルは非推奨で15.0で削除される可能性があると警告が出るようになった でも最終決定はまだ 15.0ではサポートされるのはCOMPAT_FREEBSD32とlib32で ネイティブな32bitプラットフォームは非推奨ということですな そしてstable/14は一週間遅れ 妙なスレ立てがあるようなのでsageたままにします。 「FreeBSDでwimeを使っている君」は、情弱です。 情報提供ありがとうございます。 FreeBSD/i386がTier2になって、すぐ感のあるいま、こういう話が 出ているんですね。人手、運用、設備を考えても仕方がないかなあ。 cgit.freebsd.org/src/commit/RELNOTE を翻訳にかけて読む限り、 Athlon64(AMD64・x86-64)以前の32bit機では、FreeBSDは 特定バージョンで打ち切りになるかもしれない、という事ですね。 Linuxでも32bit版を提供するDistributionが減っていますしね。 PAE_Kernelの記事でお世話になった「uyota 匠の一手」氏の反応は どうか、と、思いましたが、いまのところ記事はないようです。 COMPAT_FREEBSD32と、lib32は、残るそうなので、32bitバイナリの 実行、32bitのソースコードのコンパイルはできますね。 そういうものがあるかどうかは知りませんが、ソース非公開の 商用などのソフトウェアで、それっきり更新されていない場合でも、 WXGの経緯(使い続けようとするユーザー側の努力)を参考にすると、 それなりの期間は安心かもしれません。 ドライバはソースを書き換えないと無理かもしれませんが、 その頃には、ハードウェア自体が腐っているかもしれませんし。 何かの事情で、COMPAT_FREEBSD32とlib32がベースシステムから、 なくなるとしても、純粋なcshがportsに移った経緯がありました から、何とかなるかもしれません。 COMPAT_FREEBSD32とlib32、最終版Kernel、をベースに 独自のi386版としてフォークする動きがあるとおもしろいんですが、 ないでしょうね。 それで、Wineの場合です。 Wineの場合、Windows業界に蓄積された膨大なソフトウェア資産を Unix系でも使いたい、というのが、もともとの趣旨でもあります。 そういうエロゲがあるかどうかは知りませんが、32bit版Windows向けの、 他機種に移植されていない特定バージョンのゲームがしたい、 などの要望は、性癖に関わりそうな話ですので、 Wineに対して、きわめて強い要望がありそうです。 ですが、>>303 に「さがわ@sagawa_aki」氏の引用をしましたが、 Wine8.0以降ならば、将来的に問題とは、ならなさそうです。 未来の話ですが、FreeBSDでのWine+wime+ATOKの場合、です。 現在、FreeBSD/amd64の64bit版のWineでは、64bit版ATOKが インストールできませんが、インストールでき、動作すれば、 問題はありませんし、さがわ氏の引用に依ると、32bit版ATOKも Wine側で対応できそうです。 余談ですが、大昔の一太郎では関連モジュール的なものに 16bitなWindowsバイナリが残っていたそう(公式に依るとそれを 更新したという記述がありました)なので、 一太郎の完全な64bit化は遅いかもしれません。 執筆者は、32bit版ATOK用のwimeのバイナリを仮想環境下の FreeBSD/i386でgmakeしているのですが、この作業が、 どう変わるか、と思っています。 wimeのMakeFileに記述が入ればよいのですが、 wime作者のthomas氏はLinuxなので……。 執筆者は、wimeのPorts化すらできないので、修正する能力は、 当然ながらありません。キリッ! FreeBSDでwimeを使っている君は、タイミングが悪いです。 i386wineの時も、書いた直後に新情報(統合する)を見つけ、 追加のレスをした記憶があります。 Wine公式のWineHQによると、以下の通りで、安定版と開発版の 両方とも、メジャーバージョンは8系に上がっています。 まあ、それが普通ですね。 Stable : Wine 8.0.2 Development : Wine 8.14 FreshPortsによると、以下の通りですが、 FreeBSDでは、安定版と開発版のメジャーバージョンに ズレが生じています。まあ、よくある事なんですが。 執筆者的には、wine-develが8.11に上がっており、>>306 の理由で 非常にうれしいです。 さらに、新規に「wine7」ができていました。 FreeBSDでの安定版が、Wine8系に上がっても、明示的にWine7系を 使い続けたければ、「wine7」を使用する、という事かと思います。 wine 7.0.2_5,1 Last Update: 2023-08-18 21:57:12 wine-devel 8.11_1,1 Last Update: 2023-08-20 08:07:09 wine7 7.0.2_1 Port Added: 2023-07-30 22:00:06 Last Update: 2023-08-19 11:19:32 FreshPortsでの、Wine8.11の流れですが、wine-devel8.11,1時点では、 32bit版Wineに問題が生じていたようですが、8.11_1,1では、 問題ないようです。 「bump」とは、「stuck」に対応して「プログラムを実行する」 という意味なんでしょうか。 ○8.11,1 13 Aug 2023 13:29:15 >Finally, Wine 8.x so far does not appear to work on FreeBSD/i386, >so mark as BROKEN. Still better to progress than being stuck. ○8.11,1 15 Aug 2023 21:57:36 >emulators/wine-devel: Fix 32-bit pkg invocation for WoW64 (中略) >Do not bump PORTREVISION since 32-bit builds are broken right now. ○8.11_1,1 20 Aug 2023 08:07:09 >Bump PORTREVSION accordingly. PORTREVISIONを増やすのは元のバージョンは変わってないけど ports/pkgに変更があったので再インストールさせたい時 >>318 知りませんでした。非常に勉強になりました。 「PORTREVSION」そのものも、まったく理解していませんでした。 「_1」「_1,1」は、単純なmakeのやり直しや、リンクされる物などの バージョンが上がった場合、だと思っていました。 「Bump」は、1段階引き上げる、という意味か。 単純翻訳の語意イメージと合致します。 質問スレ125の209に書きましたが、その分野を理解していないと 単純翻訳だけではダメだ、という例ですね。 ググって、以下を知りました。 5.2.2.3. Example of PORTREVISION and PORTEPOCH Usage https://people.freebsd.org/ ~olivierd/porters-handbook/makefile-naming.html PORTREVISIONは「never decreases」とは知りませんでした。 FreeBSDへ移植する場合、移植元ソフトウェアにバージョンが ない場合などでも、PORTVERSIONに単純な日付をつけるのは、 数値の大小問題が出るかもしれないので避けたほうがよいの ですね。 PORTREVISIONは、命名が移植者に委ねられており、pintaを 例にとると、まず、移植元バージョンが「1.7.1」ならば、 「1.7.1」がつく。これは、「1.7.1,0」と見なされる。 次のバージョン命名がなされれば「1.7.1,1」となる。 ※実際には「1.7.1,1」はないが。 移植元上でなく、FreeBSD上だけで、必要な修正があった場合、 「1.7.1_1」(1.7.1_1,0)となる。 元バージョンが「7.0」から「7.0.1」にUpした場合(人間的には 大の数値だが)、機械的には、大の数値と判定されないので、 あらかじめ(※注)、「7.0,1」と命名しておき、「7.0.1」は、 「7.0.1,1」と命名される。 ※注:Wineのバージョン命名は決まっているので、あらかじめ、 リビジョンUpに備えて、「,1」をつけてあるのではないか。 また、遠目に見ると「7.0,1」を「7.0.1」と誤認する可能性も あるので、必ず「*,1」をつける命名を選択したほうがよいかも しれませんしね。 PORTREVISIONを理解すると、「*,1」で、不備などがあると 明記されている場合、「*_1」を待とう、と、判断する事も、 できるのですね。 勉強になりました。ありがとうございました。 PORTREVISIONとPORTEPOCHがごっちゃになってる PORTEPOCHが増やされるのは単純に数値的に比較すると バージョンの大小が判断できない時 Wineを例にすると20050930から0.9にバージョンアップした時 https://cgit.freebsd.org/ports/commit/emulators/wine/Makefile?id=943fc1582ce5f4bf7b55a853f4205bdfcc433080 あー、かなり混同しています。 指摘されるまで気づきませんでした。 引用URLの例のまま、gtkmumble-0.10を例にすると。 PORTNAME=gtkmumble PORTVERSION=0.10 命名→gtkmumble-0.10 ※0.10,0と見なされる。 FreeBSDでpatchされました。 PORTNAME=gtkmumble PORTVERSION=0.10 PORTREVISION=1 ※見落としていた。リビジョンだった。 命名→gtkmumble0.10_1 ※0.10_1,0と見なされる。 命名の数値大小問題でPORTEPOCHがつきました。 PORTNAME=gtkmumble PORTVERSION=0.2 PORTEPOCH=1 ※よく分かっていなかった。 命名→gtkmumble-0.2,1 命名の数値大小問題の後のバージョン。 ※PORTEPOCHが「never decreases」なので 最初から「,1」がついている。 PORTNAME=gtkmumble PORTVERSION=0.3 PORTEPOCH=1 命名→gtkmumble-0.3,1 と、いう事は、ある時点で、PORTEPOCH=1がついた場合、 ずっと「0.3,1」のように後のバージョンにも最初から 「,1」がつき続ける、と。 なぜ、Wineに最初から「,1」がついているかと言うと、 20050930から0.9になった時に「,1」がついたから、と いう事ですね。 pintaに「,1」がついていないのも、PORTEPOCHを設定する 状況がなかったから、という事ですね。 PORTVERSIONに日付をつけてもいいが、 後に日付ではないバージョンが出た場合や、 移植元ソフトウェアのバージョンのつけ間違いなどが あった場合(引用URLでの例)、数値大小問題が発生するので PORTEPOCHをつけてね、という事ですね。 混乱したまま、書いていました。 すっきりしました。ありがとうございました。 >>320 の後半と>>321 は間違いです。 ネイティブのchromiumからlinux版のwidevineが利用できるようになりました まだ細かい不具合があるようですがいずれlinux版のchromiumなどを使わ なくてもNetflixなどのDRMで保護された動画を見れるようになるでしょう 執筆者自身、FreeBSD上では、DRMで悩む事はないのですが、 こういう動きがあるたびに「あー、FreeBSDでよかったなあ」と 思います。 今では、FreeBSDって、なんだか、日本国内より、海外のほうが、 動くというか、若いというか、パワフル感がありますね。 Linuxより動きが遅くても、うれしいものです。 FreeBSD15.0-CURRENTでもi386版(非推奨ではありますが >>311 )が あります。よかったです。 32bit機に入れるわけではないのですが、i386版上でwimeをgmakeする という目的がありますので、ないと困ります。 たったこれだけのために、仮想環境でFreeBSD/i386を、というのも どうなのよ、なのですが。 これ、wimeをamd64版上で、COMPAT_FREEBSD32と、lib32を利用して 32bitバイナリとして、コンパイルする方法はないものですかね。 どうも。レスを書いて、寝かせてから投稿をする執筆者君です。 サーバ自体は動いており、該当サーバ上の他の板は開けるのに ブラウザでUNIX板トップを開くと、真っ白だったので、 復旧を忘れ去られていたらどうしよう、と思っていましたが、 まだ、やや、重いものの、UNIX板、稼働するようになりました。 「したらば」と、「おーぷん」に、UNIX板が「あるにはある」のを 発見しましたが、業者宣伝で埋まっていたり、過疎で荒れて タンブルウィードが転がっていそうな、開設した管理者ですら 忘却の彼方っぽい所(「したらば」は板ごとの開設管理者だったか、 と思います)へ移住するのもどうか、と思いましたし、 執筆者自身で開設するのも、管理業務が発生してしまううえ、 移住する住人感情の面でも「君が管理者カヨー」となりますので、 「どうなのよ」、と思いました。 ※「t*l*.jp」掲示板のUNIX板は廃止され、スレは「パソコン一般」に 移動したようです。 その掲示板の「語れ」スレに、そちら側でレスがついていなければ、 こちらからコピーしたUNIX板由来のスレが、キレイに消えていたのに、 と思います。 UNIX板で、すでにある古いスレのタイトルと、1をコピーして、 スレたてをする動きがありますね。 スレタイを不完全にコピーしたものや、文章中にhtmlっぽいものが 入っているのを見ると、作業は「機械」でしょうね。 「意志」は人間だろう、と思いますが。 古いスレに他愛ない内容の上げレスなどをつける動きもありますね。 もう、ネタが古びているし、転用もしづらいスレタイなんだから、 上げなくてもいいでしょうに。ヒマ人(婉曲表現)はいるものですね。 必要もないのにスレッドタイトルを微妙に変えたり、必要もないのに 個人感情由来のサブタイトルを、つけ足したりして、スレ立てするのも どうかと思いますし、一気に埋め立ててしまうのも、とても、とても、 どうかと思います。 「(CM声で)おカネは大事だよぉー。でも、スレタイ的にも、FreeBSDの 動きの最新情報は、もっと大事だよぉー」なので、落ち着くまで、 このスレで、FreeBSDを語ったり、質問をしても、よいのではないか、と 思います。 「(アニメ声で)こんな事もあろうかと」、 1の内容に「などの整備」「手段は問わない」を、入れておきました。 つーか、「公式を見ろ」ではあるものの、執筆者君は、情報弱者なので、 リリース情報などは知りたいですし。 じゃ、お夜食を食べるとします。 がーん。「語れPart58」が立ってました。 スレ一覧を見ればよかったお……。 サーバが重いもので、つい……。 「(今日のわんこ声)またしてもタイミングの悪い執筆者君でしたー」 シレッと、こういう理由で立てる方法があったか……。 FreeBSDを語れPart58@UNIX https://mevius.5ch.net/test/read.cgi/unix/1696777979 上記スレでは、FreeBSD14以降の32bit版の話題が出ています。 32bitソフトウェアを稼働させるWine的には、 FreeBSD側(Wineが稼働するOS側)の32bit環境は、 必要がなくなりつつありますが、 執筆者君的に不安なのは、wime側の話です。 Wine上で稼働する32bit版ATOKを、ATOKのユーザインタフェイスの ままで、emacsに入力する、という可能性も、あるかもしれませんが、 それだと、wimeのグッドアイデアとしての 「Cannaとして振る舞う」 の良さがなくなるしなあ。 まあ、FreeBSD/i386(FreeBSDの32bit版)の動きと、 wimeの動きを注視する事にします。 UNIX板にも、「Keyboard キーボード 3」のスレがあるんですが、 廃墟になって十年近いので、こちらに書きます。 PC系媒体でのニュースはもちろんの事、ハードウェア板の 「Happy Hacking Keyboard US」スレや、 「IBM/Lenovo トラックポイント付き単体キーボード」でも 話題の、今はリコーグループとなったPFUから「HHKB Studio」が 発売され、速攻で売り切れたらしい、という話です。 媒体記事や、使用レポートは、たくさん出回っていますが、 機能、仕様の報告となっている記事を貼っておきます。 OSもアプリも関係なく自分の作法であらゆるデバイスを使いたい〜HHKB Studioならそれができるかも https://pc.watch.impress.co.jp/docs/column/config/1542688.html 「HHKB Studio」とは、HappyHackingKeyboardに、IBMのNotePCの ThinkPadのようなマウス用途のポイントスイッチ(マウスカーソル・ マウスクルーザー)の“ポッチ”がつきました、という話なんですが、 過去には、ThinkPadのキーボードだけ、の製品があったように、 ThinkPadな人には、たまらないでしょうね。 製品の記事は、Windowsが前提なだけに、やはり、公式の キーマップ変更用のツールも、Windowsや、Macが対象のようです。 ※前述記事に依ると、キーカスタマイズは、「HHKB Studio」自身が 記憶する。カスタマイズを試行する記述が興味深いので カスタマイズ周りが気になる人は読んでみてください。 「HHKB Studio」は、FreeBSDでは、どのように認識されるか、 ゼスチャ機能は、X_Window_System(xev)では、どういうキーコードを 吐くのか、興味がわきます。X_Window_Systemでも、割り当てて 使いたいですしね。 少し欲しい気持ちになりつつ、NotePCを「尊師スタイル」で使う場合は、 場所を取らなくていいなあ、でも、マウスボタンを押しながら マウスクルーザーを動かすのはつらいかも……、などとも思いましたが、 執筆者君は、NotePCを使っていない、という事を思い出しました。 「中クリックでペースト」よ、さようなら? | スラド オープンソース https://opensource.srad.jp/story/13/09/25/0419255/ あらら、今って、こういう時代だったんですね。知りませんでした。 ※前回の書き込み時に2連投しようとしたのですが、書き込めなかった (書き込み成功は出るが、書き込みができていない)ので 日にちをおいて投稿しました。 今の書き込みも1回目は吸われ、文面を見直して2回目を投稿すると Rock54でした。NGワードがありました。 「製品『しょうかい』の記事は」(『』内は漢字) の2漢字単語がダメだったようです。犯罪誘因対策ですかね。 気になるDesktop環境ネタ。 poppler を使った各種PDFリーダで、合字が空白表示されたり、 合字にならずに表示される件。自力解決済み。 (質問125)https://mevius.5ch.net/test/read.cgi/unix/1632283136/216-n EeePC 4G-X に FreeBSD14.0R/i386をInstallした対処の報告。 (語れ058)https://mevius.5ch.net/test/read.cgi/unix/1696777979/77-n 最近の環境のemacsでの「anthy.el」で、anthyのON/OFFのトグルが うまく動作しない件。助言により、anthy.elの修正にて解決済み。 (語れ058)https://mevius.5ch.net/test/read.cgi/c/unix/1696777979/120-n 元コアでメンテナだった佐藤さんが japanese/kterm を復活させました >>336 おおっ! うれしい! ありがたい! ボランティア、頭が下がります。 ずいぶん昔から、標準の xterm で、日本語が通るように なりましたが、このフォントで、などと設定をしたくても、 イマイチ感がありました。 今どきは、各デスクトップ環境の物のみならず、 多くの仮想端末が存在するけれど、やっぱり、 日本語を扱う昔からの仮想端末の標準物として kterm が 存在しないとダメではないか、と思っていました。 FreshPorts >Last Update: 2024-01-07 17:30:34 >Resurrect kterm-6.2.0 復活してホッヤホヤ。 ktermのman見てたらutf-8と書いてあって gitのログ見たら2013年にUTF-8のサポートが追加されてた 知らなかった ( ゚ ⊇ ゚)チャーラ〜ヘッチャラ〜 ちょっとユルい感じになっている層が薄いだけやん 過去の犯罪者は騙されやすいから効果覿面 国葬は「ある」との違いかもだが 真っ向勝負の雑談配信を 今の仕事が許されるわけないの アクアリウムはやってないとかあるはずがないよね イェール中退しなかったら本物ってことか。 嵌め込み酷い それが出来やすくなるらしいから詰まりどころがないって? 視聴率取れないし客席ガラガラになるじゃん? ワイヤレスゲート空売りゴチ UNIX板にも、スレ立て荒らし、スクリプトらしき 書き込みの埋め立て荒らしは、一気という感じでなく、 チビチビと来ていますね。 現在、このスレの順位は418です。 100ほどスレ立て荒らしをされるとdat落ちする可能性が 高い、と感じました。 「スレが落ちたら立てればいいや」と思っていましたが、 スレ立ての労力(たいしたものではありませんが)や、 立てたい時に、システム変更で立てにくくなっているかも しれない、と、考え、何かを書いて、ageておいたほうが いいのでは、と思いました。 いま思えば、日本語入力ネタなら、UNIX板には、 「IMEなんとかしろ」のスレがあったのですが、 次スレが期待されるスレタイとは言い難いですしね。 執筆者的には、wimeや日本語入力、デスクトップ環境や、 Wineについて、飽きたわけではありません。 wimeネタは、執筆者が新規に試した場合、試用報告を するつもりでいます。書かずにはいられないですから。 まだ、古い環境を使っているので…。すいません。 いま見た、語れスレによると、6月には14.1Rとの事です。 うーん、執筆者的には、なんとも中途半端だお…。 じゃ、お夜食を食べてきます。 荒らし前はスレ順位が700くらいならまだ残ってたくらいだった 何度かスレを消してるんだろうけど抜本的な規制や対策する気がなさそう linux版のchromeもportsに追加されました www/linux-chrome 少し古いバージョンなのが残念ですが 前回のレスを書いた後に、スクリプトが100ほどスレを立てて、 このスレの順位が下がりましたが、数日後にスレ一覧を見ると 常識的な順位に戻っていました。 どなたかが、スクリプトなスレを「削除要請」から削除依頼して くださったのか、と、思いましたが、特に削除依頼は 出ていませんでした。 スクリプトなスレは運営が対処してくれているようですね。 ここぐらいのゆるい情報交換がいいんですよ。 facebookみたいに、個人情報や、「こじらせ」や、性癖をさらして 情報交換をするほど…、でもないんですよ。 でも、Wineやwimeが、Unix系ユーザに知られてほしいんですよ。 昔みたいにUnix系雑誌があれば、記事で知られるんでしょうけどね。 SoftwareDesign誌はLinux寄りVim寄りの総合誌っぽくなったしなあ。 Twitterは、アカウントなしでは時系列ではWeb閲覧できなくなったし、 Wineで有名な「さがわ@sagawa_aki」の投稿は、即ログイン表示で まったく見ることができないしなあ。 「twilog.togetter.com」なサイトは、リツイートが表示されないから 「さがわ@sagawa_aki」氏みたいなリツイートを集めるスタイルだと よくわからない時系列まとめにしかならないだろうしなあ。 「さがわ@sagawa_aki」氏、昔みたいにLinux板のWineスレに 来てくれたらなあ。 UNIX板の「Emacs Part 54」スレ(常駐している訳ではないです)で 「WindowsのMS-IMEを」の流れを見ていて思ったんですが。 FreeBSDでwimeを使っている君や、まだ見ぬwimeユーザの皆様は、 FreeBSD(Linuxでもよいが)+Wine+wime+Windows用ATOK で Emacsに対してCanna変換であるかのような振る舞いをする Windows用ATOK(などのWindows用IME)で日本語入力をしています。 これ、 Windows+Windows_Subsystem_for_Linux2+Linux(Ubuntu)+Emacs を構築する事で、 Windows用IMEでLinux側のEmacsに対して日本語入力できるのか、と 思って、 「いやいや、単にWindowsで使えるLinuxの仮想環境なんじゃないの、 だいたいさ、これじゃ、FreeBSDでwimeを使っている君、の努力がさ」 などと思ってググったのですが、Windows用IMEでLinux側のEmacsに対して 日本語入力はできないみたいですね。よかったw でも、単にEmacsに対して、Windows用IMEで入力したければ、 Windowsを利用するなら、Windowsに移植されたEmacsでもよいわけですし。 よくよく考えれば、FreeBSD+Wine+wime+Windows用ATOK、な、環境は、 PC用Unix(BSD系+Linux)の日本語入力環境に対して、 商用環境で熟成したWindows用(DOS用でもかまわないが)の日本語入力を 導入したいという環境な訳ですし。 まあ、商用環境で熟成したPC_Unix向けの日本語入力でもいいわけですが。 ああ、それならLinux/FreeBSD用のオムロンの商用Wnn8があったよなあ。 しかし、商用Wnn8もいつまでやってくれるかわからないしなあ。 というか、FreeBSD12.1Rのアップデート、が最後の動きですが、 パッケージは探せば、取り寄せで購入(販売店の問い合わせ) できるようです。 PC用Unix向けのWXGも、幾多の挑戦者の努力もむなしく、 いまでは動かないですしね。 有名な「翠風に舞え」さんによると、Wnn8はFreeBSD14.0Rでも 動くみたいです。 Wnn 8 on FreeBSD http://maikaze.cafe.coocan.jp/wnn8.html 執筆者は、Chrome系はあまり興味がなかったので 理解不足なのですが。 「Chromium」がもともとの元祖で、PC_Unix版が存在する。 「Chrome」はChromiumをもとにしたもので、 Windows版、MacOS_X版、Linux版、スマホ向け版が存在する。 FreeBSDには「Chromium」しかなく、「Chrome」は存在しない。 やっと、「linux-chrome」という形ではあるが、portsに追加された。 という理解でいいですか。 むかし、Firefoxでもflash再生問題だったかで、 「linux-firefox」みたいなのがあったような気がします。 >>351 は「FreeBSDでwimeを使っている君」です。 linux-firefoxもlinux-operaもあった linux-chromeはDRMなNetflixなどを見れるという利点(ネイティブにもwww/foreign-cdmはあるが)と ネイティブのpkg問題(時間がかかりすぎてビルドが途中でKillされるのでpkgが無いことがある)を 解決する 簡潔にして詳細な解説、ありがとうございました。 まったくの誤答ではないものの、かなり外した理解だった みたいです、すいません。 Linuxulator(Linuxバイナリ互換機能)はありがたい 存在ですね。 Linuxulatorは、Brother公式のLinux用lprドライバのために 使ったのが最初で、flashのために短期間、linux-firefoxを 使っていましたが、flashの時代ではなくなったので自然と 使わなくなりました。 linux-firefox、特に違和感はなかったです。 逆にサクサクと速く感じたぐらいです。 じゃ、お夜食を食べてきます。 日本人プログラマー向けコーディングフォント「Bizin Gothic」が無償公開 - 窓の杜 https://forest.watch.impress.co.jp/docs/news/1596755.html 「Ricty」でもお馴染みの「Inconsolata」と読みやすい「BIZ UDゴシック」をかけ合わせ 樽井 秀人 2024年6月3日 11:05 今までありがとう! 日本人プログラマー向けフォントの先駆者「Ricty」の開発が終了 - やじうまの杜 - 窓の杜 https://forest.watch.impress.co.jp/docs/serial/yajiuma/1478305.html 樽井 秀人 2023年2月14日 06:45 Rictyは入れてましたけど、使っていなかった執筆者君でしたー。 「FreeBSDを語れ」スレに書こうと思ったんですが、過去にレスが あったカーネルパニックのネタが来まして、レスが入り乱れると レスが読みにくくなる、と、落ち着くまで遠慮しよう、と、思ったの ですが、邪魔になりにくそうな、ここに書きます。 デスクトップ環境というか、生活環境の話だし、という事で。 偶然見つけたんですが、ケアレスミスだと思います。 FreeBSDでは(フォントさえあれば)コンソールで日本語が出る VTコンソールの時代になりましたが、kon2は、現在でもportsに 存在します。古いソフトウェアでも残りがちなのが、FreeBSDの 良いところですね。 執筆者君は、VTコンソールを「えー、UTFなのぉ」と言いながら 試してみた事がありますが、画面サイズは広くて良かったのですが、 トロトロカクカクとした遅い描画だったので、kon2を思い出して kon2を試してみたら、kon2のほうが描画が速かったです。 ただし、VGAサイズだったのですが…。 今どきは画面サイズが大きいからkon2の24dot版が、あっても よいような気もします。 (以下ケアレスミスと思われる部分の引用) 第15章 地域化 (localization) - i18n/L10n の利用と設定 | FreeBSD Documentation Portal docs.freebsd.org/ja/books/handbook/l10n/ 15.2.2. コンソールの設定 表 3. Ports Collection で利用可能なコンソール 言語 port の位置 日本語 chinese/kon2 >>357 は、書き込みが完了しても反映されないので (俗に言う「吸われる」状態)、 ハイパーテキストトランスファープロトコルの文字列を 削ると書き込めて反映されました。 今はFreeBSDにも削除魔が大勢いる /usr/ports/UPDATINGや/usr/ports/MOVEDは昔は20年分くらいあったのが 今はサポートされてるリリース以前は削除してるので3年分くらいしかない portsのexpiration dateも以前は長めの期間が設定されていたが 今は1、2ヶ月先を指定して期日が来ると即削除 ちゃんと動いていても開発が止まると放棄されてるからと削除してる 特にメンテナのいないportsは archivers/pxz(並列 xz)なんてバージョンが20220509なのにベースのxzが マルチスレッド対応してるからとEXPIRATION_DATEが設定された kon2などが残ってるのはjapaneseだから手を出してないだけ カーネルもGENERICにFreeBSD4からのCOMPATが指定されているが 最近一桁のFREEBSD4〜9を削除して10以降にしようと主張する奴が出てきた しかも設定だけじゃなくてコードを消そうと言う奴まで さすがにこれは却下された と最近のメーリングリストやバグ報告を見て感じた不満を書いてみた ええ…、FreeBSDってそんな状況になってるの…、怖い…。 なんだか、そういう削除魔というか、整理したい派というか、 そういう感覚って、潔癖症っぽくて、ちょっとなあ。 サーバ維持費の支払いが、ってなら仕方がないと思うけど。 FreshPortsでも「There is no maintainer for this port.」を よく見るようになりましたが、メンテナがいる状態にして、 開発してますよ感も出しておかないと、危険が危なそうですね。 メンテナがいてもね 例えばpcreはpcre2が出て放棄されてるから削除しよう pcreに依存してるportsもメンテナがいて動いていても削除だよ gtk2ももうすぐ削除する予定だからね状態 もちろん、正当に開発が続くべきであって、 「開発してますよ感」はすべきではないですけど。 むむむー。 何かあると、枕を並べて討ち死に、って感じかなあ。 makeが通ってバイナリが動くなら残せばいいと思うんですが。 GTK1のRedHat由来のElectricEyes(画像ビューワ)が、 GTK1削除(End_Of_Lifeだったか)と共に消えて代替物を 探したなあ。 別に、GTK1のElectricEyesで困ってなかったんですが。 PCManFM(ファイラー)は、GTK2版とGTK3版、QT5版が あって安心感があります。このような開発スタイルなら ツールキット由来の削除からは逃れられそうです。 みんなもArch Linuxおいでよ portsよりもよっぽとちゃんと管理されてるよ 20年来のFreeBSDファンだったが積もり積もった不満でとうとう見限ったわ サーバーはFreeBSD、しかし仮想化環境構築に疲れてProxmoxVEを入れたら楽すぎて笑った。 それつながりでノートパソコンにRoot on ZFSで最小構成インストールするのにインストーラ無視してDebianいれたあとでArchでええやんって言われた悲しみ。 異論は認めるが個人的にはFreeBSDはportsのインストール先を/usr/localにしてなきゃよかったのにと昔から思ってる。 これのせいで自前で入れる奴と競合するからportsから消えたのを入れるのがすごくめんどくさい。 wimeがリビジョンアップされました。 4.1.7 2024年6月11日 ・変換候補に環境依存文字があるとハングアップすることがあった。 ・qt5でセグメンテンテーションフォールトになる。 以下のスレにも告知しました。 日本語入力メソッド総合スレッド@Linux https://mao.5ch.net/test/read.cgi/linux/1472658083/ >>364 俺はFreeBSDからopenSuSEに行った read.cgi ver 07.5.5 2024/06/08 Walang Kapalit ★ | Donguri System Team 5ちゃんねる