Amidst the holidays that perhaps aren't turning out exactly as hoped, one can take comfort in small tokens of continuity – like the fact that xsnow is still being actively maintained.

Thanks, everyone, for all the good software. Let's extract the best from the year to come.

March 5th, 2022 update: Sigh.

Year 2021 comes to an end, but not before the YaST Team publishes another development report covering areas as diverse as:

• Improvements in the installer self-update mechanism
• Better error reporting in storage analysis
• More consistent management of UEFI
• Better handling of the installer boot arguments
• More intuitive representation of thin logical volumes

Let’s check every one in detail.

Fast Self-Update for All

As you may know, YaST has the ability to update itself at the very beginning of the installation of the operating system. That makes possible to correct the installation process in case errors are detected after publishing a given release of SUSE Linux Enterprise.

Recently we found there was room for improving the speed and also to simplify how the mechanism works in some scenarios. It’s hard to explain exactly what we did in only a few words… so we will not try. ;-) But if you don’t mind reading quite some words and watching a couple of animations, go and check the description of this pull request.

Apart from the already mentioned improvements, we also extended the YaST self-update to support relative URLs. Check the details in this separate pull request.

Better Error Reporting Regarding Storage Devices

One of the most important phases of the execution of YaST, both during installation and when running some of the available configuration modules, is the analysis of the storage setup of the system. That includes checking the available disks and how they are organized into partitions, RAIDs, LVM volume groups and many other storage technologies recognized by YaST. If something goes wrong during that process, YaST stops and asks the user whether it should abort the current process.

That’s fine for most cases. But what happens if a system presents a problematic setup… replicated in more than 60 disks? Those kinds of setups are not unusual in enterprise environments and having to click “continue” 60 times is not exactly fun. So we decided to improve how YaST reports those errors, adding also the possibility of easily reviewing them all at any later point in time from the Partitioner. Check this description of the feature, containing dozens of screenshots!

This new mechanism will be used in future releases of Leap and SLE and is already available in openSUSE Tumbleweed.

More Consistent Management of UEFI

A lot of modern systems use UEFI firmware for booting. But correctly checking if a given system uses that technology or which UEFI features are available may not always be that straightforward. During this sprint we did some internal reorganization of the YaST code which deals with UEFI to make it more robust. Why an internal reorganization may be relevant for our blog readers? Because we took the opportunity to document how the detection works and how it can be overridden for YaST to setup UEFI from a system booting in legacy x86 mode and vice versa.

Better Handling of the Installer Boot Arguments

What do self-update, error reporting and UEFI detection have in common in YaST? Of course, that all of them have been mentioned on this blog post. But also that their behavior can be influenced passing some boot parameter to the installer. That’s a powerful tool for advanced users that provides great flexibility but that had a tiny drawback… until it was fixed during this sprint.

Intuitive Visualization of LVM Thin Volumes

The last change we want to highlight in this report is something that may be considered cosmetic and that affects only those using such an expert tool as LVM thin logical volumes. But it represents the kind of details we really enjoy improving when we have some spare development cycles. The small UI adjustment you can see in this pull request is already available at openSUSE Tumbleweed and will be also there in future releases of SLE and openSUSE Leap.

That’s all for this year

As we always point, this is only a small sample of everything we have done during the sprint. But we don’t want to keep you busy reading about bug-fixes and small code reorganizations. After all, year 2022 is around the corner and it’s already vacation season in many areas around the globe. So go and enjoy the celebrations. The YaST Team will be here next year with more news to share. Take care!

I drafted a post on how the Dirtywave M8 is an amazing synth, but given the time and the growing scope of that post, I’ll sum it up in a short blurb instead. For a single man project, this synth is a miracle. Very geeky, all shortcut driven, standing on the shoulders of tracker giants, particularly LSDJ, it has a solid workflow and most definitely isn’t a gimmick. You’ll have to do without any visual aid. This is what I love on the Elektron boxes, where the display really helps you understand what you’re doing when filtering or creating an LFO. All you have here are hex numbers and consistent shortcuts. But it sounds absolutely marvelous and allows you to create music anywhere.

I’d like to share two tracks I’ve learned the ropes of the device on, but also the genre itself. I’ve listened to DNB mainly through Noisia/Vision radio podcast that made my runs possible (I hated running all my life, but it’s really the best way to combat the negative effects of sitting behind a computer all day). But I’ve never actually tried producing a track within that DNB realm.

While I lean on samples for the beats, the base is all the internal FM (with multiple oscilator types, not just sine) and macrosynth engines.

