Snapshots of openSUSE Tumbleweed this week had a variety of package updates.

Both Mesa and ImageMagick, were among the packages updated both this week and last week in the rolling release.

The latest snapshot, 20231011, made some significant changes with the gpg2 2.4.3 update. The package installs internal executables in the /usr/libexec directory instead of /usr/lib64. The internal executables include daemon keyboxd, scdaemon, user authenticator gpg-auth, ` gpg-pair-tool` and more. The updated GPG also provides systemd-user files, which were removed upstream since version 2.4.1. The video acceleration package libva 2.20.0 enhances AV1 encoding, refines Direct Rendering Manager array handling to prevent out-of-range issues, and adds support for crop and partial decode JPEG. GNOME’s screen reader Orca, which provides accessibility for graphical applications through speech or Braille, updates to version 45.1. The package corrects a regression in bookmark support and fixes a bug that caused Orca to present custom widgets as images when it shouldn’t. German, Brazilian Portuguese, Indonesian and Catalan languages were updated in a yast2-trans update. Several other packages were also updated in the snapshot.

Snapshot 20231010 updates NetworkManager-applet to version 1.34.0, which include fixes for a crash when importing WireGuard connections and the package streamlines dependencies and translations. A large update for rubygem-rubocop 1.56.3 addresses issues such as false positives and negatives for various cop rules, enhances the accuracy and reliability of rubocop in code analysis. The package also optimizes the performance and functionality of the Ruby code style checker. An update of clipboard manager for the Xfce panel, xfce4-clipman-plugin, updates to version 1.6.5 in the snapshot. The package has changes like hiding certain settings for Wayland, adds D-Bus call support with the set-text action, makes the clipboard manager an interface with both Wayland and X11 implementations and fixes a memory leak. The Hewlett-Packard image and printing package hplip 3.23.8 update includes support for a wide range of new printers that include models like the HP Color LaserJet Pro MFP 4301 series, 4302 series, 4303 series, and various other HP DeskJet printers. A few other RubyGems packages were updated in the snapshot.

The Linux Kernel was updated in snapshot 20231008. The 6.5.6 kernel-source version has fixes related to Network File System error handling, O_DIRECT flag scheduling and locking issues. The Linux Kernel also addresses issues in media drivers, netfs, ext4, netfilter, Advanced Linux Sound Architecture for Embedded Systems and more. An update of NetworkManager 1.44.2 in the snapshot improves IPv4 Address Conflict Detection (ACD) logging. The package addresses issues related to generating connections with the IPv6 method disabled, enhances documentation and now uses explicit release tags. An update llvm17 17.0.2 has changes to maintain Application Programming Interfaces and Application Binary Interface compatibility with with LLVM version 17. The update of nodejs20 20.8.0 improves stream performance and does a rework of memory management in the Virtual Machine APIs as it relates to the importModuleDynamically feature. The package also includes updates to the test_runner, which now accepts testOnly in the run command, The update of LibreOffice 7.6.2.1 addresses document layout issues, image rendering, compatibility, and more. Several other packages were updated in the snapshot including gnome-control-center 45.0+34, which addresses issues such as editing connections without a device and resolves a crash in the firmware security page.

A Common Vulnerability and Exposure was addressed by ImageMagick in snapshot 20231006. The 7.1.1.19 version of the image editor doesn’t provide a description for CVE-2023-5341 other than saying it has moderate severity. The package also eliminates some warnings and compiler issues and addresses issues related to BMP file size checking and XMP profile validation. An update of GNOME Character Map gucharmap 15.1.1 changes to update Unicode version 15.1.0 and adds launchable information to metainfo. The project also removed a defunct mailing list. The essential utilities package shadow updates to version 4.14.1 in the snapshot. This update primarily addresses build system issues to resolve linker problems, particularly noted in Gentoo. Additionally, Alejandro Colomar has been added as a new stable branch maintainer to shadow.keyring. A few Python Package Index updates were made as well as updates to libXrandr and sg3_utils.

