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

The idea is about an easy way to allow users to make upgrades (e.g.: changing from one major version like 15.0 to version 15.1) using a GUI and as easy as they can in Ubuntu. Something like a notification with a button to perform the upgrade with just one-click, instead of having to deal with the terminal, that frights some new users and gives them the sensation of an outdated system.

Goal: I will look during this project for existing tools and test suites Upstream, used by others distros (like 1) Fedora, 2) Arch-Linux, 3) Debian), and try to learn how they test, use their tool, projects.

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.

Currently, the usual way to communicate with VM instances in the cloud from outside is ssh. This is okay for most uses, but a) does not work when you mess up with the guest's ability to network and b) requires a free floating IP. I wonder if, for qemu/kvm instances, it would be possible to use virtio-serial possibilities : from the guest, it is seen as a serial port, and from the outside, it is seen as a UNIX socket, or as something else. It is fast, as it does not go through virtualization and device drivers.

There is a running gag built into openQA called interactive mode. It goes like this: "if you need the interactive mode, it's broken". The reason: the so called interactive mode is a collection of hacks - in theory making it possible to update needles in a running test. But in fact it's a UI desaster that almost never works. So the goal of this hackweek project is to get rid of it - and instead build a real control from the webui into the backend allowing tests to be written on the fly including needle creation/updates. Easy as that.

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

Make a final attempt to implement a graphical user interface for grub2 (gfxboot2).

It's quite some work, unfortunately. Here's what's done so far:

To make OpenQA work with real ARM devices, we need to control * Reset

WEB_PAGES:

<https://slenkins.suse.de>

Last time I checked QEMU lacked support for >= z10 processors. Thus one cannot run SLE12 and newer in a virtual machine on non-s390x host. I'd like to improve the situation during Hackweeks.

Flatpak (previously known as xdg-app) is a bundle system, based on ostree, to easily make available applications bundle to users. Currently, flatpack is available on openSUSE Tumbleweed but we don't ship any runtime based on openSUSE (freedesktop or GNOME runtime). Also, it could be interesting to generate flatpak bundle directly from OBS, if possible, using either available packages or directly application sourcecode.

L3 bug reproduction often requires becoming the admin for a moment. I'd like to write down some nifty tricks I used to get certain “interesting” system configurations to work.

github https://github.com/okirch/susetest

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

Description

It can boot up from udisk/floppy.

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.

Every packager encounters boring manual tasks every once in a while and these tasks can most probably be automated to some extent. During Hackweek I aim to try and identify such cases in various packagers' workflow and consider creating a tool that would make these tasks easier. Also, I would like to find out whether there is a demand for such tool. In that case, this Hackweek project will turn into a long-term task I plan to keep working on.

Orcas are amazing animals. They are playful, intelligent, great swimmers, and very social. They also love to play with their food, hunting down their prey with advanced strategies - understanding where its prey hides, how it will try to escape, and how to overcome those tactics - and having a lot of fun doing so, before relentlessly tearing it apart, killing it, and eat it. Not necessarily in that order. Oh, and they have the right color scheme. This forces their prey to also improve and adapt more advanced strategies and tactics. In this arms race, both sides evolve and improve: the evolutionary pressure has made cephalopods highly intelligent, adaptable, and resilient. Unfortunately (for them), they are still very tasty. So we should exert more evolutionary pressure on individuals to help them stay alive as a species.

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

With rust 1.9 released, it should be possible to from now on bootstrap rustc from the previous version of rustc (so 1.10 can be built using 1.9 etc.). This means that it should now be possible to create a rustc package which no longer needs binary snapshots to build, meaning that we might even be able to submit rustc for inclusion in openSUSE Tumbleweed. This is the first goal.

Taskotop is a tool to check what taskomatic is currently doing on a SUSE Manager server: it's a command line python tool. The core of the tool is to get some info about jobs that taskomatic is running with a fixed time cycle running some queries and showing results to the shell.

Try to use Jenkins 2.0 CI environments to trigger jobs which running in openQA Topic 1:

https://github.com/viccuad/gomoduino Gomoduino

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

This is about writing a tool to find differences in assembly files generated by gcc. The goal is to find the symbols in a program that have changed by a source code patch. This information can then be used to create and/or verify kGraft patches.

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.

This is about porting the old KDE 3 based KDirstat to the latest Qt 5. KDirStat didn't use that much KDE infrastructure to begin with, and KDE seems to be more and more a moving target. Project repo and web site with more details:

Right now, every time a new team wants a new room in our Jangouts instance, they have to ping me and I have to manually create the room. That means: * Adding some lines to the corresponding config file

The current Jangouts UI is limiting us when thinking about adding new features. Some examples: * This (using the whole thumbnail to pin a participant) was implemented, but the result is far from optimal (I have not even deployed it in production).

The idea behind the project comes from recent work on integration of OpenDayLight with Suse OpenStack Cloud 6/7. The goal for this Hackweek project is to realize a demonstrable NFV use-case on Suse OpenStack Cloud with as much reduced manual orchestration as possible. The use-case to consider is to run a Service Function Chain(SFC) with basic Network functions like Firewall/QoS that run as services on JeOS Guests on SUSE OpenStack Cloud (SOC).

I've attempted this several times already and each attempt had different shortcomings. I'm kind of curious about how exactly will I fail this time. And it looks like I haven't failed this time.

• Build zookeeper, mesos-master and mesos-slave on SLE12
• Setup a 3-nodes high-availability cluster (zookepper + mesos-master + mesos-slave run on each node)

We all pant for customer data. Which hardware do customers run ? Which packages are installed ? Which services are running ? etc. pp. A lot of this data is in the supportconfig. But this is neither collected, nor centralized, not easily accessible.

<p> Supporttools are great and useful utilities to help support and development

Sometimes it is hard to promote our project at conferences and events. During this hackweek I'd like to prototype a papercraft for promoting Portus at the upcoming containercon.

Did you know that more that 60% of the food we produce it's thrown away? Why create pollution? Why spend out time to create something that in the end get wasted?

To make sure openSUSE can coexist nicely with an existing Windows installation, we need to have automated regression testing. UEFI and secure boot are especially interesting.That means installing Windows and openSUSE in parallel in openQA. Instead of just uploading some prepared hard disk image, openQA should ideally install Windows itself and save the generated image. In a second run openQA can then install the latest Leap or TW on that disk image.

Geeko's Hack Week Gazette - Nürnberg Edition Provide a daily news mail what is going on during Hack Week

There are a lot of issues in Crowbar due to the legacy of poor internals. This is blocking things quite a bit when it comes to improving Crowbar for adding new features. Let's fix it! So far, 39 pull requests opened!