Problem statement

Once a kernel is built, a developer/janitor may want to boot the kernel for various reasons, such as performing simple boot test or running tests and workloads from user space or simply playing around in a shell. However, an easy to use and a descriptive tool to perform those tasks doesn't exist to our knowledge.

SLE Engineering have a large flatscreen in the shared space just outside of Thorsten Kukuk and Stefan Behlert's office It runs Windows

Build a base image and template (both kiwi and Dockerfile) for openSUSE Leap 42.3 using the native OBS container building feature. Results/WIP will be available here:

• Setup Tensorflow on OpenSUSE 42.3
• Look for a way to package it

First part is to support automated builds on git pushes also with gitlab, similar to what we do already with github.com. This means OBS would get notificated in a save way to refetch sources and start build on each commit. Second part is to support automated branching when a pull request gets created. This allows CI similar to travis on pull requests.

This is a UEFI only device where openSUSE does not boot, hanging after loading the kernel and the initramfs even disabling secure boot. The goal of this project is to learn as much as possible about UEFI, secure boot and finally install openSUSE on this device.

We got a couple of GSoC projects around Jangouts this year: - https://code-master5.github.io/Aug-22-2017

YaST dumps quite information to its own log file (placed at /var/log/YaST2/y2log). That info is very useful to understand and discover what is happening when an issue appears. All YaST modules write into this log file, and the brand new yast2-storage-ng is not an exception. Some improvements are necessary regarding to the logging of this new module: * Libstorage-ng is the C++ library powering the rewrite of the YaST storage stack. For using libstorage-ng from yast2-storage-ng in a more Ruby-like way, we created a wrapper that provides several features like automatic downcasting. But the current downcasting mechanism used by the wrapper causes libstorage-ng to introduce a lot of noise in the YaST logs. It would be nice to reduce that noise.

The theory behind the partitioning proposal of yast2-storage-ng is that all possible distributions of partitions in the disk are evaluated and the best one, according to this criteria, is chosen. But I have found several examples in which is hard believe that the result is actually the optimal distribution of partitions. So I want to invest some time checking if the error is on my side and the code is indeed proposing the best solution and, if that's not the case, improving the decision making of the code.