I couldn't remember something for weeks. It popped into my head during a run — a relief, even though the memory itself was not pleasant. This episode of my flaky mind reminded me of this movie.

I won't give you even a hint of what the movie is about. The strength of it is not the premise, but the mood, the superb acting and Christian Bale's physical dedication to the role impressed me, alongside a cast of wonderfully weird characters and ominous presence of giant spinning machines. If you somehow missed the movie, give it a go. It's one of those that keep coming back to you.

One of the initial goals of the project was to explore whether the SVG build results generated by obs-status-service could become interactive and update in real time. In particular, I wanted to determine whether an SVG embedded in a Gitea README or comment in a PR could use JavaScript to request fresh OBS results without requiring the user to reload the page.

Testing JavaScript Inside SVG

To verify the browser behavior, I created a small test repository containing an SVG clock. The file includes a JavaScript timer that updates the displayed date and time every second, making it immediately clear whether the script has been executed.

I tested the same SVG in several embedding contexts:

The important distinction is not whether SVG supports JavaScript, because it does. The restriction depends on how the browser loads the file.

When SVG is used as an image, browsers apply a restricted processing mode for security and privacy reasons. In this context, scripts and external resources are disabled. This behavior is documented by MDN’s guide to SVG as an image and by the SVG 2 conformance rules, which describe the secure image processing modes.

Gitea’s Rendering Makes the Difference

The CommonMark image specification defines Markdown images as HTML img elements. My first test used an SVG stored in the same repository, and Gitea kept it as img, so the script did not run.

Daniel later observed a different case on src.opensuse.org: an HTTPS SVG badge served from the openSUSE infrastructure was embedded as an object and did update after its 30-second timer. That distinction matters because scripts are disabled in img, but can run when the SVG is loaded as an object.

The live obs-git-explorer badge confirms the second case. It is served as image/svg+xml, contains a setInterval that runs every 30 seconds, fetches fresh results from the same gitexplorer.opensuse.org origin, and updates its text and colors.

This also limits theme integration. An SVG image may use prefers-color-scheme to follow the browser or operating-system preference, but an externally loaded SVG still cannot directly reuse Gitea’s page CSS.

Implications for obs-status-service

This means live updates may be possible for obs-status-service, but only if Gitea embeds the generated badge as object.

The practical approach would be simple:

• Serve the visible badge as SVG.
• Let the SVG JavaScript fetch the equivalent .json URL.
• Update the badge text and colors from that JSON response.

If Gitea keeps the badge as img, the SVG remains static and server-side rendering is still the fallback. The key conclusion is that Markdown syntax is not enough to decide this; the final DOM matters: img is static, while object can support a self-updating SVG.

Dear Tumbleweed users and hackers,

This week, the various maintainers have been busy like usual, but the number of snapshots we managed to publish was slightly lower than in ‘normal’ weeks. Of the 5 snapshots built, we could only release 3 (0627, 0628, and 0630). The main issue causing discarded snapshots is the update to podman 6.0, which requires a few other modules to remain in sync. Things like buildah, skopeo, netavark – and it so happens that some slipped through in a snapshot but were then detected by openQA as not working as intended. That stack is still taking some time to ‘get right’.

The three published snapshots brought you these changes:

• libzio 1.15
• Mozilla Firefox 152.0.3
• gpgme 2.1.1
• Pango 1.58.0

The list of what’s being worked on reads a bit more spectacular than the changes of last week, namely:

• KDE Gear 26.04.3
• KDE Plasma 6.7.2
• SDL 3.4.12
• fwupd 2.1.6
• Linux kernel 7.1.2
• Mesa 26.1.4
• linux-glibc-devel 7.1: fix for llvm versions needed
• systemd 260.3
• Qemu 11.0.0: 32-bit host support has been dropped. Only kiwi is currently blocking this update
• Python 3.11 modules will be removed; The interpreter itself will remain a bit longer
• Podman 6.0.0

This is a roundup of articles from the openSUSE community listed on planet.opensuse.org.

The community blog feed aggregator lists the featured highlights below from June 26 to July 2.

Blogs this week cover Hans de Raad’s openSUSE Conference keynote on the Cyber Resilience Act and sovereign open-source assurance, a Google Summer of Code midterm report on building a local offline AI assistant for openSUSE Leap, and the Tumbleweed Monthly Update for June with major version bumps across the stack. Posts also include KDE Plasma 6.7 bugfix updates, Germany mandating ODF across its public administration, Meta’s Brain2Qwerty brain-computer interface research, OpenCV 5.0.0, and a hardware fix for the Heltec ESP32 Lora32 V3 OLED issue.

Here is a summary and links for each post:

Heltec ESP32 Lora32 V3 OLED issue fix

Stefan Seyfried’s Blog documents a hardware-level fix for the Heltec ESP32 Lora32 V3 board whose OLED display would not initialize with standard libraries. The solution requires enabling the VEXT pin by pulling its GPIO low in the setup() function, which was otherwise well hidden in Heltec’s own hacked library versions.

Free Software Foundation July 2026 Newsletter Roundup

Victorhck provides a Spanish compilation and translation of the Free Software Foundation’s July 2026 newsletter. Highlights include the FSFE’s position on Android DMA interoperability calling for the right to fully uninstall machine learning features, a piece on vendor lock-in being about document formats rather than applications, and the FSF’s monthly free software advocacy roundup.

What’s New in Plasma 6.7 Global Themes

The KDE Blog highlights the global theme changes in Plasma 6.7. Classic KDE 4 themes Oxygen and Air have been revived and updated to match the Breeze standard, including restored wallpapers and adaptive transparency support. A new Union theming system is introduced as a technical preview, allowing Plasma, QtQuick, and QtWidgets applications to be styled with a single CSS file.

Tumbleweed Monthly Update - June 2026

openSUSE News summarizes the June snapshot cycle for Tumbleweed. Major version bumps include Samba 4.24.3 with seven CVE fixes, MariaDB advancing from 11.8 to 12.3.2, and Flatpak 1.18.0. The second half of June was headlined by KDE Plasma 6.7.0 and KDE Frameworks 6.27.0. OpenSSL, WebKitGTK, and the Linux kernel each received extensive rounds of security fixes.

7 Months and Only 7 Donations – KDE Blog Seeks Community Support

The KDE Blog reflects on running the blog independently after a hosting transition to Neodigit, with only seven donations received in seven months. The post renews the call for community support to cover roughly 130 euros per year in hosting and domain costs, and invites readers to contribute through small donations or sponsored articles related to digital topics.