I’ve also been learning the ropes of Blender’s geometry nodes recently. While only scratching the surface, I created this visualizer for the track. The heavy lifting is done with baking the sound to f-curves, which is then somewhat tweaked to acceptable ranges with f-curve modifiers.

I also have to mention the absolutely bonkers amazing visual identity of the M8 project. It just couldn’t be more hip. This is also my very last gear acquisition. For sure.

Previously, Previously, Previously, Previously, Previously, Previously, Previously.

10th of my 21-day quarantine*! And to celebrate, I'm going to release a new version of geewallet. It's not that I blog about geewallet releases often (or blog at all, lately), but this one is a special one for me. We decided to call it 0.4.300.0

The highlights:

• We fixed the GTK theme for our snap package. (Long version of the story: ever since we upgraded our snap generation process to take place in Ubuntu 20.04 instead of Ubuntu 18.04, the theme stopped working so the app was not showing anymore with the default theme of the system, but with the default Gtk theme, which is very plain. Even if you might consider this issue important, we haven't had time to look at it because we've been very busy finishing Lightning support. Sorry.)
• The chart rendering doesn't use SkiaSharp anymore, but good-old Cairo. This fixes some UI glitches that we had in the GTK frontend. (Long version: for this, we didn't just draw the chart using Cairo in our Gtk frontend, we actually wrote an implementation of the Shapes API for the Xamarin.Forms' GTK backend, and we contributed the work upstream: https://github.com/xamarin/Xamarin.Forms/pull/14235 . Hopefully they merge it soon so that we don't need to use our own forked repo/nuget anymore.)
• Fixed a crash when pairing with a cold-storage wallet. (Long version: user might not know that pairing is only allowed against another geewallet instance; low-hanging fruit bugfix which I shouldn't have neglected for so long, I know.)
• Fixed a crash when scanning some QR-codes that contained unknown parameters in the bitcoin URI. (Long version: I was actually in El Salvador and when trying to use a BTM, I found this bug! Apparently some BTMs here add an extraneous "chivo" param in the URI's querystring, in case the wallet being used is the one from the government; not sure why. In this case, geewallet was failing fast instead of ignoring the unexpected intruder.)

Over the next few days, all Horde libraries and apps in the maintaina-com organization will be whitelisted for PHP 8x. in their FRAMEWORK_6_0 branch development versions. One next step will be a flavour of the OpenSUSE based containers and deployments which runs off PHP 8.0. While some few libraries have been enabled for PHP 8, it is almost certain that horde as a whole will not run correctly. Main culprits are the horde/rpc and horde/form packages and their user code, but there are some other ugly places that need attention.

Development Baseline at 7.4

Code in the maintaina-com repo will stay compatible with PHP 7.4 – at least for the time being. Decisions at Horde LLC may override that at some point or time may just march on. PHP 7.4 has been released two years ago, has ended active support 20 days ago and will be EOLed for upstream security support on November 28th 2022 – roughly 11 months to go. Linux distributions have a tradition to follow their own schedules and backport security fixes. OpenSUSE LEAP 15.3 ships with PHP 7.4 while openSUSE Tumbleweed has switched to PHP 8.0.13 – with PHP 8.1 versions becoming available from official repos soon.

This is a tough decision as PHP 8 and 8.1 have some really interesting features which would allow us to develop more elegant, more readable and more efficient code. For software that is not intended for this audience, I will immediately allow using 8.x-only features as soon as we are confident with Horde’s compatibility. This is going to be a major theme of January and possibly February.

No need to switch right now

If you are running Horde as of horde.org master branches or maintaina-com FRAMEWORK_6_0 branches off PHP 7.4, you should NOT switch right now. We will announce once we think any leftover issues are minor enough for an acceptable early adopter experience.

No particular love for 8.0.x

There is no guarantee our runtime will stay fixed at 8.0. PHP 8.1 offers a lot of new features and a considerable performance boost for some relevant scenarios. While making Maintaina Horde work with 8.x on a 7.4 feature baseline is the first step, the logical next step is upgrading feature baseline to 8.1 or higher. This will be much less of a problem if we get an official Horde 6 release in the meantime and users can choose between a properly conservative release version and a more adventurous Maintaina version. This is not something I have under control though. Horde LLC do as they find appropriate and sustainable and for many users, there is little reason to choose Maintaina over the official releases once we have a Horde 6 version that properly runs on recent PHP and supports Composer out of the box. I am perfectly fine with that and looking forward to it. I will always assist with a migration path as far as I can afford to.

Time is Money, Money buys Time

If you have an urgent commercial interest in a PHP 8-ready Horde version, you really do not want to rely on Maintaina’s timelines and priorities which may be subject to change. You will need to spend money. Approach somebody to do it for you, either Horde LLC or the company I work for, B1 Systems GmbH – both are formidable places to look for Horde-experienced development resources.

Update 2021-12-18 21:00 CET

I just ran the update to the metadata as a mass operation for everything which contains a .horde.yml file – the rest will have to wait until I stumble across it. I leveraged an edited version of horde/git-tools, some bash magic, some mass editing in vscode using their regex tool and some manual fixing.

• All packages now formally require “php”: “^7.4 || ^8”
• If horde-installer-plugin is required, I now go for “^2 || dev-FRAMEWORK_6_0” – however in maintaina-com/Core, I have a job that rebuilds composer.json on commit and this job showed me that the components tool needs an update in this aspect.
• SPDX license code warnings for LGPL and GPL versions have been remedied to LGPL-2.0-only, LGPL-3.0-only, GPL-3.0-only each
• Added the CI workflow where missing. Mostly it will fail until further editing. This is intentional.
• I did NOT unify all versions of CI workflow as some deviations are intentional. I did however unify PHP versions for the unit tests to “7.4”, “8.0” and “latest” and I did unify phpunit versions to “9.5” and “latest”.
• Unified/added the phpdoc workflow and the update-satis workflow as we had multiple versions for no good reason. I have settled for a version of the phpdoc job that will scan lib/, src/ and app/ if they exist
• Cleaned up a lot of metadata mess in the Kolab related packages.
• Removed some version: tags from composer.json files
• Removed the optional pear dependency of imp for the ASN1 implementation from phpseclib – need to look for a proper composer-ready and less outdated replacement.

While the mass changes themselves seem to have gone right, the resulting avalanche of CI jobs showed some issues:

• phpdoc job and update-satis job fail if they run in parallel and the satis repo content has changed since checkout. Either give the push commands in the loop a minute to wait each time or make the job smarter about handling these clashes. Still, failing is better than silently overwriting content
• Having so many versions of the CI job is not maintainable. Need to factor out the boilerplate into an action, make version requirements a config variable with a builtin default and have some mechanism for there rare cases where extra software is needed for meaningful QA, i.e. database and storage related items.

• After getting this migration done, upgrading the git-tools utility may be an interesting exercise in PHP 8 and PHPStan.

• I may have created unnecessary conflicts with some open pull requests. Sorry, contributors. I will improve.

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

• Sending logs to Panther using syslog-ng
• Reducing the complexity of log management
• Sending logs to Humio using the elasticsearch-http() destination of syslog-ng

It is available at https://www.syslog-ng.com/community/b/blog/posts/the-syslog-ng-insider-2021-12-humio-log-management-panther

There was no slowing down of snapshots this week as new software continues to flow with daily openSUSE Tumbleweed releases. Tumbleweed went seven for seven this week!

Just two updates were in the 20211214 snapshot. The remote accessing package remmina 1.4.22 provided fixes for freerdp3 compatibility, and remmina also had a fix for a crash if the main window is closed. The libcap-ng 0.7.11 package, which analyzes a system for apps with too many privileges, removed unneeded rules.

Among the many packages that arrive in snapshot 20211213 were KDE’s Gear 21.12.0 and Frameworks 5.89.0 versions. Gear 21.12.0 had some Dolphin file manager enhancements like a Ctrl + i filter feature that brings up a box under the main panel, which added a new Detailed View feature through a right click on an empty space; select the View Mode > Details from the pop up menu. The screenshot application Spectacle gives KDE users a cleaner look of images they drag and drop from Spectacle’s preview panel to Dolphin or to an online image storage site for sharing. The Kdenlive video editor from Gear improved the motion tracking tools; Just use the box in the monitor to cover the area to track, click Analyse in the effects panel, and have fun! The video editor also has a new audio effect that removes background noises from recordings; the Noise Suppressor allows for a voice grab in the audio effects tab to be dropped onto an audio track for clean up. Frameworks 5.89.0 had a considerable amount of bug fixes for the Breeze Icons, which included the addition of a missing kmail breeze icon. The KContacts fixed address formatting for country-only addresses and deprecated countryToISO/ISOToCountry in favor of KCountry. Both KIO and Kirigami had some changes; the latter package lets the escape key close and push the dialog layers. The application library exo updated to version 4.16.3 and fixed compilation warnings; the package that is targeted at application development for Xfce also added typecheck verification to prevent a GTK bug warning. The mpg123 1.29.3 package fixed typos and added a note about equalizer frequency bands in the man page. The updated 370 version of xterm improved performance over slow connections and suppressed the loading of italic font in a few places when the colorITmode is enabled. Other packages to update were yast2-bootloader 4.4.10 and yast2-storage-ng 4.4.23, which added support for mount options use with libstorage-ng to determine whether a efibootmgr is available.

The second update of the week for the Advanced Linux Sound Architecture package arrived in snapshot 20211212. The alsa 1.2.6.1 version fixed the configuration for device parsing. Several alsa changes were made in the kernel-source 5.15.7 update. The kernel also had several KVM fixes to include a shadow nested paging that does not have Protection Keys for Userspace. Since there is now a require dependency, wireplumber became the session manager for pipewire 0.3.40 in the snapshot; “when in doubt, the suggested package is selected,” according to the changelog. The python-cryptography package updated from version 3.4.8 to 36.0.0, which went through a version number change in September. The new Python Package Index has the entire X.509 layer written in Rust; this allows alternate asymmetric key implementations that can support cloud key management services or hardware security modules provided they implement the necessary interface. About 10 more updates arrived in the snapshot.

Quite a few GNOME packages received a version bump in snapshot 20211211. While there were translation updates for gnome-maps 41.2, gnome-software 41.2 fixed a crash when processing age ratings and reloaded application details only when the items were not installing/removing the application. The gupnp 1.4.1 package fixed a regression in the async deprecated Application Programming Interfaces. Mozilla Firefox 95.0 updated in the snapshot, and fixed some Common Vulnerabilities and Exposures. The release appears to be a nod at Windows 95 now that the browser is available in the Microsoft Store. A fix in the use of the default log writer with journald namespaces was made in the glib2 2.70.2 update. Other packages to update in the snapshot were hwdata 0.354, FireEye’s hxtools 20211204, LibreOffice 7.2.4.1, Node.js, 16.13.1, vte 0.66.2, yast2-installation 4.4.28 and more.

Three packages were updated in snapshot 20211210. An added method to disconnect proxy signals was made in the gnome-remote-desktop 41.2 update; the package, which can also be used for screencasting, made warning messages a little bit more explicit. The Linux laptop battery Optimizing package tlp 1.4.0 renamed “Battery Features” to “Battery Care” and introduced plugins to support Battery Care for non-ThinkPads; ASUS, Huawei, LG, Lenovo and Samsung are the first to benefit from the plugins. The kernel headers were updated in the linux-glibc-devel 5.15 release.

Most of the updates in snapshot 20211209 were PyPi updates with the exception of the libffi 3.4.2 and nvme-cli 1.16 updates. Snapshot 20211208 provided the first asla 1.2.6 update, which improved the support of multiple formats in the Pulse-code modulation. The sudo 1.9.8p2 package fixed a few minor memory leaks and sudo_logsrvd now only sends a log ID for the first command of a session, so there is no need to send the log ID for each sub-command. Several other packages were updated in the snapshot like screen reader orca 41.1, soundtouch 2.3.1 and yast2-journal 4.4.1, which is preparing code for Ruby3 along with many other YaST packages.

Almost a year ago, on the 19th of December 2020, openSUSE Members knurpht and m4u had the following conversation:

Gertjan™ - Knurpht™, [19.12.20 00:05]
Dude, have a drink on meet.opensuse.org/beer?

Gertjan™ - Knurpht™, [19.12.20 01:11]
Yo, we( Neal and me are waiting for you to show up

Maurizio G., [19.12.20 05:36]
let’s see how i feel after coffee

Maurizio G., [19.12.20 05:38]
are you and neal still in the BAR?

Gertjan™ - Knurpht™, [19.12.20 05:39]
Nope
We were in the beer btw 😃

Maurizio G., [19.12.20 05:41]
yea i saw your message

Maurizio G., [19.12.20 05:41]
i’m just waking up. maybe in a bit

Gertjan™ - Knurpht™, [19.12.20 05:42]
Now in meet.opensuse.org/BAR

This was the birth of our beloved openSUSE BAR! Since then, the BAR has been a place for contributions, for fixing things together and just hanging out.

The BAR evolved into an important part of our community that helps people get to know each other in the project. It has on-boarded new contributors, strengthened old friendships, brought fixes for various issues on the way and was the place for historical events, such as probably the oldest openSUSE User (89 y.o.) meeting the youngest openSUSE Member (16 y.o.).

During the online openSUSE Leap 15.3 release party, which was aimed to last for 24 hours, the bar passed the marks of a 50+ guests and a 100-hour-BAR session on June 6, 2021, which was followed by reaching a mark of a 200-hour-BAR session on June 10, 2021.

To celebrate the first-year anniversary of the BAR, the second largest BAR event is going to begin on Dec. 18 starting 16:00 UTC at meet.opensuse.org/bar!! Let’s see how long we can keep the party going this time!

We definitely look forward to seeing you all there!! New faces, old friends, those that visit the BAR regularly, and those who have never logged on before. Cheers!

NOTE: Please don’t be discouraged if it takes you a couple of tries to connect! Just keep trying!! Just keep trying and mash the F5 key to refresh, you won’t regret it!!

The openSUSE BAR Crowd

Let me share my Fedora story with you. Hopefully, it helps you to understand, why I am also promoting AlmaLinux and Rocky Linux, even if I am an active Fedora and CentOS community member and contributor.

Before the beginnings

Someone suggested me to try Red Hat Linux in 1995 and replace Slackware Linux with it on my university server. I installed it, but I did not become a fan. And when I found the print out of the password file of my server on the wall of the Russian students' computer lab (see: https://peter.czanik.hu/posts/russian_students_logging/), I quickly switched to Jurix, which already featured shadow passwords. And as Jurix became the base for SUSE Linux, I became a SUSE Linux and later an openSUSE user.

The beginnings

When I started to work at Balabit (now part of One Identity) almost twelve years ago, one of my first tasks was to ensure that the latest version of syslog-ng is available in Linux distributions and FreeBSD. I reached out to package maintainers and helped them to update the syslog-ng package. It went quite well in most cases, but I was stuck with Fedora and EPEL updates. I tried to reach out to developers through official and unofficial channels without luck.

While talking to syslog-ng users, I tried to figure out what OS they use. It turned out that even if syslog-ng was the default syslog implementation in openSUSE and SLES, our most active users were running syslog-ng on RHEL and CentOS. So, I became even more active trying to resolve the syslog-ng package situation, still without luck.

The turn of events arrived almost a year later at FOSDEM. What could not be solved with tickets and e-mails was resolved within five minutes at the Fedora booth in person at FOSDEM. I met a Hungarian Fedora ambassador there who connected me with the right people, and syslog-ng was soon updated to the latest version.

Friends

Freedom, friends, features, first, are the four core values of Fedora. From those “Friends” became very important to me. Even if my operating systems of choice are openSUSE (https://peter.czanik.hu/posts/opensuse_memories_1/) and FreeBSD, I do not have many friends in those communities. However, soon after that initial meeting at the Fedora booth at FOSDEM I got many friends in the Fedora community, both here in Hungary and abroad. I helped in organizing some local gatherings and soon I was asked to become a Fedora ambassador. I gave Fedora talks at various events and helped maintaining the Fedora booth around Europe.

syslog-ng packaging

At first I helped syslog-ng package maintainers with upstream information. Soon I was asked to become a co-maintainer for the syslog-ng package in Fedora and EPEL. I did minor version updates, new syslog-ng features, while the original maintainers did larger changes, like enabling systemd support, new EPEL versions, and so on.

For the past couple of years I maintain syslog-ng mostly alone, both in Fedora and EPEL. I also have my unofficial packages in Copr. This is necessary, as the EPEL policy does not allow version upgrades, while users want to use the latest syslog-ng features.

CentOS Stream and the new RHEL clones

When the end of the traditional CentOS Linux was announced, many syslog-ng users cried out loud. Based on my estimates, about 80% of syslog-ng users run CentOS or RHEL, so I’m monitoring the situation as much as I can. I had a couple of Twitter polls, e-mails on the syslog-ng mailing list and direct discussions with some of our power users.

Only very few organizations seem to be enthusiastic about CentOS Stream. They tend to have their own OS team in house, which does its own OS release based on CentOS. In their case the Stream model made their life easier. The rest of users still seem to prefer the traditional release model.

Based on user feedback it seems, that most of our users will stay on RHEL and compatible operating systems. Some already made the switch: small companies changed from CentOS Linux to RHEL. But many larger installations running thousands of hosts are switching from CentOS to AlmaLinux. While others are switching to Rocky Linux and even Oracle Linux. And some to my favorite non-Linux OS: FreeBSD.

Friends vs. OS

While I have many friends in the Fedora and CentOS developer and user communities, these operating systems are just part of my syslog-ng work. To me it does not matter at all which OS people use to run syslog-ng. If suddenly all syslog-ng users started to use Slackware, I could easily drop my Fedora-related activities and focus on Slackware. Luckily, from the syslog-ng standpoint, support for RHEL, Alma, Rocky and Oracle is the same. I keep using the same tools, same workflows, and in bug reports I only see that people use packages from the Copr repository I maintain. No idea about the OS vendor.

TL;DR: The OS I support for syslog-ng and friendships are two completely separate things. Fedora made me many friends, and I’m grateful for that.