During the YCP Killer project, Y2R didn't translate most YCP operators and builtins into equivalent Ruby constructs but into library calls. This was necessary to preserve behavior in various edge-case situations, mostly when nil was passed around. The resulting code is often long and hard to work with. Example from SlideShow.rb:

Talking to people, getting the information about what had happened in the SUSE history, bringing all together to kind of a chronicle. Let's give it a try :-)

zypper is magic

A number of experiments suggest that it may be feasible to run zypper from an openSUSE 'live' media against a 'foreign' RPM based OS installation (eg. CentOS) and then 'zypper dup' to openSUSE

In short, give second breath to http://hall.suse.de/bugs/defects.cgi. Long version: Create a generated page reflecting SUSE organizational structure and containing links to useful generated Bugzilla queries and charts like:

The Problem: many bugs filed for openSUSE go to the screening-team by default and often remain there for weeks, so that developers (who would be interested in analyzing or fixing these bugs) do not learn about them. However, the screening process is a hard one

Write a simple command line tool for getting the open pull request from github and put it into a trello card. The tool should periodically update a list of pull request. In addition it would be great to have a connection between the trello card and github pull request.

Those working remotely or managing a distributed team know it: face time is invaluable. The former openSUSE team has been using http://sqwiggle.com to keep in touch and Google hangout to hold a stand up meeting every morning. We like the Sqwiggle approach. Although the last updates have made it worse, the concept of having a peep to your colleagues' desks to know if they are there (even if they are working hard or just talking to someone) and the possibility of starting a video conversation just clicking on the face shot can do a lot in reducing distances (and in killing the temptation of working naked for home-officers).

openSUSE 13.2 is taking shape on ARM, but we need to make sure we smoothen its edges to make an actual release out of it. The goal of this project is to make sure all devices we should run on actually work and that the last few packages necessary for productive use of ARM devices work properly on 13.2.

Moses is a statistical machine translation system that allows you to automatically train translation models for any language pair. Intention of the project is to tune up existing software, where a glimpse shows that majority of time is consumed by memory allocation, dynamic casting and other calculation non-related stuff. I would like to inspect many techniques (like perf profiling, GCC LTO, GCC profile-guided optimization, code refactoring, OpenTuner, etc.) which may bring really significant performance gain. Moreover, it would be really beneficial to come up with a cookbook that can be used by folk in general. If possible, I would like to create a step-by-step performance improvement graphs.

Project Description

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

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.

For debugging purposes one often times needs to know the communication partner on a socket or pipe a program has open. This information is not

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.

Finish Qt 5 port of vym and port to as many operating systems as possible. During Hackweek I managed to get vym to run on

Learn QT and make something to try it.

Yast team has a great experience in automating tasks that can be done by machines in order to save time that can be used better. We usually use Jenkins for running these jobs.

Why to use automation?

Continue development of generic job server in haskell with primary focus on continuous integration and later possibly as support tool for data analysis in semantic file storage server, software configuration engine, etc Project hosted at https://github.com/yaccz/yac-build-server

We have some internal systems for videoconferencing like Big Blue Button or OpenMeetings. But in my experience none of them can compare to Google Hangouts, which is still the best free (as in free beer) alternative for videoconferencing with integrated screen sharing. While implementing an alternative to Sqwiggle on previous hackweek, I discovered Janus, a lightweight WebRTC gateway that proved to be a quite capable tool to implement video applications.

As a part of this hackweek, I'd like to take a look at Clojure and use it to solve as many problems as possible from the project euler.

During the last CSM workshop we identified the need to have a good way to share the images we use for testing. We have documented the requirements and the current status in this wiki page (we even have a diagram). So analysis is done... it's time for action. The solution should be relatively easy to implement using our portfolio of solutions. Coordinating all the potential users should be easier during Hackweek, specially since I'll be in Nuremberg (and I can physically chase most people ;-) ).

We are right now testing a patch to Janus that will hopefully give us the stability we were missing in http://jangouts.suse.de. As a consequence, it's reasonable to expect a wider usage of Jangouts inside the company. Thus, I want to share maintainership of Jangouts as much as possible. The more developers know how to fix errors and implement features, the better. We already have a roadmap for the next two versions (0.4.0 and 0.5.0) but I don't want to spend my whole hackweek implementing those features in isolation. I would rather follow a workshop approach to welcome new contributors within the company (or outside, of course), so we get the stuff done and fix the single point of failure for the same price.

