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

I have been known to talk anybody I held presentations with into using odpdown. That was always a little awkward, since it started off with pip install odpdown, rather than zypper install odpdown. I want to fix this awkwardness and package odpdown properly so it can be installed as a RPM package. I'll also include the auxiliary infrastructure I've added around it over the years (various Makefiles and scripts for generating transcripts from comments) to the package so others can benefit from that stuff, too.

2019

I intend to work on translation of KDE to Czech language. There are lot of typos and fuzzy messages accumulated in Summit project of KDE. I intend to work on them and increase KDE translation coverage.

Live audio tools could use some work in openSUSE and are fun to play with. Finally many of these tools are making it into tumbleweed (And Leap 15.3) especially Cadence.

The idea is about an easy way to allow users to make upgrades (e.g.: changing from one major version like 15.0 to version 15.1) using a GUI and as easy as they can in Ubuntu. Something like a notification with a button to perform the upgrade with just one-click, instead of having to deal with the terminal, that frights some new users and gives them the sensation of an outdated system.

posixovl is a FUSE based successor of the old UMSDOS. It has a goal to provide POSIX file system functionality on top of vfat. Its code is nice and well written, but its feature set is not complete yet. It just supports: POSIX modes and user/group, hard and symbolic links, device nodes and named pipes. Much more can be done:

Make a final attempt to implement a graphical user interface for grub2 (gfxboot2).

It's quite some work, unfortunately. Here's what's done so far:

This is the tool I've been working on since HW11 and it needs more work. Actually, there's always something which could be done on it. It is basically an x86 instruction decoder with special emphasis on the kernel and decoding interesting pieces of it in order to help in the development of low-level patching techniques, among others. git repo: https://gitlab.suse.de/bp/x86d

Dochazka is a long-term project to replace the obsolete Attendance & Time Tracking system used by the Prague office since 2007. Dochazka is a complex system consisting of three major components: - RESTful backend App::Dochazka::REST (with lots of help from Web::MREST)

New Development In previous hack weeks, the first few days ended up being wasted on just getting it working. I'm pleased to share that the code quality has improved dramatically since the last hack week and there are now extensive test cases for both unit testing and testing against real vmcores, and we'll use both mypy and pylint (if installed) to perform static analysis. Packages for those are available in openSUSE or as part of the crash-python OBS repo for SLE15. It has been tested with kernels from 3.0 to 5.1.

~> osc my pkg | wc -l 699