BSD/LinuxでのOffice/Desktop環境を語れ! Part03
1 :名無しさん@お腹いっぱい。 :2021/10/06(水) 20:57:41.76 .net FreeBSD(*BSD)/LinuxなどのUnix系OSで,クライアント環境を 構築するためには,Office系ソフトウェア,Desktop環境, などの整備が重要になってくるはずだ. そのための手段は問わない.またまた熱く語ってくれ. FreeBSD での Office 環境を語れ! https://pc5.5ch.net/test/read.cgi/unix/1094394684/ FreeBSD での Office 環境を語れ! その2 https://mevius.5ch.net/test/read.cgi/unix/1107211157/
2 :名無しさん@お腹いっぱい。 :2021/10/06(水) 21:34:29.77 .net >>1 乙 メンテナにはなんとか頑張って頂いてwine復活すると良いですな
3 :名無しさん@お腹いっぱい。 :2021/10/10(日) 09:33:19.49 .net この件に関してこちらの方が適切でしょうから 近日検証してこちらへご報告させて頂きます https://mevius.5ch.net/test/read.cgi/unix/1630061644/67 > 67 名無しさん@お腹いっぱい。 sage 2021/09/11(土) 19:39:29.55 > 今更かも知れんけど、FreeBSDでzoom視られんのな(firefox)
4 :3 :2021/10/13(水) 21:37:20.29 .net >>3 Firefox93 にて zoom 試してみました カメラはロジクールC505 /etc/rc.conf に以下を追記 kld_list="普段ロードしているもの cuse" webcamd_enable="YES" 結果 https://i.imgur.com/i0fQopw.jpg 普通に使えますね もしカメラ認識が芳しくない時は multimedia/webcamoid を入れてごにょごにょすると宜しいかと webcamoid で映る時は zoom でも普通に映ったので
5 :3 :2021/10/13(水) 22:32:22.71 .net >>3 そうそう LinuxABI互換機能は有効にしておく必要があるでしょう
6 :名無しさん@お腹いっぱい。 :2021/10/14(木) 17:59:07.93 .net https://mevius.5ch.net/test/read.cgi/unix/1107211157/992 > 992 名前:FreeBSDでwimeを使っている君 [sage]: 2021/10/06(水) 19:48:39.70 > ○FreeBSD(amd64)のi386-wineならVersion6以降でも動くかも? latest の i386-wine-devel-6.12,1、なんか使えるみたいですよ 使えるようにする為に実施したことはこれだけです % doas pkg install i386-wine-devel % wineboot notepad+ と JaneStyle をお試しでインスコし普通に使えてます
7 :名無しさん@お腹いっぱい。 :2021/10/17(日) 16:02:38.55 .net >>4 テスト乙 Firefoxをバージョンアップするかな その前にまずFreeBSDをバージョンアップしたいけどw
8 :3 :2021/10/17(日) 17:44:27.08 .net >>7 FuryBSDだとデフォのまんまでWebカメ使えたんですが無くなっちゃいましたからね ついでにESRでもテストしてみました 問題ないですね https://i.imgur.com/yPgjG8m.jpg > FreeBSDをバージョンアップしたい サクッと make world イキますか
9 :FreeBSDでwimeを使っている君 :2021/10/18(月) 10:52:10.26 .net wime https://thomas66.web.fc2.com/wime/ 4.1.4 2021年9月26日 まれではあるが、よくURLが貼られているので、自分として制限をしている 「wimeの公式URLは、迷惑にならないよう、むやみに貼らないよう、気をつける」を 解除する事とします。 https://mao.5ch.net/test/read.cgi/linux/1472658083/124 にも告知しました。
10 :Wine + wime + ATOK(For Windows) on FreeBSD :2021/10/18(月) 11:04:08.38 .net □FreeBSDにおけるwime導入手順の再まとめ(2021/10/18) wimeとは、Wine環境下にインストールされたWindows用日本語IMEを Cannaサーバに見せかけて、Unix界に蓄積されたCanna系ソフトウェアを そのままで使えるようにする、というものです。 ここでは、もっともシンプルに、Cannaとして使う方法を記述します。 ただし、Wineが正常に動く事が大前提となります。 ※初出 https://mevius.5ch.net/test/read.cgi/unix/1107211157/804-n □環境 FreeBSD(i386) ports : wine , wine-devel どちらでもよい。ただし、現在のFreeBSDでは、 i386において、Wine5.8以降は、makeは通るが、バイナリは動作しない。 ※https://mevius.5ch.net/test/read.cgi/unix/1107211157/919-n amd64のi386-wineでは、メンテナのAlexander88207氏の対応により、 Wine6.0/Wine6.12は動作する。 ※https://mevius.5ch.net/test/read.cgi/unix/1633521461/6 pkg : ja-canna-lib-3.7p3 wimeをmakeするために必要。 現在では、ja-canna-libが、ja-canna-serverに依存していないので ja-canna-libだけを入れればよい。 pkg : gmake-4.x wimeをmakeするために必要。 wime-4.x.x.tar.bz2 公式サイトより取得の事。
11 :Wine + wime + ATOK(For Windows) on FreeBSD :2021/10/18(月) 11:12:15.31 .net ■ portsのWineに、wimeのimm-magicパッチをあてる 1. % /usr/bin/tar xvzf wime-4.x.x.tar.bz2(ユーザ権限でよい) 2. ほどいた wime-4.x.x/patch/imm-magic-1.7.3 の記述内容を変更。 最初の2行の両行とも、以下のようにバージョン名を削除。 wine-1.7.3/dlls/imm32/imm.c → dlls/imm32/imm.c ※すべきかどうかわかりませんが、patchの文法を知らないので。 現在の判断(未検証)ですが、おそらく内容変更も、 ファイル名変更も、しなくてもよいと思います。 3. wimeのimm-magic-1.7.3 を、patch-imm-magic-173 などと ファイル名を変更し、 /usr/ports/emulators/wine/files/patch-imm-magic-173 などとして置く。 ※リネームはしなくてもよいと思いましたが、すでに置かれている 他のパッチの命名方法にならいました。パッチをあてる順番の 正解はわかりませんが、imm.cを見ると、C言語は分かりませんが パッチ通りに変更されているように思えました。 4. ports/emulators/wine 下で、「# make ; make install」 私はmakeオプションは特に変えませんでした。 make install一発でも、portinstallとでも、お好きにどうぞ。 つまり、あらかじめ、wimeのパッチをwineのportsの パッチ置き場(wine/files)の下に置いておくのがポイントです。
12 :Wine + wime + ATOK(For Windows) on FreeBSD :2021/10/18(月) 11:22:37.04 .net ■ wimeをmakeする ※gmakeが必要 1. wime-4.x.x/conf.mk を対象に、wimeのmake時の変数を変更。 PREFIX?=/usr/local ※FreeBSDでは、このままでよい。 WINEDIR?=/usr/local ※FreeBSDでは、このままでよい。 WOW64?=1 ※「WOW64?=0」へ変更。 ※FreeBSD(i386)で32bitOSなので、Wineも32bit版となるため。 USE_CLANG?=0 ※FreeBSDでCLANGなので「USE_CLANG?=1」へ変更。 ※「USE_CLANG?」の記述がない場合は、単なる書き落としです。 処理内容は、conf.mkの末尾に存在するので、書き足してください。 「USE_CLANG?=1」がない場合、gccでコンパイルされてしまい、 FreeBSDでは動作しないバイナリができます。 2. wime4.x.x下で、ユーザ権限でよいので「% gmake」。 3. root様で「# gmake install」し、root様で「# ldconfig」。 ■ ATOKをWineへインストール 1. 「wine setup.exe」などとして、ATOKをWine環境下へインストール。 2. 「wine regedit.exe」し、 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Keyboard Layouts の「E0020411」を「E0010411」に変更。 3. 上記レジストリキーの「Ime File」が、フルパスつきの「atok??w.ime」 であった場合、パス部分を削ってファイル名のみに変更する。 ■ winecfgでの注意 「/usr/local」を W: ドライブなどのドライブに割り当てておく。 そうしないと、Wineからは「/usr/local」以下が見えないので wime起動時に「wine:cannot find 'wime.exe.so'」と言われて 起動できません。
13 :Wine + wime + ATOK(For Windows) on FreeBSD :2021/10/18(月) 11:38:41.59 .net ■ wimeの実行 wime4.0.0以降では、「wime -e atok」で起動する。 ■ wimeによるWindows版ATOKでの変換を試す ng-canna(注1)は、設定せずに、直接Cannaが扱えるので、 ng-cannaなどで、ジャストシステムのサイトで例示されている 二重敬語の校正指摘の例文を変換してみるとよいでしょう。 変換候補が以下のように表示されればATOKが動いています。 「お読みになられる《二重敬語「→お読みになる」》」 あとは、canna.el(注2)でも、yc.el(注3)でも、 scim-canna(注4)でも、kinput2 -cannaでも、 あたかもCannaServerを使っているかのように使用できます。 もちろん、この場合は、.cannaも読んでくれますので、 .cannaで、変換候補を1回で開くような設定をしていても、 (setq romkana-table "KANAinput_JibunKeyBoard.kp") みたいな設定をしていても大丈夫です。 (注1)Emacs like。pkg(8)では「ja-ng-canna」。 (注2)現在のほぼ公式と言ってよい、 https://ikumi.que.jp/cmp/emacs.html での、canna.elは、執筆者としては、yc.elで 満足しているため未検証です。 昔ながら(Muleなど)のcanna.elは、ng-cannaで いけるので大丈夫だと思います。 (注3)公式サイトは http://www.ceres.dti.ne.jp/~knak/yc.html 。 pkg(8)に「ja-yc.el-emacs27」などとして存在する。 (注4)https://mevius.5ch.net/test/read.cgi/unix/1107211157/993-n
14 :Wine + wime + ATOK(For Windows) on FreeBSD :2021/10/18(月) 11:57:01.04 .net □FreeBSD(amd64)でwimeを使う場合 FreeBSD(amd64)でもwimeは使えますが、32bitなATOKの場合、 i386-wine , i386-wine-devel で使用する事になります。 また、wimeも32bit版をmakeしないといけませんので、 実機のi386機なり、仮想環境のi386でmakeし、ファイルコピーなどで wimeのバイナリ群を持ってくる必要があります。 ※amd64でwimeを32bitとしてクロスコンパイルできれば、 持ってくる必要はありません。 また、32bitなWineでパッチがあたった「imm32.dll.so」も、 amd64のi386-wineに持ってくる必要があります ※i386-wineで、wimeのパッチがあたるかは、執筆者は未検証。 i386でWineにパッチをあてた「imm32.dll.so」は、 i386-wineに持ってきても、単純なファイルコピーで動きます。 ・imm32.dll.soを配置する場所。 amd64(i386-wine)/usr/local/lib32/wine/imm32.dll.so i386(wine) /usr/local/lib/wine/imm32.dll.so ・makeされたimm32.dll.soのバイナリが置かれている場所。 ※portsでは、該当ディレクトリのworkの下に インストール前のバイナリが置かれている。 ※以下は5.0でのパス。 emulators/wine/work/wine-5.0/dlls/imm32/imm32.dll.so なお、thomas氏によると、FreeBSDでは、64bit版ATOKは インストールできなかったそうです(公式サイト)。
15 :Wine + wime + ATOK(For Windows) on FreeBSD :2021/10/18(月) 12:04:41.67 .net □年度別のATOKのwimeでの動作状況 2004 ○ https://mevius.5ch.net/test/read.cgi/unix/1107211157/804-n ※執筆者によるCannaServerとしてのみの検証 2008 ○(公式)動作する 2010 ○(公式)動作する 2011 ○(公式)動作する 2012 ○(公式)動作する 2014 ×(公式)動作しない(詳しくは公式サイトで) 2015 ○(公式)動作する 2016 ○ https://mao.5ch.net/test/read.cgi/linux/1472658083/24-n ※おおむね動作する 2017 △(公式)動作するが(詳しくは公式サイトで) ※試用版と製品版では動作が異なる可能性があります。 ※他年度版の動作状況があれば、報告していただけると幸いです。
16 :Wine + wime + ATOK(For Windows) on FreeBSD :2021/10/18(月) 12:11:57.96 .net □現在執筆者が把握する似たような手法としての他の成果物一覧 ※URLは省略しました。ググれば出ます。 ・えせかんな(esecanna) 商用のVJE3.0/2.5,Wnn6をCannaクライアントで使う。 現在もFreeBSDには存在する。 japanese/esecannaを参照の事。 ・ximimm Windows版ATOKをWine上で動かし、LinuxのX11上のXIMから使用する。 2010年の製品版で動作確認、 2014年の体験版はインストールできず、との事。 ・canna2imm32 Cygwin環境下で、Cannaプロトコルにより、Windows側のIMEを使う。 ・FepBridge DOSエミュレータで、DOS/VのFEPを動かして、Unixから使う。 ・(OMRON)Wnn8 for Linux/BSD ※似たような手法ではありませんが。 現在も販売されているLinux/BSD用の商用かな漢字変換。 IIIMF(wnn8le)、XIM、GTK2系。 有志によるWebの知恵によると、Wnn7Egg、esecanna、 tamago-tsunagi(修正すれば)で、使う事が出来るとの事。 ※公式によると、FreeBSD12.1R以降ではamd64のみ対応、との事。
17 :FreeBSDでwimeを使っている君 :2021/10/18(月) 12:18:00.47 .net wimeで割り込んですいません。FreeBSDでwimeを使っている君です。 レスを見ていると、みなさんに支えられているなあ、と思います。 これからもよろしくお願いします。 「FreeBSDでwimeを使っている君」がセッセと書く理由は、 高スキルユーザ(パワーユーザ)さんなり、開発者さんなりの 目に止まり、事態が打開されて欲しいがためです。 今夜も Wine で乾杯! - 23本目@Linux https://mao.5ch.net/test/read.cgi/linux/1585198566/449 というレスも書きました。 (注)YAHOOのリアルタイム検索(事実上のTwitter検索)では 「wime」というアカウントが存在するようです。
18 :FreeBSDでwimeを使っている君 :2021/10/18(月) 12:21:58.73 .net >>3 FreeBSDを語れ Part54 の「zoom」のやりとりを見ていました。 動画が視られるだけでも、すごいと思います。 ただ、zoomでは音声が通らないという話でしたね。 >>6 ウッ、ブワッ(涙)。 わざわざ試していただき、ありがとうございます。 やはり、Wine6.x系は、i386-wineで動きましたか。 いっぱいググって、Alexander88207氏の生の声を 探し当てた甲斐がありました。
19 :3 :2021/10/18(月) 12:37:16.42 .net >>18 > zoomでは音声が通らない うちの者の携帯電話との同室セッションでハウリングを起こすくらい問題ありませんでした 環境によりきりかも知れませんが しかしさすがここの主wimeさん スレが一気に本格的になりましたな
20 :3 :2021/10/18(月) 12:45:51.18 .net >>19 但しこう言う事なのでしばらくはWebブラウザ版で利用する事になるでしょうね % psearch -c net-im zoom net-im/zoom Zoom videoconferencing client (CAVEAT: 【Sound doesn't yet work】)
21 :No Name :2021/10/18(月) 14:28:26.89 .net 俺はunixはmacとlinuxしか認めんぞ
22 :名無しさん@お腹いっぱい。 :2021/10/18(月) 14:46:30.90 .net 別にお前に認めてもらわんでも一向に構わんから
23 :名無しさん@お腹いっぱい。 :2021/10/18(月) 16:17:30.67 .net そもそもの話、どっちもUNIXじゃないのでは…?
24 :名無しさん@お腹いっぱい。 :2021/10/18(月) 16:30:06.96 .net ここ「BSD/LinuxでのOffice/Desktop環境を語れ!」なんだが 「UNIXの定義」について語りたいの?めんどくさい人だね
25 :FreeBSDでwimeを使っている君 :2021/10/25(月) 18:56:47.70 .net 「FreeBSDにおけるwime導入手順の再まとめ」 において誤りがあったと思います。 >>14 に、amd64のi386-wineに対して、 (i368でコンパイルした)「wimeのバイナリ群を持ってくる」 とか、 「クロスコンパイルできれば」 とか、 などと、書きましたが、誤っているのではないかと思います。 wime-4.x.x/io/Makefile には、「#amd64でi386-wineを」の コメントがあるので、FreeBSDのamd64でi386-wineを 使用している場合、wime-4.x.x/conf.mkで変更する変数を 「WOW64?=1」にすれば、amd64でも、wimeを32bitでコンパイル できるのではないかと思います。 https://mevius.5ch.net/test/read.cgi/unix/1107211157/836 で謝罪したのを忘れていました。 まことに申し訳ありませんでした。 ※執筆者はC言語もMakefileも理解していないので、 はっきりと書けずに申し訳ありません。
26 :3 :2021/10/25(月) 22:23:48.33 .net 本日とある用事でWebブラウザ版zoomをFirefoxから使用しました 序盤に音声の送信が滞ったものの少しごにょごにょして改善し普通に音声通話も可能になりました ご使用の際はwebcamoidもインスコしておくと事前に送信映像の解像度も手軽に出来て便利です
27 :FreeBSDでwimeを使っている君 :2021/11/12(金) 22:52:05.62 .net 執筆者が書く時だけは、目立つようにスレをageさせてください。 5chのクロールコピーっぽいサイトは、いっときより減ったものの、 まだまだ健在なので、情報が広がりやすいと思うのですが、 なかなか、「FreeBSDでWine6.xを使ったよ」「wimeはすごいねー」 という声は見かけませんね。 情報を広めるのは、大変なんですね。 そもそも一夜にして情報が広がるなんてオカシイですよね。 FreeBSDの公式サイトのリリーススケジュールが見つかりません。 昔は日付を入れて表になっていたような気がするんですが。 13.0Rの次のリリーススケジュールは、いつか分かりませんが、 あと半年ほどは、13.0Rのままだろう、今のうちに、と、 FreeBSD13.0R(i386)から、FreeBSD13.0R(amd64)に乗り換えました。 もちろん、目的はWine。 i386-wineの、Alexander88207氏の「回避策」に期待がかかります。 i386-wineですから、おそらく、次のFreeBSDのメジャーバージョンまで、 i386-wineのバージョンは、ほぼ固定状態になると思いますが、 なにより、確実に動くことが大切です。 結論から言うと、FreeBSD(amd64)で、Wine6.12(i386-wine-devel)は 動きました。 「ウヒョヒョヒョヒョヒョ」とスキップして踊りました。 みなさま、ありがとうございます。ありがとうございますう。
28 :FreeBSDでwimeを使っている君 :2021/11/12(金) 22:57:57.10 .net ただですね、>>6 氏の報告とは、やや、挙動が違いました。 FreeBSD13.0R(amd64)で、i386-wine-devel(Wine6.12)の 初回起動時に「%winecfg」(.wineの新規生成はせず)とすると wine:could not load ntdll.so:(null) と、言われますが、前スレであった助言 https://mevius.5ch.net/test/read.cgi/unix/1107211157/951 のように、以下のように環境変数を設定すると正常起動しました。 %env WINEDLLPATH=/usr/local/lib32/wine winecfg Wineのビルトインコマンド的な、winecfgではよいのですが、 実際に、hoge.exeを動かす時に困ります。 %env WINEDLLPATH=/usr/local/lib32/wine wine hoge.exe のように書かないといけない。 これはまずい。wimeの起動はどうすべきか。 けっきょく、.cshrc(.xinitrcなどでもいいけど)に 「setenv WINEDLLPATH /usr/local/lib32/wine」 と書く事にしました。
29 :FreeBSDでwimeを使っている君 :2021/11/12(金) 23:00:40.75 .net 執筆者は、Wine6.12のimm32.dll.soとwime4.1.4は、 i386でコンパイルされたバイナリをファイルコピーで 持ってきました。 >>14 のまとめの修正ですが、 FreeBSD(amd64)のi386-wine-devel(Wine6.12)では、 imm32.dll.soを配置する場所が以下のように変わりました。 「/usr/local/lib32/wine/i386-unix/imm32.dll.so」 しかし、なんで >>6 氏と挙動がちがうのだろう。 ・shか、cshの違い? 執筆者はtcshです。 ・モダンなデスクトップか、昔ながらのWindowManagerの違い? 執筆者はctwmです。
30 :FreeBSDでwimeを使っている君 :2021/11/12(金) 23:02:03.69 .net 以下の記事を読んで気づいたのですが、 今どきのWineの初回起動は、「%winecfg」でなく、 >>6 氏のように「%wineboot」とするもののようです。 Wineについては、あくまでもPlamoLinuxでの例ですが、 PlamoLinuxのメンテナ、こじまみつひろ氏が、 技術評論社で連載している記事が、理解を深めてくれます。 続・玩式草子 −戯れせんとや生まれけん−:連載|gihyo.jp … 技術評論社 https://gihyo.jp/lifestyle/serial/01/ganshiki-soushi-2
31 :FreeBSDでwimeを使っている君 :2021/11/12(金) 23:21:16.41 .net GenericKernelでPAE_Kernelとなったi386(Tier2)から amd64(Tier1)に乗り換えて思ったんですが。 ・amd64は、startxでコンソールからXを起動するのに数秒。 i386みたいに、15秒待つなんてことはない。 ・なんだか全体的に軽いような。キビキビしているような。 ・そもそも、ブートからlogin表示までも、amd64の方が速いような。 ・Conky読みだけど、メモリ総量が違う。i386は15.6G、amd64は15.5G。 ※ビデオカードのメモリ量が512Mです。 ・i386では、Firefox90以上で、「Gah. Your tab just crashed.」と 言われて、googleマップが見られなくなったり、アクセスによって 画面を生成するタイプ(うまく言えないですが、後面描画の後に前面 を描画するタイプ)のサイトが見られなくなったりしていたので、 FirefoxESR78にportdowgrade(戻れるバージョンがそれしかなかった) していたが、amd64ではFirefoxESR91で普通にgoogleマップが見られる。 いや、ま、それが普通だよね。 ・i386のFirefoxESR78の設定画面で、検索エンジンを選択する欄が 空っぽで、検索エンジンの追加もできなかったので、しかたがなく、 文字列をマウスでコピーして右クリックでgoogle検索をするadd-onsを 入れていたが、FirefoxESR91だと普通に検索エンジンがある。 EUとかの政治的な規制で検索エンジン欄が空になったんじゃないのか。 あれは何だったんだよお。 ・i386のFirefoxESR78では、5chのスレで文字列をマウスでコピーして 右クリックをすると、ImageをSaveとか、Playだとか、Volumeだとかの メニューが画面の上から下まで出ていた。ただのテキストを扱うのに なんでマルチメディアなメニューが見境なく出て来ていたんだろう。 という感じです。
32 :FreeBSDでwimeを使っている君 :2021/11/12(金) 23:44:33.01 .net 広大なメモリを使いたければ、amd64(64bit)が、普通の選択肢であり、 PAE_Kernelは「無理を承知でどうしても」のための物なのかも しれません。 PAE_Kernelを追いかけていた「uyota 匠の一手」氏も、 そういう感じで使っているようですし。 そうそう、VZエディタライクなエディタの「ne」(pkgで入れた)は、 amd64ではセグメントエラーでした。 i386では動いていたような気がするけどなあ。 「PANIXのカタログに、そういう物がありますよ、って出てたなあ」 と、入れただけなんですが。 VZエディタのキーアサインで覚えているのは、 Ctrl-K-K、Ctrl-K-C、コマンドラインでESCでファイラ、 ぐらいで、Emacs歴のほうがずっと長くなりました。 FreeBSD13.0R(amd64)でi386-wine-devel(Wine6.12)が 動いて、回避策の対応をしていただいたMaintainerの Alexander88207氏には大感謝です。 さーて、夜食でも食べてくるかなーあ。 うは、うほほーい。
33 :名無しさん@お腹いっぱい。 :2021/11/13(土) 00:57:21.11 .net 長いことemacs+wanderlustを使ってたけど、キーバインドを覚えるor調べるのに疲れて、 thunderbirdに乗り換えちゃったよ
34 :名無しさん@お腹いっぱい。 :2021/11/13(土) 07:25:22.14 .net >>33 グッジョブ! コンピュータなんて楽できてなんぼだからね
35 :6 :2021/11/13(土) 11:13:30.67 .net >>29 当方環境 OSバージョン:FreeBSD 13.0-RELEASE-p4 amd64(当時) インタラクティブシェル:/bin/tcsh GUI環境:Window Maker、Fluxbox 等 たまにモダンなデスクトップ環境も使用しております
36 :FreeBSDでwimeを使っている君 :2021/11/15(月) 17:51:51.59 .net # pkg upgrade Installed packages to be REINSTALLED: dialog4ports-0.1.6_1 (option removed: CHINESE) 新しい冷戦が始まる(始まっている)と言われていますが、 米中新冷戦って意味合いでremovedなんでしょうか。
37 :FreeBSDでwimeを使っている君 :2021/11/15(月) 17:55:31.51 .net >>29 wimeの事を書き忘れていましたが、 FreeBSD(amd64)のi386-wine-devel(Wine6.12)において、 i386でコンパイルされたimm32.dll.soをファイルコピーで 持ってきて、 「/usr/local/lib32/wine/i386-unix/imm32.dll.so」に 置いたことにより、 Wine6.12 + wime4.1.4 + ATOK17(2004)で動いています。 >>35 6氏、ありがとうございます。 6氏もプロンプトに「%」を使っているので、csh系だと 思っていたのですが。 Wineの開発ターゲットはLinuxだから、bashだと問題ないのか?とか、 モダンなデスクトップだと勝手に設定を追加してくれるのか?などと、 考えたのですが、執筆者と、6氏 との間には、有意な差は、 ないような気がします。何かが違う「おま環」かもしれません。 まあ、私は、.wineの新規生成もしなかったですし。 もし、i386-wine(6.x以降)において、 「wine:could not load ntdll.so:(null)」 と、言われた場合(例はcsh系の場合)、 「%env WINEDLLPATH=/usr/local/lib32/wine winecfg」 としてください。
38 :FreeBSDでwimeを使っている君 :2021/11/15(月) 17:58:24.90 .net 何気なくググってたら驚きました。 259587 emulators/i386-wine{-devel}: Delete ports (was: Fails to fetch: i386-wine-devel-6.12,1.txz: Not Found) https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259587 D32322 emulators/i386-wine{-devel}: Delete ports https://reviews.freebsd.org/D32322 Alexander氏によると、通常のWineで32bit、64bitが扱えるので、 i386-wine{-devel}は、削除要請されているとのこと。 ports/emulators/wine-devel/Makefile を見ると、 「a subset of emulators/i386-wine-devel」とか書いてあって、 i386-wineの成果が吸収されるのかもしれません。 これからは「3つのパートに分かれる」そうです。 wine 32bitなWineで32bitなEXE(FreeBSD/i386) wine64 64bitなWineで64bitなEXE(FreeBSD/amd64) wow64 64bitなWineで32bitなEXE(FreeBSD/amd64) wine32 wow64が代替予定とのこと と言うことですが、現状を把握していないので、よく分かりません。
39 :FreeBSDでwimeを使っている君 :2021/11/15(月) 18:00:14.52 .net FreeBSD13.0(amd64) ※以下レス用に1byte空白連続→2byte空白 # pkg remove i386-wine-devel # pkg install wine-devel % pkg info |grep wine wine-devel-6.18,1 Microsoft Windows compatibility environment % wine <TAB> wine wineboot wineconsole winedump winegcc winepath wine64 winebuild winecpp winefile winemaker wineserver wine64.bin winecfg winedbg wineg++ winemine % wineboot /home/hoge/.i386-wine-pkg//usr/local/bin/wine doesn't exist! Try installing 32-bit Wine with /usr/local/share/wine/pkg32.sh install wine mesa-dri % /usr/local/share/wine/pkg32.sh install wine mesa-dri pkg -o ABI=FreeBSD:13:i386 -o INSTALL_AS_USER=true -o RUN_SCRIPTS=false --rootdir /home/hoge/.i386-wine-pkg install wine mesa-dri Updating FreeBSD repository catalogue... Fetching meta.conf: 100% 163 B Fetching packagesite.pkg: 100% 6 MiB pkg: Error opening the trusted directory /usr/share/keys/pkg/trusted pkg: Error loading trusted certificates Unable to update repository FreeBSD Error updating repositories! # /usr/local/share/wine/pkg32.sh install wine mesa-dri Don't run this script as root! ※rootで走らせるな、は、どこかに書いてありましたが、 一応やってみました。
40 :FreeBSDでwimeを使っている君 :2021/11/15(月) 18:01:38.52 .net 259697 emulators/wine /usr/local/share/wine/pkg32.sh upgrade: pkg: wrong architecture: … pkg: repository poudriere contains packages with wrong ABI: FreeBSD:14:amd64 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259697 >>39 に関して上記のような記事もみつけましたが、微妙に違う気もします。 つい最近の話ですし、状況が落ち着くのを待ちます。 あー、FreeBSDの現在のWine事情を解説してくれる記事はないものか。 技術評論社のWebでのFreeBSDの連載は、とうの昔に終わったし、 紙媒体でなら、なんて、とても無理な話です。
41 :6 :2021/11/15(月) 20:20:59.50 .net >>37-38 大した用途に使っていない事もありますが今のところ正常動作ですね i386-wine-develのdistfileに関しては驚きですね 確かにportsディレクトリで # make fetch しても落ちてきませんでした 取り敢えず # pkg create i386-wine-devel しておきました いつ入手不可になるかわからないので
42 :FreeBSDでwimeを使っている君 :2021/11/18(木) 00:33:21.58 .net FreshPortsを、今、見るとi386-wine-develは、 もう無くなっています。 i386-wine、wine、wine-develは、 2021/11/16 14:33:56 に更新され、 更新内容は同じ文章です。 >Emulator/i386-wine-devel. port removed. >This port and the pre-built binaries have not been updated recently. >emulators/wine-devel now supports i386 on amd64, so remove it. との事です。 wine-devel-6.21なら正常に動くんでしょうか。 Wineに関わるMaintainerとして、Alexander88207氏、 以外の方は、にわかに信用しがたいのですが。 これ、 「動くようになったから、俺の役割は終わりだ。ヨカタ」 なのか、 「チッ! じゃあ、i386-wine は、消せや!」 「distfiles も消してやる! ザマーみろ!」 なのか、このへんの雰囲気が分からないので、困惑します。 distfilesで取得できるファイルが、即、消されて、 円満別れなのか、そうでないのか、ゾワゾワします。
43 :FreeBSDでwimeを使っている君 :2021/11/19(金) 03:14:09.76 .net Wine6.21時点での、emulators/wine{-devel}/files の wow64.sh(長いものはレス用に桁折り)を見ると、 「I386_ROOT="${WINE_i386_ROOT:-$HOME/.i386-wine-pkg}"」 と、i386-wine-pkgをホームディレクトリの下に作り、 32bitなEXEは、 「exec "$I386_ROOT/$PREFIX/bin/wine" "$@"」 で起動するようです。 ※執筆者の場合は、>>39 の試行で作りかけで止まっていた。 当たり前ですが、以下の引用のように Wine64とWine32(WoW64)のバージョンは同一に保たれるようです。 「printf "wine [%s] and wine64 [%s] versions do not match!\n\n" "$WINE32_VERSION" "$WINE64_VERSION"」 「printf "Try updating 32-bit wine with\n\t%s\n" "$PREFIX/share/wine/pkg32.sh upgrade"」 まさか、i386-wine-pkgはバイナリ配布ではないでしょうね? まあ、今は、数週間レベルでの本当の過渡期ですから、 Wine32からWoW64に完全移行してから試そうかと思っています。
44 :FreeBSDでwimeを使っている君 :2021/11/19(金) 03:44:48.56 .net FreeBSD(amd64)からi386-wine{-devel}がなくなり、 FreeBSDでのWineの、WoW64移行をふまえたうえでの、 wimeについて。 現状では、64bitなatokが、FreeBSDのWine64にインストールできない (wime公式)ので、人柱の試行で発見されるなど、事態が変わらない限り、 FreeBSDのWineでは、atokは32bit版を使う事になります。 ※今度のFreeBSDでのWineの変更で、Linuxのように、64bitなatokが 使えるようになっているかもしれません。 これまでのレスの内容をふまえると、32bitなimm32.dll.soは、置き場所が 変わるという事になります。 i386-wine-pkgが、バイナリ配布かどうかは、分かりませんが、 自前でportsからmakeできるのなら、 wimeのpatchをあてた32bitなimm32.dll.soが amd64のWineで作れるのではないか、と、思います。
45 :FreeBSDでwimeを使っている君 :2021/11/19(金) 03:54:07.14 .net >>25 の追記。 FreeBSD(amd64)のi386-wine-devel(Wine6.12)では 「WOW64?=0」「WOW64?=1」どちらも、 wimeのgmakeが通りませんでした。 ~/wime-4.1.4 % gmake (略) gmake[1]: ディレクトリ '/usr/home/hoge/wime-4.1.4/lib' から出ます gmake -C so gmake[1]: ディレクトリ '/usr/home/hoge/wime-4.1.4/so' に入ります gmake[1]: *** 'wimeapi.o' に必要なターゲット 'X11/keysym.h' を make するルールがありません. 中止. gmake[1]: ディレクトリ '/usr/home/hoge/wime-4.1.4/so' から出ます gmake: *** [Makefile:12: so] エラー 2 libまではmakeできていますので、 ~ % file /home/hoge/wime-4.1.4/lib/array.o /home/hoge/wime-4.1.4/lib/array.o: ELF 64-bit LSB relocatable, x86-64, version 1 (FreeBSD), with debug_info, not stripped 64bitなオブジェクトができてます……。 32bitなライブラリを見せてmakeすれば、32bitなバイナリが できると思うのですが。
46 :FreeBSDでwimeを使っている君 :2021/11/19(金) 04:28:32.50 .net https://reviews.freebsd.org/D32322 >gerald added a comment. Mon, Nov 15, 11:15 PM >For the actual commit, I'll list you as author anyway. Alexander88207氏とgerald氏がケンカしている訳ではないようで 安心しました。 ただ、過渡期真っ最中のようで、低スキルの執筆者としては、 Wineのバージョンが、いくつか上がってこなれるまでは、 試せません。
47 :FreeBSDでwimeを使っている君 :2021/11/20(土) 08:51:38.10 .net i386-wine-develが、即、消えたのはともかく、 i386-wineは残っていたので、ある程度までは残しておくんだ、と、 思っていましたが、今、FreshPortsを見ると消えています。 https://reviews.freebsd.org/D32322 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259589 アメリカ時間だと思いますが、2021/11/19の昨日には、 i386-wine{-devel}は、なくなり、wine{-devel}へ、一本化されたようです。
48 :FreeBSDでwimeを使っている君 :2021/12/11(土) 18:41:57.36 .net 前スレの「その2」に書いた、yc.elの話で、おわびと言うか、 「その後」に、かなり遅いタイミングではあるものの、 「気づいた」という話をします。 https://mevius.5ch.net/test/read.cgi/unix/1107211157/916 emacs27.1で、yc.elを起動すると「process-kill-without-query」の エラーが出るが、twitterの「shg@shg」氏の説明と、助言により、 .emacsに以下のコードを書いて一応の解決を見たという話です。 >(defun process-kill-without-query (process &optional flag) >(set-process-query-on-exit-flag process nil)
49 :FreeBSDでwimeを使っている君 :2021/12/11(土) 18:45:16.55 .net 偶然、気づいたのですが、FreeBSDのyc.elのPorts(5.2.1_17,1)側で 修正が入っていました。 この場合、.emacs側で「のりきる」コードを書くより、yc.el側の修正の ほうが、正しい解決方法であると思います。 FreshPorts -- japanese/yc.el: Yet another Canna client for Emacs https://www.freshports.org/japanese/yc.el/ >5.2.1_17,1 >04 Dec 2020 12:41:09 >The "process-kill-without-query" function was made >obsolete in emacs 27.1 [1]. Therefore the function >should be replaced in japanese/yc.el by >"set-process-query-on-exit-flag" function. 「Submitted by: Takayuki Nakao」とのことです。 執筆者が、レスを書いたのが、2020/12/11なので、レスをした時点では、 Ports側で、すでに修正が入っていた事になります。 執筆者は、yc.elを野良で使っていたので、Portsの修正に 気づきませんでした。 まるで(Portsでの)成果がないかのようなレスを書いた事を、 Portsでの修正にかかわった皆様にお詫びします。
50 :FreeBSDでwimeを使っている君 :2021/12/11(土) 18:47:32.23 .net YC's Room http://www.ceres.dti.ne.jp/~knak/yc.html yc.elの公式は開店休業状態なので、何かあれば、自分で何とか するしかない、と思っていましたが、Ports側だけで修正が入る事が あるのですね。 yc.elの公式に反映させないとLinuxユーザが困るな、と思うのですが、 yc.elの公式はどうなっているんでしょうね。 yc.elのFreeBSDのPortsのパッチを公開すれば、 yc.elで「process-kill-without-query」で困ったLinuxユーザも 対応できると思うので、以下にURLなどを書きます。
51 :FreeBSDでwimeを使っている君 :2021/12/11(土) 19:04:18.31 .net freebsd-ports/patch-yc.el at main・freebsd/freebsd-ports・GitHub https://github.com/freebsd/freebsd-ports/blob/main/japanese/yc.el/files/patch-yc.el ※FreeBSDのPortsのPatchでは日本語コメントが読めるのですが、 githubでは、日本語コメント部分が化けています。 対照引用しようと思ったのですが、5chに書き込む際も、書き込み欄に コピペした時点で、github側の引用が妙な化けかたをしており、 対照にならないので、日本語コメント部分のみを、FreeBSDのPortsの、 /usr/ports/japanese/yc.el/files/patch-yc.el から引用します。 以下、引用行を執筆者が明示し、次行の引用部分は、引用符をつけません。 03行 @@ -393,7 +393,9 @@ OBJ を返却する。" 14行 @@ -1736,6 +1738,7 @@ OBJ を返却する。" 22〜25行 @@ -2071,7 +2074,7 @@ OBJ を返却する。" ;; 文節を指定しない場合、現在の文節が対象となる ;; 読みを取得した文節はその読みをキャッシュする ;; cut が 非nil の場合、指定文節以降の読みを削除する 引用ここまで。 今回のyc.elネタは以上となります。 wimeの周知のためageさせてください。 じゃ、夜ゴハン食べてきます。
52 :名無しさん@お腹いっぱい。 :2021/12/20(月) 11:01:54.49 .net Python2の呪いにてportsから無くなってからしばらく経つccsm、アップストリームのソースから入れてみた ちゃんと機能するもののアイコンに不満あり https://i.imgur.com/VlXs9kc.jpg
53 :名無しさん@お腹いっぱい。 :2022/02/17(木) 21:42:20.20 .net 何故かLinux板に書き込めないので質問 pcA USBメモリーからdebian11XFCELive起動 pcB ディスプレイ死亡で画面付かず(windows10起動可) この状態でdebian11からshredコマンドでpcBのハードディスクを上書きしたいのだが、 どうやってpcAからpcBに繋げればいい? LANケーブルだけでいける? 無線で繋ぐのは無理ね。
54 :名無しさん@お腹いっぱい。 :2022/02/17(木) 21:48:55.90 .net スレチは消えて、どうぞ
55 :名無しさん@お腹いっぱい。 :2022/02/17(木) 23:38:08.14 .net >>53 代行レスはここへ370 https://nova.5ch.net/test/read.cgi/operatex/1643509995/
56 :名無しさん@お腹いっぱい。 :2022/02/19(土) 15:22:01.09 .net >>53 パソコンを廃品回収に出す
57 :名無しさん@お腹いっぱい。 :2022/02/23(水) 13:18:23.97 .net 最近hyper-v環境にNetBSDを入れて遊んでいます。作法が良く分からずxdm→ctwmで日本語表示、入力を等を設定するために共有のXsessionで日本語入力デーモン起動とメニューのxtermに-ls付けて強引に.profileを読ませています。 .profileではif文でdisplayを見ています。 .xsessionがうまく動かないからですが普通はどうやるものなのでしょうか?
58 :FreeBSDでwimeを使っている君 :2022/02/24(木) 10:56:31.67 .net >>51 「22〜25行」は、「22〜25行」の 5chへの書き込み時の文字化けです。 別件。 「たしか、FreeBSDでは『正式表記』」があったはずだよなあ、と、 思っていましたが、正式表記を思い出せず、テケトーな表記を していましたが、いろいろとドキュメントを見ているうちに 思い出しました。 短縮表記の場合、「FreeBSD13.0R/amd64」という表記が 正しかったのです。 ずーっと、テケトーな表記をしていた事をお詫びします。 >>57 NetBSDのスレか、FreeBSDの質問スレ(OS抜きで共通の話題だから)で 聞いた方が早いと思う。 「余所でやってください。[unix]」、 「もう新しいのにしましょ。」が出るので 書き込みテストがてらの書き込み。 User-AgentをWindows10(Chrome98)で書き込み。
59 :FreeBSDでwimeを使っている君 :2022/02/24(木) 11:01:55.24 .net やっぱり化けるな。 >>58 は、「22全角波線25行」と書きました。
60 :名無しさん@お腹いっぱい。 :2022/02/26(土) 20:38:59.60 .net >>57 > 普通はどうやるもの 俺はこういうのをわざわざ書いた事がないな ↓ > .profileではif文でdisplayを見ています。 NetBSDスレで Xorg.*.log を交えて話題展開してみては?
61 :名無しさん@お腹いっぱい。 :2022/03/02(水) 17:52:09.73 .net 57ですが、とうとうhyperーvのFreeBSD環境でYouTubeの音声をpaprefs使ってネット接続で聴ける様になりました。これで画面サイズの変更が出来れば良いのに。
62 :名無しさん@お腹いっぱい。 :2022/03/02(水) 22:12:57.85 .net NetBSD前提の話じゃなくなってて草
63 :名無しさん@お腹いっぱい。 :2022/03/03(木) 09:41:06.53 .net いえhyperーv環境で拡張セッションを使わずにubuntu、fedora、freebsd、netbsdで何処迄同じdesktop環境を作れるか?で遊んでいるので自分の中では変わっていません。 Windows側からsshで操作できる。 sambaサーバになる。 libreofficeで日本語ドキュメントを作り、sambaで公開して、Windows側から操作も出来る。 firefoxでYoutube配信の音楽をWindows側のスピーカーで聴きく。の内ubuntuとfreebsdはクリアしたので次はnetbsdです。fedoraはlib64とか言う変な所にpulseaudioが入れられるのでpipeWireからネットワークスピーカが動くか別途調べます。
64 :FreeBSDでwimeを使っている君 :2022/03/20(日) 14:39:43.20 .net Wine上で、ちょこっと日本語入力ができれば、ありがたい時が あるよね、と思って設定をしてみたが、日本語入力ができない。 FreeBSDでも、Wine0.9系の頃から、できているようだが。 環境:FreeBSD13.0R/amd64 :i386-wine-devel-6.12,1 :ja-kinput2-3.1_13 ※「kinput2 -canna &」 :Wine上のxyzzy0.2.2.250 「~/.wine/user.reg」の「[Volatile Environment] 」の 上の行あたりに、「root」設定の場合は、以下を書き足す。 ※「[Volatile Environment] 」の下に書き足すと、 Wineの次回起動時に、消されてしまうので注意。 [Software\\Wine\\X11 Driver] "InputStyle"="root" 試行結果は次レスで。
65 :FreeBSDでwimeを使っている君 :2022/03/20(日) 14:43:21.56 .net >>64 の続き。 ・「root」の場合 Shift+Spaceでkinput2を起動すると、[あ]が出現しないものの、 kinput2の変換窓が開き、変換ができるが、漢字を確定しても、 Wine上のxyzzyには空白行のみが入る。 ・「onthespot」の場合 Shift+Spaceでkinput2を起動しても、[あ]が出現しない。 Wine上のxyzzyは、kinput2を終了するまで入力に反応しない。 ・「offthespot」の場合 Shift+Spaceでkinput2を起動しても、[あ]が出現しない。 Wine上のxyzzyには、半角空白が入力される。 ・「overthespot」の場合 Shift+Spaceでkinput2を起動すると、[あ]は出現するが、 Wine上のxyzzyは、kinput2を終了するまで入力に反応しない。 「できませんでした」という報告ですが、 解決方法をご存知の方は助言をお願いします、 というレスでした。 じゃ、お三時のオヤツ食べてきます。
66 :名無しさん@お腹いっぱい。 :2022/03/23(水) 18:45:41.26 .net >>63 ですが、fedoraでもpulseaudioを入れてpaprefsを使えばネットワークスピーカーが動きました。 これでubuntu21.10、fedora 35、FreeBSD9.2全てブラウザで「無修正」と入力してavを探し視聴出来る事が出来ました。officeツールも動くので十分使えると思います。 NetBSDはbmpまでは音が出るのですがfirefoxは音が出ません。officeツールが動くだけに残念です。 hyperーvでなければもっと簡単かもしれません。
67 :FreeBSDでwimeを使っている君 :2022/03/24(木) 19:35:10.11 .net FreeBSD13.1Rのリリースを待ってから試そう、と、思っていましたが、 リビジョンアップでも、何かと変わるだろうし、低スキルの執筆者は、 リビジョンアップの対応で、ウオーサオーしそうなので、 あらかじめ試しておこう、と、Wine関係を試行しました。 現在、FreeBSDでは、i386-wineがwineに吸収(>>38 )され、 通常の、wine、wine-develでは、WOW64対応なWineとなっています。 まず、執筆者としては、wimeの稼働も目的としていますので、 Wineにwimeのパッチをあてた32bitなimm32.dll.soを 作らないといけません。 生活環境のFreeBSD13.0R/amd64のVirtualBox6.1(注1・注2)に、 FreeBSD13.0R/i386をインストールし、その中で、portsから、 wine-devel(注3)をmakeしました。 wimeの「imm-magic-1.7.3」を「emulators/wine-devel/files」の下に 置いてmakeします。普通にmakeが通りますが、 「emulators/wine-devel/work/wine-7.2/dlls/imm32」の下には、 「imm32.dll.so」でなく、「imm32.dll」しかありません(注4)。 執筆者は、低スキルですので、「そう変わったのかな」と 「imm32.dll」を、ホスト側のFreeBSD13.0R/amd64へ ファイルコピー(注5)しました。
68 :FreeBSDでwimeを使っている君 :2022/03/24(木) 19:39:11.03 .net >>67 (注1)「chroot」や「jail」が、よくワカラナイため。 勉強しろ、なんですけどね。 (注2)makeするだけだし、コンソールだけでいいや、 だから、ディスクは8GBでじゅうぶん、と思いましたが、 Wine7.2が依存する、なぜだか古い「llvm12」のmakeが からんだこともあり、ディスクがあふれました。 10GB以上は必要かと思います。 (注3)現行のWineはWine7.4で、この試行ではWine7.2となりました。 現在、FreshPortsを見ると、昨日の03/23にWine7.4へと バージョンが上がっていました。タイミングが悪いです。 (注4)imm.cを見るとパッチの指定どおりにソースが変更されていました。 (注5)ホスト、ゲスト間で、FTPで転送しました。
69 :FreeBSDでwimeを使っている君 :2022/03/24(木) 19:44:15.81 .net 続き。 ホスト側というか、生活環境のFreeBSD13.0R/amd64では、 pkg(8)で、wine-develをインストールする事とします。 # pkg remove i386-wine-devel ※Wine6.12 # pkg install wine-devel ※Wine7.0.r2 WOW対応版 % wineboot /home/HOGE/.i386-wine-pkg//usr/local/bin/wine doesn't exist! Try installing 32-bit Wine with /usr/local/share/wine/pkg32.sh install wine-devel mesa-dri % /usr/local/share/wine/pkg32.sh install wine-devel mesa-dri ※repository catalogueを取得して、ユーザのホームディレクトリの 「.i386-wine-pkg」以下に、i386対応な、Wineのパッケージが インストールされます。サイズは2.5GBです。
70 :FreeBSDでwimeを使っている君 :2022/03/24(木) 19:49:28.39 .net 続き。 ・Wine6.x系で必要だった「setenv WINEDLLPATH /usr/local/lib32/wine」は 必要なくなっていました。 ※当時、スレで助言していただいた方、本当にありがとうございました。 ・WOW対応版のWineで「.wine」を新規生成すると「Program Files (x86)」が できていますが、新規生成をしなくても、32bitなWineで作った、 古い.wineのままで、「wine hoge.exe」とすれば、WineでEXEが起動します。 つまり、32bitなWindowsソフトウェアを再インストールする手間はいらず、 EXE起動時に、Wineは、32bitなEXEを判別してくれます。 ただし、32bitな環境で作った古い.wineのままだと、 「Program Files (x86)」がないまま、となりますので、 64bitなWindowsソフトウェアと混用する場合は、不便かもしれません。 ・使用感としては、昔のLinux板のWineスレでは、 「(Linuxでは)WOW64だと、32bitソフトウェアの起動が遅い」 などと言われていましたが、普通に速く、違和感はないです。
71 :FreeBSDでwimeを使っている君 :2022/03/24(木) 19:53:46.45 .net 続き。 さて、かんじんのwimeです。 FreeBSD13.0R/i386で作った32bitな「imm32.dll」をどこに置くか? あちこちに「imm32.dll」や「imm32.dll.so」がありますが、 /usr/ports/emulators/wine-devel/work/wine-7.2/dlls/imm32/imm32.dll のように、できあがった「imm32.dll」を、 /home/HOGE/.i386-wine-pkg/usr/local/lib/wine/i386-windows/imm32.dll として、オリジナルのimm32.dllを、wimeのパッチがあたった 「imm32.dll」と置き換えると、32bit環境でgmakeしたwimeにより、 32bitなATOKが稼働してくれました。 ※ >>14 は、このレスの内容で修正して読んでください。 pkg(8)で入れたwine-develは、7.0.r2であり、7.2でmakeしたimm32.dllへと 差し替えたことになりますが、「IMEまわりは、さほど変更がない」と、 昔のLinux板のWineスレで読みましたので、気にしません。 あいかわらず「余所でやってください」が出るので UserAgentをWindows10(Chrome98)で書き込みました。うえーん。 じゃ、夜ゴハン食べてきます。
72 :名無しさん@お腹いっぱい。 :2022/03/24(木) 20:32:15.10 .net 荒らしがウロウロしてなければサラッと教えられるんだがなあ UA
73 :FreeBSDでwimeを使っている君 :2022/03/24(木) 20:55:07.98 .net え゛!そうなの! 運用情報板でも確定した回避方法が出てないんだけど、 なんらかの方法があるのね。 他の荒らしが多そうな板で書けて(テストで書いてみた)、 すっかり静かなUNIX板で書けないのはおかしいよね。 UNIX板でも無意味にスレを保守しているのが目ざわりなので 個別に規制して欲しいくらいだわ。
74 :名無しさん@お腹いっぱい。 :2022/03/24(木) 21:39:31.16 .net 代わりと言ってはなんだがGoogleタイムラインに流れてきた記事を https://forest.watch.impress.co.jp/docs/serial/yajiuma/1397428.html Windowsのメイリオっぽささえ許せれば抜群に綺麗で読みやすい UIフォントとしてもなかなか優秀
75 :FreeBSDでwimeを使っている君 :2022/03/24(木) 22:14:01.64 .net ニュー速(嫌儲)の 「Windowsのクソフォントwww」のスレで知ったw ports化されればいいなあ、と思った。 と言っても、執筆者君は、 「font-jis-misc」と「ja-font-mona-ipa」ぐらいしか 使ってないけどさ。 フォントが少なかった時代から思うと、フォントの選択肢が 多いと得した気持ちになるよね。 「不正なPROXYを検出しました。」が出たので 嫌儲のURLを書かないでレスしてみた。 じゃ、夜のデザート食べてきます。
76 :名無しさん@お腹いっぱい。 :2022/03/25(金) 06:49:42.77 .net 夜のデザート(桃源郷)
77 :名無しさん@お腹いっぱい。 :2022/03/25(金) 07:35:18.04 .net >>73 > 無意味にスレを保守している 放置しておいても落ちやしない板で行うそれの推測 ・「書き込みで広告代稼がせてんだから他の荒らし行為は大目に見ろや」と言うつもり ・縄張りアピールのつもり ・落書きによるただの発散
78 :名無しさん@お腹いっぱい。 :2022/03/26(土) 00:25:59.27 .net https://i.imgur.com/0LrL7zP.jpg
79 :FreeBSDでwimeを使っている君 :2022/03/26(土) 18:59:56.10 .net ○FreeBSDのWineがWOW64になった状況のまとめ ・FreeBSDのWineがWOW64対応になったのはよいけれど、 64bit版と32bit版が重複して入った形になっている。 ・amd64においては、ユーザのディスクを重複で消費して ムダなような気もするが、Ports的には、64bit版と32bit版の 2種類をメンテするよりは、人的リソースの面で効率がよい。 ・なにより、i386-wineのAlexander88207氏が、関わっている という状況は、Alexander88207氏の、今までの貢献からも、 確実に動くものがコミットされている、という安心感につながる。 ・最近のことなのに、すでに憶えていないが、今までは、 wineと、i386-wineは、排他利用だったような気がする。 Windowsソフトウェアの64bit版と32bit版の混用ができるのは、 より、Windowsに近い。 まあ、SETUP.EXEは、32bitで、本体は、64bitをインストールする というソフトウェアもあるようだし。 ・しかし、Wineの32bit版は、wineboot時に、シェルスクリプトを 走らせないといけないという状況から、32bit版Wineは、 pkg(8)から入れないといけない、というキメウチのようで、 今回のように、imm32.dllにパッチを当てたい場合は、 i386でmakeしないといけない。 32bit版Wineも、amd64のPortsで自前でmakeしたものが入れられる なら、FreeBSD/amd64だけを用意すればよいのだが……。
80 :FreeBSDでwimeを使っている君 :2022/03/26(土) 19:13:29.06 .net ○Windows版ATOKまわりのまとめ ・「ATOK Passport」は、月額/年額の契約で、ネット経由でライセンスを 問い合わせるようになっている。 そして、一太郎2022同梱版ATOKも、年契約となり、 いわゆる「買い切り版」のATOKは、一太郎2021同梱版が最後となった。 一太郎スレでも、駆け込み購入で大騒ぎになったのは、当然かもしれない。 ・おそらく、wimeで、年契約版のATOKが動くとは思うが、報告がないので なんとも言えない。 >>15 の2014年版のようにヒョッコリと動かないかもしれない。 試用版(体験版)で試すという方法もあるが、過去のWineスレや wime公式や、各種ブログで、報告があったように、試用版と製品版では 挙動が違うという場合があったので、製品で試さない限り、 確実なことは言えない。 ・wimeのconf.mkには「CC32_ENV?=schroot -c dev32 --」の記述が あるので、自分でなんとかするならば、FreeBSD/amd64のchrootでも、 32bitなwimeがgmakeできるかもしれない。 ・現状、64bit版ATOKは、FreeBSDの64bit版Wineにインストールできない、 と、wimeの公式で報告されている。 また、一太郎は今でも、32bitなソフトウェアとして提供されている。 じゃ、夜ゴハン食べてきます。
81 :FreeBSDでwimeを使っている君 :2022/03/29(火) 11:52:26.72 .net このスレをふくめ、複数スレの『依頼』、ありがとうございました。 廃墟のスレで、栞となっているぶんには、板の「華」と言えない事も ないですが、目ざわりには違いないので。 微妙にURLを変えてあるので「手が込んでいるなあ」と 思ってました《くだけた表現》。 まあ、レスごとにファイルをアップしていただけ、かもしれませんが、 その労力と執念が、怖がられる結果になる、と、感じないところが、 なんとも言えませんね。 情報的な面で古びてしまったスレは、ある程度で落ちればいいのにね。 そのわりに、WXGのスレは、情報的には古びてしまい、現状を報告する 散発的なレスが続いているが、次が必要ってほどでもないし、という 感じで、いい感じだったんですが《くだけた表現》、 突然の大量書き込みで過去ログ行きになりましたし。 「そういう」人間関係や社会に生きている、と感じさせられます。
82 :名無しさん@お腹いっぱい。 :2022/03/29(火) 12:07:36.35 .net 削除依頼の目的は削除そのものだけじゃないからな
83 :名無しさん@お腹いっぱい。 :2022/03/30(水) 01:37:57.78 .net >>81 ところでwimeさん、今宵は本スレが随分賑やかな様ですが あれ何人でやり取りしてる様に見えますか? 日頃閑散としてる板なのに急に多数の人が集結するとは思いづらいんですけど
84 :名無しさん@お腹いっぱい。 :2022/03/30(水) 03:05:25.48 .net まあ3人くらいで回しているんだろうねえw 歴史を知らない人大杉
85 :名無しさん@お腹いっぱい。 :2022/03/30(水) 05:46:09.12 .net それはどうかな
86 :FreeBSDでwimeを使っている君 :2022/03/30(水) 20:21:04.22 .net >>82 ああ。なるほど。 >>83 「語れ」スレの事かな。1人 VS 3から4人かなあ。 うーん、UNIX板は、ほとんど人がいないように見えるけど、 NetHackスレ、Emacsスレ、あたりは常時活発だしなあ。 ※現在のUNIX板では、1日2レスで活発という感じ。 ※大昔、「質問」スレだかで、見たんだけど《くだけた表現》、 「2chの書き込みは水曜日から多くなる」そうだ。 考察内容(週の中だるみか?、とか)は、忘れたけど、 それは今でも、他の板でも、感じるなあ。 ただ、昔のUNIX板では、「BSD入門の心得」な、人も 多かったから、利用者の継続(年齢の持ち上がり)を 考えても、突然のレスバトルは不思議ではない、と思う。 「ああー」って感じ。 ただ、熱意というか、執着というか、が、激減したw 3スレほど、24時間ピッタリ張りついて、レスバトルで 体力を消耗して、半年ほど寝込むぐらいの勢いで やらないとだめじゃん、と思うw
87 :FreeBSDでwimeを使っている君 :2022/03/30(水) 20:28:23.22 .net そもそも、UNIX板の人って、 知識不足で、いい加減な回答をするぐらいならスルー、 それなりに興味がないとスルー、 まれに「BSD入門の心得」な感じで、熱くなる時もある、 って感じです。 たまに見かける「光る」レス、回答の「man hoge」レス、でも、 冷静感があふれているので、成熟した人 (ちゃんとした社会人と言うか)の利用が多く、 UNIX板には、それなりに人は居るが、レスのやり取りという形で 見えていないだけ、なのではないか、と思う。 それゆえに、執筆者君は、「かなりの人数の無言の閲覧者がいる」 という前提で、しかも、「そういう」人から理不尽なツッコミが 入らないように、気をつけてレスを書いています。
88 :FreeBSDでwimeを使っている君 :2022/03/30(水) 20:35:56.41 .net 盛り上げるための工作員(職業レス屋)って事は、ないと思う。 「語れ」スレでは、双方、ちゃんとUnixの知識があるし。 工作員は、「そもそも、語るべきものを持たない」から、 その職業ができるのかもしれない。 だから、「許可を受けた」レスしかできなかったり、 仕事だから、感情抜きで、レスを「貼り付ける」わけで。 よって、工作員は、専門板には来ないと思う。 マルチポストは来るけどね。 自作板では、受診を勧めたい荒らし、も、いる感じだし。 Linux板では、私怨の荒らし、っていうのもあるみたいだし。 Linux板の急激な廃墟化というか、レベルの低下には、 気づいてましたが《くだけた表現》、「おかしさ」までは 気づかず、「タコ(Linux用語)が増えたのかな」って 程度でした。 外部のまとめサイトを見ると、「そういう人」がいて、 Linux板は廃墟状態になったみたいです。 本当に1人で、Linux板を廃墟化させたとしたら、ある意味、 すごいですけど、まとめサイト側が、「そういう人」かも しれませんから、部外者は判断できかねますが。
89 :FreeBSDでwimeを使っている君 :2022/03/30(水) 20:49:57.82 .net 最近、こういうレスも書きました。 ※UNIX板ではハンドルを固定する事にしています。 なぜかって? wimeをもりあげるためです、キリッ。 まあ、他の板は、閲覧はしても、そもそも書きませんが。 書く労力がもったいないからですw いいかげんPC-98は捨てろ@UNIX https://mevius.5ch.net/test/read.cgi/unix/1036951410/642-n あ、それと、このスレの主催者ではないです。 主催者なんて、とんでもない、おこがましいです。 スレを立てて、頻繁に利用しているだけですw 他の方々、いらはい、いらはい(寄席の呼び込み感)。 あー、wimeのおかげで、WineでWindows版のATOKを使って 長文レスが快適だったなあー(棒)。 あー、wimeのおかげだわー(棒)。 執筆者君より高スキルのユーザが降臨して、助言して くれないかなあ(真剣)。
90 :名無しさん@お腹いっぱい。 :2022/03/30(水) 20:58:24.45 .net > 3スレほど、24時間ピッタリ張りついて、レスバ 特徴的な方が何人か浮かびますね ほじくって貼ったりすると荒れそうなんでやりませんが
91 :名無しさん@お腹いっぱい。 :2022/04/01(金) 17:01:15.63 .net >>88 > Linux板の急激な廃墟化 ここ1~2年の事なら自作自演が減って化けの皮が剥がれただけでしょ
92 :FreeBSDでwimeを使っている君 :2022/04/06(水) 19:51:44.71 .net □ホームディレクトリ以下に置かれるWine関連のファイル Wineの動作や、WineでのWindowsソフトウェアのインストールにより、 Wine関連のファイルがホームディレクトリ以下のあちこちに 散らばります。 もちろん、置きっぱなしでも、動作に問題はありません(注)が、 .wineを新規生成する時に、確認して消すと、気持ちよいでしょう。 一括削除するコマンド例の記事などがありますが、Wineによる命名規則が、 変わる場合がありえます(実際に微妙に命名が変わっていた)ので、 GUIなファイラーなどで、目で見て消すとよいでしょう。 執筆者による発見もありますが、おもに以下の参考文献に依っています。 参考文献 http://variedtastefinder.jp/blog/?p=1561 ※現在404。2017年に閲覧 https://wiki.archlinux.jp/index.php/Wine (注)Wineのバージョンアップのたびにインストールした フリーソフトのアイコンがインストールした回数だけ たまっていたことがある。 レスの行制限があるので、ファイル群の詳細は次レスで。
93 :FreeBSDでwimeを使っている君 :2022/04/06(水) 19:56:33.53 .net 続き。 $HOME/.wine ※本体 $HOME/Desktop/の下 ※WineでDesktopをDesktopにしている場合 $HOME/.config/menus/applications-merged/wine* $HOME/.local/share/applications/ の下 ※Wine以外も使っています $HOME/.local/share/applications/wine/ の下 $HOME/.local/share/applications/mimeinfo.cache ※キャッシュなので消せます $HOME/.local/share/desktop-directories/ の下 $HOME/.local/share/icons/hicolor/ の下 ※Wineしか使っていないような $HOME/.local/share/mime/packages/x-wine-extension* $HOME/.local/share/mime/application/x-wine-extension* $HOME/.cache/wine/wine-mono-*.msi ※Wineバージョンごとのmonoインストーラ
94 :FreeBSDでwimeを使っている君 :2022/04/06(水) 20:06:27.31 .net wine-devel(WOW64なWine7.0)で、.wineの新規生成と Windowsソフトウェアの再インストールをしました。 Wine6系からは日本語命名のファイルはUTF8扱い(注)のようですので、 「setenv LANG ja_JP.eucJP」な、運用の方は、インストール時のみ、 「ja_JP.UTF-8」にされるとよいでしょう。 一太郎は、「C:\JUST」に配置される、テンプレートデータ (入れない選択はできない)のファイル名が、半角カタカナや 全角日本語だったりして、インストーラ内でのコピー中に、 読み取れない、などのエラーが出ますが、「次へ」の連打で 乗り切ることができます。 これらのファイルは、インストール後、正常にUTF8なファイル名に なっており、コピーできずに欠落したファイルはありませんでした。 また、他のソフトウェアでも、書式ファイルや、設定ファイルなどは、 日本語ファイル名だったりしますし、インストーラでインストールした ディレクトリに「説明書.TXT」のようなファイルがあったりもしますね。 (注)Wine5系の時は、EUC-JPな日本語ファイル名が扱えました。
95 :FreeBSDでwimeを使っている君 :2022/04/06(水) 20:19:01.09 .net FreeBSD13.0Rのwine-devel(WOW64なWine7.0)でのwimeの動作 ※これは、あくまで執筆者の環境でのみ、の話です。 環境 ・FreeBSD13.0R/amd64 ・wine-devel-7.0.r2 ※WOW64対応 ・wime4.1.4 ※32bitバイナリ ・ATOK17(2004年) ※もちろん32bit ・emacs-27.2 ・ja-yc.el-5.2.1_19,1 ※FreeBSDのPortsでパッチがあたったものを野良化 (1)wimeのwimectrlが以下のエラーを出して動かない。 ld-elf32.so.1: Shared object "libX11.so.6" not found, required by "wimectrl" ATOKのプロパティが開けないので、ほんの少し不便です。 「libX11.so.6」っぽいものが、どのディレクトリに置かれているのか、 だけでも、どなたか、分かりませんでしょうか。 (2)wimeでの初回変換時、yc.elにより、入力された文節の区切りを 変更しようと、Cintrol+fすると、 Wineがエラーを出して停止、 Emacsの上の、Xクルーザは腕時計となり、killするしかなくなる。 Wineのエラーは、backtrace.txtを取ることができる。 ※backtrace.txtを見てもどこが悪いのか分かりませんが。 一度でも変換確定してしまえば、2度目の変換で、文節の区切りを 変更しても大丈夫、という不思議状態です。 じゃ、夜ゴハン食べてきます。
96 :FreeBSDでwimeを使っている君 :2022/04/07(木) 19:39:47.63 .net >>95 wimeでの初回変換時、の件に関して追記。 wimeでの初回変換時、 Cannaのフェンス(1byteのパイプ文字に囲まれた状態)内の 1度目の変換候補をさわろうとして、 ・文節区切りの変更で、Control+f ・変換自体を取りやめようとして、Control+g ・変換一覧を出そうとして、2度スペース(注)を打鍵 であっても、Wineがエラーを出して停止、それにともない、 wimeも「Canna」に接続できなくなる、ということが判明。 (注)執筆者は「.canna」で「(setq n-henkan-for-ichiran 1)」と スペースでの変換打鍵の2度目で変換一覧を出すようにしている。 今のところ、とりあえずの回避策としては、 「1度目の変換では、フェンスに囲まれた状態で確定しておく」 としている。 次のバージョンのFreeBSD、次のバージョンのWineまで我慢します。 あいかわらず、Windows10のChrome98.0のUser-Agentで書き込み。
97 :FreeBSDでwimeを使っている君 :2022/04/17(日) 04:42:00.11 .net 参考 【西川和久の不定期コラム】Chrome OS Flexと最新版Wine 7.0の組み合わせでWindowsアプリを動かしてみる - PC Watch https://pc.watch.impress.co.jp/docs/column/nishikawa/1401328.html
98 :FreeBSDでwimeを使っている君 :2022/04/17(日) 04:44:55.29 .net 今現在の、FreeBSDのpkg(8)のバイナリパッケージ(quarterly)の Wineのバージョンは、Wine7.4(wine-devel)、Wine6.0.3(wine)、 となっています。 FreeBSD13.0R/amd64での、Wine7.4では、.wineの生成のために、 「wineboot」して、 「/usr/local/share/wine/pkg32.sh install wine-devel mesa-dri」 として、32bit環境(~/.i386-wine-pkg以下に入る)を入れても、 32bit環境は、wine6.0.3を展開されます。 当然ながら、 「wine [wine-6.0.3] and wine64 [wine-7.4] versions do not match!」 と言われます。 指示通りに「/usr/local/share/wine/pkg32.sh upgrade」をして、 リポジトリが、Upgradeされても、なぜだか、やはり、wine-6.0.3が 展開される状況ですので、32bit環境が必要な方は、Wine7.4を 避けた方がよいでしょう。
99 :FreeBSDでwimeを使っている君 :2022/04/17(日) 04:49:41.65 .net Wine6.0.3(WOW64)では、普通に32bit環境が生成でき、 執筆者として懸案だった、wime+emacs+yc.el環境下での、 「変換フェンス内で何かをするとemacsが腕時計になる」状態(注)は 回避できましたが、 やはり、wimeのwimectrlで「"libX11.so.6" not found」となる状況は 変わりませんでした。 (注)>>95 >>96 「1度目はフェンスで確定をする」という運用をしていても、 時間がたっても同様のエラーが出たため、他のバージョンを 試す気になった。 >>70 あまり関係ありませんが、Wine6.x系で、 「setenv WINEDLLPATH /usr/local/lib32/wine」と、 環境変数を設定しないといけなかった過去があるのは、 「i386-wine」であるから、ということが、これらの試行で よく理解できました。 今のWOW64なWineの仕組みだと、FreeBSD/amd64インストール時に 「lib32」を入れておかなくてもよいということです。
100 :FreeBSDでwimeを使っている君 :2022/04/17(日) 04:52:56.61 .net 「ちょこっと印刷できると便利だもんね!」ということで、 田中みな実さんの美容なみに、執筆者君は、Wineでの印刷も 期待しています。 Wine7.0r2(WOW64)では、Wineで稼働するソフトウェア内から プリンタ(注1)が見えない状態(注2)でしたが、 Wine6.0.3(WOW64)では、プリンタは見えました(注3)。 (注1)CUPSでなく、昔ながらのBSDlpr(/usr/bin/lp)。 (注2)エラーメッセージは忘れましたが 「プリンタがセットアップされていない」というような内容。 (注3)実際の印刷はしていない。 やはり、執筆者君としては、ATOKのプロパティが出せない、 というのは、多少なりとも不便なので、i386-wine-devel(6.12)に 戻りました。 じゃ、田中みな実さんオススメのボディクリームを塗ってきます。
101 :名無しさん@お腹いっぱい。 :2022/04/17(日) 09:03:51.63 .net 釣れますか? , \ ,/ヽ  ̄∨ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ,/ ヽ ∧_∧ ∧∧ ,/ ヽ ( ´∀`) (゚Д゚,,),/ ヽ ( ) (| つ@ ヽ | | | ___ 〜| | ヽ (__)_) |――|. ∪∪ ヽ  ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄| ヽ /⌒\/⌒\/⌒\/⌒\|彡~゚ ゜~ ~。゜ ~ ~ ~ ~~ ~ ~~ ~ ~~ ~~ ~~ ⌒\/⌒\/⌒\/⌒\/⌒\彡 〜 〜〜 〜〜 〜〜 〜 〜
102 :FreeBSDでwimeを使っている君 :2022/04/17(日) 23:46:08.93 .net >>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
103 :名無しさん@お腹いっぱい。 :2022/04/19(火) 08:24:30.00 .net GNOME42悪くない 少なくとも近年のFreeBSDのGNOMEらしからぬ仕上がり どうせ誰も使わんのだろうが
104 :FreeBSDでwimeを使っている君 :2022/04/19(火) 20:13:20.24 .net 参考 今夜も Wine で乾杯! - 23本目@Linux https://mao.5ch.net/test/read.cgi/linux/1585198566/679 >あとWine7.0のANNOUNCEで
105 :FreeBSDでwimeを使っている君 :2022/04/19(火) 20:14:20.56 .net >>103 追っかけている方はおられるんじゃないですか。 「かけまわる子犬。」氏はKDEを追っかけているし。
106 :名無しさん@お腹いっぱい。 :2022/04/19(火) 22:01:28.34 .net FreeBSDのKDEはdiscoverでpkgが扱える様になれば言う事無し
107 :FreeBSDでwimeを使っている君 :2022/04/20(水) 22:18:07.52 .net 割り込んですいません。自己レスですが。 >>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
108 :名無しさん@お腹いっぱい。 :2022/04/21(木) 09:17:49.23 .net FreeBSDを語れスレのテンプレで興味を持って来ました このスレは主にFreeBSDでwimeを使っている君と言う方が盛り上げている感じなんですね FreeBSDではどのデスクトップ環境がおすすめですか?推している方がいるようにKDEですか?
109 :FreeBSDでwimeを使っている君 :2022/04/22(金) 18:45:25.11 .net ん? 語れスレのテンプレ?(ケンモメンぽく) えっ!やだっ!(田中みな実さんっぽく) けっこう活発なラズパイスレと一緒に関連スレになってる! 盛り上げると言うか、 「高スキルユーザさーん! 興味を持ってくださーい!」とか 「FreeBSDのWineで何かあれば、さがわ@sagawa_aki氏にも届け!」という 感じで報告しているだけで。 Linux板にはWineスレがあるんだけれど、FreeBSD特有のWineの話は、 Linuxには関係ないし、「FreeBSD限定のWineスレ」ってほどの 話題もないしね。
110 :FreeBSDでwimeを使っている君 :2022/04/22(金) 18:48:00.44 .net 「おすすめのデスクトップ環境」って、Linux板文化っぽいね。 Linuxでも有名で、FreeBSDでも、FreshPortsでコミット回数が 多くて、よく使われている感じの、しかも、FreeBSD特有の問題が あれば、回避策が見つかりやすいやつ、で、いいんじゃないかな。 PCでのUnixは、Linuxが当然の前提、って感じなので、 FreeBSDだと……、という事が起こりやすいしね。
111 :FreeBSDでwimeを使っている君 :2022/04/22(金) 18:52:06.19 .net 例のところを見ると、 「みなさん、普通にリッチなデスクトップ環境を使っているのね」 と思います。 触れないほうがいいかもしれないけれど(注)、リンクを書いておこう。 FreeBSD研究部 https://ja-jp.facebook.com/groups/freebsd.labo.japan/ (注) いいかげんPC-98は捨てろ@UNIX https://mevius.5ch.net/test/read.cgi/unix/1036951410/642-n
112 :名無しさん@お腹いっぱい。 :2022/04/22(金) 20:22:56.72 .net >>109 > FreeBSD特有のWine 5chブラウザの動作報告などして下さると面白いかも知れないですね 5chなので Windowsの専ブラの動作報告などダサイでしょうから気が向いたらと言う事で
113 :FreeBSDでwimeを使っている君 :2022/04/24(日) 18:28:56.50 .net 「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 (deleted an unsolicited ad)
114 :名無しさん@お腹いっぱい。 :2022/04/25(月) 10:51:53.84 .net ONLYOFFICEはどうですか?
115 :名無しさん@お腹いっぱい。 :2022/04/25(月) 12:12:28.86 .net オススメのウィンドウマネージャとかありますか?
116 :名無しさん@お腹いっぱい。 :2022/04/25(月) 16:35:41.14 .net >>112 13-stableでpkgのwine6を使ってjanestyle4は動いた。この書き込みはそこから。
117 :115 :2022/04/25(月) 20:07:21.24 .net >>116 確かに動いた あっさりと https://i.imgur.com/uWiXdbE.jpg それも i386-wine-devel で使ってたやつがそのまんま wime氏、116氏、ありがとう そのうち私も何らかの成果があればご報告差し上げます
118 :112と117 :2022/04/25(月) 20:09:47.40 .net >>117 自分のレス番間違えてしまった とにかく感謝してます
119 :名無しさん@お腹いっぱい。 :2022/04/26(火) 11:52:14 .net wineは使わないけどV2Cだって13-stableで動くよ。 自分はV2C-Rを使ってて最近V2C/2に移行した。
120 :名無しさん@お腹いっぱい。 :2022/04/26(火) 12:05:21 .net これ?確かディスコンになったパッケージを使うやつ https://mevius.5ch.net/test/read.cgi/unix/1632283136/79
121 :名無しさん@お腹いっぱい。 :2022/04/26(火) 12:47:16.31 .net そうそれ。 JAILで古いportsをビルドしてパッケージだけメイン環境に突っ込んだ。 スクリプトエンジンが変わってて動かんから古いエンジンを突っ込む必要があったり ちょっと手間だったけどV2C/2が快適に動いててこの書き込みしてる。
122 :名無しさん@お腹いっぱい。 :2022/04/28(木) 10:11:27.28 .net >>74 これをベースにした合成フォントがportsに来たみたいですよ FreshPorts -- japanese/font-udev-gothic: UDEV Gothic https://www.freshports.org/japanese/font-udev-gothic/
123 :FreeBSDでwimeを使っている君 :2022/04/28(木) 20:24:05.14 .net >>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/
124 :名無しさん@お腹いっぱい。 :2022/04/28(木) 20:52:12.95 .net >>123 上流リポジトリ https://github.com/yuru7/udev-gothic HackGenの作者さんの様でテキストエディタや端末エミュレータ用の等幅フォントですね ナードフォントというやつは絵文字グリフが充実したフォントらしいです
125 :名無しさん@お腹いっぱい。 :2022/04/29(金) 03:45:46.68 .net >>113 この方妙に入力システムにこだわりがあるらしいんですけどどう思いますか? https://mevius.5ch.net/test/read.cgi/win/1648180114/681 https://mevius.5ch.net/test/read.cgi/win/1648180114/683
126 :FreeBSDでwimeを使っている君 :2022/04/29(金) 22:19:21.18 .net >>124 わざわざレスすいません。 モリサワの「BIZ UD」フォントからのPorts化なのでなく、 「yuru7」氏の二次的成果物(BIZ UD+JetBrains Mono)からの Ports化なんですね。
127 :FreeBSDでwimeを使っている君 :2022/04/29(金) 22:23:29.31 .net >>125 と、言われても……、なあ。 連日の長レスの後の短レスの投稿数の多さが恐いと思います。 Windowsは、「データを持って行って」ぐらいでしか 使ったことがないので、理解できませんでした。 今でこそ、Windowsが対応しておかないといけないキーボードは、 日本語か、英語か、ぐらいの選択ですが、昔は、Windowsが対応して おくべきキーボードがたくさんありました。 101/104英語、106/109日本語、PC9801系、AX、J3100(ATコネクタ)、 FM-TOWNS、親指シフト(最近まで現役だったみたい)、かなあ。 Controlキーが、左にしかない場合もあるし、Windowsさんには歴史が あるんだから、ぐちゃぐちゃとは言えないよね。 大昔(MS-DOS時代の話かもしれない)に読んだ、ATOKのバグ出し チーム(だったかな?)の記事。 バグ出しチームは、標準のキー割り当てで変換し(当たり前ですが)、 しかも、変換結果の漢字が何番目に出るかも記憶しているため、 即、変換結果を選ぶことができ、漢字変換が正確で速いのは良いが、 学習機能を使わない状態(無意識に学習機能を使わないようにしていた) だったため、学習機能の向上の役に立たない、ということに気づいた、 という話。
128 :FreeBSDでwimeを使っている君 :2022/04/29(金) 22:28:44.94 .net >>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」には戻れません。
129 :名無しさん@お腹いっぱい。 :2022/04/30(土) 16:58:54.71 .net >>74 参考画像 定番Takao https://i.imgur.com/t7lUV7Q.png BIZ UD https://i.imgur.com/mtaDaHV.png
130 :名無しさん@お腹いっぱい。 :2022/05/01(日) 02:28:56.20 .net >>127 もしご本人が読んだらどんな反応があるか目に浮かぶ様なご回答ですな
131 :FreeBSDでwimeを使っている君 :2022/05/01(日) 22:57:53.03 .net >>130 恐いのは恐いんですが、悪口ではないんですよ。 ただ、キー割り当てやソフトウェアの挙動には、人間側として 不満があったとしても、よかれと思って考えられた設計思想や、 俗に語られる、タイプライターの配列の話などの、 いまさら変えられない歴史があるし、あえて、人間側が標準状態に 合わせるのも考え方として「ある」という話です。 ATOKのバグ出しチームの話も、「へえ、変換学習をさせなければ 変換先の順番が変わらないのだから、変換作業が速くなるね」と 感心したので、憶えていたのだと思います。 ATOKのスレで、ATOKの新規インストールをしたので、 「これから(自分流の入力をして)辞書を鍛える」というレスが 並んでいた中に、「短文でなく、長文で変換をしたら、文脈に 応じた変換結果になりやすいのに」というレスを見てからは、 執筆者も、文脈を読み取りやすい長さのタイミングで 変換するようになりました。そのレスには感謝しています。
132 :FreeBSDでwimeを使っている君 :2022/05/01(日) 23:00:08.42 .net そのスレで言及があった「窓使いの憂鬱」は知っていましたが、 共同使用のPCには入れられないし(共同使用相手がUnix系とは 限らない)、「窓使いの憂鬱」を入れられる環境なら、 Emacsな人なら、xyzzyを入れて「メモ帳」代わりに使っても よいだろうし、Windowsのダイアログ入力のコピペなどの すべてまでも、を、Unixっぽくするのも、どうなのか、 Windowsにおいて、「絶対にマウスを使たくないでござる」は、 難しいだろうな、人間には慣れる能力もあるのに、と、 思ったことがあります。 『UNIXという考え方−その設計思想と哲学』を読んで、 マウス操作もアリ(操作は、なるべく楽をしろ)なのだな、と、 考えを改めた執筆者君でしたー(きょうのわんこ風)。
133 :名無しさん@お腹いっぱい。 :2022/05/02(月) 10:00:39.94 .net ありきたりな環境で人並みに過ごすのか、楽をする為に人並み外れた途方も無い時間と労力を費やすのか まさに人それぞれと言う話でござるな
134 :名無しさん@お腹いっぱい。 :2022/05/02(月) 12:23:55.75 .net まあどっちかというとWindowsならマウス無しのオペレーションも無くはないんだけどね。
135 :名無しさん@お腹いっぱい。 :2022/05/03(火) 02:13:54.53 .net > BSD/LinuxでのOffice/Desktop環境を語れ! Part03
136 :名無しさん@お腹いっぱい。 :2022/05/03(火) 06:07:53.55 .net ちんちんシュッ!シュッ!シュッ!
137 :名無しさん@お腹いっぱい。 :2022/05/03(火) 08:38:34.79 .net お題にはちんちんなんか生えて無いが
138 :名無しさん@お腹いっぱい。 :2022/05/06(金) 01:20:47.43 .net GhostBSDのデザイン割と好きなんですが OpenRCに馴染めないのでパーツだけ拝借してそれっぽくしてみました https://i.imgur.com/HmjeR0v.jpg
139 :FreeBSDでwimeを使っている君 :2022/05/08(日) 00:39:11.24 .net みなさん、フツーにリッチなデスクトップ環境を使っているのね。 計算機資源は、makeやコンパイルに振り向けるべきだよ、 それなら自作PCも安価で済むしね、という貧乏性な執筆者です。 大昔、初めてWindow Managerの仮想デスクトップを使った時は、 「わー、すげー」とか言って、いくつかの窓を仮想デスクトップへ 移動させたが、存在を忘れてシャットダウン。 仮想デスクトップマネージャみたいなものがあっても、 「見えていない物は忘れてしまう」という事に気づいて、 そもそも、仮想デスクトップは使わなくなった。 XのWindow Managerは、ソフトウェアを位置指定(-geometry)して 起動ができるので、「わー、すげー」とか言って、 「Emacsはこの位置で」などと、設定に夢中になったが、 同じソフトウェアを複数起動すると、ピッタリと同じ位置に 起動するので、先に起動していたのを忘れてしまう、という事で、 位置指定もやめた。ダメダメじゃん。 といっても、タイル型のWindow Managerへ行くほどでもないです。
140 :名無しさん@お腹いっぱい。 :2022/05/08(日) 07:22:02.21 .net > ※執筆者はC言語もMakefileも理解していない
141 :FreeBSDでwimeを使っている君 :2022/05/09(月) 22:51:06.79 .net >>140 あははー。 執筆者のスキルを明示するためにサラッと書いたんですが。 前スレにwimeネタを初めて書いた時点で書きましたが、 執筆者は、C言語も、Makefileも、理解していません。 いちおう、見るには見ますが、修正する能力はありません。 ケアレスミス程度なら修正しますが。 さらに言えば、シェルスクリプトも、こみいったものだと、 追いきれず、途中で迷子になります。 wimeや、Wineに対して、*BSD業界の高スキルユーザさんに 興味を持ってほしい、というのは、それが理由なんです。 「FreeBSDでは、動かないんですが」 「さあ? Linuxでは普通に動いてるし」 「え゛え゛!」 って、ありそうでしょ。
142 :名無しさん@お腹いっぱい。 :2022/05/12(木) 07:23:45.98 .net https://livedoor.blogimg.jp/akira2016/imgs/4/e/4e7cc039.jpg
143 :FreeBSDでwimeを使っている :2022/06/01(水) 23:33:10.45 .net 執筆者しか、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 (deleted an unsolicited ad)
144 :名無しさん@お腹いっぱい。 :2022/06/05(日) 04:35:01.14 .net FreeBSDの使い手でケンモメンねえ まさかとは思うが可能性はゼロじゃねえ
145 :名無しさん@お腹いっぱい。 :2022/06/19(日) 11:19:27.74 .net LINEはwineで動くんかな? (他力本願)
146 :名無しさん@お腹いっぱい。 :2022/06/21(火) 01:05:51 .net vncやxrdpで入ろうとするとconsolekit-daemonがエラー吐きながら1分から2分くらい待たせやがるんだが何事かわかる?
147 :名無しさん@お腹いっぱい。 :2022/06/21(火) 06:49:29.05 .net なぜその吐いたエラーを貼らんのか?
148 :名無しさん@お腹いっぱい。 :2022/06/21(火) 07:33:32.12 .net 例えばこんなの console-kit-daemon[7641]: WARNING: Error waiting for native console 9 activation: Inappropriate ioctl for device > なぜその吐いたエラーを貼らんのか? 寝起きで思い出した様に書いたから
149 :名無しさん@お腹いっぱい。 :2022/06/21(火) 08:57:19.40 .net あと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が吐いたタイムアウトエラーの後に一応繋がりはするんだけどさ
150 :146 :2022/06/22(水) 01:08:18.49 .net 結局手直しは諦め新規インストール用データセットへinstallworld、設定複製、 chrootして各種パッケージ入れて再起動し一応解決 リフレッシュ出来たと思う事にしました
151 :名無しさん@お腹いっぱい。 :2022/06/22(水) 14:20:58.00 .net Desktop環境の話なのか?
152 :名無しさん@お腹いっぱい。 :2022/06/22(水) 15:35:56.93 .net デスクトップ環境にリモートアクセスし操作する為のプログラム そんなこと言い出したらwineの話もアウツでは
153 :名無しさん@お腹いっぱい。 :2022/06/29(水) 16:31:07.07 .net amd64、i386共に wine-devel-7.8 6.0では起動しなかったbecky2が起動 https://i.imgur.com/4lfNo2n.jpg 互換性が良くなってきている模様
154 :名無しさん@お腹いっぱい。 :2022/07/01(金) 06:33:31.92 .net おお~Becky!動くんだね~(^_^)
155 :名無しさん@お腹いっぱい。 :2022/07/02(土) 15:54:11.47 .net winnyとかFLMASKはwineで動くのかな? 当時?はFLMASKのためだけに、vmwareを入れたりしてたけど
156 :名無しさん@お腹いっぱい。 :2022/07/02(土) 17:58:32.96 .net https://www.winehq.org/search?q=winny https://www.winehq.org/search?q=FLMASK
157 :名無しさん@お腹いっぱい。 :2022/07/05(火) 21:43:23 .net 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 この辺を野良ビルドで入れるのオススメ
158 :名無しさん@お腹いっぱい。 :2022/07/07(木) 02:59:54.89 .net github使うのヤメレ、ってニュースがあったな
159 :名無しさん@お腹いっぱい。 :2022/07/07(木) 09:08:34.60 .net これのことか GitHubの利用をやめるようオープンソースソフトウェア非営利団体が強く呼びかけ - GIGAZINE https://gigazine.net/news/20220704-software-freedom-conservancy-give-up-github/ ギガジンを鵜呑みにしてしまう人っているのか
160 :名無しさん@お腹いっぱい。 :2022/07/07(木) 23:09:55 .net Software Freedom Conservancyがどんな団体なのか の方がgigazine云々より重要じゃないか?
161 :名無しさん@お腹いっぱい。 :2022/07/08(金) 09:45:59.63 .net 余所でやってください。
162 :FreeBSDでwimeを使っている君 :2022/08/03(水) 22:10:45.53 .net >>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で動作するという報告は見あたりませんが。 日本語利用者がこのデータベースを参考にする可能性は、 比較的に低いと思われますが、誤解を生む登録だなあ、 と思います。 日本語を常用利用していない方が登録したのかなあ。
163 :FreeBSDでwimeを使っている君 :2022/08/03(水) 22:19:31.21 .net すでに、ずいぶん前から使っている方からすれば、いまさらでしょうが、 Emacs28.1で、文書中の全角空白(2byte空白)が赤のアンダーバーで 表示されるようになりました。 まあ、昔から設定によって全角空白などを表示させることはできましたが、 四角い形状で表示されたりして、執筆者的にはイマイチ感があり、 アンダーバー表示の控えめ感は、ありがたいと感じています。 ただ、Emacsのエコー領域に表示されるCannaの変換候補でも表示されます。 ※emacs-cannaで、canna.elを使用。 不思議なことに、全角漢字の候補のうしろにも表示されています。 漢字は全角なので、まあ、おかしくはないけれど、意味がない、と 思うのですが……、ああーっ!分かったー! 変換候補の一単語ごとの区切りの空白に全角空白を使用しているので、 それに反応して赤のアンダーバーが表示されているんだ!
164 :FreeBSDでwimeを使っている君 :2022/08/03(水) 22:31:33.19 .net (ヽ´ん`) それぼく ごぶさたしております。 ニュー速(嫌儲)のキャラクターがカワイイので、つい見に行って しまう執筆者君です。 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を試してみます。
165 :FreeBSDでwimeを使っている君 :2022/08/03(水) 22:38:16.29 .net 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」を入れておきました。 〔次に続く〕
166 :FreeBSDでwimeを使っている君 :2022/08/03(水) 22:52:27.66 .net 〔前からの続き〕 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 とのメッセージが出ます。
167 :FreeBSDでwimeを使っている君 :2022/08/03(水) 22:58:38.04 .net 執筆者は、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 結果:状況変わらず。 〔次に続く〕
168 :FreeBSDでwimeを使っている君 :2022/08/03(水) 23:09:41.27 .net 〔前からの続き〕 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」にしていなかったからかなあ? 、ぐらいです。 こんな風に変わっているよ、という助言などがあれば、 よろしくお願いします。 じゃ、お夜食、食べてきます。
169 :名無しさん@お腹いっぱい。 :2022/08/03(水) 23:45:22.27 .net 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 はインストールしていたのか
170 :名無しさん@お腹いっぱい。 :2022/08/03(水) 23:50:56.79 .net あと 13.0 から 13.1 にアップグレードしたのなら -kmod は ports で make し直す必要があるかと
171 :FreeBSDでwimeを使っている君 :2022/08/04(木) 00:55:00.22 .net あわわ。即レス驚きました。ありがとうございます。 >>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」も 試しましたが状況は変わりませんでした。
172 :名無しさん@お腹いっぱい。 :2022/08/04(木) 08:30:07.58 .net そもそもこれだけ熱心にレポート書いてる人が あんなしょうもない釣りやるとも思えんよね ここの嫌儲民はどちらかと言えばあの
173 :名無しさん@お腹いっぱい。 :2022/08/04(木) 11:44:50 .net >>171 > ・xorg.confに「Driver "modesetting"」 modesetting じゃなくて "amdgpu" ではどうなるの?
174 :名無しさん@お腹いっぱい。 :2022/08/04(木) 12:05:37 .net >>171 まだ 13.0 のサポート期間なので pkg は 13.0 で make されてる >>165 のリンク先にも書いてある > カーネルメッセージの、rc.confの評価あたりで、画面出力がなくなる。 -kmod は pkg じゃなく ports からインストールするように
175 :FreeBSDでwimeを使っている君 :2022/08/05(金) 00:52:11.29 .net ん? 何か嫌疑が、かかってます? 古くさい釣りAAが貼られていたのも、それがらみですか? 世の中、ヒマ人が多いんですね。 嫌儲板には書いたことはありません。閲覧のみです。 そんなことよりも、wimeを、以下略。 執筆者は、UNIX板では「FreeBSDでwimeを使っている君」で 書き込みをしています。※他の板では書いていません。 仮に、初歩的な質問をする場合で、通りすがりのフリを したくても、即バレてしまう文体なので、恥を忍んで固定名に するつもりです。 Linux板に書く場合も、これからは同様にするつもりです。 それもこれも、すべてwimeの宣伝のためです。 なぜ宣伝するかというと、wimeを、以下略。
176 :FreeBSDでwimeを使っている君 :2022/08/05(金) 00:56:09.74 .net さらに書き忘れていた。 執筆者が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 [終了] ファイルの差し替え処理のようです。
177 :FreeBSDでwimeを使っている君 :2022/08/05(金) 01:02:54.85 .net 日本語入力メソッド総合スレッド@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を追加のこと、と。
178 :FreeBSDでwimeを使っている君 :2022/08/05(金) 01:05:31.18 .net >>174 >まだ 13.0 のサポート期間なので pkg は 13.0 で make されてる そういうものとは、まったく知りませんでした。 今までカーネルモジュールを使うソフトウェアは、あまり使っておらず、 意識していませんでした。 >>>165 のリンク先にも書いてある まことにすいませんでした。 英語なもので、さらっと読み飛ばして、ポイントっぽいところだけを 読んでいました。 >>173 CUIのコンソールの出力がなくなり、CUIのloginまでいけない状態なので、 xorg.confの評価までは、いけていないのです。
179 :FreeBSDでwimeを使っている君 :2022/08/05(金) 01:15:10.58 .net 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秒くらいかかっていたので。
180 :名無しさん@お腹いっぱい。 :2022/08/05(金) 01:25:20.23 .net http://mevius.5ch.net/test/read.cgi/unix/1632283136/152-153 出力先が切り替わってるとかはないか
181 :名無しさん@お腹いっぱい。 :2022/08/05(金) 06:52:41.45 .net うろ覚えだがgpu firmwareみたいな名前のpkgもportsで作り直しが必要だったような。
182 :名無しさん@お腹いっぱい。 :2022/08/05(金) 13:09:12.38 .net 本当にその程度のレベルの人かと言う話でもある
183 :名無しさん@お腹いっぱい。 :2022/08/05(金) 13:34:41.24 .net 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とは違うはずだから
184 :名無しさん@お腹いっぱい。 :2022/08/05(金) 15:31:16.04 .net Athlon Athlon5350なのにgpu-firmware-amd-kmod をインストールしているのが間違い 必要なのはgpu-firmware-radeon-kmodの方 分からないのならMeta ports の gpu-firmware-kmod あと -kmod なのだから pkg ではなく ports から試すように(特にトラブってる時には)
185 :名無しさん@お腹いっぱい。 :2022/08/05(金) 15:35:38.52 .net amdなんて使ってないけどwikipedia見て調べてみた 180 書いたの俺だけどこれは関係無かったか
186 :名無しさん@お腹いっぱい。 :2022/08/05(金) 16:13:19 .net wine 等とまるで関係ないんだがCinnamonが割とまともにつかえる 足りないと思ったものは適宜追加しながらお好きな人はどうぞ ただし画面ロックとシステム情報おまえらはまだダメか ヤらねばヤられる
187 :FreeBSDでwimeを使っている君 :2022/08/06(土) 00:53:08.52 .net >>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にしても、構築する個人や、 コミュニティの好みで構築されているので、長短がありますから。
188 :FreeBSDでwimeを使っている君 :2022/08/06(土) 00:59:17.91 .net >>180 >>185 それ、サーバなマザーボードでの構成でしょ。 おそらく、後載せのRadeonR7は、「ダミーが刺さって」とのことから、 ビデオ出力に使わずに、演算に使っているのではないか、と感じました。 執筆者君の環境の場合、VGAを複数認識するような高価な環境ではなく、 ビデオカードをさすと、APU側のビデオ機能は無効になるマザーボードが ある、という、ローエンド環境に、ありがちな環境です。 もちろん、この試行中でも、いちいちビデオカードを外しながら 試していました。 おかげで、アルミ筐体の拡張スロットのネジがゆるくなってきました。
189 :FreeBSDでwimeを使っている君 :2022/08/06(土) 01:02:30.02 .net >>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
190 :FreeBSDでwimeを使っている君 :2022/08/06(土) 01:16:46.45 .net なんだか、入門者の犬小屋スレみたいになっていますが、 みなさん、ありがとうございます。 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」もね! (田中みな実さんぽくキリッとキメ顔)
191 :名無しさん@お腹いっぱい。 :2022/08/06(土) 01:29:59.85 .net >>189 Linuxの場合と同様64/32bit使用可な環境作って32bitアプリインスコすると ~/.wine/drive_c/Program Files (x86) ディレクトリが出来るのでどうなんでしょうねえ (emulators/i386-wine(含-devel)の頃には起こらなかった挙動)
192 :名無しさん@お腹いっぱい。 :2022/08/06(土) 17:28:29.19 .net >>182 その程度のレベルだったな
193 :FreeBSDでwimeを使っている君 :2022/08/06(土) 23:59:32 .net >>182 >>192 執筆者が「その程度のレベル」なのは、 前スレ当時から自己紹介しております。キリッ。 自分でKernelをReConfigureした場合、Ports由来のKernelModuleを 再makeしないといけない、というのは知っていましたが、 「まだ 13.0 のサポート期間なので pkg は 13.0 で make されてる」、 というのは知りませんでしたし、さらに、標準のKernelで「.1」の差が 問題になる、というのも認識していませんでした。 この後に「その程度のレベル」な、謝罪のレスがあります。
194 :FreeBSDでwimeを使っている君 :2022/08/07(日) 00:00:32 .net >>191 執筆者の試行では、32bit環境の.wineのまま(新規生成していない)で、 WOW64なWineで32bitなソフトウェアが動きました。 WOW64のWineでwinebootで.wineを新規生成すると、「Program Files (x86)」が できていました。
195 :FreeBSDでwimeを使っている君 :2022/08/07(日) 00:01:51 .net まずは、おわびです(ガバッ、土下座)。 お散歩がてら「さがわ@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 (deleted an unsolicited ad)
196 :FreeBSDでwimeを使っている君 :2022/08/07(日) 00:04:36 .net で、前スレ951氏助言の 「setenv WINEDLLPATH /usr/local/lib32/wine」との設定をコメントし、 /etc/fstabに「proc /proc procfs rw 0 0」と、設定をして、 winecfgを起動すると、普通にwinecfgが起動しました。 執筆者が、procをマウントしていれば、騒ぐ必要がなかったミスとなります。 前スレの951氏にはWineのソースを調べ、助言レスをさせる、という手間を かけさせて、まことに申し訳ありませんでした。 Linux板のWineスレでも質問をして、申し訳ありませんでした 執筆者の不注意なミスにより、心配した方々に迷惑をかけて、 本当に申し訳ありませんでした。
197 :FreeBSDでwimeを使っている君 :2022/08/07(日) 00:16:44 .net あれれ? >>195 のWineのエラーメッセージ引用のかぎカッコ中に 「 h t t p : / / 」とありますが、執筆者は書いておりません。 投稿時に自動的についたものと思われます。
198 :名無しさん@お腹いっぱい。 :2022/08/07(日) 00:54:25.07 .net >>196 インストールのメッセージくらい読めというところだが 貴方が前スレの992に貼ったFreeBSD Forumsでも そのエラーの回避法としてprocのことが書いてある
199 :名無しさん@お腹いっぱい。 :2022/08/07(日) 03:52:07.25 .net >>193 そうか ならばもう大体把握した
200 :名無しさん@お腹いっぱい。 :2022/08/07(日) 07:49:48.49 .net >>195 当時のリンク先のサイトのレスが書き込まれた日付をよーく見ると良いよ。 ついでにそれがportsに反映された時期も。 四ヶ月後に再度見に行くか?ったらまあしないだろうし そもそも当時の作業者が初耳!してるくらいだから。 あとprocマウントしてても多分そのエラーは当時は出てたと思う。 なんでかっつーと自分のマシンは最初からfdescfsとprocfsはmount済みなんで。
201 :FreeBSDでwimeを使っている君 :2022/08/07(日) 22:03:53.46 .net >>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.」 と書かれました。(注) 〔次に続く〕
202 :FreeBSDでwimeを使っている君 :2022/08/07(日) 22:05:49.33 .net 〔前からの続き〕 前スレ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を閲覧して 検証することができないのですが。 〔次に続く〕
203 :FreeBSDでwimeを使っている君 :2022/08/07(日) 22:07:33.37 .net 〔前からの続き〕 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」をマウント することはなかっただろう、と、思うからです。 試した報告をする方々、助言をくださる方々に感謝します。 〔終了〕
204 :名無しさん@お腹いっぱい。 :2022/08/08(月) 04:07:14.04 .net >>202 > もう今は、i386-wineのPortsTreeがないので、FreshPortsを閲覧して > 検証することができないのですが。 パッケージを保存しておいた実機で各種検証する人の書く事とも思えんが
205 :名無しさん@お腹いっぱい。 :2022/08/08(月) 04:41:56.49 .net 何でfreshportsなのかという疑問はあるが https://cgit.freebsd.org/ports/log/emulators/i386-wine https://cgit.freebsd.org/ports/tree/emulators/i386-wine?id=99af2239fc168cc980f622c3f98b6ab21af873aa
206 :FreeBSDでwimeを使っている君 :2022/08/08(月) 20:52:30.49 .net >>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のパッチがあたるかは、執筆者は未検証。 と、書きましたが、この迂遠な手抜き手法は、そうするしかなかった、と、 いうことになります。
207 :FreeBSDでwimeを使っている君 :2022/08/08(月) 20:59:38.99 .net 「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
208 :名無しさん@お腹いっぱい。 :2022/08/08(月) 21:02:31.20 .net >>206 それが Forum とかでの freebsd の ports は multilib をサポートしてないから という発言につながるわけですな
209 :FreeBSDでwimeを使っている君 :2022/08/08(月) 21:04:50.29 .net この件について、執筆者自身も、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の現状を 試さないといけないな。時間ができたら試します。
210 :FreeBSDでwimeを使っている君 :2022/08/08(月) 21:16:23.56 .net >>208 あ、連続レス中にはさんでしまった。 >multilib をサポートしてないからという発言に ああ。そういう意味、そういうこと、だったのか。 なんの話だろう、特殊なライブラリ? とか思っていました。 すいません、forumsの内容も、英語のため、精読していませんでした。
211 :6 :2022/08/08(月) 21:21:25.71 .net そう言えばprocfsはふつうにマウントしてましたねえ と言うか sysutils/desktop-installer でDE入れると勝手に設定されるので
212 :FreeBSDでwimeを使っている君 :2022/08/15(月) 00:08:53.38 .net >>211 ああ、やっぱり。 「wine: could not load」の件は、まさに「おま環」(お前の環境特有) だった、ということでした。大騒ぎしてすいませんでした。 fstabの見直しで、procfsの設定に追加して、tmpfsに128MBを設定したという、 あつものに懲りてなますを吹くかのような執筆者君です。 あと、i386-wineが出てきた直後ぐらいに、2chで、i386-wineが待てない人用、 として手作業の方法をレスしていた方が、Portsはユーザが、makeしてinstall することができないので、i386-wine的なものに対応しづらい、と 読んだことがあったような気がする。 ※技評のWebの後藤大地氏のFreeBSDの記事で読んだのかもしれない。 Linuxもバイナリ配布が主で、ports的な仕組みからバイナリを作って いるんだろうけど、どうしているのかなあ。
213 :FreeBSDでwimeを使っている君 :2022/08/15(月) 00:10:31.92 .net 手順の再まとめをする時用にアンカーを打っておこう。 >>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を選択する。 という結果になりました。
214 :FreeBSDでwimeを使っている君 :2022/08/15(月) 00:13:36.79 .net >>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
215 :FreeBSDでwimeを使っている君 :2022/08/15(月) 00:17:44.71 .net 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
216 :FreeBSDでwimeを使っている君 :2022/08/15(月) 00:21:48.92 .net 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されたものが提供されることになるでしょう。
217 :FreeBSDでwimeを使っている君 :2022/08/15(月) 00:47:38.25 .net 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は違いました。
218 :FreeBSDでwimeを使っている君 :2022/08/15(月) 00:48:58.62 .net 再まとめ用: 「wimeのパッチはリネームも編集もせずにそのまま置けばよい」>>11 「Wine7系からはパッチを当てても、imm.c.origとリネームされた オリジナルのソースファイルは残らなくなった」
219 :FreeBSDでwimeを使っている君 :2022/08/15(月) 00:51:39.18 .net 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氏は、どう思っているのだろう。
220 :名無しさん@お腹いっぱい。 :2022/08/15(月) 00:56:56.20 .net >>219 そこは /usr/local/share/wine/pkg32.sh install wine-devel mesa-dri だろ
221 :FreeBSDでwimeを使っている君 :2022/08/15(月) 00:57:11.65 .net >>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 の環境下では、今のところ出ていません。
222 :FreeBSDでwimeを使っている君 :2022/08/15(月) 01:03:40.90 .net >>219 >>220 あ゛! あ゛! あ゛! 間違っていた! そりゃあ、そうですよね! pkgのメッセージをそのままコピペしただけなんですけどね! いや、言い訳にはならないな! 間違ってました! すいませんでした!
223 :FreeBSDでwimeを使っている君 :2022/08/15(月) 01:12:12.96 .net 執筆者としては、 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公式と同じ結果。
224 :名無しさん@お腹いっぱい。 :2022/08/15(月) 01:19:28.89 .net 知らないかもしれないので書いとくが amd64でi386-wineはビルドできる https://wiki.freebsd.org/i386-Wine
225 :FreeBSDでwimeを使っている君 :2022/08/15(月) 01:29:49.96 .net >>224 その記事は、昔から知っていたんですが、 ほぼ、理解できていませんでした。 今は、うっすら理解できます。
226 :FreeBSDでwimeを使っている君 :2022/08/15(月) 01:32:26.53 .net 今のところ、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!」と言われているな。なぜだろう。 じゃ、夜食を食べてきます。
227 :FreeBSDでwimeを使っている君 :2022/08/16(火) 00:44:57.40 .net >>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
228 :FreeBSDでwimeを使っている君 :2022/08/16(火) 01:07:40.43 .net >>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を持ってきて、 展開してもいいのではないかと思う。
229 :名無しさん@お腹いっぱい。 :2022/08/16(火) 08:22:02.20 .net スキル云々以前に先ずサラの環境で試してみろよ
230 :名無しさん@お腹いっぱい。 :[ここ壊れてます] .net スクショも見たい
231 :FreeBSDでwimeを使っている君 :2022/08/18(木) 01:53:45.55 .net やだぁ。こういうこと? しようがないわね(意味深)。 環境: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
232 :名無しさん@お腹いっぱい。 :2022/08/18(木) 03:38:54.54 .net そう言うズレた事やるなら今後俺が何かを手助けする事は無い
233 :名無しさん@お腹いっぱい。 :2022/08/18(木) 03:54:40.58 .net 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 「パッケージのファイル名」 でインストールしてみたらどうなるの
234 :名無しさん@お腹いっぱい。 :2022/08/18(木) 06:09:46.95 .net だけど libX11 は mesa-dri の依存関係でインストールされる筈だよな
235 :名無しさん@お腹いっぱい。 :2022/08/18(木) 08:38:14.19 .net > versions do not match! もし、パッケージマネージャに複数のリポジトリを登録してるなら pkg32.shを呼ぶときにリポジトリを指定しないと混ざって不整合起こす可能性があるよ。 こっちの環境でそれ喰らって少し悩んだけど結局pkgを呼んでるわけだからオプション付けるだけ。 wine-devel 7.8.1でjanestyleの通信回りが動かなかった悲しみ。
236 :名無しさん@お腹いっぱい。 :2022/08/18(木) 12:17:46.80 .net >>227 これでいいんか? https://i.imgur.com/gobPqEo.jpg >>231 ここまでの流れをざっと見てみると何がしたいのかサッパリわからんな おまかん自慢?
237 :名無しさん@お腹いっぱい。 :2022/08/18(木) 12:31:47.24 .net ちゃんと読まないからwineじゃなくてwine-develの事だと分からないんだろ
238 :名無しさん@お腹いっぱい。 :2022/08/18(木) 12:46:11.29 .net ちゃんと読めば「既存パッケージで32bitアプリも64bitアプリも同時に動かせるのに何故過去の遺産に拘っているのか」 と首を傾げているって事では
239 :名無しさん@お腹いっぱい。 :2022/08/18(木) 12:54:05.82 .net それは消えた i386-wine-devel のほうが今の wine よりバージョンが上だからでは そして wine-devel(7系?)では imm32.dll.so が無くなったせいなのか wime が動かないと
240 :名無しさん@お腹いっぱい。 :2022/08/18(木) 13:06:55.34 .net バージョンが上とかじゃないな wimeの作成環境に書いてあるのがwineのstableじゃなくて開発版だから wine-develなのか
241 :名無しさん@お腹いっぱい。 :2022/08/18(木) 13:16:54.17 .net 検証不可能だが要はこれが望む環境で使えんライブラリであると https://i.imgur.com/JtkfBpN.png 何をゴチャゴチャビルドだのdevelだの書いていると思ったわ /procがどうのこうのだの切り分けが半端だったんだから先ずは不満な人が 既存パッケージで作れる環境でいちから試せば少しでも前進するんじゃね
242 :名無しさん@お腹いっぱい。 :2022/08/18(木) 13:25:16.41 .net パッチ当てが必要とか書いてるみたいだけど必要ならソースあるよ https://github.com/wine-mirror/wine/tree/oldstable/dlls/imm32
243 :名無しさん@お腹いっぱい。 :2022/08/18(木) 13:30:26.82 .net >wine-devel(7系?)では imm32.dll.so が無くなったせいなのか https://github.com/wine-mirror/wine/tree/master/dlls/imm32
244 :名無しさん@お腹いっぱい。 :2022/08/18(木) 13:39:59.71 .net imm32.dll.so と書いてるのはwime君であってwimeの作者じゃないけどな 作者は imm.c にパッチをあてろと書いてるだけ >>242 wine-devel でも imm.c はある というか>>217-218 見るとパッチがあたって無い wine-devel/files に置くんじゃなくて make patch の後手作業でファイルを変更してみたら
245 :名無しさん@お腹いっぱい。 :2022/08/18(木) 13:54:20.83 .net ソース置き場まとめ wime君がつかってるやつ https://github.com/wine-mirror/wine/tree/wine-6.14/dlls/imm32 現行pkgのやつ(wine-6.0.4) https://github.com/wine-mirror/wine/tree/oldstable/dlls/imm32 quarterlyのwine-develのやつ(wine-devel-7.8) https://github.com/wine-mirror/wine/tree/wine-7.8/dlls/imm32
246 :名無しさん@お腹いっぱい。 :2022/08/18(木) 14:04:24.57 .net ソースが無いって話はしてないぞ imm32.dll.so が無くなった でも imm32.dll.so なんて言ってるのはwime君で作者じゃない linux でも7系では imm32.dll.so は無いようだ
247 :名無しさん@お腹いっぱい。 :2022/08/18(木) 14:14:21.91 .net つまり氏のコレは早とちりか何かと 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のパッチをあてるのは、そもそも無理だった、 ということになります
248 :名無しさん@お腹いっぱい。 :2022/08/18(木) 14:24:36.64 .net >imm32.dll.so あるよ latestの wine-devel-7.14,1 i386のパッケージを展開し確認 quarterly の7.8に同梱されているかはしらん
249 :248 :2022/08/18(木) 14:26:16.81 .net >>248 あ、微妙に違ってた imm32.dll はあるが imm32.dll.so というファイルは無い
250 :248 :2022/08/18(木) 14:29:49.29 .net >>249 >imm32.dll マジックナンバー文字列は「MZ」
251 :名無しさん@お腹いっぱい。 :2022/08/18(木) 14:36:24.10 .net 作者が書いてるのは 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 にも無い
252 :名無しさん@お腹いっぱい。 :2022/08/18(木) 15:05:31.79 .net > 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でもつかってんのかな
253 :名無しさん@お腹いっぱい。 :2022/08/18(木) 15:15:11.74 .net > 現在pkgに存在しないバージョンの様だが更新していないportsでもつかってんのかな コピペミス wine-devel-7.14,1.pkg
254 :名無しさん@お腹いっぱい。 :2022/08/18(木) 15:22:14.31 .net こちらもelfじゃないみたいだけど https://i.imgur.com/TnxdLCD.png
255 :名無しさん@お腹いっぱい。 :2022/08/18(木) 15:37:35.04 .net >>231 twm愛好家なんだ よかったらあっちのスレも盛り上げてよ
256 :名無しさん@お腹いっぱい。 :2022/08/18(木) 16:48:03.06 .net 13.1-RELEASE-p1 quarterly いつの間にか sysutils/fusefs-smbnetfs がふつうに使える様になっとる クライアントマシンとしてSMB2以降を使いたい人にはオススメ
257 :名無しさん@お腹いっぱい。 :2022/08/18(木) 23:05:18.33 .net 時代はarmやで
258 :FreeBSDでwimeを使っている君 :2022/08/19(金) 02:13:23.86 .net >>232 ん? よく意味が分からないです……。 悪いところがあれば直します。 助言者が欲しくて書いているようなものですから。 >>255 「あっち」?
259 :FreeBSDでwimeを使っている君 :2022/08/19(金) 02:14:57.99 .net あらやだ、すごいことになってるわ、困ったわね(意味深)。 画像のチカラってすごいのかな(意味深)。 ※こんなボケを書く雰囲気ではないんですけれど一応。
260 :FreeBSDでwimeを使っている君 :2022/08/19(金) 02:29:34.04 .net 個別にレスできませんが、誤解を解きたいです。 >>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 でも勧めましたし。
261 :FreeBSDでwimeを使っている君 :2022/08/19(金) 02:32:34.73 .net >>217 の試行では、wine-devel(7.14)がPortsのVersion でしたので、pkg(8)も、一時的に、latestにしました。 >>244 >imm32.dll.so と書いてるのはwime君であって その通りで、imm32.dll.soとか、imm32.dllとか、 のことを書いているのは執筆者本人のみです。 「wime」ではパッチをあてろとしか言っていません。
262 :FreeBSDでwimeを使っている君 :2022/08/19(金) 02:34:20.13 .net >>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 ※アンカーをつけすぎると書き込めないので細切れになります。 〔次に続く〕
263 :FreeBSDでwimeを使っている君 :2022/08/19(金) 02:38:08.60 .net 〔前からの続き〕 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系以降、 「分離作業が行われているから」か、と思います。
264 :FreeBSDでwimeを使っている君 :2022/08/19(金) 02:41:19.31 .net >>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対応版)に持ってきました (少しぐらいのバージョン違いは気にしません)。 〔次に続く〕
265 :FreeBSDでwimeを使っている君 :2022/08/19(金) 02:43:01.87 .net 〔前からの続き〕 その結果が、>>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
266 :FreeBSDでwimeを使っている君 :2022/08/19(金) 02:44:48.25 .net >>233 >>235 >/usr/local/share/wine/pkg32.sh add 「パッケージのファイル名」 i386で作ったパッケージを「/home/ユーザ名/.i386-wine-pkg」 として持って来られるとは思っていませんでした。
267 :名無しさん@お腹いっぱい。 :2022/08/19(金) 02:46:02.99 .net >>263 pkg がビルドされているのは13.0R、13.1Rとはコンパイラのバージョンが違うので md5が違うのは当然
268 :名無しさん@お腹いっぱい。 :2022/08/19(金) 06:07:56.91 .net これは面白くなってきたぞ 乞うご期待
269 :FreeBSDでwimeを使っている君 :2022/08/20(土) 02:35:35.89 .net >>262 では、肝心なことを書き忘れていました。 ホームディレクトリ以下に展開される32bit環境では、 Wine7.14では、「lib/wine/fakedlls」しかなく、 「lib/wine/i386-windows」はなくなっています。 しかし、Wine7.14をi386でmakeすると、 「i386-windows」は存在します。 >>267 ああ、そうなのか。知りませんでした。 パッチをあてて、オリジナルファイルを残さないのは おかしいですから、なんとなくですが、 そもそも、パッチがあたっていない可能性があります。
270 :名無しさん@お腹いっぱい。 :2022/08/20(土) 07:58:43.18 .net いつまで続くのかじっくり見物させて頂くとしよう
271 :FreeBSDでwimeを使っている君 :2022/08/21(日) 16:27:53.43 .net 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が ホームディレクトリ以下に入りました。
272 :FreeBSDでwimeを使っている君 :2022/08/21(日) 16:29:31.54 .net (注)基本に戻るのは大事だと痛感しました。 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 再まとめの際は注意。
273 :FreeBSDでwimeを使っている君 :2022/08/21(日) 16:34:31.21 .net 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」でした。
274 :名無しさん@お腹いっぱい。 :2022/08/21(日) 16:37:52.95 .net >>273 wime-4.1.5/io/Makefile の ifneq "$(OS)" "Linux" override LDFLAGS:=$(subst local/lib,local/lib32,$(LDFLAGS)) endif を消してみたらどうなる?
275 :FreeBSDでwimeを使っている君 :2022/08/21(日) 16:38:20.35 .net 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 ※桁折り済み
276 :FreeBSDでwimeを使っている君 :2022/08/21(日) 16:39:52.87 .net では、と、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に戻ってきました。
277 :FreeBSDでwimeを使っている君 :2022/08/21(日) 17:31:04.04 .net >>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 と同じ結果となりました。
278 :名無しさん@お腹いっぱい。 :2022/08/21(日) 17:38:46.26 .net 32bit の libX11.so.6 があるディレクトリを ldconfig -32 で追加したら
279 :名無しさん@お腹いっぱい。 :2022/08/21(日) 17:40:48.50 .net https://github.com/chriswells0/freebsd-scripts ここの portsfetch で quarterly の ports tree が取得できる wine-devel も 7.8,1
280 :FreeBSDでwimeを使っている君 :2022/08/21(日) 18:39:40.17 .net ○漢字変換はできるが、「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 〔次に続く〕
281 :FreeBSDでwimeを使っている君 :2022/08/21(日) 18:42:15.76 .net 〔前からの続き〕 >>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系をやってみます。
282 :FreeBSDでwimeを使っている君 :2022/08/21(日) 19:02:35.01 .net 書き忘れていました。 >>269 で、 >ホームディレクトリ以下に展開される32bit環境では、 >Wine7.14では、「lib/wine/fakedlls」しかなく、 >「lib/wine/i386-windows」はなくなっています。 と書きましたが、 Wine6.0.4でも「lib/wine/fakedlls」しかありませんでした。 執筆者は、安直に「imm32.dll.so」や「imm32.dll」の ファイルだけを持って来ていましたが、 「パッケージで持ってくればよい」という知見が、 このスレで与えられました。 みなさんありがとうございました。
283 :名無しさん@お腹いっぱい。 :[ここ壊れてます] .net 辛抱した代わりと言ってはなんだがよかったらtwmスレもちょいちょい書いてくれると嬉しい
284 :FreeBSDでwimeを使っている君 :[ここ壊れてます] .net twmというか、ctwmだから、おじゃま虫だなあ。 執筆者君は、ctwm特有のカスタマイズはしないようにして、 すぐにtwmに切り替えられるような.ctwmを書いています。 twmのスレ、見てはいますが、特に書くネタはないなあ。 Windows3.1や、FreeBSDのAfterStep1.4からの慣れで、 「ウインドウを消すバツ(Xのロゴ)が最右端でないと、 使いにくいな」と、思ったことがあり、バツを最右端に する設定を、ググり中に見つけたが、バツを最右端にすると リサイズボタンが使いにくくなるのに気づいて、最右端は リサイズボタンなのだなあ、と、思ったことがあります。 よくあるウインドウのように隅っこでリサイズできると いいんだけど、窓枠が太くなるしなあ。 まあ、気をつけておきます。
285 :FreeBSDでwimeを使っている君 :2022/08/21(日) 20:33:20.83 .net それで思い出したけど、最近のGNOME系かな、 ユーザーサイド側の窓の装飾ってどうなの、と思う。 Window Manager を考えなくてもよいので、 管理の負担が減るとか、アプリケーション内の入れ子で 表示しやすい、というのが、あるのかもしれないけれど、 X Window Systemの考え方からは、逆行しているように思う。 もし、ユーザーサイド側の窓の装飾を、流行などで、 コロコロと変えられたら、ユーザ側からは地獄でしょ。 それに、そういう事をすると、逆に古びると思う。 「スマホ風のUIだって、プギャー」って時代も来るだろうし。
286 :名無しさん@お腹いっぱい。 :2022/08/22(月) 04:36:00.32 .net >>281 使ってないから知らなかったが net/gitup 見たら gitup.conf.sample に quarterly の設定もあるな ports の更新もこれ使えばいいんじゃね
287 :名無しさん@お腹いっぱい。 :[ここ壊れてます] .net portsfetch でも更新できるから どちらでもいいが
288 :FreeBSDでwimeを使っている君 :2022/08/23(火) 23:04:25.61 .net 「portsfetch」の、ご紹介ありがとうございました。 ありがたいShellScriptですね。 VirtualBox6.1.36内のFreeBSD13.1R/i386で、portsfetchを 動かしたところ、動作中にリブートがかかりました。 portsfetch内から追加パッケージをインストールしたまま 動かしていたからなのか、負荷がかかりすぎたのか、は 不明です。 ですが、リブート後、再度、portsfetch したら (何かを取得し直しになりましたが)、PortsTreeが quarterlyになりました。
289 :FreeBSDでwimeを使っている君 :2022/08/23(火) 23:06:53.01 .net さて、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 〔次に続く〕
290 :FreeBSDでwimeを使っている君 :2022/08/23(火) 23:08:37.37 .net 〔前からの続き〕 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の設定通りに見えて、 印刷できました。
291 :FreeBSDでwimeを使っている君 :2022/08/23(火) 23:10:33.94 .net 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での設定も、ちゃんと載っていますし。
292 :名無しさん@お腹いっぱい。 :2022/08/24(水) 11:18:10.74 .net 素直に pkg32.sh で cups インストールして設定すればいいと思うが
293 :名無しさん@お腹いっぱい。 :[ここ壊れてます] .net wime君育成ゲームスレっぽくなってきた
294 :FreeBSDでwimeを使っている君 :2022/09/12(月) 00:30:56.15 .net □いまさらながら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の存在に困って、この入れ替え設定をしている人は、 それなりにおられると思います。
295 :FreeBSDでwimeを使っている君 :2022/09/12(月) 00:33:06.72 .net □いまさらながら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ファイルを指定します。
296 :FreeBSDでwimeを使っている君 :2022/09/12(月) 00:34:36.18 .net □いまさらながら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/
297 :FreeBSDでwimeを使っている君 :2022/09/12(月) 00:37:22.88 .net □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」をインストールしました。
298 :FreeBSDでwimeを使っている君 :2022/09/12(月) 00:38:48.85 .net □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でも、印刷できて 偉いなあ、と思います。 じゃ、お夜食を食べてきます。
299 :名無しさん@お腹いっぱい。 :2022/12/29(木) 07:50:25.01 .net Wineなんか使わん
300 :FreeBSDでwimeを使っている君 :2023/01/08(日) 22:04:08.77 .net 備忘録。 タイミングで該当バージョンに当たった人がいるかもしれませんが firefox-105は避けた方がよいようです。 Firefox-ESRが105固定になりませんように。 https://mevius.5ch.net/test/read.cgi/unix/1632283136/154-171
301 :名無しさん@お腹いっぱい。 :2023/01/09(月) 00:42:11.77 .net Firefoxは常に最新使ってるが105の時も落ちた事はないな なおESRになるバージョンは決まってる https://wiki.mozilla.org/Release_Management/Calendar
302 :FreeBSDでwimeを使っている君 :2023/01/10(火) 00:59:24.05 .net あ、やっぱり、1つだけの報告の場合、 判断は保留したほうがいいのか。 つい、飛びついちゃうな。 ReleaseCalendarは知りませんでした。 ありがとうございました。
303 :FreeBSDでwimeを使っている君 :2023/01/29(日) 19:02:48.86 .net 少し前に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の先頭部分をカットしています。
304 :FreeBSDでwimeを使っている君 :2023/01/29(日) 19:06:11.69 .net >>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が実装された
305 :FreeBSDでwimeを使っている君 :2023/03/25(土) 20:50:29.09 .net さがわ@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です。
306 :FreeBSDでwimeを使っている君 :2023/06/16(金) 01:29:38.84 .net 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なんですが。
307 :FreeBSDでwimeを使っている君 :2023/06/16(金) 01:33:51.20 .net 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に更新されている。
308 :FreeBSDでwimeを使っている君 :2023/07/16(日) 03:00:04.25 .net 前スレッドを事実上の占有状態で消費した事による贖罪の意味で、 執筆者は、次スレッドとして、このスレッドを作成しました。 別にスレッドのヌシというわけではありません。 5ch(2ch)専用ブラウザ分裂がらみの「talk」掲示板のUNIX板には、 このスレッドと同名のスレッド(>>1 のみがある状態)が存在しますが、 執筆者が関与したものではありません。 >>1 のみが、コピーされた形でのスレッドのようです。 「出典」という形で、このスレッドのURLが表記されてはいますが、 著作権的にはどうなんでしょうね。 「出典」には、あたらないように思います。以上です。
309 :名無しさん@お腹いっぱい。 :2023/08/17(木) 03:17:42.46 .net 32bitWineは少なくとも15、16では動くだろうけど先のことは分からない 15.0が出るとまた方針が変わるかもしれないよと https://cgit.freebsd.org/src/commit/RELNOTES?id=da51a1211dc799fa123f5d7f041eaf83c36f976b 今の流れ的には32bitに関して考慮する必要があるのは主にarmとWineについてで i386自体はもういいだろって感じ
310 :名無しさん@お腹いっぱい。 :2023/08/17(木) 09:01:39.67 .net 14.0では32bitカーネルは非推奨で15.0で削除される可能性があると警告が出るようになった でも最終決定はまだ
311 :名無しさん@お腹いっぱい。 :2023/08/18(金) 16:44:15.23 .net 15.0ではサポートされるのはCOMPAT_FREEBSD32とlib32で ネイティブな32bitプラットフォームは非推奨ということですな そしてstable/14は一週間遅れ
312 :FreeBSDでwimeを使っている君 :2023/08/21(月) 01:17:59.70 .net 妙なスレ立てがあるようなので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版としてフォークする動きがあるとおもしろいんですが、 ないでしょうね。
313 :FreeBSDでwimeを使っている君 :2023/08/21(月) 01:21:00.60 .net それで、Wineの場合です。 Wineの場合、Windows業界に蓄積された膨大なソフトウェア資産を Unix系でも使いたい、というのが、もともとの趣旨でもあります。 そういうエロゲがあるかどうかは知りませんが、32bit版Windows向けの、 他機種に移植されていない特定バージョンのゲームがしたい、 などの要望は、性癖に関わりそうな話ですので、 Wineに対して、きわめて強い要望がありそうです。 ですが、>>303 に「さがわ@sagawa_aki」氏の引用をしましたが、 Wine8.0以降ならば、将来的に問題とは、ならなさそうです。
314 :FreeBSDでwimeを使っている君 :2023/08/21(月) 01:24:26.03 .net 未来の話ですが、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化すらできないので、修正する能力は、 当然ながらありません。キリッ!
315 :FreeBSDでwimeを使っている君 :2023/08/22(火) 23:08:33.74 .net FreeBSDでwimeを使っている君は、タイミングが悪いです。 i386wineの時も、書いた直後に新情報(統合する)を見つけ、 追加のレスをした記憶があります。 Wine公式のWineHQによると、以下の通りで、安定版と開発版の 両方とも、メジャーバージョンは8系に上がっています。 まあ、それが普通ですね。 Stable : Wine 8.0.2 Development : Wine 8.14
316 :FreeBSDでwimeを使っている君 :2023/08/22(火) 23:10:21.39 .net 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
317 :FreeBSDでwimeを使っている君 :2023/08/22(火) 23:15:20.91 .net 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.
318 :名無しさん@お腹いっぱい。 :2023/08/23(水) 06:59:19.96 .net PORTREVISIONを増やすのは元のバージョンは変わってないけど ports/pkgに変更があったので再インストールさせたい時
319 :FreeBSDでwimeを使っている君 :2023/08/24(木) 22:45:24.61 .net >>318 知りませんでした。非常に勉強になりました。 「PORTREVSION」そのものも、まったく理解していませんでした。 「_1」「_1,1」は、単純なmakeのやり直しや、リンクされる物などの バージョンが上がった場合、だと思っていました。 「Bump」は、1段階引き上げる、という意味か。 単純翻訳の語意イメージと合致します。 質問スレ125の209に書きましたが、その分野を理解していないと 単純翻訳だけではダメだ、という例ですね。
320 :FreeBSDでwimeを使っている君 :2023/08/24(木) 22:55:21.73 .net ググって、以下を知りました。 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に単純な日付をつけるのは、 数値の大小問題が出るかもしれないので避けたほうがよいの ですね。
321 :FreeBSDでwimeを使っている君 :2023/08/24(木) 22:58:43.51 .net 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」を待とう、と、判断する事も、 できるのですね。 勉強になりました。ありがとうございました。
322 :名無しさん@お腹いっぱい。 :2023/08/25(金) 09:51:45.80 .net PORTREVISIONとPORTEPOCHがごっちゃになってる PORTEPOCHが増やされるのは単純に数値的に比較すると バージョンの大小が判断できない時 Wineを例にすると20050930から0.9にバージョンアップした時 https://cgit.freebsd.org/ports/commit/emulators/wine/Makefile?id=943fc1582ce5f4bf7b55a853f4205bdfcc433080
323 :FreeBSDでwimeを使っている君 :2023/08/26(土) 22:33:55.79 .net あー、かなり混同しています。 指摘されるまで気づきませんでした。 引用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
324 :FreeBSDでwimeを使っている君 :2023/08/26(土) 22:36:21.55 .net と、いう事は、ある時点で、PORTEPOCH=1がついた場合、 ずっと「0.3,1」のように後のバージョンにも最初から 「,1」がつき続ける、と。 なぜ、Wineに最初から「,1」がついているかと言うと、 20050930から0.9になった時に「,1」がついたから、と いう事ですね。 pintaに「,1」がついていないのも、PORTEPOCHを設定する 状況がなかったから、という事ですね。 PORTVERSIONに日付をつけてもいいが、 後に日付ではないバージョンが出た場合や、 移植元ソフトウェアのバージョンのつけ間違いなどが あった場合(引用URLでの例)、数値大小問題が発生するので PORTEPOCHをつけてね、という事ですね。 混乱したまま、書いていました。 すっきりしました。ありがとうございました。 >>320 の後半と>>321 は間違いです。
325 :名無しさん@お腹いっぱい。 :2023/10/06(金) 05:00:59.57 .net ネイティブのchromiumからlinux版のwidevineが利用できるようになりました まだ細かい不具合があるようですがいずれlinux版のchromiumなどを使わ なくてもNetflixなどのDRMで保護された動画を見れるようになるでしょう
326 :FreeBSDでwimeを使っている君 :2023/10/09(月) 03:17:16.02 .net 執筆者自身、FreeBSD上では、DRMで悩む事はないのですが、 こういう動きがあるたびに「あー、FreeBSDでよかったなあ」と 思います。 今では、FreeBSDって、なんだか、日本国内より、海外のほうが、 動くというか、若いというか、パワフル感がありますね。 Linuxより動きが遅くても、うれしいものです。 FreeBSD15.0-CURRENTでもi386版(非推奨ではありますが >>311 )が あります。よかったです。 32bit機に入れるわけではないのですが、i386版上でwimeをgmakeする という目的がありますので、ないと困ります。 たったこれだけのために、仮想環境でFreeBSD/i386を、というのも どうなのよ、なのですが。 これ、wimeをamd64版上で、COMPAT_FREEBSD32と、lib32を利用して 32bitバイナリとして、コンパイルする方法はないものですかね。
327 :FreeBSDでwimeを使っている君 :2023/10/09(月) 03:22:03.57 .net どうも。レスを書いて、寝かせてから投稿をする執筆者君です。 サーバ自体は動いており、該当サーバ上の他の板は開けるのに ブラウザでUNIX板トップを開くと、真っ白だったので、 復旧を忘れ去られていたらどうしよう、と思っていましたが、 まだ、やや、重いものの、UNIX板、稼働するようになりました。 「したらば」と、「おーぷん」に、UNIX板が「あるにはある」のを 発見しましたが、業者宣伝で埋まっていたり、過疎で荒れて タンブルウィードが転がっていそうな、開設した管理者ですら 忘却の彼方っぽい所(「したらば」は板ごとの開設管理者だったか、 と思います)へ移住するのもどうか、と思いましたし、 執筆者自身で開設するのも、管理業務が発生してしまううえ、 移住する住人感情の面でも「君が管理者カヨー」となりますので、 「どうなのよ」、と思いました。 ※「t*l*.jp」掲示板のUNIX板は廃止され、スレは「パソコン一般」に 移動したようです。 その掲示板の「語れ」スレに、そちら側でレスがついていなければ、 こちらからコピーしたUNIX板由来のスレが、キレイに消えていたのに、 と思います。
328 :FreeBSDでwimeを使っている君 :2023/10/09(月) 03:32:27.83 .net UNIX板で、すでにある古いスレのタイトルと、1をコピーして、 スレたてをする動きがありますね。 スレタイを不完全にコピーしたものや、文章中にhtmlっぽいものが 入っているのを見ると、作業は「機械」でしょうね。 「意志」は人間だろう、と思いますが。 古いスレに他愛ない内容の上げレスなどをつける動きもありますね。 もう、ネタが古びているし、転用もしづらいスレタイなんだから、 上げなくてもいいでしょうに。ヒマ人(婉曲表現)はいるものですね。 必要もないのにスレッドタイトルを微妙に変えたり、必要もないのに 個人感情由来のサブタイトルを、つけ足したりして、スレ立てするのも どうかと思いますし、一気に埋め立ててしまうのも、とても、とても、 どうかと思います。 「(CM声で)おカネは大事だよぉー。でも、スレタイ的にも、FreeBSDの 動きの最新情報は、もっと大事だよぉー」なので、落ち着くまで、 このスレで、FreeBSDを語ったり、質問をしても、よいのではないか、と 思います。 「(アニメ声で)こんな事もあろうかと」、 1の内容に「などの整備」「手段は問わない」を、入れておきました。 つーか、「公式を見ろ」ではあるものの、執筆者君は、情報弱者なので、 リリース情報などは知りたいですし。 じゃ、お夜食を食べるとします。
329 :FreeBSDでwimeを使っている君 :2023/10/09(月) 05:10:06.04 .net がーん。「語れ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の動きを注視する事にします。
330 :FreeBSDでwimeを使っている君 :2023/10/29(日) 00:58:35.68 .net 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
331 :FreeBSDでwimeを使っている君 :2023/10/30(月) 00:50:29.29 .net 「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連投しようとしたのですが、書き込めなかった (書き込み成功は出るが、書き込みができていない)ので 日にちをおいて投稿しました。
332 :FreeBSDでwimeを使っている君 :2023/10/30(月) 00:58:10.81 .net 今の書き込みも1回目は吸われ、文面を見直して2回目を投稿すると Rock54でした。NGワードがありました。 「製品『しょうかい』の記事は」(『』内は漢字) の2漢字単語がダメだったようです。犯罪誘因対策ですかね。
333 :FreeBSDでwimeを使っている君 :2023/12/12(火) 01:15:07.42 .net 気になる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
334 :名無しさん@お腹いっぱい。 :2024/01/03(水) 01:43:09.25 .net 以前は毎月更新されていたpopplerが23.05以降止まっていますが もう更新されそうです https://bugs.freebsd.org/bugzilla/showdependencytree.cgi?id=275555&hide_resolved=1
335 :FreeBSDでwimeを使っている君 :2024/01/07(日) 22:51:45.75 .net 最近の環境のemacsでの「anthy.el」で、anthyのON/OFFのトグルが うまく動作しない件。助言により、anthy.elの修正にて解決済み。 (語れ058)https://mevius.5ch.net/test/read.cgi/c/unix/1696777979/120-n
336 :名無しさん@お腹いっぱい。 :2024/01/08(月) 05:32:00.33 .net 元コアでメンテナだった佐藤さんが japanese/kterm を復活させました
337 :FreeBSDでwimeを使っている君 :2024/01/08(月) 19:27:40.93 .net >>336 おおっ! うれしい! ありがたい! ボランティア、頭が下がります。 ずいぶん昔から、標準の xterm で、日本語が通るように なりましたが、このフォントで、などと設定をしたくても、 イマイチ感がありました。 今どきは、各デスクトップ環境の物のみならず、 多くの仮想端末が存在するけれど、やっぱり、 日本語を扱う昔からの仮想端末の標準物として kterm が 存在しないとダメではないか、と思っていました。 FreshPorts >Last Update: 2024-01-07 17:30:34 >Resurrect kterm-6.2.0 復活してホッヤホヤ。
338 :名無しさん@お腹いっぱい。 :2024/02/11(日) 18:27:49.14 .net ktermのman見てたらutf-8と書いてあって gitのログ見たら2013年にUTF-8のサポートが追加されてた 知らなかった
339 :名無しさん@お腹いっぱい。 :2024/03/21(木) 10:21:00.58 .net https://www.freebsd.org/releases/14.1R/schedule/ 6/18 リリース予定 リリースエンジニアリングのリーダーが変わって前倒ししたようだ
340 :名無しさん@お腹いっぱい。 :2024/03/27(水) 20:04:34.42 .net ( ゚ ⊇ ゚)チャーラ〜ヘッチャラ〜 ちょっとユルい感じになっている層が薄いだけやん
341 :名無しさん@お腹いっぱい。 :2024/03/27(水) 20:10:37.46 .net 過去の犯罪者は騙されやすいから効果覿面 国葬は「ある」との違いかもだが 真っ向勝負の雑談配信を
342 :名無しさん@お腹いっぱい。 :2024/03/27(水) 20:13:51.35 .net そりゃ老人たち
343 :名無しさん@お腹いっぱい。 :2024/03/27(水) 20:50:02.03 .net 今の仕事が許されるわけないの アクアリウムはやってないとかあるはずがないよね イェール中退しなかったら本物ってことか。
344 :名無しさん@お腹いっぱい。 :2024/03/27(水) 21:25:36.65 .net 嵌め込み酷い それが出来やすくなるらしいから詰まりどころがないって? 視聴率取れないし客席ガラガラになるじゃん? ワイヤレスゲート空売りゴチ
345 :FreeBSDでwimeを使っている君 :2024/05/01(水) 01:54:02.44 .net UNIX板にも、スレ立て荒らし、スクリプトらしき 書き込みの埋め立て荒らしは、一気という感じでなく、 チビチビと来ていますね。 現在、このスレの順位は418です。 100ほどスレ立て荒らしをされるとdat落ちする可能性が 高い、と感じました。 「スレが落ちたら立てればいいや」と思っていましたが、 スレ立ての労力(たいしたものではありませんが)や、 立てたい時に、システム変更で立てにくくなっているかも しれない、と、考え、何かを書いて、ageておいたほうが いいのでは、と思いました。 いま思えば、日本語入力ネタなら、UNIX板には、 「IMEなんとかしろ」のスレがあったのですが、 次スレが期待されるスレタイとは言い難いですしね。 執筆者的には、wimeや日本語入力、デスクトップ環境や、 Wineについて、飽きたわけではありません。 wimeネタは、執筆者が新規に試した場合、試用報告を するつもりでいます。書かずにはいられないですから。 まだ、古い環境を使っているので…。すいません。 いま見た、語れスレによると、6月には14.1Rとの事です。 うーん、執筆者的には、なんとも中途半端だお…。 じゃ、お夜食を食べてきます。
346 :名無しさん@お腹いっぱい。 :2024/05/01(水) 12:12:37.92 .net 荒らし前はスレ順位が700くらいならまだ残ってたくらいだった 何度かスレを消してるんだろうけど抜本的な規制や対策する気がなさそう
204 KB
新着レスの表示
掲示板に戻る
全部
前100
次100
最新50
read.cgi ver 2014.07.20.01.SC 2014/07/20 D ★
本文 スレッドタイトル 投稿者