Orz日記 by Akio Morita

_ [FreeBSD]ibus 1.5.34続き

ibus 1.5.34不具合の件だが、1.5.34で問題なくktermに入力できる環境がある…何故 Orz

ibus 1.5.34 + ktermが動かない環境にXIMまわりの問題があるっぽぃのだが、ibus 1.5.34 + ktermが動いている環境もあるので謎が深まった

build環境の問題それとも依存ライブラリの更新失敗か？

パッケージを運搬して検証するば、build環境依存 or 実行環境依存の区別は出来そう

_ [雑記]Noctua水冷発注

OLIOSPECさんが入荷と発送開始を告知していたNoctua水冷ですが、国内正規代理店TechAceによるamazon上の販売が開始されたので、Antec P5向けにNL-LC1-24とVRMファンオプションNL-ACF1を発注した

組み込みと各種ベンチマークは週末かなぁ…

_ [FreeBSD]ibus 1.5.34不具合

• ktermへのXIM入力が動かない (ibus-1.5.33は動く)
  • xterm・emacsへのXIM入力は動く

影響を見えるのがktermのみなので、EUC-JP localeでXIMを初期化するkterm固有のエンコーディングがらみかなぁ？

過去のXIM関連のトラブルは…

• ktermのEUC-JP locale XIMとX側のUTF-8→EUC-JP変換の不具合
• gdk_initだとXIM動かない件

次の作業は、コアコンポーネントの差分を確認して、コンポーネント単位で巻き戻して動作検証か…

_ [FreeBSD]www/firefox-esrビルド出来ない

stable/15上でwww/firefox-esrのビルドが失敗する

• 使用するdevel/llvmによって微妙にエラーが異なるが、同梱のrustコードのコンパイルで起きるぽぃ
• www/firefox(152.0.3_2) + devel/llvm21は正常にビルド出来る
  • www/firefoxの頻繁なversion upとプロファイル互換性のため退行時にversion down出来ない問題を避けるために firefox-esrを選んでいるので解決にならない

devel/llvm19使用時 (default設定)

warning: struct `ResultIter` is never constructed
   --> /usr/obj/usr/ports/www/firefox-esr/work/firefox-140.12.0/third_party/rust/askama_derive/src/input.rs:611:8
    |
611 | struct ResultIter<I, E>(Result<I, Option<E>>);
    |        ^^^^^^^^^^
    |
    = note: `#[warn(dead_code)]` (part of `#[warn(unused)]`) on by default

warning: `futures-executor` (lib) generated 1 warning
warning: `cssparser` (lib) generated 1 warning
warning: `askama_derive` (lib) generated 1 warning
gmake[3]: *** [/usr/obj/usr/ports/www/firefox-esr/work/firefox-140.12.0/config/makefiles/rust.mk:528: force-cargo-library-build] Error 101
gmake[3]: Leaving directory '/usr/obj/usr/ports/www/firefox-esr/work/.build/toolkit/library/rust'
gmake[2]: *** [/usr/obj/usr/ports/www/firefox-esr/work/firefox-140.12.0/config/recurse.mk:72: toolkit/library/rust/target-objects] Error 2
gmake[2]: Leaving directory '/usr/obj/usr/ports/www/firefox-esr/work/.build'
gmake[1]: *** [/usr/obj/usr/ports/www/firefox-esr/work/firefox-140.12.0/config/recurse.mk:34: compile] Error 2
gmake[1]: Leaving directory '/usr/obj/usr/ports/www/firefox-esr/work/.build'
gmake: *** [/usr/obj/usr/ports/www/firefox-esr/work/firefox-140.12.0/config/rules.mk:359: all] Error 2
*** Error code 1

Stop.
make[1]: stopped making "/usr/obj/usr/ports/www/firefox-esr/work/.stage_done.firefox._usr_local" in /usr/ports/www/firefox-esr
*** Error code 1

devel/llvm21使用時

warning: struct `ResultIter` is never constructed
   --> /usr/obj/usr/ports/www/firefox-esr/work/firefox-140.12.0/third_party/rust/askama_derive/src/input.rs:611:8
    |
611 | struct ResultIter<I, E>(Result<I, Option<E>>);
    |        ^^^^^^^^^^
    |
    = note: `#[warn(dead_code)]` (part of `#[warn(unused)]`) on by default

