Dear Tumbleweed users and hackers,

This week, we have seen only a single snapshot (1127) published, which landed just before the start of HackWeek.

Since then, a few issues have piled up, blocking further releases. First, the update to ICU 78 caused libqt5-qtwebengine the build to fail. Because this package is present on nearly 100% of systems (specifically those installed before the new opensuse-welcome), we could not consider releasing it in that state.

We also encountered significant friction with systemd 258, which triggered several complex issues in openQA. While we have set that update aside for deep diagnostics, we decided to revert to the already shipped version for the immediate future. This specific move should unblock Tumbleweed and get the snapshots rolling again.

Naturally, HackWeek 25 has also played a role here. With many contributors focusing on side projects, resources for regular maintenance have been kept to a minimum.

Snapshot 1127 contained these changes:

• GDM 49.2
• libproxy 0.5.12
• XOrg server 21.1.21

The future will bring you these changes sooner or later:

• Mozilla Firefox 145.0.2
• Bash 5.3.8
• Linux kernel 6.18.0
• PostgreSQL 18.1
• SQLite 3.51.1
• Mesa 25.3.1
• Ruby 4.0 (early preview staged to find out what all breaks)

As part of HackWeek, Santiago has tirelessly improved the test coverage for “Tumbleweed installed using Agama.” We plan to expand this further and minimize the gap between the legacy installer and Agama, with a priority on NET installations.

The Idea

My original idea was to study how to RAG (Retrieval-Augmented Generation) an LLM model by inserting something potentially useful to it.

I chose qwen3-coder as my language model, and qwen3-embedding as my embedding model, both easily available via Ollama.

My current work laptop is not powerful enough for any of this work, so I used my personal desktop computer for the testing, with AMD’s ROCm containers.

In Practice

The LLM vibes brought me to learn a couple of things. First of all, after searching for a couple of alternatives, I found a simple MIT licensed ragging demo to start experimenting with. I changed it to use my local, already downloaded models and cut off the network access to my container. Since I’m pulling all kinds of dependencies from the Internet, I like to both use a container in the first place and also not have the container access network to make sure it’s both safe and provably functional without network.

I realized that I can also experiment with the local Ollama qwen3-coder for the coding part of the RAG at the same time, and used its help to implement a couple of new features - I stored the accumulated vector database into a file, added chat functionality instead of one query, support for “compressing” the history to fit within context window, and even some tests. I found this experience initially quite good, since I didn’t have previous experience on this topic it really helped me with the examples. The problem is mostly the amount of code it generates that needs to be reviewed if it makes any sense or not, but all in all I couldn’t have achieved the same in the same time, because reading documentation and trial and error would have taken more time. Arguably the technical debt is something that offsets any time savings, but for this kind of experimental study purposes, doing something someone else has already done before, it worked well to get quick results.

My 400kB amount of scripts led to a vector database of 440MB in size 🤔 It’ll be interesting how it will be for example if I put 10x of data in, will the database keep on increasing in size in proportion to that?

How’s the actual usage? Well, it does retrieve correctly my knowledge from my own scripts, but OTOH I’m not sure if I’m able to find (old, forgotten) things with this any faster than with grep. I’ll try to integrate this however to my usage so that at some point this is another query feature similar to grep. For that though, I need to accumulate more data to feed to it.

I also added a web interface so that within home network I can query it from a browser.

I Need Moooore AI

I was also looking at moving to ChromaDB for the vector storage. I thought to try OpenCode at the same time, still paired with the qwen3-coder. Oh what an agentic mess it became! It started configuring my already-configured git with its own user name, fetching all kinds of stuff, and committing bloated things that were clearly broken. But, it did all that locally, which is kind of neat.

Some of the end result can be seen at my testing git repo.

At the End

It has been an interesting experiment with ups and downs of LLM usage. I’ve learned things fast at first, but then I’ve already grown hating the need to practice the “art” of prompting and getting to the “maybe next prompt will fix it” phase of developing things.

The Goal

The goal was to extract all issues from a Redmine instance, anonymize the data, and build a local RAG system for semantic search and Q&A.

Just like with the previous experiment with Bugzilla it started with data extraction. I planned to make a simple bulk download via Redmine API. Then came the first problem. Redmine’s API doesn’t return journal entries (comments) when using the project-level endpoint, even with the include=journals parameter. I tried out different ways but nothing worked. The solution was, after all, to change the strategy and fetch each issue individually via /issues/{id}.json. This was much slower but guaranteed complete data including all comments.

It all started last summer

