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!

Meet up NBG meeting room Paris with fellow Ruby on Rails hackers, throw an editor/shell onto the wall, grab a cup of coffee and refactor OSEM code together. That way we can share knowledge about setting up the development environment, editor tricks, RSpec patterns, gems or general rails code. Interested? Join us!

Our beloved competitor developed and use project-wide message bus called Fedora Infrastructure Message Bus. This project was already adapted, or is being adapted, also by Debian community. During Lucky Thirteen I want to get deeply familiar with the concept and implementation, deploy test scenario and write plugins for OBS and openQA to talk to each other.

motivation

jenkins is a great CI system (continuous integration) with a plethora of plugins available. SUSE QA uses openQA extensively as it excels in distribution and product testing - not only image comparison (common misconception ;-) ). How about combining both in using jenkins with plugins to act as a UI for openQA?

See README for description of the Dove-eye project (poor man's Hawk-Eye). The main goal is to make 2D object tracking from a single camera more stable, so that it's reliable for 3D localization.

We have various individual tools to automate parts of the Haskell packaging process, like cabal-rpm, but those tools aren't integrated into a fully automated system that keeps Haskell packages up-to-date with as little human intervention as possible. I would like to build that system. Stackage provides us with an accurate list of packages and versions that are known to work together well, and there are basically two flavors: the nightly snapshot (bleeding edge) and the LTS release (stable API). The former is appropriate for Tumbleweed, IMHO, and the latter is appropriate for stable releases like SLE or Leap. Now, we can use cabal-rpm to generate spec files automatically for all packages in a Stackage release and check them into OBS. The process does need some tweaking, however, because cabal-rpm generates spec files that don't always work well for SUSE. We could (a) branch cabal-rpm and add SUSE-specific know-how to remedy that issue or we could (b) maintain a set of patches that adapt the generated spec files to our needs. Once the Stackage releases are available in an OBS development project, we need another automated process that submits all updated packages to openSUSE:Factory, etc.

FATE#319830, FATE#319843 and FATE#319842 propose integration of AutoYaST with different software configuration management systems like Salt, Chef and Puppet.

kanku make's installation and testing of kiwi images built by OBS very easy. https://github.com/M0ses/kanku

kanku make's installation and testing of kiwi images built by OBS very easy. https://github.com/M0ses/kanku

It is not a about make a new software. It is a service in fact. Everyone working in Beijing Office struggles with the tortoise network speed when doing zypper.

Gordon

A collection of autotests for Crowbar

Quotes from xrdp wiki: https://github.com/neutrinolabs/xorgxrdp/wiki/Xorg-drivers-for-xrdp "At first, xrdp used Xvnc only for the X11 backend. Later X11rdp was used as the X11 backend as another option to Xvnc. X11rdp has definitely proved itself as a superior replacement for Xvnc. Xvnc is limited to the VNC drawing primitives. X11rdp was built for RDP.

In many cases, people want to start containers on a system where the administrator is not happy about granting privileges to users or installing any new software. For example, when I was a researcher and wanted to run Python 3 on a computing cluster it was not possible to get the administrator to install Docker or Python 3. In recent Linux kernels, it has been possible to create containers without any privileges. All that's missing is a container runtime that allows you to do this. LXC is close but falls short (it requires certain privileged processes and PAM modules for everything to work).

The kernel compile and link itself is only a fraction of the OBS kernel-default package build. Several other passes take significant time: - Post build checks, especially the clamav scan

All other distributions have scanmem/gameconqueror packages. scanmem is a command line memory scanner to locate variables in memory and GameConqueror is the Python/GTK3 front-end for it which also provides game trainer features. But it is not only a game cheating tool. It can also help testing applications, debugging memory issues, watching variables in memory or it can be used for reverse-engineering. Hackers also use it for things like ping spoofing. As the upstream maintainer of this tool I'd like to bring it to openSUSE and maintain it there.

The SUSE Manager team currently uses vagrantup.com to create developer environments (a project known as suminator). Doing the same with terraform.io and the terraform libvirt provider we could:

Look at bcache and start adding support in libstorage-ng. It should be possible to implement probing during hackweek.

The translation repo: https://github.com/beijinglug/fsfs-zh

In this HW I would trying learn about how to modeling aircraft in FlightGear, which is a free and open source flight simulator.

The goal of this project is to get a familiar with NativeScript, play with it and create one or two simple demo applications. Maybe even something useful ;)

The project is about taking a fresh look at Crowbar UI for SOC provisioning. Main goal is to mock user workflows that would allow to scale Crowbar to support multiple datacenters, a more flexible way to add large number of nodes and manipulate services, as well as control and customize various types of hardware groups. <i>Note: Bellow links and images might not work without VPN enabled</i>

py2pack is the prefered tool todo Python packaging for openSUSE. There are multiple issues. The one I want to focus on is the dependency detection which is tricky for Python packages.

Results

Submitted upstream.

Prepare the module and concept done for the CSM Workshop and prepare it for upstream inclusion. Upstream plans to add some hooks to make it possible to automatically snapshot different stages of state.apply.

Right now internal SLE development is still organised & structured around the concept of 'Milestones'. Schedules are defined, deadlines are set, and off we go making Alpha 1, 2, 3, Betas 1, 2, 3, RC's, and so on. Meanwhile, QA has evolved, and with openQA and other automated tooling we are increasingly testing SLE in a more agile, rolling model, testing every single build as soon as it's produced by OBS, and just paying extra attention to the Milestones with additional manual testing.