You can read about many interesting syslog-ng features in my blogs. However, it can happen that when you want to try them at home, you fail because the feature is missing. How can you solve such problems? In this blog, I discuss some of the possible solutions from installing sub-packages through using unofficial repositories, to upgrading your OS.

This blog focuses on RPM packages for openSUSE / SLES, Fedora / RHEL, and FreeBSD, because these are the packages I know – I am their maintainer. However, these problems and their solutions also apply to Debian / Ubuntu, and other Linux distributions.

https://www.syslog-ng.com/community/b/blog/posts/why-is-a-feature-not-available-in-the-syslog-ng-package

A new version of the modern lightweight host operating system Leap Micro 5.5 just entered the Beta of its development.

A quick transition to a Release Candidate (RC) expected and the General Availability (GA) slated for the first half of October.

One of the standout features of Leap Micro 5.5 is its SELinux enhancements. Security-Enhanced Linux (SELinux) has received a significant boost; It brings podman-docker and hyper-v support for AArch64 for a more robust and secure computing experience for users.

In tandem with this exciting update, it’s important to note that Leap Micro 5.3 is nearing its End of Life (EOL). As soon as Leap Micro 5.5 makes its official debut, Leap Micro 5.3 will be retired. Users of Leap Micro 5.3 are strongly advised to consider upgrading to either Leap Micro 5.4 or the upcoming 5.5 release. This ensures access to the latest features, security enhancements, and ongoing support.

A recently published openSUSE survey is asking IT professionals and users about their views on open-source technologies and the ever-evolving Linux ecosystem.

The Use Case Survey aims to gather insights on what will shape the future of Linux and its role in various industries. The survey has four groups with the potential of answering up to 30 questions based on the response of the first and only mandatory question. The survey can take less than 10 minutes depending on how in depth of details a surveyee would like to provide. The overarching themes and ideas of the survey are the following:

Understanding User Needs and Satisfaction

The survey kicks off by categorizing respondents based on their use of IT: work/business, home/hobby, or both. This segmentation helps tailor the approach to better serve the needs of the surveyee.

For those in the work/business category, the survey delves into IT services satisfaction. Those not satisfied have options to suggest improvement, and it explores the idea of future growth prospects for Linux.

Home and Hobby Enthusiasts

For those using Linux at home or for hobbies, the survey asks about their preferences among openSUSE’s offerings like Tumbleweed, Leap, MicroOS, and SlowRoll, and why these distributions appeal to users and developers.

Contributions and Open Source Involvement

As an open-source project, it makes sense to inquire about contributions to open-source projects and to openSUSE. This helps to recognize not only the use of open-source software and projects, but how much users are contributing to it.

General Insights and Future Trends

This section asks all respondents about broader use of Linux beyond primary use cases. The aim is to help to understand the benefits respondents experience and the challenges they encounter. Respondents are encouraged to share their preferences for specific Linux distributions and their thoughts on emerging IT trends and technologies. The community members who came up with the survey are keen to understand if Linux is well-positioned to meet the market’s evolving needs with medium to long-term strategies.

The openSUSE’s Use Case Survey is not just a set of questions; it’s a collective effort to ensure that Linux continues to evolve to meet the diverse needs of its users and to make a brighter future for open-source technologies. Stay tuned for more updates and analysis from the results of the survey, which will run until Oct. 31.

After publishing Agama 3 a month ago, it is time for a new release. Among other things, this new version fixes several issues in the startup process, allows the use of a network proxy, adds (partial) support for IPv6, includes a few improvements in the web UI and features a new tool to extract Agama-related logs.

But as important as those changes, we did some internal work that will serve as the base for other features, like proper i18n support and more flexible storage management. Some of those features will land sooner than later, but meanwhile, let’s focus on what Agama 4 brings.

Agama startup issues

Our QA team is testing Agama through several scenarios and in different architectures. Those tests helped identify some issues with Agama’s startup process: D-Bus activation errors, time-outs and even potential crashes.

Working closely with QA, we have identified and (hopefully) fixed most of those problems. In a nutshell, you should not see the “Cannot connect to D-Bus” error message anymore. And if that’s not the case, please open a bug report attaching the logs :wink:

If you are interested in the technical details, there is a bunch of fixes you might want to check: #729, #732, #747, #749, #753.

Installing through a proxy