When my family moved to a new place. In our previous home we had a district heating service that included unlimited hot water for a fixed price. That was awesome - not very environmentally friendly and actually not very cheap, but we never ran out of hot water.

In our new home we are independent from the city’s hot water services. This is good because we pay exactly for the energy we use. It means that we have a 300-liter hot water heater that we turn on when we want to make as much hot water as we need. In most households such a hot water boiler has a thermostat set to a specific temperature and the heater keeps all 300 liters of water as hot as it is set. I do not like this, because regardless of how great the insulation on the water tank is, it loses temperature over time. I needed a smarter system.

A long-waited feature for syslog-ng, the Kafka source, is getting ready soon. The development is still in progress, but you can already try it, and it is worth the effort. How? Using the very same tool the syslog-ng testing and release process relies on.

From this blog you can learn how to download and patch syslog-ng git sources and build packages for popular RPM and DEB Linux distributions. Once you have installable packages, comes the fun part: getting the Kafka source working.

Read the rest at https://www.syslog-ng.com/community/b/blog/posts/how-to-test-the-syslog-ng-kafka-source-by-building-the-package-yourself

As the founder of the openSUSE Innovator initiative, and a member of the openSUSE and Intel Innovator communities, I maintain my ongoing commitment to bringing cutting-edge technologies to the different flavors of the openSUSE Linux distribution.

With the arrival of NPU (Neural Processing Unit) devices, it has become possible to run LLMs and generative AI applications without relying on a dedicated GPU. In light of this advancement, we began the work of packaging the Intel NPU Driver into RPM for the openSUSE ecosystem. As a result of this collective effort, the openSUSE for Innovators initiative is proud to announce the official availability of this package to the community.

The Intel NPU is an inference accelerator integrated into Intel CPUs starting with the Intel® Core™ Ultra family (formerly known as Meteor Lake). It enables efficient and low-power execution of artificial neural network workloads directly on the processor.

The NPU is integrated into the processor die, designed to perform matrix operations of neural networks with high energy efficiency. Its architecture complements CPU and GPU, enabling intelligent offloading for ONNX models, computer vision pipelines, quantized models, and hybrid model operations with simultaneous use of CPU+GPU+NPU.

Participating in this project is a source of great satisfaction, as we know it will have a significant impact on future applications. As members of an open-source community, we have a responsibility to democratize emerging technologies and help reduce the digital divide, and this delivery is another important step in that direction.

For more information, go to software.opensuse.org!

I was reading a blog post about the testing strategy for the Wild linker, when I came upon a link to cargo-mutants, a mutation testing tool for Rust. The tool promised to be easy to set up, so I gave it a try. I'm happy to find that it totally delivers!

Briefly: mutation testing catches cases where bugs are deliberately inserted in the source code, but the test suite fails to catch them: after making the incorrect changes, all the tests still pass. This indicates a gap in the test suite.

Previously I had only seen mentions of "mutation testing" in passing, as something exotic to be done when testing compilers. I don't recall seeing it as a general tool; maybe I have not been looking closely enough.

Setup and running

Setting up cargo-mutants is easy enough: you can cargo install cargo-mutants and run it with cargo mutants.

For librsvg this ran for a few hours, but I discovered a couple of things related to the way the librsvg repository is structured. The repo is a cargo workspace with multiple crates: the librsvg implementation and public Rust API, the rsvg-convert binary, and some utilities like rsvg-bench.

1. By default cargo-mutants only seemed to pick up the tests for rsvg-convert. I think it may have done this because it is the only binary in the workspace that has a test suite (e.g. rsvg-bench does not have a test suite).

2. I had to run cargo mutants --package librsvg to tell it to consider the test suite for the librsvg crate, which is the main library. I think I could have used cargo mutants --workspace to make it run all the things; maybe I'll try that next time.

Initial results

My initial run on rsvg-covert produced useful results; cargo-mutants found 32 mutations in the rsvg-convert source code that ought to have caused failures, but the test suite didn't catch them.

The second run, on the librsvg crate, took about 10 hours. It is fascinating to watch it run. In the end it found 889 mutations with bugs that the test suite couldn't catch:

5243 mutants tested in 9h 53m 15s: 889 missed, 3663 caught, 674 unviable, 17 timeouts

What does that mean?

• 5243 mutants tested: how many modifications were tried on the code.

• 889 missed: The important ones: after a modification was made, the test suite failed to catch this modification.

• 3663 caught: Good! The test suite caught these!

• 674 unviable: These modifications didn't compile. Nothing to do.

• 17 timeouts: Worth investigating; maybe a function can be marked to be skipped for mutation.

