The only Mediatek "hacker" board available is from 96 Boards [1]. Unfortunately up to now there is nearly no mainline support. Idea would be to improve this situation. The idea would be to get the pin-controller merged first and then hopefully most of the other stuff can be just added (fingers crossed...)

Currently we have only packages for python2 but OpenStack is starting to work with Python3 so we need python3 packages and try to get it working.

PDF format allows inclusion of digital signatures. Unfortunately, Evince can't provide these metadata to the user. There's an upstream bug and actual implementation resides in poppler. The integration is still incomplete though.

I want to write a bot that generates random Gothic facades. Maybe using L-systems? Maybe that generates SVG? building -> aisle, naves, aisle

Almost all our laptops, and many servers, feature a TPM today. The TPM doesn't have the best reputation in the community because it could be used to lock down platforms or do nasty things with DRM. Under normal conditions on PCs, the TPM is controlled by the system owner and could actually be useful for almost anything involving crypto. Unfortunately the integration of the TPM in the OS is essentially non-existent. The introduction of the TPM2.0 standard complicates matters, because we now have two different devices with different APIs. The goal of this project would be to identify reasonable use cases for the TPM, evaluate exisiting projects, and create ways how to integrate it into various workflows in openSUSE.

This idea was inspired by the recent discussion on the "talk" mailing list about the (in)security of the German ID card. The Chaos Computer Club and other researchers claim that the ID card is insecure. Actual attacks that have been demonstrated are based on keyloggers. Keyloggers might be the biggest security threat for Linux users at this time. Keyloggers are trivial to write for Linux and readily installable, and a keylogger with normal user rights may read root's password. One might ask "Why are we caring about local root exploits at all as long as users run stuff like sudo in X terminals"? Keyloggers can even read the input from devices like the Yubikey.

Some time ago the YaST team started to get bug reports about the "System Log" option displaying no content. By default this component opens /var/log/messages and after the switch to systemd that file is not longer used by default. Thus, we created the yast2-journal module to allow viewing of the systemd journal (journald). But the new module did not substitute the old viewer because the old one is still useful to inspect plain text files like /var/log/boot.log and because is still called from other YaST modules. The current situation is confusing. In the YaST main screen we have now "System Log" and "Systemd Journal". Is not unlikely that in some other places we only have a reference to the old one. It's not clear when to use which one. That has been reported several times, like in bug#948729.

Wireshark has a CLI program called tshark that can dump the dissectors raw (or xml) output. It would be nice to have complete curses wireshark UI, either by reusing tshark xml output or by making another ui program.

Resilient File System (ReFS), codenamed "Protogon", is a Microsoft proprietary file system introduced with Windows Server 2012 with the intent of becoming the "next generation" file system after NTFS. https://en.wikipedia.org/wiki/ReFS

I started this project a couple years ago, and it only recently got off the ground enough that I committed the code somewhere (though it's still pretty minimal). A lot of work still needs to be done in the main instruction loop. I've been implementing instructions in the order of the execution of a test binary I created on an HP PA-RISC system. To get started:

The YaST team is rewriting yast2-storage. That includes new shiny code for the storage proposal during installation. It calculates what partitions and/or volumes need to be created to allocate the system and finds the best way to create those partitions in the existing free spaces. The second part becomes more complicated than it looks as soon as you start considering the restrictions imposed by each volumes and by the technology (primary vs logical partitions, for example). Right now, the problem is solved by brute force. All the possible distributions of partitions and LVM physical volumes are considered and the best one (according to several simple criteria) is chosen.