I’m using an external keyboard (1) and mouse (2), but the laptop lid is usually still open for better cooling. That means the internal keyboard (3) and touchpad (4) – made of comfortable materials – are open to be used by a cat searching for warmth (7), in the obvious “every time” case that a normal non-heated nest (6) is not enough.

The problem is, everything goes chaotic at that point in the default configuration. The solution is to have quick shortcuts in my Dash to Dock (8) to both disable (10) and enable (9) keyboard and touchpad at a very rapid pace.

It is to be noted that I’m not disabling the touch screen (5) by default, because most of the time the cat is not leaning on it – there is also the added benefit that if one forgets about the internal keyboard and touchpad disabling and detaches the laptop from the USB-C monitor (11), there’s the possibility of using the touch screen and on-screen keyboard to type in the password and tap on the keyboard/touchpad enabling shortcut button again. If also touch screen was disabled, the only way would be to go back to an external keyboard or reboot.

So here are the scripts. First, the disabling script (pardon my copy-paste use of certain string manipulation tools):

dconf write /org/gnome/desktop/peripherals/touchpad/send-events "'disabled'"
sudo killall evtest
sudo evtest --grab $(sudo libinput list-devices | grep -A 1 "AT Translated Set 2 keyboard" | tail -n 1 | sed 's/.*\/dev/\/dev/') &
sudo evtest --grab $(sudo libinput list-devices | grep -A 1 "Dell WMI" | tail -n 1 | sed 's/.*\/dev/\/dev/') &
sudo evtest --grab $(sudo libinput list-devices | grep -A 1 "Power" | grep Kernel | tail -n 1 | sed 's/.*\/dev/\/dev/') &
sudo evtest --grab $(sudo libinput list-devices | grep -A 1 "Power" | grep Kernel | head -n 1 | sed 's/.*\/dev/\/dev/') &
sudo evtest --grab $(sudo libinput list-devices | grep -A 1 "Sleep" | grep Kernel | tail -n 1 | sed 's/.*\/dev/\/dev/') &
sudo evtest --grab $(sudo libinput list-devices | grep -A 1 "HID" | grep Kernel | head -n 1 | sed 's/.*\/dev/\/dev/') &
sudo evtest --grab $(sudo libinput list-devices | grep -A 1 "HID" | tail -n 1 | sed 's/.*\/dev/\/dev/') &
#sudo evtest --grab $(sudo libinput list-devices | grep -A 1 "ELAN" | tail -n 1 | sed 's/.*\/dev/\/dev/') # Touch screen

And the associated ~/.local/share/applications/disable-internal-input.desktop:

[Desktop Entry]
Version=1.0
Name=Disable internal input
GenericName=Disable internal input
Exec=/bin/bash -c /home/timo/Asiakirjat/helpers/disable-internal-input.sh
Icon=yast-keyboard
Type=Application
Terminal=false
Categories=Utility;Development;

Here’s the enabling script:

dconf write /org/gnome/desktop/peripherals/touchpad/send-events "'enabled'"
sudo killall evtest

and the desktop file:

[Desktop Entry]
Version=1.0
Name=Enable internal input
GenericName=Enable internal input
Exec=/bin/bash -c /home/timo/Asiakirjat/helpers/enable-internal-input.sh
Icon=/home/timo/.local/share/icons/hicolor/scalable/apps/yast-keyboard-enable.png
Type=Application
Terminal=false
Categories=Utility;Development;

With these, if I sense a cat or am just proactive enough, I press Super+9. If I’m about to detach my laptop from the monitor, I press Super+8. If I forget the latter (usually this is the case) and haven’t yet locked the screen, I just tap the enabling icon on the touch screen.

Then using openqa-clone-job (and derivates) one can use the SCHEDULE variable to clone a test run with a custom set of test modules. This is particular useful, when developing a new test case and you need a verification run with e.g. an additional test module or to exclude some failing ones. However it is sometimes cumbersome to type out a large list of tests into a custom SCHEDULE variable, if the amount of test modules exceeds 5 or more tests (e.g. extra_tests_textmode - good luck!).

Dear Tumbleweed users and hackers,

