コグノスケ

AVIFの変換

AVIFが読めないアプリケーションがたまにあるので、AVIF（AV1 Image File Format）画像をJPEGなど他の形式に変換する方法をメモしておきます。AVIFが変換できるなら別に何でも良いのですが、今回はImageMagickを使用します。

AVIFとは何かというと、まずMPEG系のHEICというのがあります。HEIF（High Efficiency Image File Format）コンテナにHEVC（High Efficiency Video Coding, ISO/IEC 23008-2 HEVC, ITU-T H.265）で圧縮した画像を格納したファイル形式を指します。AVIFはHEIFコンテナを流用して、HEVCの代わりにAV1（Alliance for Open Media Video 1）で圧縮した画像を格納したファイル形式です。まとめたらこんな感じです。

AOMedia（Alliance for Open Mediaを略したもの）を含む、非MPEG系の陣営はWebMというMatroskaベースのコンテナを使うことが多いです。でもAVIFはHEIFを使うんですよね。動画系コーデックは大抵MPEG系のMP4（ISO/IEC 14496-12, 14 MP4ファイルフォーマット）コンテナに対応していますし、MPEG系コンテナを使うこと自体は変ではないですが……。WebPの策定が遅れたらしく、AVIFが先に流行っちゃったのは面白いなと思います。

ビルド＆実行

ビルド前の準備です。AVIFはHEIFというコンテナを使っていますので、HEIFを扱うためのライブラリをインストールしておきます。

# apt-get install libheif-dev

ImageMagickのソースコードはGitHubにあるので、cloneしてきてビルドします。

$ git clone https://github.com/ImageMagick/ImageMagick
$ cd ImageMagick
$ mkdir build
$ cd build
$ ../configure
$ make

AVIFを扱えるかどうかはconfigureログのHEICの行に表示されます。

Delegate library configuration:
  BZLIB             --with-bzlib=yes                    yes
  Autotrace         --with-autotrace=no                 no
  DJVU              --with-djvu=yes                     no
  DPS               --with-dps=no                       no
  FFTW              --with-fftw=no                      no
  FLIF              --with-flif=no                      no
  FlashPIX          --with-fpx=no                       no
  FontConfig        --with-fontconfig=yes               yes
  FreeType          --with-freetype=yes                 yes
  Ghostscript lib   --with-gslib=no                     no
  Graphviz          --with-gvc=yes                      no
  HEIC              --with-heic=yes                     yes  ★yesになっていればOK
  JBIG              --with-jbig=yes                     yes
  JPEG v1           --with-jpeg=yes                     yes
  JPEG XL           --with-jxl=yes                      no
...

下記のように実行します。

./magick.sh ./utilities/magick hato.avif hato.jpg

ビルドに失敗していると、no decode delegate for this imageというメッセージが出て怒られます。

magick: no decode delegate for this image format `AVIF' @ error/constitute.c/ReadImage/746.

このメッセージが出るときは先ほど紹介したconfigureのログを確認してみてください。

ROCK 3Cの青色LED点滅を止める

目次: Arduino

ゲーミングマシンの流行により、最近のコンピュータは意味もなくビカビカ光って点滅しています。個人的にはマザーボードや電源が七色に光る意味が全く見出せません……。電気を無駄にしてる感があります。

しかし組み込み機器の場合は話が別です。画面出力やUARTなどが確認できる機器なら状態がわかりやすいですが、外部出力に乏しい機器は動いているかどうかよくわかりませんので、生存確認方法の1つとしてLEDを交互に光らせる（もしくは点滅させる）というのは現代でも割と見かける方法です。

先日購入したROCK 3Cも生存確認で青色LEDが点滅するようになっています。ドライバで実装しているようで点滅が鬱陶しいなら、

$ sudo rmmod ledtrig_heartbeat

とすると点滅が止まります。二度と点滅しなくて良ければ/etc/modules-load.d/modules.confを編集してledtrig-から始まる4行を全てコメントアウトすれば良いです。ただし青色LEDは消灯ではなく常時点灯になってしまいます。消灯させる方法は、

# echo 0 > /sys/class/leds/user-led1/brightness

もっとスマートに消灯させる方法はあるんだろうか……？

SDIの一覧

聞かれてぱっと思い出せなかったのでSDI（Serial Digital Interface）の規格一覧をメモしておきます。

SDIはデジタル動画の送信に使われるインタフェースです。SMPTE（The Society of Motion Picture and Television Engineers）という団体が規格を定めています。英語圏だと「シンプティ」みたいに発音するらしいですが、日本では聞いたことないです。

• SMPTE ST 259M: SD-SDI、SDTV画質（例: NTSC/PAL）、143/177/270/360Mbps
• SMPTE ST 292M: HD-SDI、HDTV画質（例: 1080i59.94, 720p59.94）、1.485Gbps
• SMPTE ST 424M: 3G-SDI、プログレッシブHD（例: 1080p59.94）、2.97Gbps
• SMPTE ST 2081: 6G-SDI、4K解像度（例: 4K 29.97p）、6Gbps
• SMPTE ST 2082: 12G-SDI、4K解像度（例: 4K 59.94p）、12Gbps

SMPTEの仕様書の一覧はSMPTEのサイト（Standards Index - Society of Motion Picture & Television Engineers）にあります。ST 2081は見つかりますけど、それ以前の古い規格は見当たらないですね？別のところにあるんでしょうか。

Docker pullするときにプロキシを使う

目次: 自宅サーバー

Dockerの設定はいつも忘れますね。メモしておきます。

企業内ネットワークなど、Docker pullでイメージをダウンロードしてくるときにプロキシを参照したいときがあります。systemdの設定で指定できるようです。

#/etc/systemd/system/docker.service.d/http-proxy.conf

[Service]
Environment="http_proxy=http://192.168.1.1:8080/"
Environment="https_proxy=http://192.168.1.1:8080/"

この設定ファイルが存在しないときは、ディレクトリと設定ファイルを作成してください。反映方法は、

# systemctl daemon-reload
# systemctl restart docker.service

確認方法は、

# systemctl status docker.service

docker.service - Docker Application Container Engine
    Loaded: loaded (/lib/systemd/system/docker.service; enabled; vendor preset>
    Drop-In: /etc/systemd/system/docker.service.d
             `- http-proxy.conf    ★Drop-Inの行が出現していればOK

