Motivation

Testing GUIs is hard: unit tests require a tremendous amount of mocking and often don't capture the exact user input anyway, integration tests on the other hand are difficult to setup as they often require a dedicated infrastructure with virtual machines.

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

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.

This issue has been blocked for a while due to time constraints so I want to take Hackweek 19 to work on it.

Put together a collection of ideas and resources to mentor people managers on how to make better decisions:

Learn and use tools to build/deploy SUSE/openSUSE to the KVM environment for developing kernel CVE patches and testing automation

Create DevOps automation for testing PTFs prior to delivering to customers, that will be available to each of the team members using standard L3 tools.

The Gameshell is a small game console based on AllWinner R16 (Cortex-A7, IIRC the same CPU that the RPi2). Currently is supporting Debian, and some community member ported ArchLinux on it.

Diagnosing issues with stalling desktop application (or a whole desktop environment) is difficult these days as the application often requires multiple processes interconnected with sockets, pipes, futexes, etc. to work and often it is not clear which process is the one responsible for blocking the whole ecosystem. The idea of this project is to write a tool that gathers information about processes in the system and for each process that is sleeping display the resource (file, socket, futex) it is waiting on as well as the process that is likely responsible for unblocking (feeding pipe, sending data to socket, unlock futex, ...). Once the information is gathered, we can also plot it for graphical displaying with tools like graphviz.