BSD/LinuxでのOffice/Desktop環境を語れ！　Part03

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 の助言と経験のおかげで書くのですが、
新バージョン公開から３か月で、旧バージョンは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のプロパティを表示しながら、漢字変換はできないので、
２枚になりました。
いま気づきましたが、二重敬語の補正の指摘が、左上に出ますが、
表示されるだけなので、指示通りのキー打鍵をしても、
自動的に補正されません。表示されるだけです。
確定などの、次の動作をすると、指摘は消えてくれます。
※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系の時に、
まったく動かなかったことが、２度あっただけで、
数日後に即、修正版が出ましたから、
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の場合、
Ｃ言語は読めませんが、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からの慣れで、
「ウインドウを消すバツ（Ｘのロゴ）が最右端でないと、
使いにくいな」と、思ったことがあり、バツを最右端に
する設定を、ググり中に見つけたが、バツを最右端にすると
リサイズボタンが使いにくくなるのに気づいて、最右端は
リサイズボタンなのだなあ、と、思ったことがあります。

よくあるウインドウのように隅っこでリサイズできると
いいんだけど、窓枠が太くなるしなあ。

まあ、気をつけておきます。

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は、７系から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

５．５ プリンタの設定 | あらかると
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

あ、やっぱり、１つだけの報告の場合、
判断は保留したほうがいいのか。
つい、飛びついちゃうな。
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を、
たばねた（注１）ような状態（注２）であるのは、
Wineの開発方向を把握した上で、将来的に対応しやすいように
配慮してあるのかもしれません。

「/usr/local/share/wine/pkg32.sh install wine mesa-dri」として、
pkg(8)の指示による、ユーザ実行のShellScriptで、
32bit版のWineを、ユーザのホームディレクトリに
インストールしなくてもよくなる方向か、と思います。

注１：別々に存在する物を同時に使えるようにしてある。
注２：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が修正される可能性も、あるかと思われます。

（備考１）
大昔の事で、どこで読んだか忘れましたが、
既知情報として、MicrosoftOffice付属などのMicrosoftIMEは、
Wine環境下にInstallできない（エラー停止）、とされています。

（備考２）
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によると、以下の通りで、安定版と開発版の
両方とも、メジャーバージョンは８系に上がっています。
まあ、それが普通ですね。

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」は、１段階引き上げる、という意味か。
単純翻訳の語意イメージと合致します。

質問スレ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板で、すでにある古いスレのタイトルと、１をコピーして、
スレたてをする動きがありますね。
スレタイを不完全にコピーしたものや、文章中にhtmlっぽいものが
入っているのを見ると、作業は「機械」でしょうね。
「意志」は人間だろう、と思いますが。

古いスレに他愛ない内容の上げレスなどをつける動きもありますね。
もう、ネタが古びているし、転用もしづらいスレタイなんだから、
上げなくてもいいでしょうに。ヒマ人（婉曲表現）はいるものですね。

必要もないのにスレッドタイトルを微妙に変えたり、必要もないのに
個人感情由来のサブタイトルを、つけ足したりして、スレ立てするのも
どうかと思いますし、一気に埋め立ててしまうのも、とても、とても、
どうかと思います。

「（CM声で）おカネは大事だよぉー。でも、スレタイ的にも、FreeBSDの
動きの最新情報は、もっと大事だよぉー」なので、落ち着くまで、
このスレで、FreeBSDを語ったり、質問をしても、よいのではないか、と
思います。
「（アニメ声で）こんな事もあろうかと」、
１の内容に「などの整備」「手段は問わない」を、入れておきました。

つーか、「公式を見ろ」ではあるものの、執筆者君は、情報弱者なので、
リリース情報などは知りたいですし。

じゃ、お夜食を食べるとします。

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/

あらら、今って、こういう時代だったんですね。知りませんでした。

※前回の書き込み時に２連投しようとしたのですが、書き込めなかった
　（書き込み成功は出るが、書き込みができていない）ので
　日にちをおいて投稿しました。

332 ：FreeBSDでwimeを使っている君：2023/10/30(月) 00:58:10.81 .net

今の書き込みも１回目は吸われ、文面を見直して２回目を投稿すると
Rock54でした。NGワードがありました。

「製品『しょうかい』の記事は」（『』内は漢字）

の２漢字単語がダメだったようです。犯罪誘因対策ですかね。

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ネタは、執筆者が新規に試した場合、試用報告を
するつもりでいます。書かずにはいられないですから。
まだ、古い環境を使っているので…。すいません。
いま見た、語れスレによると、６月には14.1Rとの事です。
うーん、執筆者的には、なんとも中途半端だお…。

