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.

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.

Video Recording of openSUSE Conference session which introduced the project

Core Project

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.

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

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:

We already tried to improve the Jangouts data model in the past and, although we made quite some progress, we did not finish it. I've been playing a bit with React and Redux lately, and I would like now to try a different approach replacing Angular with that combo. Using Vue.js might be another option too. Of course, we are not going to rewrite Jangouts in just one week, but let's see how far we can go. By the way, the redesign branch contains some interesting stuff from one of the GSoC that we should consider.

Idea is to have SUSE system with OpenZFS as root FS. Why ZFS

Description

It can boot up from udisk/floppy.

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.

openSUSE Leap 42.3 goes for a rolling release model with automated openQA tests. That covers only so much though. We need manual testing too. In previous releases a google document spread sheet was used to coordinate and track the efforts.That's probably not the best method anymore. Come up with ideas and a prototype of how manual testing could be guided, tracked, visualized for a rolling development distribution with volunteers testing.

RPMlint upstream milestone 2.0 is shaping up but there are still ticket that needs to be tackled to finalize the release and enjoy the freshness of awesome QA on Tumbleweed/SLE16. In this hackweek we plan to look on various problems as described at:

Learn the inner workings of TCP as implemented in the Linux kernel. This will involve * reading textbooks and IETF docs

For years we have been discussing the idea to modularize SUSE Manager. This would enable developers to create their own extensions to SUSE Manager without needing to touch the core repository. There are several frameworks that could be helping in that direction. The goal here is to create a Proof of Concept with the virtualization features moved into an add-on.

GNOME Software supports distribution upgrade, that only requires a few clicks for upgrading your system. But it's not integrated into Leap. So this is that I plan to do this Hack Week.

Involved components

I've attempted this several times already and each attempt had different shortcomings. I'm kind of curious about how exactly will I fail this time. And it looks like I haven't failed this time.

Avahi is (among others) a domain names auto-configuration system for Linux compatible with Bonjour. The project is to dig into avahi source code to modernize it if possible and fix bugs.

Simplify the codebase by using a more modern toolkit to accelerate maintenance and future development. Enjoy Hakkaweek!

Customers are using complex storage stacks such as LVM over dm-crypt over MD RAID over multipath over iSCSI and FC with LOTs of LUNs, and we're facing problems in that area which are usually very hard to reproduce. It's also hard to guard against regressions. Being able to quickly and reliably set up VMs with various types of storage / multipath is a key part of testing multipath. It's doable, but cumbersome and has a steep learning curve. I want to create easy-to-understand manual recipes plus scripts that are both easy to understand / customize and deploy.

Lately the necessary patches to get rudimentary support for the Mediatek chromebook with a mainline kernel got posted. There are some hacks and I'll work on some good solution to get graphics go, at least.

Join us in singing a capella — barbershop-style and others. Find us on RocketChat: #chameleon-harmonists

The USB controller (Via Labs 805 XHCI) on the RPi4 sits behind a PCIe bus which has no drivers at the moment in u-boot. After implementing it, we'll also have to make sure the USB HID is correctly connected with UEFI routines.

The project aims to port openSUSE to the ROCKPro64. The ROCKPro64 is the most powerful Single Board Computer released by Pine64. It is powered by a Rockchip RK3399 Hexa-Core (dual ARM Cortex A72 and quad ARM Cortex A53) 64-Bit Processor with a MALI T-860 Quad-Core GPU.

transactional-update, the application to update read-only systems such as openSUSE MicroOS and openSUSE Kubic and the Transactional Server installations of openSUSE Leap, openSUSE Tumbleweed and SUSE Linux Enterprise Server, evolved from a POC to a fully fledged solution - and is currently completely written in Bash. This has been working really well in the past, but is gradually reaching its limits, especially when thinking about supporting additional file systems or ports to other Linux distributions - yes, we have a huge interest in other distributions adopting our technology. A C++ version would simplify those abstractions, but would it also make maintenance of the complete application easier? Check that as part of a POC and refresh C++ knowledge on the way there.

I would like to learn Elixir, I plan to do some tutorial and look into books. I if I have time also start with Phoenix the framework for Elixir :smile:

There seems to be an overall consensus that the ioctl interface used by ethtool is a poor design as it's inflexible, error prone and notoriously hard to extend. It should clearly be replaced by netlink and obsoleted. Unfortunately not much actual work has been done in that direction until this project started. The project started in Hackweek 16 (fall 2017) and has been worked on since, both in Hackweek 17-19 and outside. First two parts of kernel implementation are in mainline since 5.6-rc1, first part of userspace implementation (ethtool utility) has been submitted to upstream at the end of Hackweek 19 (2020-02-16).

To ease debugging cgroup relates issues this suggests to: - list cgroup hierarchy tree(s),

Whether it's building a newer, upstream UBoot, EDK II, or merely a SLE based rootfs, I want to make this platform a realistic possibility for desktop, digital signage, labs, etc.

Provisioning works with Autoyast/Cobbler for traditional clients, with profiles to enable major version upgrades. The goal is to offer that in a predictable way that can be scheduled and automated for salt minions. Salt minions pose a different challenge, and we would like to enable a reboot into the upgrade without needing PXE not traditional client to enable it.

The idea here is to study and understand how ephemeral storage for containers works and investigate if local storage could be avoided at all and Ceph used instead. Could new storage driver be developed to support Ceph storage:

Currently we have two sponsored 3D printers available in the Nuremberg office. Both are located in a lab - which makes it hard to access them. Both also need some (hardware) maintenance. This (hopefully short) side project should make the printers more usable and accessible for others.

Features I'd like to implement: * Built in search on obs, with one-click branch checkout,

The idea is to hack os-autoinst-distri-opensuse infrastucture and explore design patterns that can fit. The end point of this is to restructure the framework in such a way that the main-common.pm is more efficient, functional and readable.

I would like to set up a small backup server on my spare hardware What I have:

We kinda need more flexible PXE in Prague office, UEFI would also not hurt - so lets check what we can do to make it better. EDIT (ggherdovich):

Build and benchmark some smaller SES clusters (2 - 3 nodes) targetted at edge deployments. Evaluate the performance and configurations.

Background

Given the number of different demands on our time and attention, it becomes increasing hard to focus and find the 'flow state' where a developer can be most productive. Interruptions due to chat notifications, email, and updater applets all break focus. Additionally, the desktop metaphor has in most cases failed to evolve as the browser and other MDI interfaces have become the focus for many users, and increased performance has allowed us to keep more tasks running and present on the desktop at once, presenting a higher cognitive load to the user.

OSC is already available on Homebrew, but it is missing the integration with Staging as the openSUSE-release-tools are not available. In this Hackweek project I would like to get the openSUSE-release-tools running on macOS via Homebrew.

There's a long standing request to extend the output of dmidecode to something that would be machine-readable. Something like an XML or JSON-based format. Unfortunately this can't be implemented right now because the output of dmidecode is generated by open-coded printfs as the DMI table is being parsed, with no intermediate structures nor temporary buffers. While implementing a machine-parseable output is out of scope for a single hack week, let's remember that even the longest journey starts with a single footstep. I would like to try and rewrite the 5200 lines of code of dmidecode in such a way that printing the output would be somewhat separated from parsing the DMI table and done by a limited set of dedicated functions. Alternative output formats could later hook into such functions.

I'd like a way to have a device on my desk which lights up to indicate that I have something I should be paying attention to. Initially, I'd like this to be for Office365 calendar events and GitHub mentions, but ideally it should support arbitrary messages. The plan is to assign specific colors (ideally "patterns" consisting of a sequence of colors and time) to specific message types. I have a handful of raspberry Pi Zeroes, a couple of OLEDs, a strand of individually-addressable RGB LEDs, a power supply, and some misc electronics (like the 3.3-5v logic level shifter necessary for the 5v LED strand). I'm thinking Python is probably the way to go for the software. I'm hoping OpenSUSE actually works on the Pi zero. :D If not, there's an ESP32 with a built-in display and a few Pi 3s laying around barely used, maybe one of them will work.

Since SUSE Manager doesn't scale out and stacking it into another pyramid of susemanagers won't help here, the real architectural changes needs to be done to achieve true scale-out of this product. This hackweek project is about how to Turn SUSE Manager into a cluster. Areas to be tackled:

Salt is moving towards a plugable architecture using POP and Idem. This project is about experimenting with those new concepts by applying them to a real life case: the virt execution and state modules. The goals of this project are:

