Orz日記 by Akio Morita

_ [雑記]Let'snote FV5

2024年春の新モデル、CPUパワーはLV9比で200%強らしい

現在使っているLV8との比較だと画面が1920x1080(16:9)から2160×1440(3:2)に広がるのがメリット、デメリットは光学ドライブ廃止だが現行機種で内蔵している方が珍しくなっているので運用上というかソフトインストール時のデメリットですかねぇ…

載ってるのがCore Ultra7 165H(Meteor Lake)になるので、drm kernel module対応がいつになるかが気になるところ

stable/14だとdrm-61-kmodまで対応で、pull requestが出てるdrm-66-kmodだと15-CURRENTが必要で一つ前のRapter Lake対応までなので、使えるようになるまで時間がかかりそう (その時には、さらに新しいCPUモデルが出ている罠)

WiFiまわりに関してはiwlwifiに期待だが、最悪USBか？ (LV8だとiwmは安定に動くがiwlwifiはpanicする)

_ [FreeBSD]14.1の準備が始まる模様

4月から14.1Rへむけてのリリースサイクルが始まる。14.0はだいぶ遅れたけど、ポイントリリースは予定どおり夏前に出るだろうなぁ

_ [FreeBSD]lang/ruby32へ切り替え

ports-CURRENTのdefaultがruby3.2へ切り替わったので、いろいろ置き換え

Redmine5.0運用系はRuby3.2に対応しないので、Redmineのアップグレード完了まで要注意

_ [FreeBSD]13.3-RELEASE

RCが無事終わった模様

_ [FreeBSD]graphics/drm-61-kmod on FreeBSD 14.0-STABLE

1400509にてdrm-61-kmodビルドに必要なlinuxkpiがMFCされた ports-CURRENT側はまだ対応されてないので以下のQuick HackでビルドとAlderLake-N(Intel N305)での動作を確認した

index 43f0d5be31aa..5eca31fcb15e 100644
--- a/graphics/drm-61-kmod/Makefile
+++ b/graphics/drm-61-kmod/Makefile
@@ -26,7 +26,7 @@ GH_TAGNAME=   ${DRM_KMOD_GH_TAGNAME}

 .include <bsd.port.options.mk>

-.if ${OPSYS} == FreeBSD && ${OSVERSION} < 1500008
+.if ${OPSYS} == FreeBSD && (${OSVERSION} < 1400509 || 1500000 <= ${OSVERSION} && ${OSVERSION} < 1500008)
 IGNORE=                not supported on older than 15.0, no kernel support
 .endif
 .if ${OPSYS} != FreeBSD

_ [雑記]みぞれ→雪→雨→雪…

昨日から寒いと思っていたが、なんか白いものが降り始めた Orz

_ [雑記]計算機サーバー不調

どうもNFS mountに関連して、kernel内のリソースのロック競合で待ちが発生しているように見える

設定変更しようにも、一度ユーザープロセスを追い出さないとNFS mountが解除できない罠

_ [FreeBSD]MANPREFIX廃止準備

LOCALPREFIX/manからLOCALPREFIX/share/manへの移行に併せてMANPREFIXが廃止する模様

ローカルで維持しているports更新向けにports-CURRENT側の作業内容をピン止め

• MANPREFIX: eleminate its usage and move man to share/man
• MAN[1-5]PREFIX: eleminate its usage and move man to share/man

_ [FreeBSD]cgit止まってる？

https://cgit.freebsd.org/ が応答しない模様、portsとかの変更履歴調べるのが不便 Orz

_ [雑記]電子レンジ壊れた

TWINBIRDの単機能な奴だが、前から一部不調だった操作ボタンがまったく反応しなくなった。10年持たないとは軟弱な！

前の奴は、大学進学時に下宿するとき大学生協で購入したもので、大学院出て就職してからも動きつづけたタフな奴。 さすがに宿舎廃止で引っ越すとき移動させようとしたら、足がもげたので今日壊れた奴に買い換えたのだが、やはり白物家電の品質下がっているのかなぁ？

_ [雑記]japanease/ktermの覚書

ports-CURRENTから外されてもしぶとくktermを使っているのだが…

FreeBSD 14.0-STABLE上でビルドしたものは、TERMCAP環境変数が壊れている？ (www/firefox configure/build時にpythonでruntime errorになる)

少なくとも、13.2-STABLE上でビルドしたものと値が異なるというか、凄く短いので何か変

同様に、x11/xtermの挙動も異なって見えるので要調査(分類してみた)

動作的には、stable/14系ではtermcapの検索に失敗し、xtermではTERMCAPを設定無し動作(深刻な副作用は出ない)、ktermでは独自のco#, li#エントリ追加時に正しく初期化されていないtermcap bufferを操作して、壊れたTERMCAP環境変数を設定している模様

コードを読んで状況が見えてきた…

• co#・li#エントリは、ktermのresize@main.cが追加している
  • resizeを含めtermcap編集コードは、termcap bufferの有効性を検査していない
• stable/14系だとtgetent(3)が1を返して成功しても、bufferにtermcapが書き戻されない
• spawn@main.c内のlocal scopeなtermcap, newtc bufferが初期化されていない
  • ifdef linuxなbzeroコードがあるが、当該環境では有効にならない
  • 起動毎にTERMCAP環境変数の先頭が異なる原因

多分、正しい修正は…

• bufferを明示的に初期化する(bzeroは過剰で、先頭をNULL文字にするで十分のはず)
  • 未初期化の場合、その後の編集操作で最悪buffer overrunで上書き or SEGVする
• termcap bufferが空文字列のときの処理を入れる
  • 編集しない (resize・strcat)
    • remove_termcap_entryは、自動的にNOPになる
  • TERMCAP環境変数を設定しない