openQA has a well earned reputation as a 'full system' testing tool, able to test a system end-to-end from the operating system to it's applications on a number of different platforms and architectures, including VM's & Bare Metal.
But one area of weakness is it's usefulness as a testing tool for developers or packagers. openQA can easily test a package once it's INSIDE a distribution, but how do you test that package BEFORE submitting it to the distribution?
Updated
over 2 years
ago.
13 hacker ♥️.
1 follower.
For quite some time I am providing a ResourceSpace container on Docker Hub. It is meanwhile pulled about 234K times but unfortunately still based on Ubuntu. Meanwhile I have updated the base to Ubuntu 20.04, but I would like to move it to openSUSE instead. With ResourceSpace 9.5 coming out soon I see a possibility of introducing this switch. Enno Gotthold also did a great job of packaging ResourceSpace on OBS, so this could be used as a starting point for the container.
It's not always straightforward to open a core dump originating from customer's environment, since there's a wide variety of versions of all the binaries involved - usual workflow is to install a VM with the SP that the customer is using, enable debuginfo repositories and then follow the buildid hints that gdb is providing.
However this sounds like a bit of an overkill. Lately, there has been a debuginfod project announced:
Updated
almost 2 years
ago.
2 hacker ♥️.
3 followers.
I have been known to talk anybodyI held presentations withinto using odpdown.
That was always a little awkward, since it started off with pip install odpdown, rather than zypper install odpdown. I want to fix this awkwardness and package odpdown properly so it can be installed as a RPM package. I'll also include the auxiliary infrastructure I've added around it over the years (various Makefiles and scripts for generating transcripts from comments) to the package so others can benefit from that stuff, too.
I run openSUSE TW and FF with i7-5600U Intel CPU. Calls with ~4 (video) participants work but my CPU load is approaching number of cores. In slightly bigger calls (>=6 participants) the CPU load was insufficient and audio packets were being dropped. I'd like learn more about webrtc video streams in order to reduce the client's CPU work or make it more adaptive when running with limited resources.
openQA Package Testing
Dangerous voyage in openSUSE Infrastructure sea.
Migrate suntorytimed/resourcespace container to an openSUSE base
Get the new SUSE Floor ready to use!
Without data this is just an opinion (SCC Analytics)
Investigate debuginfod & cores from SLES
Package odpdown
document/blog commit -> container workflow
