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.
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.
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/
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.
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#
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
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/
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).
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!
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.
|