Guides

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. VirtualBox Setup VirtualBox can be configured both from its GUI or via the command line. From the VirtualBox GUI Download the required .vdi.gz for the SDK from the image repository Uncompress the downloaded .vdi.gz file Create a new VM in the VirtualBox Manager (Machine → New. [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]

While Apertis is focussed on providing a full infotainment system, including HMI, there are potential use-cases for a much smaller and scaled down variation of Apertis. One such use-case is to use Apertis purely to bridge between the internal car systems and the wider internet, in such a situation Apertis would only be used to run Agents which connect to web and other online services and relay information received from those systems to the other in-car systems. [Read More]

This page describes some general API design principles which are useful to bear in mind when designing APIs (whether those APIs are for C, C++, JavaScript, D-Bus, or something else). Summary API designs must make sense from the point of view of a third-party app developer (start by designing high-level APIs, only add daemons if it is necessary) Interfaces that don't have to be API should not be API (minimize surface area) Follow GNOME/GObject conventions, so that we get JavaScript bindings automatically Use existing frameworks where we can; if we can't use them directly, learn from their design Identify privilege boundaries, do not trust less-privileged components, and consider whether some features should be restricted Minimize “surface area” The “SDK API” is intended to remain stable/compatible over time, which means that we are committing to interfaces in the “SDK API” continuing to work in future: third-party code that uses stable Apertis APIs should continue to work in future, without needing changes. [Read More]