NUREMBERG, Germany (May 30, 2023) - Open-source projects and contributions have brought remarkable advancements in technology by enabling communication and collaboration among people worldwide.

One such example of this is the openQA testing tool, which has collectively benefited the Linux ecosystem.

Started by the openSUSE community in 2011 and still very actively developed, openQA has gained strong usage by projects such as Fedora, Debian, Kali Linux, Qubes OS, GNOME, and KDE. Recently, AlmaLinux joined this group as a reliable and stable RHEL clone, and the community has made contributions to openQA that demonstrate how complementary open-source projects can work together.

“To assure our users that we take testing very seriously and are committed to delivering the best possible experience, we’ve implemented the openQA tool to automatically test AlmaLinux OS for all supported architectures,” according to a community post.

“I want to thank AlmaLinux for these contributions!” said Sarah Julia Kriesch, openSUSE zSystems Maintainer & (Co-)Chair of the Linux Distributions Working Group at The Open Mainframe Project. ”openQA is already used by Fedora and Debian besides openSUSE/SUSE. Working together and improving our tests is part of the collaborative maintenance of Linux for s390x.”

“With tests enabled for Red Hat KVM now, we can additionally test all other Linux distributions on Fedora and RHEL,” she said. “That is also a test extension, where we all can benefit. openQA is an open-source project and can be used for automated tests for every operating system.

In brief, openQA uses virtual machines to reproduce predefined processes and check the output against what it expects to be the output. The architectures available are for Intel/AMD (x86-64), ARM64 (aarch64), IBM PowerPC (ppc64le) and IBM Z (s390x).

A pull request to add Enterprise Linux support to the QEMU backend started the AlmaLinux contributions to openQA and more are expected from the community. Updating QEMU-KVM options like Kriesch mentioned to make them compatible with RHEL’s QEMU-KVM build as well as several updates to make QEMU backend work with s390x are making a difference for developers.

“Expanding architecture support for quality testing software like openQA is really great to see, and it’s even better to see this support already being put into use by the AlmaLinux project.” said Elizabeth K. Joseph, Open Source Software Program Office for IBM zSystems and LinuxONE & (Co-)Chair of the Linux Distributions Working Group at The Open Mainframe Project.

During the development, the AlmaLinux contributors went through the processes of adapting openQA for working on the RHEL virtualization stack and bringing back KVM support in ppc64le architecture for AlmaLinux 9. It was removed from RHEL9 and therefore can’t be part of AlmaLinux 9 (as it promises to be a 1:1 binary clone of RHEL), but modified kernel and qemu-kvm packages are part of AlmaLinux’s openQA repo now.

The AlmaLinux community also implemented virtualization support for s390x architecture in openQA. More details of the development process and challenges that the AlmaLinux Team overcame are coming soon from Elkhan Mammadli, the AlmaLinux OS Engineer responsible for the openQA improvements they’ve contributed.

Elkhan gave a shout out to openQA developers for such a cool project, to the Fedora Project for tests and inspiration, and to Sam Thursfield who gave a presentation at FOSDEM about using openQA for testing GNOME OS Nightly builds, which played a big role for Elkhan for using and contributing to the testing tool.

The team prepared an openQA User guide with more details and has invited contributions by helping AlmaLinux define test suites tailored for developer needs.

The expansion of openQA’s use started in 2014 after Richard Brown wrote a test suite for Fedora. His talk at the openSUSE Conference in 2015 and other events gradually helped to expand its usage across the open-source ecosystem.

This year’s openSUSE Conference starts in about 72 hours and open-source enthusiasts, contributors and supporters are making their way to Nuremberg, Germany, for a collaborative community event.

Talks begin on May 26 at 9:30 a.m. Central European Time and the event will be streamed by c3voc; the stream link will be posted on events.opensuse.org before the event begins. The schedule lists plenty of talks ranging from an introduction to the Geeko Foundation to an introduction of the service-based Linux installer Agama.

Talks will take place in two presentation rooms at the event and are labeled on the schedule as Saal and Galerie. Stream viewers can ask questions to the presenters during the event via two Telegram channels that correspond with the room where the presentation is being held. Questions for talks in Saal should be asked in the https://t.me/oscsaal Telegram channel and questions for talks in Galerie should be asked in the https://t.me/oscgalerie Telegram channel. Questions may be presented to the speakers as time allows.