warning: `half` (lib) generated 21 warnings
warning: `serde_path_to_error` (lib) generated 1 warning
warning: `askama_derive` (lib) generated 1 warning
warning: `async-trait` (lib) generated 4 warnings
gmake[3]: *** [/usr/obj/usr/ports/www/firefox-esr/work/firefox-140.12.0/config/makefiles/rust.mk:528: force-cargo-library-build] Error 101
gmake[3]: Leaving directory '/usr/obj/usr/ports/www/firefox-esr/work/.build/toolkit/library/rust'
gmake[2]: *** [/usr/obj/usr/ports/www/firefox-esr/work/firefox-140.12.0/config/recurse.mk:72: toolkit/library/rust/target-objects] Error 2
gmake[2]: Leaving directory '/usr/obj/usr/ports/www/firefox-esr/work/.build'
gmake[1]: *** [/usr/obj/usr/ports/www/firefox-esr/work/firefox-140.12.0/config/recurse.mk:34: compile] Error 2
gmake[1]: Leaving directory '/usr/obj/usr/ports/www/firefox-esr/work/.build'
gmake: *** [/usr/obj/usr/ports/www/firefox-esr/work/firefox-140.12.0/config/rules.mk:359: all] Error 2
*** Error code 1

Stop.
make[1]: stopped making "/usr/obj/usr/ports/www/firefox-esr/work/.stage_done.firefox._usr_local" in /usr/ports/www/firefox-esr
*** Error code 1

_ [雑記]AI人気

AIが自律的にコード開発できるとか、AI任せでデバッグできる的な話が話題になり、AIに任せれば既存コードのバグ取りが無人化できるとの期待を語る人々が現れる今日この頃…

現在のLLM(大規模言語モデル)は、既存のノイマン型コンピュータで動いているはずなので、計算科学の文脈だとその能力はチューリングマシンやλ計算と同等(正確には、メモリの有限性で制約されたそれ)なはずで、タスクを解くLLMは、たかだか多項式時間でCなりFortran等のチューリング完全なプログラミング言語に変換できます (シビラシステムとかIAL社の量子サーバーとかなら前提が変わるかも…)

現行のLLMベースのコード開発自動化システムに任意性はもてないはずで…

1. 任意のプログラムPが任意の仕様Sに適合しない場合、修正されたプログラムP'を返すプログラムQが存在すると仮定
2. Q'(S, P) := (Q(S,P) == P)は、任意のプログラムPが任意の仕様Sに適合するかの真偽値を返すプログラムとなる
3. 仕様Sに「プログラムPは停止する」を与え Q"(P) := Q'(「Pは停止する」, P)を生成する
4. Q"(P) は 任意のプログラムPの停止性を判定するプログラムなので、Qの存在は「停止性問題の肯定的な解決」を含意する
5. チューリング完全な計算機上での、停止性問題は否定的に解決されている
6. 従って、チューリング完全な計算機上のAIは、任意の仕様Sに沿って任意のプログラムPのデバックを完遂できない

例えば、量子計算機はNP完全問題が多項式時間で解けると証明されていないが、現時点では古典計算機より強力だと考えられているので、量子計算機上のLLMはそうしたハイパータスクを解ける可能性はまだ残っているはず…

_ [雑記]Noctua水冷NL-LC1予約始まっている

OLIOSPECでNoctua水冷の予約が始まっている模様

240mmサイズで4万スタートかぁ…

240mmサイズで厚めのラジエータなARCTIC Liquid Freezer III Pro 240が 1万円台前半、NF-A12x25 G2 PWM PPセットが9000円程度なので、Noctua監修の静音化チューニングに価値を見出せるかどうかですねぇ…

Noctua公式のスペックシートだと、240mmでNSPR 210(同360mm 248・420mm 268)に対して、NH-D15 G2がNSPR 228 (同NH-U12A 168)なので 240mmサイズでもD15 G2と戦えるレベルか…

_ [雑記]AGESA 1.3.0.1

ぼちぼち導入開始

• MSI B850 TOMAHAWK MAX WIFI 7E62v2A53→7E62v2A60
• ASRock B650M PG Riptide WiFi 3.40→4.20

_ [雑記]10Gtek 10GBASE-T SFP+モジュール

