Members of the openSUSE Brazilian community are getting together for a release party on June 15 for openSUSE Leap 15.4.

The team is developing a full schedule and will be doing live lectures and will give away a few items.

The event will be on YouTube and people are asked to sign up for a ticket to receive the participation link.

The event will run from 1 to 6 p.m. Brazilian Standard Time (16:00 UTC - 22:00 UTC). Leap 15.4 will be released on June 8.

Important Notice

With my new blogpost Installation of NVIDIA drivers on openSUSE and SLE this article here became more or less obsolete. So it is highly recommended to read my new article there instead.

Introduction

On May 19, 2022 NVIDIA made a release of their Open GPU kernel modules for their newer GPU platforms (Turing and newer) with Risc-V system processor. Meanwhile we have packages available in our currently supported openSUSE/SLE distributions. If you want to use these you need to install nvidia-open-driver-G06-signed package.

Installation

Installation instructions since Leap 15.6/SLE15-SP6 and Tumbleweed:

# will install needed packages
zypper in nvidia-open-driver-G06-signed-kmp-default

Find supported Turing/Ampere/Hopper/Ada/Blackwell GPUs here. Check with inxi -aG. Use hwinfo --gfxcard on SLE.

Display Drivers

nvidia-video-G06, nvidia-gl-G06 and nvidia-compute-utils-G06 packages are available via NVIDIA’s openSUSE/SLE repositories, which then can be used together with NVIDIA’s Open GPU kernel modules above.

Installing Display Drivers on Leap 15.6/Tumbleweed/SLE15-SPx

# if you have not added this repository yet
# Leap 15.6
zypper addrepo https://download.nvidia.com/opensuse/leap/15.6/  nvidia
# Leap 16.0 (Beta)
zypper addrepo https://download.nvidia.com/opensuse/leap/16.0/  nvidia
# Tumbleweed
zypper addrepo https://download.nvidia.com/opensuse/tumbleweed/  nvidia
# SLE15-SP6
zypper addrepo https://download.nvidia.com/suse/sle15sp6/  nvidia
# SLE15-SP7
zypper addrepo https://download.nvidia.com/suse/sle15sp7/  nvidia
# SLE16 (Beta)
zypper addrepo https://download.nvidia.com/suse/sle16/  nvidia

# install all required packages
version=$(rpm -qa --queryformat '%{VERSION}\n' nvidia-open-driver-G06-signed-kmp-default | cut -d "_" -f1 | sort -u | tail -n 1)
zypper in nvidia-video-G06 == ${version} nvidia-compute-utils-G06 == ${version}

CUDA

With that - after installing nvidia-compute-utils-G06 (which requires nvidia-compute-G06, which contains libcuda) - you can experiment with CUDA. Install CUDA stack from NVIDIA’s webserver.

Installing CUDA on Leap 15.6/Tumbleweed/SLE15-SPx

# if you have not added this repository yet
# Leap 15.6/16.0(Beta)/Tumbleweed
zypper addrepo https://developer.download.nvidia.com/compute/cuda/repos/opensuse15/x86_64/  cuda
# SLE15-SPx/SLE16(Beta) (x86_64)
zypper addrepo https://developer.download.nvidia.com/compute/cuda/repos/sles15/x86_64/  cuda
# SLE15-SPx/SLE16(Beta) (aarch64)
zypper addrepo https://developer.download.nvidia.com/compute/cuda/repos/sles15/sbsa/  cuda

# will install needed CUDA packages
zypper in cuda-toolkit-12-8

# Unfortunately the following package is not available for aarch64,
# but there are CUDA samples available on GitHub, which can be
# compiled from source: https://github.com/nvidia/cuda-samples
zypper in cuda-demo-suite-12-8

Let’s have a first test for using libcuda (only available on x86_64).

/usr/local/cuda-12.8/extras/demo_suite/deviceQuery

CUDA Minimal Installation

Users, who don’t need a graphical desktop, can omit the installation of the display driver packages above and perform a CUDA Minimal Installation instead.

version=$(rpm -qa --queryformat '%{VERSION}\n' nvidia-open-driver-G06-signed-kmp-default | cut -d "_" -f1 | sort -u | tail -n 1)
zypper in nvidia-compute-utils-G06 == ${version} cuda-libraries-12-8

