terraform-provider-libvirt supports CoreOS ignition file/content, which end rendered as kernel command line options (the provider does some nice stuff like allowing you to pass the json content and it will take care of putting it into a temporary file). The idea is to:

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.

2019

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

kCFI is a tool that enables the compilation of commodity Operating Systems with Control-Flow Integrity protection. kCFI first prototype was developed/implemented during a PhD program held in the University of Campinas, in Brazil. Although fully functional, the tool remains in a very experimental shape, needing to be refactored prior to being released. As kCFI consists in multiple tools, which include compiler plugins, kernel patches and binary analyzers, its deployment is considerably complex. Once code refactoring is finished, the next step consists in setting up proper repositories for the tool and for each submodule, along with scripts and documentation to enable easy configuration and compilation on new environments.

There are a couple of interesting initiatives that make the openSUSE project interesting for SMB, such as

The Invis Server

Plans of the Project

After some time I would like to move KF5 translation ahead again.

djmount is a neat idea - see UPnP/AV resources in your directly in the file system. Unfortunately the code hasn't been maintained for ~10y, and - at least for me - seems to by plagued by various bugs causing crashes and what not. There's currently no official openSUSE package. This project aims to pick up the code, fix bugs, and make the tool actually useful again. The code itself seems to be in quite a good shape, so this should be doable.

BPF Compiler Collection (BCC)

https://github.com/iovisor/bcc

The idea is to create a bootable medium (eg. pendrive) that allows: * Selection of either SLES, Leap or Tumbleweed.

This was planned for previous hackweek (hw16-1) => Automated deployment of virtualization hosts and build up of virtual machines for xen+kvm+related tool testing.

Oficina, a mechanical workshop application developed in Qt/C++ Hackweek 17: Work on TODO - Test. Make it very stable, after that, insert it in openQA.

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.

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

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.

There is a running gag built into openQA called interactive mode. It goes like this: "if you need the interactive mode, it's broken". The reason: the so called interactive mode is a collection of hacks - in theory making it possible to update needles in a running test. But in fact it's a UI desaster that almost never works. So the goal of this hackweek project is to get rid of it - and instead build a real control from the webui into the backend allowing tests to be written on the fly including needle creation/updates. Easy as that.

The openSUSE build service could build hundreds of packages in parallel but in practice serial package dependencies prevent that.

L3 bug reproduction often requires becoming the admin for a moment. I'd like to write down some nifty tricks I used to get certain “interesting” system configurations to work.