Architecture

Build infrastructure on Intel x86-64 Introduction The current Apertis infrastructure is largely made of hosts based on the Intel x86-64 architecture, often using virtualized machines. The only exceptions are: OBS workers used to build packages natively for the ARM 32 bit and ARM 64 bit architectures LAVA workers, which match the reference hardware platforms While LAVA workers are by nature meant to be hosted separately from the rest of the infrastructure and are handled via geographically distributed LAVA dispatchers, the constraint on the OBS workers is problematic for adopters that want to host downstream Apertis infrastructure. [Read More]

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]

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]

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 Introduction on the build and integration infrastructure of Apertis by Andrew Shadura Application Framework APIs in action - a case study [Read More]

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]

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 (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]

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]

Apertis follows an app-centric architecture. This means that the development is more vertical and not layered as in automotive domain. This reduces dependency and leads to less time to market. SDK is designed to make app development fast and easy while maintaining backward compatibility. The system gets upgraded periodically; however the applications should not be affected. This is achieved by writing apps against SDK APIs. The SDK APIs are ensured to maintained backward compatibility. [Read More]

Apertis has a fairly typical Linux boot process: A platform specific bootloader performs initial low-level configuration of the system The Linux kernel performs higher level configuration and creates a standardised environment The kernel passes execution to the user space which enables services based on the functionality provided by the kernel and sets up the system to accept user input Critical sequences during startup The phases during startup generally proceed from most- to least-critical. [Read More]