Guides

The SDK is distributed as VirtualBox images, with one VirtualBox image for each version of Apertis. As the SDK is designed to be used for development, it is highly likely that developers using it will adjust the SDK to their needs. These changes include installing tools, libraries, changing system configuration files, and adding content to their workspace. Additionally some developers may have to support different versions of the SDK at the same time and it may be advantageous for them to be able to synchronize their customizations between multiple SDK VirtualBox images. [Read More]

Apertis stores the source of all the shipped packages in GitLab and uses a GitLab CI pipeline to manage the workflows and automate many of the tasks that are required to release a package, thus for many tasks such as adding or updating packages, interaction is only required with GitLab, with automation taking care of the rest of the process. Please see the Apertis workflow for more information regarding the automation provided by Apertis. [Read More]

This document aims as a single resource for all information related to Apertis Release Process. It covers the Major Release process as well as the Point Release process. Apertis Infrastructure The Apertis project is hosted on a couple of infrastructure services, which are tightly coupled to each other, providing end-to-end automation. This includes: Landing new packages into Apertis Landing new security and general updates into Apertis Landing downstream changes into Apertis This document stands as a comprehensive guide to all package related processes as outlined above. [Read More]

The recommended virtual machine platform for the AMD64 Apertis system images is VirtualBox. It is typical for the Apertis SDK to be run in a virtual machine, though other image types can also be used. This enables development to be performed on computers running Windows, Mac OS, or different Linux distributions. System requirements You will need a PC with the following configuration to install and run the SDK: Hardware Dual core CPU at 2GHz or higher 8 GB RAM or more 12 GB or more free space on the hard disk If your PC supports Virtualization Technology, make sure that it is enabled. [Read More]

Often target platforms are not supported by Apertis. This may be due to the way the Apertis components are built/configured or due to these components lacking support for the required hardware. Whilst they may lack support in Apertis, these boards frequently have reference images based on another Linux variant with the associated source code being available. This support is often provided in a Yocto-based deliverable. The support generally provides good coverage of the vendors hardware, however the quality of implementation can vary quite dramatically. [Read More]

This guide aims to explain how to use the apertis-abi-compare tool in order to detect API/ABI breakage between two versions of a library package. Other Apertis documents are available: Supported API API Stability API/ABI Evolution Guideline How to use apertis-abi-compare tool First, install the apertis-dev-tools package (>= 0.2021.11) providing the apertis-abi-compare tool. 1 sudo apt install apertis-dev-tools Then, build you library package using gbp buildpackage (or dpkg-buildpackage) for example. 1 2 3 4 5 6 7 8 user@apertis:~$ cd dev/ user@apertis:~/dev$ git clone https://gitlab. [Read More]

Linters are tools that analyze the code and warn about bugs & style issues. Utilising such tools can help improve code quality and enforce a consistent style which can help with code maintainability and bug fixing, especially where multiple developers are likely to be maintaining the code. This guide shows how to utilise the clang linter. Install clang-format-linter locally A custom local install of the linter for C, C++, Python and Bash/POSIX shell can be easily done. [Read More]

Apertis is meant as a very flexible baseline to base a variety of different product and product types. This flexibility not only in the software selection used, but also in the hardware platforms, boards and features. As Apertis aims to cater to a variety of use-cases and hardware platforms (with each platform providing its own balance of performance and features), developers are free to pick the hardware platform that provides the best match to their requirements. [Read More]

Getting from source code to an image suitable for loading into a target device is typically a two step process. The first step is creating binary packages and the second combining them to create an image. A more detailied explanation of this process is documented in the Apertis workflow. The Apertis project automates the creation of the official images, which are built for the reference hardware and supported by the project. [Read More]

This guide will explore a number of workflows for retrieving, patching, building and packaging the Apertis kernel. This guide will suggest workflows both utilising the Debian infrastructure on which Apertis is built and a workflow that eschews the Debian infrastructure and thus is usable by third party integrators who may need access to a patched kernel tree for integration, but who’s workflow would make using the Apertis infrastructure difficult. This document is targeted towards development of Apertis and where possible, we would strongly advise using the Apertis SDK image and the Debian tooling provided for it, as this workflow will be more efficient (“option 1” where present). [Read More]