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!

The CRUSH algorithm determines how to store and retrieve data by computing data storage locations. CRUSH empowers Ceph clients to communicate with OSDs directly rather than through a centralized server or broker. With an algorithmically determined method of storing and retrieving data, Ceph avoids a single point of failure, a performance bottleneck, and a physical limit to its scalability. CRUSH requires a map of your cluster, and uses the CRUSH map to pseudo-randomly store and retrieve data in OSDs with a uniform distribution of data across the cluster. This project aims at creating graphs of the crush map, for better visualization of the Ceph cluster.

More and more customers use our products in mission critical environment. They have a huge need that things run smooth. With Hack Week we have the challenge

inputlirc is superior to previous lirc input daemon as it can monitor multiple input sources at the same time. This is needed for some new remote controls that appear as two devices, providing both virtual keypresses as well as mouse clicks. Since I'm too lazy to always build the package manually, I would like to have it available for OpenSUSE.

While packaging node.js modules, which often depend on specific versions of other node.js modules, sometimes many of them, you easily end up in dependency hell, and maintaining an OBS project with a few hundred of those modules can be a tedious task. So the idea for this project is to familiarise myself with how exactly dependencies are managed on package and repository level, check out what tools exist to drill into dependency data, and hack something that helps keeping OBS repositories in a dependency consistent state.

I'm using soundkonverter a lot (my whole music collection is flac, but for the car or my children I prefer mp3) and it is working fine. However when doing mass conversions, building the list of files to convert can take ages. It seems the filelist is being re-created for every title added. Debug it and try to fix it in order to speed up this operation.

[User] who has lots of PDFs to read

DAPS (https://build.opensuse.org/package/show/Documentation:Tools/daps) is a tool we use in the documentation team to create/validate/export/... docbook documents. It's currently available for SUSE and openSUSE systems, and I believe that packaging it for Debian GNU Linux would help both the DAPS and the Linux community (and me myself as I'm using Debian at home as well :-)

Package a basic, stripped down version of sysvinit for emergency cases, so you can repair a failed system without interference. My goal is not to replace systemd with sysvinit again, but to provide a sysvinit-base package that does not have any dependencies at all and can just be installed on any system. sysvinit will only be used in exception situations by specifying the kernel parameter "init=/sbin/init" or something like that. The package will come with the binary, a minimal inittab and a basic boot script that does only the really needed stuff. Experiment with an extension to have sysvinit execve systemd, so people can boot into their allmighty uber-daemon once the system has been fixed.