A parte problemática deste nome é que ele vem da mitologia romana e não, como a maioria dos nossos produtos, da mitologia grega. Phoenix já foi levado por um carregador...
Este leia-me documenta como compilar e construir o Venus OS a partir do código-fonte.
Primeiro, certifique-se de que é realmente isso que você deseja ou precisa. Demora várias horas para compilar, muito espaço em disco e resulta em uma imagem e SDK que já estão disponíveis para download como binários swu e sdk.
Mesmo quando você está desenvolvendo em uma das partes do Venus OS, por exemplo, um de seus drivers ou a interface gráfica do usuário, ainda não é necessário construir o Venus OS completo a partir do código-fonte.
Certifique-se de ler o wiki do Venus OS primeiro.
Então, se você insiste: este repo é o ponto de partida para construir Vênus. Ele contém funções wrapper em torno do bitbake e git para buscar e compilar fontes.
Para uma construção completa, você precisa ter acesso a reproduções privadas da Victron Energy. Construir apenas pacotes de código aberto também é possível (mas não é verificado automaticamente no momento).
Venus usa OpenEmbedded como sistema de construção.
Construir Vênus requer Linux. Na Victron usamos o Ubuntu para isso.
# 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
Esse último comando de busca clonou várias coisas no diretório ./sources/ . Em primeiro lugar, existe o bitbake, que é uma ferramenta de construção semelhante a um make que faz parte do OpenEmbedded. Além disso, você encontrará openembedded-core e várias outras camadas contendo receitas e outros metadados que definem Vênus.
Agora é hora de realmente começar a construir (o que pode levar muitas horas). Selecione um dos comandos de exemplo abaixo:
# 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
As instruções de introdução acima selecionarão automaticamente a configuração usada para o Venus OS conforme distribuído. Configurações alternativas também podem ser usadas, por exemplo, para construir uma versão OE mais recente:
make CONFIG=rocko fetch-all
Para ver qual configuração seu checkout está usando, consulte o link simbólico ./conf. Ele será vinculado a uma das configurações nos diretórios ./configs.
Para cada configuração existem alguns arquivos:
repos.conf contém os repositórios que precisam ser verificados. Pode ser reconstruído com make update-repos.conf .metas.whitelist contém o metadiretório que será adicionado ao bblayers.conf, mas apenas se eles estiverem realmente presentes.machines contém uma lista de máquinas que podem ser construídas nesta configuração Para adicionar um novo repositório, coloque-o em fontes, faça check-out do branch desejado e defina um branch upstream. O resultado pode se tornar permanente com: make repos.conf .
Não se esqueça de adicionar os diretórios que deseja usar do novo repositório ao metas.whitelist.
reposRepos é como git submodule foreach -q git, mas mais curto, então você pode fazer:
./repos push origem ./repos tag xyz
Ele irá enviar tudo, marcar todos, etc. Da mesma forma, você pode reverter para uma determinada revisão com:
./repos checkout nome da tag
# 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
A ramificação base na qual as versões de manutenção serão baseadas deve ser prefixada com um b .
Este exemplo mostra como criar uma nova ramificação de manutenção. O contexto é que o master já está trabalhando na v2.30. O último lançamento oficial foi v2.20. Então criamos um branch chamado b2.20 no qual o primeiro lançamento será v2.21; mais tarde, se outra versão de manutenção for necessária, a v2.22 será colocada no topo; e assim por diante.
# 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
Agora está tudo pronto; e pronto para começar a escolher.
Esteja ciente de que existem duas maneiras de fazer backport de uma alteração. Uma é fazer um commit completo dos meta-repositórios; e a outra é adicionar patches do repositório de origem. Onde você puder, aplique o método um. Mas caso o repositório, por exemplo mk2-dbus ou gui, tenha tido muitos commits dos quais você precisa de apenas um; então você tem que pegar apenas o patch.
As mudanças precisam ser muito pequenas, bem testadas ou muito importantes
git cherry-pick -x anexa uma linha legal (escolhida a dedo em [ref]) à mensagem de commitbackported from como esta à mensagem de commit(**backported to v2.22**) ou quando aplicável (**backported to v2.22 as a patch**) a cada patch e versão que for foi portado para trás.Para construir, crie um pipeline no repositório mirrors/venus e execute-o para o branch de manutenção. Nenhuma variável necessária.
Se você encontrar problemas como este:
if pode ser corrigido com: make einstein-bb bitbake -c cleanall packagegroup-machine-base
e depois tente novamente