Unfortunately, we could not keep up the daily streak of snapshots during this week. We ‘only’ managed to push out 6 snapshots. Over the last weekend, we had an openQA-worker causing some troubles, which resulted in not sufficient throughput to get anything ready to publish. But 6 snapshots is still acceptable, isn’t it? Anyway, we had the following releases: 1202, 1203, 1205, 1206, 1207, and 1208.

The main changes included were:

• KDE Plasma 5.23.4
• Automake 1.16.5
• sssd 2.6.1
• Harfbuzz 3.1.1: as announced, sadly with an ABI break. I triggered a rebuild of everything behind harfbuzz, so unless packages explicitly used the lost API, they should be back in shape at least. One known fallout is still electron, which I have a submission on the queue, scheduled for snapshot 1210.
• Linux kernel 5.15.6
• Mesa 21.3.1
• gc 8.2.0
• Poppler 21.12.0
• strace 5.15
• GCC 11: Enable the full cross compiler, cross-aarch64-gcc11 and cross-riscv64-gcc11 now provide a fully hosted C (and C++) cross compiler, not just a freestanding one

Stagings are almost all filled, and you can expect these changes coming to Tumbleweed soon:

• Linux kernel 5.15.7
• Mozilla Firefox 95.0
• Rust 1.57
• Kubernetes 1.23
• KDE Applications 21.12.0
• GNOME 41.2
• Moving default php version from php7 to php8
• Testing the results when moving system ruby from 2.7 to 3.0: YaST team is working on the main fallouts
• Enabling the build of python310-* modules; the move of the devault python3 provider to python310 should follow soon after
• pipewire 0.3.40, with a move to from pipewire-media-session to wireplumber; currently failing openQA
• openSSL 3.0

It is easy to over-complicate log management. Almost all departments in a company need to log messages for their daily activities. However, installing several different log management and analysis systems in parallel is a nightmare both from a security and an operations perspective and wastes many resources. You cannot always reduce the number of log analysis systems, but you can reduce the complexity of log management. Let me show you, how.

Read my blog at https://www.syslog-ng.com/community/b/blog/posts/reducing-the-complexity-of-log-management

Note: unlike most of my blogs, this one is not deeply technical. Rather it gives a good overview, why a dedicated log management layer is important. The second half of my blog also mentions commercial software.

This week brought an exuberant amount of openSUSE Tumbleweed snapshots.

While the rolling release snapped its streak of continuous daily snapshots, Tumbleweed persists releasing numerous snapshots; in total, five have been released so far this week.

The last snapshot, 20211207, updated one package that gamers will appreciate. The computer opponent for the board game Blokus was updated with the release of pentobi 19.1. The bug fixing update provided a work around for a crash that happened during an exit in some situations. The package also avoids a warning with Qt 6 caused by a deprecated signal-handler syntax.

Snapshot 20211206 updated the 3D graphics package Mesa to version 21.3.1. The updated provided mostly AMD, Intel and Zink fixes. The package also added a work around to fix a segfault with the first-person shooter video game Metro Exodus, which announced availability with Linux in April 2021. The highly portable implementation of the Domain Name System protocol bind 9.16.23 fixed CVE-2021-25219 by disabling the lame server cache that would have allowed an attacker to significantly degrade resolver performance. There were some patches removed in the blog 2.26 update. Font rendering package freetype2 2.11.1 improved cmake support and updated the latest experimental COLRv1 Application Programming Interface to OpenType standard 1.9. Another rendering package poppler, which is for pdfs, updated to version 21.12.0 and added a few APIs; one to read/save to file descriptor; one to add images; and one to validate signatures. Many incremental improvements and bug fixes were made in the libvirt 7.10.0 update and a new feature is a binary that helps users figure out the format of Distinguished Name from a certificate file the way it expects in the tls_allowed_dn_list option of the libvirtd.conf configuration file. The userspace components for the Linux Kernel’s drivers and infiniband subsystem package rdma-core 38.0 was the only major version update in the snapshot; it updated kernel headers stddef.h. Other packages to update in the snapshot were gc 8.2.0, kImageAnnotator 0.5.3, strace 5.15 and more.