OpenCV 5.0.0: The Biggest Evolution of OpenCV in Years

Alessandro’s Blog covers the OpenCV 5.0.0 release. The major version requires C++17, drops the legacy C API and Python 2 support, and introduces new data types including bfloat16, uint32, uint64, and boolean matrices. Modules have been reorganized with features2d becoming features. New deep-learning-based local features include ALIKED, DISK, and LightGlue matcher.

Second Bugfix Update for Plasma 6.7

The KDE Blog announces the second bugfix release for Plasma 6.7, arriving a few weeks after the initial release. The update continues KDE’s regular maintenance cycle with stability improvements, better translations, and error resolution across the desktop environment.

Brain2Qwerty: Typing with the Brain

Alessandro’s Blog covers Meta AI Research’s Brain2Qwerty v2, a non-invasive brain-computer interface that decodes typed sentences from MEG and EEG signals. The model achieves up to 78% word-level accuracy on the best participant and over half of sentences were decoded with at most one word error. The post discusses the technology’s potential for communication aids and the ethical considerations around neural data privacy.

Building a Local, Offline openSUSE Assistant for GSoC

openSUSE News shares a GSoC midterm update on suse-assist, which combines a Small Language Model with retrieval-augmented generation over official openSUSE documentation. The assistant runs on Leap 16.0 in a BCI-based container built by OBS, benchmarks six GGUF models with Gemma 4 E4B as the default, and supports offline bundles with checksums for machines without internet access.

KDE Seeks Its Next Goals: Submissions Open to Shape the Project’s Future

The KDE Blog reports that KDE e.V. has opened the goal-setting process for the project’s next development priorities. Following previous cycles focused on Wayland adoption, accessibility, and application development simplification, the community is now invited to propose new goals through a dedicated workspace. Proposals are accepted through August 8, with the final announcement at Akademy on September 19.

What’s New in Plasma 6.7 Plasmoids

The KDE Blog covers the new features in Plasma 6.7 plasmoids. Highlights include the ability to switch between light and dark modes directly from the Brightness and Color plasmoid, a new Background Applications entry in the system tray for better oversight of running services, and the addition of the Vietnamese lunar calendar for broader international support.

openSUSE Tumbleweed Review – Weeks 25 & 26 of 2026

Victorhck and Dominique Leuenberger report on 11 snapshots published during a two-week period bridging the openSUSE Conference in Nuremberg. Key updates include KDE Plasma 6.7.0 and 6.7.1, KDE Frameworks 6.27.0, Linux kernel 7.0.12, Mesa 26.1.3, MariaDB 12.3.2, Mozilla Firefox 152.0.2, and GStreamer 1.28.4. Staging topics include Qemu 11.0.0 dropping 32-bit host support and Linux kernel 7.1 testing.

Bug Fixes After 6.7 – This Week in Plasma

The KDE Blog translates Nate Graham’s This Week in Plasma, covering the post-Plasma 6.7 bugfix sprint. Plasma 6.7.1 shipped with fixes for KWin crashes on NVIDIA GPUs, DisplayLink monitor support, and dual-GPU laptop display freezes. Plasma 6.7.2 addresses variable refresh rate crashes on multi-monitor setups.

When the Code Stays Clean and Trust Collapses Anyway

openSUSE News publishes Hans de Raad’s keynote article from the openSUSE Conference on why Europe’s third way needs sovereign open-source assurance. The post examines the GSD project’s trust-state inversion, the xz backdoor, and how the Cyber Resilience Act turns sovereignty into an evidence problem. It argues that open-source assurance is no longer only about scanning code but about governing the chain of authority around it, and calls for funding maintainers as supply-chain risk reduction.

Germany Makes ODF Mandatory Across Its Public Administration

The KDE Blog reports on Germany mandating the Open Document Format as the obligatory standard within its sovereign digital infrastructure framework, the Deutschland-Stack. Public administration documents must use ODF formats (.odt, .ods, .odp, .odg, .odb) instead of proprietary formats. The PDF/UA accessibility standard is also included. Florian Effenberger of The Document Foundation called it a confirmation that open formats are fundamental infrastructure for democratic and interoperable public administration.

View more blogs or learn to publish your own on planet.opensuse.org.

 I am using different ESP32 Lora boards, not for LORA but for their included modem chips which can be used to receive 868MHz sensors like in my https://github.com/seife/lacrosse2mqtt project.

Now I got a new one, "Heltec ESP32 Lora32 V3" and this one did not want to light up its OLED. The hardware is not broken, as the factory-shipped software did use the display, but with my own examples, it stayed dark.

Searching the internet found that other people had the same issue but the only solution that was to be found was using Heltec's own horribly hacked library versions, which I did not want.

So I examined the differences between the Heltec version and the original https://github.com/ThingPulse/esp8266-oled-ssd1306 and the solution was simple, even though it is well hidden:

You need to enable the VEXT pin (by pulling its GPIO to low), like this in your setup() function:

That's it. Now it is working as with the other boards before.

Contributors to openSUSE had a great time at the openSUSE Conference in June. Even as many of them gathered in Nuremberg to discuss how to drive development of the rolling release forward, software package updates for openSUSE Tumbleweed kept rolling out.

June brought major version bumps across the stack with Samba jumping to 4.24.3 carrying seven Common Vulnerabilities and Exposures fixes, MariaDB advancing from 11.8 to 12.3.2, and Flatpak reaching 1.18.0.

KDE Gear 26.04.2 landed as the second bugfix release of the series, and GStreamer progressed to 1.28.4 with security and playback fixes. OpenSSL received a massive security update and both WebKitGTK and the Linux kernel received extensive rounds of vulnerability fixes.

The second half of June was headlined by KDE Plasma 6.7.0 and KDE Frameworks 6.27.0. NetworkManager advanced to 1.56.1 and python-cryptography reached 49.0.0 with post-quantum ML-DSA signing support. FreeRDP 3.27.1 raised the minimum TLS version to 1.2 while addressing multiple CVEs. VirtualBox 7.2.10 added Linux kernel 7.1 support and Wayland clipboard sharing.

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

Samba 4.24.3: A major version bump from the 4.23 series brings a major security refresh with several CVE fixes. Notable changes include a fix for unauthenticated remote code execution in the AD DC, SAMR remote code execution, and group policy certificate enrollment without validation.