There are other online event interactions as well. From a Fedora Hatch event to a Kubernetes workshop, attendees are being reminded to incorporate events with people attending the conference virtually. Like the Telegram channels for talks, those giving workshops are encouraged to incorporate a Jitsi room corresponding to where their workshop is taking place. Workshops on the schedule listed in Seminar Raum 1 will have a dedicated virtual room https://meet.opensuse.org/Seminarraum1 and Seminar Raum 2 will have a dedicated virtual room https://meet.opensuse.org/Seminarraum2.

Members of the community are also looking for help during and after the conference. The video team needs help during the conference. The team at the physical location really needs help as the video recording, editing, and streaming can be demanding if not enough people are willing to help. The video team will be meeting at 9:00 a.m. in Saal on May 26, so please join and help the team with our online viewership and recorded videos.

There are also several other areas the openSUSE community can use help with. A list of those items can be found at https://etherpad.opensuse.org/p/help. Consider helping out as the project can use some help in quite a few areas.

The openSUSE Project’s annual openSUSE community event brings people from around the world together to meet, collaborate and learn. With organized talks, workshops and meetup sessions, openSUSE Conference 2023 provides a framework for communities to enhance and improve open-source technologies and shared projects.

The project thanks our sponsors for the great support. This year’s sponsors are SUSE, arm, The Geeko Foundation, Fedora, Linux Pro Magazine and FOSSLife.

Chongqing, China, Selected for openSUSE.Asia Summit 2023

Chongqing has been accepted to host the openSUSE.Asia Summit 2023 and the openSUSE.Asia Summit will return to China for the second time, Chongqing is one of the four directly-administered municipalities of the PRC, located in southwest China, bordered by Sichuan, Yunnan and other areas, is one of the second batch of national historical and cultural city announced by the State Council of China.The world map hanging in the halls of the United Nations, marked only the names of four cities in China, one of which is Chongqing.PRC

The openSUSE.Asia Summit is a highly anticipated event for supporters of openSUSE in China and Free/Libre Open Source Software (FLOSS) in general. This activity will bring together experts, contributors, end-users and technology enthusiasts.will gather to share experiences about the development of openSUSE and other things related to FLOSS and have a lot of fun.The venue for the openSUSE.Asia Summit was chosen by vote of openSUSE.Asia committee . Finally, the Asian committee decided Chongqing as the host of openSUSE.Asia Summit 2023 from October 21, 2023 to October 23, 2023, at Chongqing University of Posts and Telecommunications.

Some of the goals to be achieved at the openSUSE.Asia Summit 2023 in Chongqing will be to

• Promotion of openSUSE in China.
• Attraction of new openSUSE contributors from China and other Asian countries.
• To provide an alternative for the wider community to see that FLOSS can be a powerful tool for them to use in their day-to-day work.
• Provide a platform for the exchange of experiences between users and developers, where such discussions would normally only take place online.

Finally, we are proud to present Chongqing as one of the best locations for openSUSE.Asia.

Pre-announcement

openSUSE.Asia Summit 2023 will open a call for papers for potential speakers. and the openSUSE.Asia Summit 2023 logo competition will also be opened. The logo competition would be an opportunity for designers in Asia to compete with each other to showcase their skills and be a part of this activity. More details about the above information will be announced in the near future via news.opensuse.org.

See you in Chongqing!

Tao-dialog is part of tao-utils commands group. It assembles only tao-manager (simple file manager) and tao-dialog currently. Tao-dialog aims to work as zephyr/kdialog replacement, but it is currently not done. Maybe in future, I will add xmessage compatibility mode. Dialog compact mode rather never been supported, due dialog have options rather hard to implement using libgreattao.

Libgreattao have GUI and shell mode. Network mode must be re-implemented. Many feature, working in V2 version must be rewriten to V3 (3.0 version). But V2 is rather complicated and error-prone. LibgreattaoV3 uses libexslt internally.

Zephyr and KDialog modes of tao-dialog are partially implemented. You can do basic stuff like displaying yes/no dialog, info dialog and file dialogs. File dialogs are currently error-prone in libgreattaoV3 (sometimes causes crash, when dialog is destroyed), but I will work on this.

One good point of Libgreattao is GUI mode could use one of three backends: GTK4, Qt5 and console. So it could revolution inside system-communication manner. Programmer could write script, which uses tao-dialog in zenity/kdialog mode and, depending on current DE, it could show GTK+, QT or console dialogs. Yes… it even could work without Graphical Environment, so it made many programming problems less problematic. You can write installer in bash, using tao-dialog and it spawns Qt dialogs, Gtk4 dialogs. If user open it terminal, it also uses console backend and works. Maybe I will add ncurses backend in future. Console backend is very simple, but works.

