Using the camsource and vlc packages as an example. If camsource is configured to use a given dev/video[n] device with a choice of resolution in the width and height fields of a camsource conf file then if camsource is the first application to access the device captured images are as-expected. However, if an application like vlc is used for the same device (and exited) before starting camsource (e.g. to check the view from the camera before starting camsource) and if the camera supports higher resolutions than used in the camsource configuration what occurs is that camsource will not setup the camera to use the configured resolution and has a broken view of the camera output based on the vlc chosen resolution chopped to the camsource configuration. For example, with camsource configuration set to use 640x480 on a camera that supports 720x480 and vlc is used and exited before camsource is started then the captured camsource images contain two non-continuous partial image blocks with a horizontal border dividing them. I assume either vlc fails to fully reset the device configuration when exiting or camsource fails to initialize the device "from scratch" when starting. The two applications use different video device APIs but the setup and cleanup for the camera in each case is a very limited part of the application's functionality.

• implement a POC deploying CaaSP v4 on top of AWS using: Spotinst's elastigroup
• "Spotinst Elastigroup predicts Spot Instances behavior, capacity trends, pricing, and interruptions rate. Whenever there’s a risk of interruption, Elastigroup acts accordingly to balance capacity up to 15 minutes ahead of time, ensuring application availability.

Problem description Jira is used inside SUSE to track various process/workflows.

Why is it nice?

Diagnosing issues with stalling desktop application (or a whole desktop environment) is difficult these days as the application often requires multiple processes interconnected with sockets, pipes, futexes, etc. to work and often it is not clear which process is the one responsible for blocking the whole ecosystem. The idea of this project is to write a tool that gathers information about processes in the system and for each process that is sleeping display the resource (file, socket, futex) it is waiting on as well as the process that is likely responsible for unblocking (feeding pipe, sending data to socket, unlock futex, ...). Once the information is gathered, we can also plot it for graphical displaying with tools like graphviz.

Solid Ground is an essential software tool for the daily tasks of an L3 agent. A continuous integration/continuous delivery (CI/CD), and even more a continuous deployment, approach is currently missing from its development ecosystem slowing down its release cycles. Current project aspires to sketch the design principles of such approach and if possible to end up with a functional CI/CD mechanism that will be utilized in the next software releases of Solid Ground.

Investigate possibilities for the distributed builds for Ceph to speed up builds. This task could have 2 scopes.

Many cases are Client-Server testing or Multi-Machine testing in FIPS area, I plan to hack and learn more deeply about Multi-Machine test automation in openQA. Refer to:

Debian

• https://wiki.debian.org/Apache

I tried to work blockchain into this, just so we could cover the trifecta of buzz words. Sadly I could not maintain saintly and do this. What do I plan on doing? a few things, so please reach out if you would be interested in any one of them. I will update with a list later.

GitLab provides a bridge to connect to Gitter using an IRC client. The source code is at https://gitlab.com/gitlab-org/gitter/irc-bridge/

Create a tool which will make it possible to monitor the lifecycle of pods in a kubernetes cluster (as well as other types of tabular or structured data), and provide a convenient user interface for viewing and interpreting that data. This will be useful in development and testing of our kubernetes-based container platform (Cloud Application Platform), as it will allow us to better understand where things are going wrong when we encounter component failures. * Github

Have a play with SUSE CAP on AWS during this hackweek.

The plan is to start working towards a rewrite of xdg-utils in python, focusing on the really bad bits such as dealing with desktop files and mime handling. In this hackweek, I want to split python-xdg into multiple libraries such as python-mime and python-desktop file and prepare them to be used in helper binaries to handle some of the more complex tasks currently done in shell.

DevOps teams face double sided challenges: development tasks should be planable and maintenance tasks should maintain their flow to provide maximum value through the queue. Build a prototype JIRA project to help them organize their workload with a Scrum board for their development tasks and a Kanban board for their maintenance work, all fed from a common backlog.

SUSE CaaS Platform is a Cloud-Native Computing Foundation (CNCF) certified Kubernetes distribution. - Family with SUSE CaaS Platform

I recently bought a Lioncast LK200 RGB keyboard which is a nice piece of hardware and has exactly the look and feel I want. All basic functions work well under Linux. Unfortunately the manufacturer only provides user software to upload/download profiles and control the LEDs for Windows. The device can be configured and operates autonomously from any OS but color setup is a PITA and it's very easy to factory-reset, and lose all config. I approached them but Lioncast seems neither interested to support native Linux nor to provide protocol specs so one can implement it. I thought to take this as an example to learn about reading and reverse-engineering USB device software.

Finglonger is an internal tool used by the SUSE Manager team intended to make the life of the Round Robin Bug Guy easier. It was originally written by @fkobzik in Clojure. This is an attempt to learn some Go by reimplementing Finglonger.

****The motivation is create a open source solution, base on this business astronomy products: AZWO Asiair

Very often people find themselves wanting to store secrets in a way that either they can recover even if (for instance) their house burns down, or allow friends and family to recover if they pass away. Existing solutions to this problem are: * Too complicated to use for ordinary people.

https://gitlab.suse.de/l3ms/RES-weather/ needs some improvements, e.g. manual generation of statistics and reports.

At present it is our practice to "vendor" all dependencies for a Golang package. This has the advantage that everything is in one nice package and self contained but it has the disadvantage that dependencies are hidden and therefore security issues may slip through the cracks. The idea is to investigate and create automation "go2rpm" that generates a spec file with the necessary "BuildRequires:" such that the dependencies can be broken into golang- packages and we get rid of the implicit dependency inclusion via "vendor". The potential problem is scale, with some golang applications having thousands of dependencies.

Recently, ConnMan got support for iwd and WireGuard. The current support is only a starting point and it needs some more changes in the core code base to support the cool features:

I would like to learn and play with RL/ML and Go ( gorgonia for example). The lack of Reinforcement Learning library in Golang makes me very sad, so I wanted to implement a RL algorithm and alongside create a small library for RL and go in general. On the other hand, I would like also to expand and add features on a project that I'm working on: https://github.com/mudler/luet . It's a package manager based on containers, focused on cloud/OTA-alike update delivery. It would be nice to combine the two ideas, for e.g. to achieve one feature.

There are a number of items related to doing Virtualization CI and testing which I have a hard time getting to during my day job. I'll take Hackweek as an opportunity to get at least a little out of my normal space and improve our methods. This mainly focuses on QEMU/KVM and some of the efforts and infrastructure I've already got in various states of development, or at least investigation. Part of this effort is to try to leverage what is available in this space upstream, and to focus on watching the state of CI as it exists upstream, not just in our shipping products.