Motivation

Running async actions in SUSE Manager lacks a user-friendly feedback. For instance, running a salt highstate on a system:

Put together a collection of ideas and resources to mentor people managers on how to make better decisions: - Useful mental models and how they work together

I'm hearing impaired. Where others have no issues following talks or dicussions, I often fail even grasp the bottom line what it's about. I've got hearing aids, but they help only so much. I also have an add-on device for my hearing aids that acts like a bluetooth headset. Unfortunately, making this thing work under my Linux desktop has been an ongoing, frustrating struggle. On the contrary, it works flawlessly with Android devices of different generations, and even with my lowly Gigaset phone. Actually, the thing works better with older kernels/Linux versions than with current TW. While I've little hope to solve the bluetooth audio issues on Linux for good, I hope at least to be able to understand better what's going wrong, and be able to slow down or even stop the deterioration I've observed lately.

I want to study the knowledge of openQA I will read the online documents and do some experiment in virtal-machine.

SUSE is using OBS as a build system and openQA for automated testing purposes. The goal of the study is to find out the strengths and weaknesses of these systems and compare them to other open source alternatives in a structured way.

There is a number of annoyances and pending improvements when working with the Salt Formula for provisioning Prometheus Exporters in Uyuni: - Fix issue with cleanup in case the monitoring entitlement is removed.

With the approach of kernel 5.6 SGI Octanes are supported with builtin IO components. What's missing for a graphics workstation is a driver for the graphics card. There is already a not upstreamed framebuffer driver for Impact graphic cards. Since there will be no new framebuffer driver accepted upstream, the goal of this project is to convert the existing frame buffer driver to a DRM driver and make it ready to be sent upstream.

I want to set up a few small raised beds to plant some vegetables. Volunteers more than welcome-just ping me on RC.

CephFS is awesome, but without a VPN it's not safe to be routed over the internet, and it lacks client support on many platforms. The Linux Kernel Library allows for the linux kernel to be built as a cross-platform user-space library and integrated into a regular Android, Windows, macOS, etc. application. This project combines CephFS, LKL and wireguard, and sprinkles some io-uring on top. My objectives are:

I have several themes in progress, they all need lots of work before they could be used with openSUSE. * The gtk people keep changing things so the gtk theme I use to match my enlightenment theme also needs fixing.

Ai and Machine learning play important role in our life, I'd like to learn it. research to see is there any way of using DEEP learning on open source stuff.

What is the VFX Reference Platform? https://www.vfxplatform.com/FAQ/

In the past, some customers ever complained that OCFS2 file system performance went down when listing a big directory (e.g. include 400k files). According to my preliminary investigation, this performance problem is related to file system block allocation algorithm. Then, I want to look at the current mainstream file systems (e.g. EXT4, XFS, etc) block allocation algorithms in this hack week, compare and analysis these algorithms advantages/disadvantages.

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.

Hackweek 21?

Postmaster desperately needs a mail spool. I need to come up with a good way to store meta information about queued messages. An sqlite database seems like a natural fit because I might want to do some nontrivial queries in there to figure out which messages to deliver (and where). On the other hand, interfacing with sqlite is a bit unpleasant, so instead I might want to write one big JSON file that contains all relevant information. That would certainly suffice for the first version ...

Create a prototype of an agent on kvm hosts to control the distributen of master / worker nodes between different kvm hosts. No central control plane should be used - the main design goal should be: as simple as possible :-)

Since Kubernetes already has a clear path of "in-tree" volume plugin to CSI migration. I would like to understand the concept of CSI with writing a simple driver for Kubernetes. Reference:

Termux is already bringing a terminal and debian package manager to Android. Let's see if we can reuse it and provide a base system with zypper and build openSUSE:Factory for it in OBS.

This hackweek I will focus on improving my drawing/painting skills. I will do either some portrait for people I know at SUSE and this could be used as Github profiles or do something related to Linux/SUSE chameleon etc. ( without any precise goal).

Although CNCF projects are almost exclusively related to Linux containers, some ideas, like wrapping all the services into network proxies to create a distributed data-plane and enable true observability, could perhaps be explored for some kind of backport in complex legacy distributed systems, like... say... S4/HANA?! I don't even know if this is feasible, but trying won't hurt... just stand at a safe distance from the cluster!