みつきんのメモ

組み込みエンジニアです。Interface誌で「Yocto Projectではじめる 組み込みLinux開発入門」連載中

YoctoProject bitbake-setupのGeneric Configuration

はじめに

以下の続き

bitbake-setupが参照するGeneric Configurationの内容を調べる。

Generic Configuration

Setupを作成するために参照されるファイルで、JSON形式で記述されている。 bitbake-setup initはGeneric Configurationを元にプロンプトを表示している。

bitbake-setup initはRegistoryから.conf.jsonの拡張子のファイルを探し設定を開始する。

bitbakeリポジトリではdefault-registoryに、デフォルトで使用可能なGeneric Configurationを提供している。

基本構造

Generic Configurationは以下の要素から構築されている。

以下にトップレベルの内容を抜粋する。

{
    "description": "Poky - The Yocto Project testing distribution",
    "expires": "2026-05-31",
    "sources": {
        ...
    },
    "bitbake-setup": {
        ...
    },
    "version": "1.0"
}

構成している要素を以下に示す。

要素 概要 必須
description コンフィグレーションの概要 o
expires 有効期限(YYYY-MM-DDTHH:MM:SS) x
sources Fetch対象のGitリポジトリ x
bitbake-setup コンフィグレーションのリスト o
version バージョン o

以下のような構造になる。

sources

ダウンロードしてくるデータのGitリポジトリを指定する。

{
   "sources": {
       "bitbake": {
           "git-remote": {
               "remotes": {
                   "origin": {
                       "uri": "https://git.openembedded.org/bitbake"
                   }
               },
               "branch": "master",
               "rev": "master"
           },
           "path": "bitbake"
       }
   }
}

構成している要素を以下に示す。

要素 概要 必須
uri git形式のURI o
rev チェックアウト対象のリビジョン o
branch チェックアウト対象のブランチ o
path ダウンロード先のディレクト x

revにブランチ名を指定した場合、そのブランチの最新を取得する。また、bitbake-setup updateしたタイミングで取得済みのソースが更新される。

以下のような構造になる。

bitbake-setup

Setupを作成するためにメインで参照される要素。bitbake-setupはこの設定を元にプロンプトを表示する。 1つ以上のconfigurationsの要素から構成される。configurationsは必要に応じて再帰的にネストすることができる。

以下はpoky-master.conf.jsonの例。

{
    "bitbake-setup": {
        "configurations": [
        {
            "bb-layers": ["openembedded-core/meta","meta-yocto/meta-yocto-bsp","meta-yocto/meta-poky"],
            "setup-dir-name": "$distro-master",
            "oe-fragments-one-of": {
                "machine": {
                    "description": "Target machines",
                    "options" : ["machine/qemux86-64", "machine/qemuarm64", "machine/qemuriscv64", "machine/genericarm64", "machine/genericx86-64"]
                },
                "distro": {
                    "description": "Distribution configuration variants",
                    "options" : ["distro/poky", "distro/poky-altcfg", "distro/poky-tiny"]
                }
            },
            "configurations": [
            {
                "name": "poky",
                "description": "Poky - The Yocto Project testing distribution"
            },
            {
                "name": "poky-with-sstate",
                "description": "Poky - The Yocto Project testing distribution with internet sstate acceleration. Use with caution as it requires a completely robust local network with sufficient bandwidth.",
                "oe-fragments": ["core/yocto/sstate-mirror-cdn"]
            }
            ]
        }
        ]
    },
}

各configurationを構成している要素を以下に示す。(抜粋)

要素 概要 必須
name コンフィグレーションの名前 o
description コンフィグレーションの概要 o
configurations ネストされたconfigurations x
bb-layers bblayers.confに追加されるレイヤのリスト x
setup-dir-name Setupディレクトリ名の提案 x
oe-fragments-one-of 選択可能なOE_FRAGMENTSのリスト x
oe-fragments OE_FRAGMENTS x

bb-layersの値は、各Setupのlayersディレクトリからの相対パスを指定する。

以下のような構造になる。

まとめ

Generic ConfigurationのJSONファイルの構造を調べた。

  • sourcesは取得するレイヤなどのリポジトリの情報
  • configurationsはプロンプトを表示するための情報
    • OE_FRAGMETNSやbblayers.confの値が決定される

要素の完全なリストはマニュアルを参照のこと。

YoctoProject bitbake-setup環境でmeta-raspberrypi

はじめに

以下の続き

bitbake-setupを使用した環境で、サードパーティのレイヤを追加する手順を試す。

今回はmeta-raspberrypiを使用する。

環境構築

作業ディレクト

~/yocto/poky-bsに作成したTop Directoryに、新たにSetupを追加する。

まずは作業ディレクトリに移動する。

$ cd ~/yocto/poky-bs

Setupの作成

"bitbake-setup init"でラズベリーパイ用のSetupを作成する。

$ ./bitbake/bin/bitbake-setup init \
--non-interactive poky-whinlatter poky distro/poky machine/qemuarm64 \
--setup-dir-name poky-whinlatter-rpi

--non-interactiveオプション

--non-interactiveオプションを使用すると、以下のような感じで、答えを記述しておくことでプロンプトをスキップすることができる。(試した感じでは順番はどうでも良さそう。)

--non-interactive <Generic Configuration> <bitbake configuration> <distro> <machine>

--setup-dir-name

--setup-dir-nameオプションを使用すると、Setupディレクトリの名前を明示的に指定することができる。

bitbake-setupのデフォルトのオプションでは、以下の順番で評価し同じものがある場合は次のものを提案してくる。

  1. 簡易名(Generic Configuraionと同じ)
  2. フルネーム(Generic Configuration + bitbake configuration + distro + machine )
  3. エラー終了

