Results

Learn how to use the Relm4 Rust GUI crate by xiaoguang_wang

Relm4 is based on gtk4-rs and compatible with libadwaita. The gtk4-rs crate provides all the tools necessary to develop applications. Building on this foundation, Relm4 makes developing more idiomatic, simpler, and faster.

https://github.com/Relm4/Relm4

---

Build a terminal user-interface (TUI) for Agama by IGonzalezSosa

Description

Officially, Agama offers two different user interfaces. On the one hand, we have the web-based interface, which is the one you see when you run the installation media. On the other hand, we have a command-line interface. In both cases, you can use them using a remote system, either using a browser or the agama CLI.

We would expect most of the cases to be covered by this approach. However, if you cannot use the web-based interface and, for some reason, you cannot access the system through the network, your only option is to use the CLI. This interface offers a mechanism to modify Agama's configuration using an editor (vim, by default), but perhaps you might want to have a more user-friendly way.

Goals

The main goal of this project is to built a minimal terminal user-interface for Agama. This interface will allow the user to install the system providing just a few settings (selecting a product, a storage device and a user password). Then it should report the installation progress.

Resources

• https://agama-project.github.io/
• https://ratatui.rs/

Conclusions

We have summarized our conclusions in a pull request. It includes screenshots ;-) We did not implement all the features we wanted, but we learn a lot during the process. We know that, if needed, we could write a TUI for Agama and we have an idea about how to build it. Good enough.

---

Exploring Rust's potential: from basics to security by sferracci

Description

This project aims to conduct a focused investigation and practical application of the Rust programming language, with a specific emphasis on its security model. A key component will be identifying and understanding the most common vulnerabilities that can be found in Rust code.

Goals

Achieve a beginner/intermediate level of proficiency in writing Rust code. This will be measured by trying to solve LeetCode problems focusing on common data structures and algorithms. Study Rust vulnerabilities and learning best practices to avoid them.

Resources

Rust book: https://doc.rust-lang.org/book/

---

Learn a bit of embedded programming with Rust in a micro:bit v2 by aplanas

Description

micro:bit is a small single board computer with a ARM Cortex-M4 with the FPU extension, with a very constrain amount of memory and a bunch of sensors and leds.

The board is very well documented, with schematics and code for all the features available, so is an excellent platform for learning embedded programming.

Rust is a system programming language that can generate ARM code, and has crates (libraries) to access the micro:bit hardware. There is plenty documentation about how to make small programs that will run in the micro:bit.

Goals

Start learning about embedded programming in Rust, and maybe make some code to the small KS4036F Robot car from keyestudio.

Resources

• micro:bit
• KS4036F
• microbit technical documentation
• schematic
• impl Rust for micro:bit
• Rust Embedded MB2 Discovery Book
• nRF-HAL
• nRF Microbit-v2 BSP (blocking)
• knurling-rs
• C++ microbit codal
• microbit-bsp for Embassy
• Embassy

Diary

Day 1

• Start reading https://mb2.implrust.com/abstraction-layers.html
• Prepare the dev environment (cross compiler, probe-rs)
• Flash first code in the board (blinky led)
• Checking differences between BSP and HAL
• Compile and install a more complex example, with stack protection
• Reading about the simplicity of xtask, as alias for workspace execution
• Reading the CPP code of the official micro:bit libraries. They have a font!

Day 2

• There are multiple BSP for the microbit. One is using async code for non-blocking operations
• Download and study a bit the API for microbit-v2, the nRF official crate
• Take a look of the KS4036F programming, seems that the communication is multiplexed via I2C
• The motor speed can be selected via PWM (pulse with modulation): power it longer (high frequency), and it will increase the speed
• Scrolling some text
• Debug by printing! defmt is a crate that can be used with probe-rs to emit logs
• Start reading input from the board: buttons
• The logo can be touched and detected as a floating point value

Day 3

• A bit confused how to read the float value from a pin

---

AI-Powered Unit Test Automation for Agama by joseivanlopez

The Agama project is a multi-language Linux installer that leverages the distinct strengths of several key technologies:

• Rust: Used for the back-end services and the core HTTP API, providing performance and safety.
• TypeScript (React/PatternFly): Powers the modern web user interface (UI), ensuring a consistent and responsive user experience.
• Ruby: Integrates existing, robust YaST libraries (e.g., yast-storage-ng) to reuse established functionality.

The Problem: Testing Overhead

