A Community Effort to Teach Linux Early Published on behalf of Coly Li, with his permission To help children interested in artificial intelligence and information technology grow up with basic Linux skills, Coly Li started a voluntary Linux study group. He created it together with other parents from his child’s school who share an interest […]

The post Teaching Linux to Kids With openSUSE Leap 16.0 appeared first on SUSE Communities.

A Hack Week 25 project seeks to finish a native SSH implementation written in the Zig programming language that gives developers a lightweight, flexible alternative for experimenting with the secure-shell protocol.

The effort builds on an incomplete implementation that already covers primitives, keys, certificates and much of the agent protocol.

The project’s work so far lives at a SourceHut repository and the immediate goal is to produce a working SSH stack in Zig that is easy to extend for research and experimentation.

Contributors can help finish the protocol flows and broaden cryptographic support so the code can be used for tasks such as testing post-quantum cryptography (PQC) algorithms.

Project goals include:

• Have a working implementation of the ssh protocol in Zig.
• Be flexible, as to allow for hacking of the protocol (i.e. testing PQC algorithms).
• Be agnostic of cryptography libraries (i.e. libcrypto, leancrypto).

Resource links by the project maintainers include several Internet Engineering Task Force Request for Comments (RFC) that define SSH and related extensions, plus Zig’s own documentation to guide implementers.

Interested developers can join the Hack Week project or follow the progress.

Hack Week, which began in 2007, has become a cornerstone of the project’s open-source culture. Hack Week has produced tools that are now integral to the openSUSE ecosystem, such as openQA, Weblate and Aeon Desktop. Hack Week has also seeded projects that later grew into widely used products; the origins of ownCloud and its fork Nextcloud derive from a Hack Week project started more than a decade ago.

For more information, visit hackweek.opensuse.org.

Almost three months have passed since our previous blog post, but that does not mean Agama development has stalled. The team is actually working on two parallel lines. On the one hand we are working to revamp several Agama internals and to greatly improve its HTTP API. On the other hand we keep implementing several small improvements and fixes on top of the codebase of Agama 17, to the point that it deserves a new version number. So please welcome Agama 18.

This new version delivers several features that you may experience if you install SUSE Linux Enterprise 16.0 or Leap 16.0 using Agama, since the official installation media for those two distributions include an intermediate version between Agama 17 and 18.

But let's take a look to the whole set of new features, starting with the changes introduced in the user interface.

Rearranged information in the storage section​

The most potentially complex part of the web interface is the storage configuration page. Due to its flexibility and the variety of options it offers, we are in constant search for the best way to present the information there. Agama 18 is our latest step in that journey.

The ultimate goal is to offer a more self-explanatory interface that allows newbies to understand what is going to happen to their disks, while making it possible for expert users to find the advanced options they need. See more information about the changes in the following pull request.

Enhanced interface to manage DASD devices​

Storage management can even be more challenging for users of System/390 mainframes. Even before tweaking the configuration in the already mentioned storage page, they usually need to manage the DASD devices in order to activate and maybe format the disks that will be configured.

Agama's web interface to handle those DASD devices was greatly improved in version 18, allowing to work with a big number of devices in a more convenient way.

Not many of our readers have access to a S/390 system, but you can still get a very good overview of the new page thanks to the many screenshots available at the description of the corresponding pull request.

Improvements when using the JSON configuration​

As most of our readers know, the web interface is just one of the possible ways to manage the installation. The full potential of Agama can be unleashed by describing the configuration using JSON (or Jsonnet), like it is done in the unattended installation process.

Agama 18 introduces several improvements in the way the configuration can be specified and managed, but we would like to highlight three headlines in that regard.

• Ability to validate a JSON profile locally, with no Agama instance running.
• Support to manage answers to Agama questions directly in the profile.
• Possibility to add and remove patterns to install, in addition to replacing the full list.

The starter guide and the documentation page offer more information about how to use the power of JSON to get the most out of Agama.

Installer self-update functionality​

As you may know, YaST has the ability to update itself at the beginning of the installation process getting an up-to-date version of the installer and the installation medium from a special dedicated repository. That feature debuted at SUSE Linux Enterprise 12 SP2 and, of course, we don't want to lose it in SLE 16.X.

The SLE 16 family will also offer self-update repositories and the Agama installation media are now able to use them to update the installation environment very early in the process.

Hello SLE 16.1​

