nForce使ってましたね…Phenom9500と組み合わせて。エラッタありのPhenom9500をわざわざ使ってましたｗ

nV1…ｸﾞｷﾞｷﾞ…

結論：名前は正しく書こう（書けなかったとしても正しく書く努力はしたい）

ARMに関しては…ごめんなさい、もうどうでもいいという感情です
（だって最初ARMだったけど今Arm表記でロゴはarmなんだもん…自分の中では昔のARMが一番しっくりくるんだけどさ）

逆にNVIDIAはNvidiaとは書かないだろうし

あー、でもWindowsをWINDOWSと書いてもあまり違和感はない…無くは無いか。やっぱWindowsって書いた方が良いよね？

FreeBSDをFREEBSD表記するのってどの程度許されてるんだろう（ってNetBSD/OpenBSDのNETBSD/OPENBSD表記についても）。

駄目ではないのだろうけど、小文字を利用できないような特殊な環境下でない限りはFreeBSD表記するのが筋って気がするんだが…（NetBSD/OpenBSDに関しても同様？）。

あんまりこーゆう重箱の隅をつつく系なPRは投げたくなかったんだよ…
https://github.com/n7tae/mrefd/pull/24/commits/22f08c930af53d679782cb7be83a148fc6e27765

dosbox-x 2023.10.06→2024.03.01へのcommit終了っと。7.5に収録されるpackageが新しい方だと良いんだけど。

make update-patchesって…なんか便利だなこれ（教えてもらった）。

アニメ版のめぞん一刻って確か二階堂さんだっけ、誰かいなかったような…

まあ最近はカジュアルに悪意を向けてくる輩があまりにも多いので、この手の言葉狩りも良いエンターテイメントなんでしょう、彼らの頭の中では（他にもカジュアルに悪意を向ける手法、色々ありますよね）。

悪意を向けられる側としては正直迷惑しているので、どうにかして滅ぼせないかと考える毎日になりますけど。

「障害者」という表記を「障がい者」に改めよという「障害」狩り、だったら「システム障害」を「システム障がい」と書くのかい？というのは問うてみたいですね。

問題なのは文字列じゃなく、文字列に込められた悪意の有無だろって思うんですけど…そこを確認せずにただの文字列比較だけで「悪意あり！死ね！」とする人間の方が遥かに差別的であり、悪意の塊にしか自分には見えません。

これは昔からそう思っているし、この考えを改める気も今のところ無いです。他の人に自分と同じ考えを持てと押し付ける気は無いですが、その代わり反論は一切受け付けませんので。

gomrefdash化の作業…結局徒労に終わっただけ（使うの止めた）ではあるのだけど、何かの折にまた動かすことができやしないか試してみたいですね…

結局この手の魔女狩りって、単に「気に食わないからお前を殺す」という感情表現なだけなのでお互いがギスギスするだけだし、それを煽って喜ぶバカが出てくるだけなので良いことないんですよね。

だからこそ、魔女狩り狩りが必要だと以下省略。

このアカウントは、notestockで公開設定になっていません。

そうですか。

このアカウントは、notestockで公開設定になっていません。