Starting to analyze the results

Due to the way cargo-mutants works, the "missed" results come in an arbitrary order, spread among all the source files:

rsvg/src/path_parser.rs:857:9: replace <impl fmt::Display for ParseError>::fmt -> fmt::Result with Ok(Default::default())
rsvg/src/drawing_ctx.rs:732:33: replace > with == in DrawingCtx::check_layer_nesting_depth
rsvg/src/filters/lighting.rs:931:16: replace / with * in Normal::bottom_left
rsvg/src/test_utils/compare_surfaces.rs:24:9: replace <impl fmt::Display for BufferDiff>::fmt -> fmt::Result with Ok(Default::default())
rsvg/src/filters/turbulence.rs:133:22: replace - with / in setup_seed
rsvg/src/document.rs:627:24: replace match guard is_mime_type(x, "image", "svg+xml") with false in ResourceType::from
rsvg/src/length.rs:472:57: replace * with + in CssLength<N, V>::to_points

So, I started by sorting the missed.txt file from the results. This is much better:

rsvg/src/accept_language.rs:136:9: replace AcceptLanguage::any_matches -> bool with false
rsvg/src/accept_language.rs:136:9: replace AcceptLanguage::any_matches -> bool with true
rsvg/src/accept_language.rs:78:9: replace <impl fmt::Display for AcceptLanguageError>::fmt -> fmt::Result with Ok(Default::default())
rsvg/src/angle.rs:40:22: replace < with <= in Angle::bisect
rsvg/src/angle.rs:41:56: replace - with + in Angle::bisect
rsvg/src/angle.rs:49:35: replace + with - in Angle::flip
rsvg/src/angle.rs:57:23: replace < with <= in Angle::normalize

With the sorted results, I can clearly see how cargo-mutants gradually does its modifications on (say) all the arithmetic and logic operators to try to find changes that would not be caught by the test suite.

Look at the first two lines from above, the ones that refer to AcceptLanguage::any_matches:

rsvg/src/accept_language.rs:136:9: replace AcceptLanguage::any_matches -> bool with false
rsvg/src/accept_language.rs:136:9: replace AcceptLanguage::any_matches -> bool with true

Now look at the corresponding lines in the source:

... impl AcceptLanguage {
135     fn any_matches(&self, tag: &LanguageTag) -> bool {
136         self.iter().any(|(self_tag, _weight)| tag.matches(self_tag))
137     }
... }
}

The two lines from missed.txt mean that if the body of this any_matches() function were replaced with just true or false, instead of its actual work, there would be no failed tests:

135     fn any_matches(&self, tag: &LanguageTag) -> bool {
136         false // or true, either version wouldn't affect the tests
137     }
}

This is bad! It indicates that the test suite does not check that this function, or the surrounding code, is working correctly. And yet, the test coverage report for those lines shows that they are indeed getting executed by the test suite. What is going on?

I think this is what is happening:

• The librsvg crate's tests do not have tests for AcceptLanguage::any_matches.
• The rsvg_convert crate's integration tests do have a test for its --accept-language option, and that is what causes this code to get executed and shown as covered in the coverage report.
• This run of cargo-mutants was just for the librsvg crate, not for the integrated librsvg plus rsvg_convert.

Getting a bit pedantic with the purpose of tests, rsvg-convert assumes that the underlying librsvg library works correctly. The library advertises support in its API for matching based on AcceptLanguage, even though it doesn't test it internally.

On the other hand, rsvg-convert has a test for its own --accept-language option, in the sense of "did we implement this command-line option correctly", not in the sense of "does librsvg implement the AcceptLanguage functionality correctly".

After adding a little unit test for AcceptLanguage::any_matches in the librsvg crate, we can run cargo-mutants just for that the accept_language.rs file again:

# cargo mutants --package librsvg --file accept_language.rs
Found 37 mutants to test
ok       Unmutated baseline in 24.9s build + 6.1s test
 INFO Auto-set test timeout to 31s
MISSED   rsvg/src/accept_language.rs:78:9: replace <impl fmt::Display for AcceptLanguageError>::fmt -> fmt::Result with Ok(Default::default()) in 4.8s build + 6.5s test
37 mutants tested in 2m 59s: 1 missed, 26 caught, 10 unviable

Great! As expected, we just have 1 missed mutant on that file now. Let's look into it.

The function in question is now <impl fmt::Display for AcceptLanguageError>::fmt, an error formatter for the AcceptLanguageError type:

impl fmt::Display for AcceptLanguageError {
    fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result {
        match self {
            Self::NoElements => write!(f, "no language tags in list"),
            Self::InvalidCharacters => write!(f, "invalid characters in language list"),
            Self::InvalidLanguageTag(e) => write!(f, "invalid language tag: {e}"),
            Self::InvalidWeight => write!(f, "invalid q= weight"),
        }
    }
}

What cargo-mutants means by "replace ... -> fmt::Result with Ok(Default::default()) is that if this function were modified to just be like this:

impl fmt::Display for AcceptLanguageError {
    fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result {
        Ok(Default::default())
    }
}

then no tests would catch that. Now, this is just a formatter function; the fmt::Result it returns is just whether the underlying call to write!() succeeded. When cargo-mutants discovers that it can change this function to return Ok(Default::default()) it is because fmt::Result is defined as Result<(), fmt::Error>, which implements Default because the unit type () implements Default.

In librsvg, those AcceptLanguageError errors are just surfaced as strings for rsvg-convert, so that if you give it a command-line argument with an invalid value like --accept-language=foo, it will print the appropriate error. However, rsvg-convert does not make any promises as to the content of error messages, so I think it is acceptable to not test this error formatter — just to make sure it handles all the cases, which is already guaranteed by its match statement. Rationale:

• There already are tests to ensure that the error codes are computed correctly in the parser for AcceptLanguage; those are the AcceptLanguageError's enumeration variants.

• There is a test in rsvg-convert's test suite to ensure that it detects invalid language tags and reports them.

For cases like this, cargo-mutants allows marking code to be skipped. After marking this fmt implementation with #[mutants::skip], there are no more missed mutants in accept_language.rs.

Yay!

Understanding the tool

You should absolutely read "using results" in the cargo-mutants documentation, which is very well-written. It gives excellent suggestions for how to deal with missed mutants. Again, these indicate potential gaps in your test suite. The documentation discusses how to think about what to do, and I found it very helpful.

Then you should read about genres of mutants. It tells you the kind of modifications that cargo-mutants does to your code. Apart from changing individual operators to try to compute incorrect results, it also does things like replacing whole function bodies to return a different value instead. What if a function returns Default::default() instead of your carefully computed value? What if a boolean function always returns true? What if a function that returns a HashMap always returns an empty hash table, or one full with the product of all keys and values? That is, do your tests actually check your invariants, or your assumptions about the shape of the results of computations? It is really interesting stuff!

Future work for librsvg

The documentation for cargo-mutants suggests how to use it in CI, to ensure that no uncaught mutants are merged into the code. I will probably investigate this once I have fixed all the missed mutants; this will take me a few weeks at least.

Librsvg already has the gitlab incantation to show test coverage for patches in merge requests, so it would be nice to know if the existing tests, or any new added tests, are missing any conditions in the MR. That can be caught with cargo-mutants.

Hackery relevant to my tests, but not to this article

If you are just reading about mutation testing, you can ignore this section. If you are interested in the practicalities of compilation, read on!

The source code for the librsvg crate uses a bit of conditional compilation to select whether to export functions that are used by the integration tests as well as the crate's internal tests. For example, there is some code for diffing two images, and this is used when comparing the pixel output of rendering an SVG to a reference image. For historical reasons, this code ended up in the main library, so that it can run its own internal tests, but then the rest of the integration tests also use this code to diff images. The librsvg crate exports the "diff two images" functions only if it is being compiled for the integration tests, and it doesn't export them for a normal build of the public API.

Somehow, cargo-mutants didn't understand this, and the integration tests did not build since the cargo feature to select that conditionally-compiled code... wasn't active, or something. I tried enabling it by hand with something like cargo mutants --package librsvg -- --features test-utils but that still didn't work.

So, I hacked up a temporary version of the source tree just for mutation testing, which always exports the functions for diffing images, without conditional compilation. In the future it might be possible to split out that code to a separate crate that is only used where needed and never exported. I am not sure how it would be structured, since that code also depends on librsvg's internal representation of pixel images. Maybe we can move the whole thing out to a separate crate? Stop using Cairo image surfaces as the way to represent pixel images? Who knows!

Software package updates for openSUSE Tumbleweed in November had a steady rhythm and delivered both user-visible improvements and deeper technical fixes across the stack.

Plasma 6.5.3 and KDE Gear 25.08.3 focused on stability and polish across the KDE desktop and applications, while GNOME 49.2 delivered smoother session behavior, fewer freezes and more reliable system handling. The rolling release moved forward with Kernel Source 6.17.9, Mesa 25.3.0, and PipeWire 1.5.83 and several other important updates. Security fixes were also widespread this month, spanning the kernel, X.Org Server, Firefox, grub2, OpenEXR, and multiple networking components.

