Hey Kids! Other than raving about GNOME.org being a static HTML, there's one more aspect I'd like to get back to in this writing exercise called a blog post.

I've recently come across an apalling genAI website for a project I hold deerly so I thought I'd give a glimpse on how we used to do things in the olden days. It is probably not going to be done this way anymore in the enshittified timeline we ended up in. The two options available these days are — a quickly generated slop website or no website at all, because privately owned social media is where it's at.

The wanna-be-catchy title of this post comes from the fact the website underwent numerous iterations (iterations is the core principle of good design) spanning over a year before we introduced the redesign.

So how did we end up with a 3D model of a laptop for the hero image on the GNOME website, rather than something generated in a couple of seconds and a small town worth of drinking water or a simple SVG illustration?

The hero image is static now, but used to be a scroll based animation at the early days. It could have become a simple vector style illustration, but I really enjoy the light interaction of the screen and the laptop, especially between the light and dark variants. Toggling dark mode has been my favorite fidget spinner.

Creating light/dark variants is a bit tedious to do manually every release, but automating still a bit too hard to pull off (the taking screenshots of a nightly OS bit). There's also the fun of picking a theme for the screenshot rather than doing the same thing over and over. Doing the screenshooting manually meant automating the rest, as a 6 month cycle is enough time to forget how things are done. The process is held together with duct tape, I mean a python script, that renders the website image assets from the few screenshots captured using GNOME OS running inside Boxes. Two great invisible things made by amazing individuals that could go away in an instant and that thought gives me a dose of anxiety.

This does take a minute to render on a laptop (CPU only Cycles), but is a matter of a single invocation and a git commit. So far it has survived a couple of Blender releases, so fingers crossed for the future.

Sophie has recently been looking into translations, so we might reconsider that 3D approach if translated screenshots become viable (and have them contained in an SVG similar to how os.gnome.org is done). So far the 3D hero has always been in sync with the release, unlike in our Wordpress days. Fingers crossed.

A Hack Week 25 project aims to reduce the time developers spend navigating Bugzilla by introducing an AI-driven triage and reporting assistant.

The Bugzilla Goes AI - Phase 1 project proposes using a locally hosted AI model to summarize bugs, recommend next steps and deliver a daily digest through a simple Web Interface.

The project aims at integrating the Ollama LLM with a Bugzilla instance through a dedicated API connector. Once connected, the AI agent could analyze bugs, assign them to a team, produce short summary and create actionable items. Developers could scan workloads without opening Bugzilla.

The project may design the AI tool to highlight what matters rather than change Bugzilla workflows. The system may report only on bugs that have changed since a previous triage, which could reduce the time developers spend re-checking old and/or inactive tickets.

Core benefits that could emerge from the prototype is a daily bug debriefing that offers an automated overview of issues, relevant change alerts, which should reduce noise of resurfacing activity, and provide a follow-up feature that helps developers realize the next steps.

Time constraints to develop the project during Hack Week and AI accuracy remain notable risks, but a prototype could provide a meaningful step toward modernizing bug triage for openSUSE and the open-source ecosystem.

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.

Over the weekend, in Prague, Czechia, Zuzana Pechová organized a full-day workshop together with Terka Lukešová and Markéta Gregorová as part of the CyberLadies z.s. community initiative. The goal was to introduce ten women to Linux installation, basic desktop use, and common open-source alternatives to commercial software. The workshop also covered how to work with […]

The post CyberLadies Empower Women With openSUSE Leap 16 appeared first on SUSE Communities.

On our latest development iteration we have introduced new filtering capabilities using labels and we have polished the Submit Request workflow when there are assigners involved. These improvements make managing and tracking your work more efficient and organized. These updates are part of the Labels and Foster Collaboration beta program. You can find more information about the beta program here. Our efforts to foster collaboration started in August 2024, when we introduced labels and bug...

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.

On our latest development iteration we have introduced new filtering capabilities using labels and we have polished the Submit Request workflow when there are assigners involved. These improvements make managing and tracking your work more efficient and organized. These updates are part of the Labels and Foster Collaboration beta program. You can find more information about the beta program here. Our efforts to foster collaboration started in August 2024, when we introduced labels and bug...

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