In my previous post I covered the template refactor for the obs-status-service SVG generation. That work was reviewed and merged into main (PR #364). Building on top of that, I’ve opened a follow-up PR (#402) that focuses on two things: making the SVG badges visually consistent with Gitea’s UI and making them responsive for large projects.

Native Gitea Colors

The old SVGs used hardcoded colors that looked out of place next to Gitea’s UI. I extracted the real CSS variables from Gitea’s dark and light themes and embedded them directly into the SVG templates. Now the badges blend in naturally with the rest of the page, and they automatically switch between light and dark mode using the ?theme= parameter.

Responsive Compact Mode

The project matrix view works great when there are a few repositories, but some projects like openSUSE:Tools have dozens of repo/arch combinations. The full matrix becomes too wide for any screen.

To solve this I added a ?compact=true|false|auto parameter. In compact mode:

• Column headers are rotated 90° to take up less horizontal space.
• Badge text is hidden, leaving only colored squares.
• Column width shrinks from 155px to 32px.

The auto mode (the default) activates compact mode automatically when the matrix would exceed 800px wide or when there are more than 4 repositories. This is calculated server-side before generating the SVG, since CSS @media queries cannot resize an SVG’s viewBox when it’s embedded as an <img>.

Dynamic Layout

Long package names like 000product:openSUSE-Addon-NonOss-ftp-ftp-x86_64 used to overflow and overlap with the status cells. Now both the label column width and the header height are calculated dynamically based on the longest text string, so nothing gets cut off regardless of the data.

Side-by-side Comparisons

To verify the improvements, I wrote a Go test that fetches live build data from the OBS public API and generates SVGs with both the old production code (downloaded via HTTP from br.opensuse.org) and the new template-based renderer. Here are some examples using the projects my mentor dgarcia suggested:

Project Summary: devel:languages:python:Factory

obs-status-service (old):

obs-status-service (new):

Package: devel:languages:python:Factory / python313

Before:

After:

Badge: openSUSE:Factory / python313:base / standard / x86_64

Before:

After:

Matrix View: devel:languages:python:Factory

gitexplorer (interactive):

obs-status-service (new):

What’s Next

The template refactor PR #364 has been merged into main. The Gitea color integration and compact mode are in review in PR #402.

The next step is exploring JavaScript inside SVGs so that badges can update themselves in real time without reloading the page.

Infrastructure runs on Linux, and Linux hardware is only as good as the software that builds, packages, signs and distributes its drivers and libraries, work that has to happen across dozens of distributions and several CPU architectures, every single day.

That work has a home. The openSUSE Project has spent years assembling a development structure that hardware vendors and enterprises now lean on:

• Open Build Service compiles a single source tree into signed packages for nearly any distribution or architecture;
• openQA boots and tests the results the way a real user would;
• The rolling release Tumbleweed and stable Leap distributions serve as both upstream and supporting structure for Enterprise as a proving ground and downstream anchor;
• Uyuni Project, the upstream of SUSE Multi-Linux Manager pioneers the space that keeps deployed fleets patched and accounted for long after the packages ship.

Together, these answer the question every hardware maker eventually faces; build once, validate everywhere and deliver with confidence.

Companies whose revenue depends on silicon “just working” in Linux data centers may evaluate funding this layer as an investment, not as charity. It is one of the highest-leverage, lowest-cost investments available. But communities like openSUSE depend on sponsors so that the contributing community can grow, support and thrive.

SUSE is the primary sponsor of openSUSE, and the project has other companies that sponsor the project. The project welcomes additional backers. Sponsorship takes three practical forms; money, hardware, or services. Sponsorship has historically been organized into tiers: Platinum, Gold, and Silver. The sponsors gain visibility and developer reach. Hardware sponsors sign an Equipment Donation Agreement. Services provided to contributing developers make development more efficient. And the Geeko Foundation, a not-for-profit, acts as fiscal steward, receiving and administering funds on the project’s behalf to support contributors, travel and events.

The return on a sponsorship

1. The whole ecosystem, not just one distro

OBS builds on the order of 140,000 packages for more than a dozen base distributions across many architectures. A vendor that donates silicon and sponsors build capacity gets its drivers and libraries built and validated across that entire matrix; Fedora, Debian, Ubuntu, the SUSE family and more.

This is not a static archive. In a typical week, Tumbleweed absorbs on the order of 500 accepted change requests, moving Mesa, the Linux kernel, QEMU, GCC, LLVM, Rust, GNOME and KDE forward in lockstep. Paying engineers to chase each target distribution independently is expensive; the same result comes far more cost-effectively from developers already working inside the openSUSE ecosystem. Hardware that works on Linux ships and sells faster.

2. Silicon QA at scale

Packaging is only half the problem; the other half is testing. That is where openQA comes in; openSUSE’s automated OS-testing service, which boots real images and drives real installs.

Pair it with sponsored hardware and a vendor’s drivers get exercised continuously: every snapshot, every architecture, in front of tens of thousands of real users doing unpredictable things. The value shows in the ordinary weekly record; compiler transitions caught in dedicated staging projects before they reach users, individual test failures tracked down to a specific step in a specific run, unresolvable dependencies counted and driven back down. Regressions surface on actual silicon earlier, and far more cheaply, than any internal lab could manage.

3. Growing the architecture your chips are trying to sell

openSUSE does not treat arm as an afterthought. Tumbleweed on arm rolls continuously alongside x86, with its own openQA coverage, and a dedicated ARMv9 project rebuilds the core of the distribution to take advantage of the newer baseline. s390x is maintained in parallel. A chipmaker sponsoring arm build capacity is directly cultivating the soil its own products grow in. And would be doing it where the architecture is already a first-class citizen rather than a port.

4. Faster driver delivery, fewer support tickets

The model already exists: openSUSE’s NVIDIA driver packages are maintained by SUSE engineers, with spec files living in OBS and coordinated with NVIDIA. A factory first policy, where development happens upstream, deepens that relationship. Dedicated hardware, closer coordination and sponsored maintainer time all shorten the lag between a driver release and users actually being able to install it. Every week shaved off that cycle is support load a vendor never has to absorb.

5. Strategic influence on neutral ground, without lock-in

OBS, openQA and Uyuni are deliberately vendor-neutral. None is tied to a single vendor’s product line; all three build, test and manage systems well beyond the SUSE family. For a chipmaker, neutrality is the point; sponsorship keeps the packaging pipeline healthy and open, so no single competitor ends up controlling how silicon reaches Linux.

Uyuni is upstream of SUSE Multi-Linux Manager, and that relationship cuts the way a sponsor should want: the upstream project sets direction and the commercial product follows, not the reverse. It’s the same arrangement that governs most of the Linux stack a vendor already ships on. A sponsor influences the open project and gets the benefit downstream, without buying into any vendor’s roadmap.

6. Developer mindshare, ISV reach, and recruiting

Sponsorship has always carried visibility in front of the developers and independent software vendors who decide what runs where. In a labor market where kernel, driver and systems talent is scarce, presence in the openSUSE community is a recruiting channel and a credibility signal to the wider open-source world.

The bottom line

Put these together and you get a flywheel of mutual benefit. The technology gets built by the community at a fraction of what in-house enablement would cost, and it gets built continuously, in public, with the failures visible and tracked rather than discovered by a customer. The community gets what it needs to keep going: travel to the conferences where the work gets shared, hardware to test on, and infrastructure that grows as fast as the ideas do.

For a business valued in the hundreds of billions, an equipment donation or a sponsored service is a rounding error. It is also one of the cleanest ways a company can fund the building of the technology it sells build on open-source. Donations acknowledging community efforts are also encouraged.

If you are interested in sponsoring openSUSE, we are open to options or suggestions.

Providing space for hosting an openSUSE event or sponsoring the openSUSE Conference provides a unique opportunity to connect with open source users, system administrators, developers, designers, and community leaders. Sponsoring the conference also provides an opportunity to showcase your brand to the open-source knowledge.

For more information, email ddemaio@opensuse.org.

Dear Tumbleweed users and hackers,

This week was quite busy and successful, with 5 snapshots (0709, 0710, 0712, 0714, and 0715) published to our users.

Last week, we promised to put selinux-policy back into the queue after having temporarily reverted it to bypass the openQA failures, and we did just that. It turned out our theory was spot-on! In snapshot 0714, the SELinux Toolchain 3.11 landed, and confirmed our dependency fix for rpm-plugin-selinux was correct

Another noteworthy change is the reversion of the gvim GTK4 build back to GTK3. While we strive to ship the latest technology, the current state of the GTK4 port simply does not live up to the quality promises we give to our users, resulting in clipboard deadlocks. Thus, we chose stability over the shiny new build.

These five snapshots delivered the following updates:

• SELinux Toolchain 3.11 (together with selinux-policy)
• KDE Frameworks 6.28.0
• QEMU 11.0.2
• GStreamer 1.28.5
• Vim 9.2.0780
• PipeWire 1.6.8
• freetype 2.14.3
• poppler 26.07.0
• curl 8.21.0
• git 2.55.0
• BusyBox 1.38.0
• php 8.5.8
• postfix 3.11.5
• timezone 2026c
• kernel-firmware 20260710
• Rust 1.97

Let’s take a look at what we can expect in the coming days and weeks.

• KDE Plasma 6.7.3
• systemd 261.1
• Perl 5.44.0
• linux-glibc-devel 7.1: Last holdup at this time is llvm (15 – 21)
• Podman 6.0.0: Undergoing integration and sync testing with buildah and skopeo. Staging seems to pass, but for this stack we also get some manual testing
• GCC 16 as the default system compiler. If my eyes don’t deceive me, qemu seems to be the last package failing to build

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 July 10 to 16.

Blogs this week cover the third Plasma 6.7 bugfix release, a SUSE security advisory on SELinux userspace utilities, a call for host proposals for the openSUSE.Asia Summit 2027, syslog-ng packages for Ubuntu 26.04, a keynote recap on open source trust and the Cyber Resilience Act, audio recording arriving in Spectacle, a Meteoclimatic desktop plasmoid, a Krita June development report, Slimbook’s local AI workstation and more.

Here is a summary and links for each post:

Display the Meteoclimatic data on your desktop with this Plasmoid for Plasma 6 from KDE

Victorhck shares information about Plasma 6 plasmoid that visualizes Meteoclimatic weather station data directly on the desktop. Building on an earlier text-mode plasmoid and terminal scripts, this version presents the data with emoji icons for a more elegant and visually appealing display. Victorhck invites users to share screenshots of their configurations on Mastodon.

Nexus AI Workstation, the proposal to have local AI free on Slimbook

The KDE Blog presents Slimbook’s Nexus AI Workstation, a server family designed for running local AI workloads without relying on cloud token subscriptions. The goal is to offer a platform prepared for executing and developing AI workloads locally, combining high performance with the flexibility professionals, companies, researchers and developers demand.

Krita Report June 2026

The KDE Blog covers the June 2026 Krita development report, highlighting releases 5.3.2.1 and 6.0.2.1 that fix severe regressions related to layer selection and crashes when working with wait frames. Krita Plus for Android replaces old contributor badges with downloadable resource packs and a Google Play subscription, along with improved interface scaling, transform tool fixes with multiple layers, and crash fixes when undoing text operations.

Third Bugfix Update for Plasma 6.7

The KDE Blog announces the third bugfix release for Plasma 6.7, delivering stability improvements, better translations, and error resolution across the desktop environment. The post also recaps the major new features of Plasma 6.7, including per-monitor virtual desktops, a microphone volume test tool, quick theme switching, a Vietnamese lunar calendar, and a new print queue manager.

SELinux Userspace Utilities: Local Denial-of-Service Attack Vectors in seunshare

The SUSE Security Team discloses two local denial-of-service vulnerabilities in the seunshare program from SELinux userspace utilities version 3.10. A symlink race condition in rm_rf() allows deletion of root-owned files, while the killall() function can be exploited to kill root-owned processes running in the unconfined SELinux domain. Both issues were independently fixed upstream in version 3.11.

openSUSE.Asia Summit 2027: Call for Host

openSUSE News invites local openSUSE communities across Asia to submit proposals to host the openSUSE.Asia Summit 2027. The proposal deadline is August 10 with the host announcement scheduled for October 31 following presentations at the 2026 summit in Yogyakarta, Indonesia. Proposals should cover venue, transportation, budget, catering, and the local organizing team’s experience.

Syslog-ng 4.12.0 Available for Ubuntu 26.04 (Resolute)

Peter Czanik’s Blog confirms that syslog-ng now supports Ubuntu 26.04 with ready-to-use packages alongside the 4.12.0 release. The post fills a gap in his usual coverage, which tends to focus on FreeBSD, Fedora and openSUSE.

Bare Weather – Weather Information on Your Desktop with Plasmoids for Plasma 6 (35)

The KDE Blog presents Bare Weather, the 35th entry in its Plasma 6 plasmoid series, which delivers interactive weather data directly on the desktop. The widget by corral76 offers two layouts: a card design with animated icons and color-coded headers, and a graph design with scrollable temperature and precipitation curves.

Bash and Fish Scripts to Display Meteoclimatic Weather Station Data

Victorhck shares Bash and Fish terminal scripts that display real-time weather data from Meteoclimatic amateur stations. The scripts use curl and awk with emoji icons to present the information, and the first run prompts for a station ID which is saved to a config file.

This Month in KDE Linux: June 2026

The KDE Blog translates Nate Graham’s monthly progress report on KDE Linux, the community’s upcoming operating system. The project has reached 78 percent completion toward its beta milestone. Updates include Audex replacing the old CD ripping tool, a built-in log collection utility, and UEFI-only boot support.

When the Code Remains Clean but Trust Collapses: The New Era of Open Source

Efstathios summarizes the openSUSE Conference 2026 keynote by Hans de Raad on the intersection of open source security, the Cyber Resilience Act, and AI tooling risks. The post examines the GSD framework incident where clean code masked a collapsed trust chain, drawing parallels to the xz-utils backdoor.

Audio Recording in Spectacle – This Week in Plasma

The KDE Blog translates Nate Graham’s weekly Plasma development update, which highlights audio recording arriving in Spectacle for screen captures in Plasma 6.8. The update also covers VRAM usage display in System Monitor, the Ethiopian calendar addition, improved combobox theming, tablet stylus support for Overview overlays, and numerous bugfix releases across Plasma 6.6.6, 6.7.3, and Frameworks 6.29.

Linux Saloon 209 | Fedora 44

Nathan’s Blog covers the latest Linux and technology news, including the Warthunder Sim Rig hardware build, font management in Linux, and the retirement of the “Father of the Internet.” The episode also discusses Firefox updates, the Steam Machine launch, and Fedora governance changes alongside the Fedora 44 release.

KDE Frameworks 6.28.0 Update

The KDE Blog announces KDE Frameworks 6.28 and continues its series describing each library in the framework collection. This month focuses on KCodecs, a Tier 1 library responsible for character set detection, XML entity translation, and email address validation across KDE applications.

Colors, Graphics, and Performance in Plasma 6.7

The KDE Blog covers the under-the-hood improvements in Plasma 6.7 related to color management, graphics rendering, and energy efficiency. Users can now use ICC color profiles and HDR content simultaneously. There is a new toggle to control reddish tinting at low brightness on AMD laptops. The team also achieved performance gains and reduced power consumption for CPU-rendered applications and Intel integrated GPUs.

openSUSE Tumbleweed Review of Week 28 of 2026

Victorhck and Dominique Leuenberger provide a Spanish and English language review of four Tumbleweed snapshots (0702, 0703, 0707, and 0708) published during the week. Highlights include the removal of Python 3.11 modules while keeping the interpreter and pip, KDE Gear 26.04.3, Plasma 6.7.2, Linux kernel 7.1.2 and 7.1.3, Mesa 26.1.4, and systemd 260.3. Upcoming packages include GStreamer 1.28.5, SELinux toolchain 3.11, and GCC 16 as the default compiler.

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

Table of Contents

• 1) Introduction
• 2) Design Overview
• 3) Security Issues
  • 3.1) Local File Deletion Attack Vector in rm_rf() (CVE-2026-59676)
  • 3.2) Process Kill Attack Vector in killall() (CVE-2026-59677)