Marvelの新チップ CUX3610が乗ったASF-10G-T100を入手したので、 テスト結果まとめ

テスト環境はQNAP QSW-M1208-8CのSFP+専用ポート

表面温度は10GBASE-T接続(ケーブル2m)でアイドリング時だが、SFP+モジュール挿入後10分程度なので平衡温度に達してない可能性あり

• ASF-10G-T (昔から使っている) - 10G/1G両方動くが、かなりホットでモジュールにずっと触っていられない
• ASF-10G-T80(CISCO互換) - 1G接続は認識しない、温度はASF-10G-Tよりは低くASF-10G-T100より高め、汎用性に難あり
• ASF-10G-T100(CISCO互換) - 10G・1G両方動く、発熱はさわり続けられる程度、現時点では価格高め＆品薄気味 @ 密林

新規に追加調達するなら、ASF-10G-T100が良さそう…

_ [FreeBSD]15.1 RELENG

予定通りに15.1-RC1に到達した模様なので、6月頭には特に遅延なくリリースされるのかな…

_ [雑記]同人誌整理

ゴールデンウィークは6日かけて同人誌の整理実施

第一段階として、4日ほどかけて本棚3本＋床置きの蔵書から即時廃棄決定出来るものを抽出し、搬出可能な状態に纏める作業を実施。多分、連休中に纏めた分だけで本棚1本相当ぐらいか？

多分、スーパーのリサイクルステーションまでカート7往復ぐらい必要

第二段階として、蔵書スペース周辺の不用品整理・処分して、精査分類作業用の一時置きスペースを確保

続く第三段階として、確実に残す予定のものを抽出・分類して、クロネコボックス8号に梱包を予定 (小さめのダンボールだが、B5同人誌が2冊単位で平置き可能で、みっちり詰めても普通に両手で運べる重量に止まる箱で、ヤマト運輸の営業所でまとめ買い or ネット注文で配送してもらえる)

初期段階として、特定ジャンル・作家単位での抽出・仮置き作業を実行中

これで、本棚内の本の廃棄・梱包が進めば、場所が空くので分類・精査作業が捗るように成るはず…

あとは、A5版の書籍が綺麗に詰められ、重くなりすぎないダンボールを探さないと…(底面にA4が入り、高さがあまり高くない箱が望ましい)

書籍類を普通のダンボールにみっちり積めると、普通の人間には運べない＆重すぎて底が抜けるので、積み上げられるようにみっちり詰めた状態で 15〜20kg辺りに収まるサイズ感のダンボールが欲しい

B5版だとヤマト運輸のクロネコボックス8号がいい感じ、底面的には10号も該当だが高さがありすぎるのでギッチリ詰めると持ち上げるのに苦労しそうである

_ [FreeBSD]15.1-STABLEへ移行開始

stable/15に15.1-STABLEが下りてきたので移行開始

linuxkpi回りは、drm 6.11サポートまでマージされている模様

https://github.com/freebsd/drm-kmod 上のDRMであるが2026/05/02時点のコードは、 drm/i915kms moduleのMakefileが壊れている模様 (includeの位置がおかしい)

ttm/Makefileを見ながら修正すれば 15.1-STABLE上でビルド出来る模様

diff --git a/drm/Makefile b/drm/Makefile
index d816052888..debb29e845 100644
--- a/drm/Makefile
+++ b/drm/Makefile
@@ -4,6 +4,10 @@ SRCDIR=       ${.CURDIR:H}/drivers/gpu/drm

 .PATH:        ${SRCDIR} ${SRCDIR}/display ${SRCDIR}/scheduler

+.include "../kconfig.mk"
+.include "../linuxkpi_version.mk"
+.include "../compiler_flags.mk"
+
 KMOD= drm
 SRCS= drm_atomic.c \
       drm_atomic_helper.c \
@@ -131,12 +135,6 @@ SRCS+=    drm_panic.c

 CLEANFILES+= ${KMOD}.ko.full ${KMOD}.ko.debug

-.include <bsd.kmod.mk>
-
-.include "../kconfig.mk"
-.include "../linuxkpi_version.mk"
-.include "../compiler_flags.mk"
-
 CFLAGS+= -I${.CURDIR:H}/linuxkpi/gplv2/include
 CFLAGS+= -I${.CURDIR:H}/linuxkpi/bsd/include
 CFLAGS+= -I${SYSDIR}/compat/linuxkpi/common/include