設定ファイルの場所がややこしい以外はそんなに難しくないですね。

cntlmを経由してプロキシを使用する

目次: 自宅サーバー

プロキシのアドレスが拠点やゾーンによって異なる場合があります。プロキシを使用するサービスが1つならそのサービスの設定ファイルを書き換えれば良いのですが、サービスが複数ある場合は各サービスのプロキシ設定を全て書き換えて回る必要があって面倒です。

このようなときはcntlm（Cntlm Authentication Proxy - SourceForge.net）にてローカルにプロキシを置くと便利です。各サービスは常にcntlmをプロキシとして設定しておけば良く、cntlmの設定ファイルを書き換えるだけでプロキシ設定の変更に対応できます。

このときの通信経路は[各サービス] - [cntlm] - [プロキシ] - [インターネット]となります。

ちなみにcntlmは認証やトンネリングに対応している高機能なプロキシで、設定もたくさんあります。が、プロキシの中継をするだけなら設定は2行です。

#/etc/cntlm.conf

Proxy		192.168.1.1:8080

...

Listen		172.17.0.1:3128

反映方法は、

# systemctl restart cntlm.service

確認するときは、環境変数にcntlmのListenに指定したアドレスとポートを設定し、プロキシを必要とするソフトウェアが正常に動作するか見ると良いでしょう。

$ export http_proxy="172.17.0.1:3128"
$ export https_proxy="172.17.0.1:3128"

$ (httpを使用するコマンド、curlなどが動作することを確かめる)

各サービスのプロキシ設定も同様です。例えばDockerなら、

#/etc/systemd/system/docker.service.d/http-proxy.conf

[Service]
Environment="http_proxy=http://172.17.0.1:3128/"
Environment="https_proxy=http://172.17.0.1:3128/"

こんな感じです。Dockerのプロキシ設定、確認方法は以前（2024年5月13日の日記参照）紹介したのでそちらをご覧ください。

イマドキ？のlocale設定方法

目次: 自宅サーバー

Localeの設定方法は未だによくわかってないのですが、最近ROCK 3CのDebian 11 (bullseye)でLocaleを設定したときの方法をメモしておきます。

# localedef -i /usr/share/i18n/locales/ja_JP -f UTF-8 /usr/lib/locale/ja_JP.UTF-8
# localedef --add-to-archive /usr/lib/locale/ja_JP.UTF-8
# localectl set-locale LANG=ja_JP.UTF-8

これで切り替わりました。作成、登録、選択という感じ？です。Cロケールに戻すときはLANG=C.UTF-8です。

タイムゾーンの設定方法

一緒に変えたくなるであろうタイムゾーンの設定方法も書いておきます。

# timedatectl set-timezone Asia/Tokyo

作成や登録の手間はなく簡単です。UTCに戻すときはEtc/UTCと指定します。注意点として、

# timedatectl set-timezone asia/Tokyo
Failed to set time zone: Invalid or not installed time zone 'asia/Tokyo'