Flatpak 1.18.0: This major update improves error handling and printed output of flatpak-coredumpctl, adds support for the AMD vendor-specific compute interface (/dev/kfd) via DRI device permissions, and improves startup time for fish shell integration. Ignoring system bus failures in parental controls check and replacing deprecated GTimeVal with g_get_real_time() round out the release.

GPGME 2.1.0: This update introduces new flags is_de_vs and beta_compliance for encryption results, a new decryption flag GPGME_DECRYPT_SESSION_HASH, and support for setting CMS signature attributes via gpgme_sig_notation_add. A new context flag export-filter is also added. Several locking and passphrase handling fixes are included, along with the companion gpgmepp 2.1.0 and qgpgme 2.1.0 updates.

MariaDB 12.3.2: A major version jump from 11.8.8 brings the database server to the 12.3 series. This release carries multiple security fixes alongside a changelog of improvements documented in the upstream release notes.

KDE Gear 26.04.2: Dolphin fixes a dangling pointer access in SettingsDataSource and a swapActiveView crash. Kate corrects working directory handling when invoking git and fixes urlinfo for relative files. Konsole fixes a copy command causing unwanted scroll-to-bottom. Kitinerary adds extractors for BDŽ (Bulgarian State Railways) PDF tickets and Condor PKPass. KOrganizer fixes recurring event start-end time display and Kleopatra now requires GpgME 1.24.2 (at the beginning of the month in Tumbleweed updated to version 2.1.0).

GStreamer 1.28.4: The rtspsrc2 element receives major feature expansion with support for SRTP, authentication, HTTP tunnelling, keep-alive, TLS validation, and latency configuration. Wavpack audio receives channel and channel-mask related fixes. Debug logging performance is improved, and memory leaks across caps allocation, buffer pools, and the GL upload path are resolved. The d3d12decoder gets a fix for Qualcomm GPUs on ARM64 Windows.

GraphicsMagick 1.3.47: DPX subsampling validation is corrected to avoid divide-by-zero. The JNG writer properly handles NULL returns from ImageToBlob(), and the MNG writer enforces a 256-color palette limit. The PS/PS2/PS3 coders enforce dimension limits to prevent Ghostscript-based denial-of-service. SVG gains validations for element id syntax and rejects attribute values with single quotes. The XCF reader reports errors for layerless images and fixes two unsigned integer overflow cases.

fwupd 2.1.4 & 2.1.5: The firmware update daemon received two updates during June. Version 2.1.4 adds support for Compal BIOS version format, NixOS quickstart, encrypted swap detection below device-mapper, and removes the flashrom plugin. Dozens of bounds checks and validation fixes are included across Dell dock, Novatek, Goodix MoC, Synaptics RMI, CCGX DMC, and other device updaters. The 2.1.5 follow-up fixes a msgpack regression for Huddly cameras, adds Elan touchscreen support, and expands the netlink socket buffer to prevent packet loss during event floods.

SDL3 3.4.10: This update adds depth texture array support in the GPU API, GameInput v3 controller sensor support, rumble support for the new Steam Controller, and GameCube rumble support when the adapter is in PC mode. Several new controllers are supported including the GameSir Super Nova and PDP Afterglow Wave Wireless. The X11 Synchronization Extension is disabled by default and can be re-enabled via SDL_HINT_VIDEO_X11_ENABLE_XSYNC_EXT.

Key Package Updates

Linux kernel 7.0.11 & 7.0.12: The kernel received two updates during June with a heavy security focus. Version 7.0.11 carried an extensive set of CVE fixes spanning BPF (end-of-list detection in cgroup storage, negative CO-RE accessor indices), netfilter (divide-by-zero in nfnetlink_osf, IEEE1394 ARP payload handling, arp_tables), ALSA USB audio UAC2 rate parsing, and more. Version 7.0.12 added fixes for NFC LLCP use-after-free, xfrm underflow, netfilter ebtables OOB read, nf_tables dst corruption, tun/tap XDP page handling, ethtool RSS context handling, ALSA HDA cs35l56 and OSS setup UAF, and HSR OOB access in supervision frame handling.

WebKitGTK 2.52.4: A security-focused update fixing 16 CVEs in the web rendering engine. The release adds support for half-width fonts, improves content filter compilation, improves handling of out-of-disk-space conditions in the NetworkProcess cache, fixes scrollbar painting during width changes, fixes playback of certain YouTube videos with low frame rates, and addresses several crashes and rendering issues.

ImageMagick 7.1.2.25: A security-focused update rejecting malformed HDR, PGX, RLA, FITS, SGI, and DDS files with invalid dimensions. Polynomial distortion argument count validation is added, and an out-of-bounds read of GPS rationals in GetEXIFProperty is fixed.

Mesa 26.1.2: The update resolves graphical corruption on older Intel integrated GPUs (e.g., i5-2400) introduced in 26.1.0 and fixes a crash in ANV’s ASTC texture handling on Xe3 when floating-point exceptions are enabled. Vulkan drivers see important corrections: RADV adds workarounds for Forza Horizon 6 and Crimson Desert, ANV restores Android external format compatibility in debug builds, and PanVK/Turnip improve memory reporting and depth state handling. More details are available in the Mesa 26.1.2 release notes.

mutter 50.2: Fixes size increases when quickly unmaximizing windows by drag, cursor position hint for Xwayland with scaling, fullscreening of edge-tiled windows, tablet tool cursor hotspot scaling, alt-tab with sloppy/mouse focus, and broken switch-monitor mapping on stylus buttons. Support for version 2 of the text_input_v3 protocol is implemented, and DND with tablets now works across surfaces.

flatpak 1.18.0: This update adds support for the AMD compute interface (/dev/kfd) via the DRI device permission, enabling GPU compute access for Flatpak applications on AMD hardware. The output of flatpak update is improved with clearer failure causes, and flatpak-coredumpctl gains better error handling. Fish shell integration startup time is improved. Bug fixes include ignoring system bus failures in parental controls checks and replacing deprecated GTimeVal usage.

cups-filters: The cups-browsed service is now provided as a separate sub-package, allowing users to uninstall it to avoid the security risk of automatic print queue creation from any DNS-SD announcement on the local network.

libzypp 17.38.13: Two security fixes in the package management library. A path= entry in .repo files must not refer to a location outside the repo (CVE-2026-44942), and repo keyhint must denote a filename not a path (CVE-2026-44941).

