Flatpak applications are based on runtimes such as KDE or Gnome Runtimes. Both of these runtimes are actually based on Freedesktop SDK which contains essential libraries and services such as Wayland or D-Bus.

Recently there were a lot of discussion about supply chain attacks, so it might be interesting to ask how Freedesktop SDK was built. The answer can be found in freedesktop-sdk repository:

sources:
- kind: ostree
  url: freedesktop-sdk:releases/
  gpg-key: keys/freedesktop-sdk.gpg
  track: runtime/org.freedesktop.Sdk.PreBootstrap/x86_64/21.08
  ref: 0ecba7699760ffc05c8920849856a20ebb3305da9f1f0377ddb9ca5600be710b

So it is built using an older version of Freedesktop SDK image. There is now an approved merge request that completely reworks bootstrapping of Freedesktop SDK. It uses another intermediate docker image freedesktop-sdk-binary-seed that bridges the gap between freedesktop-sdk and live-bootstrap.

So what is this live-bootstrap? If you look at parts.rst you’ll see that it is a build chain that starts with 256 byte hex assembler that can build itself from its source and also 640-byte trivial shell that can read list of commands from the file and executes them. Then it proceeds building 130 (as of the moment of writing) other components and in the process builds GCC, Python, Guile, Perl and lots of other supporting packages. Furthermore, each component is built reproducibly (and this is checked using SHA256 hash).

Some caveat: at the moment freedesktop-sdk-binary-seed still uses older binary of rustc to build rustc but in principle one could leverage mrustc to build it. Or possibly rust-gcc will become more capable in future versions and will be able to bootstrap rustc.

So unless your flatpak application uses rust, it will soon be buildable from sub 1 KiB binary seed.

This is a rather small release with only two new features and one small improvement.

Big thank you to Xstrahl Inc. who sponsored development of new features included in this release and of QCoro in general.

And as always, thank you to everyone who reported issues and contributed to QCoro. Your help is much appreciated!

The original release announcement on qcoro.dvratil.cz.

Improved QCoro::waitFor()

Up until this version, QCoro::waitFor() was only usable for QCoro::Task<T>. Starting with QCoro 0.8.0, it is possible to use it with any type that satisfies the Awaitable concept. The concept has also been fixed to satisfies not just types with the await_resume(), await_suspend() and await_ready() member functions, but also types with member operator co_await() and non-member operator co_await() functions.

QCoro::sleepFor() and QCoro::sleepUntil()

Working both on QCoro codebase as well as some third-party code bases using QCoro it’s clear that there’s a usecase for a simple coroutine that will sleep for specified amount of time (or until a specified timepoint). It is especially useful in tests, where simulating delays, especially in asynchronous code is common.

Previously I used to create small coroutines like this:

QCoro::Task<> timer(std::chrono::milliseconds timeout) {
 QTimer timer;
 timer.setSingleShot(true);
 timer.start(timeout);
 co_await timer;
}

Now we can do the same simply by using QCoro::sleepFor().

Read the documentation for QCoro::sleepFor() and QCoro::sleepUntil() for more details.

QCoro::moveToThread()

A small helper coroutine that allows a piece of function to be executed in the context of another thread.

void App::runSlowOperation(QThread *helperThread) {
 // Still on the main thread
 ui->statusLabel.setText(tr("Running"));

 const QString input = ui->userInput.text();

 co_await QCoro::moveToThread(helperThread);
 // Now we are running in the context of the helper thread, the main thread is not blocked

 // It is safe to use `input` which was created in another thread
 doSomeComplexCalculation(input);

 // Move the execution back to the main thread
 co_await QCoro::moveToThread(this->thread());
 // Runs on the main thread again
 ui->statusLabel.setText(tr("Done"));
}

Read the documentation for QCoro::moveToThread for more details.

Full changelog

See changelog on Github

KDE's getting started page on documentation states:

KDE documentation is written in DocBook XML.

Historically, this was probably a good decision. Who does not remember that XML was so much easier to read, parse, and work with compared to binary or virtually any propitiatory file format?

KDE is aiming to bump its major version to 6. This might be a good time to reflect whether DocBook should serve as the sole official documentation language. Well, I would like to open this to an optional second language.

I don't mind what the second language could be; possible candidates are reStructuredText / Sphinx, Markdown, AsciiDoc -- among others. I don't want to convert DocBook to any other format. But giving projects some choice, might help.

I am by far not the only person with regard to a replacement of DocBook: DigiKam recently switched to Sphinx for their user documentation after 20 years of using DocBook. Krita uses Sphinx for five years and Kdenlive for over a year. By the way, the Linux kernel left DocBook for Sphinx, too.

What do you think? This would be a good topic for an Akademy BoF. Where should we discuss this in the meantime?

The XRechnung format is a E-Government standard for electronic invoicing. At some point it will be mandatory for every company dealing with German governmental partners to send the invoices in this XML format.

Many commercial vendors have already caught up and provide ways to generate XRechnung formatted documents with their software. However, to my knowledge, the availability of open source end user software is very limited. Since the standard itself is at least very open and transparently documented, so I think it is worthwhile to also support it with free software on the desktop.

Kraft, the desktop software for invoicing and efficient office work in the small enterprise, supports export of XRechnung documents since a while.

Over the weekend I created a new little project that adds a viewer for XRechnung documents called xrview.

A german city was looking for something to evaluate processes in a Linux- and KDE based productivity work environment.

Technically it is not very sophisticated: It renders the provided XML file using XSL styles officially provided by the Koordinierungsstelle für IT-Standards in a two step process to HTML, which is displayed in a web view. Some values of interest are extracted from the XML and displayed in a detail pane on the left side.

This is just a POC and has to be continued, but the time was good to kickstart this project.

Maybe anybody is interested to create a PR to help to improve digitalization in Germany?

It has been a while since the last blog post covering Qt OPC UA news. This short update will outline what we have primarily worked on in 2022.

Continue reading Qt OPC UA news catch up at basysKom GmbH.

New year, new digiKam Recipes book release. The new version features the completely rewritten Tag faces with the Face Recognition feature chapter and an all-new example workflow section in the Batch process photos and RAW files chapter. Several chapters have been revised and improved, including Edit tags with Tag Manager, Color management in digiKam, and Move digiKam library and databases. All screenshots have been refreshed, too. As always, the new revision includes plenty of tweaks and fixes.

We at the @kde-sig are happy to announce we have created a COPR repository which currently contains the KDE Plasma 5.27.0 Beta (aka: 5.26.90).

We intend to use this COPR repository in the future for KDE beta releases so that those Fedora users who want to help the KDE Community can test and report bugs to the KDE developers.

Enabling this COPR repository is very simple:

sudo dnf copr enable @kdesig/kde-beta
sudo dnf update

Your system should now have the Plasma Beta:

For our users using Kinoite, you should check out this blog post by @siosm

That’s all for now.

Feel free to join us at our Matrix room!.

Day 0

Day 1

• Building the Future of Qt, Together: What have happened in The Qt Project during the last two years
• Goals old and new! : What are Goals that were the focus of the community for the next year
  
  
• A Brief History of Terminals, and what the future holds for Konsole: Moto was "Trying to sell konsole to non kde users". I am not a KDE user and I really liked some cool stuff you can do with terminal
• Full Steam ahead! :Seen how Plasma fits into the Steamdeck and what aspects of KDE made us the right choice for their new userbase

Day 2

• Launching an application - How hard can it be? It was what I wanted actually since we are going to launch an application with the Open Source Team of our Univeristy.
• Healthy Mind, Healthy Code : Maybe this was my favourite talk