Improve chore and screen time doc generator script `wochenplaner` by gniebler

Description

I wrote a little Python script to generate PDF docs, which can be used to track daily chore completion and screen time usage for several people, with one page per person/week.

I named this script wochenplaner and have been using it for a few months now.

It needs some improvements and adjustments in how the screen time should be tracked and how chores are displayed.

Goals

• Fix chore field separation lines
• Change screen time tracking logic from "global" (week-long) to daily subtraction and weekly addition of remainders (more intuitive than current "weekly time budget method)
• Add logic to fill in chore fields/lines, ideally with pictures, falling back to text.

Resources

tbd (Gitlab repo)

---

Liz - Prompt autocomplete by ftorchia

Description

Liz is the Rancher AI assistant for cluster operations.

Goals

We want to help users when sending new messages to Liz, by adding an autocomplete feature to complete their requests based on the context.

Example:

• User prompt: "Can you show me the list of p"
• Autocomplete suggestion: "Can you show me the list of p...od in local cluster?"

Example:

• User prompt: "Show me the logs of #rancher-"
• Chat console: It shows a drop-down widget, next to the # character, with the list of available pod names starting with "rancher-".

Technical Overview

1. The AI agent should expose a new ws/autocomplete endpoint to proxy autocomplete messages to the LLM.
2. The UI extension should be able to display prompt suggestions and allow users to apply the autocomplete to the Prompt via keyboard shortcuts.

Resources

GitHub repository

---

Bring to Cockpit + System Roles capabilities from YAST by miguelpc

Bring to Cockpit + System Roles features from YAST

Cockpit and System Roles have been added to SLES 16 There are several capabilities in YAST that are not yet present in Cockpit and System Roles We will follow the principle of "automate first, UI later" being System Roles the automation component and Cockpit the UI one.

Goals

The idea is to implement service configuration in System Roles and then add an UI to manage these in Cockpit. For some capabilities it will be required to have an specific Cockpit Module as they will interact with a reasource already configured.

Resources

A plan on capabilities missing and suggested implementation is available here: https://docs.google.com/spreadsheets/d/1ZhX-Ip9MKJNeKSYV3bSZG4Qc5giuY7XSV0U61Ecu9lo/edit

Linux System Roles:

• https://linux-system-roles.github.io/
• https://build.opensuse.org/package/show/openSUSE:Factory/ansible-linux-system-roles Package on sle16 ansible-linux-system-roles

First meeting Hackweek catchup

• Monday, December 1 · 11:00 – 12:00
• Time zone: Europe/Madrid
• Google Meet link: https://meet.google.com/rrc-kqch-hca

---

Enhance git-sha-verify: A tool to checkout validated git hashes by gpathak

Description

git-sha-verify is a simple shell utility to verify and checkout trusted git commits signed using GPG key. This tool helps ensure that only authorized or validated commit hashes are checked out from a git repository, supporting better code integrity and security within the workflow.

Supports:

• Verifying commit authenticity signed using gpg key
  
• Checking out trusted commits
  

Ideal for teams and projects where the integrity of git history is crucial.

Goals

A minimal python code of the shell script exists as a pull request.

The goal of this hackweek is to:

• DONE: Add more unit tests
  • New and more tests can be added later
    
• Partially DONE: Make the python code modular
  
• DONE: Add code coverage if possible
  

Resources

• Link to GitHub Repository: https://github.com/openSUSE/git-sha-verify

---

Update M2Crypto by mcepl

There are couple of projects I work on, which need my attention and putting them to shape:

• M2Crypto

Goal for this Hackweek

• Put M2Crypto into better shape (most issues closed, all pull requests processed)
• More fun to learn jujutsu
• Play more with Gemini, how much it help (or not).
• Perhaps, also (just slightly related), help to fix vis to work with LuaJIT, particularly to make vis-lspc working.

---

Work on kqlite (Lightweight remote SQLite with high availability and auto failover). by epenchev

Description

Continue the work on kqlite (Lightweight remote SQLite with high availability and auto failover).
It's a solution for applications that require High Availability but don't need all the features of a complete RDBMS and can fit SQLite in their use case.
Also kqlite can be considered to be used as a lightweight storage backend for K8s (https://docs.k3s.io/datastore) and the Edge, and allowing to have only 2 Nodes for HA.

Goals

Push kqlite to a beta version.
kqlite as library for Go programs.

Resources

https://github.com/kqlite/kqlite

---

Casky – Lightweight C Key-Value Engine with Crash Recovery by pperego

Description

Casky is a lightweight, crash-safe key-value store written in C, designed for fast storage and retrieval of data with a minimal footprint. Built using Test-Driven Development (TDD), Casky ensures reliability while keeping the codebase clean and maintainable. It is inspired by Bitcask and aims to provide a simple, embeddable storage engine that can be integrated into microservices, IoT devices, and other C-based applications.

Objectives:

• Implement a minimal key-value store with append-only file storage.
• Support crash-safe persistence and recovery.
• Expose a simple public API: store(key, value), load(key), delete(key).
• Follow TDD methodology for robust and testable code.
• Provide a foundation for future extensions, such as in-memory caching, compaction, and eventual integration with vector-based databases like PixelDB.

Why This Project is Interesting:

Casky combines low-level C programming with modern database concepts, making it an ideal playground to explore storage engines, crash safety, and performance optimization. It’s small enough to complete during Hackweek, yet it provides a solid base for future experiments and more complex projects.

Goals

• Working prototype with append-only storage and memtable.
• TDD test suite covering core functionality and recovery.
• Demonstration of basic operations: insert, load, delete.
• Optional bonus: LRU caching, file compaction, performance benchmarks.

Future Directions:

After Hackweek, Casky can evolve into a backend engine for projects like PixelDB, supporting vector storage and approximate nearest neighbor search, combining low-level performance with cutting-edge AI retrieval applications.

Resources

The Bitcask paper: https://riak.com/assets/bitcask-intro.pdf The Casky repository: https://github.com/thesp0nge/casky

Day 1

[0.10.0] - 2025-12-01

Added

• Core in-memory KeyDir and EntryNode structures
• API functions: caskyopen, caskyclose, caskyput, caskyget, casky_delete
• Hash function: caskydjb2hash_xor
• Error handling via casky_errno
• Unit tests for all APIs using standard asserts
• Test cleanup of temporary files

Changed

• None (first MVP)

Fixed

• None (first MVP)

Day 2

[0.20.0] - 2025-12-02

---

GRIT: GRaphs In Time by fvanlankvelt

Description

The current implementation of the Time-Travelling Topology database, StackGraph, has served SUSE Observability well over the years. But it is dependent on a number of complex components - Zookeeper, HDFS, HBase, Tephra. These lead to a large number of failure scenarios and parameters to tweak for optimal performance.

The goal of this project is to take the high-level requirements (time-travelling topology, querying over time, transactional changes to topology, scalability) and design/prototype key components, to see where they would lead us if we were to start from scratch today.

An example would be to use RocksDB to persist topology history. Its user-defined timestamps seem to match well with time-travelling, has transaction support with fine-grained conflict detection.

Goals

Determine feasibility of implementing the model on a whole new architecture. See how to model the graph and its history such that updates and querying are performant, transactional conflicts are minimized. Build a prototype to validate the model.

Resources

Backend developers, preferably experienced in distributed systems. Programming language: scala 3 with some C++ for low-level.

Progress

The project has started at github GRaphs In Time - a C++ project that

• embeds RocksDB for persistence,
• uses (nu)Raft for replication/consensus,
• supports large transactions, with
• SNAPSHOT isolation
• time-travel
• graph operations (add/remove vertex/edge, indexes)

---

Sim racing track database by avicenzi

Description

Do you wonder which tracks are available in each sim racing game? Wonder no more.

Goals

Create a simple website that includes details about sim racing games.

The website should be static and built with Alpine.JS and TailwindCSS. Data should be consumed from JSON, easily done with Alpine.JS.

The main goal is to gather track information, because tracks vary by game. Older games might have older layouts, and newer games might have up-to-date layouts. Some games include historical layouts, some are laser scanned. Many tracks are available as DLCs.

Initially include official tracks from:

• ACC
• iRacing
• PC2
• LMU
• Raceroom
• Rennsport

These games have a short list of tracks and DLCs.

Resources

The hardest part is collecting information about tracks in each game. Active games usually have information on their website or even on Steam. Older games might be on Fandom or a Wiki. Real track information can be extracted from Wikipedia or the track website.

---

Port the classic browser game HackTheNet to PHP 8 by dgedon

Description

The classic browser game HackTheNet from 2004 still runs on PHP 4/5 and MySQL 5 and needs a port to PHP 8 and e.g. MariaDB.

Goals

• Port the game to PHP 8 and MariaDB 11
• Create a container where the game server can simply be started/stopped

Resources

• https://github.com/nodeg/hackthenet

---