wicked 0.6.79: Fixes an indirect remote shell command injection via unsanitized DHCP strings and leaseinfo dump (CVE-2026-44932). Single-quote escaping is added to leaseinfo dump output, and posix-tz-dbname processing now permits only valid characters per RFC 4833.

Security Updates

OpenSSL 3:

• CVE-2026-45447: Fixes a heap use-after-free in PKCS7_verify() that could lead to memory corruption.

• CVE-2026-45446: Addresses incorrect tag processing for empty messages in AES-GCM-SIV and AES-SIV modes.

• CVE-2026-42770: Resolves FFC-DH peer validation using attacker-supplied q, potentially weakening key exchange.

• CVE-2026-45445: Fixes AES-OCB IV being ignored on the EVP_Cipher() path.

• CVE-2026-42767: Addresses a NULL pointer dereference in CRMF EncryptedValue decryption.

• CVE-2026-42768: Resolves a multi-recipient Bleichenbacher oracle in CMS_decrypt() and PKCS7_decrypt().

• CVE-2026-42769: Fixes trust-anchor substitution via cert/issuer typo in CMP rootCaKeyUpdate.

• CVE-2026-42766: Addresses a possible NULL dereference in password-based CMS decryption.

• CVE-2026-34183: Resolves unbounded memory growth in the QUIC PATH_CHALLENGE handler.

• CVE-2026-42764: Fixes a NULL pointer dereference in QUIC server initial packet handling.

• CVE-2026-34182: Addresses CMS AuthEnvelopedData processing that could accept forged messages.

• CVE-2026-9076: Fixes an out-of-bounds read in CMS password-based decryption.

• CVE-2026-7383: Resolves a possible heap buffer overflow in ASN.1 multibyte string conversion.

• CVE-2026-34180: Addresses a heap buffer over-read in ASN.1 content parsing.

Linux kernel 7.0.11:

• CVE-2026-45838: Fixes end-of-list detection in BPF cgroup storage.

• CVE-2026-45839: Addresses negative CO-RE accessor indices in BPF.

• CVE-2026-45840: Resolves an upcall PID array size issue in openvswitch.

• CVE-2026-45841: Fixes a divide-by-zero in netfilter nfnetlink_osf.

• CVE-2026-45842: Addresses VJ receive packet rejection on SLIP instances.

• CVE-2026-45843: Resolves compressed decode bounds in SLIP.

• CVE-2026-46242: Fixes an eventpoll struct issue in ep_remove.

• CVE-2026-45844: Addresses IEEE1394 ARP payload handling in netfilter arp_tables.

• CVE-2026-45845: Fixes a NULL pointer dereference in net/sched taprio.

• CVE-2026-45846: Resolves a NULL pointer dereference in bareudp.

• CVE-2026-43494: Fixes zerocopy page pin reset in net/rds.

• CVE-2026-46300: Addresses shared frag marker preservation in skbuff.

• CVE-2026-43503: Resolves shared frag marker propagation through skbuff.

• CVE-2026-46243: Fixes SMB client rejection of userspace cifs.spnego descriptions.

• CVE-2026-46018: Addresses ALSA USB audio UAC2 rate parsing at MAX_NR_RATES.

• CVE-2026-45993: Resolves a LoongArch spectre boundary for syscall dispatch.

• CVE-2026-46006: Fixes a u32 overflow in Nouveau pushbuf relocation.

• CVE-2026-46041: Addresses a sleep-in-atomic context in greybus gb-beagleplay.

• CVE-2026-46022: Fixes an OOB MMIO read in ibmasm.

• CVE-2026-45994: Addresses OOB reads in ibmasm command file write.

• CVE-2026-46064: Resolves a heap over-read in ibmasm I2O message send.

• CVE-2026-46100: Fixes an AFS mmap_prepare revert.

• CVE-2026-46017: Addresses deferred split queue races during migration in mm.

• CVE-2026-46080: Fixes transaction splits in OCFS2 DIO completion.

• CVE-2026-46097: Addresses a use-after-free in edt-ft5x06 input debugfs.

• CVE-2026-46089: Fixes partial discard endio handling in zram.

• CVE-2026-46092: Addresses a PCI upstream bridge existence check in rtw88 WiFi driver.

• CVE-2026-46069: Fixes a use-after-free in mwifiex adapter.

• CVE-2026-46036: Addresses VFIO CDX serialization of device IRQ setting.

• CVE-2026-46034: Resolves a NULL pointer dereference in VFIO CDX interrupt handling.

• CVE-2026-46021: Fixes thermal zone governor cleanup.

• CVE-2026-45996: Addresses a use-after-free on SPI IMX unbind.

• CVE-2026-46074: Fixes memory leaks on SPI CH341 probe failures.

WebKitGTK 2.52.4:

• CVE-2026-28847: Fixes a WebKit memory handling issue that could cause an unexpected crash.

• CVE-2026-28883: Addresses a flaw where processing malicious web content could lead to memory corruption.

• CVE-2026-28901: Resolves a WebKit vulnerability where processing malicious web content could lead to an unexpected crash.

• CVE-2026-28902: Fixes a WebKit issue where processing malicious web content could lead to memory corruption.

• CVE-2026-28903: Addresses a flaw where visiting a malicious website could lead to unexpected behavior.

• CVE-2026-28904: Resolves a WebKit memory corruption issue when processing malicious web content.

• CVE-2026-28905: Fixes a logic issue where a malicious website could access restricted resources.

• CVE-2026-28907: Addresses a WebKit vulnerability that could cause an unexpected crash.

• CVE-2026-28942: Resolves a cross-origin issue in WebKit’s Navigation API.

• CVE-2026-28946: Fixes a WebKit memory handling issue that could lead to an unexpected process crash.

• CVE-2026-28947: Addresses a WebKit flaw where processing malicious web content could bypass the Same Origin Policy.

• CVE-2026-28953: Resolves a logic issue where a malicious website could access script message handlers intended for other origins.

• CVE-2026-28955: Fixes a WebKit memory handling issue that could cause an unexpected process crash.

• CVE-2026-28958: Addresses an authorization flaw where a maliciously crafted webpage could fingerprint the user.

• CVE-2026-43658: Resolves a WebKit sandbox issue where restricted content could be processed outside the sandbox.

• CVE-2026-43660: Fixes a logic flaw where visiting a malicious website could lead to a cross-site scripting attack.

Samba 4.24.3:

• CVE-2026-4480: Fixes unauthenticated remote code execution in the AD DC.

• CVE-2026-4408: Addresses remote code execution in the SAMR protocol.

• CVE-2026-3238: Resolves an unauthenticated UDP packet crash in the AD DC NBT server.

• CVE-2026-3012: Fixes group policy certificate enrollment using HTTP without validation.

• CVE-2026-1933: Addresses a missing access check on reparse point operations.

• CVE-2026-2340: Resolves a vfs_worm not blocking directory modification.

• CVE-2026-40170: Addresses a third-party ngtcp2 update requirement.

OpenEXR 3.4.12:

• CVE-2026-45696: Fixes a heap-buffer-overflow READ via codestream/channel width mismatch in HTJ2K decode.

• CVE-2026-44663: Addresses an integer overflow in the HTJ2K decoder leading to heap-buffer-overflow.

GraphicsMagick 1.3.47:

• CVE-2026-25799: Fixes YUV sampling-factor argument validation to prevent potential security issues.

• CVE-2026-26284: Fixes a security vulnerability in GraphicsMagick image processing.

• CVE-2026-28690: Addresses MNG writer enforcing a 256-color palette limit to prevent excessive memory usage.

• CVE-2026-30883: Fixes detection and reporting of excessively large profiles in the PNG writer.

• CVE-2026-33535: Addresses a static buffer overflow in MagickXImageWindowCommand when a numeric key is held depressed.

• CVE-2026-42050: Fixes an off-by-one error in GraphicsMagick.

MariaDB 11.8.8:

• CVE-2026-49261: Fixes a security vulnerability in the MariaDB server.

• CVE-2026-48165: Addresses a security vulnerability in MariaDB.

• CVE-2026-48163: Resolves a security vulnerability in MariaDB.

python-tornado6 6.5.7:

• CVE-2026-49853: Fixes credentials and cookies not being stripped when following redirects to a different origin.

• CVE-2026-49855: Addresses a denial-of-service via large compressed responses bypassing max_body_size.

• CVE-2026-49854: Resolves an out-of-bounds read of up to three bytes past an input array in the C extension.

7-Zip 26.01:

• CVE-2026-48095: Fixes a heap buffer write overflow that could be triggered by crafted archives.

sshfs 3.7.6:

• CVE-2026-47187: Fixes a symlink escape vulnerability where a rogue SFTP server could read or write local files.

• CVE-2026-48711: Addresses an argument injection vulnerability in SSH command handling.

php8 8.5.7:

• CVE-2026-44927: Fixes pointer difference truncation to int in uriparser that could lead to incorrect URI handling.

• CVE-2026-44928: Addresses a flaw where the EqualsUri function could misclassify two unequal URIs as equal.

libzypp 17.38.13:

• CVE-2026-44942: Fixes a path= entry in .repo files that could refer to locations outside the repository base.

• CVE-2026-44941: Addresses a repo keyhint entry that could specify a path instead of a filename.

wicked 0.6.79:

• CVE-2026-44932: Fixes an indirect remote shell command injection via unsanitized DHCP strings and leaseinfo dump.

perl-Cpanel-JSON-XS 4.41:

• CVE-2026-9516: Fixes a BOM-shift PV-corruption that could cause a SIGABRT.

• CVE-2026-9334: Addresses a type confusion in dupkeys_as_arrayref handling.

openssh:

• CVE-2026-3497: Fixes a possible information disclosure or denial of service due to uninitialized variables in GSSAPI key exchange patches.

python-pip 26.1.2:

• CVE-2026-8643: Fixes console_scripts and gui_scripts entry points whose name would install a script outside the scripts directory.

OpenSC:

• CVE-2026-10275: Fixes a global buffer overflow during key pair generation tests due to missing input validation.

python-M2Crypto 0.48.0:

• CVE-2026-0672: Fixes authcookie handling of CookieError from Python 3.13.12+ to prevent potential security issues.

freeipmi 1.6.18:

• CVE-2026-50031: Fixes potential stack corruption in Dell and Fujitsu IPMI OEM commands and a potential buffer overflow in Fujitsu SEL entry handling.

graphite2 1.3.15:

• CVE-2026-50593: Fixes a security vulnerability in the graphite font shaping library.

ldns 1.9.2:

• CVE-2026-10846: Fixes insufficient verification that DNS responses belong to a query, enabling potential cache poisoning.

glib-networking:

• CVE-2026-10028: Fixes a cycle detection issue when setting the issuer property in the TLS certificate chain.

perl-GD 2.86:

• CVE-2026-11526: Fixes a command injection via 2-arg open() in _make_filehandle.

perl-HTML-Parser 3.85:

• CVE-2026-8829: Fixes a heap-use-after-free in _decode_entities.

djvulibre 3.5.30:

• CVE-2021-46312: Fixes a security vulnerability in DjVu file processing.

rav1e:

• CVE-2025-58160: Fixes a security vulnerability in Rust AV1 encoder dependencies.

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

Conclusion

June came with some heavy security hardening across openSUSE Tumbleweed. Samba jumped to the 4.24 series with many CVE fixes, MariaDB advanced to 12.3.2, and Flatpak reached 1.18.0. OpenSSL received an extensive security refresh, while WebKitGTK and the Linux kernel each received large rounds of vulnerability fixes. KDE Gear 26.04.2 continued the steady cadence of KDE application refinements, GStreamer 1.28.4 delivered major RTSP infrastructure improvements, and GraphicsMagick 1.3.47 rolled up years of accumulated upstream security patches. The openSUSE Conference in Nuremberg provided the community backdrop for planning the next phase of the rolling release.

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.

We started this Google Summer of Code project with a simple question: can a new openSUSE user get useful, system-specific help without sending their questions or machine information to a cloud service?

The idea was to combine a Small Language Model (SLM) running on the user’s machine with retrieval over official openSUSE documentation. Instead of giving generic Linux advice, the assistant should know that the machine is running Leap, whether it uses Btrfs and Snapper, which GPU is installed, and which services have failed. It should then explain tools such as zypper, YaST, Snapper, and firewalld using the documentation that applies to that system.

At the midterm point, that core loop is working on an openSUSE Leap 16.0 VM. The assistant runs locally, retrieves openSUSE documentation from a local LanceDB index, reads selected host context, and is available through both a command-line interface and a web UI. More importantly, it now runs from an openSUSE BCI-based container built by the Open Build Service (OBS), including on a VM with no outbound internet access.

