Liri Blog

Liri partecipates in Hacktoberfest 2021

Thu, 30 Sep 2021 22:00:00 +0000

It’s October again! This means another Hacktoberfest!

If you already don’t know, Hacktoberfest is a month-long celebration of open source software.

Liri is partecipating in this year’s Hacktoberfest.

Make 4 pull requests on GitHub between October 1-31 (in any time zone) and win a tee!

Here’s the list of issues up for grab.

Easy issues are categorized with the good first issue label: list.

Updates for July, 2020

Sat, 01 Aug 2020 07:52:00 +0000

Photo by Glen Carrie on Unsplash

AppCenter

Flatpak support for AppCenter was improved.

It now lists the apps that need to be updated and shows their download size.

Also, the Flathub source is no longer automatically added to the system installation. It’s up to the user to install it, or the distro to automatically configure it.

Fluid

Fluid documentation is now deployed with GitHub Pages, hence it’s now available here.

Flatpak

We now build the Flatpak nightly repository with GitHub Actions workflows.

Updates for June, 2020

Wed, 01 Jul 2020 17:52:00 +0000

Photo by Glen Carrie on Unsplash

Continuous Integration

CI has been added to materialdecoration and the build issues caused by qtwayland are fixed nowadays, meaning that the package now builds again.

OSTree tools

ostree-image-creator and ostree-upload were rewritten with Go, which is way easier to develop with compared to Rust.

For this kind of applications, Rust didn’t give any advantage at all.

ostree-image-creator was also redesigned: it’s now a tool that builds any kind of image you want from a declarative recipe.

image-manager now shares code with ostree-image-creator and ostree-upload, for instance all the code to parse JSON and token authentication, and the client was rewritten in Go.

Here you can take a look at Liri OS live image recipe.

OSTree repositories

OSTree configuration was revamped and the repository is now GPG signed. Every night a GitHub workflow builds and uploads the repository.

Updates for May, 2020

Mon, 01 Jun 2020 07:52:00 +0000

Photo by Glen Carrie on Unsplash

During may the continuous integration improvements continued.

Translations

There is now a new translation action that regenerates translation sources and push them to Transifex, pull the rebased and updated translations, merge translations into desktop and metainfo files, then commit and push to git.

All in one action.

We now have metainfo translated, desktop files are translated with gettext and there is context information that indicates which key is being translated.

Build

The build workflow got some improvements. Previously we were building on Ubuntu with the ppa-beineri repository so we can build against multiple Qt versions.

However ppa-beineri doesn’t build with EGL support, but this makes building eglfs impossible.

In order to overcome this difficulty, there are OpenSuSE Tumbleweed images now with all the dependencies. One image for each Qt version we are building against.

At the time of this writing, the Qt versions supported are 5.12 because it’s a LTS release, then the latest two version 5.14 and 5.15.

All container images are in the same repository.

Documentation

The developer documentation, previously available through readthedocs.org is now available via GitHub Pages on docs.liri.io.

Updates for April, 2020

Fri, 01 May 2020 07:52:00 +0000

Photo by Glen Carrie on Unsplash

April didn’t see much code improvements, it was pretty much dedicated to the continuous integration.

Previously we used Travis CI and AppVeyor as continuous integration for pushes and pull requests, and Jenkins to build the OSTree repository, OS images and translation updates.

Now with GitHub Actions we can really improve the Liri CI.

GitHub Actions introduce the concept of workflows, this gives us great flexibility to implement whatever we want.

We now have basically three workflows:

Status check and validation
Build and release
Translations

We can see if each commit or pull request has valid QML and freedesktop.org files (desktop entries and AppStream metadata) with the following actions that I developed for Liri and will be in the marketplace soon:

And also prevent work in progress pull requests to be merged.

In the future we can also check for the proper SPDX license information or whether there are coding style violations.

With the build workflow we can check if the code builds on different operating systems, platforms and compilers. The cross-platform apps benefit by this the most as we can build against different Qt versions, Linux, Windows, macOS and Flatpak. In the future we’ll probably add Snap and AppImage. The resulting artifacts are available for each run of the workflow. When a new version is released, the artifacts are attached to the release automatically.

