This project is about advancing the tool you're currently browsing. It got started back in Hack Week 9 to retire all the weird tools we've used in the past to track ideas. As you can see it has gone far but is still far from done. There are lots of features missing and bugs to be fixed on github. Get going!

I need to finish my work from the last hackweek * github repo

Implement better UI for Weblate using Twitter Bootstrap library.

Twopence is (will be) a remote execution engine for tests, able to run tests in virtual machines and real hardware through various means of communication : virtio for KVM / QEmu, ssh on top of libssh, serial lines. This library can be called from shell and ruby wrappers. While it is already functional (and used), it still needs polishing, stabilizing, and extending. It is also planned to integrate it with Pennyworth (project Machinery) and let it go fully Open Source.

I would like to change the way "quilt setup" is implemented. At the moment, we call rpmbuild and intercept the calls to tar and patch in order to record the location where archives are extracted and the order and options of the patches which apply to them. Then we replay that record to create our own quilt-compatible source tree.

There are more and more devices with no Adobe Flash plugin support in web browser (new Android and Apple phones and tables, etc.). The aim of this project is to replace Flash testdrive in SUSE Studio with HTML5 client. So our current implementation bases on our project from a previous Cloud workshop which uses noVNC.

Improve some OpenStack projects and contribute patches to them. I plan to look at improving manila (https://wiki.openstack.org/manila) and OpenStack infrastructure in general.

Sometimes a user might want to build her own kernel instead of using the provided binary, for various reasons. This means creating own .config and maintaining it through kernel version bumps, which often results in running "make oldconfig" and mostly holding down the enter button to accept upstream defaults. What I envision instead is a way to say where I want my own config to deviate from the distro default (as provided by e.g. kernel-stable on openSUSE), and only those options will override the distro default configuration. This distro default configuration is always updated for new upstream releases, so there should be no need to (manually or automatically) accept new upstream defaults, thus less risk of producing a broken kernel, as e.g. any new kernel options will be configured in the distro kernel so that they work with the distro itself (while upstream defaults might not be safe or desired).

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.

OpenSUSE support for OpenStack Training Labs

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

Figure out how to get SUSE VPN running on Android.

In GCC we have multiple intermediate languages and for all of them we do manual pattern matching and replacement. The project uses a domain specific language to unify and simplify those pattern matching and replacing code. During hackweek I plan to split out working parts to merge to GCC trunk.

I want to modify the driver so that it:

• a) supports newer hardware

I like to try out if it is possible to write a program that does not have any kind of the traditionally separated documentation (like external files that contain the documentation texts or comments in the program code). Instead all documentation must be implemented as code at the same place where the matching functiomnality is implemented (i.e. each function implements also its documentation). In the end the user should get only the executable that he can run to let it do the intended functionality and also to provide any kind of documentation. What I do not want is a dumb '--help' option that lets the program spit out its built-in documentation. What I would like to have is that the user can run the executable in some kind of self-inspecting way. I mean: While it does the intended functionality, it can also provide documentation so that the user can explore the program while running it. In the end the user experience should be more like a text adventure ;-)

The idea is to play around with a minecraft-like block exploration game, written from scratch in C using SDL2 and OpenGL 3.0. Minimal dependencies, probably won't be a game as such before the end of the week, but the goal is to have a world generated and to be able to walk around in it. Why? Mainly to refresh my 3D knowledge, catch up with what's happened since I last played with that stuff, and to have fun. :) * Source code

1) Add support for the Microsoft Azure File Service REST protocol to Elastocloud, a cloud storage client library created in a previous Hackweek. 2) After completing (1), create an Elastocloud VFS module for Samba that intercepts filesystem IO and locking operations. This would allow for the creation of a globally accessible Samba share backed by cloud storage, which could also be accessed by VMs deployed in the Azure cloud.

Description

Travis provides nice integration with GitHub, it can automatically run tests for every commit or every pull request.

The UEFI image for QEMU/AArch64 is available in the openSUSE build service now. However, there is no openSUSE image for that setup. This project is to make openSUSE run on QEMU/AArch64 + UEFI and this may be useful for the openQA in the future.

Seems that there is currently no good way to check which python modules are outdated in devel:languages:python . AFAIU http://osc-collab.opensuse.org could learn howto handle information from pypi and set the attributes "UpstreamVersion" and "UpstreamTarballURL" for the packages.

Look at the NIS RPC protocol, enable IPv6 where possible, document where not. Try to find out what Solaris is doing.

Currently python2 and python3 packages are completely independent. Would be imho good to build py2 and py3 versions from a single source (as Fedora, Debian & Ubuntu do already). There was already a mailing list post about this: http://lists.opensuse.org/opensuse-packaging/2014-09/msg00000.html

Use my work supplied workstation to set up SUSE Cloud under KVM and deploy several instances of servers.

• czech translation
• [ ] turn antialiasing off -> [x] font antialiasing

AngularJS, Websockets, REST APIs for mobile apps, one-time links for emails — what’s the topmost complexity all those things share in common? It’s authentication. Authentication typically means sessions, and sessions are simply ubiquitous state for our stateless-by-design web.