The migration of jobs from Binary Factory to KDE's GitLab continues. Last week almost all jobs that built APKs were migrated to invent.kde.org. The only remaining Android job on Binary Factory doesn't use Craft.

The Android APK jobs running on invent are the first jobs that make use of our CI Notary Services delegating tasks that require sensitive information (e.g. the keys to sign the APKs or the credentials to upload the APKs to our F-Droid repositories) to services running outside of GitLab. Currently, the apksigner service and the fdroidpublisher service are live. The configuration of the services can be found in the sysadmin/ci-utilities repository.

As before, the APKs are published in our F-Droid repositories:

• KDE Android Release Builds provides APKs built from the 23.08 branches.
• KDE Android Nightly Builds provides APKs built from the master branches.

The migration to invent has a few implications. On Binary Factory all APKs (release and nightly) were rebuilt once a day even if nothing changed. On invent the APKs are rebuilt whenever a change is pushed to the release/23.08 branch or the master branch of a project. Another change is that on invent any KDE developer can manually trigger a new pipeline to build the APKs (e.g. if a bug in a dependency was fixed). On Binary Factory you often needed to ask someone to trigger a build for you.

Building APKs If you want to start building APKs for your project then add the craft-android-apks.yml template for Qt 5 or the craft-android-qt6-apks.yml template for Qt 6 to the .gitlab-ci-yml of your project. Note that you must use the include:project format (example).

The jobs will build unsigned APKs. To enable signing your project (more precisely, a branch of your project) needs to be cleared for using the signing service. This is done by adding your project to the project settings of the apksigner. The master branch is cleared by default for all applications listed in the project settings, so that you only need to add two lines: The repo path on invent and the ID of your application. The key used to sign your application will best be created by us directly on the machine that does the signing.

Once you think the APKs are ready for publication you can enable publishing in our F-Droid repositories by adding your project to the project settings of the fdroidpublisher. Because some Qt 6 APKs are not yet ready for publication although their build succeeds, by default the master branch is not cleared for publishing. This means you will have to add five lines to the project settings of fdroidpublisher.

Outlook To complete the Android jobs/services a job/service for submitting APKs to Google Play will go live soon. It's currently only used by Itinerary but, in view of our Make a Living initiative, we hope to publish more apps on Google Play to create some revenue to fund our work. Creating and publishing Android Application Bundles (AAB), the new packaging format required for new applications published on Google Play, will follow soon after.

Then we'll add signing of Windows artifacts and installers and submission to the Microsoft Store, signing and publishing of Flatpaks, and signing and publishing of builds for macOS.

Today, 12 years after the meeting where AppStream was first discussed and 11 years after I released a prototype implementation I am excited to announce AppStream 1.0!

Check it out on GitHub, or get the release tarball or read the documentation or release notes!

Some nostalgic memories

I was not in the original AppStream meeting, since in 2011 I was extremely busy with finals preparations and ball organization in high school, but I still vividly remember sitting at school in the students’ lounge during a break and trying to catch the really choppy live stream from the meeting on my borrowed laptop (a futile exercise, I watched parts of the blurry recording later).

I was extremely passionate about getting software deployment to work better on Linux and to improve the overall user experience, and spent many hours on the PackageKit IRC channel discussing things with many amazing people like Richard Hughes, Daniel Nicoletti, Sebastian Heinlein and others.

At the time I was writing a software deployment tool called Listaller – this was before Linux containers were a thing, and building it was very tough due to technical and personal limitations (I had just learned C!). Then in university, when I intended to recreate this tool, but for real and better this time as a new project called Limba, I needed a way to provide metadata for it, and AppStream fit right in! Meanwhile, Richard Hughes was tackling the UI side of things while creating GNOME Software and needed a solution as well. So I implemented a prototype and together we pretty much reshaped the early specification from the original meeting into what would become modern AppStream.

Back then I saw AppStream as a necessary side-project for my actual project, and didn’t even consider me as the maintainer of it for quite a while (I hadn’t been at the meeting afterall). All those years ago I had no idea that ultimately I was developing AppStream not for Limba, but for a new thing that would show up later, with an even more modern design called Flatpak. I also had no idea how incredibly complex AppStream would become and how many features it would have and how much more maintenance work it would be – and also not how ubiquitous it would become.

The modern Linux desktop uses AppStream everywhere now, it is supported by all major distributions, used by Flatpak for metadata, used for firmware metadata via Richard’s fwupd/LVFS, runs on every Steam Deck, can be found in cars and possibly many places I do not know yet.

What is new in 1.0?

API breaks

The most important thing that’s new with the 1.0 release is a bunch of incompatible changes. For the shared libraries, all deprecated API elements have been removed and a bunch of other changes have been made to improve the overall API and especially make it more binding-friendly. That doesn’t mean that the API is completely new and nothing looks like before though, when possible the previous API design was kept and some changes that would have been too disruptive have not been made. Regardless of that, you will have to port your AppStream-using applications. For some larger ones I already submitted patches to build with both AppStream versions, the 0.16.x stable series as well as 1.0+.

