Language Server Protocol (LSP for friends) is used in a number of code editors these days. There are implementations for various languages, but none for Salt States. The idea is to leverage Salt state module to parse edited files to provide completion of the state ids or paths.

Bug reports can be a great source of information, but usually finding the information requires extensive work in reading through all of the discussions and understanding the details about it. Could it be that machine learning can be used to extract meaningful information out of that? That's what this project is about.

Deploy Uyuni as an app from the Rancher marketplace - or install via Helm on any Kubernetes cluster, on any OS, or any Public Cloud.

The dream

openSUSE code

What is?

Project Description

• Create an automated L0-support-like analytics solution for supportconfig data that is tiered across a customer's environment and SUSE environment (similar to a very modular AIOps Edge-Core approach). A pictorial overview of the ecosystem

Following up on the experiment from last Hackweek ( https://confluence.suse.com/display/~digitaltomm/Business+Intelligence+in+SCC ), it would be great having a production instance of Metabase running in the SCC EKS cluster, connected to the production database of SCC.

The recent glibc 2.33 version recently available in Tumbleweed includes this change: ```

I'll continue the effort I started at last Hackweek to support Windows clients in Uyuni/SUSE Manager using Salt. When this is done, SUSE Manager would act as a WSUS server to Windows clients. https://hackweek.suse.com/20/projects/suse-manager-windows-client-support

https://gitlab.com/JanZerebecki/transparency-log-watcher Trillian is used for Reproducible Source, Build and Certificate Transparency. So it could be used to log the input to OBS and the build results and make zypper check it before installing an rpm. But currently clients wouldn't detect if the log shows them a different version than anyone else. See if there is a way so this can be detected.

The situation of maintained ansible roles for boring server stuff like setting up a LEMP stack (Linux, nginx, mariadb, php) is dire and I would like to improve that. This project is about creating a handful of ansible roles with focus on * Fully supported in openSUSE (Leap and Tumbleweed)

openQA currently supports different architectures: x86(_64), ppc64le, aarch64 and s390x. In this project I would like to add support for RISC-V[1]. First emulated ontop of x86, like we previously did with aarch64. As openSUSE images for that processor are already generated, it could be useful to do some basic automated tests on them.

For events like engineering summit or hackweeks, it would be nice to have a SUSE instance of workadventu.re, and have our own maps, wired with (open)SUSE's jitsi! I am looking for folks willing to help on those 3 teams:

tcetc

Summary

So I have 469.icu :), it's currently doing nothing... (and for sale) but in the meantime, I'd like to write an url shortener from scratch and deploy it on my own server

There is always something to do if you run the infrastructure for such a big project like openSUSE.... Our Admin wiki currently lists over 80 machines - and while we already "salted" some of them, there is always room for improvement and room to learn something new just by making your hands dirty and diving into the administrator role for a machine.

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.

Once more mailprocessing has developed some bitrot, namely this recent crash: ```

Problem description Jira is used inside SUSE to track various process/workflows.

During the previous Hackweek [0], I have successfully implemented, tested and merged [1] an implementation of the entire C++ standard header <future>. This time, my aim is to modernize the C++14-esque standard library [2] of HelenOS [3][4] with a C++17 feature - the <filesystem> header. The <filesystem> header is much larger than the <future> header which I barely managed to implement and test in the allocated time for the previous Hackweek, but <future> was mostly OS-independent as it relied only on previously implemented features of the standard library. The <filesystem> header, however, is limited by the filesystem API of the OS and as such implementing of the entirety of it might not be possible, limiting the scope of the project (which is a good thing due to the time constraints). The primary features of the header [5] that should be implemented:

Video Recording of openSUSE Conference session which introduced the project

Core Project

Sorbet is a gradual type checker for Ruby. Ruby is a dynamic language, which is great for reducing overhead for small