Many users and customers are used to deploy their systems with no direct access to Internet, just using a proxy. So it did not come as a surprise that it was one of the most requested features. Agama 4 includes support for specifying a proxy at boot time using the option proxy= when the installation requires to use a HTTP(S) or FTP source. The supported proxy URL format is: protocol://[user[:password]@]host[:port].

Of course, the proxy configuration is copied to the target system at the end of the installation.

The nitty-gritty details are available in #696 and #711.

IPv6 support in the automated installation

In Agama 4 it is possible to specify the IPv6 configuration when using the automated installation. To accommodate this feature, we decided to introduce some changes in the profile definition. Here is an example that sets up IPv4 and IPv6 addresses.

  "network": {
    "connections": [
      {
        "id": "Ethernet network device 1",
        "method4": "manual",
        "method6": "manual",
        "addresses": [
          "192.168.122.100/24",
          "::ffff:c0a8:7ac7/64"
        ],
        "gateway4": "192.168.122.1",
        "gateway6": "::ffff:c0a8:7a01",
        "nameservers": [
          "192.168.122.1",
          "2001:4860:4860::8888"
        ]
      }
    ]
  }

Matching specific network devices

In previous versions of Agama, it was not possible specify which interface to use for a given network connection when using the auto-installation mechanism: Agama just delegated on NetworkManager to decide. Now you can associate a network connection with an specific interface by using its name or more complex conditions. See #723 for further details.

  "network": {
    "connections": [
      {
        "id": "Ethernet network device 1",
        "method4": "auto",
        "interface": "enp1s0"
      }
    ]
  }

Agama specific storage settings

Agama reads the information about the products offered for installation from a configuration (/etc/agama.yaml). Such a file contains a storage section which indicates the options (whether to use LVM, encryption, etc.) and the volumes (file systems) to create in the target system.

Since both Agama and YaST use the same mechanism to calculate the storage layout (known as the Guided Setup in YaST), the configuration for Agama was a direct translation of the YaST settings. But although the internal components and algorithms are the same, Agama’s approach for tweaking their behavior is actually different in several aspects from YaST. For that reason, Agama now implements its own storage settings, making the product configuration more straightforward and less error-prone.

This change has a direct impact in Agama’s auto-installation profiles.

storage: {
  bootDevice: "/dev/vda",
  lvm: true,
  encryptionPassword: "123456"
}

Interested in the implementation? Feel free to check: #721, #738 and #748.

Better logging support

As the project evolves and more people try Agama, we need to make the debugging process easier. Recently, we introduced a new command that gathers all the information we need to debug the problems you face when using Agama (similar to the venerable save_y2logs for YaST). Typing agama logs store creates a tarball you can attach to your bug reports.

