Fix RSpec tests in order to replace the ruby-ldap rubygem in OBS by enavarro_suse

Description

"LDAP mode is not official supported by OBS!". See: config/options.yml.example#L100-L102

However, there is an RSpec file which tests LDAP mode in OBS. These tests use the ruby-ldap rubygem, mocking the results returned by a LDAP server.

The ruby-ldap rubygem seems no longer maintaned, and also prevents from updating to a more recent Ruby version. A good alternative is to replace it with the net-ldap rubygem.

Before replacing the ruby-ldap rubygem, we should modify the tests so the don't mock the responses of a LDAP server. Instead, we should modify the tests and run them against a real LDAP server.

Goals

Goals of this project:

• Modify the RSpec tests and run them against a real LDAP server
• Replace the net-ldap rubygem with the ruby-ldap rubygem

Achieving the above mentioned goals will:

• Permit upgrading OBS from Ruby 3.1 to Ruby 3.2
• Make a step towards officially supporting LDAP in OBS.

Resources

• Replace ruby-ldap rubygem with net-ldap

---

Recipes catalog and calculator in Rails 8 by gfilippetti

My wife needs a website to catalog and sell the products of her upcoming bakery, and I need to learn and practice modern Rails. So I'm using this Hack Week to build a modern store using the latest Ruby on Rails best practices, ideally up to the deployment.

TO DO

• Index page
• Product page
• Admin area -- Supplies calculator based on orders -- Orders notification
• Authentication
• Payment
• Deployment

Day 1

As my Rails knowledge was pretty outdated and I had 0 experience with Turbo (wich I want to use in the app), I started following a turbo-rails course. I completed 5 of 11 chapters.

Day 2

Continued the course until chapter 8 and added live updates & an empty state to the app. I should finish the course on day 3 and start my own project with the knowledge from it.

Hackweek 24

For this Hackweek I'll continue this project, focusing on a Catalog/Calculator for my wife's recipes so she can use for her Café.

Day 1

---

Create an Android app for Syncthing as part of the Syncthing Tray project by mkittler

Description

There's already an app but code/features already in Syncthing Tray could be reused to create a nicer app with additional features like managing ignore patterns more easily. The additional UI code for the app could then in turn be re-used by other parts of Syncthing Tray, e.g. to implement further steps in the wizard as requested by some users. This way one "UI wrapper codebase" could serve GNU/Linux, Windows and Android (and in theory MacOS) at the same time which is kind of neat.

Goals

• DONE: Learn more about development for Android and development of UIs with Qt Quick
• DONE: Create an experimental app reusing as much existing Syncthing Tray code as possible
• DONE: Build Syncthing as a library also for Android and use it in the app (already done but needs further testing and integration with the rest of the app configuration)
• DONE: Update the Syncthing Tray website, documentation
• Extend the app so it has at least a start page and an import that can cope with an export of the other app
• Update forum thread
• Upload an experimental build on GitHub
• Extend the Syncthing API to download single files on demand (instead of having to sync the whole directory or use ignore patterns)

Resources

• Android SDK/NDK and emulator
• Qt Quick

---

YQPkg - Bringing the Single Package Selection Back to Life by shundhammer

tl;dr

Rip out the high-level YQPackageSelector widget from YaST and make it a standalone Qt program without any YaST dependencies.

See section "Result" at the bottom for the current status after the hack week.

Current Status

See the development status issue at the GitHub repo.

tl;dr: It's usable now with all the key features.

It does real package installation / removal / update with reasonable user feedback.

The Past and the Present

We used to have and still have a powerful software selection with the YaST sw_single module (and the YaST patterns counterpart): You can select software down to the package level, you can easily select one of many available package versions, you can select entire patterns - or just view them and pick individual packages from patterns.

You can search packages based on name, description, "requires" or "provides" level, and many more things.

The Future

YaST is on its way out, to be replaced by the new Agama installer and Cockpit for system administration. Those tools can do many things, but fine-grained package selection is not among them. And there are also no other Open Source tools available for that purpose that even come close to the YaST package selection.

Many aspects of YaST have become obsolete over the years; many subsystems now come with a good default configuration, or they can configure themselves automatically. Just think about sound or X11 configuration; when did you last need to touch them?

For others, the desktops bring their own tools (e.g. printers), or there are FOSS configuration tools (NetworkManager, BlueMan). Most YaST modules are no longer needed, and for many others there is a replacement in tools like Cockpit.

But no longer having a powerful fine-grained package selection like in YaST sw_single will hurt. Big time. At least until there is an adequate replacement, many users will want to keep it.

The Idea