Developing and maintaining code across these three languages requires a significant, tedious effort in writing, reviewing, and updating unit tests for each component. This high cost of testing is a drain on developer resources and can slow down the project's evolution.

The Solution: AI-Driven Automation

This project aims to eliminate the manual overhead of unit testing by exploring and integrating AI-driven code generation tools. We will investigate how AI can:

1. Automatically generate new unit tests as code is developed.
2. Intelligently correct and update existing unit tests when the application code changes.

By automating this crucial but monotonous task, we can free developers to focus on feature implementation and significantly improve the speed and maintainability of the Agama codebase.

Goals

• Proof of Concept: Successfully integrate and demonstrate an authorized AI tool (e.g., gemini-cli) to automatically generate unit tests.
• Workflow Integration: Define and document a new unit test automation workflow that seamlessly integrates the selected AI tool into the existing Agama development pipeline.
• Knowledge Sharing: Establish a set of best practices for using AI in code generation, sharing the learned expertise with the broader team.

Contribution & Resources

We are seeking contributors interested in AI-powered development and improving developer efficiency. Whether you have previous experience with code generation tools or are eager to learn, your participation is highly valuable.

If you want to dive deep into AI for software quality, please reach out and join the effort!

• Authorized AI Tools: Tools supported by SUSE (e.g., gemini-cli)
• Focus Areas: Rust, TypeScript, and Ruby components within the Agama project.

Interesting Links

• goose

---

MCP Perl SDK by kraih

Description

We've been using the MCP Perl SDK to connect openQA with AI. And while the basics are working pretty well, the SDK is not fully spec compliant yet. So let's change that!

Goals

• Support for Resources
• All response types (Audio, Resource Links, Embedded Resources...)
• Tool/Prompt/Resource update notifications
• Dynamic Tool/Prompt/Resource lists
• New authentication mechanisms

Resources

• https://github.com/mojolicious/mojo-mcp
• https://modelcontextprotocol.io/specification/2025-06-18

---

Create a page with all devel:languages:perl packages and their versions by tinita

Description

Perl projects now live in git: https://src.opensuse.org/perl

It would be useful to have an easy way to check which version of which perl module is in devel:languages:perl. Also we have meta overrides and patches for various modules, and it would be good to have them at a central place, so it is easier to lookup, and we can share with other vendors.

I did some initial data dump here a while ago: https://github.com/perlpunk/cpan-meta

But I never had the time to automate this.

I can also use the data to check if there are necessary updates (currently it uses data from download.opensuse.org, so there is some delay and it depends on building).

Goals

