Why Knowledge is only useful if it is accessible.

We started the SUSE Musician's Space several Hackweeks ago, out of which we spawned the SUSE band, now known as SUSE LOUD. Since there are a lot of musicians in SUSE, not all rock musicians, we decided to see whether we could get some other music projects off the ground during this Hackweek.

Python is well known all over the world and has wide range of usage. Lets dive into to a bit.

I want to create devel project for cryptocurrencies/mining tools/blockchain related stuff, fill it with packages and submit at least some of them to Tumbleweed. Lets go on as Standa took care of creating network:cryptocurrencies

2019

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.

TecnoAlarm is a house alarm system. The input devices are communicating with the main node of the system via an RS 485 bus. In order to be able to plug in such systems in a house automation system, its communication protocol needs to be reverse engineered.

We all pant for customer data. Which hardware do customers run ? Which packages are installed ? Which services are running ? etc. pp. A lot of this data is in the supportconfig. But this is neither collected, nor centralized, not easily accessible.

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.

Implement a basic file search for a given OBS project. An example of basic functionality can already be found for Ubuntu or Debian. The goal is to implement,

Features

With all those analyzers for C code we get so much information about our C code. Yet our shell code regularly nukes systems.

In this hack week we want to focus on improving the existing components used for http://docsearch.nue.suse.com. Creating separated repositories for each service and pushing them to github.com is also desired. We also want to create the theoretical foundation for categorizing text to improve the search results.

I'm using Conversations (XMPP+OMEMO) as an encrypted IM solution. Since a lot of groups organizing them self using WhatsApp, it's hard to stay away from it.

retro-gtk is a toolkit for GTK+-based Libretro frontends. It is mainly used by GNOME Games to play retro games via Libretro gaming console emulators. Currenly retro-gtk supports only software rendering. There are two ways hardware rendering can be used in retro-gtk:

After an internal call for help to take over software.opensuse.org deployment, I spend some time studying the code in order to find out what would it mean to take it over. The main reason was a PR from the community that has not been merged, and deployment depending on internal SUSE employees.

There is a lot to do in the openSUSE infrastructure land... So let's start, have a look at https://progress.opensuse.org/, take some tickets and try to resolve them as good as possible. There are also other interesting topics:

Learn how openQA was implemented in details. And will spend some time to learn Perl (e.g. read the book <Learning Perl>)

My current mail setup is mu4e and emacs based mail client included with the amazing mu mail indexer. mu works similar to notmuch but allows easy bidirectional operation with the original Maildir. Add mbsync (isync) to sync imap locally and msmtp and you have a full mail setup.

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.