YaST sw_single always revolved around a powerful high-level widget on the abstract UI level. Libyui has low-level widgets like YPushButton, YCheckBox, YInputField, more advanced ones like YTable, YTree; and some few very high-level ones like YPackageSelector and YPatternSelector that do the whole package selection thing alone, working just on the libzypp level and changing the status of packages or patterns there.

For the YaST Qt UI, the YQPackageSelector / YQPatternSelector widgets work purely on the Qt and libzypp level; no other YaST infrastructure involved, in particular no Ruby (or formerly YCP) interpreter, no libyui-level widgets, no bindings between Qt / C++ and Ruby / YaST-core, nothing. So it's not too hard to rip all that part out of YaST and create a standalone program from it.

For the NCurses UI, the NCPackageSelector / NCPatternSelector create a lot of libyui widgets (inheriting YWidget / NCWidget) and use a lot of libyui calls to glue them together; and all that of course still needs a lot of YaST / libyui / libyui-ncurses infrastructure. So NCurses is out of scope here.

Preparatory Work: Initializing the Package Subsystem

To see if this is feasible at all, the existing UI examples needed some fixing to check what is needed on that level. That was the make-or-break decision: Would it be realistically possible to set the needed environment in libzypp up (without being stranded in the middle of that task alone at the end of the hack week)?

Yes, it is: That part is already working:

https://github.com/yast/yast-ycp-ui-bindings/pull/71

---

Explore the integration between OBS and GitHub by pdostal

Project Description

The goals:

1) When GitHub pull request is created or modified the OBS project will be forked and the build results reported back to GitHub. 2) When new version of the GitHub project will be published the OBS will redownload the source and rebuild the project.

Goal for this Hackweek

Do as much as possible, blog about it and maybe use it another existing project.

Resources

• The Blog post
• Issue: poo#123858 - build.opensuse.org: /usr/lib/obs/service//go_modules.service No such file or directory

---

Port git-fixup to POSIX shell script and submit to git/git by mcepl

Description

https://github.com/keis/git-fixup is an exceedingly useful program, which I use daily, and I would love to every git user could bask in its awesomeness. Alas, it is a bash script, so it is not appropriate for the inclusion in git proper.

Goals

Port the script to plain POSIX shell and submit for consideration to git@vger.kernel.org

Resources

---

Packaging Mu on OBS by joeyli

Description

Packaging Microsoft Mu project

Goals

Packaging Mu RPM on OBS.

Resources

https://microsoft.github.io/mu/

https://github.com/microsoft/mu

https://github.com/microsoft/mu_basecore

https://github.com/microsoft/mutianoplatforms

https://github.com/microsoft/mutianoplus

https://github.com/microsoft/mu_plus

Hackweek 22: Look at Microsoft Mu project

https://hackweek.opensuse.org/22/projects/look-at-microsoft-mu-project

https://drive.google.com/file/d/1BT31i7z3qh13adj9pdRz3lTUkqIsXvjY/view?usp=drive_link

---

Update Haskell ecosystem in Tumbleweed to GHC-9.10.x by psimons

Description

We are currently at GHC-9.8.x, which a bit old. So I'd like to take a shot at the latest version of the compiler, GHC-9.10.x. This is gonna be interesting because the new version requires major updates to all kinds of libraries and base packages, which typically means patching lots of packages to make them build again.

Goals

Have working builds of GHC-9.10.x and the required Haskell packages in 'devel:languages:haskell` so that we can compile:

• git-annex
• pandoc
• xmonad
• cabal-install

Resources

• https://build.opensuse.org/project/show/devel:languages:haskell/
• https://github.com/opensuse-haskell/configuration/
• #discuss-haskell
• https://www.twitch.tv/peti343

---

Framework laptop integration by nkrapp

Project Description

Although openSUSE does run on the Framework laptops out-of-the-box, there is still room to improve the experience. The ultimate goal is to get openSUSE on the list of community supported distros

Goal for this Hackweek

The goal this year is to at least package all of the soft- and firmware for accessories like the embedded controller, Framework 16 inputmodule and other tools. I already made some progress by packaging the inputmodule control software, but the firmware is still missing

Resources

As I only have a Framework laptop 16 and not a 13 I'm looking for people with hardware that can help me test

Progress:

Update 1:

The project lives under my home for now until I can get an independent project on OBS: Framework Laptop project

Also, the first package is already done, it's the cli for the led-matrix spacer module on the Framework Laptop 16. I am also testing this myself, but any feedback or questions are welcome.

You can test the package on the Framework 16 by adding this repo and installing the package inputmodule-control

Update 2:

I finished packaging the python cli/gui for the inputmodule. It is using a bit of a hack because one of the dependencies (PySimpleGUI) recently switched to a noncommercial license so I cannot ship it. But now you can actually play the games on the led-matrix (the rust package doesn't include controls for the games). I'm also working on the Framework system tools now, which should be more interesting for Framework 13 users.

You can test the package on the Framework 16 by installing python311-framework16_inputmodule and then running "ledmatrixctl" from the command line.

Update 3:

I packaged the framework_tool, a general application for interacting with the system. You can find it some detailed information what it can do here. On my system everything related to the embedded controller functionality doesn't work though, so some help testing and debugging would be appreciated.

Update 4:

Today I finished the qmk interface, which gives you a cli (and gui) to configure your Framework 16 keyboard. Sadly the Python gui is broken upstream, but I added the qmk_hid package with the cli and from my testing it works well.

Final Update:

All the interesting programs are now done, I decided to exclude the firmware for now since upstream also recommends using fwupd to update it. I will hack on more things related to the Framework Laptops in the future so if there are any ideas to improve the experience (or any bugs to report) feel free to message me about it.

As a final summary/help for everyone using a Framework Laptop who wants to use this software:

The source code for all packages can be found in repositories in the Framework organization on Github

All software can be installed from this repo (Tumbleweed)

The available packages are:

• framework-inputmodule-control (FW16) - play with the inputmodules on your Framework 16 (b1-display, led-matrix, c1-minimal)

• python-framework16_inputmodule (FW16) - same as inputmodule-control but is needed if you want to play and crontrol the built-in games in the led-matrix (call with ledmatrixctl or ledmatrixgui)

• framework_tool (FW13 and FW 16) - use to see and configure general things on your framework system. Commands using the embedded controller might not work, it looks like there are some problems with the kernel module used by the EC. Fixing this is out of scope for this hackweek but I am working on it

• qmk_hid (FW16) - a cli to configure the FW16 qmk keyboard. Sadly the gui for this is broken upstream so only the cli is usable for now

---

Port some classic game to Linux by MDoucha

Let's pick some old classic game, reverse engineer the data formats and game rules and write an open source engine for it from scratch. Some games from 1990s are simple enough that we could have a playable prototype by the end of the week.

Write which games you'd like to hack on in the comments. Don't forget to check e.g. on Open Source Game Clones, Github and SourceForge whether the game is ported already.

Hack Week 24 - Master of Orion II: Battle at Antares & Chaos Overlords

Work on Master of Orion II continues but we can hack more than one game. Chaos Overlords is a dystopian, lighthearted, cyberpunk turn-based strategy game originally released in 1996 for Windows 95 and Mac OS. The player takes on the role of a Chaos Overlord, attempting to control a city. Gameplay involves hiring mercenary gangs and deploying them on an 8-by-8 grid of city sectors to generate income, occupy sectors and take over the city.

How to ~~install & play~~ observe the decompilation progress:

• Clone the Git repository
• A playable reimplementation does not exist yet, but when it does, it will be linked in the repository mentioned above.

Further work needed:

• Analyze the remaining unknown data structures, most of which are related to the AI.
• Decompile the AI completely. The strong AI is part of the appeal of the game. It cannot be left out.
• Reimplement the game.

Hack Week 20, 21, 22 & 23 - Master of Orion II: Battle at Antares

Master of Orion II is one of the greatest turn-based 4X games of the 1990s. Explore the galaxy, colonize planets, research new technologies, fight space monsters and alien empires and in the end, become the ruler of the galaxy one way or another.

How to install & play:

• Clone the Git repository
• Run ./bootstrap; ./configure; make && make install
• Copy all *.LBX files from the original Master of Orion II to the installation data directory (/usr/local/share/openorion2 by default)
• Run openorion2

Further work needed:

• Analyze the rest of the original savegame format and a few remaining data files.
• Implement most of the game. The open source engine currently supports only loading saved games from the original version and viewing the galaxy map, fleet management and list of known planets.

Hack Week 19 - Signus: The Artifact Wars

Signus is a Czech turn-based strategy game similar to Panzer General or Battle Isle series. Originally published in 1998 and open-sourced by the original developers in 2003.

How to install & play:

• Clone the Git repository
• Run ./bootstrap; ./configure; make && make install in both signus and signus-data directories.
• Run signus

Further work needed:

• Create openSUSE package
• Implement full support for original game data (the open source version uses slightly different data file contents but original game data can be converted using a script).

---

RISC-V emulator in GLSL capable of running Linux by favogt

Description

There are already numerous ways to run Linux and some programs through emulation in a web browser (e.g. x86 and riscv64 on https://bellard.org/jslinux/), but none use WebGL/WebGPU to run the emulation on the GPU.

I already made a PoC of an AArch64 (64-bit Arm) emulator in OpenCL which is unfortunately hindered by a multitude of OpenCL compiler bugs on all platforms (Intel with beignet or the new compute runtime and AMD with Mesa Clover and rusticl). With more widespread and thus less broken GLSL vs. OpenCL and the less complex implementation requirements for RV32 (especially 32bit integers instead of 64bit), that should not be a major problem anymore.

Goals

Write an RISC-V system emulator in GLSL that is capable of booting Linux and run some userspace programs interactively. Ideally it is small enough to work on online test platforms like Shaderoo with a custom texture that contains bootstrap code, kernel and initrd.

Minimum:

riscv32 without FPU (RV32 IMA) and MMU (µClinux), running Linux in M-mode and userspace in U-mode.

Stretch goals:

FPU support, S-Mode support with MMU, SMP. Custom web frontend with more possibilities for I/O (disk image, network?).

Resources

RISC-V ISA Specifications
Shaderoo
OpenGL 4.5 Quick Reference Card

Result as of Hackweek 2024

WebGL turned out to be insufficient, it only supports OpenGL ES 3.0 but imageLoad/imageStore needs ES 3.1. So we switched directions and had to write a native C++ host for the shaders.

As of Hackweek Friday, the kernel attempts to boot and outputs messages, but panics due to missing memory regions.

Since then, some bugs were fixed and enough hardware emulation implemented, so that now Linux boots with framebuffer support and it's possible to log in and run programs!

The repo with a demo video is available at https://github.com/Vogtinator/risky-v

---

YQPkg - Bringing the Single Package Selection Back to Life by shundhammer

tl;dr

Rip out the high-level YQPackageSelector widget from YaST and make it a standalone Qt program without any YaST dependencies.

See section "Result" at the bottom for the current status after the hack week.

Current Status

See the development status issue at the GitHub repo.

tl;dr: It's usable now with all the key features.

It does real package installation / removal / update with reasonable user feedback.

The Past and the Present

We used to have and still have a powerful software selection with the YaST sw_single module (and the YaST patterns counterpart): You can select software down to the package level, you can easily select one of many available package versions, you can select entire patterns - or just view them and pick individual packages from patterns.

You can search packages based on name, description, "requires" or "provides" level, and many more things.

The Future

YaST is on its way out, to be replaced by the new Agama installer and Cockpit for system administration. Those tools can do many things, but fine-grained package selection is not among them. And there are also no other Open Source tools available for that purpose that even come close to the YaST package selection.

Many aspects of YaST have become obsolete over the years; many subsystems now come with a good default configuration, or they can configure themselves automatically. Just think about sound or X11 configuration; when did you last need to touch them?

For others, the desktops bring their own tools (e.g. printers), or there are FOSS configuration tools (NetworkManager, BlueMan). Most YaST modules are no longer needed, and for many others there is a replacement in tools like Cockpit.

But no longer having a powerful fine-grained package selection like in YaST sw_single will hurt. Big time. At least until there is an adequate replacement, many users will want to keep it.

The Idea

YaST sw_single always revolved around a powerful high-level widget on the abstract UI level. Libyui has low-level widgets like YPushButton, YCheckBox, YInputField, more advanced ones like YTable, YTree; and some few very high-level ones like YPackageSelector and YPatternSelector that do the whole package selection thing alone, working just on the libzypp level and changing the status of packages or patterns there.

For the YaST Qt UI, the YQPackageSelector / YQPatternSelector widgets work purely on the Qt and libzypp level; no other YaST infrastructure involved, in particular no Ruby (or formerly YCP) interpreter, no libyui-level widgets, no bindings between Qt / C++ and Ruby / YaST-core, nothing. So it's not too hard to rip all that part out of YaST and create a standalone program from it.

For the NCurses UI, the NCPackageSelector / NCPatternSelector create a lot of libyui widgets (inheriting YWidget / NCWidget) and use a lot of libyui calls to glue them together; and all that of course still needs a lot of YaST / libyui / libyui-ncurses infrastructure. So NCurses is out of scope here.

Preparatory Work: Initializing the Package Subsystem

To see if this is feasible at all, the existing UI examples needed some fixing to check what is needed on that level. That was the make-or-break decision: Would it be realistically possible to set the needed environment in libzypp up (without being stranded in the middle of that task alone at the end of the hack week)?

Yes, it is: That part is already working:

https://github.com/yast/yast-ycp-ui-bindings/pull/71

---

New KDE Plasma notification app/applet by apappas

Description

My memory is terrible so I depend a lot on notifications to carry me through the workday. As a plasma user I am ok with the current applet, but I don't love it. It is too small for the centrality it has in my day. Also I dislike how you can not go back to notifications you have dismissed

Goals

Develop a plasma app that * must gather notifications without disrupting the existing notification app * must offer the ablity to refer to dismissed/archived/seen notification up to some defined point in the past * must allow deletion of notifications

---