mirror of
https://github.com/tuxbox-neutrino/buildenv.git
synced 2025-08-26 23:13:18 +02:00
Compare commits
11 Commits
| Author | SHA1 | Date | |
|---|---|---|---|
|
bd4394002a | ||
|
|
dc119f2cab | ||
|
|
f058f2dc4f | ||
|
|
f610523694 | ||
|
|
a8123d868a | ||
|
|
1c8c28d6fe | ||
|
|
e5e068c9c6 | ||
|
|
5a6564cfa1 | ||
|
|
17c788f0b6 | ||
|
|
2528ed229f | ||
|
|
b4102b8629 |
410
README-de.md
410
README-de.md
@@ -1,213 +1,355 @@
|
||||
# Schnellstart Image-Erstellung #
|
||||
Dieses Skript dient als Werkzeug zur Vereinfachung der Erstellung einer Umgebung für Entwicklung und des Build-Prozesses für Images die mit Neutrino als Benutzeroberfläche auf unterschiedlichen Hardware-Plattformen laufen. Es automatisiert einige Schritte, die für die Einrichtung einer konsistenten und funktionalen Entwicklungs- und Build-Umgebung erforderlich sind, indem es die notwendigen Abhängigkeiten und grundlegende Konfigurationen sowie Meta-Layer voreinrichtet und benutzerdefinierte Einstellungen ermöglicht. Das Skript zielt darauf ab, eine Grundlage zu bieten, auf der man aufbauen und experimentieren kann, um eigene angepasste Versionen von Tuxbox-Neutrino Images zu erstellen, zu aktualisieren und zu pflegen.
|
||||
|
||||
- [Vorbereitung](#Vorbereitung)
|
||||
- [Image bauen](#Image-bauen)
|
||||
- [Aktualisierung](#Aktualisierung)
|
||||
- [Arbeiten an Zielquellen](#Arbeiten-an-Zielquellen)
|
||||
- [Übersicht über globale Konfigurationsdateien](#Übersicht-über-globale-Konfigurationsdateien)
|
||||
- [1. Vorbereitung](#1-vorbereitung)
|
||||
- [1.1 Erforderliche Host-Pakete installieren](#11-erforderliche-host-pakete-installieren)
|
||||
- [1.1.1 Empfohlene Zusatzpakete zur grafischen Unterstützung und Analyse](#111-empfohlene-zusatzpakete-zur-grafischen-unterstützung-und-analyse)
|
||||
- [1.2 Git vorbereiten (falls erforderlich)](#12-git-vorbereiten-falls-erforderlich)
|
||||
- [1.3 Init-Skript klonen](#13-init-skript-klonen)
|
||||
- [1.4 Init-Skript ausführen](#14-init-skript-ausführen)
|
||||
- [1.5 Struktur der Buildumgebung](#15-struktur-der-buildumgebung)
|
||||
- [2. Image bauen](#2-image-bauen)
|
||||
- [2.1 Box wählen](#21-box-wählen)
|
||||
- [2.2 Starte Umgebungsskript](#22-starte-umgebungsskript)
|
||||
- [2.3 Image erstellen](#23-image-erstellen)
|
||||
- [3. Aktualisierung](#3-aktualisierung)
|
||||
- [3.1 Image aktualisieren](#31-image-aktualisieren)
|
||||
- [3.2 Paket aktualisieren](#32-paket-aktualisieren)
|
||||
- [3.3 Meta-Layer-Repositorys aktualisieren](#33-meta-layer-repositorys-aktualisieren)
|
||||
- [4. Eigene Anpassungen](#4-eigene-anpassungen)
|
||||
- [4.1 Konfiguration](#41-konfiguration)
|
||||
- [4.1.1 Konfigurationsdateien](#411-konfigurationsdateien)
|
||||
- [4.1.2 bblayers.conf](#412-bblayersconf)
|
||||
- [4.1.3 Konfiguration zurücksetzen](#413-konfiguration-zurücksetzen)
|
||||
- [4.3 Recipes](#43-recipes)
|
||||
- [4.4 Pakete](#44-pakete)
|
||||
- [4.4.1 Quellcode im Workspace bearbeiten (Beispiel)](#441-quellcode-im-workspace-bearbeiten-beispiel)
|
||||
- [5. Neubau eines einzelnen Pakets erzwingen](#5-neubau-eines-einzelnen-pakets-erzwingen)
|
||||
- [6. Vollständigen Imagebau erzwingen](#6-vollständigen-imagebau-erzwingen)
|
||||
- [7. Lizenz](#7-lizenz)
|
||||
- [8. Weiterführende Informationen](#8-weiterführende-informationen)
|
||||
|
||||
## Vorbereitung
|
||||
## 1. Vorbereitung
|
||||
|
||||
### Erforderliche Host-Pakete installieren (Debian 11)
|
||||
Zur Verwendung mit anderen Distributionen siehe: [Yocto Project Quick Build](https://docs.yoctoproject.org/3.2.4/ref-manual/ref-system-requirements.html#supported-linux-distributions)
|
||||
Hier angegebene Pfade basieren auf Vorgaben, die vom Init-Script erzeugt werden. Einige Einträge werden als ```<Platzhalter>``` dargestellt, die lokal angepasst werden müssen. [Siehe Schema](#14-init-skript-ausführen)
|
||||
|
||||
> :memo: **HINWEIS:** Bei Verwendung der Tuxbox-Builder-VM (welche nicht zwingend erforderlich ist), springe bitte zu [Schritt 1](#1-Init-Skript-klonen). Die Tuxbox-Builder-VM enthält bereits erforderliche Pakete. Details und Download von Tuxbox-Builder VM siehe: [Tuxbox-Builder](https://sourceforge.net/projects/n4k/files/Tuxbox-Builder)
|
||||
**HINWEIS:** Die Wartung der Tuxbox-Builder-VM wird nicht mehr weitergeführt. Falls die VM-Lösung trotzdem verwendet werden soll, springe bitte zu [Schritt 2](#2-image-bauen). Die Tuxbox-Builder-VM enthält normalerweise bereits erforderliche Pakete.
|
||||
|
||||
Details und Download: [Tuxbox-Builder](https://sourceforge.net/projects/n4k/files/Tuxbox-Builder)
|
||||
|
||||
### 1.1 Erforderliche Host-Pakete installieren
|
||||
|
||||
**Hinweis:** Bei Verwendung anderer Distributionen siehe: [Yocto Project Quick Build](https://docs.yoctoproject.org/3.2.4/ref-manual/ref-system-requirements.html#supported-linux-distributions)
|
||||
|
||||
Debian 11
|
||||
|
||||
```bash
|
||||
apt-get install -y gawk wget git-core diffstat unzip texinfo gcc-multilib build-essential \
|
||||
sudo apt-get install -y gawk wget git-core diffstat unzip texinfo gcc-multilib build-essential \
|
||||
chrpath socat cpio python python3 python3-pip python3-pexpect xz-utils debianutils \
|
||||
iputils-ping python3-git python3-jinja2 libegl1-mesa pylint3 xterm subversion locales-all \
|
||||
libxml2-utils ninja-build default-jre clisp libcapstone4 libsdl2-dev doxygen
|
||||
```
|
||||
> :memo: **HINWEIS:** Bei Debian 10 (buster) libcapstone3 verwenden.
|
||||
|
||||
#### Empfohlene Zusatzpakete zur grafischen Unterstützung und Analyse (z.B. mit Kdevelop, Meld):
|
||||
**HINWEIS:** Bei Debian 10 (buster) libcapstone3 verwenden.
|
||||
|
||||
#### 1.1.1 Empfohlene Zusatzpakete zur grafischen Unterstützung und Analyse
|
||||
|
||||
```bash
|
||||
apt-get install -y gitk git-gui meld cppcheck clazy kdevelop
|
||||
sudo apt-get install -y gitk git-gui meld cppcheck clazy kdevelop
|
||||
```
|
||||
|
||||
### Optional: Falls kein konfiguriertes Git vorhanden ist, gib bitte Deine globalen Git-Benutzerdaten ein:
|
||||
### 1.2 Git vorbereiten (falls erforderlich)
|
||||
|
||||
Das init-Script verwendet Git zum Klonen der Meta-Layer Repositorys. Wenn noch kein konfiguriertes Git vorhanden ist, lege bitte Deine globalen Git-Benutzerdaten an, andernfalls wird während das Script durchläuft, unnötig darauf hingewiesen.
|
||||
|
||||
```bash
|
||||
git config --global user.email "you@example.com"
|
||||
git config --global user.user "Dein Name"
|
||||
git config --global user.name "Dein Name"
|
||||
```
|
||||
|
||||
## Image bauen
|
||||
### 1.3 Init-Skript klonen
|
||||
|
||||
> :memo: **Hinweis:** Einige Pfade basieren auf Vorgaben, die vom Init-Script erzeugt werden. Einige Einträge werden als ```<Platzhalter>``` dargestellt, die entsprechend angepasst werden müssen.
|
||||
|
||||
> ### 1. Init-Skript klonen.
|
||||
```bash
|
||||
git clone https://github.com/tuxbox-neutrino/buildenv.git
|
||||
cd buildenv
|
||||
git clone https://github.com/tuxbox-neutrino/buildenv.git && cd buildenv
|
||||
```
|
||||
|
||||
> ### 2. Init-Skript ausführen
|
||||
### 1.4 Init-Skript ausführen
|
||||
|
||||
```bash
|
||||
./init
|
||||
cd poky-3.2.4
|
||||
./init && cd poky-3.2.4
|
||||
```
|
||||
|
||||
> ### 3. Liste möglicher Maschinentypen anzeigen
|
||||
### 1.5 Struktur der Buildumgebung
|
||||
|
||||
Nach [Schritt 1.4](#14-init-skript-ausführen) sollte etwa diese Struktur angelegt worden sein:
|
||||
|
||||
```
|
||||
.buildenv
|
||||
├── dist <-- Freigabeordner für http-Server (falls eingerichtet) http://localhost, http://localhost:8080 , benötigt für IPK-Feeds und Images
|
||||
│ └── {DISTRO_VERSION} <-- hier liegen die erzeugten Images und Pakete (Symlinks zeigen auf die Deploy-Verzeichnisse innerhalb der Build-Unterverzeichnisse)
|
||||
:
|
||||
├── init.sh <-- init-Script
|
||||
├── local.conf.common.inc <-- globale Benutzerkonfiguration, ist in die benutzerdefinierte Konfiguration inkluiert
|
||||
:
|
||||
├── log <-- Ordner für Logs, enthält Logs für jede Ausführung des Init-Scripts
|
||||
:
|
||||
└── poky-{DISTRO_VERSION} <-- Nach Schritt 1.4 befindest Du dich hier. Hier befindet sich der Buildsystem-Kern und die Meta-Layer
|
||||
│
|
||||
:
|
||||
└── build <-- Hier liegen die Build-Unterverzeichnisse, nach Schritt 2.2 befindest Du dich in einem dieser Build-Unterverzeichnisse
|
||||
├── <machine x> <-- Build-Unterverzeichnis für Maschinentyp x
|
||||
│ ├── conf <-- Ordner für Layer und benutzerdefinierte Konfiguration
|
||||
│ │ └── bblayers.conf <-- Konfigurationsdatei für eingebundene Meta-Layer
|
||||
│ │ └── local.conf <-- benutzerdefinierte Konfiguration für einen Maschinentyp
|
||||
│ :
|
||||
│ ├── (tmp) <-- Arbeitsverzeichnis, wird beim Bauen automatisch angelegt
|
||||
│ └── (workspace) <-- Workspace, wird beim Ausführen von devtool angelegt
|
||||
:
|
||||
└── <machine y> <-- weiteres Build-Unterverzeichnis für Maschinentyp y
|
||||
```
|
||||
|
||||
## 2. Image bauen
|
||||
|
||||
Stelle sicher, dass Du dich wie im [Schema](#15-struktur-der-buildumgebung) gezeigt hier befindest:
|
||||
|
||||
```
|
||||
poky-{DISTRO_VERSION}
|
||||
```
|
||||
|
||||
### 2.1 Box wählen
|
||||
|
||||
Liste verfügbarer Geräte anzeigen lassen:
|
||||
|
||||
```bash
|
||||
ls build
|
||||
```
|
||||
|
||||
> ### 4. Umgebungsskript ausführen
|
||||
### 2.2 Starte Umgebungsskript
|
||||
|
||||
Führe das Umgebungsskript für die aus der Liste gewünschte Box einmalig aus! Du gelangst dann automatisch in das passende Build-Unterverzeichnis.
|
||||
|
||||
```bash
|
||||
. ./oe-init-build-env build/<Machine-Type aus der Liste von Schritt 3 hier eintragen>
|
||||
. ./oe-init-build-env build/<machine>
|
||||
```
|
||||
|
||||
> ### 5. Bauen
|
||||
Solange man sich ab jetzt mit der erzeugten Umgebung innerhalb der geöffneten Shell im gewünschten Build-Unterverzeichnis befindet, muss man dieses Script nicht noch einmal ausführen und kannst [Schritt 2.3 ](#23-image-erstellen) Images oder beliebige Pakete bauen.
|
||||
|
||||
**Hinweis:** Du kannst auch weitere Shells und damit Buildumgebungen für weitere Boxtypen parallel dazu anlegen und je nach Bedarf auf das entsprechende Terminal wechseln und auch parallel bauen lassen, sofern es dein System hergibt.
|
||||
|
||||
### 2.3 Image erstellen
|
||||
|
||||
```bash
|
||||
bitbake neutrino-image
|
||||
```
|
||||
|
||||
Das kann eine Weile dauern. Einige Warnmeldungen können ignoriert werden. Fehlermeldungen, welche die Setscene-Tasks betreffen, sind kein Problem, aber Fehler während der Build- und Package-Tasks brechen den Prozess in den meißten Fällen ab. [Bitte melde in diesem Fall den Fehler oder sende Deine Lösung an uns](https://forum.tuxbox-neutrino.org/forum/viewforum.php?f=77). Hilfe ist sehr willkommen.
|
||||
Das kann eine Weile dauern. Einige Warnmeldungen können ignoriert werden. Fehlermeldungen, welche die Setscene-Tasks betreffen, sind kein Problem, aber Fehler während der Build- und Package-Tasks brechen den Prozess in den meisten Fällen ab. [Bitte melde in diesem Fall den Fehler oder teile Deine Lösung](https://forum.tuxbox-neutrino.org/forum/viewforum.php?f=77). Hilfe ist sehr willkommen.
|
||||
|
||||
Wenn alles erledigt ist, sollte eine ähnliche Meldung wie diese erscheinen:
|
||||
|
||||
```bash
|
||||
...
|
||||
NOTE: Tasks Summary: Attempted 4568 tasks of which 4198 didn't need to be rerun and all succeeded.
|
||||
...
|
||||
```
|
||||
**Das war's ...**
|
||||
|
||||
Erstellte Images und Pakete sind zu finden unter:
|
||||
```
|
||||
~/build/poky-3.2.4/build/<machine>/tmp/deploy
|
||||
```
|
||||
oder im dist-Verzeichnis:
|
||||
```
|
||||
~/build/dist/<Image-Version>/<machine>/
|
||||
"NOTE: Tasks Summary: Attempted 4568 tasks of which 4198 didn't need to be rerun and all succeeded."
|
||||
```
|
||||
|
||||
## Aktualisierung
|
||||
> :memo: Manuelle Aktualisierungen für beliebeige Ziel-Quellen sind nicht erforderlich. Dies wird automatisch bei jedem aufgerufenen Ziel mit Bitbake durchgeführt. Dadurch werden auch immer erforderliche Abhängigkeiten aktualisiert. Wenn man die volle Kontrolle über bestimmte Ziel-Quellen haben möchte, siehe [Arbeiten an Zielquellen](#Arbeiten-an-Zielquellen)!
|
||||
<span style="color: green;">Das war's ...</span>
|
||||
|
||||
Falls [Schritte 1 bis 4](#3-Liste-möglicher-Maschinentypen-anzeigen) bereits ausgeführt wurden, ist nur Schritt 5 erforderlich:
|
||||
|
||||
### Update Image
|
||||
Ergebnisse findest Du unter:
|
||||
|
||||
```bash
|
||||
buildenv/poky-{DISTRO_VERSION}/build/<machine>/tmp/deploy
|
||||
```
|
||||
|
||||
oder im Freigabe-Verzeichnis:
|
||||
|
||||
```bash
|
||||
buildenv/dist/<Image-Version>/<machine>/
|
||||
```
|
||||
|
||||
Falls ein Webserver eingerichtet ist, der auf das Freigabe-Verzeichnis zeigt:
|
||||
|
||||
```bash
|
||||
http://localhost/{DISTRO_VERSION} oder mit Portnummer http://localhost:8080/{DISTRO_VERSION}
|
||||
```
|
||||
|
||||
## 3. Aktualisierung
|
||||
|
||||
Manuelle Aktualisierungen der Pakete sind nicht erforderlich. Dies wird automatisch bei jedem aufgerufenen Target mit Bitbake durchgeführt. Das gilt auch für mögliche Abhängigkeiten. Wenn man die volle Kontrolle über bestimmte Paket-Quellen haben möchte, kann man sich diese für jedes Paket im dafür vorgesehenen Workspace ablegen, siehe [4.4 Pakete](#44-pakete).
|
||||
Sollten keine Aktualisierungen notwendig sein, werden die Builds automatisch übersprungen.
|
||||
|
||||
### 3.1 Image aktualisieren
|
||||
|
||||
```bash
|
||||
bitbake neutrino-image
|
||||
```
|
||||
|
||||
### Update Ziel
|
||||
### 3.2 Paket aktualisieren
|
||||
|
||||
```bash
|
||||
bitbake <target>
|
||||
bitbake <package>
|
||||
```
|
||||
|
||||
### Meta-Layer-Repositories aktualisieren
|
||||
Die erneute Ausführung des Init-Skripts aktualisiert die enthaltenen Meta-Layer auf den Stand der Remote-Repositories.
|
||||
### 3.3 Meta-Layer-Repositorys aktualisieren
|
||||
|
||||
Die Ausführung des Init-Skripts mit dem ```--update``` Parameter aktualisiert die enthaltenen Meta-Layer auf den Stand der Remote-Repositorys.
|
||||
|
||||
```bash
|
||||
cd $HOME/build
|
||||
./init
|
||||
```
|
||||
Die angestoßenen Update-Routinen des Init-scripts sollten nicht festgeschriebene Änderungen vorübergehend stashen bzw. rebasen lokale Commits auf die Remote-Änderungen. Konflikte muss man jedoch manuell auflösen. Natürlich kann man seine lokalen Meta-Layer für Meta-Neutrino- und Maschinen-Layer-Repositories manuell aktualisieren und modifizieren.
|
||||
./init --update
|
||||
```
|
||||
|
||||
> :memo: **Hinweis:** Konfigurationsdateien bleiben unberührt. Neue oder geänderte Konfigurationsoptionen werden nicht berücksichtigt. Bitte überprüfe ggf. die Konfiguration.
|
||||
Falls Du an den Meta-Layern Änderungen vorgenommen hast, sollten angestoßene Update-Routinen des Init-scripts nicht festgeschriebene Änderungen vorübergehend stashen bzw. auf das lokale Repository rebasen. Natürlich kann man seine lokalen Meta-Layer für Meta-Neutrino- und Maschinen-Layer-Repositorys manuell aktualisieren. Konflikte muss man jedoch immer manuell auflösen.
|
||||
|
||||
## Arbeiten an Zielquellen
|
||||
Wenn man die volle Kontrolle über die Ziel-Quellen haben möchte, sollten die Quellcodes in den Workspace verschoben werden. Siehe
|
||||
[devtool](https://docs.yoctoproject.org/current/ref-manual/devtool-reference.html) und insbesondere [devtool modify](https://docs.yoctoproject.org/current/ref-manual/devtool-reference.html#modifying-an-existing-recipe).
|
||||
**Hinweis:** Konfigurationsdateien bleiben im Wesentlichen unberührt, aber mögliche Variablennamen werden migriert. Neue oder geänderte Einstellungen werden nicht geändert. Bitte überprüfe evtl. die Konfiguration.
|
||||
|
||||
## Konfiguration zurücksetzen
|
||||
## 4. Eigene Anpassungen
|
||||
|
||||
### 4.1 Konfiguration
|
||||
|
||||
Es wird empfohlen, zum ersten Mal ohne geänderte Konfigurationsdateien zu bauen, um einen Eindruck davon zu bekommen, wie der Build-Prozess funktioniert und um die Ergebnisse möglichst schnell zu sehen.
|
||||
Die Einstellmöglichkeiten sind sehr umfangreich und für Einsteiger nicht wirklich überschaubar. OpenEmbedded insbesondere das Yocto-Project ist jedoch sehr
|
||||
umfassend dokumentiert und bietet die beste Informationsquelle.
|
||||
|
||||
#### 4.1.1 Konfigurationsdateien
|
||||
|
||||
> ~/buildenv/poky-3.2.4/build/```<machine>```/conf/local.conf
|
||||
|
||||
Diese Datei befindet sich im Buildverzeichnis des jeweiligen Maschinentyps und ist die eigentliche benutzerdefinierte Konfigurationsdatei, welche ursprünglich vom Buildsystem dafür vorgesehen ist. Diese local.conf enthält in dieser Umgebung jedoch nur nur wenige Zeilen und inkludiert eine globale Konfiguration. Diese Datei ist **nur** für den von ihr unterstützten Maschinentyp gültig. Hier kann man deshalb ergänzende Einträge vornhemen, die entsprechend nur für den Maschinentyp vorgesehen sind. [Siehe auch Schema](#14-init-skript-ausführen)
|
||||
|
||||
> ~/buildenv/local.conf.common.inc
|
||||
|
||||
Diese Datei enthält Einstellungen, die für alle Maschinentypen zutreffen und wird bei erstmaligen ausführen des Init-Scripts aus der Vorlage ```~/buildenv/local.conf.common.inc.sample``` erzeugt.
|
||||
|
||||
Die vom Buildsystem vorgesehene ```./build/<machine>/conf/local.conf``` könnte man zwar so wie es ursprügliche vom Buildsystem vorgesehen ist als primäre Konfigurationsdatei für jeden Maschinentyp separat verwenden, aber das würde den Wartungsaufwand unnötig erhöhen. Deshalb ist ```~/buildenv/local.conf.common.inc``` nur in ```./build/<machine>/conf/local.conf``` inkludiert,
|
||||
|
||||
**Hinweis zu** ```~/buildenv/local.conf.common.inc.sample```**:** Dies ist nur eine Vorlage und sollte unberührt bleiben, um mögliche Konflikte beim Aktualisieren des Build-Script-Repositorys zu vermeiden und um zu sehen, was sich geändert haben könnte.
|
||||
|
||||
Nach einer Aktualisierung des Build-Script-Repositorys könnten neue oder geänderte Optionen hinzugefügt oder entfernt worden sein, die nicht in die inkludierte Konfigurationsdatei übernommen werden. Diesen Fall sollte man in der eigenen Konfiguration berücksichtigen und falls erforderlich prüfen und anpassen.
|
||||
|
||||
#### 4.1.2 bblayers.conf
|
||||
|
||||
> ~/buildenv/poky-3.2.4/build/```<machine>```/conf/bblayers.conf
|
||||
|
||||
Diese Datei wird normalerweise beim erstmaligen ausführen des Init-Skripts angepasst und braucht in der Regel nur angepasst zu werden, wenn man Layer hinzufügen, entfernen oder ersetzen möchte.
|
||||
|
||||
#### 4.1.3 Konfiguration zurücksetzen
|
||||
Wenn Du deine Maschinen-Konfigurationen zurücksetzen möchtest, benenne bitte das conf-Verzeichnis um (Löschen wird nicht empfohlen) und führe das Init-Skript erneut aus.
|
||||
|
||||
|
||||
```bash
|
||||
mv $HOME/build/poky-3.2.4/build/<machine>/conf $HOME/build/poky-3.2.4/build/<machine>/conf.01
|
||||
cd $HOME/build
|
||||
./init
|
||||
~/mv ~/buildenv/poky-3.2.4/build/<machine>/conf ~/buildenv/poky-3.2.4/build/<machine>/conf.01
|
||||
~/cd ~/buildenv
|
||||
~/./init
|
||||
```
|
||||
|
||||
### 4.3 Recipes
|
||||
|
||||
## Neubau eines einzelnen Ziels erzwingen
|
||||
In einigen Fällen kann es vorkommen, dass ein Target, warum auch immer, abbricht. Man sollte deswegen nicht in Panik verfallen und deswegen den tmp-Ordner und den sstate-cache löschen. Das kann man auch für jedes Target einzeln machen.
|
||||
**Sofern man nicht direkt an der Entwicklung der Poky-Ebenen beiteiligt ist, ändere nichts an den offiziellen Poky-Ebenen (Meta-Layer)! Dies wird vom Yocto-Projekt ausdrücklich nicht empfohlen, da man Gefahr läuft, bei Aktualisierungen, seine gesamte Arbeit zu verlieren und Inkompatibilitäten oder Konflikte schafft, die nur schwer zu warten sein können. Die übliche Vorgehensweise, um vorhandene offizielle Rezepte zu vervollständigen, zu erweitern oder zu überschreiben, ist die [Verwendung von .bbappend](https://docs.yoctoproject.org/3.2.4/dev-manual/dev-manual-common-tasks.html#using-bbappend-files-in-your-layer)-Dateien.**
|
||||
|
||||
> :memo: Insbesondere defekte Archiv-URL's können zum Abbruch führen. Diese Fehler werden aber immer angezeigt und man kann die URL überprüfen. Oft liegt es nur an den Servern und funktioneren nach wenigen Minuten sogar wieder.
|
||||
Alternativ, allerdings auch nicht wirklich empfehlenswert, könnte man Kopien von offiziellen Reciepes in seine eigenen Meta-Layer übernehmen und anpassen, da diese dann in der Regel vom Buildsystem bevorzugt werden. In solch einem Fall ist man allerdings selbst dafür verantwortlich, diese Recipes aktuell zu halten, was den Wartungsaufwand allerdings unnötig erhöhen kann.
|
||||
|
||||
Für Rezepte aus den eigenen Meta-Layern wie z.B. meta-neutrino oder den Maschinen-Layern, gilt das prinzipiell genauso. Wer aber [aktiv an den Recipes mitarbeiten](https://docs.yoctoproject.org/current/ref-manual/devtool-reference.html#modifying-an-existing-recipe) möchte, kann dies gerne tun.
|
||||
|
||||
### 4.4 Pakete
|
||||
|
||||
Wenn man die volle Kontrolle über einen Paket-Quellcode haben möchte, um z.B. etwas zu fixen oder aktiv zu entwickeln, sollte der Quellcode an dem man arbeiten möchte in den Workspace verschoben werden. Siehe: [Beispiel für Neutrino](#441-quellcode-im-workspace-bearbeiten-beispiel)
|
||||
|
||||
Siehe [devtool](https://docs.yoctoproject.org/current/ref-manual/devtool-reference.html) und insbesondere [devtool modify](https://docs.yoctoproject.org/current/ref-manual/devtool-reference.html#modifying-an-existing-recipe). Im Workspace hat man die Garantie, dass der Quellcode nicht vom Buildsystem angefasst wird. Beachtet man das nicht, kann es z.B. vorkommen, dass geänderter Quellcode immer wieder gelöscht oder modifiziert wird. Eigene Anpassungen können daher verloren gehen oder inkompatibel werden. In der lokalen Standardkonfiguration ist [rm_work](https://docs.yoctoproject.org/ref-manual/classes.html#ref-classes-rm-work) aktiviert, was dafür sorgt, dass nach jedem abgeschlossenem Bau eines Pakets, das jeweilige Arbeitsverzeichnis aufgeräumt wird, so dass ausser einigen Logs nichts übrig bleiben wird.
|
||||
|
||||
#### 4.4.1 Quellcode im Workspace bearbeiten (Beispiel)
|
||||
|
||||
Hier wird beispielhaft Neutrino verwendet, aber diese Vorgehensweise trifft im Wesentlichen auf alle anderen Pakete zu.
|
||||
|
||||
```bash
|
||||
~/buildenv/poky-3.2.4/build/hd61$ devtool modify neutrino
|
||||
NOTE: Starting bitbake server...54cf81d24c147d888c"
|
||||
...
|
||||
workspace = "3.2.4:13143ea85a1ab7703825c0673128c05845b96cb5"
|
||||
|
||||
Initialising tasks: 100% |###################################################################################################################################################################################################| Time: 0:00:01
|
||||
Sstate summary: Wanted 0 Found 0 Missed 0 Current 10 (0% match, 100% complete)
|
||||
NOTE: Executing Tasks
|
||||
NOTE: Tasks Summary: Attempted 83 tasks of which 80 didn't need to be rerun and all succeeded.
|
||||
INFO: Adding local source files to srctree...
|
||||
INFO: Source tree extracted to /home/<user>/buildenv/poky-3.2.4/build/hd61/workspace/sources/neutrino
|
||||
INFO: Recipe neutrino-mp now set up to build from /home/<user>/buildenv/poky-3.2.4/build/hd61/workspace/sources/neutrino
|
||||
```
|
||||
|
||||
Unter ```/buildenv/poky-3.2.4/build/hd61/workspace/sources/neutrino``` befindet sich jetzt der Quellcode für Neutrino. Dort kann man dann daran arbeiten. Das bedeutet, dass das Buildsystem nicht mehr von sich aus vom Remote Git-Repo die Neutrino-Quellen klont bzw. automatisch aktalisiert, sondern ab jetzt nur noch die lokalen Quellen innerhalb des Workspace nutzt, die man selbst verwalten muss. Dabei handelt es sich um ein von devtool angelegtes Git-Repo, in welches man an das Original-Remote-Repository einbinden kann, sofern dies nicht bereits der Fall ist.
|
||||
|
||||
Führt man jetzt das aus...
|
||||
|
||||
```bash
|
||||
bitbake neutrino
|
||||
```
|
||||
|
||||
...wird Neutrino ab sofort nur noch vom lokalen Repo im Workspace gebaut werden:
|
||||
|
||||
|
||||
```bash
|
||||
NOTE: Started PRServer with DBfile: /home/<user>/buildenv/poky-3.2.4/build/hd61/cache/prserv.sqlite3, IP: 127.0.0.1, PORT: 34211, PID: 56838
|
||||
...
|
||||
workspace = "3.2.4:13143ea85a1ab7703825c0673128c05845b96cb5"
|
||||
|
||||
Initialising tasks: 100% |###################################################################################################################################################################################################| Time: 0:00:01
|
||||
Sstate summary: Wanted 122 Found 116 Missed 6 Current 818 (95% match, 99% complete)
|
||||
NOTE: Executing Tasks
|
||||
NOTE: neutrino-mp: compiling from external source tree /home/<user>/buildenv/poky-3.2.4/build/hd61/workspace/sources/neutrino
|
||||
NOTE: Tasks Summary: Attempted 2756 tasks of which 2741 didn't need to be rerun and all succeeded.
|
||||
```
|
||||
|
||||
**Hinweis!** Im speziellen Fall von Neutrino, ist es ratsam nicht nur dessen Quellcode, sondern auch die zugehörige ```libstb-hal``` in den Workspace zu übertragen.
|
||||
|
||||
```bash
|
||||
devtool modify libstb-hal
|
||||
```
|
||||
|
||||
## 5. Neubau eines einzelnen Pakets erzwingen
|
||||
|
||||
In einigen Fällen kann es vorkommen, dass ein Target, warum auch immer, abbricht. Man sollte deshalb aber keinesfalls in Panik verfallen und deswegen den Arbeitsordner und den teueren sstate-cache löschen. Bereinigungen kann man für jedes Target einzeln vornehmen, ohne ein ansonsten funktionierendes System platt zu machen.
|
||||
|
||||
Insbesondere defekte Archiv-URLs können zum Abbruch führen. Diese Fehler werden aber immer angezeigt und man kann die URL überprüfen. Oft liegt es nur an den Servern und funktionieren nach wenigen Minuten sogar wieder.
|
||||
|
||||
Um sicherzustellen, ob das betreffende Recipe auch tatsächlich ein Problem hat, macht es Sinn das betreffende Target komplett zu bereinigen und neu zu bauen. Um dies zu erreichen, müssen alle zugehörigen Paket-, Build- und Cachedaten bereinigt werden.
|
||||
|
||||
Um sicherzustellen, ob das betreffende Recipe auch tatsächlich ein Problem hat, macht es Sinn das betreffende Target komplett zu bereinigen und neu zu bauen. Um dies zu erzwingen, müssen alle erzeugten Paket-, Build- und Cachedaten bereinigt werden.
|
||||
```bash
|
||||
bitbake -c cleansstate <target>
|
||||
|
||||
```
|
||||
anschließend neu bauen:
|
||||
|
||||
```bash
|
||||
bitbake <target>
|
||||
```
|
||||
|
||||
## Vollständigen Imagebau erzwingen
|
||||
Wenn Du einen kompletten Imagebau erzwingen möchtest, kann man das tmp-Verzeichnis löschen (oder umbenennen):
|
||||
## 6. Vollständigen Imagebau erzwingen
|
||||
|
||||
Das Init-Skript stellt dafür die Option `--reset` zur Verfügung.
|
||||
|
||||
```bash
|
||||
./init --reset
|
||||
# Anweisungen befolgen
|
||||
```
|
||||
|
||||
Manuell erreichst Du das ebenfalls, indem man das tmp-Verzeichnis im jeweiligem Build-Unterverzeichnis manuell umbenennt. Löschen kann man es nachträglich, wenn man Speicherplatz freigeben will oder sich sicher ist, dass man das Verzeichnis nicht mehr braucht:
|
||||
|
||||
```bash
|
||||
mv tmp tmp.01
|
||||
```
|
||||
|
||||
Anschließend das Image neu bauen lassen:
|
||||
|
||||
```bash
|
||||
bitbake neutrino-image
|
||||
```
|
||||
Wenn man den sstate-cache **nicht** gelöscht hat, sollte das Image in relativ kurzer Zeit fertig gebaut sein. Daher wird empfohlen, den sstate-cache beizubehalten. Das Verzeichnis wo sich der sstate-cache befindet, wird über die Variable ```${SSTATE_DIR}``` festgelegt und kann in der Konfiguration angepasst werden.
|
||||
|
||||
Wenn man den Cache **nicht** gelöscht hat, sollte das Image in relativ kurzer Zeit fertig gebaut sein. Gerade deshalb wird empfohlen, den Cache beizubehalten. Das Verzeichnis wo sich der Cache befindet, wird über die Variable ```${SSTATE_DIR}``` festgelegt und kann in der Konfiguration angepasst werden.
|
||||
|
||||
Dieses Verzeichnis ist ziemlich wertvoll und nur in seltenen Fällen ist es notwendig, dieses Verzeichnis zu löschen. Bitte beachte, dass der Build in diesem Fall sehr viel mehr Zeit in Anspruch nimmt.
|
||||
> :bulb: Man kann Bitbake anweisen, keinen sstate-cache zu verwenden.
|
||||
```bash
|
||||
bitbake --no-setscene neutrino-image
|
||||
```
|
||||
oder
|
||||
```bash
|
||||
bitbake --skip-setscene neutrino-image
|
||||
```
|
||||
|
||||
## Bei Bedarf anpassen
|
||||
Es wird empfohlen, zum ersten Mal ohne Änderungen an den Konfigurationsdateien zu bauen, um einen Eindruck davon zu bekommen, wie der Build-Prozess funktioniert, und um die Ergebnisse zu sehen.
|
||||
Die Einstellmöglichkeiten sind sehr umfangreich und für Einsteiger nicht wirklich überschaubar. Das Yoctoproject ist jedoch sehr
|
||||
umfassend dokumentiert und bietet die beste Informationsquelle.
|
||||
|
||||
**Wichtig für Entwickler**: "[Arbeiten an Zielquellen](#Arbeiten-an-Zielquellen)"!
|
||||
Dieses Verzeichnis ist ziemlich wertvoll und nur in seltenen Fällen ist es notwendig, dieses Verzeichnis zu löschen. Bitte beachte, dass der Buildvorgang nach dem Löschen des Cache sehr viel mehr Zeit in Anspruch nimmt.
|
||||
|
||||
> :memo: **Bitte ändere nicht die Yocto-Recipes! Dies wird vom Yocto-Team nicht empfohlen, aber man kann zum Vervollständigen, Erweitern oder Überschreiben von Meta-Core-Recipes [.bbappend](https://docs.yoctoproject.org/3.2.4/dev-manual/dev-manual-common-tasks.html#using-bbappend-files-in-your-layer)-Dateien verwenden.**
|
||||
|
||||
### Übersicht über globale Konfigurationsdateien
|
||||
Für die lokale Konfiguration werden diese Konfigurationsdateien innerhalb der Build-Verzeichnissen benötigt:
|
||||
## 7. Lizenz
|
||||
|
||||
> $HOME/build/poky-3.2.4/build/```<machine>```/conf/local.conf
|
||||
MIT License
|
||||
|
||||
Diese generierte local.conf enthält nur wenige Zeilen, besitzt aber eine Zeile, die auf eine gemeinsame Konfigurationsdatei zeigt, die für alle Images und unterstützten Maschinentypen gültig ist und kann man mit eigenen Optionen füttern.
|
||||
|
||||
> $HOME/build/local.conf.common.inc
|
||||
|
||||
Diese **.inc** Datei wurde aus der geklonten Beispieldatei beim erstmaligen ausführen des init-Scripts erzeugt.
|
||||
|
||||
> local.conf.common.inc.sample
|
||||
|
||||
Diese Beispieldatei sollte unberührt bleiben, um mögliche Konflikte beim Aktualisieren des build-Repositories zu vermeiden und um zu sehen, was sich geändert haben könnte.
|
||||
|
||||
Nach einer Aktualisierung des build-Repositries könnten einige neue oder geänderte Optionen hinzugefügt oder entfernt worden sein, die nicht in die inkludierte Konfigurationsdatei übernommen werden. Diesen Fall sollte man in der eigenen Konfiguration berücksichtigen und falls erforderlich anpassen.
|
||||
Natürlich kann man ```$HOME/Build/poky-3.2.4/build/<machine>/conf/local.conf``` mit eigenen Anforderungen ändern und als separate Konfigurationsdatei für einen Maschinentyp verwenden.
|
||||
|
||||
#### Musterkonfiguration für bblayers.conf:
|
||||
> $HOME/build/poky-3.2.4/build/```<machine>```/conf/bblayers.conf
|
||||
|
||||
```bitbake
|
||||
# POKY_BBLAYERS_CONF_VERSION is increased each time build/conf/bblayers.conf
|
||||
# changes incompatibly
|
||||
POKY_BBLAYERS_CONF_VERSION = "2"
|
||||
|
||||
BBPATH = "${TOPDIR}"
|
||||
BBFILES ?= ""
|
||||
|
||||
BBLAYERS ?= " \
|
||||
/home/<username>build/poky-3.2.4/meta \
|
||||
/home/<username>/build/poky-3.2.4/meta-poky \
|
||||
/home/<username>/build/poky-3.2.4/meta-yocto-bsp \
|
||||
"
|
||||
BBLAYERS += " \
|
||||
/home/<username>/build/poky-3.2.4/meta-neutrino \
|
||||
/home/<username>/build/poky-3.2.4/meta-<machine-brand-or-bsp-name> \
|
||||
/home/<username>/build/poky-3.2.4/meta-openembedded/meta-oe \
|
||||
"
|
||||
BBLAYERS += " \
|
||||
/home/<username>/build/poky-3.2.4/meta-python2 \
|
||||
"
|
||||
BBLAYERS += " \
|
||||
/home/<username>/build/poky-3.2.4/meta-qt5 \
|
||||
"
|
||||
```
|
||||
|
||||
## Mehr Informationen
|
||||
## 8. Weiterführende Informationen
|
||||
Weitere Informationen zum Yocto Buildsystem:
|
||||
|
||||
* https://docs.yoctoproject.org/3.2.4/index.html
|
||||
* https://docs.yoctoproject.org
|
||||
|
||||
@@ -270,7 +270,6 @@ function create_local_config () {
|
||||
fi
|
||||
|
||||
# modify or upgrade config files inside conf directory
|
||||
LOCAL_CONFIG_FILE_INC_PATH=$BASEPATH/local.conf.common.inc
|
||||
if test -f $LOCAL_CONFIG_FILE_INC_PATH; then
|
||||
|
||||
if test -f $LOCAL_CONFIG_FILE_PATH; then
|
||||
@@ -346,6 +345,9 @@ function create_local_config () {
|
||||
|
||||
# add layer entries into bblayer.conf
|
||||
set_file_entry $BBLAYER_CONF_FILE "generated" '# auto generated entries by init script'
|
||||
if [[ -z "$PYTHON2_SRCREV" ]]; then
|
||||
PYTHON2_LAYER_NAME=""
|
||||
fi
|
||||
LAYER_LIST=" $TUXBOX_LAYER_NAME $META_MACHINE_LAYER $OE_LAYER_NAME/meta-oe $OE_LAYER_NAME/meta-networking $PYTHON2_LAYER_NAME $QT5_LAYER_NAME "
|
||||
for LL in $LAYER_LIST ; do
|
||||
if set_file_entry $BBLAYER_CONF_FILE $LL 'BBLAYERS += " '$BUILD_ROOT_DIR'/'$LL' "' == 1;then
|
||||
@@ -359,7 +361,7 @@ function create_local_config () {
|
||||
function create_dist_tree () {
|
||||
|
||||
# create dist dir
|
||||
DIST_BASEDIR="$BASEPATH/dist/$IMAGE_VERSION"
|
||||
DIST_BASEDIR="$DIST_DIR/$IMAGE_VERSION"
|
||||
if test ! -d "$DIST_BASEDIR"; then
|
||||
my_echo -e "\033[37;1mcreate dist directory:\033[0m $DIST_BASEDIR"
|
||||
do_exec "mkdir -p $DIST_BASEDIR"
|
||||
@@ -371,7 +373,7 @@ function create_dist_tree () {
|
||||
DEPLOY_DIR="$BUILD_ROOT/$DL/tmp/deploy"
|
||||
do_exec "ln -sf $DEPLOY_DIR $DIST_BASEDIR/$DL"
|
||||
if test -L "$DIST_BASEDIR/$DL/deploy"; then
|
||||
do_exec "unlink -v $DIST_BASEDIR/$DL/deploy"
|
||||
do_exec "unlink $DIST_BASEDIR/$DL/deploy"
|
||||
fi
|
||||
done
|
||||
}
|
||||
@@ -381,3 +383,103 @@ function MD5SUM () {
|
||||
MD5STAMP=`md5sum $MD5SUM_FILE |cut -f 1 -d " "`
|
||||
echo $MD5STAMP
|
||||
}
|
||||
|
||||
# Function for selecting for items included a custom entry
|
||||
function do_select() {
|
||||
local items="$1"
|
||||
SELECTION=""
|
||||
local user_input
|
||||
local valid_selection=0
|
||||
|
||||
IFS=' ' read -r -a items_array <<< "$items"
|
||||
|
||||
echo "Please select one or more entries (numbers separated by spaces):"
|
||||
local i=1
|
||||
for item in "${items_array[@]}"; do
|
||||
printf "[%2d] %s\n" "$i" "$item"
|
||||
((i++))
|
||||
done
|
||||
printf "\n[%2d] %s\n" "$i" "Enter custom"
|
||||
|
||||
printf "\nEnter the numbers of the entries or [$i] for custom entry: "
|
||||
read -r user_input
|
||||
|
||||
for choice in $user_input; do
|
||||
if [[ "$choice" =~ ^[0-9]+$ ]]; then
|
||||
if [ "$choice" -ge 1 ] && [ "$choice" -lt "$i" ]; then
|
||||
SELECTION+="${items_array[$choice-1]} "
|
||||
valid_selection=1
|
||||
elif [ "$choice" -eq "$i" ]; then
|
||||
echo "Enter your custom entry:"
|
||||
read -r custom_entry
|
||||
SELECTION+="$custom_entry "
|
||||
valid_selection=1
|
||||
else
|
||||
my_echo "Invalid selection: $choice"
|
||||
fi
|
||||
else
|
||||
my_echo "Invalid selection: $choice"
|
||||
fi
|
||||
done
|
||||
|
||||
if [ "$valid_selection" -eq 0 ]; then
|
||||
my_echo "No valid selection made. Process aborted."
|
||||
return 1
|
||||
fi
|
||||
|
||||
# Remove the last space
|
||||
SELECTION=$(echo "$SELECTION" | sed 's/ $//')
|
||||
|
||||
my_echo "Selected entries: $SELECTION"
|
||||
# Return the selected machines as a string
|
||||
#"$SELECTION" has global scope
|
||||
}
|
||||
|
||||
|
||||
# Reset the build. Nothing is deleted, but rather renamed for safety.
|
||||
# Users can then decide when they want to clean up permanently.
|
||||
function do_reset() {
|
||||
# Make selection and save in a variable
|
||||
do_select "$MACHINES"
|
||||
local selected_machines=$SELECTION
|
||||
|
||||
# Check if a selection was made
|
||||
if [ -z "$selected_machines" ]; then
|
||||
return
|
||||
fi
|
||||
|
||||
# Set the start directory from where the search should begin
|
||||
local start_directory="$BUILD_ROOT_DIR" # Adjust to base directory
|
||||
local rename_success=0 # Tracks if a rename was performed
|
||||
|
||||
# Process the selected machines
|
||||
IFS=' ' read -r -a machines_array <<< "$selected_machines"
|
||||
for machine in "${machines_array[@]}"; do
|
||||
my_echo "Reset is being carried out for: $machine"
|
||||
|
||||
# Save results from find in an array
|
||||
readarray -t found_dirs < <(find "$start_directory" -type f -name "saved_tmpdir")
|
||||
|
||||
# Check if the array contains elements
|
||||
for dir in "${found_dirs[@]}"; do
|
||||
# Read the path from the file
|
||||
tmp_dir_path=$(cat "$dir")
|
||||
# Check if the path exists and matches the machine name
|
||||
if [[ -d "$tmp_dir_path" && "$tmp_dir_path" == *"/$machine/tmp"* ]]; then
|
||||
local timestamp=$(date '+%Y%m%d_%H%M%S')
|
||||
do_exec "mv "$tmp_dir_path" "${tmp_dir_path%/*}/tmp_${timestamp}""
|
||||
my_echo "Folder $tmp_dir_path was renamed to ${tmp_dir_path%/*}/tmp_${timestamp}."
|
||||
rename_success=1
|
||||
break # Exit the loop after the first successful rename
|
||||
fi
|
||||
done
|
||||
done
|
||||
|
||||
# Check if reset was performed
|
||||
if [ "$rename_success" -eq 0 ]; then
|
||||
my_echo "\033[33mNo reset could be performed.\033[0m"
|
||||
else
|
||||
my_echo "Reset succeeded."
|
||||
fi
|
||||
}
|
||||
|
||||
|
||||
174
init.sh
174
init.sh
@@ -2,8 +2,10 @@
|
||||
source init.functions.sh
|
||||
#set -x
|
||||
|
||||
## Comatible image version
|
||||
IMAGE_VERSION="3.2.4"
|
||||
## Comatible and default image version
|
||||
DEFAULT_IMAGE_VERSION="3.2.4"
|
||||
COMPATIBLE_IMAGE_VERSIONS="$DEFAULT_IMAGE_VERSION 3.2"
|
||||
IMAGE_VERSION="$DEFAULT_IMAGE_VERSION"
|
||||
|
||||
## global vars
|
||||
BASEPATH=$(pwd)
|
||||
@@ -12,9 +14,10 @@ GIT_SSH_KEYFILE=""
|
||||
true="1"
|
||||
false="0"
|
||||
DO_UPDATE=$false
|
||||
DO_RESET=$false
|
||||
FILES_DIR="$BASEPATH/files"
|
||||
HTTPD_DIST_HOSTNAME="localhost"
|
||||
HTTPD_DIST_DIR="/var/www/html/dist"
|
||||
UPDATE_SERVER_URL="http://localhost"
|
||||
DIST_DIR="$BASEPATH/dist"
|
||||
USER_CALL="$0 $@"
|
||||
|
||||
## Basename of this script
|
||||
@@ -30,24 +33,16 @@ rm -f $TMP_LOGFILE
|
||||
LOGFILE_NAME="$NAME"_"$TIMESTAMP.log"
|
||||
LOGFILE=$LOG_PATH/$LOGFILE_NAME
|
||||
LOGFILE_LINK=$LOG_PATH/$NAME.log
|
||||
LOCAL_CONFIG_FILE_INC_PATH=$BASEPATH/local.conf.common.inc
|
||||
echo "" > $LOGFILE
|
||||
ln -sf $LOGFILE $LOGFILE_LINK
|
||||
my_echo "true" "$USER_CALL"
|
||||
|
||||
## Current build env script version
|
||||
VERSION=$(git -C $BASEPATH describe --tags 2>/dev/null)
|
||||
if [ -z "$VERSION" ]; then
|
||||
VERSION="$IMAGE_VERSION"
|
||||
BUILD_ENV_VERSION=$(git -C $BASEPATH describe --tags 2>/dev/null)
|
||||
if [ -z "$BUILD_ENV_VERSION" ]; then
|
||||
BUILD_ENV_VERSION="unknown"
|
||||
fi
|
||||
INIT_VERSION="$NAME $VERSION"
|
||||
|
||||
## Preset required branches and revs
|
||||
COMPATIBLE_BRANCH="gatesgarth"
|
||||
COMPATIBLE_TAG="$IMAGE_VERSION"
|
||||
YOCTO_SRCREV="bc71ec0"
|
||||
PYTHON2_SRCREV="27d2aeb"
|
||||
OE_SRCREV="f3f7a5f"
|
||||
|
||||
|
||||
## Machines
|
||||
# Identical listings
|
||||
@@ -78,20 +73,6 @@ BACKUP_PATH=$BASEPATH/backups
|
||||
mkdir -p $BACKUP_PATH
|
||||
BACKUP_SUFFIX=bak
|
||||
|
||||
## Layer sources
|
||||
YOCTO_GIT_URL="https://git.yoctoproject.org/git/poky"
|
||||
POKY="poky"
|
||||
POKY_NAME="$IMAGE_VERSION"
|
||||
BUILD_ROOT_DIR="$BASEPATH/$POKY-$IMAGE_VERSION"
|
||||
BUILD_ROOT="$BUILD_ROOT_DIR/build"
|
||||
|
||||
OE_LAYER_NAME=meta-openembedded
|
||||
OE_LAYER_GIT_URL=https://git.openembedded.org/meta-openembedded
|
||||
OE_LAYER_PATCH_LIST="0001-openembedded-disable-meta-python.patch 0002-openembedded-disable-openembedded-layer-meta-phyton.patch"
|
||||
|
||||
OE_CORE_LAYER_NAME=openembedded-core
|
||||
OE_CORE_LAYER_GIT_URL=https://github.com/openembedded/openembedded-core.git
|
||||
|
||||
# meta-neutrino project URL:
|
||||
PROJECT_URL="https://github.com/tuxbox-neutrino"
|
||||
|
||||
@@ -109,19 +90,21 @@ show_help() {
|
||||
echo ""
|
||||
echo "Options:"
|
||||
echo " -m, --machine $HINT_MACHINES"
|
||||
echo " --httpd-dist-hostname IP or hostname (optional with portname) to define the update server address for local.conf.common.inc, default: $HTTPD_DIST_HOSTNAME"
|
||||
echo " --httpd-dist-dir Directory where the local httpd server find the deployed images and packages, default: $HTTPD_DIST_DIR"
|
||||
echo " --update-url URL (IP, hostname or domain, optional with portnumber) to define the update server address for $LOCAL_CONFIG_FILE_INC_PATH, default: $UPDATE_SERVER_URL"
|
||||
echo " --dist-dir Directory where to find the deployed images and packages, default: $DIST_DIR"
|
||||
echo " -p, --project-url Project-URL where to find project meta layers,"
|
||||
echo " e.g. for read and write access: git@github.com:tuxbox-neutrino, default = $PROJECT_URL"
|
||||
echo " --image-version Sets the required image version to build, possible versions are: $COMPATIBLE_IMAGE_VERSIONS, default = $DEFAULT_IMAGE_VERSION"
|
||||
echo " -u, --update Update your project meta layers"
|
||||
echo " -r, --reset Resets the tmp dir within the build directory, $BASEPATH/poky-x.x.x/build/<machine>/tmp. The /tmp directory will be not deleted but renamed"
|
||||
echo " -i, --id-rsa-file Path to your preferred id rsa file, default: users id rsa file, e.g. $HOME/.ssh/id_rsa"
|
||||
echo ""
|
||||
echo " -h, --help Show this help"
|
||||
echo " --version Show version information"
|
||||
echo " --version Show version information for buildenv script"
|
||||
}
|
||||
|
||||
## Processing command line arguments
|
||||
TEMP=$(getopt -o up:m:i:h --long httpd-dist-hostname:,httpd-dist-dir:,update,project-url:,machine:,id-rsa-file,help,version -n 'init' -- "$@")
|
||||
TEMP=$(getopt -o rup:m:i:h --long reset,update-url:,dist-dir:,update,project-url:,machine:,id-rsa-file,image-version:,help,version -n 'init' -- "$@")
|
||||
if [ $? != 0 ] ; then
|
||||
my_echo "Error while process arguments" >&2
|
||||
show_help
|
||||
@@ -140,23 +123,63 @@ while true ; do
|
||||
MACHINE="$2"; shift 2 ;;
|
||||
-i|--id-rsa-file)
|
||||
GIT_SSH_KEYFILE="$2"; shift 2 ;;
|
||||
--httpd-dist-hostname)
|
||||
HTTPD_DIST_HOSTNAME="$2"; shift 2 ;;
|
||||
--httpd-dist-dir)
|
||||
HTTPD_DIST_DIR="$2"; shift 2 ;;
|
||||
--update-url)
|
||||
UPDATE_SERVER_URL="$2"; shift 2 ;;
|
||||
--dist-dir)
|
||||
DIST_DIR="$2"; shift 2 ;;
|
||||
-u|--update)
|
||||
DO_UPDATE="$true"; shift ;;
|
||||
-r|--reset)
|
||||
DO_RESET="$true"; shift ;;
|
||||
--image-version)
|
||||
IMAGE_VERSION="$2"; shift 2 ;;
|
||||
-h|--help)
|
||||
show_help
|
||||
exit 0 ;;
|
||||
--version)
|
||||
echo "$INIT_VERSION"
|
||||
echo "$BUILD_ENV_VERSION"
|
||||
exit 0 ;;
|
||||
--) shift ; break ;;
|
||||
*) echo "Internal Error!" ; exit 1 ;;
|
||||
esac
|
||||
done
|
||||
|
||||
## Validate the chosen image version
|
||||
if [[ ! " $COMPATIBLE_IMAGE_VERSIONS " =~ " $IMAGE_VERSION " ]]; then
|
||||
my_echo "\033[31;1mError: Invalid image version specified '$IMAGE_VERSION'. Available versions are: [$COMPATIBLE_IMAGE_VERSIONS]\033[0m"
|
||||
exit 1
|
||||
fi
|
||||
|
||||
## Layer sources
|
||||
YOCTO_GIT_URL="https://git.yoctoproject.org/git/poky"
|
||||
POKY="poky"
|
||||
POKY_NAME="$IMAGE_VERSION" #TODO
|
||||
BUILD_ROOT_DIR="$BASEPATH/$POKY-$IMAGE_VERSION"
|
||||
BUILD_ROOT="$BUILD_ROOT_DIR/build"
|
||||
|
||||
OE_LAYER_NAME=meta-openembedded
|
||||
OE_LAYER_GIT_URL=https://git.openembedded.org/meta-openembedded
|
||||
OE_LAYER_PATCH_LIST=""
|
||||
|
||||
OE_CORE_LAYER_NAME=openembedded-core
|
||||
OE_CORE_LAYER_GIT_URL=https://github.com/openembedded/openembedded-core.git
|
||||
|
||||
## Preset required branches and revs based on the selected image version
|
||||
case "$IMAGE_VERSION" in
|
||||
"3.2"|"3.2.4")
|
||||
COMPATIBLE_TAG="$IMAGE_VERSION"
|
||||
COMPATIBLE_BRANCH="gatesgarth"
|
||||
YOCTO_SRCREV="bc71ec0"
|
||||
PYTHON2_SRCREV="27d2aeb"
|
||||
OE_SRCREV="f3f7a5f"
|
||||
OE_LAYER_PATCH_LIST="0001-openembedded-disable-meta-python.patch 0002-openembedded-disable-openembedded-layer-meta-phyton.patch"
|
||||
;;
|
||||
*)
|
||||
my_echo "\033[31;1mError: No valid configuration for the specified image version '$IMAGE_VERSION'.\033[0m"
|
||||
exit 1
|
||||
;;
|
||||
esac
|
||||
|
||||
# Check machine type
|
||||
if [ $(is_valid_machine "$MACHINE") == false ]; then
|
||||
my_echo "\033[31;1mNo valid machine defined.\033[0m"
|
||||
@@ -165,18 +188,25 @@ if [ $(is_valid_machine "$MACHINE") == false ]; then
|
||||
fi
|
||||
|
||||
my_echo "------------------------------------------------------------------------------------------"
|
||||
my_echo "Buildenv Version: \033[37;1m$INIT_VERSION\033[0m "
|
||||
my_echo "Buildenv Version: \033[37;1m$BUILD_ENV_VERSION\033[0m "
|
||||
my_echo "Image Version: \033[37;1m$IMAGE_VERSION\033[0m "
|
||||
my_echo "Compatible OE-branch: \033[37;1m$COMPATIBLE_BRANCH\033[0m "
|
||||
my_echo "httpd Dist hostname: \033[37;1m$HTTPD_DIST_HOSTNAME\033[0m "
|
||||
my_echo "httpd Dist directory: \033[37;1m$HTTPD_DIST_DIR\033[0m "
|
||||
my_echo "Machine: \033[37;1m$MACHINE\033[0m "
|
||||
my_echo "Buildroot directory: \033[37;1m$BUILD_ROOT_DIR\033[0m "
|
||||
my_echo "Update Server URL: \033[37;1m$UPDATE_SERVER_URL\033[0m "
|
||||
my_echo "Dist directory: \033[37;1m$DIST_DIR\033[0m "
|
||||
my_echo "Configured Machine(s): \033[37;1m$MACHINE\033[0m "
|
||||
my_echo "Project Repository URL: \033[37;1m$PROJECT_URL\033[0m "
|
||||
my_echo "SRCREV Yocto: \033[37;1m$YOCTO_SRCREV\033[0m "
|
||||
my_echo "SRCREV OE: \033[37;1m$OE_SRCREV\033[0m "
|
||||
my_echo "SRCREV Python2: \033[37;1m$PYTHON2_SRCREV\033[0m "
|
||||
my_echo "------------------------------------------------------------------------------------------"
|
||||
|
||||
## reset build
|
||||
if [[ $DO_RESET == "$true" ]]; then
|
||||
do_reset "$MACHINES"
|
||||
exit 0
|
||||
fi
|
||||
|
||||
## Fetch meta sources
|
||||
# fetch required branch from yocto
|
||||
fetch_meta "" $COMPATIBLE_BRANCH $YOCTO_GIT_URL $YOCTO_SRCREV $BUILD_ROOT_DIR
|
||||
@@ -188,10 +218,12 @@ fetch_meta "" $COMPATIBLE_BRANCH $OE_LAYER_GIT_URL $OE_SRCREV $BUILD_ROOT_DIR/$O
|
||||
fetch_meta "" master $OE_CORE_LAYER_GIT_URL "" $BUILD_ROOT_DIR/$OE_CORE_LAYER_NAME
|
||||
|
||||
# fetch required branch for meta-python2
|
||||
PYTHON2_LAYER_NAME=meta-python2
|
||||
PYTHON2_LAYER_GIT_URL=https://git.openembedded.org/$PYTHON2_LAYER_NAME
|
||||
PYTHON2_PATCH_LIST="0001-local_conf_outcomment_line_15.patch"
|
||||
fetch_meta "" $COMPATIBLE_BRANCH $PYTHON2_LAYER_GIT_URL $PYTHON2_SRCREV $BUILD_ROOT_DIR/$PYTHON2_LAYER_NAME "$PYTHON2_PATCH_LIST"
|
||||
if [[ -n "$PYTHON2_SRCREV" ]]; then
|
||||
PYTHON2_LAYER_NAME=meta-python2
|
||||
PYTHON2_LAYER_GIT_URL=https://git.openembedded.org/$PYTHON2_LAYER_NAME
|
||||
PYTHON2_PATCH_LIST="0001-local_conf_outcomment_line_15.patch"
|
||||
fetch_meta "" $COMPATIBLE_BRANCH $PYTHON2_LAYER_GIT_URL $PYTHON2_SRCREV $BUILD_ROOT_DIR/$PYTHON2_LAYER_NAME "$PYTHON2_PATCH_LIST"
|
||||
fi
|
||||
|
||||
# fetch required branch for meta-qt5
|
||||
QT5_LAYER_NAME=meta-qt5
|
||||
@@ -257,9 +289,10 @@ fi
|
||||
|
||||
## Configure buildsystem
|
||||
# Create included config file from sample file
|
||||
if test ! -f $BASEPATH/local.conf.common.inc; then
|
||||
my_echo "\033[37;1mCONFIG:\033[0mCreate $BASEPATH/local.conf.common.inc as include file for local layer configuration ..."
|
||||
do_exec "cp -v $BASEPATH/local.conf.common.inc.sample $BASEPATH/local.conf.common.inc"
|
||||
if test ! -f $LOCAL_CONFIG_FILE_INC_PATH; then
|
||||
my_echo "\033[37;1mCONFIG:\033[0mCreate $LOCAL_CONFIG_FILE_INC_PATH as include file for local layer configuration ..."
|
||||
do_exec "cp -v $LOCAL_CONFIG_FILE_INC_PATH.sample $LOCAL_CONFIG_FILE_INC_PATH"
|
||||
do_exec "sed -i -e 's|#UPDATE_SERVER_URL = \"http://@hostname@\"|UPDATE_SERVER_URL = \"${UPDATE_SERVER_URL}\"|' $LOCAL_CONFIG_FILE_INC_PATH"
|
||||
fi
|
||||
|
||||
# Create configuration for machine
|
||||
@@ -277,17 +310,13 @@ fi
|
||||
## Create distribution structure
|
||||
create_dist_tree;
|
||||
|
||||
## check and create distribution directory inside httpd directory for online update
|
||||
if test ! -L $HTTPD_DIST_DIR; then
|
||||
my_echo "\033[37;1mLocal setup for package online update.\033[0m"
|
||||
my_echo "------------------------------------------------------------------------------------------------"
|
||||
my_echo "The httpd directory $HTTPD_DIST_DIR doesn't exists."
|
||||
my_echo "If you want to use online update, please configure your webserver and use dist content"
|
||||
my_echo ""
|
||||
my_echo "An easy way is to create a symlink to dist directory:"
|
||||
my_echo ""
|
||||
my_echo "\033[37;1m\tsudo ln -s $BASEPATH/dist $HTTPD_DIST_DIR\033[0m"
|
||||
fi
|
||||
## Distribution directory inside httpd directory for online update
|
||||
my_echo "\033[37;1mLocal setup for package online update.\033[0m"
|
||||
my_echo "------------------------------------------------------------------------------------------------"
|
||||
my_echo "If you want to use online update for your devices, please configure your webserver and use the"
|
||||
my_echo "content of $DIST_DIR"
|
||||
my_echo "as destination for your webserver (e.g. apache, nginx, lighttpd or what ever you want)"
|
||||
my_echo ""
|
||||
|
||||
## Show results
|
||||
my_echo "\033[32;1m\nSummary:\033[0m"
|
||||
@@ -307,6 +336,16 @@ my_echo ""
|
||||
my_echo "\033[37;1m\t$BUILD_ROOT/<machine>/bblayer.conf\033[0m"
|
||||
my_echo "\033[37;1m\t$BUILD_ROOT/<machine>/local.conf\033[0m"
|
||||
|
||||
my_echo ""
|
||||
my_echo "\033[37;1mUpdating build evironment and meta-layers\033[0m"
|
||||
my_echo "------------------------------------------------------------------------------------------------"
|
||||
my_echo ""
|
||||
my_echo "\033[37;1m\texecute: $USER_CALL\033[0m \033[32;1m--update\033[0m"
|
||||
my_echo ""
|
||||
my_echo "------------------------------------------------------------------------------------------------"
|
||||
|
||||
my_echo "\033[32;1mDONE!\033[0m"
|
||||
|
||||
my_echo ""
|
||||
my_echo "\033[37;1mStart build\033[0m"
|
||||
my_echo "------------------------------------------------------------------------------------------------"
|
||||
@@ -317,19 +356,10 @@ my_echo "\033[37;1m\t$MACHINES\033[0m"
|
||||
my_echo ""
|
||||
my_echo "Select your favorite machine (or identical) and the next steps are:\033[37;1m"
|
||||
my_echo ""
|
||||
my_echo "\tcd $BUILD_ROOT_DIR"
|
||||
my_echo "\t. ./oe-init-build-env build/<machine>"
|
||||
my_echo "\tcd $BUILD_ROOT_DIR && . ./oe-init-build-env build/<machine>"
|
||||
my_echo "\tbitbake neutrino-image"
|
||||
my_echo "\033[0m"
|
||||
|
||||
my_echo ""
|
||||
my_echo "\033[37;1mUpdating build evironment and meta-layers\033[0m"
|
||||
my_echo "------------------------------------------------------------------------------------------------"
|
||||
my_echo ""
|
||||
my_echo "\033[37;1m\texecute: $USER_CALL\033[0m \033[32;1m--update\033[0m"
|
||||
my_echo ""
|
||||
my_echo "------------------------------------------------------------------------------------------------"
|
||||
my_echo "For more informations and next steps take a look at the README.md!"
|
||||
my_echo "\033[32;1mDONE!\033[0m"
|
||||
my_echo "For more information and next steps take a look at the README.md!"
|
||||
|
||||
exit 0
|
||||
|
||||
@@ -242,15 +242,12 @@ DISTRO_TYPE = "beta"
|
||||
# where do find the buildsystem the distro type file (beta.txt, release.txt ...), this file contains list of image urls for download
|
||||
#RELEASE_TEXT_LOCATION_FILE = "${DEPLOY_DIR_IMAGE}/${DISTRO_TYPE}.txt"
|
||||
|
||||
### Server URL which contains update and packages.
|
||||
### Server URL which contains update and packages, must contain the content of the deployed images and packages
|
||||
# Web server must be running and html content must point to the toplevel directory which contains the deployed images
|
||||
# NOTE: @hostname@ is only a placeholder and will be replaced with current hostname of your build host automatically. @hostname@ could be the current host IP too.
|
||||
# or any other domain.tld. If required, replace @hostname@ with the host IP or Domain.
|
||||
#UPDATE_SERVER_URL = "http://@hostname@"
|
||||
|
||||
## URL to the dist directory, must contain the content of the deployed images and packages
|
||||
#DIST_URL = "${UPDATE_SERVER_URL}/dist"
|
||||
|
||||
## URL to the images, must contain the content of the image dir and its a sub dir to specific machine build and image dir which contains machine images
|
||||
#IMAGE_LOCATION_URL = "${DIST_URL}/${DISTRO_VERSION}/${MACHINE}/images/${MACHINE}"
|
||||
|
||||
@@ -312,6 +309,7 @@ SHOUTCAST_DEV_KEY = ""
|
||||
# The WEATHER_DEV_KEY variable is not longer used for darksky keys
|
||||
# Currently used provider is: openweather map
|
||||
WEATHER_DEV_KEY = ""
|
||||
WEATHER_API_VERSION = "3.0"
|
||||
# NOTE: YouTube functionality of Neutrino was completely removed in 2022, this key has no effects anymore, but YouTube is usable further with plugins.
|
||||
YT_DEV_KEY = ""
|
||||
|
||||
@@ -322,13 +320,21 @@ YT_DEV_KEY = ""
|
||||
# NOTE! --enable-testing Works only with FLAVOUR = "tuxbox".
|
||||
# If you want to use a different FLAVOUR than 'tuxbox', keep these lines uncommented and
|
||||
# add them to your local.conf within your build directory.
|
||||
#EXTRA_OECONF_append_pn-neutrino-mp += " \
|
||||
#EXTRA_OECONF_append_pn-neutrino += " \
|
||||
# --enable-testing \
|
||||
#"
|
||||
## Uncomment these lines to disable debug mode for Neutrino.
|
||||
#EXTRA_OECONF_append_pn-neutrino-mp += " \
|
||||
#EXTRA_OECONF_append_pn-neutrino += " \
|
||||
# --without-debug \
|
||||
#"
|
||||
## Uncomment these lines to enable API-management via Neutrino.
|
||||
# EXTRA_OECONF_append_pn-neutrino += " \
|
||||
# --enable-tmdb-key-manage \
|
||||
# --enable-omdb-key-manage \
|
||||
# --enable-youtube-key-manage \
|
||||
# --enable-shoutcast-id-manage \
|
||||
# --enable-weather-key-manage \
|
||||
# "
|
||||
|
||||
### Extra build config options for gdb build
|
||||
#EXTRA_OECONF_append_pn-gdb = "--with-system-gdbinit=/etc/gdbinit"
|
||||
|
||||
Reference in New Issue
Block a user