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

Problem description

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.

Investigate possibilities for the distributed builds for Ceph to speed up builds.

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.

Debian

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.

GitLab provides a bridge to connect to Gitter using an IRC client.

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.