The Idea

Since some time I am interested in getting better at C++ and learn more about Qt framework. Since I learn best with having a project/goal I came up with this:

My hobby project is about using Lego mindstorms to turn a lathe / turning machine into a CNC. One missing piece is the "CAM" part that takes a 3D model and produces gcode that determines the tool-path.

Packman reduction

As we know, we have ABC notation or GNU Lilypond for music staff. It takes ASCII as input and generates music scores and even MIDI format, which is very convenient for people to type music in computer.

This is the tool I've been working on since HW11 and it needs more work. Actually, there's always something which could be done on it. It is basically an x86 instruction decoder with special emphasis on the kernel and decoding interesting pieces of it in order to help in the development of low-level patching techniques, among others. git repo: https://gitlab.suse.de/bp/x86d

"Let’s Encrypt is a new Certificate Authority: It’s free, automated, and open."[1]

I'm trying to write a static analyzer for Lua programming language. And I've ready done some parts, say, lexer/parser/AST/types...etc. The challenge part at present, is to write comment-based type annotation, for later type-inference. I plan to implement it in a week. I've spent years on this area. Hope I'm lucky in hackweek.

Writing code is wonderful, but it gets its real value, when it's released and shipped to the world. You know the mantra: "Release early, release often". Releasing code is not hard, but it involves a lot of details, and you want to get them right, because a release is this public statement "Hey, it's done, it works, you can use it." and you can't take a release back, once it's out there. To help with releases there are tons of release scripts which try to automate things. But they usually are quite fragile in case something goes wrong and a pain to test and maintain.

With rust 1.9 released, it should be possible to from now on bootstrap rustc from the previous version of rustc (so 1.10 can be built using 1.9 etc.). This means that it should now be possible to create a rustc package which no longer needs binary snapshots to build, meaning that we might even be able to submit rustc for inclusion in openSUSE Tumbleweed. This is the first goal.

As DBus a main component in Linux user space, in this hackweek I plan to learn more about it. Tentative Plan: a node js binding for sd-bus interface offered by systemd (available in SLE12)

YaST code organization is a mess at many levels (files location, namespaces, code dependencies...). Recently we created this gist to put some of the issues on the table Many YaST developers will be at openSUSE Conference, that overlaps with Hackweek. The plan is to lock them all in a room with a blackboard and reach agreements on how the code should be organized in the future. Then use Hackweek to iron the details, document everything in some kind of style guide and, if time permits, even do some experiments about how to adapt the existing code to the new conventions.

To make OpenQA work with real ARM devices, we need to control * Reset

