この名前の問題点は、この名前がローマ神話に由来しており、当社のほとんどの製品と同様にギリシャ神話に由来していないことです。フェニックスはすでにチャージャーに取られていますが...
この Readme には、Venus OS をソースからコンパイルしてビルドする方法が記載されています。
まず、それが本当にあなたが望むもの、または必要なものであることを確認してください。コンパイルには数時間かかり、大量のディスク容量が必要になり、結果としてイメージと SDK が生成されます。これらは両方ともバイナリ swu および sdk として既にダウンロード可能です。
Venus OS の一部 (ドライバーや GUI など) を開発している場合でも、完全な Venus OS をソースからビルドする必要はありません。
最初に必ず Venus OS wiki を読んでください。
したがって、もし主張するなら、このリポジトリは Venus を構築するための出発点です。これには、ソースをフェッチしてコンパイルするための bitbake と git のラッパー関数が含まれています。
完全なビルドを行うには、Victron Energy のプライベート リプロにアクセスする必要があります。オープンソース パッケージのみをビルドすることも可能です (ただし、現時点では自動的にチェックされません)。
Venus はビルド システムとして OpenEmbedded を使用しています。
Venus の構築には Linux が必要です。 Victron では、これに Ubuntu を使用しています。
# clone this repository
git clone https://github.com/victronenergy/venus.git
cd venus
# install host packages (Debian based)
sudo make prereq
# fetch needed subtrees
# use make fetch-all instead, if you have access to all the private repos.
make fetch
最後の fetch コマンドは、いくつかのものを./sources/ディレクトリにクローンしました。まず、bitbake があります。これは、OpenEmbedded の make に似たビルド ツールの一部です。それに加えて、openembedded-core や、Venus を定義するレシピやその他のメタデータを含むその他のさまざまなレイヤーもあります。
ここで、実際に構築を開始します (これには何時間もかかる場合があります)。以下のコマンド例のいずれかを選択します。
# build all, this will take a while though... it builds for all MACHINES as found
# in conf/machines.
make venus-images
# build for a specific machine
make ccgx-venus-image
make beaglebone-venus-image
# build the swu file only
make ccgx-swu
# build from within the bitbake shell.
# this will have the same end result as make ccgx-swu
make ccgx-bb
bitbake venus-swu
上記の「はじめに」の手順では、配布された Venus OS に使用される構成が自動的に選択されます。たとえば、新しい OE バージョン用にビルドする場合など、代替セットアップを使用することもできます。
make CONFIG=rocko fetch-all
チェックアウトで使用されている構成を確認するには、./conf シンボリックリンクを参照してください。これは、./configs ディレクトリ内の構成の 1 つにリンクします。
各構成にはいくつかのファイルがあります。
repos.confチェックアウトする必要があるリポジトリが含まれています。 make update-repos.confで再構築できます。metas.whitelistは、bblayers.conf に追加されるメタ ディレクトリが含まれていますが、これは実際に存在する場合に限ります。machinesこの構成で構築できるマシンのリストが含まれています新しいリポジトリを追加するには、それをソースに配置し、必要なブランチをチェックアウトして上流ブランチを設定します。結果はmake repos.conf使用して永続的にすることができます。
新しいリポジトリから使用するディレクトリを metas.whitelist に追加することを忘れないでください。
reposコマンドの使用Repos は git submodule foreach -q git に似ていますが、短いため、次のことができます。
./repos プッシュオリジン ./repos タグ xyz
すべてをプッシュしたり、すべてにタグを付けたりします。同様に、次のようにして特定のリビジョンに戻すことができます。
./repos チェックアウト タグ名
# patches not in upstream yet
./repos cherry -v
# local changes with respect to upstream
./repos diff @{u}
# local changes with respect to the push branch
./repos diff 'origin/`git rev-parse --abbrev-ref HEAD`'
or if you have git 2.5+ ./repos diff @{push}
./repos log @{u}..upstream/`git rev-parse --abbrev-ref @{u} | grep -o "[a-Z0-9]*$"` --oneline
# rebase your local checkout branches on upstream master
./repos fetch origin
./repos rebase 'origin/$checkout_branch'
# checkout the branches as per used config
./repos checkout '$checkout_branch'
# tag & push venus repo as well as all repos.
git tag v2.21
git push origin v2.21
./repos tag v2.21
./repos push origin v2.21
メンテナンス リリースのベースとなるベース ブランチには、接頭辞としてbが付けられます。
この例では、新しいメンテナンス ブランチを作成する方法を示します。コンテキストとしては、マスターはすでに v2.30 で作業しているということです。最新の正式リリースは v2.20 でした。そこで、最初のリリースが v2.21 となる b2.20 という名前のブランチを作成します。後で別のメンテナンス リリースが必要な場合は、v2.22 が一番上にプッシュされます。など。
# clone & make a branch in the venus repo
git clone [email protected]:victronenergy/venus.git venus-b2.20
cd venus-b2.20
git checkout v2.20
git checkout -b b2.20
# fetch all the meta repos
make fetch-all
# clone, prep and push them
./repos checkout v2.20
./repos checkout -b b2.20
./repos push --set-upstream origin b2.20
# update the used config to the new branch
make update-repos.conf
git commit -a -m "pin dunfell branches to b2.20"
# update the raspbian config to the new branch
[
Now manually update the raspbian config file, and commit that as well.
See some earlier branch for example.
]
git commit -a -m "pin raspbian branches to b2.20"
# Update gitlab-ci.yml
[
Now, modify .gitlab-ci.yml. See a previous maintenance branch for
how that is done.
]
git commit -a -m "Don't touch SSTATE cache & build from b2.20"
# Push the new branch and changes to the venus repo
# Note that this causes a (useless) CI build to start on the builder once
# it syncs. Easily cancelled in the gitlab ui.
git push --set-upstream origin b2.20
これで準備は完了です。そしてチェリーピッキングを始める準備ができています。
変更をバックポートするには 2 つの方法があることに注意してください。 1 つは、メタ リポジトリから完全なコミットを取得することです。もう 1 つは、ソース リポジトリからパッチを追加することです。可能な場合は、方法 1 を適用してください。ただし、mk2-dbus や gui などのリポジトリに多数のコミットがあり、そのうち 1 つだけが必要な場合は、その場合はパッチだけを取得する必要があります。
変更は非常に小さいか、十分にテストされているか、または非常に重要である必要があります
git cherry-pick -xコミットメッセージに素晴らしい ([ref] から厳選された) 行を追加します。backported fromものをコミットメッセージに追加します(**backported to v2.22**)または該当する場合は(**backported to v2.22 as a patch**)を追加します。バックポートされました。構築するには、mirrors/venus リポジトリにパイプラインを作成し、それをメンテナンス ブランチに対して実行します。変数は必要ありません。
次のような問題が発生した場合:
make einstein-bb bitbake -c cleanall packagegroup-machine-base で修正できる場合
その後、もう一度試してください