フルネームの例は「poky-whinlatter-poky-distro_poky-machine_qemuarm64」となる。 OE_FRAGMENTSの部分(MACHINEやDISTRO)がSetup名に入ると後から変更したときに整合性が取れなくなるので開発中では不便。

特に今回はMACHINEを書き換える前提の作業なのでフルネームにはしたくない。 そのため、--setup-dir-nameで「poky-whinlatter-rpi」を指定する。

BitBakeの環境設定

Setupに作成されたinit-build-envでBitBakeの環境を設定する。

$ source bitbake-builds/poky-whinlatter-rpi/build/init-build-env

meta-raspberrypiの追加

この時点でbitbake-layersなどのコマンドが使用可能になるので以下のようにmeta-raspberrypiを追加する。

$ bitbake-layers layerindex-fetch meta-raspberrypi -f ../layers

-f ../layersでSetup中のlayersディレクトリにダウンロード先を指定することがポイント

ブランチの問題

執筆時点(2025-11-30)ではmeta-raspberrypiにwhinlatterブランチが存在しないため以下のようなエラーになる。

Traceback (most recent call last):
  File "/home/mickey/yocto/poky-bs/bitbake-builds/poky-whinlatter-rpi-test/layers/bitbake/bin/bitbake-layers", line 109, in <module>
    ret = main()
  File "/home/mickey/yocto/poky-bs/bitbake-builds/poky-whinlatter-rpi-test/layers/bitbake/bin/bitbake-layers", line 104, in main
    return args.func(args)
  File "/home/mickey/yocto/poky-bs/bitbake-builds/poky-whinlatter-rpi-test/layers/bitbake/lib/bblayers/layerindex.py", line 138, in do_layerindex_fetch
    remoteIndex.load_layerindex(remoteurl)
  File "/home/mickey/yocto/poky-bs/bitbake-builds/poky-whinlatter-rpi-test/layers/bitbake/lib/layerindexlib/__init__.py", line 219, in load_layerindex
    indexEnt = plugin.load_index(indexURI, load)
  File "/home/mickey/yocto/poky-bs/bitbake-builds/poky-whinlatter-rpi-test/layers/bitbake/lib/layerindexlib/restapi.py", line 45, in load_index
    return self.load_index_web(up, url, load)
  File "/home/mickey/yocto/poky-bs/bitbake-builds/poky-whinlatter-rpi-test/layers/bitbake/lib/layerindexlib/restapi.py", line 216, in load_index_web
    logger.debug("No valid branches (%s) found at url %s." % (branch, url))
UnboundLocalError: local variable 'branch' referenced before assignment

これを回避するには-b masterとしてmasterブランチを指定する必要がある。 ただしmasterブランチを指定すると、依存関係の問題で何故かとても古い互換性のないレイヤを追加しようとするため 以下のような別のエラーが発生する。

ERROR: Variable BB_ENV_EXTRAWHITE has been renamed to BB_ENV_PASSTHROUGH_ADDITIONS (file: /home/mickey/yocto/poky-bs/bitbake-builds/poky-whinlatter-rpi-test/layers/openembedded-core/meta-yocto-kernel-extras/meta-kernel-dev/conf/layer.conf line: 12)
ERROR: Variable BB_DANGLINGAPPENDS_WARNONLY support for the variable was removed as it unconditionally affects all layers (file: /home/mickey/yocto/poky-bs/bitbake-builds/poky-whinlatter-rpi-test/layers/openembedded-core/meta-yocto-kernel-extras/meta-kernel-dev/conf/layer.conf line: 3)
ERROR: Parse failure with the specified layer added, exiting.

こちらのエラーはbitbake-layers add相当の処理が失敗しているだけなので、ダウンロード自体は成功している。

そのため、以下のような手順で作業すれば問題ない。

$ bitbake-layers layerindex-fetch meta-raspberrypi -f ../layers -b master
$ bitbake-layers add-layer ../layers/meta-raspberrypi

一応確認する。

$ bitbake-layers show-layers
... (snip) ...
layer                 path                                                                    priority
========================================================================================================
core                  /home/mickey/yocto/poky-bs/bitbake-builds/poky-whinlatter-rpi/layers/openembedded-core/meta  5
yoctobsp              /home/mickey/yocto/poky-bs/bitbake-builds/poky-whinlatter-rpi/layers/meta-yocto/meta-yocto-bsp  5
yocto                 /home/mickey/yocto/poky-bs/bitbake-builds/poky-whinlatter-rpi/layers/meta-yocto/meta-poky  5
raspberrypi           /home/mickey/yocto/poky-bs/bitbake-builds/poky-whinlatter-rpi/layers/meta-raspberrypi  9

これで問題ない。

MACHINEの変更

MACHINEをraspberrypi4-64に設定する。

$ bitbake-config-build enable-fragment machine/raspberrypi4-64

確認する。

$ bitbake -e | grep '^MACHINE='
MACHINE="raspberrypi4-64"

これでビルドが可能となる。

ビルド実行

$ bitbake core-image-minimal

site.confについて

bitbake-setupで作成されたsite.confにはDL_DIRの指定がされている。 つまり、すべてのSetupが自動的に同じダウンロードキャッシュを参照するようになっている。 これまでこの設定は手動で行う必要があったので地味に便利。

# This file is intended for build host-specific bitbake settings

# Where to place downloads
#
# During a first build the system will download many different source code
# tarballs from various upstream projects. This can take a while, particularly
# if your network connection is slow. These are all stored in DL_DIR. When
# wiping and rebuilding you can preserve this directory to speed up this part of
# subsequent builds. This directory is safe to share between multiple builds on
# the same machine too.
DL_DIR = "/home/mickey/yocto/poky-bs/bitbake-builds/.bitbake-setup-downloads"