Libgreattao allows to make Linux software easier. Imagine xdg-su do not load backends by its own. It only create normal windows (authorization prompts) and libgreattao takes care for rest. There could be also other pieces of Linux desktop, which could take advantage thanks to libgreattao, like prompt for allow to start application (set x bit and ran app, if user allow), dialog asking to select application for file open task, etc. DE could only selects GUI backend or design files.

Recently, I was looking for some new hybrid / crossover music, and someone recommended me to check out Hidden Orchestra. Listening to their album, “Creaks” was an instant love. As I learned later, it’s the music of a game. I’m not a gamer, but once seeing that it’s on sale on Humble Bundle I bought it immediately.

You can listen to the whole album here:

You can also find it on Bandcamp.

So, what is hybrid or crossover music? A real musician would probably have two distinct definitions with lots of fine details. To me, both mean combining classical and modern styles and instruments in a song. This can easily lead to disaster, but when done right, that’s my favorite style of music. There are some fantastic bands and composers here in Hungary who work in this genre, like After Crying, Fugato, Hidden Kingdom, or Julius Dobos (strictly in alphabetical order, as all of them are good).

I was curious to find more hybrid / crossover music, so I asked around. From the handful of suggestions, Hidden Orchestra was to the closest to what I was looking for. Luckily, much of their music is available on TIDAL, so I could listen to them in CD quality. And while I liked most of their albums, “Creaks” became my absolute favorite.

“Creaks” is now installed on my machine. I must admit, I did not play much with it. The music and graphics are beautiful, however I’m not a gamer. The only other game I bought recently is Civilization, as I played that a lot during my university years, so I bought it mostly out of nostalgia :-)

As a music fanatic, I find it fascinating that the music I love to listen to is also available as the soundtrack of a game. Previously, I had similar experiences with films. I watched many movies because I listened to their soundtrack first, and I became curious. But that’s another story, and I already wrote a blog about that almost two years ago: Watching movies belonging to soundtracks.

Finally a question and request to you:

• Did you ever buy a game because of its music?
• If you know any good hybrid / crossover music, let me know!

Reach out to me on Twitter or Mastodon! Links to my accounts are available at the top of the page.

In version 4 of syslog-ng, the role of Python became even more important. Previously, all parts of syslog-ng could be extended using Python code, but no actual Python code was provided with syslog-ng. Version 4.0 added a Kubernetes module implemented in Python, while version 4.2 added support for Hypr. But how can we ensure that all Python dependencies are met?

In my latest blog I describe the current situation and ask you for feedback!

https://www.syslog-ng.com/community/b/blog/posts/syslog-ng-python-packaging

I'm glad to say that I'll participate again in the GSoC, as mentor. This year will be a bit different from the previous ones, because I'm not mentoring a GNOME project but a openSUSE project.

I started to work at SUSE the past year and with this new job I get involved in the openSUSE community and I started to contribute to rpmlint.

So this summer I'll be mentoring an intern and we'll work on improving the testing framework of the rpmlint project.

The rpmlint project is a command line tool to check rpm packages, the correctness of these kind of packages and warn the packagers about usual problems or good practices. It's widely used in all Linux distributions based on rpm, mainly SUSE and RedHat.

It is written in Python and uses pytest for testing the code. Right now there are a lot of .rpm binary packages, to check different functionality, but that way of testing makes a bit hard to write new tests and to maintain with changes. The idea of this GSoC project is to extend the testing framework of rpmlint to support an easy way of writting tests that doesn't require a real rpm, something that can mock what it's in the .rpm binary and try to replace some of the current binary tests with this new mock.

The selected intern is Afrid Hussain. He has done some initial work in the rpmlint project, solving some minor issues and we're now preparing the work to be done during the GSoC program. I'm sure that he will be able to achieve great things during these three months, so I'm looking forward to start to code and see how far can we go.

Project Link: CNCF – Kubescape: Release engineering: add Kubescape to commonly-requested package managers

kubescape is a Cloud Native Computing Foundation (CNCF) sandbox project. It is an open-source Kubernetes security platform and includes risk analysis, security compliance, and misconfiguration scanning. Targeted at the DevSecOps practitioner or platform engineer, it offers an easy-to-use CLI interface, flexible output formats, and automated scanning capabilities.