• 4) Remaining Concerns
• 5) CVE Assignments
• 6) Timeline
• 7) References
• 8) Change History

1) Introduction

The seunshare program is part of the SELinux “sandbox” feature, which is used to confine untrusted programs using Linux mount namespaces and restrictive SELinux policies. The program is designed to be installed with setuid-root privileges, accessible to all users in the system.

We have been asked to review the program’s security with the intention of assigning the setuid bit to it on SUSE distributions in the future. Fedora Linux already ships this program with setuid-root enabled; other SELinux-enabled Linux distributions may do so as well.

During our review of the utility’s code in version 3.10 of the SELinux userspace utilities we identified two local Denial-of-Service attack vectors, which will be described in detail in the following sections. Upstream independently fixed these issues in version 3.11, without clearly marking them as security issues, however.

The rest of this report is based on version 3.10 of the codebase of seunshare.

2) Design Overview

The seunshare program is relatively small, consisting of about 1,000 lines of C code. The elevated root privileges are primarily needed to setup a custom mount namespace for the sandbox environment.

The program accepts a range of command line arguments which, among others, allow to request dedicated directories to be used for the following paths inside the sandbox:

• the user’s home directory.
• the /tmp directory.
• the /run/user/<uid> directory.

For the /run and /tmp directories, the source paths specified by the user are copied into a random temporary directory in the initial mount namespace under /tmp/.sandbox-<label>-XXXXXX using the rsync program. These directories are then bind-mounted into the sandbox’s mount namespace to appear at the expected locations.

