This section provides documentation covering the implementation goals and strategies taken to enable features or functionality in Apertis.

For more detailed guidance on implementing or using specific functionality, please refer to the guides.

Sysroots and Devroots

Sysroots and devroots are two development rootfs meant to provide an environment to build software for Apertis, targeting foreign architecture that don’t match the CPU architecture of the build host (for instance, building ARM64 binaries from a Intel-based host). They are meant to address different use cases with different trade-offs. Sysroot Sysroots are file system trees specifically meant for cross-compilation and remote debugging targeting a specific release image. They are meant to be read-only and target a specific release image, shipping all the development headers and debug symbols for the libraries in the release image. [Read More]

Web engine

Apertis provides the GTK port of WebKit as its web engine. To ensure low maintenance effort, no changes are made to the downstream branch, any improvements should go to the upstream project. Security maintenance Like all other major browser engines, the GTK port does not provide long term support, so security maintenance comes down to staying up to date. The general approach Apertis takes is to follow whatever Debian provides. The project may also importing a new upstream release that has not been made available in Debian yet if an important fix is available. [Read More]

Image building infrastructure (obsolete)

This document provides and overview of the image build pipeline prior to the migration to GitLab CI/CD that has been completed during the v2021 development cycle. Refer to the documentation in the infrastructure/apertis-image-recipes project for information about the current pipeline. Introduction The Apertis infrastructure supports continuous building of reference images, hwpacks and ospacks. This document explains the infrastructure setup, configuration and concepts. Technology overview To build the various packs (hardware, os) as well as images, Apertis uses Debos, a flexible tool to configure the build of Debian-based operating systems. [Read More]

Presentations

These are some of the slides and presentations which members of the Apertis community have previously shared (ordered newest to oldest): 2019 Building an entire Debian derivative from Git The Apertis approach to using git as part of the build pipeline by Andrej Shadura 2018 Testing your distribution with LAVA Introducton to testing with LAVA by Andrej Shadura and Guillaume Tucker 2017 Managing build infrastructure for a Debian derivative [Read More]

API Stability

Summary Define API stability guarantees for your project. Ensure version numbers are changed as appropriate when API changes. API and ABI At a high level, an API – Application Programming Interface – is the boundary between two components when developing against them. It is closely related to an ABI – Application Binary Interface – which is the boundary at runtime. It defines the possible ways in which other components can interact with a component. [Read More]

Application Design

Apertis is a platform for automotive infotainment. With this in mind, it is intended to be used only with a touch screen interface by a driver or a passenger in a vehicle. The graphical user interface (GUI), or human-machine interface (HMI), will normally be made up of widgets provided by Mildenhall. Mildenhall takes the nature of Apertis into consideration so many of the widgets will be automatically sized and in some cases even placed for ease of use. [Read More]

Indexing and Searching

Tracker is a desktop search engine, metadata indexing and storage service. It is the recommended way to search for user files and access metadata about them. A full introduction to Tracker is here. Summary Avoid SPARQL injection vulnerabilities by using prepared statements. Using Tracker Tracker is effectively a metadata store which applications can query using the SPARQL query language. SPARQL is similar to SQL, so all the same considerations about SQL injection apply when using it. [Read More]

Internationalization

Internationalization (commonly abbreviated i18n) is a topic which covers many areas: more than just translating UI strings, it involves changing settings and defaults to match the customs and conventions of the locale a program is being run in. For example, days of the week, human name formats, currencies, etc. Summary Design projects to be internationalized from the beginning. Use gettext (not intltool) for string translation. Remember that all strings are in UTF-8, and may contain multi-byte characters. [Read More]

Apertis Application Bundle Specification

Version: 1.2.0 The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119. This specification uses semantic versioning. After version 1.0.0 is finalized, the major version number (first component) will be incremented if a change makes previously-valid application bundles cease to work or be valid, for example changing “MAY” to “MUST” or “MUST NOT”. [Read More]

Debug Symbol Packages

Packages automatically generate debug symbol packages at build time, the packages have the package name extension -dbgsym. Infrastructure To be able to benefit from dbgsym packages, the infrastructure must be ready for them, the requirements are: reprepro: must support dbgsym since 4.17.0 debhelper: with dbgsym support since 9.20160114 dpkg-dev: support for dbgsym since 1.18.2~ When building packages with those tools, automatic debug symbols will be generated for all built packages. [Read More]