Blog on Fre(i)e Software GmbH

Commenting on the recent Ubuntu Touch review done by @SwitchandClickOfficial on Youtube

Do., 18 Juni 2026 07:49:10 +0000

There has been a video blog post recently published with a review of Ubuntu Touch as an option to opt out of the Android world: https://www.youtube.com/watch?v=wTK6TS3pXgc

Thanks to @SwitchandClick for spending time on this and publishing that video. Much appreciated.

Many Issues amended in upcoming 24.04-2.0 Release

When I watched that video referenced above, I continuously thought: ah... this is fixed in the next major release of Ubuntu Touch, or: ah... this is a known issue that we have on the roadmap..., or: ah... this is done in this ways by design (so it's a feature or basic functionality)...

Let me just state, that most of the criticized aspects will be resolved in upcoming Ubuntu Touch release 24.04-2.0 (the tests in that video blog post have been run on Ubuntu Touch 24.04-1.x):

Camera notch and rounding corners get honoured now by the UI
Ubuntu Touch's default webbrowser (Morph Browser) has been bumped from Chromium engine v87 (Qt5 based) to v134 (Qt6 based), installing another browser should not be necessary anymore (note that the privacy level in Morph Browser is pretty high, so using other browsers could mean a loss of privacy).
Bluetooth pairing agent got added to the bluetooth indicator
Ubuntu Touch now supports Snaps on CLI level and in the OpenStore app
Libertine has received fixes, but no substantial improvements. It mainly targets users who want to use their Ubuntu Touch device as desktop daily driver. Libertine-provided desktop apps UI-wise are often not usable on a phone-like device.

The full feature preview of the 24.04-2.0 release can be found here: https://ubports.com/blog/ubports-news-1/ubuntu-touch-24-04-2-0-beta-is-n...

Ubuntu Touch App Ecosystem

The app ecosystem of Ubuntu Touch is quite specific, because many apps in Ubuntu Touch have been explicitly developed for Ubuntu Touch using a widget toolkit called Lomiri.Components. However, in Ubuntu Touch we also encourage developers to provide apps written with other convergent-capable toolkits, such as QQC2-based apps or Kirigami-based apps.

One reason for the very different app ecosystem in Ubuntu Touch is that many service providers don't have Ubuntu Touch on their radar when investing in app development for their services. Some Ubuntu Touch App Developers work around this by either implementing unofficial client apps for web services (e.g. the Flow app for Deezer by Sander Klootwijk), others provide the web service via implementing a web app (will not work when offline, but at least will show up as an app in the launcher).

The overall solution for making Open-Store.io more familiar to users who migrate from Android is that commercial service providers start honouring digital sovereignty and start providing apps for Linux. Not just for the Linux desktop, but also for mobile Linux platforms. This dual use case can easily achieved with an app development that bears convergence in mind.

App Ecosystems are also a Matter of Perspective

And one more minor note: whenever I open an Android appstore or can peak over someone's shoulder using an iOS device: I always wonder: what are all these apps about??? Never heard about them.

So, familiarity really depends on perspective. And perspective depends on what you are used to. Change what you do and your perspective will follow.

Ubuntu Touch's root filesystem (rootfs) is Immutable

Only thing from that video blog post that we haven't fixed and won't do so in the midterm future is apt-get not working on the command line.

The reason for this is: the Ubuntu Touch root file system is an immutable file system and thus shall not be changed via apt-get & friends by ordinary users.

There are various discussions ongoing such as dpkg-divert'ing apt-get to a wrapper shell script that spits out an error message if rootfs is mounted read-only and someone tries to install packages the Debian/Ubuntu way. Other approaches are to mount some RAM disk over the rootfs, so apt-get can be used at runtime but changes to the system get reset at reboot.

However, it is possible to mount the root filesystem read-write and test newer package versions (as UT core developers do regularly, in fact). If you tinker with this, it is recommended to reflash your device (don't wipe user data, when you reflash!) from time to time, because adding packages or package upgrades to your rootfs may over time corrupt the integrity of the rootfs.

One reason for apt-get breaking the rootfs and thus your Ubuntu Touch development device is that the upgrade process of the rootfs image is incremental, so update tarballs sometimes contain only those parts that got changed between this and your previous upgrade (sometimes, upgrades contain a complete rootf image, depending on the interval between upgrades). If files from an incremental update tarball mix into a rootfs that got tinkered with via apt-get, you really end up on your own. Re-flashing will grab the complete rootfs tarball and wipe the whole rootfs and reinstall a fresh version of the newest rootfs image. Developers also do this in regular intervals to ensure their test device is clean again before running more/other tests.

Ubuntu Touch development - 24.04-2.0 Beta and Meaning of Branching-Off

Di., 16 Juni 2026 11:14:29 +0000

The next Ubuntu Touch major release is approaching rapidly, yesterday we reached a major step in the preparation of the upcoming Ubuntu Touch 24.04-2.0 release: The branching-off (see below on what that is).

Ubuntu Touch 24.04-2.0 Beta is Now Available

Part of this development release step is the publication of the 24.04-2.0 Beta release images, for more details and information see:
https://ubports.com/blog/ubports-news-1/ubuntu-touch-24-04-2-0-beta-is-n...

And additionally, find below some background information on how we maintain various Ubuntu Touch releases in parallel via Git(Lab). In fact, the release model of Ubuntu Touch has partially been adopted from how we in Debian maintains our various Debian versions in parallel, only that in Ubuntu Touch we use Git(Lab) for maintaining the different package versions and not, like in Debian, the APT archive itself.

What does 'Branching-Off' Mean?

Last Saturday, in the UBports Q&A, I explained Ubuntu Touch's "branching-off", an aspect of the Ubuntu Touch release workflow based on Git(Lab). To make this accessible to even more people, here it comes as a write-up:

We host many Git repositories on GitLab, and our primary work is done on the main branches, which contain the bleeding-edge code. When a merge request is deemed critical for stable versions of Ubuntu Touch, we cherry-pick it into a release series branch.

Currently, we land our changes in the main branches and then cherry-pick them to the ubports/24.04.1.x branches. The 'branching off' process for the upcoming 24.04-2.x release means that our current main branches will be copied over to create new branches for this release cycle, namely ubports/24.04-2.x.

This has two major implications. First, any item that hasn't been translated by the time of the branch-off will not receive any more translation updates during the 24.04-2.x cycle. This is why it is crucial that translation work is completed before the branching-off.

Warning of Breaking Changes arriving soon in 26.04-1.x Daily Development UT Images

Second, looking ahead to the release after 24.04-2.x, we will be approaching 26.04-1.x. The OS base will change to Ubuntu 26.04 LTS, hopefully being ready for release to Ubuntu Touch users before the end of the year. We already have a list of features we want to land there. Because we plan to include various major changes, such as the switch from Mir 1 to Mir 2, new calendar and contacts backends, Qt6-based core apps and service components, etc., the likelihood of breaking changes at the beginning of the 26.04-1.x release cycle (which will become the next main branches' target) is very high.

The Ubuntu Touch 24.04-2.0 Release Schedule

The current release schedule is estimated to be:

25 May 2026 [done]
Platform stability freeze 24.04-2.x

25 May 2026 [done]
String freeze 24.04-2.x

15 June 2026 [done]
Branching-off (and unfreeze 26.04-1.x development), UT image release: 24.04-2.0 Beta

22 or 29 June 2026 [coming]
Final freeze for 24.04-2.x, UT image release: 24.04-2.0 RC

6 or 13 July 2026 [coming]
Release version 24.04-2.0

Ayatana Indicators: Call for Translations

Fr., 12 Juni 2026 21:50:34 +0000

In the process of preparing a major Ubuntu Touch release (v24.04-2.0, coming soon...) we will also update Ayatana Indicators in Ubuntu Touch.

Last week various new features have been added to some of the indicators (toggle switch to keep the display switched on permanently, blue tooth pairing agent, redesign of the keyboard indicator, etc.) and those changes require translation updates.

If you can, please visit [1] this weekend and help translating Ayatana Indicators into your native language. Thanks so much!!!

light+love
Mike

[1] https://hosted.weblate.org/projects/ayatana-indicators/

Future of libayatana-appindicator (v0.6.0 released today)

Mi., 10 Juni 2026 20:15:00 +0000

Some of you might have noticed that the recent (or rather: previous) version of libayatana-appindicator (v0.5.94) notified users and developers of the library being deprecated.

This short post is to notify you, that with today's libayatana-appindicator v0.6.0 release [1] this deprecation warning has now been removed again. Another new feature (added to AppIndicator without ABI breakage) is tooltip support. The new package version has just been uploaded to Debian experimental. Please test if your application (if it gets linked against libayatana-appindicator) continues to work flawlessly. Thanks!

libayatana-appindicator will receive continued support until GTK-3 becomes end-of-life (because libayatana-appindicator has a baked-in GTK-3 dependency which should not be ported to GTK-4 imho). That said, in the future, GTK-3 applications can continue using libayatana-appindicator for sending AppIndicator-like icons and menus over DBus to KStatusNotifierItem-based system tray renderers.

If you are looking for an AppIndicator implementation for GTK-4 applications (or other), I'd like to encourage you to help making libayatana-appindicator-glib [2] a new standard (can be used in GTK and Qt applications alike, implementation is using pure Glib-2.0). Currently, there is only one renderer (ayatana-indicator-application), so more work needs to be done on the renderers' side. (One of the next work items here is to get AppIndicator-Glib support working in Lomiri's desktop/windowed mode).

[1] https://github.com/AyatanaIndicators/libayatana-appindicator/releases/ta...
[2] https://github.com/AyatanaIndicators/libayatana-appindicator-glib/

Voxit 1.0 has been released

Di., 09 Juni 2026 09:45:00 +0000

Official announcement

European Voxit community strengthens digital sovereignty: shared codebase completed.

Read the official announcement at:
https://www.voxit.org/european-voxit-community-strengthens-digital-sover...

The Voxit community and platform development

The Voxit participation platform is originally based on the open source Polis platform developed by The Computational Democracy Project in the United States, but since its establishment in autumn 2025, the European Voxit community has been developing an independent solution, adapted to European needs.

The aim is to create an open source, interoperable and scalable participation infrastructure suited to Europe’s regulatory environment and aligned with democratic values. Through this development work, Voxit is becoming a clearly distinct fork of the original Polis platform – allowing Europe to develop participatory infrastructure at its own pace and according to its own governance needs, while the original Polis project continues to break new ground. This enables Europe to build its own open and trustworthy digital democracy tools, rooted in public governance and European democratic traditions.

Voxit 1.0 source code is now available

The source code for version 1.0 of the European community edition of the Voxit platform has now been published and is openly maintained on GitLab.com at: https://gitlab.com/voxit/voxit#

KVM Support inside LXC Containers [updated]

Mo., 27 Apr. 2026 09:44:28 +0000

Yesterday, I had to add support for running KVM virtual machines inside an LXC container. More as a reminder to myself, in case I ever have to do this again, here the simple recipe:

LXC Container Config Adjustment

Enable lxc.autodev and execute hook script to be executed after initial /dev creation (updated 20260428: lxc.cgroup2.* instead of lxc.cgroup.*):

[...]

# Auto-create /dev nodes and add native KVM support to the LXC container
lxc.autodev = 1
lxc.hook.autodev = /var/lib/lxc/.hooks/lxc-hook.kvm-support
lxc.cgroup2.devices.allow = c 10:232 rwm
lxc.cgroup2.devices.allow = c 10:238 rwm
lxc.cgroup2.devices.allow = c 10:241 rwm

[...]

[added 20260408] On the internet, you can find a recipe that simply bind-mounts /dev/kvm from the host in to the LXC container. However, this fails if group ID of POSIX group kvm differs between host and container.

LXC Hook Script for KVM Support Enablement

The following script I placed at /var/lib/lxc/.hooks/lxc-hook.kvm-support (on the LXC host!):

#!/bin/sh

# set up native KVM support in LXC container
mknod -m 0660 ${LXC_ROOTFS_MOUNT}/dev/kvm c 10 232
chown :kvm ${LXC_ROOTFS_MOUNT}/dev/kvm
mknod -m 0660 ${LXC_ROOTFS_MOUNT}/dev/vhost-net c 10 238
chown :kvm ${LXC_ROOTFS_MOUNT}/dev/vhost-net
mknod -m 0660 ${LXC_ROOTFS_MOUNT}/dev/vhost-vsock c 10 241
chown :kvm ${LXC_ROOTFS_MOUNT}/dev/vhost-vsock

Join us at Lomiri CodeFest on May 16-17 & Fre(i)e Software GmbH is hiring more Lomiri Developers

Di., 21 Apr. 2026 17:35:40 +0000

Lomiri Codefest in Tilburg NL (May 16-17 2026)

Just a quick invitation to an in-person event in Tilburg, the Netherlands.

All people interested in the Lomiri Operating Environment are invited to join us at the Lomiri Codefest [codefest] taking place on May 16-17 (participation is free of charge).

We are hiring Lomiri developers

And as another side node, we still have budget (until 07/2027) for 2-3 additional Lomiri developers (depends on each devs weekly availability). The details of my previous post [hiringdetails] +/- still apply. One more limitation / strength: You need real coding skills to apply for the open positions, AI-generated contributions will not be accepted for the tasks at hand.

If you are interested and a skilled FLOSS developer (you need previous OSS contributions as references) and available with at least 10 hrs / week, please get in touch [fsgmbh].

References

[codefest] https://codefest.os-sci.info/?lang=en
[hiringdetails] https://sunweavers.net/blog/node/150
[fsgmbh] https://freiesoftware.gmbh/

Debian Lomiri Tablets 2025-2027 - Project Report (Q4/2025)

Do., 12 März 2026 08:59:05 +0000

On 25th Oct 2025, I announced via my personal blog and on Mastodon that Fre(i)e Software GmbH was hiring. The hiring process was a mix of asking developers I know and waiting for new people to apply.

At the beginning of November 2025 / in mid November 2025, we started with 13 developers (all part-time) to work on various topics around Lomiri (upstream and downstream). Note that the below achievements don't document the overall activity in the Lomiri project, but that part that our team at Fre(i)e Software GmbH contributed to.

Organizational Achievements

Setup management board for Qt6 migration in Lomiri [1]
Setup management board for salsa2ubports package syncing [2]
Bootstrap Qt 6.8 in UBports APT repository
Bootstrap Qt 6.8 in Lomiri PPA
Fix Salsa CI for all Lomiri-related Debian packages
Facilitate contributor's project around XDG Desktop Portal support for Lomiri.
Plan how to bring DeltaTouch and DeltaChat core to Debian

Maintenance Development

Replace libofono-qt by libqofono in telepathy-ofono
Rework unit tests in telepathy-ofono utilizing ofone-phonesim
Obsolete not-used-anymore u1db-qt
Fixing wrong bin:pkg names regarding snapd-glib's QML module

Qt6 Porting

qmake -> CMake porting (if needed) and Qt6 porting of shared libraries and QML modules consumed by Lomiri shell and Lomiri apps:
- biometryd
- libqofono
- libqofonoext
- libqtdbusmock
- lomiri-account-polld
- lomiri-action-api
- lomiri-api
- lomiri-download-manager
- lomiri-location-service
- lomiri-online-accounts
- lomiri-push-qml
- lomiri-push-service
- maliit-framework
- mediascanner2
- qtlomiri-appmenutheme
- qtpim (started, work in progress)
- qwebdavlib
- signond (flaws spotted in Debian's porting of signond to Qt6)

Feature Development

Continuing with Morph Browser Qt6 / LUITK
- Build, run and fix LUITK unit tests for Qt6
- various bug fixes and improvements for Morph Qt6
Add mbim modem support to ofono upstream
Improve ofono support in Network Manager
Improve mbim modem support in lomiri-indicator-network
Package kazv (convergent Matrix client) and dependencies for Debian
Provide Lomiri images for Mobian

Research

Research on fuse-based caching Webdav client for lomiri-cloudsync-app.
Research on alternative ORM instead of QDjango in libusermetrics

[1] https://gitlab.com/groups/ubports/development/-/boards/9895029?label_name%5B%5D=Topic%3A%20Qt%206
[2] https://gitlab.com/groups/ubports/development/-/boards/10037876?label_name[]=Topic%3A%20salsa2ubports%20DEB%20syncing

Debian Lomiri Tablets 2025-2027 - Project Report (Q3/2025)

Sa., 28 Feb. 2026 18:36:37 +0000

Debian Lomiri for Debian 13 (previous project)

In our previous project around Debian and Lomiri (lasting until July 2025), we achieved to get Lomiri 0.5.0 (and with it another 130 packages) into Debian (with two minor exceptions [1]) just in time for the Debian 13 release in August 2025.

Debian Lomiri for Debian 14

At DebConf in Brest, a follow-up project has been designed between the project sponsor and Fre(i)e Software GmbH [2]. The new project (on paper) started on 1st August 2025 and project duration was agreed on to be 2 years, allowing our company to work with an equivalent of ~5 FTE on Lomiri targetting the Debian 14 release some time in the second half of 2027 (an assumed date, let's see what happens).

Ongoing work would be covered from day one of the new project and once all contract details had been properly put on paper end of September, Fre(i)e Software GmbH started hiring a new team of software developers and (future) Debian maintainers. (More of that new team in our next Q4/2025 report).

The ongoing work of Q3/2025 was basically Guido Berhörster and myself working on Morph Browser Qt6 (mostly Guido together with Bhushan from MiraLab [3]) and package maintenance in Debian (mostly me).

Morph Browser Qt6

The first milestone we could reach with the Qt6 porting of Morph Browser [4] and related components (LUITK aka lomiri-ui-toolkit (big chunk! [5]), lomiri-content-hub, lomiri-download-manager and a few other components) was reached on 21st Sep 2025 with an upload of Morph Browser 1.2.0~git20250813.1ca2aa7+dfsg-1~exp1 to Debian experimental and the Lomiri PPA [6]).

Preparation of Debian 13 Updates (still pending)

In background, various Lomiri updates for Debian 13 have been prepared during Q3/2025 (with a huge patchset), but publishing those to Debian 13 are still pending as tests are still not satisfying.

[1] lomiri-push-service and nuntium
[2] https://freiesoftware.gmbh
[3] https://miralab.one/
[4] https://gitlab.com/ubports/development/core/morph-browser/-/merge_reques... et al.
[5] https://gitlab.com/ubports/development/core/lomiri-ui-toolkit/-/merge_re... et al.
[6] https://launchpad.net/~lomiri

Debian Lomiri Tablets - We are hiring!

Sa., 25 Okt. 2025 20:58:24 +0000

We at Fre{i}e Software GmbH now have a confirmed budget for working on Debian based tablets with the special goal to use them for educational purposes (i.e. in schools).

Those Debian Edu tablets shall be powered by the Lomiri Operating Environment (that same operating environment that is powering Ubuntu Touch).

That said, we are hiring developers (full time, part time) [*] [**]:

Lomiri developers (C/C++, Qt5 and Qt6, QML, CMake)
Debian maintainers

Global tasks will be:

Transition Lomiri from Qt5 to Qt6
Consolidate the Lomiri Shell on various reference devices (mainline Linux only)
Integrate Lomiri Shell with cloud services such as Nextcloud and OpenCloud
XDG Desktop Portal support for Lomiri, integrate better with non-Lomiri Wayland apps
Bring more Lomiri-specific (Ubuntu Touch) apps to Debian
... (more to come) ...

The budget will cover work for the +/- next 1.5-2 yrs. Development achievements shall culminate in the release of Debian 14.

If you are interested in joining our team, please get in touch with me via known communication channels.

light+love,
Mike (aka sunweaver at debian.org)

[fsgmbh] https://freiesoftware.gmbh
[*] We can employ applicants who are located in Germany, Austria or Poland (for other regions within the EU, please ask).
[**] Alternatively, if you are self-employed, we are happy to onboard you as a freelancer.