Member
CzPSyslog-ng repo for Amazon Linux 2023 updated to syslog-ng version 4.12
Two years ago, I created a syslog-ng repo for Amazon Linux 2023. As I received zero feedback, I left it alone until last week. The repo is now updated to the latest version of syslog-ng: 4.12.
According to Fedora Copr download stats, my Amazon Linux 2023 repo has many downloads. However, for over two years, I received zero feedback from the community, no matter how many GitHub, e-mail or social media posts I used to ask users about their experiences and requirements. As any kind of package maintenance needs some effort, I left the repo alone without updates.
Fast forward to last week: someone responded to my post on GitHub, asking for an update. So, once I got some idle time during a longer task, I updated the repo to syslog-ng version 4.12. During another break, I disabled Java support and slog, just as in any other repository we maintain.
As usual, you can find my Amazon Linux 2023 repo at https://copr.fedorainfracloud.org/coprs/czanik/syslog-ng-amazon23/ and share your feedback at https://github.com/syslog-ng/syslog-ng/discussions/4965
syslog-ng logo
Originally published at https://www.syslog-ng.com/community/b/blog/posts/syslog-ng-repo-for-amazon-linux-2023-updated-to-syslog-ng-version-4-12
Kudos August 2026
Welcome to our monthly report from the openSUSE Kudos recognition platform, where we take a moment to put a spotlight on the people who stepped up, helped others, and made this community a little brighter.
During the month of August 2026, 17 users received 24 kudos, and 419 badges were awarded to 251 contributors. You can see stats for this and previous months.
Spotlight
Top of the list in August: Bernhard Wiedemann (@bmwiedemann) with 5 kudos, more than twice what anyone else collected. Most of them (4) landed in Code & Engineering. That alone accounts for 5 of the month’s 24 kudos. Second place was a three-way tie at 2 kudos each: @bigironman, Gertjan Lettink (@knurpht) and Martin Schreiner (@mschreiner). Behind them, thirteen more people each picked up a kudo of their own, and all of them are listed below.
A milestone is worth stopping for: @dirkmueller, @jengelh, @krop and @pluskalm reached 100 Tumbleweed Contributions. That is the kind of steady, long-haul contribution that rarely makes headlines. Congratulations!
Not all of it is code, either. Documentation, translation, artwork, moderation and event work keep openSUSE usable and welcoming for everyone, and this month @aplanas, @bmwiedemann, @jimed-rand and @lkocman earned Wiki Contributor.
Kudos
Here are the thank-you notes themselves: 24 peer-to-peer kudos written by contributors about contributors, grouped by the person being thanked. The order follows the standings above, so August’s most recognized contributor opens the list.
From @levolet in Code & Engineering
“Thanks for all your great work in maintaining Slowroll. Your community spirit in thinking of it and creating it is also much appreciated.”
From @mdhup in Infrastructure Heroes
“Thank you for the work you do. Using slowroll has been a smooth experience. So much so that it ended my disro hopping. If it’s this good in beta, I can’t wait until it’s finished.”
From @PossiblePrinterPalace in Code & Engineering
“Thank you for the wonderful Slowroll. It has been my most pain-free Linux Desktop experience, in now more than 10 years of using different Linux distros.”
From @dnla in Code & Engineering
“Thanks for maintaining slowroll! Keep up the good work”
From @C7NhtpnK in Code & Engineering
“Thank you for offering Slowroll!”
From @lkocman in Support & User Assistance
“Many thanks for your quick help with re-branching the Leap-Images Wolfgang!”
From @lkocman in Support & User Assistance
“Thanks you for the help with the SPICE devel project for Leap 16.X Wolfgang!”
From @lkocman in Support & User Assistance
“Thank you for raising the concern with spamminess of kudos bot. Thanks to our discussion and the spamminess we actually met a new friend in /bar. So the spam from kudos-bot is actually useful. And we also get to reduce the spamminess”
From @C7NhtpnK in Support & User Assistance
“Thank you for help and assistance at forums.o.o!”
From @C7NhtpnK in Code & Engineering
“Thank you for maintaining LibreOffice!”
From @lkocman in Code & Engineering
“Martin, thank you so much for going the extra mile here! It would have been much easier to simply ship the same LibreOffice version from Factory in Leap, but instead you’re putting in the effort to maintain a separate version that better fits what users expect from a long-term stable distribution. That’s a lot of extra work behind the scenes, and I and many other users really appreciate your work to make Leap an even better LTS-style distro. Thank you! <3”
From @lkocman in Support & User Assistance
“Many thanks for your quick help on building an efficient query for OBS requests accepted within n-days Antonello! I’ll be using it for granting people Tumbleweed contributor badge in kudos. This will make sure we don’t keep OBS busy for too long:)”
From @lkocman in Infrastructure Heroes
“Many thanks for your help with whitelisting access from kudos-o-o to wiki and other services Georg!”
From @victorhck in Code & Engineering
“Thanks for your work keeping Tumbleweed rolling. and for your weekly reviews!”
@firstyear received a kudo:
From @lkocman in Support & User Assistance
“Many thanks you for the help with the 2factor recovery William!”
From @victorhck in Code & Engineering
“Thanks Imobach & Ancor for their work developing Agama, and many other tools since many years..”
From @C7NhtpnK in Code & Engineering
“Thank you for os-update!”
From @C7NhtpnK in Code & Engineering
“Thank you for answering and moderating some user questions about maintenance!”
From @lkocman in Community Moderation
“Many thanks for your quick help with the locked SPICE thread on forums-o-o Malcolm. Users will be happy to find a pointer in case they find this thread in the future. Many thanks!”
From @lkocman in Code & Engineering
“Many thanks for your work on the openSUSE-packaging-skill Martin! I’m really happy that we have somebody who’s proactively looking into how AI can actually improve general packaging experience in openSUSE.”
From @C7NhtpnK in Support & User Assistance
“Thank you for help and assistance at forums.o.o!”
From @C7NhtpnK in Code & Engineering
“Thank you for offering Myrlyn!”
From @lkocman in Code & Engineering
“Many thanks for your support with anything kernel related Takashi! I always really appreciate your help! We might make rtl8812au users happy!”
From @lkocman in Code & Engineering
“Many thanks for all your work on broadcom-wl Tobi! I think many broadcom users will highly appreciate it.”
Badges
Here is an overview of the 8 badges earned in August. The full list of badges you can earn is on the badges page.
Wiki Contributor
Recognition for the first day/page documentation contribution on en.opensuse.org wiki.
Awarded this month to @aplanas, @bmwiedemann, @jimed-rand and @lkocman.
100 Tumbleweed Contributions
For submitting 100 Submit Requests to openSUSE:Factory.
Awarded this month to @dirkmueller, @jengelh, @krop and @pluskalm.
10 Tumbleweed Contributions
For submitting 10 Submit Requests to openSUSE:Factory.
35 contributors earned this badge this month, too many to list here, but every one of them counts.
First Tumbleweed Contribution
For submitting 1 Submit Request to openSUSE:Factory.
210 contributors earned this badge this month, too many to list here, but every one of them counts.
Leap 16.1 Contributor
Recognition for submitting at least one pull request to Leap 16.1 or related appliance repositories on src.opensuse.org.
76 contributors earned this badge this month, too many to list here, but every one of them counts.
Leap 16.0 Contributor
Recognition for submitting at least one pull request to Leap 16.0 or related appliance repositories on src.opensuse.org.
75 contributors earned this badge this month, too many to list here, but every one of them counts.
Got First Kudo
Received your first kudos.
Awarded this month to @atartamo, @bigironman, @firstyear, @IGonzalezSosa, @kukuk, @mschreiner, @pluskalm, @Sauerland and @Tobi_Peter.
First Kudos Given
Shared your first kudos.
Awarded this month to @C7NhtpnK, @dnla, @levolet, @mdhup, @PossiblePrinterPalace and @victorhck.
Congrats on your kudos and badges. Keep up the great work everyone, and don’t forget to have a lot of fun!
Generated by kudos-bot-news-o-o from https://kudos.opensuse.org/api/reports/monthly for the period 1-31 August 2026.
Innit
I've been doing weeklybeats 2026 almost entirely on the Dirtywave M8 -- often on a Sunday night, in bed, on an actual hw. This was before Tim went and elevated a hardware abstraction layer into a proper iOS App (which I still very much recommend). This particular tune though, "Innit", is an oddity for me: it lives on the Analog Four, a box I got from a friend ages ago for an absolutely irresistible price. It mostly collected dust. I'd make a few tunes here and there but never really dug into the stuff that makes it unique. Other than having individual channels ready for effects pedals and exposing the Elektron sequencer via CV for your eurorack addiction (stuff that I for sure will never use).
I've been putting off learning about the performance macros forever, and I hate myself for it. Luckily the amazing Ivar Tryti revealed his mastery on Youtube which helped a lot. The concept is simple: you bundle up to five track parameters onto a single macro knob. Ten of them live on the performance page making is far less stressful of a navigation when performing. There's a setup cost, you need to precisely tune the parameter interactions, but once that's locked in, live performance becomes a far less stressful affair. You can also live map any or all of these ten mappings onto a single encoder for otherwise physically impossible twistings. This is easily remappable during the performance.
I'm still a noob at this, but the point is the same as always: there's real joy in performing and building up energy for the drop in real time -- way more satisfying than preprogramming the whole sequence.
Linux Saloon 219 | Butterbian and ButterKnife Distribution Exploration
Tumbleweed – Review of the week 2026/37
Dear Tumbleweed users and hackers,
This week saw the release of 4 snapshots (0904, 0907, 0908, and 0909).
It was a swift, steady week of updates, delivering several major items from our recent outlook. Core system elements and desktop utilities kept their momentum, keeping everything fully updated and robust while developers prepare for the major compiler and installer transitions currently brewing in staging.
These 4 snapshots delivered the following updates:
- bubblewrap 0.12.0
- curl 8.22.0
- expat 2.8.4
- gdm 50.3
- gpg2 2.5.22
- gpgme 2.2.0
- libarchive 3.8.9
- libgcrypt 1.12.3
- LibreOffice 26.8.0.3
- libvirt 12.7.0
- libxml2 2.15.4
- libzypp 17.38.15
- Linux Kernel 7.2.3 & 7.2.4
- Mesa 26.2.2
- MozillaFirefox 155.0 & 155.0.1
- ovmf 202608
- php8 8.5.10
- qemu 11.1.1
- re2c 4.6
- Samba 4.24.6
- SDL3 3.4.16
- wireplumber 0.5.17
- Xen 4.22.0_04
- yast2-bootloader 5.0.42
- zypper 1.14.101
As we close out this week’s chapter, here is a sneak peek at what is brewing in the staging projects for the coming days:
- Swig 4.5.0: YaST-related integration issues are still being addressed, tracked under boo#1275515.
- KDE Plasma 6.7.5
- KDE Frameworks 6.30
- KDE Gear 26.08.1
- fontconfig 2.18.3: Still held up as it breaks the AppStream test suite.
- libnettle 4.0.0: Remains explicitly excluded from main staging runs while developers work on resolving test suite breakages in libzypp.
Planet News Roundup
This is a roundup of articles from the openSUSE community listed on planet.opensuse.org. This community blog feed aggregator lists the featured highlights below from Sept. 4 - 10.
This week highlights the SUSE security spotlight covering the combined spring and summer review activity plus a command-injection vulnerability in wicked that allows remote root code execution via DHCP, the fifth bug-fix update of Plasma 6.7 and the release of KDE Frameworks 6.30, an openSUSE version-diff page that covers every package, the wrap-up of openSUSE’s Google Summer of Code, the release of Audacity 4.0, and Packman’s announcement that the repository will be discontinued unless a successor steps up.
Here is a summary and links for each post:
JPEG-XL, AppStream, and Better Media Processing
Matthias Klumpp reports on the AppStream 1.2.0 release, which makes JPEG-XL the new default image export format while redesigning the media processing pipeline with sandboxed workers. The post benchmarks JPEG-XL against PNG on Debian’s icon pool, showing bandwidth savings.
The syslog-ng Insider 2026-09: Performance; Openssl; Containers; Learning
Peter Czanik publishes the 141st issue of the syslog-ng Insider newsletter. It covers performance tuning options that can reach 7 million events per second in lab tests, nightly AlmaLinux-based containers published on Docker Hub, and the status of OpenSSL 4.0 support.
30th update of KDE Frameworks 6 and KCoreAddons library
The KDE Blog announces KDE Frameworks 6.30, the 30th monthly update of the libraries that underpin the KDE project, released on September 10. As part of a year-long series profiling each framework, the post introduces KCoreAddons library, which adds extensions and utilities on top of QtCore, from MIME management and automatic saving to backups, randomness generation and system user information.
The Other WTC Attack
Jakub Steiner shares a short, personal post recalling his 1993 visit to the top of the World Trade Center, unaware at the time that it had been bombed months earlier. He reflects on that 1993 attack, the truck bomb built from around 600 kilograms of homemade explosives plus hydrogen tanks, and how later events gave the story new weight.
SUSE Security Team Spotlight Spring/Summer 2026
The SUSE Security Team blog releases a combined spotlight covering its spring and summer review activity across dozens of D-Bus and Polkit policy rules, from upower and AppArmor’s aa-notify to fwupd and the transactional update notifier. The post also documents file-based root capabilities assigned in packages like cacti-spine’s CAP_NET_RAW and ksystemstats6’s CAP_PERFMON, and revisits the Apptainer setuid starter.
How to Keep a Script Running in the Background with SSH and tmux
Victorhck explains how to launch a script on a remote machine over SSH and keep it running in the background using a tmux session. The tutorial covers creating a named session, detaching with the tmux prefix and ‘d’, reconnecting later with tmux a -t, and closing the session when done.
“35 Years of Linux: 35 Curiosities That Changed Computing” by La Chica de Sistemas
The KDE Blog introduces the YouTuber La Chica de Sistemas, whose channel teaching Linux and Unix system administration it had long wanted to promote. It shares her video celebrating Linux’s 35th anniversary with 35 curiosities about the operating system that changed computing.
One Page, Every Package
The openSUSE News blog presents the openSUSE version diff tool, a machine-built comparison of source package versions across Tumbleweed and the current Leap releases. Pulled directly from the download.opensuse.org archive indexes, the page covers more than 17,500 source packages in a sortable, filterable table with downloadable JSON and CSV exports, categorizing each package as older, newer, equal or exclusive to one release.
Fifth Update of Plasma 6.7
The KDE Blog reports the fifth bug-fix update of Plasma 6.7 released on September 8. It recaps the branch’s recurring highlights such as independent virtual desktops per monitor, microphone volume testing, a light/dark theme switch, lunar calendar integration and print queue management, alongside the fixes in the new point release.
The Packman Repository Will Be Discontinued as of Jan 1, 2027
Victorhck translates the announcement from Packman’s maintainers that after 25 years, the project will be discontinued on January 1, 2027 unless a successor is found. The post recounts the history of the repository, the reasons behind stepping down, including the growth of Flatpak and the workload involved, and what a takeover would require.
Optimizing the sudo Test
Zoltán shares how the openQA sudo test for openSUSE and SLE was cut from about 9 minutes to 3 seconds while gaining broader coverage. He explains running the upstream test suite during the package build, porting functional tests to pytest, and adding a validator that checks the shipped sudoers file against common misconfigurations like targetpw.
Photos as a Substitute for KDE’s Gwenview Image Viewer
Victorhck looks at the Photos application as a substitute for KDE’s default Gwenview image viewer. The post examines what each viewer offers and what users should weigh before switching.
Synchronize the “scroll” in two tabs in the #KDE Kate editor
Victorhck shows how to synchronize the scroll position between two tabs in the KDE editor Kate. Using the View menu, Split View and Toggle Scroll Sync, Kate shows a chain icon and keeps both documents aligned so users can read and compare them together.
This Year’s Google Summer of Code Wrap Up
The openSUSE News blog wraps up the 2026 Google Summer of Code season in which openSUSE mentored eight contributors. Projects ranged from enhancing the git workflow build results page and benchmarking Uyuni on Kubernetes to an AI agent for root cause analysis, an MQTT publisher with Node-RED nodes, Uyuni’s API docs ported to OpenAPI, a new mgrctl get command and native LDAP support.
KDE Express Episode 75: Season 6 plus AkademyES and KDE Gear 26.08
The KDE Blog presents episode 75 of KDE Express, the podcast hosted by David Marzal returning after a hiatus. The episode spotlights Akademy-es 2026, scheduled for October 23-25 in Villaviciosa de Odón, and reviews KDE Gear 26.08 applications like Okular, Dolphin, Konsole and Minuet.
The Hacktivist Collective Autistici/Inventati Closes Its Services
Victorhck reports that after 25 years of providing privacy-preserving services to activists, the collective Autistici/Inventati is closing down. Following the U.S. government’s August 26 designation of the collective as a terrorist organization, it announced on September 6 that continuing to operate would endanger its users.
Audacity 4.0 Released, Renewing the Interface
The KDE Blog announces the release of Audacity 4.0, whose major update rebuilds the interface with Qt, introduces a new clip-based editing model, Guardable workspaces, HiDPI rendering and the new .aup4 project format. It lists the new recording, playback and effects features along with Audacity 3 functions not yet available.
Linux Saloon 218 | News Flight Night
Nathan Wolf posts episode 218 of the technology and Linux podcast and looks at California’s open-source legislation.
So Many Ways to Click and Scroll - This Week in Plasma
The KDE Blog translates this week’s Plasma development report, in which the last Plasma 6.8 features land along with fixes across the 6.6.7, 6.7.5 and 6.8 branches. It covers new ways to click and scroll, plus improvements to Discover, the task manager and other Plasma components.
Tumbleweed - Review of the Week 2026/36
Dominique Leuenberger and Victorhck review the six Tumbleweed snapshots of week 2026/36. Kernel 7.2.2, glibc 2.44, Rust 1.98, QEMU 11.1.0 and LLVM 23.1.0 were among the headline packages delivered to the rolling release.
Best Linux Distros for New Laptops in 2026 (Tested)
LinuxStans ranks seven distributions best suited to brand new laptops that need the freshest kernels, firmware and drivers. Fedora Workstation takes the top recommendation, with openSUSE Tumbleweed second for its rolling kernel updates and openQA snapshot testing, ahead of CachyOS, EndeavourOS, Pop!_OS, Ubuntu 26.04 LTS and Manjaro.
Complete Redesign of KDE Connect for Android
The KDE Blog reports on the complete redesign of KDE Connect for Android, the app that links a phone with Plasma desktops to share notifications, clipboard and files. The refresh brings a renewed visual interface to the app many users rely on daily.
Tiny Wins for Packagers: End-of-Week Update
The Open Build Service blog shares its end-of-week “Tiny Wins” update for packagers. Shipped fixes include preventing an encoding crash when writing YAML to temp files, repairing an osc branch crash for packages with an empty element, and updates to obs-service-node_modules and obs-service-source_validator.
View more blogs or learn to publish your own on planet.opensuse.org.
Tiny Wins for Packagers: End-of-Week Update (2026-09-11)
Releasing version 24
Yes, we know: version 23 came and went without a blog post. As it has happened before, we were busy enough with several tasks and blogging fell down the priority list. So consider this a two-for-one announcement covering the most relevant changes introduced in both Agama 23 and Agama 24.
But do not expect a long list of shiny new features. During the last months the team poured most of its energy into testing, polishing and fixing corner cases, so this post is a bit more modest than usual. Still, there are a few improvements worth highlighting.
Better interface to configure language and region
Configuring the internationalization settings -language, keyboard layout and time zone- in previous versions of the web user interface used to require jumping into three separate full-page selectors. Those three settings now live together in a single form, each one as a searchable field that filters the available options as you type.
The matching is accent-insensitive, so typing "ingles" finds "Inglés". The time zone selector even shows the current local time and UTC offset for each entry. A single "Accept" button applies all the changes at once, saving a couple of round trips in the process.
Binding network connections to their devices
Agama offers the possibility to configure several network connections. Some of those network connections can be associated with a specific network adapter, but telling several similar devices apart used to be tricky when the interface only offered their names and MAC addresses. The web UI now includes a "Browse with details..." option that opens a sortable table listing each device along with its type, IP addresses and connection state, so you can pick the right one with confidence.
In addition, other small improvements regarding the binding of network connections and devices were implemented here and there.
More usability and accessibility improvements
Beyond the changes already mentioned, this stabilization phase brought a long tail of smaller usability and accessibility refinements scattered across the whole web interface: better keyboard navigation, more consistent forms, clearer wording, improved screen reader support and many other little touches. There are far too many to list here, but together they make the installer noticeably more pleasant to use.
More theming capabilities
And things are especially pleasant when they feel consistent and in-place. To achieve that, every distribution can restyle the whole installer as explained in our previous blog post about theming Agama. Those styling capabilities keep growing: recent versions expanded the set of customizable roles and refined how the light, dark and high-contrast schemes are handled, giving products even more freedom to make Agama look like their own.
More possibilities to select storage devices
But the recent Agama improvements go beyond the web user interface. When using JSON to configure the
installation, for example in an unattended installation profile, it is often important to define how
each individual disk or partition must be processed. That requires a reliable way to identify the
devices in the system and to match them against the definitions in the JSON configuration. As you
may know, that is done using a search section within each of those definitions.
We recently made those search sections much more expressive. In addition to the logical operators
and, or and not to combine and nest conditions, it is now possible to match devices by their
kernel driver, by their filesystem (type, label or simply whether they are formatted), by the ID
type of a partition and even by the number and content of partitions or logical volumes within a
disk or LVM volume group. That allows queries as specific as "the smallest of those NVMe disks that
are bigger than 100 GiB and contain an ext4 partition".
Improved AutoYaST compatibility
Talking about unattended installations, one of the key features of Agama is its ability to consume AutoYaST profiles. Agama reads those profiles and automatically converts them into its own configuration, which is then processed as usual. The latest versions improve that conversion for the network configuration and also handle errors more gracefully while processing AutoYaST profiles, resulting in a more intuitive user experience if some feature is not fully supported by Agama.
More to come
With this stabilization phase behind us, the team is eager to switch back into a more innovative mode. So we hope the next release will bring a bunch of more exciting features to write about. Stay tuned!
Meanwhile, if you want a closer look at the development of Agama and wish to help shaping its
future, you can take a look at the project at GitHub or
drop by the #yast channel at Libera.chat.
JPEG-XL as default in AppStream, and better media processing
Two weeks ago, I released AppStream 1.2.0. This release contains a lot of great changes, but one of the most important ones concerns how media are being handled, and AppStream’s default image export format.
AppStream is a Freedesktop metadata standard to describe software components. That can be anything from system services over fonts to console and graphical applications. AppStream metadata is supposed to give users enough information to decide whether they want to install a piece of software, to represent that piece of software, and to give the operating system enough information to decide whether a software component should be installed automatically and (to some extent) what capabilities and relations it has, to provide the user with sensible options.
Especially for the first two goals, and especially for GUI applications, AppStream supports icons and screenshots, which are used to showcase applications. Today, AppStream is used by all kinds of services, from Linux distributions over firmware updates to Flatpak and desktops directly. AppStream’s original design however comes from the perspective of Linux distributions in 2011, where you may want to browse the software catalog offline, without delay, and without pinging an external server (which could be a privacy concern).
Therefore, a common way to deploy an AppStream-enabled software repository is to ship all icons of all applications in the repository to the user as part of the repository metadata download. AppStream does support remote icon downloads nowadays, and for a while I thought that this would become the default eventually. However, especially in today’s world, having a bandwidth-saving, instantly responsive, privacy-protecting application browsing experience seems more important that ever.
PNG images are great!
The only format that AppStream supports for icons and screenshots (which are downloaded on-demand from your distributor’s CDN) has always been exclusively PNG. PNG images are perfect for icons, because they compress well (especially for common icon shapes), are fast and simple to load, and can be loaded anywhere, by any toolkit or webbrowser. They also ensure we deliver faithful screenshot images, even though we may have scaled or re-rendered them. Still though, PNG images are less great for screenshots, as they are not very efficient, which puts strain on any CDN that has to deliver them, as well as on people’s internet connections when browsing screenshots. Having smaller thumbnails alleviates that problem a little, but does not fully solve it.
But even for icons, PNG could be improved upon: In many cases, icons are re-downloaded with the repository metadata again and again, so having a large icon tarball adds up to the data transferred during metadata refreshes. AppStream also now supports large 128x128px icons, which nobody in 2012 expected we would need, adding even more data that will be re-downloaded. Saving some space here translates directly to lower bandwidth costs as well as faster downloads for users.
To improve PNG file sizes, the AppStream Compose library, which handles all image processing and metadata catalog composition, was running optipng on all generated PNG images. That does create smaller PNG images, but they were still relatively large compared to other image formats.
For a long time though, there was no alternative to PNG images for icons: There was no lossless image compression format that could give us the same quality as PNG images and that was also widely supported.
JPEG-XL vs PNG in AppStream
Since 2021 we have JPEG-XL (JXL), which offers a true lossless mode with often better compression than PNG. The issue was that JPEG-XL wasn’t widely supported. Then, in 2025, the PDF Association selected JPEG-XL as the preferred image format for HDR images in PDFs, and now we are finally getting browser support and more ubiquitous availability of the format (you can try it right now in Firefox!).
For screenshots, using JXL’s lossy mode, it has obvious and extreme size advantages over PNG, so supporting JXL or WebP for screenshot images was an obvious choice. If JXL would support the lossless case very well as well though, we could serve many use cases with the same exported image format, which is very attractive to me.
So, the obvious next question was whether it was worth the pain of switching the icon format, so I did some measurements on real icons. For that I used the AppStream component icon pool that Debian Unstable ships, which is almost 5000 application icons of various sizes, and converted them to PNG:
| Icon size | Icons | PNG total | JXL total | Pool saved | PNG avg | JXL avg | Median saved | Mean saved | Worst | Best | Larger as JXL |
|---|---|---|---|---|---|---|---|---|---|---|---|
| 48×48 | 1544 | 3.7 MiB | 3.0 MiB | 17.8% | 2.4 KiB | 2.0 KiB | 17.9% | 16.7% | -118.7% | 60.0% | 206 |
| 64×64 | 2018 | 7.0 MiB | 5.8 MiB | 17.8% | 3.6 KiB | 2.9 KiB | 18.0% | 15.8% | -112.7% | 70.0% | 279 |
| 128×128 | 1411 | 11.2 MiB | 8.7 MiB | 22.0% | 8.1 KiB | 6.3 KiB | 20.1% | 17.5% | -89.7% | 61.0% | 209 |
| TOTAL | 4973 | 21.9 MiB | 17.5 MiB | 19.9% | 4.5 KiB | 3.6 KiB | 18.6% | 16.6% | -118.7% | 70.0% | 694 |
PNG images saved with libpng at effort=4, compression=9, then optimized using optipng -o2, JXL images encoded using vips jxlsave lossless=1 effort=7 strip=1 via VIPS/libjxl.
As the table shows, using lossless JXL images over size-optimized PNG images (using optipng’s default settings) provides a roughly 20% gain. This does not look like much, until you consider how often these files are downloaded: A 20% file size reduction may only save 1-2 MiB of disk space, but if they are downloaded over and over again by many clients, it will save a lot of bandwidth.
Interesting JXL encoding findings
As a sidequest, I was curious why some images were larger than their PNG counterparts when encoded with JXL, and what the ones that were significantly smaller were.
In short, the biggest size reductions for JXL existed on images that were already small as PNG, and contained large, flat color surfaces with hard edges and simple shapes. They were not very interesting, and much of JXL’s wins come from accumulating smaller gains across all files, which compound the bigger icons get (especially at 128x128px, where JXL truly shines).
The events were JXL loses to PNG are more interesting: For example, it does quite poorly with pixel-art images that have a lot of repeating patterns. Those are encoded well by PNG, but less efficiently by JXL. Take for example Vonsh:
My guess is that while PNG can exploit the repeating pixel patterns for compression, JXL’s predicts surrounding pixels from its neighbours, which fails too often and makes it pay almost full entropy per pixel. In this single rare case, the PNG is at 5.4 KiB, while the JXL is almost 8 KiB in size.
Other cases I looked at were arguably buggy input data, where color channels were hidden under the alpha channel of the input image. PNG could probably again exploit repeats, while we were forcing JXL to encode pixels that were invisible in the final image. This is arguably a problem with the original input data. Currently, AppStream does not make any changes to icons at all, but in future we might add a filter that removes invisible colors from images to solve this pathological case (it was only two icons out of 5000 though, so it is not a high priority).
The third case I found where JXL loses to PNG were icons with checkerboard-like patterns:
For those, PNG can likely again exploit the repeating patterns, while a checkerboard layout is pretty bad for left/top predictors like JXL’s. However, in this case the size difference (and loss for JXL) is only 450 bytes, so even though JXL loses to PNG, it does so not by much.
JXL in AppStream
Given these findings, JPEG-XL is the default image format starting with AppStream 1.2.0. AppStream Compose will encode all images losslessly as JXL, while screenshots are encoded in lossy mode at Q=90 effort=7. Since the optipng step does not happen for JXL images, this comes at no speed penalty and is even a bit faster on modern x86_64 CPUs (where libjxl can use SIMD). PNG is still available, and Compose can be told to switch between the two formats.
Upsides of JXL in AppStream right now
If you use JXL in Compose or the recent release of appstream-generator, you will get much smaller images and, for screenshots, will benefit from other JPEG-XL features such as progressive decoding, providing a far nicer user experience. libAppStream has supported JXL icons since version 1.1.3, so your clients will need that version or a newer one, and all software centers will have to support loading JXL images (which all of them do, provided the right plugins are installed).
Downsides of switching to JXL too quickly
JXL is a very new format, so web browsers might not yet display it if you are serving webpages. Your clients may also have bugs in processing JXL images, as the format is still “new”. For example, switching on JXL in Debian sent KDE Discover into an infinite loop on startup while trying to load the icons (an issue which has been fixed, but clients will need that patch first before JXL is switched on).
This currently makes JXL enablement only possible when you know that your clients can support it. This is the case for me in Debian Unstable and Debian 14, which are using JXL images for a few weeks now, but not for any older releases. Platforms like Flatpak have it even harder, because they do know even less about their clients. So, even though it has big advantages, you may want to hold off on using JXL right away, and force PNG by setting the ImageFormat key to png in appstream-generator‘s configuration, or passing --image-format=png to appstreamcli compose.
It is also worth mentioning that JPEG-XL is much, much slower on systems that do not have SIMD instructions or for which the libjxl/jxl-rs library does not have them (such as apparently riscv64 right now). If this is a concern, you might not want to switch to JXL right away.
Media pipeline improvements
Besides the JXL default change, AppStream 1.2.0 also comes with a complete overhaul of its media processing pipeline. While libappstream, AppStream’s main library, does not do any media processing and comes with very minimal dependencies to be embedded in client applications and used on servers, the same can not be said about libappstream-compose, AppStream’s library to build metadata generating applications (the server-side part, usually).
The compose library has to render fonts into font specimen cards, inspect translation files, render SVG images, decode all kinds of raster images, inspect video files, etc. Especially the fonts, and the fact that fonts can appear in SVG images, has caused issues in the past, as libappstream-compose is a heavily threaded library and most font libraries can only work from a single thread. This forced the library to essentially go into single-thread mode anytime anything that could touch a font was being processed.
AppStream also originally was created for a “safe world” where applications were vetted by the distributors before their metadata was processed. This is increasingly not the case, so it made sense to put at least a few guardrails on the most complex part of the pipeline: The media processing. As part of the change, media processing was split out into a separate worker process. This solved two problems at once: Font handling was isolated in a single-threaded binary – if we wanted to handle fonts in parallel, we could simply spawn more workers. And, being in a separate process, the media processing could now be sandboxed.
As part of the multiprocess changes, Compose also switched from using GdkPixbuf to VIPS for image processing. The latter allows for much more fine-grained control over the image output and encoding, and comes with a lot of well-maintained filters and operations, which made it possible to eliminate a fair chunk of AppStream’s hand-rolled image processing operations. As part of this transition, we unfortunately lost the ability to read XPM images, which dropped about 20-30 applications from the pool at Debian. But in the name of security, this is a sensible choice, especially since most XPM icons were very small and low-resolution, and applications using them could benefit from adding a high-quality PNG icon anyway. With VIPS, we also now restrict the amount of image formats we can load to a sensible set, so extremely niche or unexpected formats will be outright rejected (this includes sane-but-unusual formats for screenshots and icons, such as TIFF images).
The Compose library, with all of these changes, will now just request high-level operations (e.g. “render a font card for this font to a JXL image”) from the worker, and provide it with input data in sealed memfds and output locations as FDs as well. On Linux systems, the worker will use Landlock if available, to block all write access to the filesystem, deny device access and deny TCP and UDP as well. The sandbox can certainly be tightened a fair bit in future, but this was a good and safe start to gain some experience with it without having things break too easily, given the many places Compose is used in (also, Landlock’s API is surprisingly nice to use, so it was easier than I thought to add in this early version).
With all of these changes, the libappstream-compose library is now also officially marked API-stable, so you should be able to rely on it in future to build new things (its API has barely changed in the past, and now with the new media API and defaults change in place, it was time to declare it stable).
I want to see / try this!
Currently, the easiest way to have a look at the new data is to check out Debian Unstable. If you have a JXL-enabled browser, you can also see the icons in AppStream Generator’s HTML pages for Debian Sid. If you are using appstream-generator for your distribution, you will also get much more pleasant statistics and HTML pages, as well as fully deterministic media output and a whole bunch of security updates, so, update to its recent 1.0 release.
Please keep in mind that if you switch to JXL, the client tools receiving the image data have to support it. Support varies depending on the Linux distribution, so, test it first and switch the default back to PNG in case you encounter any issues.
What’s next?
With so many features and changes landed, the next changes in AppStream will focus on improving what already exists and fixing any issues (there will be more blogposts about the other features 1.2.x delivers!). Testing with the entire Debian archive as data source makes me fairly confident though that there will not be many problems. In the longer term, tightening the media processing sandbox will also be something we might want to do, e.g. by hiding parts of the filesystem tree or filtering syscalls.
For JPEG-XL, one obvious question is “Will you add support for it to the Freedesktop icon-theme specification as supported format alongside PNG, SVG(Z), and XPM?”. For on-disk icon repositories, JXL’s space-savings are less compelling, and it being HDR-capable is also not necessarily a killer feature (PNG can go a long way!). However, JPEG-XL’s ability to immediately decode larger images at reduced resolution without resampling could legitimately be very powerful here, as applications could ship a single large image and quickly decode it at 1/2, 1/4 or 1/8 the size for different purposes in their UI. JPEG-XL also supports spot-color extra channels, which applications could use as masks to recolor raster icons at render time. This could be incredibly nice to color symbolic icons on-the-fly without any SVG and CSS. JXL also provides richer metadata, which might be neat for (license/author) documentation. So, the answer here is: Maybe it makes sense to allow another format, but this will have to be discussed first, as it would force JXL into every toolkit and desktop, which is a much bigger ask than supporting it only in AppStream.
As always, let me know what you think and please report any issues or bugs directly against AppStream or AppStream Generator if you encounter problems that are with the tools, and not with a project’s metadata.
JPEG-XL, AppStream, and better media processing
Two weeks ago, I released AppStream 1.2.0. This release contains a lot of great changes, but one of the most important ones concerns how media are being handled, and AppStream’s default image export format.
AppStream is a Freedesktop metadata standard to describe software components. That can be anything from system services over fonts to console and graphical applications. AppStream metadata is supposed to give users enough information to decide whether they want to install a piece of software, to represent that piece of software, and to give the operating system enough information to decide whether a software component should be installed automatically and (to some extent) what capabilities and relations it has, to provide the user with sensible options.
Especially for the first two goals, and especially for GUI applications, AppStream supports icons and screenshots, which are used to showcase applications. Today, AppStream is used by all kinds of services, from Linux distributions over firmware updates to Flatpak and desktops directly. AppStream’s original design however comes from the perspective of Linux distributions in 2011, where you may want to browse the software catalog offline, without delay, and without pinging an external server (which could be a privacy concern).
Therefore, a common way to deploy an AppStream-enabled software repository is to ship all icons of all applications in the repository to the user as part of the repository metadata download. AppStream does support remote icon downloads nowadays, and for a while I thought that this would become the default eventually. However, especially in today’s world, having a bandwidth-saving, instantly responsive, privacy-protecting application browsing experience seems more important that ever.
PNG images are great!
The only format that AppStream supports for icons and screenshots (which are downloaded on-demand from your distributor’s CDN) has always been exclusively PNG. PNG images are perfect for icons, because they compress well (especially for common icon shapes), are fast and simple to load, and can be loaded anywhere, by any toolkit or webbrowser. They also ensure we deliver faithful screenshot images, even though we may have scaled or re-rendered them. Still though, PNG images are less great for screenshots, as they are not very efficient, which puts strain on any CDN that has to deliver them, as well as on people’s internet connections when browsing screenshots. Having smaller thumbnails alleviates that problem a little, but does not fully solve it.
But even for icons, PNG could be improved upon: In many cases, icons are re-downloaded with the repository metadata again and again, so having a large icon tarball adds up to the data transferred during metadata refreshes. AppStream also now supports large 128x128px icons, which nobody in 2012 expected we would need, adding even more data that will be re-downloaded. Saving some space here translates directly to lower bandwidth costs as well as faster downloads for users.
To improve PNG file sizes, the AppStream Compose library, which handles all image processing and metadata catalog composition, was running optipng on all generated PNG images. That does create smaller PNG images, but they were still relatively large compared to other image formats.
For a long time though, there was no alternative to PNG images for icons: There was no lossless image compression format that could give us the same quality as PNG images and that was also widely supported.
JPEG-XL vs PNG in AppStream
Since 2021 we have JPEG-XL (JXL), which offers a true lossless mode with often better compression than PNG. The issue was that JPEG-XL wasn’t widely supported. Then, in 2025, the PDF Association selected JPEG-XL as the preferred image format for HDR images in PDFs, and now we are finally getting browser support and more ubiquitous availability of the format (you can try it right now in Firefox!).
For screenshots, using JXL’s lossy mode, it has obvious and extreme size advantages over PNG, so supporting JXL or WebP for screenshot images was an obvious choice. If JXL would support the lossless case very well as well though, we could serve many use cases with the same exported image format, which is very attractive to me.
So, the obvious next question was whether it was worth the pain of switching the icon format, so I did some measurements on real icons. For that I used the AppStream component icon pool that Debian Unstable ships, which is almost 5000 application icons of various sizes, and converted them to PNG:
| Icon size | Icons | PNG total | JXL total | Pool saved | PNG avg | JXL avg | Median saved | Mean saved | Worst | Best | Larger as JXL |
|---|---|---|---|---|---|---|---|---|---|---|---|
| 48×48 | 1544 | 3.7 MiB | 3.0 MiB | 17.8% | 2.4 KiB | 2.0 KiB | 17.9% | 16.7% | -118.7% | 60.0% | 206 |
| 64×64 | 2018 | 7.0 MiB | 5.8 MiB | 17.8% | 3.6 KiB | 2.9 KiB | 18.0% | 15.8% | -112.7% | 70.0% | 279 |
| 128×128 | 1411 | 11.2 MiB | 8.7 MiB | 22.0% | 8.1 KiB | 6.3 KiB | 20.1% | 17.5% | -89.7% | 61.0% | 209 |
| TOTAL | 4973 | 21.9 MiB | 17.5 MiB | 19.9% | 4.5 KiB | 3.6 KiB | 18.6% | 16.6% | -118.7% | 70.0% | 694 |
PNG images saved with libpng at effort=4, compression=9, then optimized using optipng -o2, JXL images encoded using vips jxlsave lossless=1 effort=7 strip=1 via VIPS/libjxl.
As the table shows, using lossless JXL images over size-optimized PNG images (using optipng’s default settings) provides a roughly 20% gain. This does not look like much, until you consider how often these files are downloaded: A 20% file size reduction may only save 1-2 MiB of disk space, but if they are downloaded over and over again by many clients, it will save a lot of bandwidth.
Interesting JXL encoding findings
As a sidequest, I was curious why some images were larger than their PNG counterparts when encoded with JXL, and what the ones that were significantly smaller were.
In short, the biggest size reductions for JXL existed on images that were already small as PNG, and contained large, flat color surfaces with hard edges and simple shapes. They were not very interesting, and much of JXL’s wins come from accumulating smaller gains across all files, which compound the bigger icons get (especially at 128x128px, where JXL truly shines).
The events were JXL loses to PNG are more interesting: For example, it does quite poorly with pixel-art images that have a lot of repeating patterns. Those are encoded well by PNG, but less efficiently by JXL. Take for example Vonsh:
My guess is that while PNG can exploit the repeating pixel patterns for compression, JXL’s predicts surrounding pixels from its neighbours, which fails too often and makes it pay almost full entropy per pixel. In this single rare case, the PNG is at 5.4 KiB, while the JXL is almost 8 KiB in size.
Other cases I looked at were arguably buggy input data, where color channels were hidden under the alpha channel of the input image. PNG could probably again exploit repeats, while we were forcing JXL to encode pixels that were invisible in the final image. This is arguably a problem with the original input data. Currently, AppStream does not make any changes to icons at all, but in future we might add a filter that removes invisible colors from images to solve this pathological case (it was only two icons out of 5000 though, so it is not a high priority).
The third case I found where JXL loses to PNG were icons with checkerboard-like patterns:
For those, PNG can likely again exploit the repeating patterns, while a checkerboard layout is pretty bad for left/top predictors like JXL’s. However, in this case the size difference (and loss for JXL) is only 450 bytes, so even though JXL loses to PNG, it does so not by much.
JXL in AppStream
Given these findings, JPEG-XL is the default image format starting with AppStream 1.2.0. AppStream Compose will encode all images losslessly as JXL, while screenshots are encoded in lossy mode at Q=90 effort=7. Since the optipng step does not happen for JXL images, this comes at no speed penalty and is even a bit faster on modern x86_64 CPUs (where libjxl can use SIMD). PNG is still available, and Compose can be told to switch between the two formats.
Upsides of JXL in AppStream right now
If you use JXL in Compose or the recent release of appstream-generator, you will get much smaller images and, for screenshots, will benefit from other JPEG-XL features such as progressive decoding, providing a far nicer user experience. libAppStream has supported JXL icons since version 1.1.3, so your clients will need that version or a newer one, and all software centers will have to support loading JXL images (which all of them do, provided the right plugins are installed).
Downsides of switching to JXL too quickly
JXL is a very new format, so web browsers might not yet display it if you are serving webpages. Your clients may also have bugs in processing JXL images, as the format is still “new”. For example, switching on JXL in Debian sent KDE Discover into an infinite loop on startup while trying to load the icons (an issue which has been fixed, but clients will need that patch first before JXL is switched on).
This currently makes JXL enablement only possible when you know that your clients can support it. This is the case for me in Debian Unstable and Debian 14, which are using JXL images for a few weeks now, but not for any older releases. Platforms like Flatpak have it even harder, because they do know even less about their clients. So, even though it has big advantages, you may want to hold off on using JXL right away, and force PNG by setting the ImageFormat key to png in appstream-generator‘s configuration, or passing --image-format=png to appstreamcli compose.
It is also worth mentioning that JPEG-XL is much, much slower on systems that do not have SIMD instructions or for which the libjxl/jxl-rs library does not have them (such as apparently riscv64 right now). If this is a concern, you might not want to switch to JXL right away.
Media pipeline improvements
Besides the JXL default change, AppStream 1.2.0 also comes with a complete overhaul of its media processing pipeline. While libappstream, AppStream’s main library, does not do any media processing and comes with very minimal dependencies to be embedded in client applications and used on servers, the same can not be said about libappstream-compose, AppStream’s library to build metadata generating applications (the server-side part, usually).
The compose library has to render fonts into font specimen cards, inspect translation files, render SVG images, decode all kinds of raster images, inspect video files, etc. Especially the fonts, and the fact that fonts can appear in SVG images, has caused issues in the past, as libappstream-compose is a heavily threaded library and most font libraries can only work from a single thread. This forced the library to essentially go into single-thread mode anytime anything that could touch a font was being processed.
AppStream also originally was created for a “safe world” where applications were vetted by the distributors before their metadata was processed. This is increasingly not the case, so it made sense to put at least a few guardrails on the most complex part of the pipeline: The media processing. As part of the change, media processing was split out into a separate worker process. This solved two problems at once: Font handling was isolated in a single-threaded binary – if we wanted to handle fonts in parallel, we could simply spawn more workers. And, being in a separate process, the media processing could now be sandboxed.
As part of the multiprocess changes, Compose also switched from using GdkPixbuf to VIPS for image processing. The latter allows for much more fine-grained control over the image output and encoding, and comes with a lot of well-maintained filters and operations, which made it possible to eliminate a fair chunk of AppStream’s hand-rolled image processing operations. As part of this transition, we unfortunately lost the ability to read XPM images, which dropped about 20-30 applications from the pool at Debian. But in the name of security, this is a sensible choice, especially since most XPM icons were very small and low-resolution, and applications using them could benefit from adding a high-quality PNG icon anyway. With VIPS, we also now restrict the amount of image formats we can load to a sensible set, so extremely niche or unexpected formats will be outright rejected (this includes sane-but-unusual formats for screenshots and icons, such as TIFF images).
The Compose library, with all of these changes, will now just request high-level operations (e.g. “render a font card for this font to a JXL image”) from the worker, and provide it with input data in sealed memfds and output locations as FDs as well. On Linux systems, the worker will use Landlock if available, to block all write access to the filesystem, deny device access and deny TCP and UDP as well. The sandbox can certainly be tightened a fair bit in future, but this was a good and safe start to gain some experience with it without having things break too easily, given the many places Compose is used in (also, Landlock’s API is surprisingly nice to use, so it was easier than I thought to add in this early version).
With all of these changes, the libappstream-compose library is now also officially marked API-stable, so you should be able to rely on it in future to build new things (its API has barely changed in the past, and now with the new media API and defaults change in place, it was time to declare it stable).
I want to see / try this!
Currently, the easiest way to have a look at the new data is to check out Debian Unstable. If you have a JXL-enabled browser, you can also see the icons in AppStream Generator’s HTML pages for Debian Sid. If you are using appstream-generator for your distribution, you will also get much more pleasant statistics and HTML pages, as well as fully deterministic media output and a whole bunch of security updates, so, update to its recent 1.0 release.
Please keep in mind that if you switch to JXL, the client tools receiving the image data have to support it. Support varies depending on the Linux distribution, so, test it first and switch the default back to PNG in case you encounter any issues.
What’s next?
With so many features and changes landed, the next changes in AppStream will focus on improving what already exists and fixing any issues (there will be more blogposts about the other features 1.2.x delivers!). Testing with the entire Debian archive as data source makes me fairly confident though that there will not be many problems. In the longer term, tightening the media processing sandbox will also be something we might want to do, e.g. by hiding parts of the filesystem tree or filtering syscalls.
For JPEG-XL, one obvious question is “Will you add support for it to the Freedesktop icon-theme specification as supported format alongside PNG, SVG(Z), and XPM?”. For on-disk icon repositories, JXL’s space-savings are less compelling, and it being HDR-capable is also not necessarily a killer feature (PNG can go a long way!). However, JPEG-XL’s ability to immediately decode larger images at reduced resolution without resampling could legitimately be very powerful here, as applications could ship a single large image and quickly decode it at 1/2, 1/4 or 1/8 the size for different purposes in their UI. JPEG-XL also supports spot-color extra channels, which applications could use as masks to recolor raster icons at render time. This could be incredibly nice to color symbolic icons on-the-fly without any SVG and CSS. JXL also provides richer metadata, which might be neat for (license/author) documentation. So, the answer here is: Maybe it makes sense to allow another format, but this will have to be discussed first, as it would force JXL into every toolkit and desktop, which is a much bigger ask than supporting it only in AppStream.
As always, let me know what you think and please report any issues or bugs directly against AppStream or AppStream Generator if you encounter problems that are with the tools, and not with a project’s metadata.