問題タブ [bitbake]

複数のパッケージを作成する単一の Bitbake レシピがあり、PACKAGES 変数を使用して宣言し、FILE_package1、FILE_package2 などを使用して各パッケージの内容を指定します。

パッケージごとに異なるバージョン文字列を指定したいのですが、それらはすべて ${PV} に格納されているバージョン文字列を共有しています。パッケージごとに異なるバージョンを提供するにはどうすればよいですか?

複数のパッケージに分割して適用したいと思います。基本的に、特定のイメージを使用してビルドできる別のものを追加したいと思います。

追加したアプリケーションに関連付けられた .bb ファイル内:

次に、bb 画像テストに次の行を追加しました

次を返すコマンド bitbake image-test を使用しています。

bluez5-obex パッケージと IMAGE_ISTALL += " bluez5-obex" の同じ定義に従いました。

私は何を忘れますか？

Galileo BSP の Yocto 部分を動かそうとしています。

ソース ./iot-devkit-init-build-env yocto_build

しかし、私はbitbakeを実行します

bitbake イメージフル

33個の失敗したタスクが返されます

概要: 33 個のタスクが失敗しました:
virtual:native:/home/mark/meta-clanton_v1.1.0-dirty/meta/recipes-support/sqlite/sqlite3_3.8.3.1.bb、do_fetch
virtual:native:/home/mark/meta -clanton_v1.1.0-dirty/meta/recipes-extended/bzip2/bzip2_1.0.6.bb, do_fetch
/home/mark/meta-clanton_v1.1.0-dirty/meta/recipes-devtools/quilt/quilt-native_0.61.bb , do_fetch
virtual:native:/home/mark/meta-clanton_v1.1.0-dirty/meta/recipes-kernel/cryptodev/cryptodev-linux_1.6.bb, do_fetch
/home/mark/meta-clanton_v1.1.0-dirty/meta /recipes-core/eglibc/eglibc-initial_2.19.bb, do_fetch
virtual:native:/home/mark/meta-clanton_v1.1.0-dirty/meta/recipes-devtools/elfutils/elfutils_0.155.bb, do_fetch
virtual:native:/home/mark/meta-clanton_v1.1.0-dirty/meta/recipes-extended/xz/xz_5.1.3alpha.bb, do_fetch
virtual:native:/home/mark/meta-clanton_v1.1.0-dirty/ meta/recipes-support/mpfr/mpfr_3.1.2.bb、do_fetch
virtual:native:/home/mark/meta-clanton_v1.1.0-dirty/meta/recipes-core/zlib/zlib_1.2.8.bb、do_fetch
virtual:native :/home/mark/meta-clanton_v1.1.0-dirty/meta/recipes-support/libmpc/libmpc_1.0.2.bb, do_fetch
virtual:native:/home/mark/meta-clanton_v1.1.0-dirty/meta/recipes- devtools/kconfig-frontends/kconfig-frontends_3.12.0.0.bb, do_fetch
virtual:native:/home/mark/meta-clanton_v1.1.0-dirty/meta/recipes-extended/pigz/pigz_2.3.1.bb, do_fetch
virtual:native:/home/mark/meta-clanton_v1.1.0-dirty/meta/recipes-devtools/file/file_5.16.bb, do_fetch
virtual:native:/home/mark/meta-clanton_v1.1.0-dirty/meta /recipes-connectivity/openssl/openssl_1.0.1g.bb, do_fetch
virtual:native:/home/mark/meta-clanton_v1.1.0-dirty/meta/recipes-devtools/gnu-config/gnu-config_20120814.bb, do_fetch
virtual :native:/home/mark/meta-clanton_v1.1.0-dirty/meta/recipes-support/gmp/gmp_5.1.1.bb, do_fetch
virtual:native:/home/mark/meta-clanton_v1.1.0-dirty/meta/レシピ-devtools/pkgconfig/pkgconfig_0.28.bb, do_fetch
virtual:native:/home/mark/meta-clanton_v1.1.0-dirty/meta/recipes-devtools/pseudo/pseudo_1.5.1.bb, do_fetch
virtual:native:/home/mark/meta-clanton_v1.1.0-dirty/meta/recipes-devtools/flex/flex_2.5.38.bb, do_fetch
/home/mark/meta-clanton_v1.1.0-dirty/meta/recipes-devtools /binutils/binutils-cross_2.24.bb, do_fetch
virtual:native:/home/mark/meta-clanton_v1.1.0-dirty/meta/recipes-extended/gperf/gperf_3.0.4.bb, do_fetch
virtual:native:/home /mark/meta-clanton_v1.1.0-dirty/meta/recipes-core/ncurses/ncurses_5.9.bb, do_fetch
/home/mark/meta-clanton_v1.1.0-dirty/meta/recipes-devtools/m4/m4-native_1 .4.17.bb、do_fetch
virtual:native:/home/mark/meta-clanton_v1.1.0-dirty/meta/recipes-devtools/automake/automake_1.14.bb、do_fetch
virtual:native:/home/mark/meta-clanton_v1 .1.0-dirty/meta/recipes-devtools/autoconf/autoconf_2.69.bb, do_fetch
virtual:native:/home/mark/meta-clanton_v1.1.0-dirty/meta/recipes-core/gettext/gettext_0.18.3.2.bb, do_fetch
/home/mark/meta-clanton_v1.1.0-dirty/meta/recipes -devtools/libtool/libtool-native_2.4.2.bb, do_fetch
virtual:native:/home/mark/meta-clanton_v1.1.0-dirty/meta/recipes-devtools/bison/bison_2.7.1.bb, do_fetch
/home/mark /meta-clanton_v1.1.0-dirty/meta/recipes-kernel/linux-libc-headers/linux-libc-headers_3.14.bb, do_fetch
virtual:native:/home/mark/meta-clanton_v1.1.0-dirty/meta /recipes-support/attr/attr_2.4.47.bb, do_fetch
/home/mark/meta-clanton_v1.1.0-dirty/meta/recipes-core/eglibc/eglibc_2.19.bb, do_fetch
/home/mark/meta-clanton_v1 .1.0-dirty/meta/recipes-devtools/libtool/libtool-cross_2.4.2.bb, do_fetch
/home/mark/meta-clanton_v1.1.0-dirty/meta/recipes-devtools/gcc/gcc-cross-initial_4.8.bb, do_fetch 概要: 34 個の警告メッセージが表示されました。概要: 66 個のエラー メッセージが表示され、ゼロ以外の終了コードが返されました。