"GNU Hyperbole is an open, efficient, programmable information management and hypertext system for GNU Emacs." (<https://www.gnu.org/software/hyperbole/&gt;) I used it quite some years ago. The last weeks it was a topic on the Emacs mailing list.

Every packager encounters boring manual tasks every once in a while and these tasks can most probably be automated to some extent. During Hackweek I aim to try and identify such cases in various packagers' workflow and consider creating a tool that would make these tasks easier. Also, I would like to find out whether there is a demand for such tool. In that case, this Hackweek project will turn into a long-term task I plan to keep working on.

Flatpak (previously known as xdg-app) is a bundle system, based on ostree, to easily make available applications bundle to users. Currently, flatpack is available on openSUSE Tumbleweed but we don't ship any runtime based on openSUSE (freedesktop or GNOME runtime). Also, it could be interesting to generate flatpak bundle directly from OBS, if possible, using either available packages or directly application sourcecode.

Elixir is a Ruby-ish dialect of Erlang with meta-programming capabilities, this is my first project using it: pedro . The idea is to create a task manager that would organize tasks (jobs) and manage them in projects. It will be running locally, remotely or both in multi-node setup, will provide CLI, have web UI relying on http and websockets. It makes use of erlang OTP, web framework phoenix that is inspired by rails. Author of elixir and main contributor to phoenix is Jose Valim, he's also the author of devise rubygem and former contributor to rails.

There are several popular ways of controlling home automation with voice today. Amazon Echo and Google Home both allow users to control lights, speakers, etc. with a simple voice command. For this project, I want to replicate some of the simple voice commands supported by projects like those, but in a way that does all processing from within the local network, and doesn't upload any voice clips to a server outside the home. There's something that feels a little uncomfortable about Amazon or Google having the ability to listen in on all conversations, so I'm trying to eliminate that while still being able to turn my lights on or off by voice.

ESP8266 Tinkering

The ESP8266 is an interesting little device that has been around for a while. It has the potential to support some interesting IoT applications. There is Ardunio core support for this device <https://github.com/esp8266/Arduino> and a rich set of libraries to help developers get started.

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

The plan is to gather ideas about how SUSE can become a more integral part of the local tech community scene (in PRG, NUE, or other locations). As a person who has been involved in educating women about tech for some time, I am thinking of introductory workshops and meetups, aimed not necessarily only at female audience.

Currently we use openQA for the the YaST integration tests. It runs YaST in a VM and controls it via emulating keyboard input. The result is checked by comparing the screenshots. This approach has several disadvantages:

In general plan for YaST is to use ruby only in future. So goal of this project is to move it forward and replace more parts with ruby. Current ideas is to replace binary y2base with ruby script, which allows easier integration with ruby tools and more important it solve some issues with embedding ruby, as it will be then first citizen.

Since there is no real documentation about openQA's lib/ functions I wanted to kill two birds with one stone and write a parser in perl that extracts all function names (and maybe preceding comments) in said directory and improve my perl knowledge by doing this. Possible additions:

An introduction from minetest website: " Minetest is a near-infinite-world block sandbox game and a game engine, inspired by InfiniMiner, Minecraft, and the like. Minetest is available natively for Windows, OS X, GNU/Linux, Android, and FreeBSD. It is Free/Libre and Open Source Software, released under the LGPL 2.1 or later. " In short, MineTest is a Free and Open Source re-implementation of MineCraft, but it provide many flexible features compare MineCraft. It's not only a game but also a framework for developers to extend so to make their own worlds.

I've attempted this several times already and each attempt had different shortcomings. I'm kind of curious about how exactly will I fail this time. And it looks like I haven't failed this time.

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.

The plan is to start working towards a rewrite of xdg-utils in python, focusing on the really bad bits such as dealing with desktop files and mime handling. In this hackweek, I want to split python-xdg into multiple libraries such as python-mime and python-desktop file and prepare them to be used in helper binaries to handle some of the more complex tasks currently done in shell.

The Gameshell is a small game console based on AllWinner R16 (Cortex-A7, IIRC the same CPU that the RPi2). Currently is supporting Debian, and some community member ported ArchLinux on it. The goal of the project is to port the openSUSE MicroOS distribution into the device, providing a transactional upgrade process for a canonical IoT architecture. In the process I expect to learn about ARM7, uBoot and some kernel hacking.

transactional-update, the application to update read-only systems such as openSUSE MicroOS and openSUSE Kubic and the Transactional Server installations of openSUSE Leap, openSUSE Tumbleweed and SUSE Linux Enterprise Server, evolved from a POC to a fully fledged solution - and is currently completely written in Bash. This has been working really well in the past, but is gradually reaching its limits, especially when thinking about supporting additional file systems or ports to other Linux distributions - yes, we have a huge interest in other distributions adopting our technology. A C++ version would simplify those abstractions, but would it also make maintenance of the complete application easier? Check that as part of a POC and refresh C++ knowledge on the way there.

This is an extra project for Hack Week evenings because there is never enough chameleons. Never.

Project Description

Project Description

The ultimate goal is to create agama live image that is really small iso and with minimal memory requirements. It provides just agama CLI and remote connection to web server. So no embedded browser.

Initially, the Agama D-Bus service was written 100% in Ruby. For many things, it relies on YaST, so it makes sense to use the same language. It was great to have something working quickly, but it also had some drawbacks. The main problem is that, as YaST is not thread-safe, we separated the service into different processes (storage, software, localization, etc.). The system became most responsive but at the cost of eating a lot of RAM.

Moving to Rust