The guides provide detailed guidance on performing specific tasks or utilize specific features provided by Apertis.

For higher level descriptions of the technology employed in Apertis, please see the architecture documents.

Apertis packages checking with lintian

lintian is the Debian package checker. It describes itself as: Lintian dissects Debian packages and reports bugs and policy violations. It contains automated checks for many aspects of Debian policy as well as some checks for common errors. This package is useful for all people who want to check Debian packages for compliance with Debian policy. Every Debian maintainer should check packages with this tool before uploading them to the archive. [Read More]

Apertis packages testing with LAVA

Automatic testing of packages is essential to ensure high quality software. This document describe how to define tests and run them as part of the Apertis ci-package-builder pipeline. A job called package-centric-testing will install freshly built packages in an Apertis image and will run a test command to ensure the package works as expected. How to enable testing of packages The first step is to create a file debian/apertis/package-centric-testing.yaml in the source package. [Read More]

OBS Access Control List Feature

This document outlines the OBS ACL feature that has been implemented on the Collabora instance of OBS. This is a feature specific to Collabora OBS only. Background OBS currently supports creating multiple projects but it lacks support for a more fine-grained access restriction, for instance to allow certain projects to have a restricted view of other repositories. This support has been implemented by Collabora using ACLs for projects. This document describes the details of the implementation and how to use it. [Read More]

API/ABI Evolution Guideline

The purpose of this guideline is to provide advice how to handle evolution of your API/ABI in order to minimize breakage and keep your library binary compatible as much as possible. Other higher level Apertis documents are available regarding the API stability: Supported API aims to explain the relevant issues around API (Application Programming Interface) and ABI (Application Binary Interface) stability. It introduces as well, the strategy used by several big projects to maintain a certain stability without sacrificing the evolution of their components. [Read More]

How to Build Your First Image on Apertis

This guide aims to explain how to build your first image on Apertis using the GitLab UI. This guide details how to customise an image designed to run on the existing reference hardware. If you are looking for documentation on how to manually build a customized image for other hardware, see the Image building guide. This document will explain how to create a GitLab account and how to use its UI and pipelines to modify and create a custom Apertis image. [Read More]

Creating Flatpak Runtimes and Applications

This guide will give an overview of the Apertis reference Flatpak runtimes, as well as creating, signing, and publishing your own runtimes and applications. Reference Runtimes Apertis provides a reference Flatpak runtime, available in two variants: org.apertis.headless.Platform and org.apertis.headless.Sdk: A basic runtime with some common libraries that headless applications may use. org.apertis.hmi.Platform and org.apertis.hmi.Sdk: A larger runtime for graphical applications, based on the headless one but with additional packages included that are generally needed by graphical applications. [Read More]

Device Hardening

Apertis reference implementation provides packages and images geared towards development, allowing more flexibility than actual products. This guidance is targeted towards teams building products with Apertis to aid them with “hardening” the general-purpose development Apertis image/packages to reduce the attack surface on products. This document also lightly touches on measures that can be taken to physically harden a device. The procedures detailed below reduce the attack surface of the Apertis image and in some cases will provide improvements to other facets such as storage optimization and boot performance which are also likely to be important to product teams. [Read More]

Security and Access Control

AppArmor is a Linux Security Module (LSM) implementation, which enforces Mandatory Access Control (MAC) on individual application basis. AppArmor confines applications by only allowing access to resources or privileges which are explicitly whitelisted in the profile which is associated with the application. Since AppAmor uses a path-based approach, a great deal of flexibility regarding which applications to confine is achieved. Hence, not all applications on a system need to be confined. [Read More]

Apertis integration testing with LAVA

LAVA is a testing system allowing the deployment of operating systems to physical and virtual devices, sharing access to devices between developers. As a rule tests are started in non-interactive unattended mode and LAVA provides logs and results in a human-readable form for analysis. As a common part of the development cycle we need to do some integration testing of the application and validate it’s behavior on different hardware and software platforms. [Read More]

Automated Licensing Compliance Install

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 FOSSology Docker installation [Read More]