The base version for uselessd is systemd-208, which is the version used in 13.1. Let's try if a direct substitution of the binaries works and watch out for the problems.
Expected result of the project is to have a working package with "Conflicts: systemd" and "Provides: systemd". The goal is not to fix all problems, a stripped down system with uselessd is considered a good achievement. Anything more complicated could build on top of this.
Tracking and fixing translations in modern applications is a surprisingly complicated task. Visible strings often come from several projects, and strings can be processed by a complex formating. The project should extend the current project trace-wrappers to easily display string sources inside the application.
The project successfully reached a working state: watch gettext
I'm in SUSE for about a month and as a fresh graduate I had to learn a lot of stuff during this period. And there is a bunch of other things I will have to learn of course. Therefore I would like to use Hackweek to deepen my knowledge of various tools, processes, techniques or other packagers related stuff. However it would be quite a pity to hold the acquired information just to myself. So I would like to keep the result of my learning for further usage either by enhancing the Innerweb wiki, the public openSUSE wiki or by creating new wiki for packagers' purposes.
Who can utilize this knowledge base? Newly employed packagers to learn important things quickly. Current packagers to share interesting techniques or hacks among them. Or just whoever else wants to quickly understand certain packagers' process or tool.
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 :-)
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.
Currently, the usual way to communicate with VM instances in the cloud from outside is ssh. This is okay for most uses, but a) does not work when you mess up with the guest's ability to network and b) requires a free floating IP.
I wonder if, for qemu/kvm instances, it would be possible to use virtio-serial possibilities : from the guest, it is seen as a serial port, and from the outside, it is seen as a UNIX socket, or as something else. It is fast, as it does not go through virtualization and device drivers.
Implement file system image build using the Builder infrastructure. The project will create additional builders for the ext filesystems laying the ground work for restructuring other filesystem builders.