A lot of code in seunshare is concerned with securely maintaining these temporary directories. To allow the sandbox environment to modify the directory contents, seunshare assigns group write permissions for the real group ID of the calling user, as shown in this example:

drwxrwx--T. 2 root user 80 Jul  8 16:11 /tmp/.sandbox-user-OaxmUp/

To safely access user-provided paths, the program flips its filesystem UID to the real UID of the calling user and back to root, as needed.

3) Security Issues

Since seunshare is supposed to run on SELinux-enabled systems, it is important to understand what kind of privilege escalation can be achieved when vulnerabilities are exploited in a setuid-root binary like this. Many SELinux-enabled systems, such as Fedora and openSUSE, ship with the “targeted” SELinux policy by default. This policy is focused on confining well-known system services, but assigns an unconfined SELinux context to interactive users by default to achieve a balance between security and usability.

There is currently no domain transition from the unconfined domain to the more restricted seunshare_t defined in the SELinux policy for seunshare. This means the execution of seunshare continues in the unconfined domain. Thus in the context of attacks carried out by interactive users, the impact of the vulnerabilities below will be a root-like privilege escalation despite the system running in SELinux enforced mode.

3.1) Local File Deletion Attack Vector in rm_rf() (CVE-2026-59676)

The function rm_rf() is called at the end of the utility’s execution to recursively remove temporary directory trees. While a comment in the function suggests that no symbolic links would be followed by this routine, the reality is that the openat() system call is lacking the O_NOFOLLOW flag. This creates a race condition during the recursion of the rm_rf() function:

• first an fstatat() is performed for directory contents obtained from readdir() to safely determine whether an entry refers to a sub-directory.
• when a directory is encountered the unsafe openat() happens, allowing the unprivileged user to replace the directory entry by a symbolic link in the meantime. While the O_DIRECTORY flag is passed to openat(), symbolic links in the target are still followed, as long as they point to a directory.

When the user calling seunshare is running in the unconfined SELinux domain, arbitrary root-owned files can be deleted this way. The vulnerability does not allow to delete arbitrary files of other users, however, because seunshare drops all capabilities before calling rm_rf(). This leaves the process in a somewhat strange state of privilege: it can no longer override discretionary access control (DAC) but it is still allowed to operate on files owned by the filesystem-uid of the privileged process, which is 0 during the invocation of rm_rf().

We developed a reproducer for this issue, which succeeds in executing the exploit quickly after some fine tuning of the timing for the target system. We verified that the reproducer works on current openSUSE Tumbleweed with policycoreutils 3.10 and the setuid-root bit enabled on seunshare. It does not work on current Fedora 44, as it seems Fedora backported a patch to fix this issue (it passes O_NOFOLLOW to the openat() call in question).

Upstream fixed this issue in commit 38f0a4d9a which is part of of the 3.11 upstream release.

3.2) Process Kill Attack Vector in killall() (CVE-2026-59677)