うーん、mrefdのdashboard、gomrefdash使うの止めてref-dash( https://github.com/M17-Project/ref-dash ) 1.3.0のままで行くか。これで動かせるっていうなら別に問題無い訳なんだし。

framboise# /home/uaa/gomrefdash/gomrefdash
2024/03/09 16:53:57 Starting /home/uaa/gomrefdash/gomrefdash -
2024/03/09 16:53:57 gomrefdash.toml not found
2024/03/09 16:53:57 /root/.config/gomrefdash.toml not found
2024/03/09 16:53:57 no config files found, let's try reading from environment
2024/03/09 16:53:57 unable to get config: GOMREFDASH_HOSTPORT not set
framboise#

ふむ、コンフィギュレーションのファイルは$(HOME)/.config/gomrefdash.tomlを見に行くのか。

uaa@framboise:~/gomrefdash$ ./gomrefdash
2024/03/09 16:44:29 Starting ./gomrefdash -
2024/03/09 16:44:29 gomrefdash.toml found.
2024/03/09 16:44:29 unable to create dashboard: unable to create reflector: unable to obtain reflector data for /var/log/mrefd.xml: unable to stat file /var/log/mrefd.xml: stat /var/log/mrefd.xml: no such file or directory
uaa@framboise:~/gomrefdash$

mref用の新しいdashboard、手軽に動かせるのは良いけど…httpdを内包しているのでそこをどうするかが悩みどころ。 https://github.com/kc1awv/gomrefdash

80(http)の代替ポート(http-alt)、8080が有名だけど他にも8000, 8008, 591があるのか。 https://www.speedguide.net/ports.php?filter=http-alt

バイクの免許だけはあるけど、じーさんになるまでの間には乗りたいよなあ。その「じーさん」になるまでに残された時間、大してありゃしないというのが大きな問題で。

ハスクバーナってKTMの傘下にあるのか…「2013年にKTM傘下となったハスクバーナは、翌年のミラノショーにロードスポーツのコンセプトモデルとして、ヴィットピレン401を発表。KTM390デュークのエンジンやフレームを用いたカフェスタイルのモデルだった。」って https://www.bikebros.co.jp/catalog/38/999_4/ に書いてあるけど。

このアカウントは、notestockで公開設定になっていません。

もともとDOOMって486DX2/66MHz辺りで動いてたゲームだから、Cortex-M4辺りなら十分余裕な気がする（Cortex-M0の高クロック品でもイケるんだっけ？RP2040とかって…実際にやってましたか https://kilograham.github.io/rp2040-doom/ ）。

って、ハスクバーナってあのハスクバーナっすか？バイクの。https://www.husqvarna-motorcycles.com/ja-jp.html

（多分ヤマハみたいに何でも作っちゃう系のメーカーなんだと思う）

素直にLinuxでやればいーじゃん、ではあるんだろうけど…ズボラに管理したいサーバをLinuxでやるっていうのはちょっと怖いなって（ちゃんと面倒見ないとすぐクラックされちゃうし…OpenBSDだって雑に扱えば簡単に堕ちるのかもだけど）。

さてと、VPS上で動いてるmrefd(M17 reflector)をOpenDHT対応にすべくopendht/msgpack-cxxのports化をしていたのだけど、パッケージを持っていくのもなんかアレなのでportsをVPS上でビルドすることに。

ここまでうまくいけば、あとはmrefdのビルドとdashboardの入れ替え…時間かかったなあ。

問題無さそうなのでports/emulators/dosbox-x-2024.03.01へアップデート（のdiffをports@へ投げた）

dosbox-x-2024.03.01のビルド中…長い…

https://stackoverflow.com/questions/6928110/how-may-i-override-the-compiler-gcc-flags-that-setup-py-uses-by-default に近いけど、別に全てのオプションを無効化したいわけじゃない…

@redbrick デフォルトが-O3とはいえ、どこから来たのか分からないのを気軽に放り込むのが良いのか結構悩むんですよね。CFLAGS=""が本当に許されないのか、という疑問も出てきましたし…（GitHubのチェックがどこまでアテになるのかなあって）。

うーん、OpenDHTの件はちょっと放置して様子見てみるか。
closed（でmerged）なPRを見るに、ビルドのチェックに失敗している物もあったりするし。他の人のPRのチェックが失敗しているから自分のPRが失敗していても大丈夫だもんねーという言い訳はしたくないんだけど。 https://github.com/savoirfairelinux/opendht/pull/670

でもなんでUbuntu/GCC Autotools buildやMeson buildでエラー出すんだろ。minimal buildは問題無いのに。ていうかSlackware上でのビルドで問題なかったから投げたんだけどな… https://github.com/savoirfairelinux/opendht/actions/runs/8188380132/job/22396072416?pr=689

All I've Gotの後にIN MY HEAD…LF SYSTEM祭りですかね（嬉 #freak31

@redbrick -hoge とか指定しても、特に何も効果が起こらないようなオプションって意味です。

CFLAGS="$(MsgPack_CFLAGS)" LDFLAGS="-L$(top_srcdir)/src/.libs $(MsgPack_LIBS)" $(PYTHON) setup.py build_ext --inplace

この場面におけるCFLAGSの指定を””にしないで済むように、どう誤魔化すか…というのを悩んでいるところです（-g辺りを突っ込もうかと考えてます）。

Master滅べ論者って、ATA(IDE) HDDのMaster/Slaveなんかも滅べってことなんですかね…（実際、SPIのMISO/MOSIは滅んじゃいましたね）。

うーん、CFLAGS=""を許さない環境もあるみたいなんだけど、かといってCFLAGS="$(CFLAGS)"で逃げると-O2 -gが効いてしまうので、デフォルトの-O3が無効化されてしまう（これどこから来たんだろう…CXXFLAGS辺りか？）。何もしない、NOP命令な感じのgccのオプションは無いのかなあ。

gcc -pthread -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -g -O2 -fPIC -I../../include -I../include -I/usr/include/python3.9 -c ./opendht.cpp -o build/temp.linux-i686-3.9/./opendht.o -std=c++17
g++ -pthread -shared -L../src/.libs -g -O2 build/temp.linux-i686-3.9/./opendht.o -L../../src -L. -L../src/.libs -L/usr/lib -lopendht -lgnutls -o /home/uaa/opendht-3.1.7/python/opendht.cpython-39-i386-linux-gnu.so -std=c++17

CFLAGS="-g -O2 " LDFLAGS="-L../src/.libs " /usr/bin/python3 setup.py build_ext --inplace

gcc -pthread -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -fPIC -I../../include -I../include -I/usr/include/python3.9 -c ./opendht.cpp -o build/temp.linux-i686-3.9/./opendht.o -std=c++17
g++ -pthread -shared -L../src/.libs build/temp.linux-i686-3.9/./opendht.o -L../../src -L. -L../src/.libs -L/usr/lib -lopendht -lgnutls -o /home/uaa/opendht-3.1.7/python/opendht.cpython-39-i386-linux-gnu.so -std=c++17

CFLAGS="" LDFLAGS="-L../src/.libs " /usr/bin/python3 setup.py build_ext --inplace

でもどう直したもんだろうこれ。ports側のパッチで対応でも良いんだろうけど。

おー、OpenDHTに投げたPR、てめーのせいでビルド失敗してるぞコラ💢って怒られた（こういうチェックが自動でかかるのは助かる）。

OpenDHTができたらdosbox-xのportsのメンテナンスしないと…2024.03.01が出てる。

あとはpkg/DESCRを書けば良いはず。

libtoolがOpenBSDかgnuかの違い…切り替えてみたけど、どっちもtools/のビルドには失敗してるのでlibtoolの問題ではなさそう。

でも個人的に/optとか/pkgというのはうーにゅってなることが…

このアカウントは、notestockで公開設定になっていません。

portsはとりあえずtools, pythonはdisableにしておくことにしよう。bindingsが作れる布石は打っておくけどそれ以上は面倒なのでやらないという方針で。

ごあいさつ代わりに、opendhtのPython bindingをビルドする際のちょっとした問題に対するPRでも投げてみる。こんなんでもちゃんとレビューに掛けてくれるのかな（余計な仕事増やすな💢とか言われそう）。 https://github.com/savoirfairelinux/opendht/pull/689

まあOpenBSD使ってると確かにいちいち/usr/local/{include,lib}追加しないとダメってケースが多いのでめんどくせえなあと思う場面は多いのですが、そういうもんなのであんまり気にしてません。

このアカウントは、notestockで公開設定になっていません。

（面倒ではあるんですが、なんでもかんでも/usr/includeや/usr/libに入れたれーという思想、自分はあんまり好きじゃないです）

-L/usr/local/libを入れてるのは、標準で見に行く/usr/libにはシステム標準のライブラリしか入れないことになっているからで…ports等のパッケージ化されたものは/usr/local/libを見に行くようわざわざお願いしないといけないという事情があります。

portsで使用するlibtoolはOpenBSD由来で、特段理由が無ければこれを使うようにという指示があります。もちろん、必要があればGNU libtoolの使用を認めてはいますが…何故GNUじゃないといけないのかという説明は求められますね。

/bin/sh ../libtool --tag=CXX --mode=link c++ -std=c++17 -I/usr/local/include -L/usr/local/lib -O3 -Wno-deprecated -pedantic-errors -fvisibility=hidden -DMSGPACK_NO_BOOST -DMSGPACK_DISABLE_LEGACY_NIL -DMSGPACK_DISABLE_LEGACY_CONVERT -lopendht -lreadline -lfmt -L../src/.libs -L/usr/local/lib -lgnutls -lpthread -o dhtnode dhtnode.o

なぜこれでundefined symbolの嵐になるのか（OpenBSD上）。Slackwareの場合、OpenBSDと同じようにわざわざclang++使ってるけど全然問題無いっていうのが謎。

/bin/sh ../libtool --tag=CXX --mode=link clang++ -std=c++17 -O3 -Wno-deprecated -pedantic-errors -fvisibility=hidden -DMSGPACK_NO_BOOST -DMSGPACK_DISABLE_LEGACY_NIL -DMSGPACK_DISABLE_LEGACY_CONVERT -lopendht -lreadline -lfmt -L../src/.libs -lgnutls -lpthread -o dhtnode dhtnode.o

これは何事もなくビルドできる（Slackware上）。

ld: error: undefined symbol: dht::DhtRunner::getStorageLog() const
>>> referenced by dhtnode.cpp
>>> dhtnode.o:(cmd_loop(std::__1::shared_ptr<dht::DhtRunner>&, dht_params&))

えーと、どっちがどっちを呼ぼうとしてundefinedうんたらなんだっけー？と混乱中。

ん？
sbopkgでインストールできるOpenDHTは1.7.4か。現状の最新版は3.1.7だから随分古くないか…？

あと、opendht.SlackBuildでのコンフィギュレーションはこんな感じか。
cmake \
-DCMAKE_C_FLAGS:STRING="$SLKCFLAGS" \
-DCMAKE_CXX_FLAGS:STRING="$SLKCFLAGS" \
-DCMAKE_INSTALL_PREFIX=/usr \
-DOPENDHT_TOOLS=OFF \
-DCMAKE_BUILD_TYPE=Release ..

ライブラリだけ、ツール類のビルドは無し。あと、slack-descでは"OpenDHT is a C++11 Kademlia distributed hash table implementation."ということで、C++17じゃなくC++11前提にしてる（古いから？）。

OpenDHTのビルド、configure時のMsgPack_CFLAGS, MsgPack_LIBSの指定で進められるかと思ったけど、むしろCFLAGS, CXXFLAGSを適切に設定した方が良さそう。

って思ってたんだけど、やっぱtoolsのビルドで死にましたかー

@trondd @hfp wow, pkg_add's man says

%c Expands to the string "snapshots" when running a -current or -beta
kernel, or if the command line option -D snap | -D snapshot is
specified. Otherwise, %c expands to %v, which selects a release
version.

thanks!

@hfp 遅くなりました。PKG_PATHの設定でどうにかできました。ありがとうございます。

OpenDHT、--disable-python, --disable-toolsをconfigureに指定しないとビルドが完走しないんだけどどうしたもんだろう。

パッケージを作る上では--disable-pythonがあった方が良いというか今のところPython support考えてないのでそれで逃げたいんだけど流石に--disable-toolsはどーなのって気が。トラブった時の原因追求とかで困りそう。

OpenDHTのビルドが重いーおもいーくーそーおーもーいーーーーー

security/argon2
devel/asio
boostは要らないと思う

ケーキのイチゴは真っ先に食べるー。
あとは尖ってる方から食べてく。

という話をすると無性にショートケーキを食べたくなるな（最近のショートケーキ、ちょっとしたやつでも結構なお値段がするので気楽に食べるというよりも気合を入れて食べるものになってしまったのがとっても悲しい）。

OpenDHTビルドするのに必要だから欲しいんだよね、msgpack-cxx。って話も書いといた。流石にALSAじゃないからお塩な対応にはならないと思うけどｗ

ビルドしたオブジェクトを含むportsってのは今まで作ったことはあるけど、ヘッダだけのportsってのは流石に初めてなので勝手が分らぬ…なので、とりあえずそれっぽくできたのをぶん投げてご意見頂戴するのが手っ取り早いんだろうなあ。

okもらえりゃラッキーな精神で。

@hfp とりあえず-current上じゃなく7.4上で簡単に作業してみた（一旦これで投げてみる、怒られるの覚悟でｗ）

OpenBSD-7.5-betaなので、pkg_addするとOpenBSD/7.5/packages/amd64を見に行ってしまうんだけど…まだパッケージはOpenBSD/7.4の下なんだよなあ。もしくはsnapshot。どうやって拾ってきたものか…

msgpack-cxx(C++)ってヘッダのみなので、コンパイルって特にしないらしい…というのをどうやってパッケージ化するんだろう。

sun50iで独立させてるU-bootで、SUNXI_SETUP_REGULATORS=0にしたATFをリンクするよう、orange_pi_one_plusの定義を追加しないといけないという話なんだろう多分（状況の把握に時間かかってる）。

テストしてほしいってdiffが出てたのでてすとしよっかなーとボードかき集めたら、既にcommit済だった件。どうしようこれ。

おかしなことが起こった→それはおかしなことが起きている、なのでその時に対策すれば良いなのかも。対策せずに正しく動いているならそれで問題ない、という思想？

ドライバだとどの辺りまで「寛容」を認めるのかというのは気になる。errata対策は寛容さとは言わないだろうし…かといってがちがちに、「あ、予約されてるこのbitは0返すはずだけど1返したから落としますね」とまでやるかというとそうでもなかったし（今は違うんだろうか）。

過ちは人の常、赦すは神の技ってあるけど…別に神なんて大それたものじゃないとしても、どこまで許容するかって本当に難しいなって記憶はある。

（敢えてこっちに）やっぱ間違ってるものはまちがってるんでねーけ、と正面切って言う必要もあるんだろう。納得いかんものを抱えながら生きるというのもそれなりにストレスがたまるもんだし。

という訳で、こちらの（ちょっと喧嘩腰な）見解を添えた上で、どういうことか説明してもらうとしましょうか…

OpenBoxからでもDM-1801を認識させて、gd-77_firmware_loader.pyでの書き込みは問題なし。

OpenGD77(OpenDM1801)のMCUXpresso抜きなビルド、完了。パッチもここに。 https://github.com/jg1uaa/opengd77-noxpresso/blob/master/R20231231/opengd77-r20231231.diff

相変わらずcodec_interface.cの（codec blobの）バイナリ呼出し手順はアレなままだし、SPI周りのdata barrierが必要な箇所も直っちゃいない…多言語対応はFirmware Programmer側で言語ファイルを書き込むような形で対応するみたいなので、この作業を省けるのはありがたい。

リンカスクリプト自体に手が入ってるから、ここから直さないとダメか。

[LD ] firmware.axf
/usr/lib/gcc/arm-none-eabi/12.2.1/../../../arm-none-eabi/bin/ld:../linkerscripts/firmware_newlib.ld:109 cannot move location counter backwards (from 00055324 to 00054000)
collect2: error: ld returned 1 exit status
make: *** [../Makefile:226: firmware.axf] エラー 1

言語周りを見直す前にビルドを試みてはみたけど、なんかダメっぽいな。言語周りをどう抑え込んでみたものか…

codec_interface.c: 変わりなし→そのまま使える
SPI_Flash.c: 多少違ってる→多分使える

satellite.h エラー修正用のパッチ→現時点では修正済のため不要
uiLocalisation.h 内部構成が違う→作り直し

20230304版でいじったのがこれだから…
patching file firmware/Makefile
patching file firmware/include/functions/satellite.h
patching file firmware/include/user_interface/uiLocalisation.h
patching file firmware/linkerscripts/firmware_library_picolibc.ld
patching file firmware/linkerscripts/firmware_picolibc.ld
patching file firmware/source/dmr_codec/codec_interface.c
patching file firmware/source/hardware/SPI_Flash.c
patching file firmware/source/user_interface/uiLocalisation.c

> ./firmware/include/user_interface/languages/src/languages_builder.c
> ./firmware/source/functions/aprs.c
> ./firmware/source/interfaces/gps.c
> ./firmware/source/user_interface/menuAPRSOptions.c
> ./firmware/source/user_interface/menuCalibration.c
> ./firmware/source/user_interface/menuGPS.c

このへんがOpenGD77の20231231に追加されたファイルか。

arm@ に現状報告とdiff投げて、返答を待とう。

とりあえずPD14によるPHYのリセットができないとちゃんと動かないのは確かだしそれを強引に行うコードってのは随分前に作ってはいたんだけど…ボード固有ってのはあんまり美しくないし、DeviceTreeで（ドライバが認識できれば）きちんと処理できるって形の方が万人にとって幸せな解決策であることは間違いないから。

お願いしますよ、LinuxやU-bootでDevice Treeいじってる人達…！

刺さるなあ…自分もGentooのインストールできなかったからArch入れてるし…

とりあえず、これで出来上がりってことで良いけど…SUNXI_SETUP_REGULATORS=0（だったっけか、レギュレータの設定を無視するオプション）無しのATFでもPHYのリセットをちゃんとやってれば動くって話をどうまとめたらいいんだろう。

別途ATF分けないとダメって話で最初進めてたんだけど、まとめられる方が楽なのは確か。とはいえ、Armbianも確かパッチ当てたATFで動かしてるからここは分けたままで良いんじゃないの？で進めるか…