As always, be sure to roll back using snapper if any issues arise.

For more details on the change logs for the month, visit the openSUSE Factory mailing list.

New Features and Enhancements

Plasma 6.5.3 and 6.5.2: The 6.5.3 update focuses on polish and stability across the desktop. KWin receives numerous fixes, including proper scaling in window screenshots, improved DRM handling after suspend, and better X11 test isolation, while also resolving popup activation and blur contrast issues. Breeze and breeze-gtk address visual glitches in menus and GTK4 app theming, such as missing expander arrows and incorrect corner radii. The 6.5.2 update provided fixes across core components like Discover, which now correctly handles firmware packages on certain distributions. KWin resolves crashes, improves screencast cleanup, fixes cursor and clipboard behavior under Xwayland, and addresses display issues with the FPS plugin and screenshot tool. Additional fixes include improved applet stability in Plasma Addons, better mobile task switching, proper timezone translation handling, and enhanced logging in plasma-welcome.

KDE Gear 25.08.3: Dolphin resolves issues with zoom reset, middle-click opening, and split view sizing, while Kdenlive fixes crashes related to clip pasting and monitor switching, along with improving image sequence detection and subtitle styling. Kate addresses focus and documentation handling in its LSP plugin, Itinerary and Kitinerary add new transport ticket extractors (including Comboios de Portugal and Wiener Linien), and KMail reduces false-positive scam warnings. Other updates include translatable settings in KDE Connect, a missing SVG file type fix in Kdenlive, and minor UI and stability fixes in apps like Okular, NeoChat and KWalletManager.

KDE Frameworks 6.20.0: The latest frameworks improves handling of vCard 4 properties like photos and death dates in KContacts, and has better trash detection for network filesystems in KIO. Key fixes include enhanced security in KWallet with modern session management, reduced crashes in image format plugins (KImageFormats) when handling malformed files, and improved User Interface consistency in Kirigami for overlays and action toolbars. The release also aligns with Qt 6.8+ by removing outdated version checks and improving CMake module policies across Extra CMake Modules.

Pillow 12.0.0: This major version modernizes Python image handling with better performance, cleaner APIs, and updated codec support, improving reliability for everyday image processing and development workflows. Users benefit from refreshed image libraries like libjpeg-turbo, libpng, FreeType, and WebP, which improves format support and rendering quality. Developers gain stricter type hints, improved testing, and new features like ImageText and enhanced TIFF handling. Support for Python 3.9 and very old FreeType versions is dropped, so older environments may need upgrading, but in return people get a faster, better-maintained imaging stack.

GNOME 49.2: This update provides noticeably fewer freezes, smoother window behavior, and more reliable lock-screen notifications, networking indicators, and keyboard input. Display calibration, offline updates, and the on-screen keyboard are also more dependable. GDM 49.2, GNOME Control Center 49.2.1, and gnome-session 49.2 all updated in the latter half of the month. Autologin now correctly falls back to X11 if Wayland fails, avoiding painful lockouts, while the Control Center no longer crashes when configuring global shortcuts. Apps like Calculator, Builder, and Boxes did clean up some long-standing bugs that affected everyday workflows.

Orca 49.5: Screen reading became clearer and less frustrating for everyday browsing and typing with this update. Users should notice less repeated speech on web pages, fewer verbose announcements, and more natural handling of editable tables in apps and websites. Typing passwords is also improved with spaces now spoken correctly instead of being silently ignored.

switcheroo-control 3.0: This major version update improves how hybrid-GPU laptops detect and switch between integrated and discrete graphics, which directly affects gaming performance, battery life, and desktop smoothness. The new API can now reliably discover discrete GPUs across AMD, Intel, NVIDIA, and Nouveau drivers, reducing cases where apps fail to pick the right GPU. Vulkan handling is cleaner thanks to support for driver selection through VK_LOADER_DRIVERS_SELECT, making GPU-intensive tools more predictable.

GStreamer 1.26.8: This update corrects colors when subtitles are enabled, has fewer glitches with oddly sized or subsampled video, and has smoother muxing and RTP handling in streaming or conferencing apps. Developers benefit from faster pad forwarding, better parsing for AAC and AV1, improved WebRTC deadlock avoidance, and clearer error messages.

PipeWire 1.5.83: Users should notice fewer sync issues with this release, more reliable Bluetooth/HDMI device changes. There is also improved streaming especially for RTP-based tools and apps using echo cancellation. Developers gain clearer format-parsing errors, more flexible multichannel support, and safer renegotiation behavior in GStreamer and SPA components. Despite being a release candidate, it keeps full ABI compatibility. Additional fixes reduce glitches across pro-audio, gaming, and desktop setups.