For the XML specification, some older compatibility for XML that had no or very few users has been removed as well. This affects for example release elements that reference downloadable data without an artifact block, which has not been supported for a while. For all of these, I checked to remove only things that had close to no users and that were a significant maintenance burden. So as a rule of thumb: If your XML validated with no warnings with the 0.16.x branch of AppStream, it will still be 100% valid with the 1.0 release.

Another notable change is that the generated output of AppStream 1.0 will always be 1.0 compliant, you can not make it generate data for versions below that (this greatly reduced the maintenance cost of the project).

Developer element

For a long time, you could set the developer name using the top-level developer_name tag. With AppStream 1.0, this is changed a bit. There is now a developer tag with a name child (that can be translated unless the translate="no" attribute is set on it). This allows future extensibility, and also allows to set a machine-readable id attribute in the developer element. This permits software centers to group software by developer easier, without having to use heuristics. If we decide to extend the developer information per-app in future, this is also now possible. Do not worry though the developer_name tag is also still read, so there is no high pressure to update. The old 0.16.x stable series also has this feature backported, so it can be available everywhere. Check out the developer tag specification for more details.

Scale factor for screenshots

Screenshot images can now have a scale attribute, to indicate an (integer) scaling factor to apply. This feature was a breaking change and therefore we could not have it for the longest time, but it is now available. Please wait a bit for AppStream 1.0 to become deployed more widespread though, as using it with older AppStream versions may lead to issues in some cases. Check out the screenshots tag specification for more details.

Screenshot environments

It is now possible to indicate the environment a screenshot was recorded in (GNOME, GNOME Dark, KDE Plasma, Windows, etc.) via an environment attribute on the respective screenshot tag. This was also a breaking change, so use it carefully for now! If projects want to, they can use this feature to supply dedicated screenshots depending on the environment the application page is displayed in. Check out the screenshots tag specification for more details.

References tag

This is a feature more important for the scientific community and scientific applications. Using the references tag, you can associate the AppStream component with a DOI (Digital object identifier) or provide a link to a CFF file to provide citation information. It also allows to link to other scientific registries. Check out the references tag specification for more details.

Release tags

Releases can have tags now, just like components. This is generally not a feature that I expect to be used much, but in certain instances it can become useful with a cooperating software center, for example to tag certain releases as long-term supported versions.

Multi-platform support

Thanks to the interest and work of many volunteers, AppStream (mostly) runs on FreeBSD now, a NetBSD port exists, support for macOS was written and a Windows port is on its way! Thank you to everyone working on this

Better compatibility checks

For a long time I thought that the AppStream library should just be a thin layer above the XML and that software centers should just implement a lot of the actual logic. This has not been the case for a while, but there was still a lot of complex AppStream features that were hard for software centers to implement and where it makes sense to have one implementation that projects can just use.

The validation of component relations is one such thing. This was implemented in 0.16.x as well, but 1.0 vastly improves upon the compatibility checks, so you can now just run as_component_check_relations and retrieve a detailed list of whether the current component will run well on the system. Besides better API for software developers, the appstreamcli utility also has much improved support for relation checks, and I wrote about these changes in a previous post. Check it out!

With these changes, I hope this feature will be used much more, and beyond just drivers and firmware.

So much more!

The changelog for the 1.0 release is huge, and there are many papercuts resolved and changes made that I did not talk about here, like us using gi-docgen (instead of gtkdoc) now for nice API documentation, or the many improvements that went into better binding support, or better search, or just plain bugfixes.

Outlook

I expect the transition to 1.0 to take a bit of time. AppStream has not broken its API for many, many years (since 2016), so a bunch of places need to be touched even if the changes themselves are minor in many cases. In hindsight, I should have also released 1.0 much sooner and it should not have become such a mega-release, but that was mainly due to time constraints.

So, what’s in it for the future? Contrary to what I thought, AppStream does not really seem to be “done” and fetature complete at a point, there is always something to improve, and people come up with new usecases all the time. So, expect more of the same in future: Bugfixes, validator improvements, documentation improvements, better tools and the occasional new feature.

Onwards to 1.0.1!

Seems getting laid off was pretty good for me after all. Funny how things go sometimes.

A company that works on KDE stuff (and other Linuxy things), interviewed me for a fun job: "Wanna help us work on KDE Plasma?"

You bet I said YES!

So now I work daily 8 hours a day, 5 days a week, to improve KDE Plasma! It's contract work, but I hope people there like me a lot to keep me around. :) At least I am planning to be around for the long haul!

Anyway, this was my first week doing this job!

Everyone I work with is really nice and most of them I have already met during my contribution adventures.

The job itself for now has been about helping finding and fixing bugs in KDE Plasma. I've mostly concentrated on bugs that can appear when moving from 5 to 6, like migrating configs, etc.

There's some other stuff I'm doing as well, but they're not that visible to end user, necessarily. Like fixing warnings.

I am also focusing on learning the stack and hopefully eventually get to work more on Flatpak related things and Kwin related things, since those interest me. I am also hoping to help with accessibility, like high-contrast color schemes and such. And who knows what else I will work on in future!

