Dear Tumbleweed users and hackers,

Welcome back to our weekly review, where we dissect the latest snapshots to see what’s new in the openSUSE rolling release. This week has been incredibly busy, with a massive influx of updates touching nearly every part of the system, from the desktop environment and core libraries to the installer itself. Let’s get right into the details of what rolled out this week.

We published 5 snapshots (0815, 0816, 01817, 0818, and 0820) containing these changes:

• KDE Gear 25.08.0
• Linux kernel 6.16.1
• Postgresql 17.6
• SQLite 3.50.4
• Virtualbox 7.2.0
• glibc 2.42
• git 2.51.0
• hplip 3.25.6
• Introduction of opensuse-welcome-launcher: a shell script that will allow us to show different ‘welcome apps’ per desktop. The future will go towards e.g. GNOME Tour on a GNOME Desktop.

The following things are currently being tested and will reach you when things are worked out:

• Python 3.13.7
• nftables 1.1.4: earlier detected issues could be solved
• Rust 1.89
• Mesa 25.2: Xvfb crashes on 32bit systems (https://bugzilla.opensuse.org/show_bug.cgi?id=1247995)
• GNU Gettext 0.26
• Linux kernel 6.16.2
• VLC moving to ffmpeg-7 by backporting a patchset from upstream

The familiar openSUSE-welcome window that greets millions of desktops is nearing retirement and a new approach will soon take its place.

Rather than re-inventing the wheel, members of openSUSE’s release team have decided to tweak and refine existing solutions like gnome-tour for GNOME and plasma-welcome for KDE’s Plasma by making a new controller and opensuse-welcome-launcher to coordinate them and provide desktop-specific content.

This new welcome-launcher manages which greeter to run depending on the desktop environment. This gives openSUSE’s release team more control over when and how welcome screens are shown, instead of relying on each greeter’s own autostart mechanism.

The launcher isn’t limited to the first boot. It can display greeters after major system updates so users learn about new features, enhancements, and changes in a timely way.

The enrollment of this new greeter will be done in multiple phases.

1) The launcher will initially call the well known legacy openSUSE-welcome. The only difference is that it loses the checkbox show on next boot, as it’s no longer in charge of autostart.

2) The launcher triggers openSUSE branded gnome-tour and plasma-welcome while keeping openSUSE-welcome as a fallback (in case it’s installed).

3) The legacy Qt5-based greeter will eventually be decommissioned. We should have an agreed fallback on desktop sessions without dedicated greeter.

The phased approach allows integration with openQA testing and provides flexibility for future improvements.

Since opensuse-welcome-launcher is considered a legacy and is one of the last Qt5-dependent applications, the move will help phase out some remaining Qt5 components across the distribution.

Dear Tumbleweed users and hackers,

Week 33 went without major hiccups for Tumbleweed snapshot building and testing, and so it happens that we released once again 8 Snapshots in a week (0807…0814).

The changes are numerous, most interestingly:

• Mozilla Firefox 141.0.2
• KDE Plasma 6.4.4 & KDE Frameworks 6.17.0
• python cryptography 45.0.5
• Postfix 3.10.3
• openSSL 3.5.2
• gnu gettext 0.25.1
• NetworkManager 1.52.1
• GTK 3.24.50
• Linux kernel 6.16.0
• GStreamer 1.26.5
• PHP 8.4.11
• qemu 10.0.3
• Bash 5.3.3
• Readline 8.3.1
• python PIP 25.2
• python pytest 8.4.1

A few things are still in the staging areas – either submitted recently or having issues passing QA; most interestingly, we have these changes lined up:

