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

Join the Gitter channel! https://gitter.im/uyuni-project/hackweek

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.