The title of this project is inspired from the must-see video John Hughes - Testing the Hard Stuff and Staying Sane

The afl fuzzer is an interesting tool that uses compile time instrumentation and genetic algorithms to automatically produce test cases that will trigger different code paths in binary... http://lcamtuf.coredump.cx/afl/

git rebase is a very useful construct in source control management, as it allows you to re-apply your changes atop a different branch of the same repository. While this concept transitions perfectly to container management (updating a container could be as easy as a docker rebase), and the Docker client is inspired by the git semantics, Docker has no such feature (in fact, Solomon Hykes used rebase and merge as examples of things "that we don't want"). Currently, zypper-docker works by applying an updated layer on top of an existing image. While this does work quite well, it separates the process of updating the base image and updating all of your derivative images (you need to re-download new packages for each derivative image). So, this project will be working on implementing something like git rebase for Docker images. There are several issues with this, mainly involving the fact that we are rebasing binaries and not source code, so merge conflicts will probably be quite messy. But it should be possible to implement some form of simple rebase method (which will essentially fall back to docker build in the worst case, which is what you were going to run anyway). By maximising the reuse of the existing image layers, it should be possible to reduce build times quite significantly.

As detailed previously on devel and opensuse-factory the KDE team didn't have access to their bugs and could not actively subscribe. This is changed now by introduction of opensuse-kde-bugs@opensuse.org mailinglist.

We currently have a set of shell scripts that verify if patches can be properly installed on multiple combinations of base products, extensions and modules. These scripts are all written in shell and are annoying to maintain, as configuration and code is all mixed up. My objectives are: (a) to rewrite all the scripts in a single tool, in Python; (b) separate code and configuration, so that adding a new product/SP requires only editing a configuration file; and (c) make the checkers more flexible, allowing execution from the command line against specific repositories (use case: checking one single maintenance incident before submitting it to QAM).

The basic idea is is to boot the plain SUSE installation system (inst-sys) but to not let it run YaST. Instead inst-sys runs Relax-and-Recover (rear) as generic installer that does the system installation.

There were several attempts to integrate ABRT to openSUSE. In this Hack Week I'd like to: 1. review those attempts;

• learn how to code on golang
• create a script for docker testing (bash or python)

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?

It's a CTF like game, where the goal is to unlock "lock" devices. Having access to a disassembled code you have to create an input that will unlock the device by exploiting a bug in its code.

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.

Challenge

The salt-minion client-side agent is still a bit hefty due to its dependencies and SUSE's strange Python packaging. Let's see how to create a minimal salt-minion packaging.

I want to use this hackweek to get some practice with git and rst and maybe more specifically, as a project, to set a blog written in rst and hosted in github.

French government provides a pretty up-to-date data set with the gas prices in France as open data. These data could be useful in the offline GPS application [Osmand][1] for drivers to find the cheapest nearby place to buy they gas.

Let third parties to get notifications about build failures without having maintainer rights

The download end-point of Spacewalk/SUSE Manager resolves the packages from channels dynamically with a database query. With the integration of Salt into SUSE Manager we have the chance to rethink this.

Networkmanager uses some simple dbus interfaces of firewalld to allow configuring a firewall zone for connections. FWZS offers similar features on top of SuSEfirewall2. I'd like to adjust fwzsd to provide the minimal interfacess NM needs to offer the firewall integration.

Currently, dealing with forkbombs and similar issues with Docker and runC is not very nice (you have to set a global limit for all Docker processes or you have to limit kernel memory which isn't very practical). I'm going to work on getting some [patches][2] merged into runC and Docker to enable PIDs support for Docker.

the Taipei office lacks automatic printer discovery so everyone has to download and install some weird "driver". That's not the Linux way of doing things. So set up a cups server and do proper printer announcements with that one.

Goal

• Organize a general developer mentoring program

In the kernel repository, we have a script that checks users/* branches and does some basic checks on them. My plan is to teach this script to detect kabi changes.

Dovetails are nice to assemble wood pieces... but not that easy to do. The project is about creating a template to create dovetails with a router and of course create dovetails. I prepared all the maths before hackweek to plan my actions (and buy hardware). See this geogebra file for the details.

Create a wrapper which receives the URL passed to the "firefox" binary, offers a list of available profiles, and finally runs Firefox with the selected profile and the given URL. https://github.com/olafhering/firefox-profile-selector

OpenStack uses Zuul as a pipeline manager to test changes posted on gerrit. The rpm-packaging initiative (https://wiki.openstack.org/wiki/Rpm-packaging) needs to test proposed changes. So building packages with OBS for proposed changes is the goal of the project.

Fetch and display openQA status project group per project. Helpful when we have a combination like openSUSE:Factory and openSUSE:Factory:PowerPC

Hacking on OBS dashboard requires you to have a "real" data from staging projects. this is done by quering backend directly. So either you need to have a production db deployed or you have old broken data. Let's ask the real OBS for current staging status with external API.

So far CUDA driver for Tesla card is only available as Ubuntu deb. Try to find sources in it and create SLES12 rpm

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 ;)

Previous hackweeks spent on research (project/220), other alternatives. This time I'm

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.

terraform-provider-libvirt adds libvirt support to terraform. Thanks to other projects using it, there are several pull requests open. The goal is to include the features that are ready to be merged.

Salt seems like a technology that's spreading around and more and more people are using it so I thought I'd learn more about it. I plan to create or use existing VM's to monitor and manage them with salt in order to learn more about it.