Once again, the SUSE band is coming together to make music and we're planning a party this time round!!! We have a band name :-)

New Development In previous hack weeks, the first few days ended up being wasted on just getting it working. I'm pleased to share that the code quality has improved dramatically since the last hack week and there are now extensive test cases for both unit testing and testing against real vmcores, and we'll use both mypy and pylint (if installed) to perform static analysis. Packages for those are available in openSUSE or as part of the crash-python OBS repo for SLE15. It has been tested with kernels from 3.0 to 5.1.

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

Packman reduction

Dochazka is a long-term project to replace the obsolete Attendance & Time Tracking system used by the Prague office since 2007. Dochazka is a complex system consisting of three major components: - RESTful backend App::Dochazka::REST (with lots of help from Web::MREST)

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

Working remotely has many advantages, but you sometimes lack some infrastructure. Specially if you use several computers or you share space with other SUSE co-workers. We are 3 Susers in Gran Canaria and we plan to share an office. So we have bought a Cubietruck, a tiny device with minimum power consumption, an ARM processor, a SATA interface and a Gigabit ethernet. The plan is to come-up with a set of recipes to configure such device to:

Read in a crash or oops-style backtrace and access DWARF information to output the current content of the stack and registers in term of symbols, and the the crash commands to dump/pretty print them. In other words, when looking at a crash dump, answer the questions "Which variable is currently stored in $rax? What is the structure of the stack? Which variable is stored at $rsp+16?"

Status at the end of hackweek 10

using perl's Inline::Python module, it should be possible to define openQA test modules in python instead of perl.

At SUSE LabsConf 2015 we decided to run some sort of automated tests on the SLE and openSUSE kernels after each push to kerncvs.suse.de In order to make this work the kernel has to be build, a initrd and a rootfs image has to be generated for use with qemu, it has to be booted and tests have to be run.

PXEAT (stand for PXE Administration Tool) is a tool to easily deploy and manage PXE service. It's NOT a tool for automatic deployment. It can enable user to add their own PXE items by themselves, but of course, very limited for security reasons. The tool will be developed with the light-weight framework - flask, as well as a sqlite database.

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.

Description

It can boot up from udisk/floppy.

Python is well known all over the world and has wide range of usage. Lets dive into to a bit.

The goal of openQA is "test as a QA engineer". But openQA has no ears - all we can test for are DTMF sounds. And even those are very bad. So my hackweek project is to do research on how to do proper sound verification. The keys are proper normalization of the volume and the sample rate.

Tronsmart has a Rockchip rk3368 based set-top-box [1]. I want to use it as a arm64 based workstation running openSUSE.

In openSUSE Asia summit 2015, there was a talk about the software defined networking, from the virtual switch, the controller, to the simulator. Just want to take a look at open vswitch and Ryu to learn more about SDN.

By analysing a VNC session, we can create a draft of an openQA testcase (detecting keystroke, mouse click and generating fullscreen needles). The project is to :

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.

As every hackweek, lets package/update/cleanup some stuff fore factory: Update/package:

While in the past MIPS boards were either low-end PIC32 or found in routers running OpenWRT at most, Imagination themselves have recently released the Creator CI20 board (Ingenic, MIPS32) running Debian. And the Shield Pro (previously iGuardian) kickstarter project (Octeon-III, MIPS64) promises to become a playground for testing KVM hardware virtualization. Porting openSUSE to MIPS will involve setting up an OBS instance linked to Factory (update: done) and cross-compiling a set of packages for an initial bootstrap (update: in progress). Maybe this can be scripted to some degree, as there will be some overlap with the ARM ILP32 port project.