• Have a script that updates a central repository (e.g. https://src.opensuse.org/perl/_metadata) with metadata by looking at https://src.opensuse.org/perl/_ObsPrj (check if there are any changes from the last run)
• Create a HTML page with the list of packages (use Javascript and some table library to make it easily searchable)

Resources

Results

• https://perlpunk.github.io/opensuse-perl-meta/
• https://github.com/perlpunk/opensuse-perl-meta

Day 1

• First part of the code which retrieves data from https://src.opensuse.org/perl/_ObsPrj with submodules and creates a YAML and a JSON file.
• Repo: https://github.com/perlpunk/opensuse-perl-meta
• Also a first version of the HTML is live: https://perlpunk.github.io/opensuse-perl-meta/

Day 2

• HTML Page has now links to src.opensuse.org and the date of the last update, plus a short info at the top
• Code is now 100% covered by tests: https://app.codecov.io/gh/perlpunk/opensuse-perl-meta
• I used the modern perl class feature, which makes perl classes even nicer and shorter. See example
• Tests
  • I tried out the mocking feature of the modern Test2::V0 library which provides call tracking. See example
  • I tried out comparing data structures with the new Test2::V0 library. It let's you compare parts of the structure with the like function, which only compares the date that is mentioned in the expected data. example

Day 3

• Added various things to the table
  • Dependencies column
  • Show popup with info for cpanspec, patches and dependencies
  • Added last date / commit to the data export.

Plan: With the added date / commit we can now daily check _ObsPrj for changes and only fetch the data for changed packages.

Day 4

---

Bring up Agama based tests for openSUSE Tumbleweed by szarate

Description

Agama has been around for some time already, and we have some tests for it on Tumbleweed however they are only on the development job group and are too few to be helpful in assessing the quality of a build

This project aims at enabling and creating new testsuites for the agama flavor, using the already existsing DVD and NET flavors as starting points

Goals

• Introduce tests based on the Agama flavor in the main Tumbleweed job group
• Create Tumbleweed yaml schedules for agama installer and its own jsonette profile (The one being used now are reused from leap)
• Fan out tests that have long runtimes (i.e tackle this ticket)
• Reduce redundancy in tests

Resources

• Tumbleweed development job group:
• Tumbleweed main job group in git
• osado test repository:

---

MCP Perl SDK by kraih

Description

We've been using the MCP Perl SDK to connect openQA with AI. And while the basics are working pretty well, the SDK is not fully spec compliant yet. So let's change that!

Goals

• Support for Resources
• All response types (Audio, Resource Links, Embedded Resources...)
• Tool/Prompt/Resource update notifications
• Dynamic Tool/Prompt/Resource lists
• New authentication mechanisms

Resources

• https://github.com/mojolicious/mojo-mcp
• https://modelcontextprotocol.io/specification/2025-06-18

---

openQA tests needles elaboration using AI image recognition by mdati

Description

In the openQA test framework, to identify the status of a target SUT image, a screenshots of GUI or CLI-terminal images, the needles framework scans the many pictures in its repository, having associated a given set of tags (strings), selecting specific smaller parts of each available image. For the needles management actually we need to keep stored many screenshots, variants of GUI and CLI-terminal images, eachone accompanied by a dedicated set of data references (json).

A smarter framework, using image recognition based on AI or other image elaborations tools, nowadays widely available, could improve the matching process and hopefully reduce time and errors, during the images verification and detection process.

Goals

Main scope of this idea is to match a "graphical" image of the console or GUI status of a running openQA test, an image of a shell console or application-GUI screenshot, using less time and resources and with less errors in data preparation and use, than the actual openQA needles framework; that is:

• having a given SUT (system under test) GUI or CLI-terminal screenshot, with a local distribution of pixels or text commands related to a running test status,
• we want to identify a desired target, e.g. a screen image status or data/commands context,
  • based on AI/ML-pretrained archives containing object or other proper elaboration tools,
  • possibly able to identify also object not present in the archive, i.e. by means of AI/ML mechanisms.
• the matching result should be then adapted to continue working in the openQA test, likewise and in place of the same result that would have been produced by the original openQA needles framework.
• We expect an improvement of the matching-time(less time), reliability of the expected result(less error) and simplification of archive maintenance in adding/removing objects(smaller DB and less actions).

Hackweek POC:

Main steps

• Phase 1 - Plan
  • study the available tools
  • prepare a plan for the process to build
• Phase 2 - Implement
  • write and build a draft application
• Phase 3 - Data
  • prepare the data archive from a subset of needles
  • initialize/pre-train the base archive
  • select a screenshot from the subset, removing/changing some part
• Phase 4 - Test
  • run the POC application
  • expect the image type is identified in a good %.

Resources

First step of this project is quite identification of useful resources for the scope; some possibilities are:

• SUSE AI and other ML tools (i.e. Tensorflow)
• Tools able to manage images
• RPA test tools (like i.e. Robot framework)
  
• other.

Project references

• Repository: openqa-needles-AI-driven

---

openQA log viewer by mpagot

Description

*** Warning: Are You at Risk for VOMIT? ***

Do you find yourself staring at a screen, your eyes glossing over as thousands of lines of text scroll by? Do you feel a wave of text-based nausea when someone asks you to "just check the logs"?

You may be suffering from VOMIT (Verbose Output Mental Irritation Toxicity).

This dangerous, work-induced ailment is triggered by exposure to an overwhelming quantity of log data, especially from parallel systems. The human brain, not designed to mentally process 12 simultaneous autoinst-log.txt files, enters a state of toxic shock. It rejects the "Verbose Output," making it impossible to find the one critical error line buried in a 50,000-line sea of "INFO: doing a thing."

Before you're forced to rm -rf /var/log in a fit of desperation, we present the digital antacid.

No panic: we have The openQA Log Visualizer

This is the UI antidote for handling toxic log environments. It bravely dives into the chaotic, multi-machine mess of your openQA test runs, finds all the related, verbose logs, and force-feeds them into a parser.

image

Goals

Work on the existing POC openqa-log-visualizer about few specific tasks:

• add support for more type of logs
• extend the configuration file syntax beyond the actual one
• work on log parsing performance

Find some beta-tester and collect feedback and ideas about features

If time allow for it evaluate other UI frameworks and solutions (something more simple to distribute and run, maybe more low level to gain in performance).

Resources

openqa-log-visualizer

---