まとめ

bitbake-setup環境でサードパーティのレイヤを追加する手順を試した。 以下の点が地味な便利ポイント

  • 最低限の手順ではlocal.confを一度も参照、変更しなくて良い
  • Setup間のDL_DIRの共有も意識せずに行われる
  • Setupに関して、削除しても新たに作成することが簡単

bitbake-setupは慣れれば便利だと思う。

YoctoProject bitbake-setupの基本

はじめに

YoctoProject bitbake-setupを試すの続き。

bitbake-setupを理解する上で必要となる基本的な要素について調べる。

基本構造

bitbake-setupで管理されるワークスペースは以下の様な構造になっている。

Top Directory
├── Site Configuration File
├── Setup 1/
├── Setup 2/
...

Top Directory

Top Directoryはbitbake-setupによって作成される作業場所の文字通りルートとなるディレクトリ。

Top Directoryには以下のものが存在する

  • Site Configuration File
  • 1つ以上のSetup

Site Configuration File

site.confという名前のファイルで、Top Directoryには1つ存在する。 これはbitbakeで参照されるsite.confと同じもので、すべてのSetupで同じものが参照される。

このファイルには使用するビルド環境の固有のプロキシ設定などワークスペース全体で共有したい設定を記述しておく。

Setup

bitbake-setup initで作成されたディレクトリで、実際のビルドに使用するメタデータやビルド環境を保持する。 つまり、Setup = BitBakeビルド環境 という対応づけとなる。

同じTop Directoryに対してbitbake initは複数回実行可能となっている。

Setupには以下のものが含まれている。

  • BitBake Build
  • Specific Configuration
  • Sources

BitBake Build

buildという名前のディレクトリで、BitBakeで使用されるビルドディレクトリ。

従来のビルドディレクトリと同等のものとなっており、conf/local.confconf/bblayers.confおよび、ビルド結果の生成物などが格納される。

Specific Configuration

configという名前のディレクトリでbitbake-setupが参照するための設定ファイルが格納される。

Sources

layersという名前のディレクトリで、ダウンロードされたbitbakeおよびレイヤのリポジトリが格納される。

bitbake-setupで管理される以外のレイヤもここに格納する。

作成された環境との対比

実際に作成された環境は以下のようになっている。上記の用語との対比は以下のようになる。

bitbake-builds/       => Top Directory
├── poky-whinlatter/  => Setup
│   ├── build/        => BitBake Build
│   ├── config/       => Specific Configuration
│   └── layers/       => Sources
└── site.conf         => Site Configuration File

bitbake-setupの設定

bitbake-setupの設定にはコマンドの振る舞いを設定するためのSettingsと、 bitbake-setupが環境を作成するために参照するConfigurationに分けることができる。

Settings

settings.confというファイルでINIファイル形式のテキストで記述する。

Top Directory毎に作成(Local settings)することもできるし、~/.config/bitbake-setup/settings.confのようにホームディレクトリにグローバルな設定として作成(Global settings)することもできる。

bitbake-setupのコマンドラインの引数で指定することもできる。

参照される順序としては以下のようになっている。

  1. Global settings
  2. Local settings
  3. コマンドライン引数

Configuration

Configurationには以下の2つがある。

  • Generic Configuration
  • Specific Configuration

Generic Configuration

Setupを作成するために参照されるファイルで、JSON形式で記述されている。 bitbake-setup initはGeneric Configurationを元にプロンプトを表示している。

  • 拡張子は.conf.json
  • Registoryに保存されている

bitbake-setup initはRegistoryから.conf.jsonの拡張子のファイルを探し設定を開始する。

bitbakeリポジトリではdefault-registoryに、デフォルトで使用可能なGeneric Configurationを提供している。 また、RegistoryはSettingsにより変更することもできる。

Specific Configuration

Setup毎に保存されるConfigurationで、Setup作成時に選択されたGeneric Configurationからの設定内容と、 その際にダウンロードされたSourcesのリポジトリの実際のリビジョンを格納している。

Registory

Generic Configurationを保存する場所の事で、ローカルストレージ上に存在しても良いし Webなどのネットワーク上に存在しても良い。

Registoryは以下のいづれかで指定することができる。

まとめ

bitbake-setupを理解する上で必要となる基本的な要素について調べた。

重要な項目は以下の3つ

  • Setup
  • Generic Configuration
  • Registory

YoctoProject bitbake-setupを試す

はじめに

Yocto Project Pokyリポジトリのmasterブランチの更新停止でPokyリポジトリのmasterブランチの更新が停止された後のPokyのセットアップ手順のうち下記について試す。

b) use the new bitbake-setup

     https://docs.yoctoproject.org/bitbake/dev/bitbake-user-manual/bitbake-user-manual-environment-setup.html

環境作成

作業ディレクト

~/yocto/poky-bsを作業ディレクトリとする。

$ mkdir -p ~/yocto/poky-bs
$ cd ~/yocto/poky-bs

リポジトリの取得

https://docs.yoctoproject.org/bitbake/dev/bitbake-user-manual/bitbake-user-manual-environment-setup.html の手順に従う。

bitbakeリポジトリを取得する。

$ git clone https://git.openembedded.org/bitbake

環境の設定

まずbitbake-setup initを実行する。

$ ./bitbake/bin/bitbake-setup init

以下のようなプロンプトが表示される。

Bitbake-setup is using /home/mickey/yocto/poky-bs/bitbake-builds as top directory.