Key Package Updates

Kernel Source 6.17.9: This update provides AMD and Intel GPU fixes for suspend failures, display quirks and performance issues. Storage and filesystems (NFS, SMB, exFAT, EROFS) gain reliability improvements that reduce stalls and corruption risks. Networking and input devices receive targeted bug fixes for Wi-Fi, Ethernet, and HID peripherals. Futex and input–output memory management unit (IOMMU) updates improve memory handling and virtualization edge cases.

OpenSSH 10.2p1: This update improves connection reliability and strengthens future-proof security for anyone using SSH daily. Sessions are now more stable thanks to fixes for ControlPersist terminal issues, and key handling with agents or PKCS#11 tokens work more consistently. You’ll also see smarter QoS behavior: interactive sessions get better responsiveness while file transfers fall back to normal network priority. OpenSSH also begins phasing out weak SHA1 SSHFP records and warns when non–post-quantum algorithms are used, nudging users toward safer defaults without breaking current setups.

libvirt 11.9.0: This release improves GPU-like clarity for Hyper-V thanks to a new host-model mode that exposes exactly which enlightenments are active, and network interfaces can finally be hot-plugged on Cloud Hypervisor guests. USB controller selection is smarter and more consistent across architectures, while NVMe disks and virtio memory models gain cleaner, safer options.

Mesa 25.3.0 and 25.2.7: The 25.3.0 release adds OpenGL 4.6 and Vulkan 1.4 API support (depending on driver) along with extensions for video encode, atomic operations, robust context handling and shader features on various drivers. Many driver bugs and game-specific crashes have been fixed. Games like Borderlands 4, RE4 Separate Ways, No Man’s Sky, Endless Legend 2, and Penumbra: Overture see stability and rendering improvements version 25.2.7. Video encoding paths, uniform updates, and AV1 handling are also more reliable. Developers benefit from safer Vulkan and OpenGL state handling, corrected modifiers, and cleanup across ACO, RADV, PanVK, and llvmpipe. While no new features land, this update delivers a noticeably smoother and more predictable GPU experience.

curl 8.17.0: This update closes several vulnerabilities, including an SFTP host-verification flaw and a Windows path-traversal issue, making network transfers safer by default. Users and developers also benefit from more reliable TLS handling, fewer memory leaks, better socket management, and improved QUIC and HTTP/3 stability.

sdbootutil 1+git20251111.611edd1: This update smooths out system boot management, so day-to-day usage becomes a bit more predictable with cleaner configuration files, corrected package summaries, and fewer rpmlint-related quirks that could cause confusion or misbehavior in tooling. The release also improves compatibility by recognizing tracing parameters and adds a Snapper drop-in to support CAP_SYS_CHROOT, making snapshot-based recovery more robust.

coreutils 9.9: This update addresses performance regressions in cp and tail giving smoother handling of compressed or large files, while cksum and basenc regain correct behavior for modern formats. Developers and power users benefit from safer parsing in numfmt, more predictable error handling, and faster wc -l on AVX512 systems. A few edge cases, like Ceph snapshot directories or malformed compressor scripts, now behave more consistently.

fwupd 2.0.17: This update provides fewer failed updates, smoother activation for docks and devices, and better support for newer hardware like Framework’s Copilot keyboard and additional NVMe SSDs. Behind the scenes, fwupd adds post-quantum signature support, phased update deployment, cleaner cache handling, improved EFI parsing, and fixes several crashes involving Intel GPUs, docks, and nested firmware images.

crypto-policies 20250714.cd6043a: This cryptographic algorithm for your system provides stronger defaults with expanded post-quantum and hybrid crypto support, cleaner FIPS behavior, and fewer mismatches between tools. Developers benefit from clearer policy mappings, stricter cipher enabling, and improved test coverage across PQC-capable stacks.

Security Updates

curl 8.17.0:

• CVE-2025-10966: Fixes a vulnerability of a man-in-the-middle intercept.
• CVE-2025-11563: Addresses a vulnerability known as a path traversal issue.

OpenSMTPD:

• CVE-2025-62875: Fixes a vulnerability that could trigger a shutdown and cause a denial of service.

Kernel Source 6.17.7:

• CVE-2025-40013: Fixes a kernel NULL-pointer dereference issue in the Qualcomm ASoC audioreach driver that could lead to a crash.
• CVE-2025-40028: Addresses a bug in the binder subsystem that could corrupt memory and cause a denial of service.
• CVE-2025-40027: Fixes an issue in the filesystem that could cause unexpected kernel behavior.
• CVE-2025-40026: Resolves a KVM x86 intercept-checking flaw that could allow incorrect guest/host handling.
• CVE-2025-40025: Fixes missing sanity checks preventing filesystem corruption.
• CVE-2025-40082: Fixes a slab out-of-bounds read in the hfsplus filesystem, preventing potential crashes.
• CVE-2025-40081: Prevents integer overflows that could cause incorrect memory access.
• CVE-2025-40080: Restricts NBD socket use to TCP/UDP to avoid unsafe socket operations.
• CVE-2025-40079: Fixes incorrect sign extension handling in RISC-V return values.
• CVE-2025-40078: Adds strict bounds checking reads to avoid invalid memory access.
• CVE-2025-40077: Fixes a left-shift overflow problem.
• CVE-2025-40076: Ensures PCI R-Car host uses the correct IRQ domain, avoiding interrupt misrouting.
• CVE-2025-40075: Fixes incorrect network metric lookups.
• CVE-2025-40074: Ensures IPv4 routing uses dst_dev_rcu correctly.
• CVE-2025-40073: Prevents invalid SSPP validation in drm-msm when the hardware block is not required.
• CVE-2025-40072: Adds proper return-value validation with mount namespace lookups.
• CVE-2025-40071: Fixes input queue blocking that could lead to stalled data processing.
• CVE-2025-40070: Fixes a warning and incorrect registration behavior.
• CVE-2025-40069: Resolves an object leak in drm-msm during VM_BIND error handling.
• CVE-2025-40068: Fixes an integer overflow preventing corrupted memory use.
• CVE-2025-40067: Ensures NTFS3 rejects invalid index allocation when BITMAP data is inconsistent.
• CVE-2025-40066: Adds required PHY checks during mt7996 WiFi initialization to prevent invalid operations.
• CVE-2025-40065: Fixes incorrect HGATP writes in RISC-V KVM to ensure valid mode settings.
• CVE-2025-40064: Fixes networking code during device namespace lookup.
• CVE-2025-40063: Ensures consistent allocation in crypto compression code to prevent misuse.
• CVE-2025-40062: Fixes a NULL pointer assignment.
• CVE-2025-40061: Fixes a race condition that could lead to crashes.
• CVE-2025-40060: Ensures proper NULL returns when allocations fail.
• CVE-2025-40059: Fixes incorrect return-value handling in Coresight drivers.
• CVE-2025-40018: Prevents premature FTP helper unregistering in IPVS during namespace teardown.
• CVE-2025-40058: Blocks dirty-tracking setup on VT-d hardware that does not support coherent DMA.
• CVE-2025-40057: Adds an upper bound for max_vclocks in PTP to avoid overflow or misuse.
• CVE-2025-40056: Fixes incorrect return-value checks in vhost-vringh’s copy_to_iter path that could trigger data corruption.

Unbound 1.24.2:

• CVE-2025-11411: Fixes for a vulnerability and potential DNS cache poisoning or domain hijacking.

X.Org Server 21.1.21:

• CVE-2022-49737: Fixes a race condition that could lead to crashes or unintended behavior.
• CVE-2025-26594: Fixes an issue that may access freed memory and lead to crashes or a code-execution risk.
• CVE-2025-26595: Addresses a buffer-overflow risking memory corruption or crashes.
• CVE-2025-26596: Fixes a heap-overflow that may cause memory corruption and potentially lead to crashes or exploitation.
• CVE-2025-26597: Addresses a buffer-overflow risking memory corruption or denial of service.
• CVE-2025-26598: Addresses an out-of-bounds write vulnerability that may overwrite memory, risk instability or exploitation.
• CVE-2025-26599: Addresses a vulnerability that may cause crashes or unpredictable behavior.
• CVE-2025-26600: Addresses a vulnerability leading to potential memory corruption or denial of service.
• CVE-2025-26601: Fixes invalid memory access or unstable server behavior.
• CVE-2025-49175: Fixes a vulnerability that could result in a server crash or cause resource misuse.
• CVE-2025-49176: Addresses a flaw concerning a potential crash risk or potential exploitation.
• CVE-2025-49177: Fixes a flaw that may result in invalid pointer dereferences or server instability.
• CVE-2025-49178: Fixes a vulnerability that could trigger invalid memory access or denial of service.
• CVE-2025-49179: Addresses a flaw concerning a buffer-overflow that had a potential crash risk or memory corruption.
• CVE-2025-49180: Fixes a memory-handling bug that may cause invalid memory accesses or server crashes.
• CVE-2025-62229: Addresses a crash or destabilize the display server.
• CVE-2025-62230: Addresses a vulnerability that could invalidate memory access or denial of service when clients unregister resources.
• CVE-2025-62231: Fixes a value-overflow bug that could have lead to an integer overflow.

