Since this will be my first real "from the start" publication the goal for me has more to do with the experience of publishing the projects, use of the public hosting site and access tools, particularly git.
The projects that will be published are:
Python based
Qt 6. based
One is a V4L2 device regular frame capture to jpeg file application (I use it ultimately to create daily timelapse videos of the vew from my home)
This application has a view on the main window that shows a simulation of the time-of-day using a graphical model (a sun passing through a ground/sky view with colors that are based on day time and a moon passing through a ground/sky view with colors that are based on night time)
One is a three part audio meter where the parts are all in the same UI window and are:
a) A live self-relative dB meter at a user chosen sample rate and update frequency
b) A moving day-view track of the minimum and maximum signal level
c) A moving day-view track of the audio frequency content via FFT
The current state of both projects is usable, almost fully functional, with the potential for some improvements (e.g. optimizing 5 to reduce it's runtime overhead, which is difficult for an app doing filtered, windowed and FFTed liveaudio sample data)
Both apps make decent example Python Qt6, a v4L2 client and audio capture applications
My interest in 3 is the creation of daily timelapse videos of the view from my home because in snow storms the videos look great but I wanted the frame capture automated and just left to run. My interest in 5 was a matter of exploring audio capture client interfaces with no real purpose, ergo two different signal level meters and an audio spectrum content meter were "things to do".
The audio meter application could be developed by anyone with access to monitor for problems at a location, which is one of the reasons for wanting to publish it for the benefit of others.
Both would be GPL3 licensed.
This project is part of:
Hack Week 23
Activity
Comments
Similar Projects
Symbol Relations by hli
Description
There are tools to build function call graphs based on parsing source code, for example, cscope
.
This project aims to achieve a similar goal by directly parsing the disasembly (i.e. objdump) of a compiled binary. The assembly code is what the CPU sees, therefore more "direct". This may be useful in certain scenarios, such as gdb/crash debugging.
Detailed description and Demos can be found in the README file:
Supports x86 for now (because my customers only use x86 machines), but support for other architectures can be added easily.
Tested with python3.6
Goals
Any comments are welcome.
Resources
https://github.com/lhb-cafe/SymbolRelations
symrellib.py: mplements the symbol relation graph and the disassembly parser
symrel_tracer*.py: implements tracing (-t option)
symrel.py: "cli parser"
Selenium with Python by xguo
Description
Try to create test case about Selenium base on Python
Goals
- Knowledge about Selenium with Python
- Create new test case about Selenium
Resources
https://selenium-python.readthedocs.io/ https://www.selenium.dev/
Small healthcheck tool for Longhorn by mbrookhuis
Project Description
We have often problems (e.g. pods not starting) that are related to PVCs not running, cluster (nodes) not all up or deployments not running or completely running. This all prevents administration activities. Having something that can regular be run to validate the status of the cluster would be helpful, and not as of today do a lot of manual tasks.
As addition (read enough time), we could add changing reservation, adding new disks, etc. --> This didn't made it. But the scripts can easily be adopted.
This tool would decrease troubleshooting time, giving admins rights to the rancher GUI and could be used in automation.
Goal for this Hackweek
At the end we should have a small python tool that is doing a (very) basic health check on nodes, deployments and PVCs. First attempt was to make it in golang, but that was taking to much time.
Overview
This tool will run a simple healthcheck on a kubernetes cluster. It will perform the following actions:
node check: This will check all nodes, and display the status and the k3s version. If the status of the nodes is not "Ready" (this should be only reported), the cluster will be reported as having problems
deployment check: This check will list all deployments, and display the number of expected replicas and the used replica. If there are unused replicas this will be displayed. The cluster will be reported as having problems.
pvc check: This check will list of all pvc's, and display the status and the robustness. If the robustness is not "Healthy", the cluster will be reported as having problems.
If there is a problem registered in the checks, there will be a warning that the cluster is not healthy and the program will exit with 1.
The script has 1 mandatory parameter and that is the kubeconf of the cluster or of a node off the cluster.
The code is writen for Python 3.11, but will also work on 3.6 (the default with SLES15.x). There is a venv present that will contain all needed packages. Also, the script can be run on the cluster itself or any other linux server.
Installation
To install this project, perform the following steps:
- Create the directory /opt/k8s-check
mkdir /opt/k8s-check
- Copy all the file to this directory and make the following changes:
chmod +x k8s-check.py
Enhance UV openQA helper script by mdonis
Description
A couple months ago an UV openQA helper script was created to help/automate the searching phase inside openQA for a given MU to test. The script searches inside all our openQA job groups (qam-sle) related with a given MU and generates an output suitable to add (copy & paste) inside the update log.
This is still a WIP and could use some enhancements.
Goals
- Move script from bash to python: this would be useful in case we want to include this into MTUI in the future. The script will be separate from MTUI for now. The idea is to have this as a CLI tool using the click library or something similar.
- Add option to look for jobs in other sections inside aggregated updates: right now, when looking for regression tests under aggregated updates for a given MU, the script only looks inside the Core MU job group. This is where most of the regression tests we need are located, but some MUs have their regression tests under the YaST/Containers/Security MU job groups. We should keep the Core MU group as a default, but add an option to be able to look into other job groups under aggregated updates.
- Remove the
-a
option: this option is used to indicate the update ID and is mandatory right now. This is a bit weird and goes against posix stardards. It was developed this way in order to avoid using positional parameters. This problem should be fixed if we move the script to python.
Some other ideas to consider:
- Look into the QAM dashboard API. This has more info on each MU, could use this to link general openQA build results, whether the related RR is approved or not, etc
- Make it easier to see if there's regression tests for a package in an openQA test build. Check if there's a possibility to search for tests that have the package name in them inside each testsuite.
- Unit testing?
More ideas TBD
Resources
https://github.com/os-autoinst/scripts/blob/master/openqa-search-maintenance-core-jobs
https://confluence.suse.com/display/maintenanceqa/Guide+on+how+to+test+Updates
Post-Hackweek update
All major features were implemented. Unit tests are still in progress, and project will be moved to the SUSE github org once everything's done. https://github.com/mjdonis/oqa-search
New openSUSE-welcome by lkocman
Project Description
Let's revisit our existing openSUSE welcome app.
My goal was to show Leap 16 in a new coat. Welcome app adds to the first time use experience. We've recently added donation button to our existing welcome.
Some things that I recently wanted to address were EOL and possibly upgrade notification.
I've already done some experiments with mint welcome app, but not sure if it's better than the existing one.
There is also a PR to rework existing app https://github.com/openSUSE/openSUSE-welcome/pull/36 (this should be considered as an option too)
Goal for this Hackweek
New welcome app, possibly with EOL notification for Leap.
1) Welcome application(s) with (rebrand changes) maintained under github.com/openSUSE
2) Application is submitted to openSUSE:Factory && openSUSE:Leap:16.0
3) Updated needles in openQA (probably post hackweek)
Resources
Reddit discussion about the best welcome app out there.
Github repo for the current welcome app.