/home/mickey/yocto/poky-bs/bitbake-builds looks like a new top directory. If you would like to use a different directory, answer "n" below and either:
        1) Change the default bitbake-setup settings:
                bitbake-setup settings set default top-level-prefix <PATH>
                bitbake-setup settings set default top-level-name <NAME>
        2) Pass one or more options on the command line to change the top level directory in that invocation only:
                bitbake-setup --setting default top-dir-prefix <PATH> ...
                bitbake-setup --setting default top-dir-name <NAME> ...

A common site.conf file will be created, please check it is correct before running builds
    /home/mickey/yocto/poky-bs/bitbake-builds/site.conf

Proceed? (y/N):

"y"としてEnter。コンフィグレーション選択のプロンプトが表示される。 (先週試したときはoe-nodistro-masterとpoky-masterしかなかったが増えてる。)

Available configurations:
1. oe-nodistro-master   OpenEmbedded - 'nodistro' basic configuration
2. poky-whinlatter      Poky - The Yocto Project testing distribution configurations and hardware test platforms, release 5.3 'whinlatter' (supported until 2026-05-31)
3. poky-master  Poky - The Yocto Project testing distribution configurations and hardware test platforms
4. oe-nodistro-whinlatter       OpenEmbedded - 'nodistro' basic configuration, release 5.3 'whinlatter' (supported until 2026-05-31)

Please select one of the above configurations by its number:

poky-whinlatter(YP5.3)を試したいので"2"としてEnterする。 bitbakeのコンフィグレーション選択のプロンプトが表示される。

Available bitbake configurations:
1. poky Poky - The Yocto Project testing distribution
2. poky-with-sstate     Poky - The Yocto Project testing distribution with internet sstate acceleration. Use with caution as it requires a completely robust local network with sufficient bandwidth.

Please select one of the above bitbake configurations by its number:

sstate無しのpokyを選択するため"1"としてEnter。 マシン選択のプロンプトが表示される。

Target machines:
1. machine/qemux86-64
2. machine/qemuarm64
3. machine/qemuriscv64
4. machine/genericarm64
5. machine/genericx86-64

Please select one of the above options by its number:

qemuarm64を選択したいので"2"としてEnter。 ディストリビューション選択のプロンプトが表示される。

Distribution configuration variants:
1. distro/poky
2. distro/poky-altcfg
3. distro/poky-tiny

Please select one of the above options by its number:

ノーマルのpokyを選択したいので"1"としてEnter。 セットアップディレクトリ名を訪ねてくる。

Run 'bitbake-setup init --non-interactive poky-whinlatter poky distro/poky machine/qemuarm64' to select this configuration non-interactively.

Enter setup directory name: [poky-whinlatter]

デフォルトで問題ないのでこのままEnter。(先週試した時は"poky-master-poky-distro_poky-machine_qemuarm64"とかすごい名前だった) 最終確認のプロンプトが表示される。

Initializing a setup directory in
    /home/mickey/yocto/poky-bs/bitbake-builds/poky-whinlatter
Continue? (y/N):

このままで良いので"y"としてEnterを押す。

Pokyを構成するためのレイヤのダウンロードが開始される。

Fetching layer/tool repositories into /home/mickey/yocto/poky-bs/bitbake-builds/poky-whinlatter/layers
    bitbake
    openembedded-core
    meta-yocto
    yocto-docs

セットアップが完了すると、必要な情報を表示してツールは終了する。

Setting up bitbake configuration in
    /home/mickey/yocto/poky-bs/bitbake-builds/poky-whinlatter/build

This bitbake configuration provides:
    Poky - The Yocto Project testing distribution

Usage instructions and additional information are in
     /home/mickey/yocto/poky-bs/bitbake-builds/poky-whinlatter/build/README

To run builds, source the environment using
    . /home/mickey/yocto/poky-bs/bitbake-builds/poky-whinlatter/build/init-build-env

Run 'bitbake-config-build enable-fragment <fragment-name>' to enable additional fragments or replace built-in ones (e.g. machine/<name> or distro/<name> to change MACHINE or DISTRO).

The bitbake configuration files (local.conf, bblayers.conf and more) can be found in
    /home/mickey/yocto/poky-bs/bitbake-builds/poky-whinlatter/build/conf

ビルド

BitBakeの環境設定

bitbake-setupを使用する場合は従来のoe-init-build-envではなく、作成された環境のbuildディレクトリにあるinit-build-envを実行してBitBakeの環境設定を行う。

$ source ./bitbake-builds/poky-whinlatter/build/init-build-env

ビルド設定の確認

MACHINEとDISTROの設定を確認する。

$ bitbake -e | grep '^MACHINE='
MACHINE="qemuarm64"
$ bitbake -e | grep '^DISTRO='
DISTRO="poky"

bitbake-setupのプロンプトで選択したとおりに設定されている。

ビルド

試しにcore-image-minimalをビルドする。

$ bitbake core-image-minimal

従来どおりビルドができる。

ビルド設定の変更

後からbitbake-setupで選択したMACHINEを変更したいケースは普通にあると思う。

local.confで変更する場合

試しにconf/local.confでMACHINEの設定を変更してみる。

$ echo 'MACHINE = "qemuriscv64"' >> conf/local.conf

一旦dry-runしてみる。すると下記のようなエラーが表示される。

$ bitbake -n
ERROR: A builtin fragment 'machine/qemuarm64' is used while MACHINE has already got an assignment.
Please either disable the fragment or remove the value assignment.
To disable the fragment, use 'bitbake-config-build disable-fragment machine/qemuarm64'.

このメッセージを要約すると以下のようになる。

  1. fragmentでmachine/qemuarm64が設定されているのでMACHINEは設定済み
  2. local.confの値を有効化したい場合はfragmentを無効化する必要がある
  3. fragmentの無効化はbitbake-config-buildコマンドで行う