seunshare offers --kill and -Z switches as documented in its man page:

-k --kill
       Kill all processes with matching MCS level

-Z context
       Use alternate SELinux context while running the executable

Both switches combined cause the killall() function to kill all processes running with the user-provided SELinux context. This does not fully work for arbitrary target processes due to SELinux access control; however, if the calling user is running in unconfined context (as explained previously) it allows to kill e.g. root-owned processes running also in unconfined context. Once the algorithm reaches its own PID (if the context matches), it kills itself, thus it is possible that only a certain range of PIDs can be killed this way depending on the PID selection order of the algorithm in killall().

We have been able to reproduce the issue both on openSUSE and on Fedora 44 using a command line like this:

seunshare --kill -Z unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 -t ~/some-dir/ -- /usr/bin/true

Upstream fixed this issue by dropping the --kill switch and the killall() function in commit 572db2fa.

4) Remaining Concerns

The code of seunshare has seen major changes between version 3.10 and 3.11 of the SELinux userspace utilities. The new version of the program improves on various aspects of the code; generally the code shows awareness of various filesystem-related security concerns that are relevant for setuid-root binaries. Still a number of concerns remain:

• Data which is modified in temporary directories within the sandbox is transparently copied back into the calling user’s source directory via rsync. Since the program is untrusted it can potentially create all kinds of dangerous files, which will now reside e.g. in the user’s regular home directory and could lead to security issues at a later time when accessed without care.
• The code flips the filesystem UID a lot to temporarily drop root privileges for file operations. This logic is hard to follow in parts and leaves the process in an unusual state of privilege, as the effective UID is still 0; during the first stages of the program it also still has all capabilities. Due to the filesystem UID being set to the real user’s UID, file operations are carried out using the calling user’s lower privileges, however. From a design point of view it would be preferable to let the process operate in an unprivileged state by default (effective UID and GID set to the real UID and GID). Privileges could then be raised for the few operations that actually need root privileges.
• The code currently lacks some common security precautions for setuid-root programs:
  • while a new environment variable block is set up to execute the untrusted target program, the privileged parent process keeps the untrusted environment variables of the calling user in place. These are also inherited to tools like rsync that are invoked for the purposes of setting up the sandbox. While this is not an issue at the moment, it could turn into a security issue at a later time when the code changes.
  • the umask() of the process is also kept unchanged, inheriting whatever the unprivileged parent process configured. This can cause files to receive world-readable or world-writable bits leading to unexpected attack vectors.