Longterm Kernel on Tumbleweed

In case you’re using Tumbleweed’s longterm Kernel (kernel-longterm), please replace default with longterm in the commands above, i.e.

[...]
# Installation
zypper in nvidia-open-driver-G06-signed-kmp-longterm
[...]
# Display Drivers / CUDA Minimal Installation
version=$(rpm -qa --queryformat '%{VERSION}\n' nvidia-open-driver-G06-signed-kmp-longterm | cut -d "_" -f1 | sort -u | tail -n 1)
[...]

Feedback

If you have questions, comments and any kind of feedback regarding this topic, don’t hesitate to contact me via email. Thanks!

Recently I was packaging one of the Retro freeware games, which are supported by the ScummVm project. It’s called Drascula: The Vampire Strikes Back and the story is some kind of strange mixture between Dracula and Frankenstein.

Language Support

When testing the language support I noticed, that it has been originally developed by a company in Spain called Alcachofa Soft S.L., so additional to English it also includes speech in Spanish. Subtitles are available in English, German , French, Italian and Spanish. Therefore I decided to try improving my Spanish language skills and began to play this Adventure. And although the game is from 1996 I enjoyed it a lot!

I figured out that if you press SPACE while a character is speaking, the sentence will be interrupted (apart from the voice part). And by pressing SPACE again the game continues. Which was rather useful for me in order to have more time for reading and understanding the subtitles. Press F7/F10 to load/save the game.

Installation

You can find drascula and scummvm packages in the games repository of the openSUSE Build Service.

Installation instructions for openSUSE Leap:

# if you don't have added the 'games' repository yet
# Leap 15.4
zypper addrepo https://download.opensuse.org/repositories/games/openSUSE_Leap_15.4/  games
# Leap 15.5
zypper addrepo https://download.opensuse.org/repositories/games/openSUSE_Leap_15.5/  games
# will install 'scummvm' package and other dependancies automatically
zypper in drascula

Then just run the command drascula, select your language (via xmessage - isn’t this retro?) and enjoy!

Need help?

And in case you struggle - Walkthroughs are available on Youtube - also in Spanish. :-)

Running on Windows, MacOS, etc.

In case you’re using Windows, MacOS, etc. There are precompiled executables of the ScummVM program availabe for download on the ScummVM Download Page, which you can easily install on your machine. Don’t forget to download also the Drascula datafiles. You will need: Freeware Version (English), Freeware Version (Music Adon, OGG format) and Freeware Version (Updated Spanish, German, French and Italian AddOn). Extract all of them in your favorite directory (readme.txt can be overriden), then run scummvm, press Add Game and Choose the directory, into which you installed the Drascula datafiles right before. Now select Graphics, enable Override global graphic setting, set Scaler to HQ and 3x and enable Fullscreen mode. Now select Audio, enable Override global audio setting and set Text and speech to Both. Press Ok. Then press Start to start the game. Have fun!

We will see in this link in Brazilian Portuguese, how to install the NVIDIA opensource kernel module, however version 515.48.07, GeForce and Workstation support is still considered alpha quality. So to force the installation, we must use the parameter NVreg_OpenRmEnableUnsupportedGpus as we will see in blog Assunto Nerd from Brazil.

Dear Tumbleweed users and hackers,

Last week, I skipped the review as over here, Thursday was a holiday and I decided to take Friday off as well and make for a long weekend (for a $random value of ‘off’ as it turned out). In total, Tumbleweed has seen 13 snapshots since the last review, which means it was ‘almost daily’ with one gap {0519..0601, except for 0529 – and 0526 was published, but never made it to the mirrors due to a config error)

Those 13 snapshots brought you these changes:

• LLVM 14.0.4
• Virtualbox preparation for upcoming Kernel 5.18
• gnutls 3.7.6
• GNOME 42.2
• systemd 250.6
• Perl 5.34.1
• Mozilla Firefox 100.0.2
• Linux kernel 5.17.9
• Mesa 22.1.0
• Pulseaudio 16.0
• Buldflag FORTIFY_SOURCE=3