以下のコマンドでfragmentを無効化してみる。

$ bitbake-config-build disable-fragment machine/qemuarm64
Fragment machine/qemuarm64 removed from /home/mickey/yocto/poky-bs/bitbake-builds/poky-whinlatter/build/conf/toolcfg.conf.

効果を確認する。

$ bitbake -n
Nothing to do.  Use 'bitbake world' to build everything, or run 'bitbake --help' for usage information.

エラーは出なくなったのでMACHINEの設定を確認する。

$ bitbake -e | grep '^MACHINE='
MACHINE="qemuriscv64"

これで変更できた。

OE_FRAGMENTSで変更する場合

bitbake-setupで作成した環境では初期状態でDISTROMACHINEについては新たに導入されたOE_FRAGMENTSで管理されている。 local.confで変更しようとした際にエラーが発生したのもこの仕組みと競合するからとなる。

OE_FRAGMENTSはconf/toolcfg.confで以下のように設定されている。

# Automated config file controlled by tools
#
# Run 'bitbake-config-build enable-fragment <fragment-name>' to enable additional fragments
# or replace built-in ones (e.g. machine/<name> or distro/<name> to change MACHINE or DISTRO).

OE_FRAGMENTS += "distro/poky machine/qemuarm64"

これはbitbake.confの以下の設定によりdistro/DISTROに、machine/MACHINEマッピングされるようになっている。

OE_FRAGMENTS_BUILTIN ?= "machine:MACHINE distro:DISTRO"

そのため以下の設定と同等の効果を持っている。

  • DISTRO = "poky"
  • MACHINE = "qemuarm64"

これを変更するにはbitbake-config-buildコマンドを使用する必要がある。

local.confやtoolcfg.confが初期状態である上で、以下のようにすることでMACHINEを変更する。

$ bitbake-config-build enable-fragment machine/qemuriscv64
NOTE: Starting bitbake server...
Fragment machine/qemuriscv64 added to /home/mickey/yocto/poky-bs/bitbake-builds/poky-whinlatter/build/conf/toolcfg.conf.

効果を確認する。

$ bitbake -e | grep '^MACHINE='
MACHINE="qemuriscv64"

これで変更できた。

まとめ

  • bitbake-setupはbitbakeリポジトリで提供されている
  • bitbake-initをすることで必要なレイヤをダウンロードし、プロンプトでビルド環境の初期設定を行う
  • bitbakeの環境設定はoe-init-build-envではなくinit-build-envを使う
  • DISTROとMACHINEはOE_FRAGMENTSで管理されている

基本的な使い方をする分にはマニュアル通りで良さそうだが、ブラックボックスが多いため、 応用するにはマニュアルをもう少しきちんと理解する必要がある。

所感としては、最初に試したバージョン(厳密は日付は忘れた)と本日(2025-11-29)のバージョンでかなりエラーメッセージや初期設定などの品質が上がっているので、もっと使いやすくなりそうな感じはしている。

Pokyのマニュアルセットアップ

はじめに

Yocto Project Pokyリポジトリのmasterブランチの更新停止でPokyリポジトリのmasterブランチの更新が停止された後のPokyのセットアップ手順のうち下記について試す。

a) switch to individual clones of bitbake, openembedded-core, meta-yocto and yocto-docs

   https://docs.yoctoproject.org/dev/dev-manual/poky-manual-setup.html

環境作成

作業ディレクト

~/yocto/poky-manualを作業ディレクトリとする。

$ mkdir -p ~/yocto/poky-manual
$ cd ~/yocto/poky-manual

リポジトリの取得

https://docs.yoctoproject.org/dev/dev-manual/poky-manual-setup.html の手順と全く同じ事をしてみる。

$ mkdir layers/
$ git clone -b yocto-5.2 https://git.openembedded.org/bitbake ./layers/bitbake
$ git clone -b yocto-5.2 https://git.openembedded.org/openembedded-core ./layers/openembedded-core
$ git clone -b yocto-5.2 https://git.yoctoproject.org/meta-yocto ./layers/meta-yocto

ディレクトリ構造

取得直後は以下のようになっている。layersディレクトリが(若干異なるが)以前のpokyディレクトリ相当になる。 meta-yoctoにはmeta-pokymeta-yocto-bspが含まれている。

poky-manual
└── layers
    ├── bitbake
    ├── meta-yocto
    └── openembedded-core

コミットログ

それぞれyocto-5.2のタグバージョンが取得されている。 もともとバージョン番号がPokyと連動していないbitbakeのリポジトリもPokyのバージョンでタグが打ってあるので、 使いたいバージョンのPoky環境が思ったよりも簡単に構築できる。

bitbake

commit 5b4e20377eea8d428edf1aeb2187c18f82ca6757 (HEAD, tag: yocto-5.2.1, tag: yocto-5.2, tag: 2025-04.1-walnascar, tag: 2025-04-walnascar, tag: 2.12.0)
Author: Richard Purdie <[email protected]>
Date:   Sat Mar 29 15:28:39 2025 +0000

    bitbake: Update version to 2.12.0 for release

    Signed-off-by: Richard Purdie <[email protected]>

openembedded-core

commit 6ec2c52b938302b894f119f701ffcf0a847eee85 (HEAD, tag: yocto-5.2, tag: 2025-04-walnascar, tag: 2025-04)
Author: Ross Burton <[email protected]>
Date:   Tue Apr 22 20:00:52 2025 +0100

    systemd: always depend on the explicit serial console units

    The systemd-serialgetty recipe generates explicit units for consoles
    that are defined in SERIAL_CONSOLES, and if that variable is not defined
    then just produces an empty package.

    Even when systemd has been configured to use the getty generator, if
    there are explicit consoles defined then we should respect them.  Don't
    conditionalise the dependency on systemd-serialgetty so that we always
    pull in the explicit consoles.

    Signed-off-by: Ross Burton <[email protected]>
    Signed-off-by: Richard Purdie <[email protected]>

