French government provides a pretty [up-to-date data][0] set with the gas prices in France as open data. These data could be useful in the offline GPS application [Osmand][1] for drivers to find the cheapest nearby place to buy they gas.

terraform-provider-libvirt adds libvirt support to terraform.

Take time this week to take care of the packages I maintain at Debian; open bugs, fix bugs, new upstream versions, enable testsuites in autopkgtest.

Patches for supporting SGI Octanes are floating around since ages. The latest version is against v4.10. I've talked to Ralf Baechle (MIPS kernel maintainer) and he is willing to take patches from me... so I have to provide them... and this what this project is for:-)

Currently the upstream LTP is executed by a hacked up and old runltp script that executes even worse and fairly old mess called ltp-pan which in turn actually executes the test cases. This whole thing is a unmaintainable mess that should have been replaced with something simpler a long time ago. It should also have a few more features that has been requested in the meantime and not implemented since nobody wants to touch the code. For instance executing the test cases on a different machine via ssh and writing the results locally. Another feature I've been thinking about for quite some time is a parallel test execution, since most of the test cases in fact could be executed in parallel which could easily speed up the test run twice. There are other tests that cannot, mostly stress tests, but also test cases that modify global system state, i.e. system time, make use of sysv IPC, use loop devices, etc. These kind of tests should be annotated somehow so that we do not end up with a test cases competing for a global resources in a parallel test run.

Starting from prometheus ( and grafana if needed), learn how to monitor kubernetes and docker and do some valid alert/graph etc.

Description

motivation

Lots of crucial steps in the SUSE/openSUSE product build workflow are not known or not even accessible by many people but hidden as "custom scripts" on "some machine" in the worst cases. Nowadays infrastructure and build pipelines should be written as code, e.g. in git repos, with UI frontends to show the always current state of what is going on, what needs to be done to release products, where are problems. The least we can do is learn a bit more in this direction.

Currently helpers for maintenance of SLE/openSUSE such as osc omg exist just as git repo, lets have them as packages.

In day to day job I often wait for openQA job to change a state. I plan to create chrome plugin which would allow to watch for some certain job and will send you notification when run is end.

Explore the possibility to have a self sufficient frontend server running locally. This server would compile all the frontend code and act as a proxy/middleware pointing either for a dev ref-server or to a local SUMA instance. This way would be possible to do modifications in frontend even without having a SUMA server running locally.