Fresh air and motion helps your brain to come up with new and creative ideas. This hackweek project offers exactly this*. You can expect running exercises along the Nuremberg city wall. Running 25 to 50 meters sidewards, jumping, running stairs, etc. will give your brain new energy.

The SLE15 development model follows the Factory First policy, where all submissions need to go first to openSUSE:Factory and then to SLE15 repos. This way more bugs are fixed, less patches get lost, less backporting is happening etc. Our openSUSE infrastructure is using salt for configuration management. This was working fine, but suddenly we had to split the openSUSE from the SUSE-DMZ services into separate VLANs, thus the salt codebase had to be split as well. The code itself is mostly formulas and quite similar states between the two set of services though. The only real difference was in the pillars, and even there there was a lot of duplication.

While normally data is passed to linuxrc (including an AutoYaST profile), modern auto-install tools like Ignition from CoreOS support a very interesting method: the QEMU Firmware Config device. This allows to read from inside the VM a blob by reading /sys/firmware/qemu_fw_cfg/by_name/opt/keyname. The driver is included in recent Linux kernels.

• learn how to write Dracut modules
• investigate running Salt in Dracut initrd

DAPS, the "DocBook Authoring and Publishing Suite" provides a tool set for easy creation and publication of DocBook sources on Linux. DAPS lets you create HTML (incl. webhelp), PDF, EPUB, man pages, and other formats with a single command. DAPS is used and developed by the SUSE documentation team and hosted on https://opensuse.github.io/daps/ . Currently DAPS supports building documentation from DocBook 4 and 5 sources. The goal of this project is to add support for ASCIIDOC to DAPS. This will allow to easily create all output formats mentioned above with the official SUSE brand from ASCIIDOC without having to take care about templates and other stuff.

• Setup Tensorflow on OpenSUSE 42.3
• Look for a way to package it

Build a base image and template (both kiwi and Dockerfile) for openSUSE Leap 42.3 using the native OBS container building feature. Results/WIP will be available here:

media.ccc.de currently hosts about 5TB of presentation recordings. The main mirrors send about 5TB of videos each in a single month. Several OpenSource conferences are hosted on media, like the last two openSUSE conference, or the "All Systems Go!" conference. What started as a web frontend for ftp.ccc.de in 2007 has become a complex project that integrates deeply into the tooling used by the VOC team.

I have several themes in progress, they all need lots of work before they could be used with openSUSE. * The gtk people keep changing things so the gtk theme I use to match my enlightenment theme also needs fixing.

BPF Compiler Collection (BCC)

https://github.com/iovisor/bcc

This was planned for previous hackweek (hw16-1) => Automated deployment of virtualization hosts and build up of virtual machines for xen+kvm+related tool testing.

We need to package avocado, get it into distro and migrate some of our testsuites from ctcs2. Atm avocado is present in openSUSE:Factory and Backports exist at my home project

What is HRV ?

HRV is a method for measuring the ability of your heart to respond to inner and outer levels of stress.

Take some online classes for penetration testing tools and then practice using them. The goal is to learn enough to provide some value for pen testing of real products. Originally I was hoping to have a real cloud to pen test, but that appears unlikely so I plan to set up an Apache web server instead as the system under test. It won't matter much as the goal is to learn to use the tools.

OMEMO is the next generation of end-to-end encryption method for IM applications, which supersedes OTR. Compare to OTR, OMEMO provides many useful new features. Currently, the support for libpurple is still in development. I found two projects - lurch and libpurple-omemo-plugin. They are in early phase so it is probably not very stable and few features are missing.

A pocket operating system,can be burned in a usb stick. Not the live usb,you can save all your changes in this.

As in near future, there will be python2python3 in Factory but no /usr/bin/python and in SLE-15 base no python2 it is necessary to start checking/switching dependencies. See also:

L10N for the book entitled Designing with LibreOffice by Bruce Byfield

