Dylan Aïssi
March 07, 2025
Share this post:
Reading time:
Following the Apertis release flow, Apertis v2025 is the second Bookworm-based release which includes all the updates from Debian 12.9. Note that v2025 will be the final release based on Bookworm, as Apertis v2026 will be based on Debian Trixie.
While Apertis v2024 was shipped with Linux LTS 6.6, Apertis v2025 comes with Linux LTS 6.12. This is the latest kernel with long-term maintenance. This version will be maintained mainline until December 2026. As usual, Collabora has made a number of nice contributions to this version, including improving Rockchip and MediaTek SoCs support.
This Apertis release supports the NXP Layerscape LS1028A RDB development board which is a computing, evaluation, and development platform that supports industrial IoT applications, human machine interface solutions, and industrial networking. The Apertis image specific to this board is available here.
The initial support for the MYIR Remi Pi, a cost effective SBC based on a Renesas RZ/G2L processor, has also been added to the kernel. However, an out of box Apertis image for this device is still work in progress.
Each new release requires a lot for work as described in the documentation. The two main processes are folding and branching. Until now, these have involved tedious, error-prone manual processes. To reduce manual work and potential problems, all these processes are now defined in GitLab-CI pipelines making the work faster, easier, and enjoyable!
The folding consists in merging the -security and -updates branches in the main branch to ensure the point release contains all available updates. This begins in GitLab, is propagated to OBS, and finally to the apt repositories. The pipeline still ends with a manual check to ensure all services (GitLab, OBS, and aptly) are synchronized and no error is detected. This is a future point of improvement through automation. Here's an overview of the folding pipeline:</P
The branching on the other hand, consists of creating new git branches, OBS repositories, and apt repositories, using the ones from the previous release as a base. Here we have an overview of the branching pipeline which is slightly more complex with 34 different jobs:
The first part illustrated above shows the GitLab preparation, with the creation of new branches and the setting of scheduled pipelines.
Then comes the creation of new apt repositories, followed by the creation of OBS repositories with their configuration.
Finally, like for the folding, manual checks are performed to ensure everything is in place.
One of the steps in our Gitlab package builder pipeline is to check that the copyright report is up to date and compliant with the Apertis license policy. Sometimes the report needed an update; this caused the pipeline to fail and a developer had to manually create a merge request updating the report. This process is now entirely managed by the pipeline which automatically creates a merge request with the new copyright report. This improvement reduces package maintenance time, allowing developers to focus on their development work.
As seen in the screenshot above, the author of the merge request is our tireless contributor Apertis CI robot.
A common task in Apertis is to import new packages from Debian when someone needs them to implement new features or support new hardware. This process is well documented and fully automated via our tool import-debian-package. However, it was necessary to manually add a copyright report to prevent build pipelines from failing, as the absence of debian/apertis/copyright is detected by our pipeline to ensure all packages have a comprehensive copyright report. Now import-debian-package creates a merge request with the required Apertis metadata (including the copyright report generated for the targeted Apertis release) for the first import, reducing manual work. Thus, developers now just have to review the merge request instead of generating it themselves. This improvement has been added in apertis-dev-tools 0.2024.14. For instance, the below screenshot illustrates a merge request automatically generated when importing nethogs:
Due to limitations in the way GitLab triggers pipelines, some useless and/or duplicated pipelines are triggered. The configuration of some GitLab jobs also places limits on them being built concurrently to avoid race conditions. It was not uncommon to have to wait for the end of previous builds or to cancel pipelines to speed up publishing a package with the latest changes. This issue was a waste of resources and a waste of time for developers. This is now history, we have added controls to avoid and cancel unneeded pipelines.
This screenshot illustrates a simple merge request updating the kernel in Apertis v2024-security At the bottom, we have the first pipeline running in the branch context which has been immediately canceled. As a merge request has been raised, this pipeline is redundant. The merge request pipeline performs at least as many tests as that run in the branch context and thus the pipeline completing in the merge request context provides us with adequate testing to ensure that the changes can be successfully built and packaged for all the targeted architectures in the relevant release. It also provides the author with all the information they would have gained from the pipeline running in the branch context. The middle pipeline is running in the merge request context and is legitimate. However as part of the pipeline needed to refresh the copyright report, a further pipeline, the top one, was created that includes these changes. Hence this middle pipeline can be canceled to allow the pipeline with the automatically refreshed copyright report, which will be required for the branch to be merged, to take priority. This final pipeline will be completed successfully.
In this simple example, previously we could have either had three pipelines, sharing processing resources and running slowly in parallel or three pipelines configured to run serially waiting for resources to be released from the previous pipeline. In other words, to get the final package and thus be able to merge the MR, we would have had to wait for the package with the same source code changes to build three times.
Whilst simulating the rebase of Apertis on Trixie, we improved the ability to host packaging repositories under arbitrary GitLab namespaces. All the Apertis official packages are located in the pkg GitLab namespace and it is now possible to easily use other namespaces for packages. For instance, we used pkg-rebase-trixie to simulate the rebase on Trixie in an isolated environment (GitLab/OBS) without affecting the production namespace. The use of other namespaces is also very useful to test a change on a large scale without affecting the production/developement environment. For instance, to test a change in the build pipeline or in build tools like dpkg or debhelper.
The Apertis dashboard for packages now reports a summary of the Apertis changes compared to each upstream Debian packages. It allows one to quickly identify how big the Apertis changes against the Debian package are with a summary provided by git diff --shortstat and to actually have a look at the changes by clicking on the magnifying glass. This also allows Apertis developers to more easily identify packages where we have outstanding changes that we need to upstream to benefit the community, as described in the Apertis upstreaming policy.
For instance, below is the dashboard report for the package linux which is a special package in Apertis as we ship much newer kernels than Debian, picking the latest LTS every year for our stable releases:
From this picture, we see that Apertis developers have changed 143 files with 9528 insertions and 3703 deletions. These changes can be inspected just by clicking on the left which brings us here.
While we used germinate to compute the list of dependencies for the rebase on Bookworm, its use was not simple. We have simplified and automated its usage by covering more use cases.
In addition to use it to analyse dependencies in a rebase, it's now possible to compute which dependencies are missing in Apertis to import a new package. Previously, the dependencies analysis was manual thus error-prone and fairly laborious, with this improvement all this work is automatic which allows us to easily make massive imports.
Another use case is to ensure that the packages are in the right [repository components, for instance packages in target should not depend at runtime on packages in development. An example is illustrated in the following paragraph about Rust and Go packages.
All of these use cases are illustrated in the README. We can easily run germinate from its GitLab pipeline by setting the variables according to our use case. The results will then be available as job artifacts.
target componentIn Debian, Go and Rust packages are special cases in contrast to other languages, as they are statically linked. Because of this characteristic, their distribution in the Apertis repository components has not always been consistent and thus they may not have complied with the License Expectations. Thanks to the germinate work described above, we have compiled a list of Go and Rust packages inappropriately located. This allowed us to move them into the component target and thus strengthen the compliance to the license expectations.
As a result, the number of packages in target has doubled from around 560 to just over 1200.
QA Report App is the Apertis tool for reporting and viewing the results of both manual and automated (via LAVA) QA testing. Although its interface was functional and clear, it didn't match the Apertis website's identity. After a long and great work, it has been revamped to make it more modern and add new features such as filtering on the main page, logout support, and some charts to represent results.
Here is what the main page looks like:
And here's how the results are represented now:
Each page has a nice colored doughnut chart to summarize results.
This redesign will make the QA and testing work less austere.
... as Buzz would say! As mentioned at the beginning of this post, the next Apertis release (v2026) will be based on Debian Trixie and promises to be a great and exciting version. This will be the subject of another post where we will detail the rebase process and all the new features!
In the meantime, don't hesitate to contact the Apertis community or the Apertis team directly at contact@apertis.org to help you tailor Apertis to your needs.
Part of the Apertis team will be present at Embedded World 2025 next week (from March 11 to 13, 2025) in Nuremberg. Don't hesitate to come and chat with us about Apertis (and other things) at the Collabora booth, No. 4-404.
07/03/2025
Apertis v2025 has landed with all the updates from Debian 12.9. This release has a variety of updates including new supported boards, improved…
27/02/2025
Join us at the NürnbergMesse in Nuremberg, Germany, as we take part in Embedded World 2025, one of the largest trade fairs of its kind,…
24/02/2025
It's been a long road for Wayland's recently landed color management extension. We take a brief look back at how this latest feature was…
Whether writing a line of code or shaping a longer-term strategic software development plan, we'll help you navigate the ever-evolving world of Open Source.
한국어 버전의 Collabora.com 보기
Acesse Collabora.com em Português
Comments (0)
Add a Comment