SUSE Linux Enterprise 16 is almost ready to be served. But the activity never ceases at the Open Source kitchen and the first ingredients of SLE 16.1 are already being selected and mixed. Any serious cook knows that tasting the intermediate steps is key to reach the desired result at the end. For that purpose, Agama 18 already offers the possibility to install the early alpha versions of SLE 16.1 and surely openSUSE Leap 16.1 will follow shortly.

See you soon, Kalpa​

But not everything are good news about the list of distributions supported by Agama. Recently the development team behind openSUSE Kalpa contacted us to clarify they have no desire nor intention to support Kalpa installations with advanced custom partitioning schemas, like the ones that can be achieved using Agama.

When installing openSUSE Kalpa, they would like the Agama storage page to be reduced to a single disk selector in which the distribution would be installed as a single partition. Since there is currently no way for the distributions to configure the Agama web interface in that way, it was decided to remove openSUSE Kalpa from the list of distributions installable with Agama (so-called "products" in Agama jargon).

We hope this is not a definitive farewell since, as you can see in Agama's Roadmap, we plan to improve support for transactional distributions in the mid-term future.

Officially dropped support for i586​

And talking about future, in order to submit Agama 18 to openSUSE Tumbleweed we had to exclude the i586 architecture. Unfortunately, there are several other parts of Tumbleweed that are not built for such a 32bit architecture, starting with Mozilla Firefox or Chromium. Now we have followed the same path, so it can be said that with Agama 18 we officially dropped support for i586.

We are not against re-enabling the builds for that architecture, but someone would need to create an alternate version of the installation media that can be built with software included in the i586 version of Tumbleweed (which excludes SUSE Connect and Mozilla Firefox). In the short team, the Agama development team has no human resources to invest on that front.

Working in the future​

As mentioned at the beginning of this post, the Agama team is actively working on a big revamp of several internals and a new version of the HTTP API that should be the cornerstone for any future development. As you can see in the roadmap, that new version will keep us busy for several months. As a side effect, we expect very little activity in this blog in the short term.

Of course you can always reach us at the Agama project at GitHub and our #yast channel at Libera.chat.

Don't forget to have a lot of fun!

Declarative packaging is all the rage lately. I stopped counting how often I was asked “Do you have something like nix packages?”

Back in 2019 Florian Festi gave a nice talk called Re-Thinking Spec Files. It showed many nice ideas on how packaging could be easier.

Since RPM 4.20 we actually have declarative builds. Let us explore this a bit.

Exploring the possibilities

One of the first packages in openSUSE, which switched to declarative builds was gnome-text-editor. But to focus on the basics we will use my converted minisign package.

Dear Tumbleweed users and hackers,

The release cadence of snapshots was substantially higher than last week. A whole set of six snapshots (1106, 1108, 1109, 1110, 1111, and 1112) have passed through the ether, out into the wild, and onto your systems. Quality Assurance (QA) quality took a bit of a dive—as we ‘accidentally’ cleaned up the default GNOME installation—and we found many jobs relying on those legacy tools.

Specifically, we have dropped the X11 pattern from a standard GNOME installation. This matches what GNOME has done since version 49: making it Wayland-only.

The—from our perspective—very positive side effect is that legacy tools like xterm are no longer installed. The negative aspect, however, is that openQA relied on xterm to do all kinds of tests (all console interaction inside the graphical user interface was handled by xterm).

That’s, of course, just one of the changes done. There were also a large number of other changes, like:

• GRUB2-BLS as the default bootloader selected by the installer on UEFI-based systems;
• KDE Plasma 6.5.2
• KDE Gear 25.08.3
• Linux kernel 6.17.7
• Qt 5.15.18
• openSSH 10.2p1
• Qemu 10.1.2
• Coreutils 9.9
• LLVM 21.1.5
• LXQt 2.3.0
• kernel hardening: prevent normal users from seeing dmesg

Staging looks quite poor and empty at the moment. Keep the submissions comming! Currently, we are testing:

• GStreamer 1.26.8
• Mesa 25.2.7
• Mozilla Firefox 145.0
• Linux kernel 6.17.8
• Systemd 258.2
• openSSL 3.6.0

This is a roundup of articles from the openSUSE community listed on planet.opensuse.org.

The below featured highlights listed on the community’s blog feed aggregator are from November 7 to 14.

Blog posts this week highlight KDE Plasma improvements, a translators’ meetup at LinuxDays, a new community-recognition app from Hack Week, a security advisory from the SUSE Security Team and more.