じゃ、お夜食を食べてきます。

346 ：名無しさん＠お腹いっぱい。：2024/05/01(水) 12:12:37.92 .net

荒らし前はスレ順位が700くらいならまだ残ってたくらいだった
何度かスレを消してるんだろうけど抜本的な規制や対策する気がなさそう

347 ：名無しさん＠お腹いっぱい。：2024/05/25(土) 07:46:12.05 .net

linux版のchromeもportsに追加されました
www/linux-chrome
少し古いバージョンなのが残念ですが

348 ：FreeBSDでwimeを使っている君：2024/05/26(日) 00:44:13.10 .net

前回のレスを書いた後に、スクリプトが100ほどスレを立てて、
このスレの順位が下がりましたが、数日後にスレ一覧を見ると
常識的な順位に戻っていました。
どなたかが、スクリプトなスレを「削除要請」から削除依頼して
くださったのか、と、思いましたが、特に削除依頼は
出ていませんでした。
スクリプトなスレは運営が対処してくれているようですね。

ここぐらいのゆるい情報交換がいいんですよ。

facebookみたいに、個人情報や、「こじらせ」や、性癖をさらして
情報交換をするほど…、でもないんですよ。

でも、Wineやwimeが、Unix系ユーザに知られてほしいんですよ。

昔みたいにUnix系雑誌があれば、記事で知られるんでしょうけどね。

SoftwareDesign誌はLinux寄りVim寄りの総合誌っぽくなったしなあ。

Twitterは、アカウントなしでは時系列ではWeb閲覧できなくなったし、
Wineで有名な「さがわ@sagawa_aki」の投稿は、即ログイン表示で
まったく見ることができないしなあ。
「twilog.togetter.com」なサイトは、リツイートが表示されないから
「さがわ@sagawa_aki」氏みたいなリツイートを集めるスタイルだと
よくわからない時系列まとめにしかならないだろうしなあ。

「さがわ@sagawa_aki」氏、昔みたいにLinux板のWineスレに
来てくれたらなあ。

349 ：FreeBSDでwimeを使っている君：2024/05/26(日) 00:58:48.36 .net

UNIX板の「Emacs Part 54」スレ（常駐している訳ではないです）で
「WindowsのMS-IMEを」の流れを見ていて思ったんですが。

FreeBSDでwimeを使っている君や、まだ見ぬwimeユーザの皆様は、

FreeBSD（Linuxでもよいが）＋Wine＋wime＋Windows用ATOK　で

Emacsに対してCanna変換であるかのような振る舞いをする
Windows用ATOK（などのWindows用IME）で日本語入力をしています。

これ、

Windows＋Windows_Subsystem_for_Linux2＋Linux(Ubuntu)＋Emacs

を構築する事で、

Windows用IMEでLinux側のEmacsに対して日本語入力できるのか、と
思って、

「いやいや、単にWindowsで使えるLinuxの仮想環境なんじゃないの、
だいたいさ、これじゃ、FreeBSDでwimeを使っている君、の努力がさ」

などと思ってググったのですが、Windows用IMEでLinux側のEmacsに対して
日本語入力はできないみたいですね。よかったｗ

でも、単にEmacsに対して、Windows用IMEで入力したければ、
Windowsを利用するなら、Windowsに移植されたEmacsでもよいわけですし。

350 ：FreeBSDでwimeを使っている君：2024/05/26(日) 01:06:10.95 .net

よくよく考えれば、FreeBSD＋Wine＋wime＋Windows用ATOK、な、環境は、
PC用Unix（BSD系＋Linux）の日本語入力環境に対して、
商用環境で熟成したWindows用（DOS用でもかまわないが）の日本語入力を
導入したいという環境な訳ですし。

まあ、商用環境で熟成したPC_Unix向けの日本語入力でもいいわけですが。

ああ、それならLinux/FreeBSD用のオムロンの商用Wnn8があったよなあ。
しかし、商用Wnn8もいつまでやってくれるかわからないしなあ。

というか、FreeBSD12.1Rのアップデート、が最後の動きですが、
パッケージは探せば、取り寄せで購入（販売店の問い合わせ）
できるようです。

PC用Unix向けのWXGも、幾多の挑戦者の努力もむなしく、
いまでは動かないですしね。

有名な「翠風に舞え」さんによると、Wnn8はFreeBSD14.0Rでも
動くみたいです。

Wnn 8 on FreeBSD
http://maikaze.cafe.coocan.jp/wnn8.html

351 ：名無しさん＠お腹いっぱい。：2024/05/26(日) 01:10:01.00 .net