Also due to my experience in test automation, I have taken on the sidequest to help with that part as well. I have been quite interested how test automation of Linux desktop apps works, and there's quite cool stuff going on there.

In my personal KDE plans, I want to add color customization options for separators, since those can be used in high contrast themes. But since it would be any custom color the user wants, well, they can set it to anything. Anyhow, I will first prioritize fixing bugs and learning more.

Thank you so much for the company who took me under their wing. And thanks to my colleagues for helping me get into this and teaching me things, even when my questions can be a bit dumb at times.. :'D You know who you are!

Expect more posts in future about what I learn during this job! :)

Thanks for reading!

The RiveQtQuickPlugin has now integrated the latest rivecpp version. We've implemented rendering support for rive text elements. We ensured seamless text rendering compatibility across both software and hardware-backed renderers. Explore our latest blog post for a demonstration video and to learn about more rendering enhancements.

Continue reading RiveQtQuickPlugin now with Text Support at basysKom GmbH.

What the Alpha means

The alpha release primarily focuses on preparing our software for a future release. It involves handling unreleased dependencies, version numbers, co-installation conflicts, and all the relevant bookkeeping work.

This release has been somewhat manic, with issues surfacing up to the last minute. However, that's precisely what this early release is for: resolving these issues now and gathering feedback on packaging to ensure a smoother transition to the beta phase.

Feature Freezes

The complete feature freeze for Plasma is scheduled for the day of the first beta, which is on November 29th. After that, bug fixing will be the sole focus for a period of three months leading up to the final release.

A soft freeze is set for the week before, on the 22nd, to accommodate any significant changes and ensure a seamless beta release.
This is mostly a case of doing a final round of landing straggling merge requests rather than developers starting anything new.

Should I run it?

Plasma 6 is in a pretty good state; I've been using it as a daily driver without issues for months

The alpha release does have known issues, some already fixed, but unreleased with the pending Qt 6.6.1, some our side fixed since alpha tagging, and some we need to follow up, particularly in the more esoteric areas of Plasma.
If you're the sort of user that wants to help out Plasma and are of a skill level where you're happy to log into another desktop session if things are temporarily down.

I would recommend as a user finding a distribution that covers 'git master' builds rather than any snapshot as it can provide a more dynamic list . A list can be found at https://community.kde.org/Plasma/Plasma_6#How_to_use/test_it

Pre-upgrade steps

Please take a backup of ~/.config/plasma* before upgrading. Just in case you need to file bug reports about config migration from 5.

Can I get involved?

Absolutely! It's an exciting time for Plasma and KDE in general. There are numerous tasks you can dive into. Check out our onboarding wiki here: https://community.kde.org/Get_Involved

qqc2-breeze5-style is a theme used by Plasma Mobile. This alpha release is a re-bundling of the Plasma/5.27 branch of qqc2-breeze-style. It is for use by distros shipping alpha releases of Plasma 6 so that Qt 5 apps continue to be themed appropriately.

URL: https://download.kde.org/unstable/qqc2-breeze5-style/

SHA256: 813f9da4861567e70d1eccf3a3a092d802ac9475a91070fb47fa
8766f3c1e310

Signed by E0A3EB202F8E57528E13E72FD7574483BB57B18D Jonathan Esk-Riddell <jr@jriddell.org>
https://jriddell.org/esk-riddell.gpg

Oxygen Icons is an icon theme for use with any XDG compliant app and desktop.

It is part of KDE Frameworks 6 but is now released independently to save on resources.

This is the first (and likely only) pre-release, versioned 5.245.0, and it will have a stable release alongside KDE Frameworks 6 in February.

Distros which ship this version can drop the version released as part of KDE Frameworks 5.

sha256: b082a1a9a6d06cdeee2863555951609e95dd499f133035d04719a16f8500497f

URL: https://download.kde.org/unstable/oxygen-icons/

Signed by E0A3EB202F8E57528E13E72FD7574483BB57B18D Jonathan Esk-Riddell <jr@jriddell.org>
https://jriddell.org/esk-riddell.gpg

This project is trying to create a WS-Discovery client library based on the KDSoap
library.

The name is short for Klarälvdalens Datakonsult AB Simple Object Access Protocol Web Services Addressing Discovery Client

It is used by the SMB KIO worker from kio-extras.

kio-extras will have two releases as part of KDE’s 6th Megarelease, one for Qt 5 and one for Qt 6. Distros should build and ship both versions of kio-extras but the Qt5 build should use an internal static copy of kdsoap-ws-discovery-client so does not need to be built separately. The Qt 6 build of kio-extras does need this external build of kdsoap-ws-discovery-client. Distros will need an up to date copy of KDSoap library https://github.com/KDAB/KDSoap/tags.

SHA 256: 5007747f1ce607639bb63244f8894c03a15194c0a891b8d85e10d76dbdf79188
URL: https://download.kde.org/unstable/kdsoap-ws-discovery-client/
Signed by E0A3EB202F8E57528E13E72FD7574483BB57B18D Jonathan Esk-Riddell <jr@jriddell.org>
https://jriddell.org/esk-riddell.gpg