rtcqs released

rtcqs v0.3.1 is now available on Codeberg and Github. rtcqs is the continuation of the realtimeconfigquickscan project but then rewritten in Python. It comes with a Qt GUI and a few extra checks.

Dear all,

I’d like to announce rtcqs, the continuation of the realtimeconfigquickscan project. It’s a port to Python with some added extra’s, like a Spectre/Meltdown mitigations check and a Qt GUI. It has the approval of the original author of realtimeconfigquickscan to whom I owe a debt of gratitude, not only for the original code but also for his helpfulness with the continuation, or maybe even evolution of the project.

So check it out, indulge me with bugs, issues, improvements or any other useful feedback on the Codeberg repo which you can find at at https://codeberg.org/rtcqs/rtcqs

Happy system tuning and happy holidays!


While setting up a solution to fully automate the deployment of SSL certificates at work I piggybacked on the flow and focus to rewrite the realtimeconfigquickscan Perl code in Python. As part of the certificate deployment project I wrote an application to decrypt, re-encrypt and base64 encode PFX files so they can be uploaded to a vault solution. This way I ran into PySimpleGUI which enabled me to quickly put together a nice looking Qt GUI.

rtcqs main window

The code could be more terse and probably contains some typical non-programmer idiosyncracies. First improvement will be to make the code more dynamic so the GUI gets generated instead of using hardcoded values like it does now. And I’d like to add a power management check but then I first need to read up on that subject. There are also some checks that might need some more scrutiny like the swappiness and max_user_watches checks to verify if those checks are really needed for a real-time audio environment.

rtcqs released

Packaging Python Stuff

While packaging Tuna I ran into an issue for which I couldn’t easily find a workaround on the ubiquitous search engine. Tuna depends on some unavailable Python applications so those had to be packaged too. After having successfully tested the packages locally with pbuilder I uploaded them to Launchpad and noticed that they failed to build. Apparently the Python installer setup.py wants to install in /usr/lib/python2.7/site-packages and while that worked fine locally with pbuilder, Launchpad had an issue with that:

Found files in /usr/lib/python2.7/site-packages (must be in dist-packages for python2.7).
dh_builddeb.pkgbinarymangler: dpkg-deb --build debian/python-schedutils .. returned exit code 1
make: *** [binary-arch] Error 1
dpkg-buildpackage: error: /usr/bin/fakeroot debian/rules binary-arch gave error exit status 2

Apparently the files had to be installed in /usr/lib/python2.7/dist-packages but how to instruct the installer to do so without having to resort to ugly hacks? As I couldn’t find any useful answers on the web I asked falkTX on #kxstudio. He said the setup.py installer has a flag to install to dist-packages instead of site-packages, --install-layout deb. So I added that to the debian/rules file and gave it another spin:

#!/usr/bin/make -f
# -*- makefile -*-
# Sample debian/rules that uses debhelper.
# This file was originally written by Joey Hess and Craig Small.
# As a special exception, when this file is copied by dh-make into a
# dh-make output file, you may use that output file without restriction.
# This special exception was added by Craig Small in version 0.37 of dh-make.

# Uncomment this to turn on verbose mode.
#export DH_VERBOSE=1

        dh $@

        python setup.py build

        python setup.py install --skip-build --prefix /usr --root $(CURDIR) --install-layout deb

Now both pbuilder and Launchpad built the package without any issues.

Packaging Python Stuff