• Source repository
• GSoC proposal
• Public Leap VM demo
• OBS package

From a Small PoC to a Real Leap Deployment

Before GSoC, the project used TinyLlama, ChromaDB, and a small set of documentation to prove that the basic architecture was possible. That was enough for a demo, but not enough to answer the questions that matter for a distribution feature: Which model works well on CPU-only hardware? How is the assistant installed? What happens when the target machine cannot download a model? Can a container inspect the host without being given unnecessary privileges?

The mentor-provided test VM made these questions concrete. It runs Leap 16.0 with 4 vCPUs and 15 GB of RAM, has no GPU, and cannot access the internet. This is a useful target because it prevents an accidental dependency on cloud APIs or a developer’s already-populated cache.

The current request path is:

1. The user asks a question in the CLI or Gradio web UI.
2. The assistant reads relevant, non-sensitive system facts from the host.
3. MiniLM embeddings retrieve matching chunks from a local LanceDB index.
4. The system prompt combines the question, host context, and retrieved sources.
5. A local GGUF model generates the answer through llama.cpp.
6. The answer includes references to the documentation used.

The index currently contains 1,982 chunks from the Leap Startup and Reference guides, Leap 16.0 release notes, and selected openSUSE wiki SDB pages. The SDB set includes common areas such as repositories, upgrades, audio, and NVIDIA driver and SUSE Prime troubleshooting.

Model Selection Needed Measurement, Not Guesswork

One of the first tasks was replacing TinyLlama with models that could produce reliable administration guidance while still running on ordinary hardware. We added model tiers and benchmarked six GGUF models through the complete RAG and system-context pipeline on the Leap VM.

Each model answered the same eight openSUSE onboarding questions. Generation ran offline on the VM, while judging ran separately against saved answers using Gemini 2.5 Flash-Lite, reference answers, and expected-fact checklists. Separating these steps meant the slow CPU generation did not need to be repeated when the scoring method changed.

The benchmark used the same constrained target as the public deployment: 4 vCPUs, 15 GB of RAM, no GPU, and no network access during generation. Latency below is the average time for one complete answer, including retrieval and the prompt built from the retrieved documentation and host context.

Higher and further left is better. Qwen3-4B achieved the highest judged quality; Gemma 4 E4B is the current default and answered about 30 seconds faster. The orange ring marks the current default.

The results showed that a larger model is not automatically a better default. Qwen3-4B scored slightly higher than Qwen3-8B and answered about 30 seconds faster. Gemma 4 E4B offered a useful latency/quality trade-off and is currently the default standard model following mentor discussion. Qwen3-1.7B remains a practical option for lower-resource machines, while TinyLlama is useful only for smoke tests.

The full methodology and per-model discussion are in the evaluation report.

These timings also changed the web UI. A 70-120 second answer can look like a hung application if the interface says nothing. The UI now identifies the selected tier, explains that the model is loaded on the first question, shows elapsed generation time, and reports missing model or index data more clearly.

Offline Means More Than Running the Model Locally

The largest lesson so far is that local inference and offline installation are two different problems.

Once downloaded, a GGUF model can run without a network connection. A usable assistant, however, also needs the embedding model, Python and native libraries, the documentation index, configuration, and compatible file ownership. The VM’s lack of internet access exposed every hidden download quickly.

To make the state visible, we added suse-assist doctor. It checks model files, the vector store, the embedding cache, memory and disk availability, host mounts, offline environment settings, the web port, and the container runtime. We also added suse-assist setup to select a tier, prepare the model and index, optionally import offline data, and run the final checks.

For machines that cannot download assets during setup, the project now has an offline bundle format:

suse-assist bundle export --output suse-assist-offline-bundle.tar.zst
suse-assist bundle import suse-assist-offline-bundle.tar.zst

A bundle contains a selected GGUF model, the MiniLM cache, the LanceDB index, and a manifest with checksums. The import/export commands and firstboot import path are implemented. Producing a release bundle from the VM data and testing it through a complete OEM first boot is one of the next tasks. The final distribution policy is still open: the data could be part of a KIWI image, an RPM payload, a separate artifact, or a firstboot download for connected systems.

Moving the Build into the openSUSE Infrastructure

The first container image was useful for testing, but it was not built in the same way an openSUSE deliverable should be. The container now starts from the SUSE BCI Python base and uses zypper for system dependencies.

The next issue was dependency availability. OBS builds in a clean, offline build environment, while several parts of the Python ML stack are not currently packaged as openSUSE RPMs. This includes important pieces around llama-cpp-python and LanceDB. To test the rest of the path without waiting for all dependency packaging, we built an OBS prototype with an approximately 467 MB wheelhouse. It installs the Python dependencies with pip --no-index, including a locally built llama-cpp-python wheel.

That experiment now builds the real assistant image in home:anujagrawal:suse-assist/suse-assist-image and publishes it as:

registry.opensuse.org/home/anujagrawal/suse-assist/images/opensuse/suse-assist:latest

The Leap VM cannot pull from the registry, so we tested the actual offline delivery path: download the OBS image archive on a connected machine, checksum it, copy it over SSH, load it with Podman, and run it against the prepared data volume. This found a real ownership mismatch, which was fixed by assigning the container’s suseai user a stable UID and GID of 999. The public demo now runs this OBS-built image rather than the earlier local build.

On that VM, suse-assist doctor, web startup, test-tier inference, and standard Gemma 4 E4B inference have all been exercised. A standard-tier answer to “What is zypper?” took about 70 seconds and included retrieved references.

The vendored wheelhouse proves that OBS can build and publish the container. It is not automatically the final packaging answer. The open question is whether this is acceptable as a short-term container solution or whether each missing dependency should be packaged as a proper RPM before the assistant moves beyond a home project.

Preparing for First Boot and Daily Use

Distribution integration should not require users to know a container command. The repository now includes the first scaffolding for a KIWI OEM image, a Podman Quadlet unit, and a firstboot service that prepares the assistant’s data and starts the web service. There is also a native systemd service setup path for a future RPM install, plus a desktop launcher that opens the local UI.

These pieces define how the assistant could be presented as a normal openSUSE feature, but they are not the same as a completed installer integration. The full KIWI image and offline firstboot flow still need end-to-end validation. Integration with Agama or jeos-firstboot also needs to follow the packaging and data distribution decisions rather than hard-code a temporary deployment method.