@@ -186,3 +184,5 @@ CWARNFLAGS.drm_mm.c+=                              -Wno-cast-qual -Wno-unused-function
 CWARNFLAGS.drm_syncobj.c+=                    -Wno-unused-variable

 EXPORT_SYMS=  YES
+
+.include <bsd.kmod.mk>
diff --git a/i915/Makefile b/i915/Makefile
index 5e657c35d7..83061c0dd8 100644
--- a/i915/Makefile
+++ b/i915/Makefile
@@ -11,6 +11,10 @@ SRCDIR=     ${.CURDIR:H}/drivers/gpu/drm/i915
       ${SRCDIR}/pxp \
       ${SRCDIR}/soc

+.include "../kconfig.mk"
+.include "../linuxkpi_version.mk"
+.include "../compiler_flags.mk"
+
 KMOD= i915kms
 SRCS= \
       i915_active.c \
@@ -342,14 +346,6 @@ SRCS+=    i915_hwmon.c

 CLEANFILES+= ${KMOD}.ko.full ${KMOD}.ko.debug

-
-.include <bsd.kmod.mk>
-
-.include "../kconfig.mk"
-.include "../linuxkpi_version.mk"
-.include "../compiler_flags.mk"
-
-
 CFLAGS+= -I${.CURDIR:H}/linuxkpi/gplv2/include
 CFLAGS+= -I${.CURDIR:H}/linuxkpi/bsd/include
 CFLAGS+= -I${SYSDIR}/compat/linuxkpi/common/include
@@ -403,8 +399,9 @@ CWARNFLAGS.i915_gem_context.c=     -Wno-unused-function
 CWARNFLAGS.intel_ggtt.c=      -Wno-integer-overflow
 CWARNFLAGS.intel_gmch.c=      -Wno-unused-but-set-variable
 CWARNFLAGS.intel_gt_mcr.c=    -Wno-tautological-constant-out-of-range-compare
-CWARNFLAGS.intel_guc_capture.c=       -Wno-unused-but-set-variable
-CWARNFLAGS.intel_guc_submission.c=    -Wno-unused-function
+CWARNFLAGS.intel_guc_capture.c=       -Wno-address-of-packed-member -Wno-unused-but-set-variable
+CWARNFLAGS.intel_guc_ct.c=    -Wno-address-of-packed-member
+CWARNFLAGS.intel_guc_submission.c=    -Wno-address-of-packed-member -Wno-unused-function
 CWARNFLAGS.intel_hdmi.c=      -Wno-unused-but-set-variable -Wno-unused-variable
 CWARNFLAGS.intel_hotplug.c=   -Wno-uninitialized
 CWARNFLAGS.intel_psr.c=               -Wno-unused-but-set-variable
@@ -412,9 +409,12 @@ CWARNFLAGS.intel_region_ttm.c=    -Wno-missing-prototypes
 CWARNFLAGS.intel_reset.c=     -Wno-unused-but-set-variable
 CWARNFLAGS.intel_sseu.c=      -Wno-incompatible-pointer-types-discards-qualifiers
 CWARNFLAGS.intel_workarounds.c=       -Wno-unused-variable
+
+
 CWARNFLAGS.i915_debugfs.c=    -Wno-unused-but-set-variable
 CWARNFLAGS.i915_driver.c=     -Wno-unused-but-set-variable
 CWARNFLAGS.i915_irq.c=                -Wno-unused-but-set-variable
+CWARNFLAGS.i915_gem_context.c=        -Wno-address-of-packed-member
 CWARNFLAGS.i915_gem_execbuffer.c=     -Wno-unused-but-set-variable -Wno-sometimes-uninitialized
 CWARNFLAGS.i915_gem_mman.c=   -Wno-unused-but-set-variable
 CWARNFLAGS.i915_gem_shmem.c=  -Wno-unused-but-set-variable
@@ -430,3 +430,5 @@ CWARNFLAGS.skl_universal_plane.c=  -Wno-unused-but-set-variable
 CWARNFLAGS.vlv_dsi.c=         -Wno-unused-but-set-variable

 EXPORT_SYMS=  YES
+
+.include <bsd.kmod.mk>