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:

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

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.

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.

Try to get back an automatic email notification about new or changed SAP Notes. Since SAP has closed down some of their internal servers, which hosted an unofficial database/API to the SAP Notes, the nice email notification service of the SAP LinuxLab is terminated.

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).

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.

There are many fun peripherials that you can connect to a RPi but PC users are not left out either * attiny85 <a href="http://www.banggood.com/ATTINY85-Mini-Usb-MCU-Development-Board-For-Arduino-p-971122.html&quot;&gt;&lt;img height="48" src="http://img2.banggood.com/thumb/large/2014/xiemeijuan/03/SKU207366/SKU207366-3.jpg&quot;/&gt;&lt;/a> has SPI and i2c interface so could be possibly used as USB<->i2c or USB<->SPI bridge. Unfortunately, the USB support needs some non-standard timings so there is quite a bit of integration and debugging needed.

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.

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.

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.

Description

It can boot up from udisk/floppy.

The goal is to use the work from the debug-early GCC branch to generate better debug information for LTO compiled objects, especially with regarding to language specifics like classes and templates. This has now been achieved and openSUSE Factory

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

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.