La parte problemática de este nombre es que proviene de la mitología romana y no, como la mayoría de nuestros productos, de la griega. Phoenix ya está tomada por un cargador...
Este archivo Léame documenta cómo compilar y construir Venus OS desde el código fuente.
Primero, asegúrese de que eso es realmente lo que quiere o necesita. Se necesitan varias horas para compilar, mucho espacio en disco y el resultado es una imagen y un SDK que ya están disponibles para descargar como binarios swu y sdk.
Incluso cuando estás desarrollando una de las partes del sistema operativo Venus, por ejemplo uno de sus controladores o la interfaz gráfica de usuario, todavía no es necesario compilar el sistema operativo Venus completo desde la fuente.
Asegúrate de leer primero la wiki de Venus OS.
Entonces, si insistes: este repositorio es el punto de partida para construir Venus. Contiene funciones contenedoras alrededor de bitbake y git para buscar y compilar fuentes.
Para una construcción completa, necesita tener acceso a reproducciones privadas de Victron Energy. También es posible crear solo paquetes de código abierto (pero no se verifica automáticamente por el momento).
Venus utiliza OpenEmbedded como sistema de construcción.
Para construir Venus se necesita Linux. En Victron utilizamos Ubuntu para esto.
# 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
Ese último comando de recuperación ha clonado varias cosas en el directorio ./sources/ . En primer lugar, está bitbake, que es una herramienta de construcción similar a OpenEmbedded. Además de eso, encontrará openembedded-core y varias otras capas que contienen recetas y otros metadatos que definen a Venus.
Ahora es el momento de empezar a construir (lo que puede llevar muchas horas). Seleccione uno de los siguientes comandos de ejemplo:
# 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
Las instrucciones de introducción anteriores seleccionarán automáticamente la configuración que se utiliza para Venus OS tal como se distribuye. También se pueden utilizar configuraciones alternativas, por ejemplo, para compilar una versión más nueva de OE:
make CONFIG=rocko fetch-all
Para ver qué configuración está utilizando su pago, mire el enlace simbólico ./conf. Se vinculará a una de las configuraciones en los directorios ./configs.
Para cada configuración hay algunos archivos:
repos.conf contiene los repositorios que deben extraerse. Se puede reconstruir con make update-repos.conf .metas.whitelist contiene el metadirectorio que se agregará a bblayers.conf, pero solo si realmente están presentes.machines contiene una lista de máquinas que se pueden construir en esta configuración Para agregar un nuevo repositorio, colóquelo en fuentes, luego consulte la rama que desee y configure una rama ascendente. El resultado se puede hacer permanente con: make repos.conf .
No olvide agregar los directorios que desea usar desde el nuevo repositorio a metas.whitelist.
reposLos repositorios son como el submódulo git foreach -q git, pero más cortos, por lo que puedes hacer:
./repos push origen ./repos etiqueta xyz
Empujará todo, etiquetará todo, etc. Asimismo, puede volver a una determinada revisión con:
./repos nombre de etiqueta de pago
# 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
La rama base en la que se basarán las versiones de mantenimiento debe tener el prefijo a b .
Este ejemplo muestra cómo crear una nueva rama de mantenimiento. El contexto es que el maestro ya está trabajando en la versión 2.30. La última versión oficial fue la v2.20. Entonces creamos una rama llamada b2.20 en la que la primera versión será v2.21; más adelante, si es necesaria otra versión de mantenimiento, se coloca la versión 2.22 en la parte superior; y así sucesivamente.
# 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
Ahora ya está todo listo; y listo para comenzar a seleccionar.
Tenga en cuenta que hay dos formas de respaldar un cambio. Una es realizar una confirmación completa de los metarrepositorios; y el otro es agregar parches desde el repositorio fuente. Donde puedas, aplica el método uno. Pero en caso de que el repositorio, por ejemplo mk2-dbus o la interfaz gráfica de usuario, haya tenido muchas confirmaciones de las cuales solo necesitará una; entonces tienes que llevar sólo el parche.
Los cambios deben ser realmente pequeños, bien probados o muy importantes.
git cherry-pick -x agrega una línea agradable (seleccionada de [ref]) al mensaje de confirmaciónbackported from como esta al mensaje de confirmación(**backported to v2.22**) o cuando corresponda (**backported to v2.22 as a patch**) a todos y cada uno de los parches y versiones que haya. sido respaldado.Para compilar, cree una canalización en el repositorio mirrors/venus y ejecútela para la rama de mantenimiento. No se necesitan variables.
Si encuentra problemas como este:
si se puede arreglar con: make einstein-bb bitbake -c cleanall packagegroup-machine-base
y después vuelve a intentarlo