List of things I have done

Documentations:

• Publishing

Repo and Packages created:

• kubescape/packaging
• OpenSUSE Open Build Service home:kubescape/kubescape
• Ubuntu Launchpad PPA kubescape/kubescape
• Chocolatey kubescape
• Snapcraft Store kubescape
• Arch Linux AUR
• SARIF for Reviewdog

PRs opened:

• (merged) kubescape/kubescape #1095 fix(build): LICENSE file in release tarballs
• (merged) kubescape/kubescape #1105 fix(README): broken links
• (merged) kubescape/kubescape #1140 ci(release): fix publishing krew plugin; add ‘.exe’ extension to Windows binary
• (merged) kubescape/kubescape #1147 Change installation path to ~/.kubescape/bin
• (merged) kubescape/kubescape #1148 arm64 release binaries for CI and Krew
• (merged) kubescape/kubescape #1169 Add kubescape.exe to the release assets
• (merged) kubescape/kubescape #1184 feat(sarif): add fix object in generated reports
• (merged) kubescape/kubescape #1185 fix(fix): mixed up change summary list
• (merged) kubescape/kubescape #1186 Invoke packaging workflow to update after release
• (merged) kubescape/kubescape #1196 Move building instructions to wiki, add more installation instructions
• (merged) kubescape/kubescape #1199 Update installation script
• (merged) kubescape/kubescape #1210 ci: update before install packages
• (merged) kubescape/kubescape #1213 Deprecate kubescape-windows-latest
• (merged) kubescape/kubescape #1214 Add ref to workflow dispatch
• (merged) kubescape/kubescape #1216 Make powershell Windows installation user path available immediately
• (merged) kubescape/kubescape #1236 Deprecate kubescape-windows-latest and fix CI
• (merged) kubescape/kubescape #1238 Fix downloading arm64 binary for kubescape
• (merged) kubescape/github-action #32 Support for code reviews instead with PRs
• (merged) kubescape/github-action #34 Fix start new PR with own repo
• (merged) kubescape/github-action #37 Add exceptions parameters back
• (merged) kubescape/github-action #38 Keep kubescape github-action workflow up to date
• (merged) kubescape/github-action #41 Intergrate fix with comments
• (merged) kubescape/github-action #42 Version bumps start PRs instead of committing directly
• (merged) kubescape/github-action #43 Split the suggest fix workflow and update docs
• (merged) kubescape/vscode-kubescape #11 Remove platformPackages config
• (merged) kubescape/vscode-kubescape #12 Bump kubescape version into v2.3.1
• (merged) kubescape/lens-extension #16 Bump kubescape version into v2.3.1
• (merged) kubescape/node-kubescape #3 Support for ARM64 binaries as well as kubescape.exe
• (merged) kubescape/homebrew-tap #7 Add Auto Release CI
• (rejected) kubernetes-sigs/controller-runtime #2266 Support get config inside snap with SNAP_REAL_HOME
• (rejected) kubernetes/kubernetes #117165 client-go: support detect homedir with SNAP_REAL_HOME and os/user.HomeDir
• (merged) ScoopInstaller/Main #4757 kubescape: Update url and binary naming
• (pending) gentoo/gentoo #30595 sys-cluster/kubescape: new package, add 2.3.3
• (merged) chocolatey-community/chocolatey-packages #2226 (kubescape) Add Kubescape package

Issues opened/helped with:

• (resolved) kubescape/kubescape #195 Provide ARM64 release binaries
• (resolved) kubescape/kubescape #400 Add Kubescape to packages management for easier installation
• (reviewed) kubescape/kubescape #720 Error Fixed when downloading on azure cloud vm environment
• (reviewed) kubescape/kubescape #1014 Package manager support: homebrew
• (resolved) kubescape/kubescape #1015 kubescape installed in first directory in $PATH under $HOME
• (helped) kubescape/kubescape #1033 Generate SLSA provenance for builds
• (reviewed) kubescape/kubescape #1112 can’t install Kubescape with krew on Apple Silicon Mac
• (resolved) kubescape/kubescape #1142 Package manager support: RPM
• (resolved) kubescape/kubescape #1143 Package manager support: deb
• (resolved) kubescape/kubescape #1168 Add kubescape.exe to the release assets to replace kubescape-windows-latest
• (resolved) kubescape/kubescape #1183 Add fix object in Kubescape generated SARIF reports when available
• (reviewed) kubescape/kubescape #1215 Fix issue 11552
• (helped) kubescape/kubescape #1237 Download and Installing Wrong Binary For Apple M1
• (reviewed) kubescape/kubescape #1239 Added instructions to setup kubescape locally
• (resolved) kubescape/k8s-interface #46 Kubescape supports getting packed as a snap app
• (closed) kubernetes/client-go #1261 Get HomeDir from os/user.Current().HomeDir and fallback with $HOME
• (pending response) github/community #52156 Support code auto-fixes for GitHub Code Scanning
• (resolved) chocolatey-community #2186 Migrate kubescape package
• (resolved) chocolatey-community/chocolatey-packages #2190 (kubescape) Migrate package
• (resolved) snapcraft/store-requests #34661 Request for classic confinement and name change for cli-kubescape
• (pending response) snapcraft/snapd #34683 Feature Request: Stop using $SNAP_REAL_HOME to visit real home files