5) CVE Assignments

We approached the upstream SELinux userspace utilities developers and suggested to assign CVEs for the two issues discussed above. Upstream informed us that they don’t take care of CVE assignment themselves, however. Since Red Hat developers are also involved with upstream development, we were waiting for an agreement on who will assign CVEs to avoid duplicates. On 2026-07-17, after the initial publication of this report, we received a response that there is no intention by RedHat developers to assign CVEs. As a result we assigned CVEs on our end as documented in the updated blog post.

6) Timeline

7) References

• SElinux userspace utilities bugfix release 3.11
• SELinux userspace utilities Github project
• vulnerable seunshare code in upstream release 3.10
• Reproducer for the file delete issue

8) Change History

openSUSE.Asia Summit 2027: Call for Host

The openSUSE.Asia Summit is an annual conference that brings together openSUSE contributors, users, and Free and Open Source Software (FOSS) enthusiasts from across Asia. It provides a unique opportunity for the community to meet in person, exchange ideas, share technical knowledge, and strengthen collaboration.

As the openSUSE.Asia Summit 2026 will be held in Yogyakarta, Indonesia, the openSUSE.Asia Organization Committee is now inviting local openSUSE communities to submit proposals to host the 2027 summit.

Hosting the summit is a rewarding opportunity to showcase your local community, promote open source technologies, and connect with contributors from across Asia. The organizing committee will work closely with the selected team, providing guidance and sharing experiences from previous events throughout the planning process.