meta-yocto

commit 09bef6a491c087f0f0371874e759aae08a720c4e (HEAD, tag: yocto-5.2, tag: yocto-5.0.9, tag: walnascar-5.2, tag: scarthgap-5.0.9)
Author: Mikko Rapeli <[email protected]>
Date:   Tue Apr 22 09:59:07 2025 +0300

    genericarm64.conf: increase INITRAMFS_MAXSIZE

    Since pmem kernel drivers were enabled as modules, the initrd
    size limit is hit. On genericarm64 all kernel modules and some
    firmware files get installed to initrd by default which make
    the thing large. I'm working on patches to reduce the kernel drivers
    installed to initrd and to make the kernel in general more modular
    (btrfs 5 Mb etc built into kernel by default). For now just increase
    the size limit to unblock genericarm64 builds and testing.

    Fixes: https://bugzilla.yoctoproject.org/show_bug.cgi?id=15833

    Signed-off-by: Mikko Rapeli <[email protected]>
    Signed-off-by: Richard Purdie <[email protected]>

環境変数の設定

おなじみのoe-init-build-envだが、meta-pokyのTEMPLATECONFを明示的に指定している。

$ TEMPLATECONF=$PWD/layers/meta-yocto/meta-poky/conf/templates/default source ./layers/openembedded-core/oe-init-build-env

ここでTEMPLATECONFを指定しない場合、openembedded-coreのTEMPLATECONFが使用されるので注意が必要。 opemembedded-coreのものを使用した場合以下のようになる。

  • BBLAYERSにopembedded-core(meta)のみになる
  • DISTRO設定がnodistroになる

重要 bblayers.confの修正

オフィシャルの手順をなぞっているのだが、実のところmeta-pokyのTEMPLATECONFを使用すると今回のディレクトリ構成ではエラーになる。

エラーを回避するために以下を実行する必要がある。

$ perl -pe 'BEGIN{$count=0} s/openembedded-core/++$count > 1 ? "meta-yocto" : $&/ge' conf/bblayers.conf > /tmp/tmpfile && cat /tmp/tmpfile > conf/bblayers.conf

もちろん、パスの辻褄が合うようにエディタで直接で編集しても良い。

TEMPLATECONFのbblayers.conf.sampleが以下のようになっているため、meta-pokyとmeta-yocto-bspが

# POKY_BBLAYERS_CONF_VERSION is increased each time build/conf/bblayers.conf
# changes incompatibly
POKY_BBLAYERS_CONF_VERSION = "2"

BBPATH = "${TOPDIR}"
BBFILES ?= ""

BBLAYERS ?= " \
  ##OEROOT##/meta \
  ##OEROOT##/meta-poky \
  ##OEROOT##/meta-yocto-bsp \

local.confの修正

MACHINEなど必要に応じて修正する。

$ echo 'MACHINE = "qemuarm64"' >> conf/local.conf

ビルド

ビルドは今までと同じ

$ time bitbake core-image-minimal

今回はtimeコマンドで時間計測

real    51m32.148s
user    1m35.292s
sys     0m7.959s

オフィシャルのsstate-cacheを試す

Tipという項目で以下の設定が紹介されている。

BB_HASHSERVE_UPSTREAM = "wss://hashserv.yoctoproject.org/ws"
SSTATE_MIRRORS ?= "file://.* http://sstate.yoctoproject.org/all/PATH;downloadfilename=PATH"
BB_HASHSERVE = "auto"
BB_SIGNATURE_HANDLER = "OEEquivHash"

BB_HASHSERVE_UPSTREAMで指定されているwssを処理するためにはpythonwebsocketsモジュールが必要となる。

$ pip3 install --user websockets

websocketではないので注意 ここが解決できないと下記のようなエラーが発生する。

ERROR: "Unable to use hash equivalence server at 'wss://hashserv.yoctoproject.org/ws' due to missing or incorrect python module:
ModuleNotFoundError("No module named 'websockets'")
Please install the needed module on the build host, or use an environment containing it (e.g a pip venv or OpenEmbedded's buildtools tarball).
You can also remove the BB_HASHSERVE_UPSTREAM setting, but this may result in significantly longer build times as bitbake will be unable to reuse prebuilt sstate artefacts.

ここまで解決した上でbitbakeを実行する。

$ time bitbake core-image-minimal

以下のような結果になる。

real    61m22.357s
user    1m16.911s
sys     0m7.017s

これは筆者のセミナーなどで質問があるたびに「日本からだとそこまでの時間短縮は期待できない」回答をしているがその解釈とおそらく一致している。 日本にミラーサーバがあり、そちらを参照するなどのワークアラウンドがあれば、きっと効果はある。

これはハッシュサーブに効果がないと言うことではなく、ローカルネットワークなどにsstate-cache及びハッシュサーバを構築すると 劇的にビルド時間が短くなるのは確認済みなので、距離が遠いサーバでは思うほど効果はないということ。

まとめ

Pokyリポジトリのmasterブランチが更新停止になった後のビルドの代替手順のうちの1つを試した。 ただ、ドキュメントどおりにやっても基礎的な知識がないとワークアラウンドできないだろうということがわかった。

まだ移行過程が始まったばかりなので仕方がない。 今後、ドキュメントもテンプレートも整備されることを期待している。

Yocto Project Pokyリポジトリのmasterブランチの更新停止

はじめに

今までYocto ProjectのリファレンスビルドシステムであるPokyのリリースに使用されていた Pokyリポジトリのmasterブランチの更新が停止された。

The poky repository master branch is no longer being updated.

You can either:

a) switch to individual clones of bitbake, openembedded-core, meta-yocto and yocto-docs

   https://docs.yoctoproject.org/dev/dev-manual/poky-manual-setup.html