The snapshot toward the end of last week that came out just after the blog post update was 20231005. This snapshot brought Mesa 23.2.1, which implements the OpenGL 4.6 and Vulkan 1.3 APIs and brings some new extension features. An update of terminal emulator xterm 385 updates tables based on Unicode 15.1.0 and enhances the configure script. The 3.4.3 icewm version adds a preference for showing window titles in icon-only task buttons, adds support for tabs to switch between open windows and introduces a -f, --fork option for icewmbg to detach it from the terminal. Other software packages were updated in the snapshot including a few Xfce packages and an update libvirt 9.8.0, which enhances its support for network disks by using nbdkit as a backend for network Input/Output.

The October syslog-ng newsletter is now on-line:

• Why contribute to syslog-ng upstream?
• Accelerating single TCP connections in syslog-ng: parallelize()
• Backward compatibility in syslog-ng by using the version number in syslog-ng.conf

It is available at https://www.syslog-ng.com/community/b/blog/posts/the-syslog-ng-insider-2023-10-contribute-parallelize-compatibility

A new version of the modern lightweight host operating system Leap Micro 5.5 is now available. All documents including Release notes from SLE Micro 5.5 documentation space are also applicable for Leap Micro, as Leap Micro is essentially a rebranded SLE Micro.

It’s important to mention that this also means that Leap Micro 5.3 is now End of Life (EOL). Users of Leap Micro 5.3 are strongly advised to consider upgrading to either the Leap Micro 5.4 or 5.5 release. This ensures access to the latest features, security enhancements, and ongoing support.

One of the standout features of Leap Micro 5.5 is its SELinux enhancements. Security-Enhanced Linux (SELinux) has received a significant boost. It brings podman-docker and hyper-v support for AArch64 for a more robust and secure computing experience for users.

Leap Micro 5.5 has podman 4.4 which introduces podman quadlets. If you haven’t tried quadlets yet, please make sure to check our Nextcloud deployment using quadlets. We also ship podman-docker, which is a podman wrapper that can be used together with docker-compose, or at least once the fix for Bug #1215926 is released for SLE and Leap Micro.

Cockpit 298 container management interface noticeably matured, as I’m finally able to use Cockpit to manage all of my home workloads.

Users new to ImmutableOS space (systems with read-only /root) are advised to read transactional update guide. Users can also use Toolbox to install additional software without a need to reboot into a new snapshot, this comes especially handy for debugging where the reboot is not an option.

We’ve made a short YouTube playlist with a few tutorials on how to put Leap Micro to practical use at home.

Hack Week 23 is set to blaze a trail of innovation this November.

This annual tradition started in 2007, this annual tradition, which somehow made up the difference for the number of the event to now, mirrors the year; it brings together SUSE employees, openSUSE contributors and open-source developers and enthusiasts from around the globe together for a week of uninterrupted experimentation and boundary-pushing.

This year’s Hack Week is scheduled from Nov. 6 to 10 and participants are gearing up to harness their collective creativity to innovate, contribute and expand the open-source landscape.

SUSE employees step out of their regular roles to embark on a week-long journey of collaboration, innovation and socialization. This year’s Hack Week promises to be a dynamic convergence of talent, expertise, and passion, as hackers collaborate across teams and continents to push boundaries of technology.

Hack Week is more than just a coding marathon; it’s a testament to SUSE’s commitment to nurturing open-source collaboration across the globe. Participants bring a diverse set of skills, knowledge, passion and perspectives to build and develop something new; this fosters an environment where creative ideas flourish and solutions take shape.

Past Hack Weeks having produced groundbreaking advancements and disruptive innovations. A few to mention are openQA, Aeon (formally known as MicroOS’ GNOME Desktop) and Weblate, which is used by openSUSE for translations.

While the global open-source community eagerly anticipates the commencement of Hack Week 23, individuals are already gearing up by compiling lists of projects they intend to undertake or contribute to.

Stay tuned to SUSE’s official communications channels and social media platforms for updates, announcements, and a front-row seat to the action as Hack Week 23 takes center stage this November.

At the moment I am hard at work putting together the final bits for the AppStream 1.0 release (hopefully to be released this month). The new release comes with many new new features, an improved developer API and removal of most deprecated things (so it carefully breaks compatibility with very old data and the previous C API). One of the tasks for the upcoming 1.0 release was #481 asking about a formal way to distinguish Linux phone applications from desktop applications.