This first version (#757) is rather basic but we are already working on additional features to have a pleasant debugging process :bug:.

Polishing the web user interface

Balsa Asanovic has become a regular contributor of Agama. For example, he implemented the “show password” feature (#750) and improved the error reporting in the iSCSI form (#699). But not only that, he is actively involved in our discussions in GitHub. Thank you, Balsa!

Moreover, a bug that prevented to download YaST2 logs through the web UI has been fixed (#746).

i18n support is coming to Agama

If you follow the project closely enough, you might already know that we are working on i18n support. Many of the pieces are already in place but we did not make it for this version. However, we trust that our next major version will feature a translated web interface. Actually, our translators are already working on that.

Trying Agama 4

The easiest way to try Agama is to download one of the two variants (ALP or openSUSE) of the Agama Live devel ISO. This image is built in the systemsmanagement:Agama:Devel OBS project and is updated each time we release a new version.

If you are interested in the bleeding edge, try the ISO in the systemsmanagement:Agama:Staging OBS project. It is built automatically and contains the code from Agama’s Git repository, so it might get broken occassionally.

What to expect

We expect to be able to ship a translated Agama interface and better handling of the storage settings in the next release. But, meanwhile, we are already working on other important features like software patterns selection or support for the SUSE Customer Center.

Of course, we appreciate opinions and feedback. As usual, feel free to contact the YaST team at the YaST Development mailing list, our #yast channel at Libera.chat or even the Agama project at GitHub.

Stay tuned!

Choosing a name for anything is not an easy task; the detail can wield significant influence, which is why a survey to make a decision about renaming Slowroll was presented.

Slowroll is a new distribution based on Tumbleweed, but rolls out updates slower; it is designed to implement updates at a pace of one to two months, integrating bug fixes and addressing Common Vulnerability and Exposure issues as they emerge.

As will all things in open source, the name was presented along with the idea for the distribution and discussion took place about the details surrounding Slowroll. The origin of the name was self-describing the distribution, but other names for Slowroll were proposed, so the renaming of it was put to a vote. All names there were proposed were included in the survey.

That voting process concluded today with more than 1,000 votes cast by interested members of the open-source community. This enthusiastic involvement underscores the interest of the openSUSE user base and trajectory of the project. The top results are the following:

1. Slowroll - 46.33%

2. Driftwood - 25.91%

3. Snowroll - 21.04%

4. Drift - 20.51%

5. Wave - 16.36%

6. Orbit - 13.44%

7. Lunar - 12.56%

8. Tide - 12.47%

The percentages surpass the 100% threshold due to the respondents’ option to endorse multiple choices.

With an impressive 46.33% of the votes, the community found Slowroll to remain the best option to describe the naming of the distribution. The decision has been reached to retain the established name as it represents a communal vision and messaging in name.

Members of the project extend their gratitude and appreciation for all those who took the survey and contributed to this pivotal decision.

Anyone interested in making a logo for the new distribution can send design images to the project’s marketing telegram channel. The logo should be an .svg image and should complement other logos for the project that related to a branding direction being discussed on the project’s GitHub.

Thank you for being part of the journey, and have a lot of fun!

Version 1.1 von Kraft ist mit wichtigen Verbesserungen für Benutzende und die Integration in moderne Softwarestacks wie cmake und KDE releast worden. Die wichtigsten Änderungen sollen hier kurz vorgestellt werden.

Als erstes einige technische Details: Die niederländischen Übersetzungen sind aktualisiert. Das Anwendungs-Icon wurde repariert, und die cmake Steuerdateien wurden so geändert, dass Kraft jetzt sowohl mit älteren als auch neuen Versionen von Akonadi zusammenarbeitet, wie sie in verschiedenen Linux-Distributionen gefunden werden.

Aus Sicht von Benutzenden gibt es zwei wesentliche Verbesserungen:

Erstens können die Kopf- und Fußtexte der Dokumente können jetzt mit Makros erweitert werden, die automatische Berechnung z. B. von Datumswerten unterstützen. So kann beispielsweise ein Zahlungsziel von zwei Wochen nach dem Dokumentdatum durch den Einsatz eines Makros sehr leicht automatisch auf dem Ausdruck eingefügt werden. Darüber hinaus gibt es noch weitere interessante Makros z. B. zur Berechnung der sog. haushaltsnahen Dienstleistungen. Sie werden in einem separaten Beitrag vorgestellt.

Zum Zweiten wurde ein neuer Knopf hinzugefügt, mit dem Vorlagen für Kopf- und Fußtexte jetzt an der Cursorposition zusätzlich in die Texte des Dokumentes eingefügt werden. Bisher konnten nur die gesamten Dokumenttexte ersetzt werden. Mit der neuen Erweiterung steigt die Flexibilität wie die
Vorlagen organisiert werden, da jetzt leichter spezifische Textbausteine erstellt werden können.

Parallel zu diesem Release geht die Arbeit an einem Kraft 2.0 Branch weiter, der Kraft zu einem kollaborativen, digital souveränen Werkzeug über Internet machen wird.

Kraft Version 1.1 kann wie üblich über die Download-Seite heruntergeladen werden.

Bitte beachten: Wenn man Kraft 1.1 selbst übersetzen will, stößt man auf einen kleinen Fehler: Im root-Verzeichnis des source Tarballs wird die Datei .tag erwartet, sonst bricht cmake mit einem Fehler ab. Dies kann behoben werden, indem die Datei angelegt wird mit dem Inhalt 100ca9f3.

Dear Tumbleweed users and hackers,

Tumbleweed went for a small break this week and delivered ‘only’ 4 snapshots (0914, 0915, 0917, and 0920). The large gap happened due to a test suite error in icu, which resulted in all stagings turning red. Once this was resolved, the fix was added in parallel to multiple stagings to resume progress.

The 4 delivered snapshots contained some eagerly awaited updates (at least for some):

• KDE Plasma 5.27.8
• KDE Gear 23.08.1
• Linux kernel 6.5.3
• GNOME 45.0
• Libproxy 0.5.3
• groff 1.23.0
• PostgreSQL 16.0

The staging projects are mostly moving, a few select issues have been with us for a while by now and block some updates. The things on the list are:

• Java 20 OpenJDK will be removed; Java 21 OpenJDK added. Mid-term, we will switch from Java 17 LTS version to Java 21 LTS as the distro default
• Linux kernel 6.5.4
• Poppler 23.09.0
• LLVM 17
• Mesa 23.1.8
• cmake 3.27.5
• FMT 10: breaks mariadb boo#1213219 and ceph boo#1213217; help welcome

A few openSUSE Tumbleweed snapshots became available to users of the rolling release this week.

Several software packages for KDE users were among those updated.

The health-checker package, which checks to ensure a system comes up correctly after an update, moved to version 1.10 in snapshot 20230917. The new version fixed a journal check error that reported an invalid option error with systemctl. While not a critical issue, this can spam the journal and was caused by a change in openSUSE kiwi, according to the bugzilla report. An update of OpenSSL 1.1.1w fixes a Common Vulnerability and Exposure that doesn’t effect Linux systems and had a fix preventing corruption of XMM registers ensuring application stability. The 0.10.6 snapper version had fixes for creating files in the root directory and provides improvements in handling info.xml files. Security updates came in libwebp 1.3.2 that specifically addresses CVE-2023-4863, which could have allowed a remote attacker to perform an out of bounds memory write via a crafted HTML page. Also updated in the snapshot were groff 1.23.0, tiff 4.6.0 and more.

Snapshot 20230915 brought one other package besides updates for KDE Gear 23.08.1. The lone software package to update was gtkmm4 4.12.0 had some enhancements in simplifying C++ development with GTK. The package also introduces a deprecation and improves documentation with clearer explanations about managed and non-managed widgets in GTK. The Gear 23.08.1 updates had several improvements and bug fixes. Among those updates were kitinerary and it expands its barcode extraction capabilities as well as enhances ticket handling for various scenarios. There were some fixes to the definition of preprocessor macro HAVE_X11 in KMail. KNavalBattle reset stats upon restarting a game. A crash was fixed for Konsole and Gwenview improved navigation with side mouse buttons and settings menu override issues. The update of Okular fixes object creation and button icon issues in PDFs.

The 20230914 wasn’t in the last Tumbleweed update, but it did have some significant updates. The snapshot also provides more updates for KDE users. Plasma 5.27.8 updates Application installer Discover and fixes some Flatpak crashes to enhance stability. An update of Breeze fixes the separator position on HiDPI displays and removed extra 1px padding for improved visual aesthetics. The plasma5-desktop 5.27.8 package fixes touchpad-related crashes on X11 and also includes numerous other fixes and improvements. An update of btrfsprogs 6.5.1 addresses issues with crc32c when PIE or relro is enabled. The spec file no longer has a dependency on xmlto for building docs. A 13.2.1+git update of GNU Compiler Collection addresses issues with -fstack-protector related to aarch64 fixing CVE-2023-4039. Xfce users also received an update in the snapshot. The xfce4-whiskermenu-plugin 2.8.0 update fixes menu issues in Wayland, adds new features like specific menu instances and center screen display, streamlines settings, and improves compatibility with Xfce 4.14.

Kraft (Github) is a desktop utility making it easy to create offers and invoices quickly and beautifully in small companies.

Today we are releasing Kraft Version 1.1 with significant improvements for users and the Krafts integration with latest software such as cmake and KDE.

It received updated dutch translations in UI and also for the manual. The application icon was fixed, and some cmake related fixes were done that make Kraft working with different versions of Akonadi that are available on different distributions.

Macros

For users, two significant improvements are included: The header- and footer texts of the documents now may contain macros that support automatic computing of values such as dates that depend on the document date. With that, it is for example easy to have for example a payment date printed out on the document, that is ten days later than the document date.

There are even more interesting macros, stay tuned for a separate post about this feature.

Insert Templates Button

The second new feature is a new button that allows to insert templates for the header- or footer text at the cursor position. Before it was only possible to replace the entire text with a template. This will give users way more flexibility how to structure template texts.

In parallel to these improvements, work is also going on in a branch for Kraft 2.0 which will enable more collaborative functions for Kraft.