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:

• Add more unit tests
  
• Make the python code modular
  
• DONE: Add code coverage if possible
  

Resources

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

---

Improve/rework household chore tracker `chorazon` by gniebler

Description

I wrote a household chore tracker named chorazon, which is meant to be deployed as a web application in the household's local network.

It features the ability to set up different (so far only weekly) schedules per task and per person, where tasks may span several days.

There are "tokens", which can be collected by users. Tasks can (and usually will) have rewards configured where they yield a certain amount of tokens. The idea is that they can later be redeemed for (surprise) gifts, but this is not implemented yet. (So right now one needs to edit the DB manually to subtract tokens when they're redeemed.)

Days are not rolled over automatically, to allow for task completion control.

We used it in my household for several months, with mixed success. There are many limitations in the system that would warrant a revisit.

It's written using the Pyramid Python framework with URL traversal, ZODB as the data store and Web Components for the frontend.

Goals

• Add admin screens for users, tasks and schedules
• Add models, pages etc. to allow redeeming tokens for gifts/surprises
• …?

Resources

tbd (Gitlab repo)

---

Song Search with CLAP by gcolangiuli

Description

Contrastive Language-Audio Pretraining (CLAP) is an open-source library that enables the training of a neural network on both Audio and Text descriptions, making it possible to search for Audio using a Text input. Several pre-trained models for song search are already available on huggingface

Goals

Evaluate how CLAP can be used for song searching and determine which types of queries yield the best results by developing a Minimum Viable Product (MVP) in Python. Based on the results of this MVP, future steps could include:

• Music Tagging;
• Free text search;
• Integration with an LLM (for example, with MCP or the OpenAI API) for music suggestions based on your own library.

The code for this project will be entirely written using AI to better explore and demonstrate AI capabilities.

Resources

• CLAP: The main model being researched;
• huggingface: Pre-trained models for CLAP;
• Free Music Archive: Creative Commons songs that can be used for testing;
• Colab: To be used as the development environment;
• hw25-song-search: Github repo of the project.

---

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.

---

HTTP API for nftables by crameleon

Background

The idea originated in https://progress.opensuse.org/issues/164060 and is about building RESTful API which translates authorized HTTP requests to operations in nftables, possibly utilizing libnftables-json(5).

Originally, I started developing such an interface in Go, utilizing https://github.com/google/nftables. The conversion of string networks to nftables set elements was problematic (unfortunately no record of details), and I started a second attempt in Python, which made interaction much simpler thanks to native nftables Python bindings.

Goals

1. Find and track the issue with google/nftables
2. Revisit and polish the Python code, primarily the server component
3. Finish functionality to interact with nftables sets (retrieving and updating elements), which are of interest for the originating issue
4. Align test suite
5. Packaging

Resources

• https://git.netfilter.org/nftables/tree/py/src/nftables.py
• https://git.com.de/Georg/nftables-http-api (to be moved to GitHub)
• https://build.opensuse.org/package/show/home:crameleon:containers/pytest-nftables-container

---

Gods & Steel: Tactical Prototype by pherranz

Description

A turn-based tactical combat prototype built in Godot, featuring two techno-sorcery factions in strategic warfare. This proof-of-concept demonstrates core gameplay mechanics including alternating activations, unique faction abilities, and tactical positioning on a grid-based battlefield.

Goals

Primary Objectives: Implement a complete turn-based tactical combat loop with alternating unit activation Create two distinct factions with 3-4 units each, showcasing unique mechanical identities Develop a modular code architecture for easy expansion to additional factions Deliver a playable 3v3 battle scenario with basic AI opponents

Technical Milestones: Grid-based movement and positioning system Alternating activation turn manager Unit ability system with faction-specific mechanics Basic AI decision-making (move → attack patterns) Health/damage system with win/lose conditions

Stretch Goals: Simple cover system for tactical positioning Additional faction-specific special abilities Enhanced visual feedback for actions

Resources

Technology Stack: Engine: Godot 4.2 Art Style: Top-down 64x64 pixel art Programming: GDScript Version Control: Git Tools: Aseprite/LibreSprite for pixel art, TrenchBroom for level blocking

Development Approach: Day 1: Core architecture (scenes, grid system, unit base class) Day 2: Turn management and basic movement Day 3: Combat system and faction abilities Day 4: AI implementation and balancing Day 5: Polish, bug fixing, and demo preparation

Technical Architecture: Scene Manager (handles game flow) Grid System (pathfinding, positioning) Unit Manager (turn order, activation) Faction System (modular ability definitions) AI Controller (state-based decision making)

Asset Pipeline: Placeholder art → Greybox prototyping → Final pixel art Modular unit definition using Godot's resource system Data-driven ability definitions for easy balancing

---