When a library is built in the CI, the workflow stores a .tar.gz artifact with the binaries that will be used by the CI of another repository that depends on that library. Given that you cannot download artifacts from another repository with the official actions/download-artifact, I made my fetch-artifact action.

Every week the translation sources are regenerated and sent to Transifex. The translations, now rebased to the new sources, are downloaded and automatically committed. This was previously done in our private Jenkins installation, but the workflows are easier to configure and manage. This also result in less work on our private build server.

These are the actions I made for the translations:

Then I made the .github repository that contains default GitHub files, the so called community health files such as code of conduct, contributing guidelines, issue template and pull request template. This is yet another step towards a better GitHub integration.

Updates for March, 2020

Fri, 01 May 2020 06:00:00 +0000

Photo by Glen Carrie on Unsplash

Flatpak is a first class citizen in Liri OS.

For this reason during March our XDG portal implementation was improved.

UI creation now works way better and QML code is integrated with C++, however at the moment there is no XDG foreign support. This means that portal dialogs are not parented to the application window.

The following portals were created:

Screenshot
Lockdown
Print
Access
Settings
Background
Wallpaper

The screenshot portal has a method to pick the color of a pixel, so in order to make this possible I created a custom Wayland protocol.

While working on the screenshot portal, I also improved our implementation of the screen copy Wayland protocol from wlroots.

Image format conversion was fixed, it’s now possible to capture with or without the pointer cursor as well as memory leak fixes.

In other news, the OS installer was fixed so it’s now possible to install it again. However the boot loader configuration needs some fixes that will be probably implemented in May.

Updates for February, 2020

Sat, 21 Mar 2020 20:00:00 +0000

Photo by Glen Carrie on Unsplash

February was mostly about working on this blog.

You can read more about it here.

This month we also ported the screencast program to GStreamer, in place of GStreamerQt that has been abandoned.

The app now uses the portal API to start the screencast session, this means that it will work with any other desktop environment with a portal implementation.

Meanwhile, our portal implementation has been improved and can now make screencasts without CPU effort using DMA-BUFs.

eglfs had to be changed to support passing file descriptors to the compositor, that now implements the wlr-export-dmabuf-unstable-v1 protocol from wlroots.

Updates for January, 2020

Fri, 28 Feb 2020 12:05:11 +0000

Photo by Glen Carrie on Unsplash

January was all about making progress on how Liri OS live images.

Previously, the images were made with traditional packages with kickstart files.

I wrote a Python module for the Calamares installer, that deploys the OS tree into the root partition. However this is excruciatingly slow because at the moment we don’t have a fast Web site, in order to reduce costs (all the expenses are out of my wallet).

If the image is made with OSTree itself, the same repository on the image can be used to deploy the operating system on the root partition, without involving the network at all.

At the time of my research for already existing tools, nothing was found. Then Fedora CoreOS started doing something like that, but it’s too complex and focused on their needs.

So I came up with oic, also known as ostree-image-creator.

It’s a simple tool written with Rust, that creates live images. You can use it with ostree, it doesn’t need rpm-ostree.

In the future it will be extended to disk images as well.

Our OSTree repository now has a live branch, derived from the actual branch that will be installed on users’ computers. The live branch installs Calamares and dracut modules specific to its bootstrap, plus a setup service that creates the liveuser user.

The difference with the previous images is that only /etc and /var are writable, and they are not persistent.

Another important Rust program was made: ostree-upload.

We build the OSTree repository in a separate CI machine and want to upload the objects to the public OSTree repository.

This program receives the objects from the CI machine and store them in a temporary directory, until the process is done. Once all objects are transfered, the new changes are published.

This is better than using rsync, there’s no risk that users will fetch from the OSTree repository during a synchronization.

Welcome to the new blog

Mon, 10 Feb 2020 18:05:00 +0000

Photo by Florian Olivo on Unsplash