b) use the new bitbake-setup

     https://docs.yoctoproject.org/bitbake/dev/bitbake-user-manual/bitbake-user-manual-environment-setup.html

You can find more information in our documentation: https://docs.yoctoproject.org/

Note that "poky" the distro setting is still available in meta-yocto as
before and we continue to use and maintain that.

Long live Poky!

これの詳細は下記。

[PATCH] The poky repository master branch is no longer being updated.

Pokyの開発が停止するわけではないのでご安心を。

経緯については以下のメールに詳細が記載されている。

bitbake-setup - Background and details/FAQ

概要

まずPokyリポジトリの説明の前にビルドシステムとしてのPokyの構成要素について説明する。

  • OpenEmbedded-Core(OE-Core)
  • BitBake
  • meta-poky
  • meta-yocto-bsp
  • ドキュメント

この内OpenEmbedded-CoreとBitBakeはもともとOpenEmbeddedプロジェクトが開発をしており、 2010年からYocto Projectと共同で開発・メンテナンスを行ってきた。

上記それぞれについては独立したリポジトリで管理されていたが、Yocto Projectの成果物であるPokyをユーザーが簡単に利用できる(Pokyリポジトリからcloneすればすぐに使い始められる)ようにするためにPokyリポジトリを作成し、これらをひとまとめにするという作業を行っていた。

* commit 6a80352d51bd2cf141b0dc4dd946d1b131ed94a7
| Author: Steve Sakoman <[email protected]>
| Date:   Tue Dec 10 05:48:31 2024 -0800
|
|     poky.conf: bump version for 5.0.6
|
|     (From meta-yocto rev: e9b828fdf46d3b3ad6ccd51710845bdfd29357bb)
|
|     Signed-off-by: Steve Sakoman <[email protected]>
|

コミットログをみてわかるとおり、それぞれのupstreamのリポジトリのコミットをいちいちPokyリポジトリに取り込むという作業は結構な手間であるはず。

At developer meetings there are inevitable questions about why poky/combo-layer exist and few seem to actually like/support it.

実際に当初から評判は良くはなかったらしい。

今では複数のgitリポジトリを一括で管理するツールとしてkasやrepoが思いつくが、

kas didn't exist, I think repo was only just created and it was a different world.

2011年当時はkasはなかったし、repo世に出たばかりでYocto Projectとは別世界のものだったらしい。

更新停止の理由

「更新を停止しなければならない明確な理由はない」けど、「ユーザーは古いものが利用可能である限り、新しいものを使おうとしない。」ので更新停止に踏み切ったとのこと。

we don't have to stop maintaining the poky repository however nobody will test the new approach/code unless we do

「古いもの」はコピーが必須な管理体制であるPokyリポジトリのことで、 「新しいもの」は今回Pokyリポジトリを不要にするための「bitbake-setup」のこと。

The LTS branches continue their lifetime as planned.

LTSのブランチは存続するとのこと。

If we're going to make a change, we really want this in the next LTS release, which is April 2026.

また、本格的にbitbake-setupを含めて、Pokyリポジトリを利用しない手順を標準とするまでには 2026年の4月のリリースまで猶予があるとのこと。現時点ではmasterブランチを使う必要があるユーザー以外には直接的な影響はないはず。

とはいえ、bitbake-setupを積極的に使って、不具合とか不満なところとか積極的にレポートしてほしいに違いない。 (もちろん良いところも)

まとめ

本稿は抜粋かつ意訳を含んでいるので、正確な情報はbitbake-setup - Background and details/FAQを参照すること。

Yocto Project 標準SDKのGoについて

はじめに

Yocto Project 4.1(Langdale)からSDK_TOOLCHAIN_LANGSが追加され、 標準SDKにRustやGoのツールチェーンを含むことができるようになった。

執筆時点ではGoについては少し?問題があるので紹介する。

標準SDKへのGoの追加

作成手順

local.confに以下の内容を追加する。

SDK_TOOLCHAIN_LANGS = "go"

標準SDKをビルドする。

$ bitbake core-image-minimal -c populate_sdk

問題点

go-cross-canadianのエラー

MACHINEがqemuarm64などの場合に以下以下のようなビルドエラーが発生する。

ERROR: go-cross-canadian-aarch64-1.22.8-r0 do_install: ExecutionError('/home/mickey/yocto/scarthgap/build/tmp/work/x86_64-nativesdk-pokysdk-linux/go-cross-canadian-aarch64/1.22.8/temp/run.do_install.1151458', 1, None, None)
ERROR: Logfile of failure stored in: /home/mickey/yocto/scarthgap/build/tmp/work/x86_64-nativesdk-pokysdk-linux/go-cross-canadian-aarch64/1.22.8/temp/log.do_install.1151458
... (snip) ...
ERROR: Task (/home/mickey/yocto/scarthgap/poky/meta/recipes-devtools/go/go-cross-canadian_1.22.8.bb:do_install) failed with exit code '1'

go-cross-canadianのdo_installタスクでエラーになっている。

原因

GO_BUILD_BINDIRが期待しているディレクトリ構成と、実際のディレクトリ構成が食い違うため発生する問題らしい。