We also added an MCP server and client proof of concept. The server exposes system context and documentation search as tools, while the client can connect the assistant to external MCP servers. This is not required for the basic onboarding flow, but it shows that the openSUSE-specific context and retrieval work can be reused by other local applications.

Safety Is Part of the Interface

System administration answers have more impact than ordinary chatbot responses. Retrieved web pages are therefore treated as untrusted context: instructions inside the retrieved text must not override the system prompt. The assistant cleans hidden reasoning markers, asks for documentation references when recommending commands, and adds warnings around destructive operations and repository vendor changes.

The container runtime also uses a non-root user, dropped capabilities, a read-only root filesystem where possible, resource limits, and a health check. Host system context is mounted read-only. These controls do not make generated advice infallible, but they reduce the authority of the process and make risky advice more visible to the user.

What Changed from the Proposal

The original midterm plan placed more emphasis on completing a jeos-firstboot module and systemd socket activation by this point. The core assistant, model tiers, RAG expansion, system-context work, and Agama integration research are in place, but the VM changed the order of the remaining work.

An onboarding assistant that works only after a developer manually populates model and embedding caches is not ready for first boot. We therefore moved some packaging and offline-distribution work forward: the BCI migration, OBS build, registry publication, setup and doctor commands, bundle format, and offline VM validation. The firstboot integration is now being built on top of a deployment path that has actually run on Leap without internet access.

This was a useful correction to the plan. The main difficulty is not writing one more chat interface. It is delivering several gigabytes of model data and a native ML dependency stack through normal distribution infrastructure, then making the result understandable on machines with very different resources.

Plans for the Second Half

The next part of the project will focus on closing that delivery gap:

1. Build a real offline data bundle from the VM and test bundle import through the OEM firstboot path.
2. Settle the short-term OBS dependency approach: vendored wheels or proper RPMs for the missing ML stack.
3. Produce and validate an installable RPM on a clean Leap system.
4. Decide how model weights and the generated documentation index are distributed, including licensing and image-size implications.
5. Complete the KIWI/firstboot path and connect it to the appropriate openSUSE onboarding surface.
6. Continue expanding evaluation coverage for common problems such as codecs, Packman vendor changes, Wi-Fi and Bluetooth, Btrfs snapshot disk usage, and failed systemd services.

OBS images from home projects are already published to registry.opensuse.org, so development can continue in the current home project. An appropriate long-term development project, potentially an AI-assistant or AI-containers namespace, is being discussed with the openSUSE infrastructure team.

The project has reached the point where the assistant itself works. The second half is about making it an openSUSE feature that users can install, start, diagnose, and use offline without knowing how its model and retrieval stack are assembled.

Thanks to my mentors, Rudraksh Karpe and Satyam Soni, and to the openSUSE community members who have provided the Leap VM, documentation pointers, packaging guidance, and feedback on the live demo.

We started this Google Summer of Code project with a simple question: can a new openSUSE user get useful, system-specific help without sending their questions or machine information to a cloud service?

The idea was to combine a Small Language Model (SLM) running on the user’s machine with retrieval over official openSUSE documentation. Instead of giving generic Linux advice, the assistant should know that the machine is running Leap, whether it uses Btrfs and Snapper, which GPU is installed, and which services have failed. It should then explain tools such as zypper, YaST, Snapper, and firewalld using the documentation that applies to that system.

At the midterm point, that core loop is working on an openSUSE Leap 16.0 VM. The assistant runs locally, retrieves openSUSE documentation from a local LanceDB index, reads selected host context, and is available through both a command-line interface and a web UI. More importantly, it now runs from an openSUSE BCI-based container built by the Open Build Service (OBS), including on a VM with no outbound internet access.

• Source repository
• GSoC proposal
• Public Leap VM demo
• OBS package

From a Small PoC to a Real Leap Deployment

Before GSoC, the project used TinyLlama, ChromaDB, and a small set of documentation to prove that the basic architecture was possible. That was enough for a demo, but not enough to answer the questions that matter for a distribution feature: Which model works well on CPU-only hardware? How is the assistant installed? What happens when the target machine cannot download a model? Can a container inspect the host without being given unnecessary privileges?

The mentor-provided test VM made these questions concrete. It runs Leap 16.0 with 4 vCPUs and 15 GB of RAM, has no GPU, and cannot access the internet. This is a useful target because it prevents an accidental dependency on cloud APIs or a developer’s already-populated cache.

The current request path is:

1. The user asks a question in the CLI or Gradio web UI.
2. The assistant reads relevant, non-sensitive system facts from the host.
3. MiniLM embeddings retrieve matching chunks from a local LanceDB index.
4. The system prompt combines the question, host context, and retrieved sources.
5. A local GGUF model generates the answer through llama.cpp.
6. The answer includes references to the documentation used.

The index currently contains 1,982 chunks from the Leap Startup and Reference guides, Leap 16.0 release notes, and selected openSUSE wiki SDB pages. The SDB set includes common areas such as repositories, upgrades, audio, and NVIDIA driver and SUSE Prime troubleshooting.

Model Selection Needed Measurement, Not Guesswork

One of the first tasks was replacing TinyLlama with models that could produce reliable administration guidance while still running on ordinary hardware. We added model tiers and benchmarked six GGUF models through the complete RAG and system-context pipeline on the Leap VM.

Each model answered the same eight openSUSE onboarding questions. Generation ran offline on the VM, while judging ran separately against saved answers using Gemini 2.5 Flash-Lite, reference answers, and expected-fact checklists. Separating these steps meant the slow CPU generation did not need to be repeated when the scoring method changed.

The benchmark used the same constrained target as the public deployment: 4 vCPUs, 15 GB of RAM, no GPU, and no network access during generation. Latency below is the average time for one complete answer, including retrieval and the prompt built from the retrieved documentation and host context.