Snapshot 20211205 was pretty much all about the compiler and kernel with the exception on one other package; parsing library package mxml 3.3 fixed a potential memory leak in mxmlLoad functions and added more error handling to the library. The minor update of gcc11 11.2.1 enabled the cross compilers on the i586 microprocessor and removed the cross compilers for the i386 target. The 20211123 kernel-firmware updated the firmware file for Intel Bluetooth and kernel-source 5.15.6 fixed codecs for ALSA System on Chip errors, some discovery of arm firmware and a couple network facets like fixing the bridge port operation related to Marvell hardware.

Most of the updates in snapshot 20211203 were related to YaST. The update of yast2-storage-ng 4.4.20 fixed regressions for unit tests and replicated the generation of bcache issues to avoid setting the architecture for every test. The yast2-installation 4.4.26 package added a display the of a product’s license when only one product is available, but will not display the product’s selector during an upgrade. Virtualization package xen 4.16.0 made fixes to the Trusted Platform Module in preparation for TPM 2.0 support. A major version update of the text shaping library harfbuzz became available in the snapshot; the 3.1.1 version improved Unicode 14 properties in the shaper and provided COLRv1 tables subsetting support, and various other subsetter fixes. Other packages to update were libstorage-ng 4.4.63, scout 0.2.6, rubygem-cheetah 1.0.0 and rubygem-yast-rake 0.2.43.

Starting the week, KDE users could update to Plasma 5.23.4 in snapshot 20211202. Plasma’s software management GUI Discover made some adjustments on handling Flatpak and other software. Plasma’s power consumption package PowerDevil fixed a bug that had a different notification behavior for a critical battery than that of a low battery. Other packages updated in the snapshot were sssd 2.6.1, which hardened systemd services, and automake 1.16.5, which dropped a couple patches and made the output more reproducible.

After a lot of work, Ritchie-CLI 2.11.3 is officially available in the openSUSE Tumbleweed repository. Ritchie-CLI became official Nov. 11 in Tumbleweed, but was not covered in previous blogs. A big congratulations goes out to the entire ZUP team!

Ritchie is an open-source tool developed by the ZUP Company and allows users to create, store and share automations securely. It optimizes repetitive commands so users have more programming autonomy. Ritchie release notes provides an add Rhythm List Formulas command, a forced update option to run the latest formula version when enabled, lib to support Ritchie-CLI internationalization, repository new version detection using cache, and many other features. Alessandro de Oliveira Faria is working to add a new package to Factory and help from the openSUSE community is welcomed. The package is also in Alessandro’s Open Build Service home project for those interested in testing; there is also cloud testing. More information can be found in the package’s release notes.

Deploying software for HPC clusters is often a complex task, as HCP cluster tend to have a fixed software stack. Also precompiled software is not always fully optimized to hardware of the HPC cluster. With this post I want to describe two tools which try to solve these problems. The first one is spack which is build system for mainly HPC applications and their dependencies. With singularity[1] these HPC applications can be packed into containers which can be executed in user space.

Preparations

As well spack as singularity are available as packages in openSUSE Tumbleweed, Leap and via PackageHub for SLE. The packages can be installed with

# sudo zypper install singularity spack

After the installation you should add all the users which want to use singularity to the singularity group, e.g. with

# sudo usermod -a -G singularity <user_login>

Create singularity definition

Now you have to decide which application to build inside the container. For this example we will gromacs with MPI support. So create the file spack.yaml with following content

spack:
  specs:
  - gromacs+mpi
  - openmpi

  container:
    format: singularity
    images:
      os: "leap:15"
      spack: "latest"

    os_packages:
      final:
      - libgomp1

additionally the multi threading support is enable in the final container with the installation of the OpenMP runtime library libgomp1. The definition file for singualrity can then be created with the command

spack containerize > gromacs-mpi.def

Build the container

With this definition the final application container image can now build with the command

singularity build --fakeroot gromacs-mpi.sif gromacs-mpi.def

where the --fakeroot switch to allow building for non root users. The build will have two phases, where the first one will pull in the container spack/leap15:latest which has spack and necessary build tools installed, build gromacs together with openmpi and move the resulting binaries to the container opensuse/leap:latest. The binairis built with spack are located in the container under /opt/view/bin.