何か案は？

Yocto は、フェッチ時にエラーを返します。

リポジトリgit://github.com/robclark/libdri2.git;protocol=http;branch=masterは、yocto で使用しない場合にうまく機能します。このバグかもしれないので、手で修正してパッチをあててみましたがbitbake/lib/bb/fetch2/git.py b/bitbake/lib/bb/fetch2/git.py、何も変わりません。

Yocto インストールから起動しようとすると、何らかの理由で menuconfig メニューが表示されません。ここで説明されているように、Toradex Yocto 1.6 システムを使用しています。 「apalis-t30」。bitbake virtual/kernal -c menuconfig または bitbake linux-toradex -c menuconfig を実行すると、正常に実行されますが、実際に何も表示される前に (エラーなしで) 終了します。devshell を実行しても同じ結果が得られます。

ここで説明されているように、カーネルソースを単独で使用する場合http://developer.toradex.com/software-resources/arm-family/linux/board-support-package/build-u-boot-and-linux- kernel-from-source-codeで、make nconfig を使用して menuconfig を開くことができます。Yocto スクリプトからは、まったく同じカーネル ソースが使用されているように見えます。linux-toradex_git.bb ファイルの do_configure_prepend スクリプトに make nconfig を追加しようとすると、プロセス (menuconfig と仮定) が実行中であることを示すコマンドがスタックし、プロセスの PID が提供されますが、ウィンドウやメニューは表示されません。どこでも、タスクが終了していないようです。

PS。私は Fedora 21 64 ビットを使用しています。

編集: デフォルトの Yocto イメージを確認したところ、menuconfig が正常に表示されます。Toradex BSP は Yocto と完全に互換性があるわけではないため、そのままで動作すると思います。Toradex と話したところ、代わりにカーネルをフォークし、自分のリポジトリで通常の方法で変更し、変更したリポジトリからスクリプトをプルするように指示する必要があると言われました。これでうまくいくと思いますが、少し面倒なので、彼らの Yocto システムを修正したいと思います。通常はmake nconfigを実行するだけで十分なので、これはそれほど難しくないと思いますが、そのコマンドをbitbakeで動作させる方法がわかりません。

yocto v1.7.1 "dizzy" をセットアップして、ローカルの git リポジトリにチェックインされたカスタマイズされた Linux カーネル リビジョンからカスタム Linux イメージをビルドしています。

ビルド プロセスを実行するdo_validate_branches()と、次のエラー メッセージが表示されて失敗します。

do_validate_branches に対して生成されたコードを見ると、問題は を呼び出しているためと思われますgit cat-file -t ${machine_srcrev}が${machine_srcrev}、空の文字列です。さらに、これはlinux-yocto-custom.bbで次を使用しているためと思われます

リビジョン番号に置き換えると、次のような問題が発生しなくなるため...

問題は、実際にはこのレシピをブランチの HEAD からビルドすることです。そのため、特定のリビジョンを配置することは、私が求めているものではなく、SRCREV="${AUTOREV}"実際に必要なもののように思われます。しかし、上で述べたように、これは、評価されるべきだと思うので${SRCREV_machine}はなく、空の文字列になります。AUTOINC

SRCREV正しいものを含むようにレシピを常に更新し、それを通過させることなく、レシピを頭に従うようにする方法について、誰かが私に洞察を提供できますdo_validate_branches()か? ここで何が欠けていますか？

編集：詳細...

kernel-yocto.bbclassを次のように変更すると、この問題も修正されるようです... @285

私の変更についての私の理解は$SRCREV、マシンブランチから明示的に再取得するようにしていることです。オリジナルが考えているように見えるものは、すでに に保存されてい${SRCREV_machine}ます。元の結果は空の文字列になり、私の変更はAUTOINC.

基本クラスを編集する必要はないはずなので、まだ何かが足りないと思います。しかし、私はこれがバグであるというよりも、何かが欠けていると考える傾向があります。おそらく、これを yocto メーリング リストのどこかに投稿する必要があります。