Le problème avec ce nom est qu'il provient de la mythologie romaine et non, comme la plupart de nos produits, de la mythologie grecque. Phoenix est déjà pris par un chargeur...
Ce fichier Lisez-moi explique comment compiler et construire Venus OS à partir des sources.
Tout d’abord, assurez-vous que c’est vraiment ce que vous voulez ou ce dont vous avez besoin. La compilation prend plusieurs heures, beaucoup d'espace disque et aboutit à une image et un SDK qui sont tous deux déjà disponibles en téléchargement sous forme de binaires swu et sdk.
Même lorsque vous développez sur l'une des parties de Venus OS, par exemple l'un de ses pilotes, ou l'interface graphique, il n'est toujours pas nécessaire de construire le système d'exploitation Venus complet à partir des sources.
Assurez-vous de lire d'abord le wiki de Venus OS.
Donc, si vous insistez : ce repo est le point de départ pour construire Vénus. Il contient des fonctions wrapper autour de bitbake et git pour récupérer et compiler les sources.
Pour une construction complète, vous devez avoir accès à des reproductions privées de Victron Energy. Construire uniquement des packages open source est également possible (mais pas vérifié automatiquement pour le moment).
Venus utilise OpenEmbedded comme système de construction.
Construire Venus nécessite un Linux. Chez Victron, nous utilisons Ubuntu pour cela.
# 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
Cette dernière commande fetch a cloné plusieurs éléments dans le répertoire ./sources/ . Tout d’abord, il y a bitbake, qui est un outil de construction de type make-like faisant partie d’OpenEmbedded. En plus de cela, vous trouverez un noyau ouvert et diverses autres couches contenant des recettes et d'autres métadonnées définissant Vénus.
Il est maintenant temps de commencer la construction (ce qui peut prendre plusieurs heures). Sélectionnez l'un des exemples de commandes ci-dessous :
# 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
Les instructions de démarrage ci-dessus sélectionneront automatiquement la configuration utilisée pour Venus OS telle que distribuée. Des configurations alternatives peuvent également être utilisées, par exemple pour créer une version OE plus récente :
make CONFIG=rocko fetch-all
Pour voir quelle configuration votre paiement utilise, consultez le lien symbolique ./conf. Il sera lié à l'une des configurations dans les répertoires ./configs.
Pour chaque configuration il y a quelques fichiers :
repos.conf contient les référentiels qui doivent être extraits. Il peut être reconstruit avec make update-repos.conf .metas.whitelist contient le répertoire méta qui sera ajouté à bblayers.conf, mais seulement s'ils sont réellement présents.machines contient une liste de machines qui peuvent être construites dans cette configuration Pour ajouter un nouveau référentiel, placez-le dans les sources, puis extrayez la branche souhaitée et définissez une branche en amont. Le résultat peut être rendu permanent avec : make repos.conf .
N'oubliez pas d'ajouter les répertoires que vous souhaitez utiliser du nouveau référentiel à metas.whitelist.
reposLe dépôt est comme le sous-module git foreach -q git, mais plus court, vous pouvez donc faire :
./repos pousser l'origine ./repos balise xyz
Il poussera tout, marquera tout, etc. De même, vous pouvez revenir à une certaine révision avec :
./repos nom de la balise de paiement
# 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 branche de base sur laquelle seront basées les versions de maintenance doit être préfixée par un b .
Cet exemple montre comment créer une nouvelle branche de maintenance. Le contexte est que master travaille déjà sur la v2.30. La dernière version officielle était la v2.20. Nous créons donc une branche nommée b2.20 dans laquelle la première version sera la v2.21 ; plus tard, si une autre version de maintenance est nécessaire, la v2.22 est placée en haut ; et ainsi de suite.
# 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
Maintenant, vous êtes prêt ; et prêt à commencer la cueillette des cerises.
Sachez qu'il existe deux manières de rétroporter une modification. La première consiste à effectuer une validation complète à partir des méta-dépôts ; et l'autre consiste à ajouter des correctifs à partir du référentiel source. Lorsque vous le pouvez, appliquez la première méthode. Mais dans le cas où le référentiel, par exemple mk2-dbus ou l'interface graphique, a eu de nombreuses validations dont vous n'avez besoin que d'une seule ; alors vous devez prendre juste le patch.
Les changements doivent être soit très petits, bien testés, soit très importants
git cherry-pick -x ajoute une belle ligne (sélectionnée parmi [ref]) au message de validationbackported from comme celle-ci au message de validation(**backported to v2.22**) ou le cas échéant (**backported to v2.22 as a patch**) à chaque correctif et version qui est été rétroporté.Pour construire, créez un pipeline sur le dépôt miroirs/vénus et exécutez-le pour la branche de maintenance. Aucune variable nécessaire.
Si vous rencontrez des problèmes comme celui-ci :
si cela peut être corrigé avec : make einstein-bb bitbake -c cleanall packagegroup-machine-base
et ensuite réessayez