Last Friday, we had some issues with qemu, which would not start up anymore, reporting buffer overflows. The package had a patch added, and openQA has reported on that issue. I wrongly connected the two things (i.e patch causing the buffer overflows). So I reverted qemu in Factory and published that reverted into the Update channel, and giving those openQA fails a pass. Turned out this was wrong and Friday was spent together with Dario and a lot of testers to get to the actual root of the problem and give you a working qemu package back as quickly as possible. Apologies for the trouble caused there.

For the future, we are having a few things in Staging already again and will try to keep up with a good cadence of snapshots. The most interesting changes being worked on are:

• Linux kernel 5.18.1 (Snapshot 0602+)
• Mozilla Firefox 101
• Mesa 22.1.1
• KDE Plasma 5.25 (beta staged, release planned for mid-June)
• SELinux 3.4
• Python 3.10 as the default interpreter

Over the past week I worked on merging the atk and at-spi2-atk repositories into at-spi2-core. A quick reminder of what they do:

• at-spi2-core: Has the XML definitions of the DBus interfaces for accessibility — what lets a random widget identify itself as having a Button role, or what lets a random text field to expose its current text contents to a screen reader. Also has the "registry daemon", which is the daemon that multiplexes applications to screen readers or other accessibility technologies. Also has the libatspi library, which is a hand-written binding to the DBus interfaces, and which is used by...

• at-spi2-atk: Translates the ATK API into calls to libatspi, to effectively make ATK talk DBus to the registry daemon. This is because...

• atk: is mostly just a bunch of GObject-based interfaces that programs can implement to make themselves accessible. GTK3, LibreOffice, and Mozilla use it. They haven't yet done like GTK4 or Qt5, which use the DBus interfaces directly and thus avoid a lot of wrappers and conversions.

Why merge the repositories?

at-spi2-core's DBus interfaces, the way the registry daemon works, atk's interfaces and their glue in at-spi2-atk via libatspi... all of these are tightly coupled. You can't make a change in the libatspi API without changing at-spi2-atk, and a change in the DBus interfaces really has to ripple down to everything, but keeping things as separate repositories makes it hard to keep them in sync.

I am still in the process of learning how the accessibility code works, and my strategy to learn a code base, besides reading code while taking notes, is to do a little exploratory refactoring.

However, when I did a little refactoring of bit of at-spi2-core's code, the tests that would let me see if that refactoring is correct were in another repository! This is old code, written before unit tests in C were doable in a convenient fashion, so it would take a lot more refactoring to get it to a unit-testable state. I need end-to-end tests instead...

... and it is at-spi2-atk that has the end-to-end tests for all the accessibility middleware, not at-spi2-core, which is the module I was working on. At-spi2-atk is the repository that has tests like this:

• Create a mock accessible application ("my_app").
• Create a mock accessibility technology ("my_screen_reader").
• See if the things transferred from the first one to the second one make sense, thus testing the middleware.

By merging the three repositories, and adding a code coverage report for the test suite, we can add a test, change some code, look at the coverage report, and see if the test really exercised the code that we changed.

Changes for distributions

Please see the announcement on discourse.gnome.org.

That coverage report is not accessible!

Indeed, it is pretty terrible. Lcov's genhtml tool creates a giant <pre>, with things like the execution count for each line just delimited with a <span>. Example of lcov's HTML.

