# Erkenntnisse aus der Arbeit ohne Klaus

## xkb's Tücken:
Klaus kann es gar nicht kapieren.  Die Tücken sind darin, dass alles "zusammengesetzt" wird - keine repetitiven Patterns oder irgend etwas, womit Klaus wirklich etwas anfangen kann.  Einzig die ellenlangen Listen sind repetitive Patterns.

Nur: diese Listen beschreiben lediglich Möglichkeiten…

Theoretisch sollten
- ~/.config/xkb
- ~/.xkb
- /etc/xkb
- /usr/share/xkeyboard-config-2

… durchsucht werden.  Das sind die default includes - ergo sollten user-settings automatisch nach einem Reboot auftauchen.

### Wichtige Erkenntnisse der Tücken
Die "Modelle" sind erst einmal total nebensächlich.\
Sie diehnen lediglich der optischen Anordnung bei der Konfiguration und der Festlegung, welche Tasten (und somit Key-Codes) existieren bzw. zu erwarten sind.

Welche Keycodes wirklich existieren (völlig unabhängig davon, ob jemals ausgelöst), und wie diese genau gemapped sind:\
Das ist in den `Layouts` und `Variants` festgelegt!

Es hat an der Stelle einfach deshalb nichts mehr mit dem jeweiligen `Model` zu tun, weil es nicht mehr um Tasten, sondern um das Transformieren von Key-Codes auf Uni-Codes bzw. "Keyboard-Ausgabe" geht.

## Ergänzungs-Vorgehensweise lt. Docs
### eigenes Basisverzeichnis
- es wird empfohlen, die Daten in einem eigenen Basisverzeichnis zu sammeln
- zum Compile-Testen: `xkbcli compile-keymap --include <basisverzeichnis> --include-defaults`
  - weitere Switches: `--verbose --no-pretty --test`
```shell
xkbcli compile-keymap --include /tmp/xkb \
                      --include-defaults \
                      --test \
                      --layout test \
&& echo "valid!" || echo "invalid!"
```
- To preview how keys behave interactively, use the following command. It will open a window that needs to stay focused and log the keys in the terminal. Use Esc to quit.
```shell
xkbcli compile-keymap --include /tmp/xkb \
                      --include-defaults \
                      --layout test \
| xkbcli interactive
```
- zum richtigen Testen: in eines der user-Verzeichnisse kopieren und die X-Session neu starten.

## RPM-Paket bauen

### SRPM (lokal, zum Testen) (Stand: 2026_05_28)

Tarball manuell erstellen (solange kein git-Tag vorhanden):
```bash
cd $WORKSPACE
tar czf $SRC_DIR/$PAKET_NAME-$PAKET_VERSION.tar.gz \
  --transform "s|^$SCR_DIR|$PAKET_NAME-$PAKET_VERSION|" \
  $SRC_DIR/geometry \
  $SRC_DIR/keycodes \
  $SRC_DIR/rules    \
  $SRC_DIR/symbols
```

SRPM bauen mit mock (`--sources` ist NICHT optional!):
```bash
mock -r fedora-44-x86_64 \
  --resultdir $FolderToPutSrcRpm \
  --buildsrpm --spec $PathToSpecFile \
  --sources $PathToSourcesFolder
```
RPMs aus dem SRPM erstellen:
```bash
mock -r fedora-44-x86_64 --resultdir $FolderToPutRpms --rebuild $PATH_TO_SRPM
```

### ✓ Tarball aus git (sobald Repo und Tag vorhanden)
```bash
git archive --prefix=$PAKET_NAME-$PAKET_VERSION/ $GIT_TAG \
  | gzip > $PAKET_NAME-$PAKET_VERSION.tar.gz
```

### ✓ COPR-Build (SCM-Webhook aktiv seit v0.2)

`Source0` im SPEC auf GitLab-Archiv-URL — COPR fetcht automatisch bei Tag-Push:
```
Source0: https://gitlab.com/$GITLAB_GROUP/$REPO_NAME/-/archive/%{version}/user-hw-extras-%{version}.tar.gz
```
Wichtig: Dateiname in der URL muss dem **Repo-Namen** entsprechen (nicht `%{name}`),
sonst hängt GitLab den Commit-SHA an den Verzeichnisnamen → `%autosetup -n` scheitert.

## Collab-Info

### Versionierung (Klaus & Stefan)

Format: `Version: M.m.p` + `Release: N%{?dist}`

- **Version** (`M.m.p`): gemeinsame Entscheidung — nie eigenständig hochziehen
- **Release** (`N`): Buildnummer — läuft mit jedem Commit hoch

**pre-push Hook** (`.git/hooks/pre-push`) inkrementiert `Release` automatisch per AWK
und staged die geänderte SPEC. Was gepusht wird trägt die aktuelle Buildnummer —
die nächste Entwicklungsrunde startet mit bereits gestagter `N+1`.