• KDE Gear 25.08.0
• Linux kernel 6.16.1
• Rust 1.89: build fix for 389-ds pending
• glibc 2.42: yast2/text mode installation looks ‘broken’ (missing blue background)
• Mesa 25.2: Xvfb crashes on 32bit systems (https://bugzilla.opensuse.org/show_bug.cgi?id=1247995)
• Python 3.13.7: build fix for qemu pending
• nftables 1.1.4: issues detected by openQA in combination with netavark
• openSUSE-welcome: prepare infra to have different ‘welcome apps’ per desktop (e.g gnome-tour on gnome)

The openSUSE.Asia Summit Organizing Committee has extended the deadline for the Call for Host to submit proposals for the 2026 Summit. Communities now have until August 27, 2025 to apply.

The extension comes in response to requests from local communities seeking more time to prepare their proposals. This is a great opportunity to showcase your region and bring the openSUSE community together in your city.

The selected proposals will be presented during openSUSE.Asia Summit 2025 in Faridabad from August 29–30. Proposals can be presented online if on-site participation is not possible.

For more information, visit: https://news.opensuse.org/2025/06/10/osas-cfh/

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

• Deprecating Java-based drivers from syslog-ng: Is HDFS next?

• Your first steps configuring syslog-ng

• Prometheus exporter in syslog-ng

It is available at https://www.syslog-ng.com/community/b/blog/posts/the-syslog-ng-insider-2025-08-hdfs-configuration-prometheus

Dear Tumbleweed users and hackers,

Because August 1st is Switzerland’s national holiday, I took the day off last Friday — which is my excuse for skipping last week’s review. The most noteworthy technical change was mostly invisible: we switched FTP tree generation from product-builder to product-composer. This is essentially a rewrite, trimming years of accumulated features back to a more manageable set. One side effect is that product descriptions are now in YAML instead of XML — easier on the eyes.

The published FTP tree looks largely unchanged, aside from a brief bug where appstream metadata wasn’t registered, causing software centers like Discover and GNOME Software to miss it (now fixed). The main visible change affects ARM users: we merged the FTP trees for armv6, armv7, and aarch64 into a single tree under the ports/aarch64 namespace. This saves several gigabytes on our mirrors by sharing large noarch packages.

Since this results in bigger repodata containing all architectures, the new product composer supports “split repodata for merged trees” — also used in Leap 16.0. ARM users who prefer smaller metadata can append /$basearch to the end of their OSS repo URL, and zypp will then only refresh the relevant subset.

Other than that rather technical-only change, we of course also published nine snapshots (0725, 0727, 0728, 0730, 0801, 0803, 0804, 0805, and 0806) for your updating fun, containing these changes:

• Apache 2.4.65
• pipewire 1.4.7
• Mozilla Firefox 141.0
• GStreamer 1.26.4
• Linux kernel 6.15.8
• mozilla-nss 3.113
• mozjs 128.13.0 (javascript engine used by e.g GNOME)
• Virtualbox 7.1.12a
• nvme-cli 2.15 (if you have scripts using the short parameter –output, you will need to change that to –output-format)
• Mesa 25.1.7
• libvirt 11.6.0
• GCC 15.2 RC
• gnutls 3.8.10
• container-selinux 2.240.0: containers no longer have the implicit right to change SELinux labels. If you require this, you will need to enable the new boolean container_modify_selinux_labels
• gnome-shell 48.4

The next changes being prepared and tested currently are:

• Mozilla Firefox 141.0.2
• KDE Plasma 6.4.4
• Linux kernel 6.16.0
• openSSL 3.5.2
• Mesa 25.2
• python pytest 8.4.1
• glibc 2.42
• openSUSE-welcome: prepare infra to have different ‘welcome apps’ per desktop (e.g gnome-tour on gnome)
• GNU gettext 0.25.1
• nftables 1.1.4: issues detected by openQA in combination with netavark
• Bash 5.3

I’m happy to announce the release of Himmelblau 1.0, which now supports Intune MDM policy enforcement on Linux. This is a major milestone for the project—and honestly, for the broader Linux community—because it means we finally have a working, transparent, and open-source alternative to Microsoft’s half-baked Intune client for Linux.

Let’s talk about what’s new, why it matters, and how to enable it.

Intune Policy Enforcement – Now Built In

With 1.0, Himmelblau can fetch and enforce device compliance policies from Microsoft Intune. This includes things like:

• Password requirements (applied to the Linux Hello PIN, FYI)
• Disk encryption requirements
• OS version requirements
• Script policies

Policies are enforced at login time, and any non-compliant device will be reported as such during Intune check-in. This works out of the box, with no browser hacks, GUI prompts, or extra fluff. In Himmelblau, it’s all seamless to the user.

To enable policy enforcement, just add the following to your config:

# /etc/himmelblau/himmelblau.conf
apply_policy = true

Then restart the service and watch your login enforcement and compliance status just work.

Why Microsoft’s Intune Client Just Doesn’t Cut It

Let’s be blunt for a moment: Microsoft’s official Intune for Linux client is a mess.

Here’s why:

• It’s unreliable. In my testing, it usually doesn’t work. You’ll find guides online suggesting you install Edge first, or tweak your environment in weird ways just to get the thing to launch. That’s ridiculous. A tool that claims to support Linux shouldn’t require browser voodoo to function.
• It frequently crashes. Again, this is based on my own experience. The client crashes. A lot. That’s not enterprise-grade—it’s barely alpha.
• It’s hardwired to Ubuntu and RHEL. Microsoft only builds packages for those two distros. Himmelblau supports many more: Ubuntu, Debian, openSUSE, Fedora, Rocky, RHEL, SLE, Oracle, NixOS (yes seriously, even NixOS)—and I’m happy to work with the community to expand that list. Just ask, we’ll add it.
• Policy enforcement is GUI-dependent. You can’t enforce policy without logging into the desktop session. This is so broken I don’t even know where to begin. What about headless servers? SSH? Seriously?
• It’s a bizarre mix of Rust and Java. I like Rust, but what were they thinking intermingling it with Java?
• It requires Microsoft Edge. Because of course it does. Classic Microsoft move: shove their browser into every workflow, whether it belongs there or not.
• It’s bound to a local account. That’s not cloud integration, it’s cloud side-loading.
• It’s closed source. If we can’t inspect the code and see how it works, how can they expect us to trust this thing?
• They clearly don’t understand Linux. That’s the bottom line. This is not a tool made by people who know how Linux is used in the real world. It’s a checkbox product.

Himmelblau exists because we can—and should—do better.

Important: No Custom Compliance Policies Yet

Microsoft offers a feature in Intune called Linux Custom Compliance policies. These allow you to define your own compliance scripts that Intune will evaluate on managed Linux devices.

Himmelblau does not support these (yet). So please, do not assign Linux Custom Compliance policies to devices managed by Himmelblau. If you do, they’ll be marked as non-compliant, and Himmelblau will prevent users from logging in.

This feature is in progress and will land in a future version. Until then, stick to the regular Intune compliance settings—those are supported.

This Changes Everything for Linux in the Enterprise

With Himmelblau 1.0, we finally have:

• A reliable Intune-compatible agent
• Real enforcement of Microsoft’s compliance rules
• No GUI dependency
• Support for many Linux distros
• Open code, real transparency, and community-driven development

You no longer have to settle for Microsoft’s broken Linux client. You don’t have to pretend it’s “fine” just because it has the Microsoft logo on it.

Now there’s a better option—one by the community, for the community.

Entering RC Phase

openSUSE Leap 16.0 has officially transitioned from Beta into the Release Candidate phase with the Build 148.4.

The biggest challenge for the Release Team prior to Autumn release is source code management, as we want to transition both Tumbleweed and Leap 16.0 from legacy OBS SCM to Git.
This will also require a new maintenance model for Leap.

Users can expect a few more builds before we announce our Gold Master candidate.
Given the nature of Leap 16 being built on top of binaries from SUSE Linux Enterprise 16, we can only do so once SUSE Linux Enterprise 16.0 announces their Gold Master in late September.

If all goes well with the maintenance setup we could aim for the delivery according to the roadmap in October shortly before SLES 16.0.

More details can be found in the roadmap and newly also in calendar.opensuse.org.

New installer

Leap 16.0 is using the latest Agama for both online and offline installation aside. You can get install images at get.opensuse.org. Alternatively, users can pick one of our appliance images.

Being among the first to deliver Xfce on Wayland

We offer only Wayland-based Desktop Environments in the installer. Xfce on Wayland has recently joined the list.
Thanks to the openSUSE Xfce team, we’re among the first to deliver it as an experimental preview to users.
The Xfce mailing list was quite active as we were getting closer to RC.

Users can enjoy the minimalistic Wayland-friendly greetd and gtkgreet as a replacement for LightDM.

Get the Leap 16.0 install image and try it out!

Please be aware that the Wayland support in Xfce is experimental and there are plenty of issues.
We could use help in improving our patterns and making the experience with Wayland-ready apps on Xfce more complete.
Join the Xfce mailing list if you’re interested in the effort.

YaST stack reduction

A clean install of Leap 16.0 comes with no YaST packages installed.
Users can use the new package Myrlyn, which is a drop-in replacement for legacy YaST Software Management, which provided a bit more than just a nice UI frontend to Zypper.
Some limited set of YaST packages will still be around as Agama depends on them, therefore they won’t be dropped on migration.
The long-term goal is to go in favor of Cockpit.

SELinux is the new default

All new installations will use SELinux by default.
Users can switch to AppArmor post installation.

Steam, Wine, 32-bit support

SUSE Linux Enterprise 16.0 does not support 32-bit binary execution.
Leap users can install grub2-compat-ia32, which enables it by passing ia32_emulation=1 to the kernel.
We’ve recently dropped Steam from the Non-OSS repository due to a limited set of 32-bit libraries.
Steam users will want to install selinux-policy-targeted-gaming, which is not installed by default.

New Repository structure and parallel downloads in zypper

The biggest changes for users migrating from 15.6 will likely be the absence of dedicated update repositories for SLES packages.
Leap 16.0 essentially uses just a single repository repo-oss that contains both community and SLES packages and their respective updates.
We now use separate repodata per architecture, as well as parallel downloads in Zypper for a more “snap” user experience.

Migration

I personally advise Leap 15.6 users migrating to 16.0 to look into the new opensuse-migration-tool.
The tool has some useful optional post-migration scripts such as 32-bit binary enablement, migration from PulseAudio to PipeWire, and AppArmor/SELinux selection.

sudo zypper in opensuse-migration-tool
opensuse-migration-tool --dry-run # optionally check how it looks
sudo opensuse-migration-tool

Users migrating manually will want to drop all update repositories and keep only oss/non-oss repos prior to running zypper --releasever 16.0 dup.
Details are at our System upgrade wiki page.

Revamped release notes

A preview of our new modular release-notes can be found here.
We were able to reduce the build/publish infrastructure for Release Notes to basically just GitHub, as the installer no longer requires an RPM with a local copy of release notes.

Submitting Bug Reports

Your feedback is critical at this stage.

We know that people really start testing new release with RC. Please report any issues on bugzilla.opensuse.org. Please make sure to check Known bugs wiki page prior reporting a new bug.

Thank you for testing and being part of the openSUSE community. Let’s shape Leap 16.0 together!