(Librsvg's coverage report is pretty terrible as well; grcov's HTML output is a bunch of color-coded <div>. Example of grcov's HTML.)

Does anyone know code coverage tools that generate accessible output?

Members of SUSE and openSUSE have deleloped several Work Groups (WG) to discuss the formation of the Adaptable Linux Platform. Below readers can see the latest brief from the various WGs involved in the open-source project.

The System Management WG has been progressing with the branding of Cockpit. They have been experimenting with attempts to containerize it; though outside of a possible chance to use wormholing, it doesn’t look promising. They do continue to add functionality to YaST in cointainers at a good pace.

The ALP Virtualization team has taken some technical decisions regarding support, etc. In their first technical meetings regarding VMs inside of containers, some work was done looking for the best approach and blocking points.

In the Build Service Next-Generation WG, the initial feedback shows little interest in a git-based packaging approach. Software as a Service options via git hosting continue to be very expensive, though on-premises options should be considered. A self-hosted Gitea appears to be the best option so far, while the current discussions for Large-File-Storing-in-Git have been paused at this time.

The Components delivery & lifecycle WG’s goal is to find an alternative way to ship packages with different lifecycles. With this in mind, the group has been gathering input on RHEL’s modularity, in order to compare and learn what they can from them.

The Confidential Computing WG has been collecting information to determine where they want to be in the long term, and what can be achieved in a given period of time. This allows them to establish a timeline within Confidential Computing to support upstream projects in their endeavors.

The Container Management Frontend WG strongly favors Podman for it’s systemd integration, potentialy allowing for services-as-containers and RPM-delivered services. Docker may be required as well, along with Rancher and nerdctl/containerd embedded with their products. The group would appreciate feedback on the technology decision from other WGs, as so far there was none.

The Container Easy Deployment and Installation WG has been discussing problem space and preliminary research into quadlet and systemd portable services, etc.

The Community WG has drafted a communications plan and identified topics that are relevant to the current state of the project. Weekly meetings have been established and publish minutes are available at https://etherpad.opensuse.org/p/weeklymeeting. Group encourages all other WG to make public updates on their own, and recomemends YaST team as a role model.

The Deployment/Management Framework WG is looking to identify and decide on which configuration and management tool will be the next generation. The two current options looking best to meet customers needs and integrate into the rest of SUSE’s products look to be SALT and Ansible.

The Desktop WG is looking into a remote-Wayland-based remote desktop with a focus on a headless GNOME solution. Other discussions are focused on lightweight windows managers and desktops without Xorg, containerizing the GNOME core stack, and Nvidia open source kernel modules in Wayland.

The Documentation WG is starting to update the look and feel of the documentation pages for better navigation.

The Data Processing Unit (DPU) Integration team is looking into ongoing business and technical discussions with Dell.

Full-disk encryption experts are looking to use LUKS2 for TPM-auto unlocking (on systems which support it) and to design simple and secure, yet easy to use encrypted systems.

The High Performance Computing WG is participating in multiple community projects to develop and enhance a state-of-the-art deployment systems.

The Installation and Deployment WG is discussing an evolution of the traditional installer, including modularity to make it more useful. There may also be an option to create customized images on the fly for deployment.

The Kernel and Live Patching team is currently busy with the launch of Userspace Live Patching.

Kernel Performance Testing has kicked off with a focus on defining the scope and setup during biweekly calls and a mailing list for furthing discussions.

Qualiting Engineering assigned representatives to most other workgroups and planned a kicked off a meeting and created a slack channel.

Security Framework WG has benn constitued and held a kick off call. Discussions are being held on how to make a smooth switch from AppArmor to SELinux and how to prepare for it.

The Telemetry WG has been collecting data needed to summarize requirements to measure subscriptions.

There will be several discussions at the openSUSE Conference the next couple days. People interested in ALP news and WGs can register for the conference and watch the discussions online.

Red Hat Enterprise Linux 9 became generally available recently. Version 3.35 of syslog-ng has been part of EPEL 9 (the semi-official extra software repo for RHEL maintained by Fedora packagers) for a while and now I enabled a few more destination drivers. I also enabled RHEL 9 support in my unofficial Git snapshot packages, so I can support RHEL 9 together with other RHEL and Fedora versions on the next syslog-ng release.

You can read the rest of my blog at https://www.syslog-ng.com/community/b/blog/posts/rhel-9-syslog-ng-news

There are situations where you cannot avoid giving a user full shell access through sudo. A shell with administrative privileges gives complete control over your hosts. Until recently, sudo could only log the start of the shell, not the commands executed within it. You could record sessions with sudo, but watching recordings is boring, time consuming and can still be subverted. Version 1.9.8 introduced logging of sub-commands, but that is not yet available on many systems. An alternate approach is to use auditd to log commands started from a root shell.

From this blog you will learn how to use auditd to log commands from a sudo-run root shell, why it is better to use the sub-command logging built into recent sudo releases, and why you should still record sessions with sudo.

You can read the rest of my blog at https://www.sudo.ws/posts/2022/05/looking-inside-sudo-shell-sessions-auditd-session-recordings-log_subcmds/