Inspect the container

A single command within the container can be run with

singularity exec gromacs-mpi.sif ls /opt/view/bin

which will list all the binaries installed under /opt/view/bin within the container. You can also open a shell in the container with

singularity shell gromacs-mpi.sif

Please note that the home directory of the user is mounted under $HOME in the container.

Run the container

Now you can run the application, which is gromacs in this case, in parallel with

mpirun singularity exec gromacs-mpi.sif gmx_mpi mdrun\
	-s topol_pme.tpr -maxh 0.50 -resethway\
	-noconfout -nsteps 10000 -g gmx_sing.log

Have a lot of fun

Apptainer

[1] In order to avoid confusion with singularity Community Edition from sylabs, singularity will be renamed to apptainer, but the them of this article ‘apptainer’ is not fully stable, yet. [https://linuxfoundation.org/press-release/new-linux-foundation-project-accelerates-collaboration-on-container-systems-between-enterprise-and-high-performance-computing-environments/]

This video demonstrates an image with a holographic effect generated on the openSUSE platform with the realsense camera using the Realsense Video Creator for Looking Glass Portrait project. Source codes are available at: https://github.com/cabelo/rscreatelg

In this video we will see how to work with immersion using the oculus quest 2 of the metaverse. The calculation of the transformation of the relative coordinates of the keyboard in the virtual reality environment is demonstrated. We can also see the hand traceability with skeleton detection algorithms among other fantastic features.

On the road to AppStream 1.0, a lot of items from the long todo list have been done so far – only one major feature is remaining, external release descriptions, which is a tricky one to implement and specify. For AppStream 1.0 it needs to be present or be rejected though, as it would be a major change in how release data is handled in AppStream.

Besides 1.0 preparation work, the recent 0.15 release and the releases before it come with their very own large set of changes, that are worth a look and may be interesting for your application to support. But first, for a change that affects the implementation and not the XML format:

1. Completely rewritten caching code

Keeping all AppStream data in memory is expensive, especially if the data is huge (as on Debian and Ubuntu with their large repositories generated from desktop-entry files as well) and if processes using AppStream are long-running. The latter is more and more the case, not only does GNOME Software run in the background, KDE uses AppStream in KRunner and Phosh will use it too for reading form factor information. Therefore, AppStream via libappstream provides an on-disk cache that is memory-mapped, so data is only consuming RAM if we are actually doing anything with it.

Previously, AppStream used an LMDB-based cache in the background, with indices for fulltext search and other common search operations. This was a very fast solution, but also came with limitations, LMDB’s maximum key size of 511 bytes became a problem quite often, adjusting the maximum database size (since it has to be set at opening time) was annoyingly tricky, and building dedicated indices for each search operation was very inflexible. In addition to that, the caching code was changed multiple times in the past to allow system-wide metadata to be cached per-user, as some distributions didn’t (want to) build a system-wide cache and therefore ran into performance issues when XML was parsed repeatedly for generation of a temporary cache. In addition to all that, the cache was designed around the concept of “one cache for data from all sources”, which meant that we had to rebuild it entirely if just a small aspect changed, like a MetaInfo file being added to /usr/share/metainfo, which was very inefficient.

To shorten a long story, the old caching code was rewritten with the new concepts of caches not necessarily being system-wide and caches existing for more fine-grained groups of files in mind. The new caching code uses Richard Hughes’ excellent libxmlb internally for memory-mapped data storage. Unlike LMDB, libxmlb knows about the XML document model, so queries can be much more powerful and we do not need to build indices manually. The library is also already used by GNOME Software and fwupd for parsing of (refined) AppStream metadata, so it works quite well for that usecase. As a result, search queries via libappstream are now a bit slower (very much depends on the query, roughly 20% on average), but can be mmuch more powerful. The caching code is a lot more robust, which should speed up startup time of applications. And in addition to all of that, the AsPool class has gained a flag to allow it to monitor AppStream source data for changes and refresh the cache fully automatically and transparently in the background.

All software written against the previous version of the libappstream library should continue to work with the new caching code, but to make use of some of the new features, software using it may need adjustments. A lot of methods have been deprecated too now.

2. Experimental compose support

Compiling MetaInfo and other metadata into AppStream collection metadata, extracting icons, language information, refining data and caching media is an involved process. The appstream-generator tool does this very well for data from Linux distribution sources, but the tool is also pretty “heavyweight” with lots of knobs to adjust, an underlying database and a complex algorithm for icon extraction. Embedding it into other tools via anything else but its command-line API is also not easy (due to D’s GC initialization, and because it was never written with that feature in mind). Sometimes a simpler tool is all you need, so the libappstream-compose library as well as appstreamcli compose are being developed at the moment. The library contains building blocks for developing a tool like appstream-generator while the cli tool allows to simply extract metadata from any directory tree, which can be used by e.g. Flatpak. For this to work well, a lot of appstream-generator‘s D code is translated into plain C, so the implementation stays identical but the language changes.

Ultimately, the generator tool will use libappstream-compose for any general data refinement, and only implement things necessary to extract data from the archive of distributions. New applications (e.g. for new bundling systems and other purposes) can then use the same building blocks to implement new data generators similar to appstream-generator with ease, sharing much of the code that would be identical between implementations anyway.

2. Supporting user input controls

Want to advertise that your application supports touch input? Keyboard input? Has support for graphics tablets? Gamepads? Sure, nothing is easier than that with the new control relation item and supports relation kind (since 0.12.11 / 0.15.0, details):

<supports>
  <control>pointing</control>
  <control>keyboard</control>
  <control>touch</control>
  <control>tablet</control>
</supports>

3. Defining minimum display size requirements

Some applications are unusable below a certain window size, so you do not want to display them in a software center that is running on a device with a small screen, like a phone. In order to encode this information in a flexible way, AppStream now contains a display_length relation item to require or recommend a minimum (or maximum) display size that the described GUI application can work with. For example:

<requires>
  <display_length compare="ge">360</display_length>
</requires>

This will make the application require a display length greater or equal to 300 logical pixels. A logical pixel (also device independent pixel) is the amount of pixels that the application can draw in one direction. Since screens, especially phone screens but also screens on a desktop, can be rotated, the display_length value will be checked against the longest edge of a display by default (by explicitly specifying the shorter edge, this can be changed).

This feature is available since 0.13.0, details. See also Tobias Bernard’s blog entry on this topic.

4. Tags

This is a feature that was originally requested for the LVFS/fwupd, but one of the great things about AppStream is that we can take very project-specific ideas and generalize them so something comes out of them that is useful for many. The new tags tag allows people to tag components with an arbitrary namespaced string. This can be useful for project-internal organization of applications, as well as to convey certain additional properties to a software center, e.g. an application could mark itself as “featured” in a specific software center only. Metadata generators may also add their own tags to components to improve organization. AppStream gives no recommendations as to how these tags are to be interpreted except for them being a strictly optional feature. So any meaning is something clients and metadata authors need to negotiate. It therefore is a more specialized usecase of the already existing custom tag, and I expect it to be primarily useful within larger organizations that produce a lot of software components that need sorting. For example:

<tags>
  <tag namespace="lvfs">vendor-2021q1</tag>
  <tag namespace="plasma">featured</tag>
</tags>

This feature is available since 0.15.0, details.

5. MetaInfo Creator changes

The MetaInfo Creator (source) tool is a very simple web application that provides you with a form to fill out and will then generate MetaInfo XML to add to your project after you have answered all of its questions. It is an easy way for developers to add the required metadata without having to read the specification or any guides at all.

Recently, I added support for the new control and display_length tags, resolved a few minor issues and also added a button to instantly copy the generated output to clipboard so people can paste it into their project. If you want to create a new MetaInfo file, this tool is the best way to do it!

The creator tool will also not transfer any data out of your webbrowser, it is strictly a client-side application.

And that is about it for the most notable changes in AppStream land! Of course there is a lot more, additional tags for the LVFS and content rating have been added, lots of bugs have been squashed, the documentation has been refined a lot and the library has gained a lot of new API to make building software centers easier. Still, there is a lot to do and quite a few open feature requests too. Onwards to 1.0!