Here is a summary and links for each post:

GRUB2-BLS in openSUSE Tumbleweed is now the default

The GRUB2‑BLS boot loader variant, incorporating Fedora-derived patches and BLS entry support, is now the default for openSUSE Tumbleweed when installed via YaST. The change streamlines the boot configuration process and removes the need for manual tools like grub2-mkconfig. The change also enables improved full-disk encryption workflows using systemd tools together with TPM 2 or FIDO2 tokens.

Privilege Escalation from lightdm Service User to root in KAuth Helper Service (CVE-2025-62876)

The lightdm‑kde‑greeter’s D-Bus/KAuth helper allowed the lightdm service user to escalate privileges to root due to unchecked file copy operations. The upstream fix adds a safer file-descriptor passing and drops root privileges before writing into lightdm’s directory.

The new features of Plasma 6.5

The KDE Blog post describes several visual improvements for Plasma 6.5, including rounded corners on all four corners of windows and automatic switching between light and dark themes depending on the time of day. It also introduces the ability to pin items to the clipboard for frequently used text, and has improvements for drawing tablets in the system settings.

Hack Week Project Seeks to Launch Kudos

A new Hack Week 25 project within the openSUSE Project aims to create an application called “Kudos” to publicly recognise all kinds of contributor efforts. The project emphasises recognising behind-the-scenes contributions such as translations, documentation, infrastructure maintenance, moderation and more.

Meeting of Software Translators from English to Czech at LinuxDays

The blog post reports on a meetup of Czech translators at LinuxDays 2025 where participants discussed the shortage of active translators and outdated documentation in free software projects. L10N.cz was highlighted as a hub for Czech localization efforts and as a place where collaboration could be improved. The article calls for making translation tasks easier for newcomers.

Sixth Update of Plasma 6.4

The KDE Blog announced the sixth maintenance release of KDE Plasma 6.4, which focuses on stability, translation improvements and bug fixes. It improves the desktop experience without altering functionality. Key fixes include better Bluetooth device identification, improved keyboard navigation across widgets, enhanced Wayland stability and updates to the Discover software center.

Episode 57 of KDE Express: How to Report a Bug So Albert Can Fix It