Quite a big part of openQA is testing the installation of SUSE products. All of them are installed by YaST. So a big quantity of problems found during openQA testruns are YaST problems. To find out what has gone wrong during installation YaST developers need to download the tarball containing the logs, unpack it and find the y2log among many other log files. That makes it quite complicated to just have a quick view on a problem.

A successor of - https://github.com/viccuad/salt-configs

While DDR4 memory has become quite popular, decode-dimms doesn't know about it and is not able to display any useful information for DDR4 memory modules. I would like decode-dimms to provide the same detailed information about DDR4 memory modules as it does for all older memory types.

The goal is to create a set of YAML files describing L3 supported products with all metadata we need to store there - and a JS presentation layer automatically showing this data in several forms, one of them will be a part of our L3 documentation. Technology: HandleBars.js or similar, plus some YAML technology

Deploy an openQA on my locally virtual machine and create 3 openQA test case for nautilus.

While it is important for package maintainers to track the upstream code base activities and backport significant patches in a timely manner, it could be a tedious work when there's hundreds of packages in a project (ahem, GNOME) to follow manually. So I wish to get mail notifications when new commits with certain keywords (e.g. SIG, {crash, hang}{s, ing, ed}, leak(age), CVE-, https://bugzilla.gnome.org/show_bug.cgi?id=*, etc, etc) come in.

CaaSP is designed to be used with containers based on SUSE micro OS, using Salt as the management tool. CaaSP2 GMC is available at the moment. I want to spend the hackweek 0x10 to play with it, figure out how CasSP integrate and work with Salt. My target is to understand the CasSP, like the advantage it take to k8s. How salt works in CasSP?

How to deploy container - Docker based on SUSE CaaS Platform.

Problem statement

Right now, we have different resources to pool videos. The goal of is to consolidate all video resources into a central place to make them easily searchable, and enable a youtube like experience, rather than a simple file list.

When doing the backport, I sometimes spend some time to check if the commit comes from a patch series and list all commits of a patch series. So I'd like to create a tool for doing this quickly.

YaST dumps quite information to its own log file (placed at /var/log/YaST2/y2log). That info is very useful to understand and discover what is happening when an issue appears. All YaST modules write into this log file, and the brand new yast2-storage-ng is not an exception. Some improvements are necessary regarding to the logging of this new module: * Libstorage-ng is the C++ library powering the rewrite of the YaST storage stack. For using libstorage-ng from yast2-storage-ng in a more Ruby-like way, we created a wrapper that provides several features like automatic downcasting. But the current downcasting mechanism used by the wrapper causes libstorage-ng to introduce a lot of noise in the YaST logs. It would be nice to reduce that noise.

SLE Engineering have a large flatscreen in the shared space just outside of Thorsten Kukuk and Stefan Behlert's office It runs Windows

The DriConf-Project inside of MESA has seen its latest update in 2006 and is implemented with GTK+ 2. https://dri.freedesktop.org/wiki/DriConf/

We got a couple of GSoC projects around Jangouts this year: - https://code-master5.github.io/Aug-22-2017

Problem statement

Once a kernel is built, a developer/janitor may want to boot the kernel for various reasons, such as performing simple boot test or running tests and workloads from user space or simply playing around in a shell. However, an easy to use and a descriptive tool to perform those tasks doesn't exist to our knowledge.

Look at this beauty: https://github.com/crowbar/crowbar-core/blob/master/crowbar_framework/app/models/service_object.rb#L941 Nice uh? Its a 500 lines methods that its distinctly separated into 4 different pieces internally that make 4 very distinct phases inside.

In our team, we currently manually deploy our Terraform code (namely, the SUSE Registry at registry.suse.com) from our own PCs. This is error prone, as it would be very easy to override something by mistake. I want to create the appropriate .gitlab-ci.yml file that will:

Once upon a time there was a bot

@mudler Created devbot that was helping the qa-tools party.