do_install() {
    install -d ${D}${libdir}/go/pkg/tool
    cp --preserve=mode,timestamps -R ${B}/pkg/tool/${HOST_GOTUPLE} ${D}${libdir}/go/pkg/tool/
    install -d ${D}${bindir} ${D}${libdir}/go/bin
    for f in ${B}/${GO_BUILD_BINDIR}/*
    do
        base=`basename $f`
        install -m755 $f ${D}${libdir}/go/bin
        make_wrapper $base ${TARGET_PREFIX}$base
    done
}

この問題はYocto Project 5.2(Walnascar)まで修正されていない。

修正コミット

下記のコミットで修正されている。

commit a669cd2e0c760da9d7e872daea9590fc9e86d766
Author: Osama Abdelkader <[email protected]>
Date:   Tue Aug 12 22:50:50 2025 +0200

    go-cross-canadian: fix binaries install and GOARCH

    set GOARCH to HOST_GOARCH which is set from SDKMACHINE,
    since GOARCH defaults to TARGET_GOARCH, which is set from MACHINE (wrong arch).

    Also fix do_install to correctly install all binaries from
    ${GO_BUILD_BINDIR} by using 'find -type f' to avoid issues when the
    directory contains subdirectories (e.g. "linux_arm").

    (From OE-Core rev: 31e3bd61c7986bc044e547aa5cb9caba7b32bf22)

    Signed-off-by: Osama Abdelkader <[email protected]>
    Signed-off-by: Mathieu Dubois-Briand <[email protected]>
    Signed-off-by: Richard Purdie <[email protected]>

修正内容は以下のようになっている。

diff --git a/meta/recipes-devtools/go/go-cross-canadian.inc b/meta/recipes-devtools/go/go-cross-canadian.inc
index 39330fc98b..4a6f2f4c36 100644
--- a/meta/recipes-devtools/go/go-cross-canadian.inc
+++ b/meta/recipes-devtools/go/go-cross-canadian.inc
@@ -5,6 +5,8 @@ DEPENDS = "go-native virtual/${HOST_PREFIX}go virtual/nativesdk-${HOST_PREFIX}go
            virtual/nativesdk-compilerlibs"
 PN = "go-cross-canadian-${TRANSLATED_TARGET_ARCH}"

+GOARCH = "${HOST_GOARCH}"
+
 # it uses gcc on build machine during go-cross-canadian bootstrap, but
 # the gcc version may be old and not support option '-fmacro-prefix-map'
 # which is one of default values of DEBUG_PREFIX_MAP
@@ -51,7 +53,7 @@ do_install() {
        install -d ${D}${libdir}/go/pkg/tool
        cp --preserve=mode,timestamps -R ${B}/pkg/tool/${HOST_GOTUPLE} ${D}${libdir}/go/pkg/tool/
        install -d ${D}${bindir} ${D}${libdir}/go/bin
-       for f in ${B}/${GO_BUILD_BINDIR}/*
+       for f in $(find ${B}/${GO_BUILD_BINDIR} -type f)
        do
                base=`basename $f`
                install -m755 $f ${D}${libdir}/go/bin

この修正によりビルドエラーは回避できるようになった。

動作確認

ビルドされた標準SDKをインストールしたあと下記を実行してみると、ホストPCのコマンドが見つかる。

$ source /opt/poky/5.2.99+snapshot/environment-setup-cortexa57-poky-linux
$ which go
/snap/bin/go

SDK内でgoコマンドを検索してみると見つかりはする。どうやらパスに含まれていない場所に配置されているようだ。

$ find $OECORE_NATIVE_SYSROOT -name go
/opt/poky/5.2.99+snapshot/sysroots/x86_64-pokysdk-linux/usr/lib/aarch64-poky-linux/go
/opt/poky/5.2.99+snapshot/sysroots/x86_64-pokysdk-linux/usr/lib/aarch64-poky-linux/go/bin/go

フルパス指定で実行してみる。

$ /opt/poky/5.2.99+snapshot/sysroots/x86_64-pokysdk-linux/usr/lib/aarch64-poky-linux/go/bin/go -h | head
Go is a tool for managing Go source code.

Usage:

        go <command> [arguments]
... (snip) ...

コマンドは実行可能なようなので試しにサンプルをビルドしてみる。以下の内容でhello.goを作成する。

package main

import "fmt"

func main() {
    fmt.Println("hello world")
}

ビルドする。

$ export PATH=$OECORE_NATIVE_SYSROOT/usr/lib/aarch64-poky-linux/go/bin/go:$PATH
$ go build hello.go
hello.go:3:8: package fmt is not in std (/opt/poky/5.2.99+snapshot/sysroots/x86_64-pokysdk-linux/usr/lib/aarch64-poky-linux/go/src/fmt)
package command-line-arguments: cannot find package

GOROOTに標準的なライブラリが見つからないらしい。

$ go env GOROOT
/opt/poky/5.2.99+snapshot/sysroots/x86_64-pokysdk-linux/usr/lib/aarch64-poky-linux/go
$ ls /opt/poky/5.2.99+snapshot/sysroots/x86_64-pokysdk-linux/usr/lib/aarch64-poky-linux/go
bin  pkg

ほぼ何もない。

まとめ

執筆時点(2025/10/29)でリリース済みのYocto Projectではx86系以外のプラットフォームの標準SDKでGoのツールチェーンを含めようとするとビルドエラーになる。 masterブランチには修正がすでに取り込まれているので次回リリース予定の5.3(Whinlatter)では反映されている可能性が高い。

ただし、標準SDKのsysrootにはgoのバイナリしか入らず、実行に必要な以下の処理が実施されないため実質何もできない。

  1. goコマンドのPATHへの追加
  2. GOOSやGOARCHなどのクロスコンパイルに必要な設定
  3. GOROOTへのsrcなど必要なファイルのインストール

特に3が致命的で、クロスコンパイルどころかコンパイルに必要なものが足りていないようだ。