AppStream infamously does not support any “is-for-phone” label for software components, instead the decision whether something is compatible with a device is based the the device’s capabilities and the component’s requirements. This allows for truly adaptive applications to describe their requirements correctly, and does not lock us into “form factors” going into the future, as there are many and the feature range between a phone, a tablet and a tiny laptop is quite fluid.

Of course the “match to current device capabilities” check does not work if you are a website ranking phone compatibility. It also does not really work if you are a developer and want to know which devices your component / application will actually be considered compatible with. One goal for AppStream 1.0 is to have its library provide more complete building blocks to software centers. Instead of just a “here’s the data, interpret it according to the specification” API, libappstream now interprets the specification for the application and provides API to handle most common operations – like checking device compatibility. For developers, AppStream also now implements a few “virtual chassis configurations”, to roughly gauge which configurations a component may be compatible with.

To test the new code, I ran it against the large Debian and Flatpak repositories to check which applications are considered compatible with what chassis/device type already. The result was fairly disastrous, with many applications not specifying compatibility correctly (many do, but it’s by far not the norm!). Which brings me to the actual topic of this blog post: Very few seem to really know how to mark an application compatible with certain screen sizes and inputs! This is most certainly a matter of incomplete guides and good templates, so maybe this post can help with that a bit:

The ultimate cheat-sheet to mark your app “chassis-type” compatible

As a quick reminder, compatibility is indicated using AppStream’s relations system: A requires relation indicates that the system will not run at all or will run terribly if the requirement is not met. If the requirement is not met, it should not be installable on a system. A recommends relation means that it would be advantageous to have the recommended items, but it’s not essential to run the application (it may run with a degraded experience without the recommended things though). And a supports relation means a given interface/device/control/etc. is supported by this application, but the application may work completely fine without it.

I have a desktop-only application

A desktop-only application is characterized by needing a larger screen to fit the application, and requiring a physical keyboard and accurate mouse input. This type is assumed by default if no capabilities are set for an application, but it’s better to be explicit. This is the metadata you need:

<component type="desktop-application">
  <id>org.example.desktopapp</id>
  <name>DesktopApp</name>
  [...]
  <requires>
    <display_length>768</display_length>

    <control>keyboard</control>
    <control>pointing</control>
  </requires>
  [...]
</component>

With this requires relation, you require a small-desktop sized screen (at least 768 device-independent pixels (dp) on its smallest edge) and require a keyboard and mouse to be present / connectable. Of course, if your application needs more minimum space, adjust the requirement accordingly. Note that if the requirement is not met, your application may not be offered for installation.

Note: Device-independent / logical pixels

One logical pixel (= device independent pixel) roughly corresponds to the visual angle of one pixel on a device with a pixel density of 96 dpi (for historical X11 reasons) and a distance from the observer of about 52 cm, making the physical pixel about 0.26 mm in size. When using logical pixels as unit, they might not always map to exact physical lengths as their exact size is defined by the device providing the display. They do however accurately depict the maximum amount of pixels that can be drawn in the depicted direction on the device’s display space. AppStream always uses logical pixels when measuring lengths in pixels.

I have an application that works on mobile and on desktop / an adaptive app

Adaptive applications have fewer hard requirements, but a wide range of support for controls and screen sizes. For example, they support touch input, unlike desktop apps. An example MetaInfo snippet for these kind of apps may look like this:

<component type="desktop-application">
  <id>org.example.adaptive_app</id>
  <name>AdaptiveApp</name>
  [...]

  <requires>
    <display_length>360</display_length>
  </requires>

  <supports>
    <control>keyboard</control>
    <control>pointing</control>
    <control>touch</control>
  </supports>
  [...]
</component>

Unlike the pure desktop application, this adaptive application requires a much smaller lowest display edge length, and also supports touch input, in addition to keyboard and mouse/touchpad precision input.

I have a pure phone/table app

Making an application a pure phone application is tricky: We need to mark it as compatible with phones only, while not completely preventing its installation on non-phone devices (even though its UI is horrible, you may want to test the app, and software centers may allow its installation when requested explicitly even if they don’t show it by default). This is how to achieve that result:

<component type="desktop-application">
  <id>org.example.phoneapp</id>
  <name>PhoneApp</name>
  [...]

  <requires>
    <display_length>360</display_length>
  </requires>

  <recommends>
    <display_length compare="lt">1280</display_length>
    <control>touch</control>
  </recommends>
  [...]
</component>

We require a phone-sized display minimum edge size (adjust to a value that is fit for your app!), but then also recommend the screen to have a smaller edge size than a larger tablet/laptop, while also recommending touch input and not listing any support for keyboard and mouse.

Please note that this blog post is of course not a comprehensive guide, so if you want to dive deeper into what you can do with requires/recommends/suggests/supports, you may want to have a look at the relations tags described in the AppStream specification.

Validation

It is still easy to make mistakes with the system requirements metadata, which is why AppStream 1.0 will provide more commands to check MetaInfo files for system compatibility. Current pre-1.0 AppStream versions already have an is-satisfied command to check if the application is compatible with the currently running operating system:

:~$ appstreamcli is-satisfied ./org.example.adaptive_app.metainfo.xml
Relation check for: */*/*/org.example.adaptive_app/*

Requirements:
 • Unable to check display size: Can not read information without GUI toolkit access.
Recommendations:
 • No recommended items are set for this software.
Supported:
 ✔ Physical keyboard found.
 ✔ Pointing device (e.g. a mouse or touchpad) found.
 • This software supports touch input.

In addition to this command, AppStream 1.0 will introduce a new one as well: check-syscompat. This command will check the component against libappstream’s mock system configurations that define a “most common” (whatever that is at the time) configuration for a respective chassis type.

If you pass the --details flag, you can even get an explanation why the component was considered or not considered for a specific chassis type:

:~$ appstreamcli check-syscompat --details ./org.example.phoneapp.metainfo.xml
Chassis compatibility check for: */*/*/org.example.phoneapp/*

Desktop:
 ✘ Incompatible
 • recommends: This software recommends a display with its shortest edge
   being << 1280 px in size, but the display of this device has 1280 px.
 • recommends: This software recommends a touch input device.

Laptop:
 ✘ Incompatible
 • recommends: This software recommends a display with its shortest edge 
   being << 1280 px in size, but the display of this device has 1280 px.
 • recommends: This software recommends a touch input device.

Server:
 ✘ Incompatible
 • requires: This software needs a display for graphical content.
 • recommends: This software needs a display for graphical content.
 • recommends: This software recommends a touch input device.

Tablet:
 ✔ Compatible (100%)

Handset:
 ✔ Compatible (100%)

I hope this is helpful for people. Happy metadata writing! 😀

Dear Tumbleweed users and hackers,

My punishment for taking Fridays off is having to write a weekly review that spans again over two weeks. I know, many of you rely on those reviews to know what is coming their way and doing this only bi-weekly is definitively now what I am striving for. After all, you deserve to be informed about the things happening in Tumbleweed. During the last two weeks, we have published 9 snapshots (0921, 0922, 0925, 0926, 0927, 0929, 1001, 1003, and 1005 – with the latest one being still being hot – and important in plus.

The most relevant changes in these snapshots are:

• Linux kernel 6.5.4
• Poppler 23.09.0
• dbus 1.14.10
• Node.JS 20.7.0
• XWayland 23.2.1
• UDisks 2.10.0
• LibreOffice 7.6.1.2
• Mesa 23.1.8, 23.2.0, and 23.2.1
• GPG 2.4.0
• Mozilla Firefox 118.0.1
• GStreamer 1.22.6
• openSSL 3.1.3
• systemd 254.5
• glibc CVE-2023-4911, aka Looney Tunables
• Samba 4.19.0

The glibc fix is part of Snapshot 1005, but due to its importance and reach was already published in the Tumbleweed update channel yesterday evening.

The staging projects are currently testing these changes:

• binutils 2.41
• Linux kernel 6.5.6
• Shadow 4.14.1
• zypper 1.14.65 / libzypp 17.31.21: changes around transfiletrigger handlers; openQA seems not yet happy with the result
• LibreOffice 7.6.2