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.

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

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

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

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

Description

It can boot up from udisk/floppy.

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:

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.

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

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.

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.

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.

DevOps teams face double sided challenges: development tasks should be planable and maintenance tasks should maintain their flow to provide maximum value through the queue. Build a prototype JIRA project to help them organize their workload with a Scrum board for their development tasks and a Kanban board for their maintenance work, all fed from a common backlog.

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.

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:

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.

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.

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

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

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.

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.

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.

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.

Last hackweek filtra was created – a tool to extract information like lead and cycle times from Github repos for (but not limited to) projects that are doing Kanban. The collected metrics can then be visualized with Grafana. Currently there are two problems with filtra:

Why is it nice?

I tried to work blockchain into this, just so we could cover the trifecta of buzz words. Sadly I could not maintain saintly and do this. What do I plan on doing? a few things, so please reach out if you would be interested in any one of them. I will update with a list later.

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.

SUSE CaaS Platform is a Cloud-Native Computing Foundation (CNCF) certified Kubernetes distribution. - Family with SUSE CaaS Platform

Mash is a Python based CI/CD pipeline for automated testing and publishing of public cloud images. Currently the production and development deployment for the package is inconsistent, slow and manual. This is a barrier to rapid development, deployment and testing. It also means the development workflow is different than production. This can lead to production issues which were not seen during development. In order to modernize the Mash workflow I plan to spend the week digging into a plethora of tools to first learn then build out a new workflow. The goal is to simplify deployment by choosing tools that provide consistency, modularity and repeatability. By leveraging the best tools available we can harden the code and accelerate the release cycle.

This project aims to run VMs in a CaaSP 4 cluster using kubevirt and a libvirt+qemu container (aka compute container) based on SLES15 SP1/2. Compute containers based on openSUSE Leap15.1 and SLES15 SP1 already available in registry.opensuse.org and registry.suse.com respectively. VMs can be deployed to the cluster but there are several functional problems that need investigating, e.g. accessing the VM's serial and VNC consoles, proper network access, etc.

With 'pint' the Public Cloud Team already provides a command line based tool to get information about the images we're hosting in the public clouds. It's provided via the Public Cloud Module in SLE as well as in the Cloud:Tools repo. As more and more people are asking about information on the images we've published but not all of them feel comfortable using tools on the command line we like to provide a web UI which shows that data. One should be able to search for specific images, sort by regions or state etc.

Give a more complete overview of the infrastructure and the processes the documentation team uses to write, maintain, and publish the documentation for the SUSE products. Add missing information/chapters to the guide.

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

It would be nice to have a OS that can be tinkered with easily by having only a compiler as the only binary on the system.

The next release of Ceph (Octopus) will be delivered via containers.
A new tool named cephadm is being developed to bootstrap and manage Ceph containers.

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

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.

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

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.

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:

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.

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.

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.

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

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.

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

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

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.

Currently, way we distribute ssh keys within QAM on our testing infrustructure is a bit cumbersome - maybe we should try to (ab)use existing salt used by our internal infra team.

The current GUI of FriCAS is ancient and difficult to use. I plan to improve that by using modern GUI frameworks, at least to make a working proof-of-concept demo to show this idea works.

Picotm is a system-level transaction manager. It provides transactional semantics to low-level C operations, such as modifying data structures, (some) file I/O, memory access. Picotm also handles error detection and recovery. It's fully modular, so new functionality can be added. For the Hackweek, I want to dedicate some time to picotm. I want to finish some of the refactoring work that I have been working on. If there's time left, I'd like to investigate two-phase commits and how to support them in picotm.

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

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.

It ain't rocket science, it ain't thrilling, it's just useful. Quick Event is an established orienteering management software but it is still distributed in non-standard form for Linux distros. Package the software in standard packages for major distributions.

This can be seen as a subproject of ethtool netlink interface but from the technical view it's independent. Every new piece of software is going to be buggy and with frequent changes and rewrites, new regressions are introduced. Automated selftests can help a lot but as ethtool deals with hardware devices, we do not want these tests to depend on a specific hardware. The netdevsim driver was created as a virtual device which (unlike e.g. dummy) cannot be used for actual network traffic but implements various configuration interfaces so that it can be used for their (automated) testing.

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:

labgrid [0] is an embedded board control python library with a focus on testing, development and general automation. It includes a remote control layer to control boards connected to other hosts. My idea was to use this to be able to test my MediaTek boards remotely.

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:

I would like to learn more about something outside of engineering. I have selected to learn more about marketing; something our overall team is doing more of...

• implement a POC deploying CaaSP v4 on top of AWS using: Spotinst's elastigroup
• "Spotinst Elastigroup predicts Spot Instances behavior, capacity trends, pricing, and interruptions rate. Whenever there’s a risk of interruption, Elastigroup acts accordingly to balance capacity up to 15 minutes ahead of time, ensuring application availability.

Simplify, modernize, and accelerate the process and tools for reviewing YES submissions from partners. Hopeful goals to accomplish:

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:

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

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.

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!

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.

Using the camsource and vlc packages as an example. If camsource is configured to use a given dev/video[n] device with a choice of resolution in the width and height fields of a camsource conf file then if camsource is the first application to access the device captured images are as-expected. However, if an application like vlc is used for the same device (and exited) before starting camsource (e.g. to check the view from the camera before starting camsource) and if the camera supports higher resolutions than used in the camsource configuration what occurs is that camsource will not setup the camera to use the configured resolution and has a broken view of the camera output based on the vlc chosen resolution chopped to the camsource configuration. For example, with camsource configuration set to use 640x480 on a camera that supports 720x480 and vlc is used and exited before camsource is started then the captured camsource images contain two non-continuous partial image blocks with a horizontal border dividing them. I assume either vlc fails to fully reset the device configuration when exiting or camsource fails to initialize the device "from scratch" when starting. The two applications use different video device APIs but the setup and cleanup for the camera in each case is a very limited part of the application's functionality.

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.

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

I own a 3D printer / Anet AM8 / and after 1,5y its time to upgrade the electronics, mainly the stock motherboard and get it ready for multi-color printing. Also the time has come where I would like to not only download 3D models from thingiverse but also create or customize the models for my usage. Plan is to:

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:

This is kinda continuation of my last hackweek project - learning python3 the parcical way. The goal is again to replace existing bash script which will generate 3 node KVM HA cluster on my workstation and automate quite a boring part of HA regression testing.