Important Dates

• 10 August 2026 — Proposal submission deadline
• 4 October 2026 — Host proposal presentation during openSUSE.Asia Summit 2026 in Yogyakarta, Indonesia
• 31 October 2026 — Announcement of the openSUSE.Asia Summit 2027 host

Applicants are encouraged to join our regular online meetings before the summit. This is a great opportunity to learn about the event organization process, ask questions, and interact with organizers from previous years.

How to Submit

Please send your proposal to both:

• summit@lists.opensuse.org
• opensuseasia-summit@googlegroups.com

Since summit@lists.opensuse.org does not accept email attachments, please upload your proposal to a file-sharing service (such as Nextcloud, Google Drive, or Dropbox) and include the download link in your email.

Proposal Guidelines

Your proposal should include at least the following information:

• Host city and venue
• Transportation
  • International access to your city
  • Local transportation to the venue
• Estimated budget
  • Venue
  • Catering (coffee break, lunch, dinner)
  • Conference dinner
  • Conference tour (optional)
  • T-shirts and event materials
  • Other operational expenses
• Local organizing team
  • Introduction to your local openSUSE community
  • Experience organizing conferences or community events
  • Expected volunteers and organizing structure
• Tentative event schedule
• Potential local sponsors or partners (optional but recommended)

Before preparing your proposal, please read the openSUSE.Asia Summit Tips for Organizers:

• https://en.opensuse.org/openSUSE:Asia_Summit_Tips_for_Organizers

We look forward to receiving your proposal and welcoming a new host community for openSUSE.Asia Summit 2027. We hope to see your community become the next destination for the openSUSE community in Asia!

Recently I was asked if syslog-ng supports Ubuntu 26.04 (Ubuntu Resolute). Yes, and with the arrival of the syslog-ng 4.12.0 release we also provide ready-to-use packages for it. The release notes mention it, and info is in the Readme on GitHub.

I tend to mention FreeBSD and openSUSE more often in my blogs (personal preference), so today I installed Ubuntu 26.04 and tested syslog-ng myself.

Read more at https://www.syslog-ng.com/community/b/blog/posts/syslog-ng-4-12-0-available-for-ubuntu-26-04-resolute