タイムゾーン名は大文字小文字を区別するのでTypoにご注意ください。私は最初asia/Tokyoと打っているのに気づかずエラーになって困惑しました……。

TwitterがXに置換された

今日？あたりからtwitter.comにアクセスするとx.comにリダイレクトされるようになりました。twitter.comとの違いとしては、x.comはFirefoxにてTracking contentをブロックしているとこんなエラーが出て全く使えません。

Tracking contentをブロックしたときのx.comのエラー

エラーを回避するにはEnhanced Tracking ProtectionのException設定にx.comを追加します。

Tracking contentの設定変更

そんなにトラッキングしたいんですかね？x.comはイケてないな……。

ツイート内容の置換

Xは以前からTwitterという文字を滅ぼしたがっているようで、先月辺り（？）からツイートにあるtwitter.comをx.comに置換するようになりました。そのせいで下記のようにx.comとtwitter.comという文字が両方入っているニュースがおかしなことになっています。

twitter.comをx.comに置換したためにツイートと代替テキストが食い違う様子

しかも画像の代替テキストは置換が行われないため、ツイートと画像の代替テキストが食い違うおかしな現象まで発生しています。twitter.comというドメインを手放さない限り、どうせリダイレクトするのであれば一括置換する必要なかったんじゃないの……？手放したら手放したで悪用されまくると思いますし。

Yocto - まとめリンク

目次: Yocto

• Hello Yocto
• Yoctoのセットアップスクリプトとビルドディレクトリ
• Yoctoのビルドディレクトリとテンプレートディレクトリ
• Bitbakeのレイヤー
• Bitbakeのクラス

Linux 6.1からLinux 6.6に手抜き更新したらハマった

目次: 自宅サーバー

Linux Kernelのlongtermバージョンが代替わりしてからしばらく経ちますが、更新をサボりにサボっていました。重い腰を上げて自宅サーバーのLinux 6.1をLinux 6.6に更新したところ、起動しなくなりました。悲しい。

Linux 6.1に戻せば起動しますからHWの故障などではないです。Kernelコンフィグが悪さをしていそうで、ドライバの有無を色々疑ったんですが、結果的にはCONFIG_UNIXがtristate（設定値にy/n/mを取れる）からbool（設定値にy/nを取れる）が原因でした。こんな経緯で起動しなくなったと思われます。

• ある時点（※）でCONFIG_UNIXをmにできなくなった
• menuconfigはCONFIG_UNIX=mにできないので、CONFIG_UNIX=nにする
• Unixドメインソケットが使えないKernelが爆誕
• 何ひとつ（systemdすら）起動できない

CONFIG_UNIX=mにできなくなったことなんて知りませんでした。気づけたのはmake oldconfigのおかげです。

# make oldconfig

.config:917:warning: symbol value 'm' invalid for UNIX    ★★エラーが出ている★★
*
* Restart config...
*
*
* Configure standard kernel features (expert users)
*
Configure standard kernel features (expert users) (EXPERT) [N/y/?] n
  Load all symbols for debugging/ksymoops (KALLSYMS) [Y/?] y
    Test the basic functions and performance of kallsyms (KALLSYMS_SELFTEST) [N/y/?] (NEW)

私がいつもやっている手順ですと

• 古いLinux Kernelのconfigを新しいLinux Kernelにコピー
• make menuconfig

こんな感じなので、最初はCONFIG_UNIX=mに対するエラーに全く気づいていませんでした。もしmake oldconfigが存在しなかったら迷宮入りしていたと思います。

どこで変わったのか？

せっかくなので仕様が変更されたポイントを調べます。git annotateでnet/unix/Kconfigを見て、変更のもとになったコミットを調べます。コミットログは下記です。

commit 97154bcf4d1b7cabefec8a72cff5fbb91d5afb7b
Author: Alexander Mikhalitsyn <alexander@mihalicyn.com>
Date:   Thu Jun 8 22:26:28 2023 +0200

    af_unix: Kconfig: make CONFIG_UNIX bool

    Let's make CONFIG_UNIX a bool instead of a tristate.
    We've decided to do that during discussion about SCM_PIDFD patchset [1].

    [1] https://lore.kernel.org/lkml/20230524081933.44dc8bea@kernel.org/

...以下略...

このコミットが本線に取り込まれたのはLinux 6.5みたいです。

$ cd linux
$ git log v6.4...v6.5 | grep 97154bcf4d1b7

commit 97154bcf4d1b7cabefec8a72cff5fbb91d5afb7b

ちなみにLinux 6.1の次のLongterm kernelはLinux 6.6ですから、今日でなくてもいつか私はこの問題にハマる運命だったと言えましょう……。