[

Higher and further left is better. Qwen3-4B achieved the highest judged quality; Gemma 4 E4B is the current default and answered about 30 seconds faster. The orange ring marks the current default.

The results showed that a larger model is not automatically a better default. Qwen3-4B scored slightly higher than Qwen3-8B and answered about 30 seconds faster. Gemma 4 E4B offered a useful latency/quality trade-off and is currently the default standard model following mentor discussion. Qwen3-1.7B remains a practical option for lower-resource machines, while TinyLlama is useful only for smoke tests.

The full methodology and per-model discussion are in the evaluation report.

These timings also changed the web UI. A 70-120 second answer can look like a hung application if the interface says nothing. The UI now identifies the selected tier, explains that the model is loaded on the first question, shows elapsed generation time, and reports missing model or index data more clearly.

Offline Means More Than Running the Model Locally

The largest lesson so far is that local inference and offline installation are two different problems.

Once downloaded, a GGUF model can run without a network connection. A usable assistant, however, also needs the embedding model, Python and native libraries, the documentation index, configuration, and compatible file ownership. The VM’s lack of internet access exposed every hidden download quickly.

To make the state visible, we added suse-assist doctor. It checks model files, the vector store, the embedding cache, memory and disk availability, host mounts, offline environment settings, the web port, and the container runtime. We also added suse-assist setup to select a tier, prepare the model and index, optionally import offline data, and run the final checks.

For machines that cannot download assets during setup, the project now has an offline bundle format:

suse-assist bundle export --output suse-assist-offline-bundle.tar.zst
suse-assist bundle import suse-assist-offline-bundle.tar.zst

A bundle contains a selected GGUF model, the MiniLM cache, the LanceDB index, and a manifest with checksums. The import/export commands and firstboot import path are implemented. Producing a release bundle from the VM data and testing it through a complete OEM first boot is one of the next tasks. The final distribution policy is still open: the data could be part of a KIWI image, an RPM payload, a separate artifact, or a firstboot download for connected systems.

Moving the Build into the openSUSE Infrastructure

The first container image was useful for testing, but it was not built in the same way an openSUSE deliverable should be. The container now starts from the SUSE BCI Python base and uses zypper for system dependencies.

The next issue was dependency availability. OBS builds in a clean, offline build environment, while several parts of the Python ML stack are not currently packaged as openSUSE RPMs. This includes important pieces around llama-cpp-python and LanceDB. To test the rest of the path without waiting for all dependency packaging, we built an OBS prototype with an approximately 467 MB wheelhouse. It installs the Python dependencies with pip --no-index, including a locally built llama-cpp-python wheel.

That experiment now builds the real assistant image in home:anujagrawal:suse-assist/suse-assist-image and publishes it as:

registry.opensuse.org/home/anujagrawal/suse-assist/images/opensuse/suse-assist:latest

The Leap VM cannot pull from the registry, so we tested the actual offline delivery path: download the OBS image archive on a connected machine, checksum it, copy it over SSH, load it with Podman, and run it against the prepared data volume. This found a real ownership mismatch, which was fixed by assigning the container’s suseai user a stable UID and GID of 999. The public demo now runs this OBS-built image rather than the earlier local build.

On that VM, suse-assist doctor, web startup, test-tier inference, and standard Gemma 4 E4B inference have all been exercised. A standard-tier answer to “What is zypper?” took about 70 seconds and included retrieved references.

The vendored wheelhouse proves that OBS can build and publish the container. It is not automatically the final packaging answer. The open question is whether this is acceptable as a short-term container solution or whether each missing dependency should be packaged as a proper RPM before the assistant moves beyond a home project.

Preparing for First Boot and Daily Use

Distribution integration should not require users to know a container command. The repository now includes the first scaffolding for a KIWI OEM image, a Podman Quadlet unit, and a firstboot service that prepares the assistant’s data and starts the web service. There is also a native systemd service setup path for a future RPM install, plus a desktop launcher that opens the local UI.

These pieces define how the assistant could be presented as a normal openSUSE feature, but they are not the same as a completed installer integration. The full KIWI image and offline firstboot flow still need end-to-end validation. Integration with Agama or jeos-firstboot also needs to follow the packaging and data distribution decisions rather than hard-code a temporary deployment method.

We also added an MCP server and client proof of concept. The server exposes system context and documentation search as tools, while the client can connect the assistant to external MCP servers. This is not required for the basic onboarding flow, but it shows that the openSUSE-specific context and retrieval work can be reused by other local applications.

Safety Is Part of the Interface

System administration answers have more impact than ordinary chatbot responses. Retrieved web pages are therefore treated as untrusted context: instructions inside the retrieved text must not override the system prompt. The assistant cleans hidden reasoning markers, asks for documentation references when recommending commands, and adds warnings around destructive operations and repository vendor changes.

The container runtime also uses a non-root user, dropped capabilities, a read-only root filesystem where possible, resource limits, and a health check. Host system context is mounted read-only. These controls do not make generated advice infallible, but they reduce the authority of the process and make risky advice more visible to the user.

What Changed from the Proposal

The original midterm plan placed more emphasis on completing a jeos-firstboot module and systemd socket activation by this point. The core assistant, model tiers, RAG expansion, system-context work, and Agama integration research are in place, but the VM changed the order of the remaining work.

An onboarding assistant that works only after a developer manually populates model and embedding caches is not ready for first boot. We therefore moved some packaging and offline-distribution work forward: the BCI migration, OBS build, registry publication, setup and doctor commands, bundle format, and offline VM validation. The firstboot integration is now being built on top of a deployment path that has actually run on Leap without internet access.

This was a useful correction to the plan. The main difficulty is not writing one more chat interface. It is delivering several gigabytes of model data and a native ML dependency stack through normal distribution infrastructure, then making the result understandable on machines with very different resources.

Plans for the Second Half

The next part of the project will focus on closing that delivery gap:

1. Build a real offline data bundle from the VM and test bundle import through the OEM firstboot path.
2. Settle the short-term OBS dependency approach: vendored wheels or proper RPMs for the missing ML stack.
3. Produce and validate an installable RPM on a clean Leap system.
4. Decide how model weights and the generated documentation index are distributed, including licensing and image-size implications.
5. Complete the KIWI/firstboot path and connect it to the appropriate openSUSE onboarding surface.
6. Continue expanding evaluation coverage for common problems such as codecs, Packman vendor changes, Wi-Fi and Bluetooth, Btrfs snapshot disk usage, and failed systemd services.

OBS images from home projects are already published to registry.opensuse.org, so development can continue in the current home project. An appropriate long-term development project, potentially an AI-assistant or AI-containers namespace, is being discussed with the openSUSE infrastructure team.

The project has reached the point where the assistant itself works. The second half is about making it an openSUSE feature that users can install, start, diagnose, and use offline without knowing how its model and retrieval stack are assembled.

Thanks to my mentors, Rudraksh Karpe and Satyam Soni, and to the openSUSE community members who have provided the Leap VM, documentation pointers, packaging guidance, and feedback on the live demo.