الجزء الإشكالي في هذا الاسم هو أنه من الأساطير الرومانية وليس، كما هو الحال في معظم منتجاتنا، من اليونانية. لقد تم بالفعل أخذ فينيكس بواسطة الشاحن ...
يوثق هذا الملف التمهيدي كيفية تجميع وبناء نظام التشغيل Venus من المصدر.
أولاً، تأكد من أن هذا هو ما تريده أو تحتاجه حقًا. يستغرق التجميع عدة ساعات، ومساحة كبيرة على القرص، وينتج صورة وSDK وكلاهما متاح بالفعل للتنزيل كثنائيات swu وsdk.
حتى عندما تقوم بالتطوير على أحد أجزاء نظام التشغيل Venus، على سبيل المثال أحد برامج التشغيل الخاصة به، أو واجهة المستخدم الرسومية، فلا يزال من غير الضروري إنشاء نظام التشغيل Venus الكامل من المصدر.
تأكد من قراءة موقع Venus OS wiki أولاً.
لذا، إذا كنت تصر على أن هذا الريبو هو نقطة البداية لبناء كوكب الزهرة. يحتوي على وظائف مجمعة حول 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، وهو جزء من أداة البناء الشبيهة بـ OpenEmbedded. بالإضافة إلى ذلك، ستجد طبقات أساسية مفتوحة ومتعددة أخرى تحتوي على وصفات وبيانات وصفية أخرى تحدد كوكب الزهرة.
حان الوقت الآن لبدء البناء فعليًا (والذي قد يستغرق عدة ساعات). حدد أحد الأمثلة على الأوامر أدناه:
# 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 على أنه موزع. يمكن أيضًا استخدام إعدادات بديلة، على سبيل المثال لإنشاء إصدار أحدث من المعدات الأصلية:
make CONFIG=rocko fetch-all
لمعرفة التكوين الذي يستخدمه الدفع الخاص بك، انظر إلى الرابط الرمزي ./conf. سيتم ربطه بأحد التكوينات الموجودة في أدلة ./configs.
يوجد عدد قليل من الملفات لكل تكوين:
repos.conf على المستودعات التي يجب سحبها. يمكن إعادة بنائه باستخدام make update-repos.conf .metas.whitelist على الدليل التعريفي الذي ستتم إضافته إلى bblayers.conf، ولكن فقط إذا كان موجودًا بالفعل.machines على قائمة بالأجهزة التي يمكن بناؤها في هذا التكوين لإضافة مستودع جديد، ضعه في المصادر، ثم قم بالتحقق من الفرع الذي تريده وقم بتعيين فرع رئيسي. يمكن جعل النتيجة دائمة باستخدام: make repos.conf .
لا تنس إضافة الدلائل التي تريد استخدامها من المستودع الجديد إلى metas.whitelist.
reposيشبه Repos git submodule foreach -q git، ولكنه أقصر، لذا يمكنك القيام بما يلي:
./repos Push Origin ./repos tag xyz
سيتم دفع الكل ووضع علامة على الكل وما إلى ذلك. وبالمثل يمكنك العودة إلى مراجعة معينة باستخدام:
./repo اسم العلامة الخروج
# 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. آخر إصدار رسمي كان v2.20. لذلك قمنا بإنشاء فرع اسمه b2.20 حيث سيكون الإصدار الأول هو v2.21؛ لاحقًا، إذا كان إصدار صيانة آخر ضروريًا، يتم دفع الإصدار 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
الآن أنت جاهز؛ وعلى استعداد لبدء قطف الكرز.
انتبه إلى أن هناك طريقتان لدعم التغيير. الأول هو الحصول على التزام كامل من مستودعات التعريف؛ والآخر هو إضافة تصحيحات من مستودع المصدر. حيثما أمكنك، قم بتطبيق الطريقة الأولى. ولكن في حالة وجود عدد كبير من الالتزامات في المستودع، على سبيل المثال mk2-dbus أو gui، فإنك تحتاج إلى واحد فقط منها؛ ثم عليك أن تأخذ التصحيح فقط.
يجب أن تكون التغييرات إما صغيرة جدًا أو تم اختبارها جيدًا أو مهمة جدًا
git cherry-pick -x بإلحاق سطر لطيف (منتقى من [المرجع]) برسالة الالتزامbackported from الملاحظة تمامًا مثل هذه إلى رسالة الالتزام(**backported to v2.22**) أو حيثما ينطبق ذلك (**backported to v2.22 as a patch**) إلى كل تصحيح وإصدار. تم نقله إلى الخلف.للبناء، قم بإنشاء خط أنابيب على المرايا/فينوس ريبو، وقم بتشغيله لفرع الصيانة. لا حاجة للمتغيرات.
إذا واجهت مشاكل مثل هذا:
إذا كان يمكن إصلاحه باستخدام: make einstein-bb bitbake -c cleanall packagegroup-machine-base
وبعد ذلك حاول مرة أخرى