grub2:

• CVE-2025-54771: Addresses a memory corruption or a bootloader crash.
• CVE-2025-54770: Addresses an issue that may trigger a potentially crashing the loader.
• CVE-2025-61662: Fixes a manipulation that may crash or destabilize the boot process.
• CVE-2025-61663: Fixes an issue that risks memory corruption or boot failures.
• CVE-2025-61664: Addresses a possible loader instability or denial of service.
• CVE-2025-61661: Addresses a vulnerability that could allow crafted USB hardware to corrupt memory, possibly enabling arbitrary code execution or boot compromise.

openexr 3.4.3:

• CVE-2025-64181: Fixes a problem could lead to crashes or memory corruption when processing specially crafted .exr files.
• CVE-2025-64182: A vulnerability may allow out-of-bounds behavior and potential code execution.
• CVE-2025-64183: An issue that affects safety when loading certain images, leading to potential memory safety problems.

**python313 **:

• CVE-2025-6075: Fixes a weakness causing high CPU use or performance degradation.
• CVE-2025-8291: Addresses specially crafted ZIP files that may be parsed incorrectly, potentially breaking archive integrity or causing unexpected behavior.

Xen 4.20.1_08:

• CVE-2025-58149: A fix for a hypervisor flaw that could have let a guest access memory.

python-Brotli 1.2.0:

• CVE-2025-6176: A fix for a flaw that could cause a remote server denial of service.

Mozilla Firefox 145.0:

• CVE-2025-13021: A boundary-checking flaw could allow remote code execution by a malicious web page.
• CVE-2025-13022: Another boundary-condition bug that enables sandbox escape or arbitrary code execution.
• CVE-2025-13012: A race-condition vulnerability that may lead to data corruption or memory compromise when exploited.
• CVE-2025-13023: A sandbox-escape issue allowing an attacker to break out of the browser sandbox.

Users are advised to update to the latest versions to mitigate these vulnerabilities.

Conclusion

Tumbleweed in November a steady cadence of updates that balanced desktop refinement with core system resilience. Plasma 6.5.3, KDE Gear 25.08.3 and GNOME 49.2 sharpened daily usability, while kernel 6.17.9, Mesa 25.3.0 and PipeWire 1.5.83 strengthened performance across graphics, audio and hardware support. Security remained front-and-center with fixes spanning the kernel, bootloader, network stack, browsers and virtualization.

Slowroll Arrivals

Please note that these updates also apply to Slowroll and arrive between an average of 5 to 10 days after being released in Tumbleweed snapshot. This monthly approach has been consistent for many months, ensuring stability and timely enhancements for users. Updated packages for Slowroll are regularly published in emails on openSUSE Factory mailing list.

Contributing to openSUSE Tumbleweed

Stay updated with the latest snapshots by subscribing to the openSUSE Factory mailing list. For those Tumbleweed users who want to contribute or want to engage with detailed technological discussions, subscribe to the openSUSE Factory mailing list . The openSUSE team encourages users to continue participating through bug reports, feature suggestions and discussions.

Your contributions and feedback make openSUSE Tumbleweed better with every update. Whether reporting bugs, suggesting features, or participating in community discussions, your involvement is highly valued.

It all started last summer

When my family moved to a new place. In our previous home we had a district heating service that included unlimited hot water for a fixed price. That was awesome - not very environmentally friendly and actually not very cheap, but we never ran out of hot water.

In our new home we are independent from the city’s hot water services. This is good because we pay exactly for the energy we use. It means that we have a 300-liter hot water heater that we turn on when we want to make as much hot water as we need. In most households such a hot water boiler has a thermostat set to a specific temperature and the heater keeps all 300 liters of water as hot as it is set. I do not like this, because regardless of how great the insulation on the water tank is, it loses temperature over time. I needed a smarter system.

A lively day at the office SUSE Prague hosted the fourth Linux Mobile Hackday last Thursday from eleven in the morning until the late afternoon. David Heidelberg organised the event and twelve people joined. The hackday took place one day after the very busy SUSE Open House, so the office felt quiet at first. The […]

The post 4th Linux Mobile Hackday at SUSE Prague appeared first on SUSE Communities.