Проблема с этим названием заключается в том, что оно взято из римской мифологии, а не из греческой, как большинство наших продуктов. Однако Феникс уже захвачен зарядным устройством...
В этом файле readme описано, как скомпилировать и собрать ОС Venus из исходного кода.
Во-первых, убедитесь, что это действительно то, что вам нужно или нужно. Компиляция занимает несколько часов, много дискового пространства, а в результате получается образ и SDK, которые уже доступны для загрузки в виде двоичных файлов swu и sdk.
Даже если вы разрабатываете одну из частей ОС Venus, например один из ее драйверов или графический интерфейс, все равно нет необходимости собирать полную ОС Venus из исходного кода.
Обязательно сначала прочитайте вики Venus OS.
Итак, если вы настаиваете: этот репозиторий является отправной точкой для создания Венеры. Он содержит функции-обертки вокруг bitbake и git для извлечения и компиляции исходных кодов.
Для полной сборки вам необходим доступ к частным репродукциям Victron Energy. Также возможна сборка только пакетов с открытым исходным кодом (но на данный момент это не проверяется автоматически).
Venus использует OpenEmbedded в качестве системы сборки.
Для сборки Венеры требуется 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
Последняя команда выборки клонировала несколько объектов в каталог ./sources/ . Прежде всего, есть bitbake — инструмент сборки, похожий на make, входящий в состав OpenEmbedded. Кроме того, вы найдете 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 в качестве распространяемой. Также можно использовать альтернативные настройки, например, для сборки более новой версии OE:
make CONFIG=rocko fetch-all
Чтобы узнать, какую конфигурацию использует ваша проверка, посмотрите на символическую ссылку ./conf. Он будет ссылаться на одну из конфигураций в каталогах ./configs.
Для каждого конфига есть несколько файлов:
repos.conf содержит репозитории, которые необходимо извлечь. Его можно пересобрать с помощью make update-repos.conf .metas.whitelist содержит метакаталог, который будет добавлен в bblayers.conf, но только если они действительно присутствуют.machines содержит список машин, которые можно собрать в этой конфигурации. Чтобы добавить новый репозиторий, поместите его в исходный код, затем выберите нужную ветку и установите вышестоящую ветку. Результат можно сделать постоянным с помощью команды make repos.conf .
Не забудьте добавить каталоги, которые вы хотите использовать из нового репозитория, в файл Metas.whitelist.
reposRepos похож на подмодуль git foreach -q git, но короче, поэтому вы можете сделать:
./repos push origin ./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 .
В этом примере показано, как создать новую ветку обслуживания. Контекст таков, что мастер уже работает над версией 2.30. Последней официальной версией была версия 2.20. Итак, мы создаем ветку с именем b2.20, в которой первой версией будет v2.21; позже, если потребуется еще одна версия обслуживания, версия 2.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
Теперь все готово; и готов приступить к сбору вишни.
Имейте в виду, что существует два способа поддержать изменение. Один из них — взять полный коммит из метарепозиториев; а второй — добавить патчи из исходного репозитория. Там, где это возможно, применяйте первый метод. Но если в репозитории, например mk2-dbus или gui, было много коммитов, из которых вам нужен только один; тогда вам придется взять только патч.
Изменения должны быть либо очень маленькими, хорошо протестированными, либо очень важными.
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
и после этого попробуй еще раз
