Retty is a tool for changing stdin,stdout,stderr of a running process (http://pasky.or.cz/dev/retty/) which may be handy if you want to attach to a process running e.g. from a died ssh session, changing running process to run from under screen(1) etc.. Currently it doesn't work for 64-bit systems and it doesn't handle changing of a controlling tty of a process (which may be possible using setsid() and opening a new tty). The aim of this project it to fix the above deficiencies and package the tool in OBS.

Play with Docker orchestration tools like the ones provided by CoreOS, OpenShift and kubernetes. Provide packages for openSUSE and SLE.

see iqlight.com to understand what an IQ Lamp is.

Create a system to allow a community to add contextual information to "open books". Think wikipedia for books

Predicting the non-functional properties of a Ceph cluster can be quite difficult. There are many inputs in the hardware setup and software configuration that affect the resulting availability, reliability and performance (latency and throughput at nominal levels and during degraded and rebuild times). I want to understand the interrelationship of these parameters better and build a (perhaps interactive) model that allows us to predict the result without the need to build a ten thousand node cluster.

provide a summary report of data from a sar data file. Report should be broken down into subsystems - cpu, memory, disk, and network, and provide individual summaries for each device (cpu, disk, nic).

I want to revive my "Cloud in a Box" project and this time focus on how OpenStack's Heat automation framework can help with setting up a complete demo or QA environment consisting of several SUSE products (e.g. a SLEPOS Admin/Branch/Client environment). Looking for contributors who want to hack OpenStack (especially work on a Horizon UI plugin for managing Heat-based "SUSE blueprints").

Although I've been maintaining CRIU package, I had little time to play with it recently. It's still interesting especially in combination with various containers. So let's spend (or waste) some time.

I'm sitting on old patches that implemented predicated value numbering in GCC by combining the algorithms from http://portal.acm.org/citation.cfm?id=512529.512536

There is quite a popular Android software for connection OBD standard adapters but not for older, brand specific ones. One for pre 2001 VAG cars is this one:

The kdump package can now use SMP and multiple targets with constant memory requirements. The goal of this project is to find the optimum parameters for dumping a very large machine (SAP can give me access to 6TB, SGI is able to test with 64 TB).

The idea is to produce a standalone, independent tool to save and restore windows positions and sizes, analogous to a similar feature in KDE desktop. This would be handy in various lightweight desktop enviroments.

If you want to use the full potential of SSDs as primary (and possibly only) storage on SLE or openSUSE systems, you are supposed to perform several configuration settings to make it fly, including: - changing the io scheduler of the device to noop or deadline

We had a quick course of Coccinelle during the last Labs conference. The tool is really great and I would like to explore possibility of checking lock invariants for particular functions. Julia was really prompt and implemented something that should help but I didn't get to it since the conference.

Starting with CUPS 1.6 things have changed considerably. Clients are no longer discovering broadcasted printers anymore. Distributions (e.g. Debian) has backported the original protocol into cups-daemon package but this doesn't seem to work either on my laptop. I would like to look and try to understand what the hack is going on here. The outcome should be my understanding of the change and how to configure CUPs to behave reasonably again.

cscope is a great tool index C/C++ sources and allow to navigate through the code. I have learned that the project is mostly dead and what is worse it uses its own database format to store the index. I would like to see some extended functionality in the tool - e.g. search whether a function A is reachable from B, filtering search results per-file, fix functions with function parameter detection (such functions are not recognized properly currently) and some others. See if the cscope specific storage can be replaced by a more generic database (sqlite?) and understand how the code flow works so that new extensions would be easier to implement.

The primary motivation for crash-setup (created by l3team) is to make kernel crashdumps deployment and crash using as easy as possible. This has been the case for quite some time except the tool was quite l3slave centric. With a great help from tcech the tool is close to be fully usable from other machines and !.de network as well. Let's finish the last pieces. This looks like a very minor project but it will be great to have it finally!