Guides

Automated Licensing Compliance Install As described in Automated License Compliance a check is performed on image creation to confirm the compliance with the terms that Apertis may wish to avoid. To support this feature several pieces of software need to be installed. FOSSology The recommended FOSSolgy setup consist in FOSSology server PostgreSQL database server Apache HTTP server We recommend to build this setup trough a Docker installation as described in FOSSolgy Docker installation [Read More]

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 Packaging CI Apertis stores the source of all the shipped packages in GitLab and uses a set of GitLab CI pipelines to manage the workflows to: land updated sources to OBS which will then build the binary outputs pull updates from upstream distributions like Debian 10 Buster Adding downstream changes The standard Contribution Process applies unchanged to packaging repositories, pushing changes to wip/ branches and getting them landed to the apertis/* branches via Merge Requests. [Read More]

There are likely to be instances where it is desirable to import the latest version of a piece of software into Apertis directly from it's original authors or maintainers. This may be as a result of the software in question not being packaged by Apertis’ default upstream distribution, Debian, or their being a mismatch between the desired version in the upstream distribution and what is required for a specific goal. [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]

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]

The process of getting from source code to an image suitable for loading into a target device with Apertis is a clearly defined multi-step process. The initial step is to build the source and package the resulting artefacts into .deb packages. For the vast majority of packages this is already done and provided by Apertis in the package repositories. This page will not cover this step of the process an will assume all required packages have been successfully built and are available in the package repositories. [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]