mirrors/buildenv
1
0
Fork 0
mirror of https://github.com/tuxbox-neutrino/buildenv.git synced 2025-08-26 15:02:58 +02:00
Code Issues Packages Projects Releases Wiki Activity

readme: Automatically translated README

Browse Source
This commit is contained in:
Thilo Graf
2025-03-29 20:27:21 +00:00
parent 1ff67985ec
commit 116cc557dc
2 changed files with 119 additions and 100 deletions
Download Patch File Download Diff File Expand all files Collapse all files

5
README_de.md
View File

@@ -120,7 +120,6 @@ Nach [Schritt 1.4](#14-init-skript-ausführen) sollte etwa diese Struktur angele
└── <machine y> <-- weiteres Build-Unterverzeichnis für Maschinentyp y └── <machine y> <-- weiteres Build-Unterverzeichnis für Maschinentyp y
``` ```
## 2. Image bauen ## 2. Image bauen
Stelle sicher, dass Du dich wie im [Schema](#15-struktur-der-buildumgebung) gezeigt hier befindest: Stelle sicher, dass Du dich wie im [Schema](#15-struktur-der-buildumgebung) gezeigt hier befindest:
@@ -194,7 +193,6 @@ Sollten keine Aktualisierungen notwendig sein, werden die Builds automatisch üb
bitbake neutrino-image bitbake neutrino-image
``` ```
### 3.2 Paket aktualisieren ### 3.2 Paket aktualisieren
```bash ```bash
@@ -255,7 +253,6 @@ Wenn Du deine Maschinen-Konfigurationen zurücksetzen möchtest, benenne bitte d
### 4.3 Recipes ### 4.3 Recipes
**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.** **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.**
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. 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.
@@ -333,7 +330,6 @@ anschließend neu bauen:
bitbake <target> bitbake <target>
``` ```
## 6. Vollständigen Imagebau erzwingen ## 6. Vollständigen Imagebau erzwingen
Das Init-Skript stellt dafür die Option `--reset` zur Verfügung. Das Init-Skript stellt dafür die Option `--reset` zur Verfügung.
@@ -341,6 +337,7 @@ Das Init-Skript stellt dafür die Option `--reset` zur Verfügung.
```bash ```bash
./init --reset ./init --reset
# Follow instructions # Follow instructions
``` ```
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: 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:

214
README_en.md
View File

@@ -1,48 +1,50 @@
<!-- LANGUAGE_LINKS_START --> <!-- LANGUAGE_LINKS_START -->
[🇩🇪 German](README_de.md) | <span style="color: grey;">🇬🇧 English</span> | [🇪🇸 Spanish](README_es.md) | [🇫🇷 French](README_fr.md) | [🇮🇹 Italian](README_it.md) [🇩🇪 German](README_de.md) | <span style="color: grey;">🇬🇧 English</span>
<!-- LANGUAGE_LINKS_END --> <!-- LANGUAGE_LINKS_END -->
This script serves as a tool to simplify the creation of a development environment and the build process for images running on different hardware platforms using Neutrino as the user interface. It automates some of the steps required to set up a consistent and functional development and build environment by pre-setting up the necessary dependencies and basic configurations, meta layers, and enabling custom settings. The script aims to provide a foundation upon which to build, experiment, and create, update, and maintain your own customized versions of Tuxbox-Neutrino images. This script serves as a tool to simplify the creation of a development environment and the build process for images that run with Neutrino as a user interface on different hardware platforms. It automates some steps that are required to set up a consistent and functional development and build environment by pre-configuring the necessary dependencies and basic configurations as well as meta-layers and enabling custom settings. The script aims to provide a foundation on which to build and experiment to create, update, and maintain your own customized versions of Tuxbox-Neutrino images.
[![Version](https://img.shields.io/badge/version-0.5.10-blue.svg)](https://github.com/dbt1/tuxbox-explorer) [![Version](https://img.shields.io/badge/version-0.5.7-blue.svg)](https://github.com/tuxbox-neutrino/buildenv)
- [1. Preparation](#1-preparation) - [1. Preparation](#1-preparation)
- [1.1 Install required host packages](#11-install-required-host-packages) - [1.1 Install required host packages](#11-install-required-host-packages)
- [1.1.1 Recommended additional packages for graphical support and analysis](#111-recommended-additional-packages-for-graphical-support-and-analysis) - [1.1.1 Recommended additional packages for graphical support and analysis](#111-recommended-additional-packages-for-graphical-support-and-analysis)
- [1.2 Prepare Git (if necessary)](#12-prepare-git-if-necessary) - [1.2 Prepare Git (if necessary)](#12-prepare-git-if-necessary)
- [1.3 Clone init script](#13-clone-init-script) - [1.3 Clone Init script](#13-clone-init-script)
- [1.4 Run init script](#14-run-init-script) - [1.4 Run Init script](#14-run-init-script)
- [1.5 Structure of the build environment](#15-structure-of-the-build-environment) - [1.5 Structure of the build environment](#15-structure-of-the-build-environment)
- [2. Build image](#2-build-an-image) - [2. Building an image](#2-building-an-image)
- [2.1 Select Box](#21-select-box) - [2.1 Choose a box](#21-choose-a-box)
- [2.2 Start environment script](#22-start-environment-script) - [2.2 Start the environment script](#22-start-the-environment-script)
- [2.3 Create Image](#23-create-image) - [2.3 Create an image](#23-create-an-image)
- [3. Update](#3-update) - [3. Updates](#3-updates)
- [3.1 Update Image](#31-update-image) - [3.1 Update image](#31-update-image)
- [3.2 Update package](#32-update-package) - [3.2 Update package](#32-update-package)
- [3.3 Update meta layer repositories](#33-update-meta-layer-repositories) - [3.3 Update meta-layer repositories](#33-update-meta-layer-repositories)
- [4. Custom adjustments](#4-customizations) - [4. Custom modifications](#4-custom-modifications)
- [4.1 Configuration](#41-configuration) - [4.1 Configuration](#41-configuration)
- [4.1.1 Configuration files](#411-configuration-files) - [4.1.1 Configuration files](#411-configuration-files)
- [4.1.2 bblayers.conf](#412-bblayersconf) - [4.1.2 bblayers.conf](#412-bblayersconf)
- [4.1.3 Reset configuration](#413-reset-configuration) - [4.1.3 Reset configuration](#413-reset-configuration)
- [4.3 Recipes](#43-recipes) - [4.3 Recipes](#43-recipes)
- [4.4 Packages](#44-packages) - [4.4 Packages](#44-packages)
- [4.4.1 Edit source code in the workspace (example)](#441-edit-source-code-in-the-workspace-example) - [4.4.1 Edit source code in workspace (example)](#441-edit-source-code-in-workspace-example)
- [5. Force rebuild a single package](#5-force-rebuild-a-single-package) - [5. Force rebuilding a single package](#5-force-rebuilding-a-single-package)
- [6. Force complete image construction](#6-force-complete-image-construction) - [6. Force complete image build](#6-force-complete-image-build)
- [7. License](#7-license) - [7. License](#7-license)
- [8. Further information](#8-further-information) - [8. Further information](#8-further-information)
## 1. Preparation ## 1. Preparation
It is recommended at this point to use the Docker container provided for this purpose, as this already completes the essential steps so that you can get started with as few adjustments to your system as possible. [see docker-buildenv](https://github.com/tuxbox-neutrino/docker-buildenv). In this case you can start immediately [with the initialization](#14-run-init-script). It is recommended to use the designated Docker container, as this already takes care of significant steps to get started with as few adjustments to your system as possible. [See docker-buildenv](https://github.com/tuxbox-neutrino/docker-buildenv). In this case, you can begin directly [with the initialization](#14-run-init-script).
**NOTE:** [docker-buildenv](https://github.com/tuxbox-neutrino/docker-buildenv) completely replaces the [Tuxbox-Builder](https://sourceforge.net/projects/n4k/files/Tuxbox-Builder) VM. Their maintenance will no longer be continued. **NOTE:** [docker-buildenv](https://github.com/tuxbox-neutrino/docker-buildenv) completely replaces the [Tuxbox-Builder](https://sourceforge.net/projects/n4k/files/Tuxbox-Builder) VM. Its maintenance will no longer be continued.
Paths specified here are based on defaults created by the Init script. Some entries are displayed as ```<placeholder>``` which must be adjusted locally. [See schema](#14-run-init-script)
Paths specified here are based on specifications generated by the init script. Some entries are represented as ```<Platzhalter>```, which need to be adjusted locally. [See diagram](#14-run-init-script)
### 1.1 Install required host packages ### 1.1 Install required host packages
**Note:** If using other distributions see: [Yocto Project Quick Build](https://docs.yoctoproject.org/3.2.4/ref-manual/ref-system-requirements.html#supported-linux-distributions) **Note:** For other distributions, see: [Yocto Project Quick Build](https://docs.yoctoproject.org/3.2.4/ref-manual/ref-system-requirements.html#supported-linux-distributions)
Debian 11 Debian 11
@@ -62,100 +64,107 @@ python3-git python3-jinja2 libegl1-mesa pylint3 xterm subversion locales-all lib
ninja-build default-jre clisp libcapstone4 libsdl2-dev doxygen ninja-build default-jre clisp libcapstone4 libsdl2-dev doxygen
``` ```
**NOTE:** On Debian 10 (buster) use libcapstone3.
#### 1.1.1 Recommended additional packages for graphical support and analysis #### 1.1.1 Recommended additional packages for graphical support and analysis
```bash ```bash
sudo apt-get install -y gitk git-gui meld cppcheck clazy kdevelop sudo apt-get install -y gitk git-gui meld cppcheck clazy kdevelop
``` ```
### 1.2 Prepare Git (if necessary) ### 1.2 Prepare Git (if necessary)
The init script uses Git to clone the meta-layer repositories. If there is no Git configured yet, please create your global Git user data, otherwise this will be pointed out unnecessarily while the script is running. The init script uses Git to clone the meta-layer repositories. If you don't have Git configured yet, please set up your global Git user data, otherwise you'll receive unnecessary notices while the script is running.
```bash ```bash
git config --global user.email "you@example.com" git config --global user.email "you@example.com"
git config --global user.name "Dein Name" git config --global user.name "Your Name"
``` ```
### 1.3 Clone init script
### 1.3 Clone Init script
```bash ```bash
git clone https://github.com/tuxbox-neutrino/buildenv.git && cd buildenv git clone https://github.com/tuxbox-neutrino/buildenv.git && cd buildenv
``` ```
### 1.4 Run init script
### 1.4 Run Init script
```bash ```bash
./init && cd poky-3.2.4 ./init && cd poky-3.2.4
``` ```
### 1.5 Structure of the build environment ### 1.5 Structure of the build environment
After [Step 1.4](#14-run-init-script) this structure should have been created: After [step 1.4](#14-run-init-script), the structure should look approximately like this:
``` ```
.buildenv .buildenv
├── dist <-- Freigabeordner für http-Server (falls eingerichtet) http://localhost, http://localhost:8080 , benötigt für IPK-Feeds und Images ├── dist <-- Release folder for http server (if set up) http://localhost, http://localhost:8080, needed for IPK feeds and images
│ └── {DISTRO_VERSION} <-- hier liegen die erzeugten Images und Pakete (Symlinks zeigen auf die Deploy-Verzeichnisse innerhalb der Build-Unterverzeichnisse) │ └── {DISTRO_VERSION} <-- here are the generated images and packages (symlinks point to the deploy directories within the build subdirectories)
: :
├── init.sh <-- init-Script ├── init.sh <-- init script
├── local.conf.common.inc <-- globale Benutzerkonfiguration, ist in die benutzerdefinierte Konfiguration inkluiert ├── local.conf.common.inc <-- global user configuration, is included in the custom configuration
: :
├── log <-- Ordner für Logs, enthält Logs für jede Ausführung des Init-Scripts ├── log <-- folder for logs, contains logs for each execution of the init script
: :
└── poky-{DISTRO_VERSION} <-- Nach Schritt 1.4 befindest Du dich hier. Hier befindet sich der Buildsystem-Kern und die Meta-Layer └── poky-{DISTRO_VERSION} <-- After step 1.4 you are here. This is where the build system core and the meta-layers are located
│ │
: :
└── build <-- Hier liegen die Build-Unterverzeichnisse, nach Schritt 2.2 befindest Du dich in einem dieser Build-Unterverzeichnisse └── build <-- Here are the build subdirectories, after step 2.2 you will be in one of these build subdirectories
├── <machine x> <-- Build-Unterverzeichnis für Maschinentyp x ├── <machine x> <-- Build subdirectory for machine type x
│ ├── conf <-- Ordner für Layer und benutzerdefinierte Konfiguration │ ├── conf <-- Folder for layer and custom configuration
│ │ └── bblayers.conf <-- Konfigurationsdatei für eingebundene Meta-Layer │ │ └── bblayers.conf <-- Configuration file for included meta-layers
│ │ └── local.conf <-- benutzerdefinierte Konfiguration für einen Maschinentyp │ │ └── local.conf <-- custom configuration for a machine type
│ : │ :
│ ├── (tmp) <-- Arbeitsverzeichnis, wird beim Bauen automatisch angelegt │ ├── (tmp) <-- Working directory, automatically created during building
│ └── (workspace) <-- Workspace, wird beim Ausführen von devtool angelegt │ └── (workspace) <-- Workspace, created when running devtool
: :
└── <machine y> <-- weiteres Build-Unterverzeichnis für Maschinentyp y └── <machine y> <-- Another build subdirectory for machine type y
``` ```
## 2. Build an image
Make sure you are here as shown in [schema](#15-structure-of-the-build-environment): ## 2. Building an image
Make sure you are here as shown in the [schema](#15-structure-of-the-build-environment):
``` ```
poky-{DISTRO_VERSION} poky-{DISTRO_VERSION}
``` ```
### 2.1 Select box
View a list of available devices: ### 2.1 Choose a box
Display a list of available devices:
```bash ```bash
ls build ls build
``` ```
### 2.2 Start environment script
Run the environment script once for the box you want from the list! You will then automatically be taken to the appropriate build subdirectory. ### 2.2 Start the environment script
Run the environment script once for the desired box from the list! You will then automatically be taken to the appropriate build subdirectory.
```bash ```bash
. ./oe-init-build-env build/<machine> . ./oe-init-build-env build/<machine>
``` ```
As long as you are now in the desired build subdirectory with the created environment within the open shell, you do not have to run this script again and can build [Step 2.3 ](#23-create-image) images or any packages. As long as you are now in the generated environment within the opened shell in the desired build subdirectory, you don't need to run this script again and can [step 2.3](#23-create-an-image) build images or any packages.
**Note:** You can also create additional shells and thus build environments for other box types in parallel and, if necessary, switch to the appropriate terminal and have them built in parallel, if your system allows it. **Note:** You can also create additional shells and thus build environments for other box types in parallel and switch to the corresponding terminal as needed and also build in parallel, if your system can handle it.
### 2.3 Create image
### 2.3 Create an image
```bash ```bash
bitbake neutrino-image bitbake neutrino-image
``` ```
This may take a while. Some warning messages can be ignored. Error messages affecting the setscene tasks are not a problem, but errors during the build and package tasks terminate the process in most cases. [In this case, please report the error or share your solution](https://forum.tuxbox-neutrino.org/forum/viewforum.php?f=77). Help is very welcome. This may take a while. Some warnings can be ignored. Error messages related to setscene tasks are not a problem, but errors during build and package tasks will abort the process in most cases. [Please report the error or share your solution in this case](https://forum.tuxbox-neutrino.org/forum/viewforum.php?f=77). Help is much appreciated.
When everything is done, you should see a message similar to this: When everything is done, a message similar to this should appear:
```bash ```bash
"NOTE: Tasks Summary: Attempted 4568 tasks of which 4198 didn't need to be rerun and all succeeded." "NOTE: Tasks Summary: Attempted 4568 tasks of which 4198 didn't need to be rerun and all succeeded."
``` ```
<span style="color: green;">That's it...</span> <span style="color: green;">That's it ...</span>
You can find results at: You can find results under:
```bash ```bash
buildenv/poky-{DISTRO_VERSION}/build/<machine>/tmp/deploy buildenv/poky-{DISTRO_VERSION}/build/<machine>/tmp/deploy
@@ -167,87 +176,97 @@ or in the release directory:
buildenv/dist/<Image-Version>/<machine>/ buildenv/dist/<Image-Version>/<machine>/
``` ```
If a web server is set up that points to the share directory: If a web server is set up that points to the release directory:
```bash ```bash
http://localhost/{DISTRO_VERSION} oder mit Portnummer http://localhost:8080/{DISTRO_VERSION} http://localhost/{DISTRO_VERSION} or with port number http://localhost:8080/{DISTRO_VERSION}
``` ```
## 3. Update
Manual updates of the packages are not required. This is done automatically for every target called with Bitbake. This also applies to possible dependencies. If you want to have full control over certain package sources, you can store them in the designated workspace for each package, see [4.4 Packages](#44-packages). ## 3. Updates
Manual updates of packages are not required. This is done automatically with each target called with Bitbake. This also applies to possible dependencies. If you want full control over specific package sources, you can place them for each package in the designated workspace, see [4.4 Packages](#44-packages).
If no updates are necessary, the builds are automatically skipped. If no updates are necessary, the builds are automatically skipped.
### 3.1 Update image ### 3.1 Update image
```bash ```bash
bitbake neutrino-image bitbake neutrino-image
``` ```
### 3.2 Update package ### 3.2 Update package
```bash ```bash
bitbake <package> bitbake <package>
``` ```
### 3.3 Update meta layer repositories
Executing the init script with the ```--update``` parameter updates the included meta layers to the status of the remote repositories. ### 3.3 Update meta-layer repositories
Running the init script with the ```--update``` parameter updates the included meta-layers to the state of the remote repositories.
```bash ```bash
./init --update ./init --update
``` ```
If you have made changes to the meta layers, the init script update routines should temporarily stash uncommitted changes or rebase them on the local repository. Of course, you can manually update your local meta layers for meta neutrino and machine layer repositories. However, conflicts always have to be resolved manually. If you have made changes to the meta-layers, non-committed changes should be temporarily stashed or rebased onto the local repository by triggered update routines of the init script. Of course, you can manually update your local meta-layers for meta-neutrino and machine layer repositories. However, conflicts must always be resolved manually.
**Note:** Configuration files remain essentially untouched, but possible variable names are migrated. New or changed settings will not be changed. Please check the configuration if necessary. **Note:** Configuration files remain essentially untouched, but possible variable names will be migrated. New or changed settings will not be modified. Please check the configuration if necessary.
## 4. Customizations
## 4. Custom modifications
### 4.1 Configuration ### 4.1 Configuration
It is recommended to build for the first time without modified configuration files to get an idea of ​​how the build process works and to see the results as quickly as possible. It is recommended to build for the first time without changed configuration files to get an impression of how the build process works and to see the results as quickly as possible.
The setting options are very extensive and not really manageable for beginners. However, the Yocto Project in particular is very OpenEmbedded The setting options are very extensive and not really manageable for beginners. However, OpenEmbedded, especially the Yocto Project, is very comprehensively documented and offers the best source of information.
comprehensively documented and provides the best source of information.
#### 4.1.1 Configuration files #### 4.1.1 Configuration files
> ~/buildenv/poky-3.2.4/build/```<machine>```/conf/local.conf > ~/buildenv/poky-3.2.4/build/```<machine>```/conf/local.conf
This file is located in the build directory of the respective machine type and is the actual custom configuration file originally intended for this by the build system. However, in this environment, this local.conf only contains a few lines and includes a global configuration. This file is valid **only** for the machine type it supports. Here you can therefore make additional entries that are only intended for the machine type. [See also diagram](#14-run-init-script) This file is located in the build directory of the respective machine type and is the actual custom configuration file originally intended for this purpose by the build system. However, this local.conf contains only a few lines in this environment and includes a global configuration. This file is **only** valid for the machine type it supports. Here you can therefore make supplementary entries that are only intended for the machine type. [See also schema](#14-run-init-script)
> ~/buildenv/local.conf.common.inc > ~/buildenv/local.conf.common.inc
This file contains settings that apply to all machine types and is created from the template ```~/buildenv/local.conf.common.inc.sample``` when the init script is executed for the first time. This file contains settings that apply to all machine types and is created when the init script is first executed from the template ```~/buildenv/local.conf.common.inc.sample```.
The ```./build/<machine>/conf/local.conf``` provided by the build system could be used as the primary configuration file for each machine type separately, as originally intended by the build system, but that would unnecessarily increase the maintenance effort. That's why ```~/buildenv/local.conf.common.inc``` is only included in ```./build/<machine>/conf/local.conf```, The ```./build/<machine>/conf/local.conf``` intended by the build system could be used as the primary configuration file for each machine type separately, as originally intended by the build system, but this would unnecessarily increase the maintenance effort. That's why ```~/buildenv/local.conf.common.inc``` is only included in ```./build/<machine>/conf/local.conf```.
**Note on** ```~/buildenv/local.conf.common.inc.sample```**:** This is just a template and should be left untouched to avoid possible conflicts when updating the build script repository and to see what may have changed. **Note on** ```~/buildenv/local.conf.common.inc.sample```**:** This is just a template and should remain untouched to avoid possible conflicts when updating the build script repository and to see what might have changed.
After updating the build script repository, new or changed options may have been added or removed that are not included in the included configuration file. This case should be considered in your own configuration and checked and adjusted if necessary.
After an update to the build script repository, new or changed options may have been added or removed that are not reflected in the included configuration file. This case should be taken into account in your own configuration and checked and adjusted if necessary.
#### 4.1.2 bblayers.conf #### 4.1.2 bblayers.conf
> ~/buildenv/poky-3.2.4/build/```<machine>```/conf/bblayers.conf > ~/buildenv/poky-3.2.4/build/```<machine>```/conf/bblayers.conf
This file is usually customized when the init script is run for the first time and usually only needs to be customized if you want to add, remove or replace layers. This file is normally adjusted when running the init script for the first time and usually only needs to be adjusted if you want to add, remove, or replace layers.
#### 4.1.3 Reset configuration #### 4.1.3 Reset configuration
If you want to reset your machine configurations, please rename the conf directory (deletion is not recommended) and run the init script again. If you want to reset your machine configurations, please rename the conf directory (deleting is not recommended) and run the init script again.
```bash ```bash
~/mv ~/buildenv/poky-3.2.4/build/<machine>/conf ~/buildenv/poky-3.2.4/build/<machine>/conf.01 ~/mv ~/buildenv/poky-3.2.4/build/<machine>/conf ~/buildenv/poky-3.2.4/build/<machine>/conf.01
~/cd ~/buildenv ~/cd ~/buildenv
~/./init ~/./init
``` ```
### 4.3 Recipes ### 4.3 Recipes
**Unless you are directly involved in the development of the Poky levels, do not change anything in the official Poky levels (meta layers)! This is strongly not recommended by the Yocto project, as you risk losing all your work when updating and creating incompatibilities or conflicts that can be difficult to maintain. The usual procedure to complete, extend or overwrite existing official recipes is to [use .bbappend](https://docs.yoctoproject.org/3.2.4/dev-manual/dev-manual-common-tasks.html#using-bbappend-files-in-your-layer) files.** **Unless you are directly involved in the development of the Poky layers, do not change anything in the official Poky layers (meta-layers)! This is explicitly not recommended by the Yocto Project, as you run the risk of losing all your work when updating and creating incompatibilities or conflicts that can be difficult to maintain. The usual procedure to complete, extend, or override existing official recipes is to [use .bbappend files](https://docs.yoctoproject.org/3.2.4/dev-manual/dev-manual-common-tasks.html#using-bbappend-files-in-your-layer).**
Alternatively, although not really recommended, you could copy copies of official recipes into your own meta layers and adapt them, as these are then usually preferred by the build system. In such a case, however, you are responsible for keeping these recipes up to date, which can unnecessarily increase the maintenance effort. Alternatively, although also not really recommended, you could include copies of official recipes in your own meta-layers and customize them, as these are usually preferred by the build system. In such a case, however, you are responsible for keeping these recipes up-to-date, which can unnecessarily increase the maintenance effort.
For recipes from your own meta-layers such as meta-neutrino or the machine layers, the same principle applies. But if you want to [actively work on the recipes](https://docs.yoctoproject.org/current/ref-manual/devtool-reference.html#modifying-an-existing-recipe), feel free to do so.
In principle, this also applies to recipes from your own meta layers such as meta-neutrino or the machine layers. But if you would like to [actively collaborate on the recipes](https://docs.yoctoproject.org/current/ref-manual/devtool-reference.html#modifying-an-existing-recipe), you are welcome to do so.
### 4.4 Packages ### 4.4 Packages
If you want to have full control over a package source code, for example to fix something or actively develop something, the source code you want to work on should be moved to the workspace. See: [Example of Neutrino](#441-edit-source-code-in-the-workspace-example) If you want full control over a package's source code, e.g. to fix something or actively develop, the source code you want to work on should be moved to the workspace. See: [Example for Neutrino](#441-edit-source-code-in-workspace-example)
See [devtool](https://docs.yoctoproject.org/current/ref-manual/devtool-reference.html) and especially [devtool modify](https://docs.yoctoproject.org/current/ref-manual/devtool-reference.html#modifying-an-existing-recipe). In the workspace you have the guarantee that the source code will not be touched by the build system. If you don't take this into account, it can happen, for example, that changed source code is repeatedly deleted or modified. Your own customizations can therefore be lost or become incompatible. In the local default configuration, [rm_work](https://docs.yoctoproject.org/ref-manual/classes.html#ref-classes-rm-work) is activated, which ensures that after each package has been built, the respective working directory is cleaned up, so that nothing remains except a few logs. See [devtool](https://docs.yoctoproject.org/current/ref-manual/devtool-reference.html) and especially [devtool modify](https://docs.yoctoproject.org/current/ref-manual/devtool-reference.html#modifying-an-existing-recipe). In the workspace, you have the guarantee that the source code will not be touched by the build system. If you don't observe this, it can happen, for example, that changed source code will be deleted or modified again and again. Therefore, your own adjustments may be lost or become incompatible. In the local standard configuration, [rm_work](https://docs.yoctoproject.org/ref-manual/classes.html#ref-classes-rm-work) is activated, which ensures that after each completed build of a package, the respective working directory is cleaned up, so that except for some logs, nothing will remain.
#### 4.4.1 Edit source code in the workspace (example)
Neutrino is used here as an example, but this approach essentially applies to all other packages. #### 4.4.1 Edit source code in workspace (example)
Neutrino is used here as an example, but this procedure essentially applies to all other packages.
```bash ```bash
~/buildenv/poky-3.2.4/build/hd61$ devtool modify neutrino ~/buildenv/poky-3.2.4/build/hd61$ devtool modify neutrino
@@ -264,15 +283,15 @@ INFO: Source tree extracted to /home/<user>/buildenv/poky-3.2.4/build/hd61/works
INFO: Recipe neutrino-mp now set up to build from /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
``` ```
The source code for Neutrino is now located at ```/buildenv/poky-3.2.4/build/hd61/workspace/sources/neutrino```. You can then work on it there. This means that the build system no longer clones or automatically updates the Neutrino sources from the remote Git repo, but from now on only uses the local sources within the workspace, which you have to manage yourself. This is a Git repo created by devtool, into which you can integrate into the original remote repository, if this is not already the case. Under ```/buildenv/poky-3.2.4/build/hd61/workspace/sources/neutrino``` is now the source code for Neutrino. You can then work on it there. This means that the build system no longer clones or automatically updates the Neutrino sources from the remote Git repo on its own, but from now on only uses the local sources within the workspace that you have to manage yourself. This is a Git repo created by devtool, in which you can include the original remote repository if this is not already the case.
If you do this now... If you now execute...
```bash ```bash
bitbake neutrino bitbake neutrino
``` ```
...from now on Neutrino will only be built from the local repo in the workspace: ...Neutrino will from now on only be built from the local repo in the workspace:
```bash ```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 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
@@ -286,18 +305,19 @@ NOTE: neutrino-mp: compiling from external source tree /home/<user>/buildenv/pok
NOTE: Tasks Summary: Attempted 2756 tasks of which 2741 didn't need to be rerun and all succeeded. NOTE: Tasks Summary: Attempted 2756 tasks of which 2741 didn't need to be rerun and all succeeded.
``` ```
**Note!** In the special case of Neutrino, it is advisable to transfer not only its source code, but also the associated ```libstb-hal``` into the workspace. **Note!** In the special case of Neutrino, it is advisable to transfer not only its source code but also the associated ```libstb-hal``` to the workspace.
```bash ```bash
devtool modify libstb-hal devtool modify libstb-hal
``` ```
## 5. Force rebuild a single package
In some cases it can happen that a target breaks off for whatever reason. But you shouldn't panic and delete the working folder and the expensive sstate cache. Cleanups can be carried out individually for each target without destroying an otherwise functioning system. ## 5. Force rebuilding a single package
In particular, broken archive URLs can lead to termination. However, these errors are always displayed and you can check the URL. Often it's just the servers and they even work again after a few minutes. In some cases, a target may abort for whatever reason. But you should by no means panic and therefore delete the working folder and the expensive sstate-cache. Cleanups can be performed for each target individually without flattening an otherwise functioning system.
To make sure whether the recipe in question actually has a problem, it makes sense to completely clean up the target in question and rebuild it. To achieve this, all associated package, build and cache data must be cleaned. Especially defective archive URLs can lead to aborts. However, these errors are always displayed and you can check the URL. Often it's just the servers and they work again after a few minutes.
To ensure whether the recipe in question actually has a problem, it makes sense to completely clean the target in question and rebuild it. To achieve this, all associated package, build, and cache data must be cleaned.
```bash ```bash
bitbake -c cleansstate <target> bitbake -c cleansstate <target>
@@ -308,17 +328,18 @@ then rebuild:
```bash ```bash
bitbake <target> bitbake <target>
``` ```
## 6. Force complete image construction
## 6. Force complete image build
The init script provides the `--reset` option for this. The init script provides the `--reset` option for this.
```bash ```bash
./init --reset ./init --reset
# Anweisungen befolgen # Follow instructions
``` ```
You can also achieve this manually by manually renaming the tmp directory in the respective build subdirectory. You can delete it later if you want to free up storage space or are sure that you no longer need the directory: You can also achieve this manually by renaming the tmp directory in the respective build subdirectory. You can delete it later if you want to free up storage space or if you are sure that you no longer need the directory:
```bash ```bash
mv tmp tmp.01 mv tmp tmp.01
@@ -330,9 +351,10 @@ Then have the image rebuilt:
bitbake neutrino-image bitbake neutrino-image
``` ```
If you have **not** cleared the cache, the image should be built in a relatively short time. This is precisely why it is recommended to keep the cache. The directory where the cache is located is determined via the variable ```${SSTATE_DIR}``` and can be adjusted in the configuration. If you haven't deleted the cache, the image should be built in a relatively short time. That's why it's recommended to keep the cache. The directory where the cache is located is set via the variable ```${SSTATE_DIR}``` and can be adjusted in the configuration.
This directory is quite valuable and only in rare cases is it necessary to delete this directory. Please note that the build process takes much more time after deleting the cache.
This directory is quite valuable and only in rare cases is it necessary to delete this directory. Please note that the build process will take much longer after clearing the cache.
## 7. License ## 7. License
``` ```
@@ -341,6 +363,6 @@ MIT License
## 8. Further information ## 8. Further information
Further information about the Yocto build system: More information about the Yocto build system:
* https://docs.yoctoproject.org * https://docs.yoctoproject.org