For many years, syslog-ng used Java, where C libraries were unavailable. However, over the years native C libraries became available for Elasticsearch and Kafka, and HDFS practically disappeared. As a “scream test”, I am going to disable Java support in all of my syslog-ng packages.

Once upon a time, Java support was added to syslog-ng to be able to load Elasticsearch Java drivers. Later, Kafka, HDFS, and a generic HTTP destination were also added. Unfortunately, using Java was a major pain. Loading libraries required some manual configuration. Packaging the Java destination in official Linux distribution packages was possible, however, packaging the actual drivers written in Java was impossible. For a while, I maintained unofficial packaging for these drivers, but as C alternatives appeared, I removed these components. Nobody complained. Recently all drivers, except for HDFS, have been removed from the source code as well. Again: nobody complained.

Right now, we still have HDFS support in the source code, but not for long. I have been posting about it for years now, and nobody asked us to keep it. This is the last driver making use of the Java destination of syslog-ng. We will delete it soon, too.

We do not delete code related to Java right now. However, as a “scream test” I am going to disable the Java destination in all my packages. I have done it already in the official openSUSE syslog-ng package. Fedora Rawhide is next. I will also remove it from my git snapshot packages.

If you use Java with your own driver code, let us know! Otherwise, the Java destination will be not just disabled in packages but removed from code as well.

More Space

openSUSE moved to BLS some time ago using the bootloaders systemd-boot and GRUB2-BLS that nowadays is mostly a repackaging of the traditional GRUB2, as the main patches are already merged since 2.16.

This decision also required more space in the ESP partition, as now the kernel and initrds of all snapshots are stored in /boot/efi/$TOKEN, where $TOKEN can be the machine-id, opensuse-tumbleweed or opensuse-microos, depending on the installation. For new installations, this is not a problem since the installer (YaST or Agama) will recommend a large (1 GB) partition; for older installations, the migration can be problematic, to the extreme that if the partition cannot be resized. It is advisable to keep the old GRUB2-EFI bootloader.

But if we decide to use systemd-boot, there is a escape hatch: XBOOTLDR

A New Partition

XBOOTLDR is a new partition that can live anywhere in the disk. The ESP has some limitations in that regard, and usually is the first partition in the system. If present, systemd-boot will look for the menu entries and the kernel / initrds in there, freeing the ESP of that responsibility.

The file system of this partition needs to be also FAT32, like the ESP as this is a limitation of the UEFI, and during the creation needs have a specific GPT identifier (GUID). With fsdisk, we can create a new partition and assign the type 142 or xbootldr; this will assign the correct GUID into the partition table and systemd-boot will recognize it.

Mount Points

Because of this new partition, the mount points needs to change too. As commented, the traditional place where openSUSE put the ESP is in /boot/efi but now we have two places. The UAPI recommendation is to have always the boot entries and the kernel in /boot, and only if there is a separated partition for the boot loader, then this will be placed in /efi. Because this is the case now, we will need to update out /etc/fstab:

UUID=4165-E891 /efi  vfat utf8,dmask=0077,noexec,nodev,nosuid,nosymfollow 0 2
UUID=414C-528C /boot vfat utf8,dmask=0077,noexec,nodev,nosuid,nosymfollow 0 2

Change the UUID to point to the correct device.

sdbootutil can find both partitions and write in the correct place now, depending if we are updating the bootloader or adding new entries.

Now we can move the boot entries and the kernel directories, both placed in the old /boot/efi/loader path. We can manually move it into the new partition, just keep loader/random-seed and loader/loader.conf in the old place, but the rest of the loader/ directory can be moved.

More information about a more detailed description can be found in the following section:

Further Documentation

• Migrating from GRUB2-EFI
• MicroOS FDE
• UAPI.1 The Boot Loader Specification

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.