執筆者は、Chrome系はあまり興味がなかったので
理解不足なのですが。

「Chromium」がもともとの元祖で、PC_Unix版が存在する。

「Chrome」はChromiumをもとにしたもので、
Windows版、MacOS_X版、Linux版、スマホ向け版が存在する。

FreeBSDには「Chromium」しかなく、「Chrome」は存在しない。
やっと、「linux-chrome」という形ではあるが、portsに追加された。

という理解でいいですか。

むかし、Firefoxでもflash再生問題だったかで、
「linux-firefox」みたいなのがあったような気がします。

352 ：FreeBSDでwimeを使っている君：2024/05/26(日) 01:11:10.13 .net

>>351は「FreeBSDでwimeを使っている君」です。

353 ：名無しさん＠お腹いっぱい。：2024/05/26(日) 03:47:58.23 .net

linux-firefoxもlinux-operaもあった
linux-chromeはDRMなNetflixなどを見れるという利点(ネイティブにもwww/foreign-cdmはあるが)と
ネイティブのpkg問題(時間がかかりすぎてビルドが途中でKillされるのでpkgが無いことがある)を
解決する

354 ：FreeBSDでwimeを使っている君：2024/05/26(日) 23:50:30.84 .net

簡潔にして詳細な解説、ありがとうございました。

まったくの誤答ではないものの、かなり外した理解だった
みたいです、すいません。

Linuxulator（Linuxバイナリ互換機能）はありがたい
存在ですね。

Linuxulatorは、Brother公式のLinux用lprドライバのために
使ったのが最初で、flashのために短期間、linux-firefoxを
使っていましたが、flashの時代ではなくなったので自然と
使わなくなりました。
linux-firefox、特に違和感はなかったです。
逆にサクサクと速く感じたぐらいです。

じゃ、お夜食を食べてきます。

355 ：FreeBSDでwimeを使っている君：2024/06/09(日) 17:54:24.48 .net

日本人プログラマー向けコーディングフォント「Bizin Gothic」が無償公開 - 窓の杜
https://forest.watch.impress.co.jp/docs/news/1596755.html
「Ricty」でもお馴染みの「Inconsolata」と読みやすい「BIZ UDゴシック」をかけ合わせ
樽井 秀人 2024年6月3日 11:05

今までありがとう！　日本人プログラマー向けフォントの先駆者「Ricty」の開発が終了 - やじうまの杜 - 窓の杜
https://forest.watch.impress.co.jp/docs/serial/yajiuma/1478305.html
樽井 秀人 2023年2月14日 06:45

Rictyは入れてましたけど、使っていなかった執筆者君でしたー。

356 ：FreeBSDでwimeを使っている君：2024/06/09(日) 18:25:38.77 .net

「FreeBSDを語れ」スレに書こうと思ったんですが、過去にレスが
あったカーネルパニックのネタが来まして、レスが入り乱れると
レスが読みにくくなる、と、落ち着くまで遠慮しよう、と、思ったの
ですが、邪魔になりにくそうな、ここに書きます。
デスクトップ環境というか、生活環境の話だし、という事で。

偶然見つけたんですが、ケアレスミスだと思います。

FreeBSDでは（フォントさえあれば）コンソールで日本語が出る
VTコンソールの時代になりましたが、kon2は、現在でもportsに
存在します。古いソフトウェアでも残りがちなのが、FreeBSDの
良いところですね。

357 ：FreeBSDでwimeを使っている君：2024/06/09(日) 18:38:35.25 .net

執筆者君は、VTコンソールを「えー、UTFなのぉ」と言いながら
試してみた事がありますが、画面サイズは広くて良かったのですが、
トロトロカクカクとした遅い描画だったので、kon2を思い出して
kon2を試してみたら、kon2のほうが描画が速かったです。
ただし、VGAサイズだったのですが…。
今どきは画面サイズが大きいからkon2の24dot版が、あっても
よいような気もします。

（以下ケアレスミスと思われる部分の引用）
第15章 地域化 (localization) - i18n/L10n の利用と設定 | FreeBSD Documentation Portal
docs.freebsd.org/ja/books/handbook/l10n/
15.2.2. コンソールの設定
表 3. Ports Collection で利用可能なコンソール
言語　　　port の位置
日本語　　chinese/kon2

358 ：FreeBSDでwimeを使っている君：2024/06/09(日) 18:44:56.48 .net

>>357 は、書き込みが完了しても反映されないので
（俗に言う「吸われる」状態）、
ハイパーテキストトランスファープロトコルの文字列を
削ると書き込めて反映されました。