Project summaries

Packaging

• OpenSUSE Build Service (DEB and RPM)
• RPM
• Ubuntu Launchpad PPA
• Homebrew Tap
• Chocolatey
• Snapcraft
• AUR
• Gentoo Portage

Other packages managers that have already been available and not introduced by me during this project period:

• OpenSUSE Zypper
• Homebrew
• Krew (I added the ARM64 support for Krew)
• Nix-pkgs
• Scoop

GitHub Actions Release CI

I helped improve the Kubescape GitHub Actions release CI process, where I added the ARM64 build and tested for the GitHub Actions release CI workflow. I use QEMU with Docker to simulate the Linux ARM64 environment for building and testing the binaries. For macOS M1/M2, I investigated how to cross-build libgit2 C code and use Golang cross-compilation to build the binaries.

I also helped add the auto version bumping CI for kubescape/homebrew-tap, kubescape/packaging, and kubescape/github-action. After the release is made, we trigger these CIs so that the kubescape versions in these repositories can get upgraded automatically.

GitHub Actions Code Review

I helped improve the Kubescape GitHub Actions fix suggestions code review process, where I created the workflow which works by collecting the SARIF (Static Analysis Results Interchange Format) file that kubescape generates. Then, with the help of HollowMan6/sarif4reviewdog, convert the SARIF file into RDFormat (Reviewdog Diagnostic Format) and generate reviews for code fix suggestions on GitHub Actions using Reviewdog. I also helped add the “fix” object support for the Kubescape-generated SARIF report.

In addition to the main project, I also helped the community with other issues like bug-fixing as well as feature-adding.

The May syslog-ng newsletter is now on-line:

• Learning syslog-ng, the easier way
• Why syslog over UDP loses messages and how to avoid that
• Upgrade problems from syslog-ng 3 to 4

It is available at https://www.syslog-ng.com/community/b/blog/posts/the-syslog-ng-insider-2023-05-learning-udp-upgrading

Dear Tumbleweed users and hackers,

This week, timing is on our side – and we pushed out 8 snapshots in 7 days. Of course, this could only happen because openQA was so very swift in testing yesterday’s snapshot – it passed the entire QA run in just a bit over 3 hours (314 test runs).

The snapshots published were numbered 0427 through 0504 and they contained these changes:

• openSUSE:Factory is now using suse_version 1699 (unless you need to distinguish it from ALP, keep using > 1500 or >= 1550 as done in the past. No need to use the new version just yet in normal cases
• Mozilla Firefox 112.0.2
• OpenVPN 2.6.3
• gnome-shell / mutter 44.1 (late joiners for GNOME 44.1)
• Boost 1.82
• postfix 3.8.0
• Mesa 23.0.3
• Wayland 1.22.0
• Linux kernel 6.3.1
• libvirt 9.3.0

Staging projects are quite busy, most relevant changes happening at the moment are:

• Adjustments for packaging guidelines: packages with more than one spec file (multispec) must now mention the additional spec files in _multibuild. This is needed for future changes to git-based source management, where package links are not supported.
• systemd 253.4
• PHP 8.2.5
• libxml2 2.11.1: breaks quite a few things. Users that have the package installed from the devel project (no Tumbleweed QA runs!) experience issues with zypper failing to cache repositories
• Switching default from ffmpeg-5 to ffmpeg-6 (only chromaprint blocks this by now)
• openSSL 3.1: still a few broken packages – see https://bugzilla.opensuse.org/show_bug.cgi?id=1209430
• ICU 73.1: breaks libqt5-qtwebengine