The KDE Blog covers a podcast and takes the audio of a talk given by Albert Astals Cid at AkademyES 2025 in Málaga, which walks through best and worst practices for filing bugs in the KDE Plasma ecosystem. It stresses that you should use the correct bug tracker at Bugzilla (https://bugs.kde.org), ensure crash reports include symbols, be precise if it’s a functional error, and think twice before filing a “wish” or feature request.

The Printer of Stallman on Compilando Podcast

This KDE Blog highlights episode 63 of Compilando Podcast, titled “La impresora de Stallman”, which recounts how a simple printer jam at the Richard Stallman’s workplace sparked the free-software movement. It reflects the more than forty-year history of the GNU Project and Stallman’s ethical-technical vision that changed computing.

Virtual Desktops Only on the Primary Screen: This Week in Plasma

The KDE Blog discusses the upcoming version of KDE Plasma 6.6 and how changes will help users with multi-monitor setups by keeping desktop switching confined to one screen while other monitors stay fixed. The blog also highlights other forthcoming features such as QR-code network connection via the network widget and expanded crash reporting in DrKonqi.

openSUSE Tumbleweed review of week 45 of 2025

Victorhck’s blog recaps updates to openSUSE Tumbleweed for week 45 and notes the slow pace of new snapshots starting off in November. A major upcoming change highlights the switch to grub2‑bls as the default boot loader for UEFI installations.

Afternoon Session: Part 1 of the XI Jornadas Anuales de Wikimedia España

The KDE Blog post covers sessions from the first afternoon of the Wikimedia España annual conference, which gathered participants to discuss open knowledge, cultural heritage and digital collaboration. The write-up underlines the importance of building inclusive communities and improving coordination among translation and outreach efforts.

Tumbleweed – Review of the week 2025/45

Last week, DimStar blog summarised the previous week’s software package updates in openSUSE Tumbleweed. It highlighted the major change of switching to GRUB2‑BLS as covered above.

View more blogs or learn to publish your own on planet.opensuse.org.

openSUSE is migrating the package source management from osc to git. I will try to explain here what it is the "git workflow" in openSUSE and give some practical information for contributors and maintainers.

You can find some documentation in the openSUSE wiki

Why?

openSUSE uses Open Build Service to store package sources (.spec files and patches). The source control is similar to subversion, so you can osc checkout, osc commit, osc log, etc. to work with any package source.

I don't know all the reasons to do the change, and different people will find different reasons, to support the change or to be against it. I will just write here what I consider a good reason to migrate:

• Almost everyone has moved to git now, so today, git is the default source code management (scm) tool, almost all the people knows about github, so it's good to be "standard".
• With the concept of "cheap" branches in git, it could be easier to maintain different versions of the same package, same repository, different branches, instead of actual forks.
• Decouple the package source management from build. OBS does a lot of things, moving source code and review process to gitea could reduce the complexity (but requires some integration).

From OBS to gitea

All the development happens in OBS, so the classic workflow happens entirely there:

• developer: branch -> checkout -> modify -> commit -> submit request
• maintainer: review -> accept/decline

And everything is integrated in OBS that does the corresponding build of the sources, checks with services, forward, etc.

The new workflow changes almost all the interaction from OBS to gitea. OBS is still a really important piece of software in the process, but in the new workflow it's a build backend, so the user interaction will be with the git repo in gitea.

The new git workflow happens in gitea:

• developer: fork -> clone -> modify -> commit -> push -> pull request
• maintainer: review -> approve/decline

As you may notice, the "default" workflow is very similar, the difference is in the tools, the classic workflow occurs in build.opensuse.org and the new workflow in src.opensuse.org. And the tools to work with the sources are also different, osc in the first one and git in the new workflow.

And with this new workflow, there are some bots in gitea that sends the changes to OBS, so for any pull request created you will have the build results and approval from the bot if everything is building.

How to modify a package (leap 16.0)

Notice that you should have a openSUSE account to work with the gitea instance, and don't forget to configure your ssh key to be able to push using the gitea@src.opensuse.org remote.

So as a contributor, this is the basic workflow to follow to update a package in openSUSE:

1. Look for the source package in the pool (https://src.opensuse.org/pool)
2. Fork it in your user space, click the top right button. Skip this step if you have forked before
3. Clone your fork and work on that repo, create a new branch, modify the spec file, add new soures, etc. And make sure to update the .changes file accordingly, you can still use osc vc to do that.
4. You can build locally your package with osc build, as usual, but you will need to specify the build project:

$ git obs meta pull
$ git obs meta set --project openSUSE:Backports:SLE-16.0
$ osc build

1. Once you are happy with your changes, you can commit, push to your fork and then you can create a Pull Request. The pull request should target the pool repo and desired product branch. Right now you can just target leap-16.0, as factory is not migrated yet.

Devel projects

Some devel projects have been migrated now to git, so a similar workflow is available to modify these packages in Tumbleweed. The development of these packages is not happening in the pool, so you need to find first the devel project.

There's no simple way to discover the actual package devel source, as far as I know the easier way is:

1. Look for the devel project of the package in the Factory list, (ex python-pytest)
2. Go to the devel project in OBS (ex devel:languages:python:pytest)
3. Click on the link This project is managed in SCM

Once you have located the desired package to modify, the workflow is similar to what I explained before, but instead of forking from pool, you should fork from the devel project. For example if you want to modify python-pytest you should fork from https://src.opensuse.org/python-pytest/python-pytest, and create the pull request for that repo, to the main branch.

Adding a new package follows a different process that's documented in the wiki

What's migrated?

As I said, the migration is happening right now, so not everything is migrated. The first project migrated was the Leap 16.0. And we are slowly migrating some devel projects.

Right now from the python-maintainers team, we've started the migration of two subprojects:

• python-interpreters
• python-pytest

You can find more information about the migration current state in the wiki: https://en.opensuse.org/opensuse:obs_to_git#codestream_project_status_table

A while ago we looked at conditional building in rpm. One point we did not cover yet was how we can control build conditionals within the open buildservice.

Back in the good old days

When using osc build --with=build_docs --without=run_tests rpm internally defines 2 variables:

_with_build_docs
_without_run_tests

Which is also something we used when integrate it with the buildservice:

%define _with_ruby34 1
%define _without_apparmor 1
Macros:
%_with_ruby34 1
%_without_apparmor 1
:Macros

This was working mostly well. We could have one spec file which then had features turned on and off depending on the _with(out)_something defines. But it completely failed if an user later wanted to toggle the decision made on the base distro.