In 2017, we started writing blog posts in a Medium publication. Medium appeared to be a simple, clean and reader-focused host for writers.

At the beginning it felt like a good choice.

They supported rich formatting, great image embedding, easy to use editor, RSS and custom domains.

What’s wrong with Medium

Soon after we decided to use the platform, Medium started getting more aggressive towards readers.

It was no longer possible to create an account with an email address, instead a third-party social network login was required. Now it appears the email registration was restored.

Readers who were not signed in, were shown a modal popup asking them to create an account.

Medium has also gotten aggressive with their new monetized platform. Stories are now defaulting to be behind their paywall. While this might be useful for those who seek to earn money from their content, the paywall actively reduces the number of people that will read those stories, as it restricts it to paying members.

A new blog

In the past we never blogged much about Liri, but as progress is made we want to update more frequently our publication.

We want a blog that is read by all people for free and respect their privacy.

Since the web site is already made with Jekyll, we are familiar with it.

The blog code is here and it’s published with GitHub Pages.

This is a nice opportunity to use the new Material Design Components, that replace the older Material Design Lite that is still used by our web site.

What you can find now, is just a MVP. In order to start posting to this blog the bare minimum had to be ready.

The layout and styles will be improved upon as we go along.

In the future Material Design Components will be used with the web site as well.

Liri session is now managed by systemd

Sat, 16 Nov 2019 23:00:00 +0000

Photo by freestocks on Unsplash

Recent Liri desktop architectural changes made it possible to start the desktop and applications using systemd For a long time I desired to implement this, but it wasn’t possible before landing some architectural changes.

In this post I will explain how this works and what changes lead to systemd user sessions.

Before you jump to conclusions, be aware that systemd support is enabled by default but it can be disabled both at build and run time.From a user’s perspective nothing has changed, but this is a fundamental change to push things towards Liri desktop 1.0.

Advantages

The main advantage of using systemd is that I don’t have to write code to run programs myself and I don’t have to worry about relaunching a vital program if it crashes.

There is already a tool that knows how to manage programs, it works well and have lots of options. So basically instead of writing code myself, I can just pick the right settings and write an INI style file.

There are other advantages as well: systemd allows you to control resources (CPU, memory and I/O) and lets you start programs when they are really needed.

Architectural changes

In the beginning, session management was part of Liri Shell, but that was just too much stuff for one program.

The first thing to do was to turn liri-sessioninto a C++ program.
Previously it was just a shell script that was creating the session bus before launching liri-shell.

liri-session:

sets the environment variables
create the session bus if needed
starts up liri-shell and liri-shell-helper, services and applications
can be controlled via D-Bus We also needed long running processes to carry out various operations like acting on settings changes, power management, housekeeping, free disk space notifications, …

That’s what liri-daemon is for.

How does systemd user works

On a systemd managed system, each user is given a user-X.slice(systemd.slice(5)) and the user’s session will be run in a session-Y.scope (systemd.scope(5)).

There is also user@X.service which is the user’s systemd instance that is shut down when the user logs out.

liri-session starts the liri-session.target unit and uses systemd-run to launch XDG autostart applications in a transient scope.

To ensure that graphical applications are started after the compositor, each XDG autostart application is a systemd unit that depends on liri-shell.target so that their startup is delayed until the graphical environment is up and running.

Some programs (such as pulseaudio) are available as both systemd user units and XDG autostart. We don’t want to start them twice.
To avoid running them twice, just install a desktop entry of the same name with Hidden=true inside $datadir/liri-session/systemd-user/autostart this will disable the XDG autostart entry.

Liri Shell is made by two components: liri-shell the compositor, and liri-shell-helper a Wayland client that draws parts of the user interface.

With systemd we now have a watchdog that kills liri-shell if it’s stuck for too much time, liri-shell-helper is restarted on crash or if it’s frozen.

Applications in the menu are either started with systemd-run (just like XDG autostart applications) in a transient scope or with D-Bus activation which still means the startup is carried out by systemd due to D-Bus integration with systemd.