359 ：名無しさん＠お腹いっぱい。：2024/06/09(日) 20:13:55.08 .net

今はFreeBSDにも削除魔が大勢いる

/usr/ports/UPDATINGや/usr/ports/MOVEDは昔は20年分くらいあったのが
今はサポートされてるリリース以前は削除してるので3年分くらいしかない

portsのexpiration dateも以前は長めの期間が設定されていたが
今は1、2ヶ月先を指定して期日が来ると即削除
ちゃんと動いていても開発が止まると放棄されてるからと削除してる
特にメンテナのいないportsは

archivers/pxz(並列 xz)なんてバージョンが20220509なのにベースのxzが
マルチスレッド対応してるからとEXPIRATION_DATEが設定された

kon2などが残ってるのはjapaneseだから手を出してないだけ

カーネルもGENERICにFreeBSD4からのCOMPATが指定されているが
最近一桁のFREEBSD4〜9を削除して10以降にしようと主張する奴が出てきた
しかも設定だけじゃなくてコードを消そうと言う奴まで

さすがにこれは却下された

と最近のメーリングリストやバグ報告を見て感じた不満を書いてみた

360 ：FreeBSDでwimeを使っている君：2024/06/09(日) 22:12:31.42 .net

ええ…、FreeBSDってそんな状況になってるの…、怖い…。

なんだか、そういう削除魔というか、整理したい派というか、
そういう感覚って、潔癖症っぽくて、ちょっとなあ。

サーバ維持費の支払いが、ってなら仕方がないと思うけど。

FreshPortsでも「There is no maintainer for this port.」を
よく見るようになりましたが、メンテナがいる状態にして、
開発してますよ感も出しておかないと、危険が危なそうですね。

361 ：名無しさん＠お腹いっぱい。：2024/06/09(日) 22:32:22.88 .net

メンテナがいてもね

例えばpcreはpcre2が出て放棄されてるから削除しよう
pcreに依存してるportsもメンテナがいて動いていても削除だよ
gtk2ももうすぐ削除する予定だからね状態

362 ：名無しさん＠お腹いっぱい。：2024/06/09(日) 22:39:07.68 .net

あと最後の文はスルーした

363 ：FreeBSDでwimeを使っている君：2024/06/11(火) 00:26:11.81 .net

もちろん、正当に開発が続くべきであって、
「開発してますよ感」はすべきではないですけど。

むむむー。
何かあると、枕を並べて討ち死に、って感じかなあ。
makeが通ってバイナリが動くなら残せばいいと思うんですが。

GTK1のRedHat由来のElectricEyes（画像ビューワ）が、
GTK1削除（End_Of_Lifeだったか）と共に消えて代替物を
探したなあ。
別に、GTK1のElectricEyesで困ってなかったんですが。

PCManFM（ファイラー）は、GTK2版とGTK3版、QT5版が
あって安心感があります。このような開発スタイルなら
ツールキット由来の削除からは逃れられそうです。

364 ：名無しさん＠お腹いっぱい。：2024/06/11(火) 11:44:30.34 .net

みんなもArch Linuxおいでよ
portsよりもよっぽとちゃんと管理されてるよ
20年来のFreeBSDファンだったが積もり積もった不満でとうとう見限ったわ

365 ：名無しさん＠お腹いっぱい。：2024/06/11(火) 21:52:15.21 .net

サーバーはFreeBSD、しかし仮想化環境構築に疲れてProxmoxVEを入れたら楽すぎて笑った。
それつながりでノートパソコンにRoot on ZFSで最小構成インストールするのにインストーラ無視してDebianいれたあとでArchでええやんって言われた悲しみ。

異論は認めるが個人的にはFreeBSDはportsのインストール先を/usr/localにしてなきゃよかったのにと昔から思ってる。
これのせいで自前で入れる奴と競合するからportsから消えたのを入れるのがすごくめんどくさい。

366 ：FreeBSDでwimeを使っている君：2024/06/12(水) 22:19:58.37 .net

wimeがリビジョンアップされました。

4.1.7　2024年6月11日
・変換候補に環境依存文字があるとハングアップすることがあった。
・qt5でセグメンテンテーションフォールトになる。

以下のスレにも告知しました。

日本語入力メソッド総合スレッド＠Linux
https://mao.5ch.net/test/read.cgi/linux/1472658083/

367 ：名無しさん＠お腹いっぱい。：2024/06/13(木) 10:55:48.14 .net

佐藤さんがコアに復活した

368 ：名無しさん＠お腹いっぱい。：2024/06/13(木) 15:13:30.18 .net

>>364
俺はFreeBSDからopenSuSEに行った