Jaraco Starter auf postmarketOS: Alpine Linux auf dem Smartphone

06. Februar 2026

Titel: postmarketOS als echtes Linux‑Smartphone – und wie Codex die App‑Entwicklung direkt auf dem Gerät beschleunigt

Wer Linux liebt, kennt den Moment, in dem sich „Mobile“ plötzlich nicht mehr wie eine Sonderwelt anfühlt. postmarketOS bringt genau dieses Gefühl zurück: ein Smartphone, das sich wie ein vollwertiges Alpine‑Linux‑System benimmt. Nicht nur ein Skin, nicht nur eine App‑Schicht – sondern das echte System, mit echten Paketen, echten Tools, und echtem Build‑Workflow.

Aber wir sind ehrlich: postmarketOS ist noch im Bootstrap‑Modus. Vieles funktioniert, aber vieles ist noch roh. Genau diese Frühphase macht die Plattform so spannend – und so kompromisslos: Wer hier entwickelt, baut nicht nur Apps, sondern auch die Grundlage des Ökosystems mit auf.

Als Beispiel dafür nehme ich hier Jaraco Starter, eine kleine GTK4/libadwaita‑App, die wir direkt auf postmarketOS entwickeln – mit Codex als Co‑Pilot. Warum gerade diese App? Weil sie klein genug ist, um sie komplett zu verstehen, aber vollständig genug, um alle typischen Herausforderungen zu zeigen: UI, Prozesse, Privilegien, Packaging und Integration in das System.

Projektüberblick: Was ist `Jaraco Starter`?

Jaraco Starter ist eine simple, aber produktive Utility‑App. Sie liest eine JSON‑Konfiguration aus ~/.config/jaraco/starter.json und rendert daraus eine Liste von Actions. Jede Action bekommt zwei kleine Radio‑Buttons „Off“ und „On“. Das Ziel ist klar: Dienste, Skripte oder Hintergrundjobs mit einem Finger‑Tap starten oder stoppen – auf einem mobilen Gerät, das sich wie ein echtes Linux‑System verhält.

Was die App besonders macht:

Konfigurationsgetrieben: Jede Action besteht aus name, script, sudo und optional kill_command sowie kill_sudo.
Sauberes Start/Stop‑Handling: Beim Stop wird zuerst SIGTERM gesendet; wenn der Prozess nach 3 Sekunden nicht beendet ist, folgt SIGKILL.
Privilege‑Handling über Polkit: Actions mit Root‑Rechten laufen über pkexec und eine Polkit‑Policy. Dazu existiert ein kleiner Runner, der run, pgrep, shell und kill kapselt.

Warum Codex direkt auf postmarketOS?

Der große Unterschied zwischen „Mobile‑Entwicklung“ und „Linux‑Entwicklung“ ist meistens der Umweg: Emulatoren, entfernte Builds, proprietäre Toolchains. postmarketOS kürzt das radikal ab. Du baust auf dem Gerät, testest auf dem Gerät, und installierst auf dem Gerät – ohne die Plattform zu verlassen.

Codex passt perfekt in dieses Setup, weil es direkt auf dem System arbeitet:

Konfigurationslogik erklären lassen
Signal‑Handling überprüfen
UI‑Komponenten refactoren
Packaging‑Schritte nachvollziehen
Fehler schneller lokalisieren

Und genau hier wird es für AI‑Devs interessant: Ist das die grüne Wiese, auf die man gewartet hat? Eine Plattform, die noch nicht festbetoniert ist, sondern mit neuen Tools, neuen Ideen und neuen Workflows gestaltet werden kann.

postmarketOS als echtes Alpine‑Linux‑System

postmarketOS ist keine exotische Sonderdistribution, sondern basiert auf Alpine Linux. Dadurch bekommst du apk als Paketmanager, Alpine‑Pakete, bekannte Build‑Konzepte und eine sehr klare, minimalistische Systemlogik.

Das wirkt erstmal wie ein Detail, ist aber für Entwicklung entscheidend:

Systemupdates laufen wie gewohnt über apk.
Pakete sind klein, sauber getrennt, skriptbar.
Build‑Workflows lassen sich sauber automatisieren.

Kurz: Du bist nicht „auf einem Smartphone“, sondern auf einem richtigen Linux‑System – nur mit Touchscreen.

Tool‑Ökosystem: Was ist schon da?

postmarketOS bringt nicht nur Alpine‑Pakete mit, sondern ein eigenes, aktives Ökosystem an Tools.

pmbootstrap ist das zentrale CLI‑Werkzeug für postmarketOS‑Entwicklung. Es erstellt Images, baut Pakete und unterstützt das Flashing auf reale Geräte.
pmaports ist das Repository der Package‑Build‑Definitionen, also die Paketrezepte, auf denen das System aufbaut.
apk bleibt die Basis für Paketverwaltung und Updates – ganz klassisch Alpine.

Für Linux‑Enthusiast:innen ist das der entscheidende Punkt: Das System ist nicht nur „nutzbar“, es ist entwickelbar. Und zwar mit Werkzeugen, die man bereits kennt und schätzt.

Fairphone 6 als europäischer Kontext

Technik ist nie nur Technik. Mit der Fairphone‑Reihe sehen wir ein europäisches Hardware‑Signal, das Reparierbarkeit und nachhaltige Produktgestaltung ernst nimmt. Der Fairphone 6 wurde in Europa gelauncht und steht als Beispiel dafür, dass europäische Hardware auch im Smartphone‑Bereich wieder Relevanz gewinnt.

Warum das im Kontext von postmarketOS wichtig ist? Weil Hardware‑Souveränität ohne Software‑Souveränität unvollständig bleibt. Wenn Europa eigene Hardware‑Leuchttürme baut, braucht es auch eigene Betriebssystem‑Optionen und App‑Ökosysteme, die nicht vollständig von US‑ oder China‑Plattformen abhängen.

Vision: Ein europäisches Mobile‑Ökosystem

Stell dir ein Europa vor, das nicht nur nachhaltige Hardware liefert, sondern auch ein eigenes, offenes mobiles Software‑Ökosystem.
postmarketOS ist kein Endprodukt – aber es zeigt, dass die Grundlagen existieren:

eine modulare, kontrollierbare Linux‑Basis
transparente Paketierung
offene Toolchains
eine Community, die echte Geräte supported

Das ist der strategische Hebel: Wenn postmarketOS und ähnliche Systeme reifen, entsteht Raum für europäische Apps, europäische Services und langfristig auch europäische digitale Unabhängigkeit.

Warum gerade dieses Projekt als Beispiel?

Jaraco Starter ist ein idealer Showcase, weil es drei Dinge gleichzeitig demonstriert:

Real‑World‑Funktionalität: Es ist keine Demo, sondern ein echtes Tool, das Prozesse starten/stoppen kann.
Mobile‑taugliches UI: GTK4/libadwaita läuft mobil solide, klar und angenehm.
Linux‑Logik bleibt erhalten: Prozesse, Signals, Polkit, Packaging – alles ist echtes Linux.

Damit wird der Entwicklungsprozess greifbar: Man sieht, wie Apps auf postmarketOS tatsächlich entstehen, und man kann den kompletten Weg von JSON‑Config bis Paketbau nachvollziehen.

Fazit

postmarketOS verändert nicht nur wo man entwickelt, sondern wie. Es ist eine Rückkehr zu einem direkten, transparenten Entwicklungsgefühl, das viele Linux‑Enthusiast:innen vermisst haben. Jaraco Starter zeigt, dass mobile App‑Entwicklung nicht zwingend Spezial‑SDKs oder verschlossene Plattformen braucht – sondern dass ein sauberes Linux‑System reicht, wenn die Werkzeuge stimmen.

Mit Codex direkt auf dem Gerät wird die Loop noch kürzer: lesen, verstehen, ändern, testen – alles in einem einzigen Arbeitsraum. Und damit rückt die provokante Frage ins Zentrum: Ist postmarketOS in dieser frühen Bootstrap‑Phase genau die Plattform, auf die AI‑Devs gewartet haben – eine grüne Wiese, die man jetzt erobern und neu denken kann?

Appendix: Befehle & Kurzbeschreibungen

apk update
Aktualisiert die Paketlisten von Alpine/postmarketOS.
apk add <paket>
Installiert ein Paket aus den Repositories.
pmbootstrap init
Initialisiert die pmbootstrap‑Umgebung für ein Gerät.
pmbootstrap build <pkg>
Baut ein Paket aus pmaports.
pmbootstrap install
Erstellt ein vollständiges postmarketOS‑Image.
abuild
Standard‑Tool zum Bauen von APK‑Paketen aus APKBUILD.
pkexec <command>
Startet einen Befehl mit Polkit‑Authentifizierung.
pgrep <pattern>
Findet laufende Prozesse anhand eines Namensmusters.

Um die entwicklung auszuprobieren kopiere die nachfolgende spec nach spec.md und instruiere codex die application basierend auf der Spec zu bauen.

Jaraco Starter Replication Spec (postmarketOS/Alpine)

Ziel

Eine kleine GTK4/libadwaita‑App, die Actions aus einer JSON‑Konfiguration lädt und diese als On/Off‑Schalter darstellt. Jede Action startet ein Skript (optional mit Root‑Rechten via Polkit) und kann es sauber beenden.

Funktionale Anforderungen

UI zeigt eine Liste von Actions mit Radio‑Buttons Off / On.
Konfiguration aus ~/.config/jaraco/starter.json.
Actions enthalten name, script, sudo und optional kill_command, kill_sudo.
On startet das Kommando (bei sudo: true via pkexec).
Off beendet den exakten Prozess (SIGTERM → 3s warten → SIGKILL).
Wenn kill_command gesetzt ist, wird es bevorzugt zum Stoppen verwendet.
UI zeigt Fehler via Dialog/Banner.
Erststart: Sample‑Config in ~/.config/jaraco/starter.json kopieren, falls nicht vorhanden.

Nicht‑funktionale Anforderungen

Läuft auf postmarketOS (Alpine) mit GTK4/libadwaita.
Python >= 3.10, PyGObject.
Polkit‑Integration über pkexec und Policy‑Datei.

Projektstruktur

jaraco-starter/
  README.md
  pyproject.toml
  setup.py
  starter.sample.json
  src/
    jaraco_starter/
      __init__.py
      app.py
      runner.py
  data/
    io.jaraco.Starter.desktop
    io.jaraco.Starter.metainfo.xml
    io.jaraco.Starter.svg
    io.jaraco.Starter.policy
  APKBUILD
  Makefile

Beispiel‑Konfiguration (~/.config/jaraco/starter.json)

{
  "actions": [
    {
      "name": "Tor",
      "script": "/usr/bin/tor",
      "sudo": true
    },
    {
      "name": "Notes Sync",
      "script": "/home/user/bin/notes-sync.sh",
      "sudo": false
    }
  ]
}

Optional pro Action:

kill_command: z. B. /usr/bin/pkill -f /usr/bin/tor
kill_sudo: überschreibt sudo für den Kill‑Befehl

Benötigte Pakete (Alpine/postmarketOS)

Aus APKBUILD:

python3
py3-gobject3
gtk4.0
libadwaita
polkit

Build‑Deps:

py3-setuptools

Installations‑Check (Alpine, ohne doppeltes Installieren)

Verwende apk info -e vor dem Install:

required="python3 py3-gobject3 gtk4.0 libadwaita polkit"
for pkg in $required; do
  if apk info -e "$pkg" >/dev/null 2>&1; then
    echo "OK: $pkg ist bereits installiert"
  else
    echo "Installiere: $pkg"
    sudo apk add "$pkg"
  fi
done

Für Build‑Tools:

if ! apk info -e py3-setuptools >/dev/null 2>&1; then
  sudo apk add py3-setuptools
fi

Kern‑Implementierung

Wesentliche Detail‑Logik (für 1:1 Replikation)

App‑ID ist io.jaraco.Starter (GTK/Adw Application ID, Desktop‑ID, Icon‑Name, Metainfo‑ID).
CONFIG_PATH ist ~/.config/jaraco/starter.json (expanduser).
SAMPLE_PATH ist /usr/share/jaraco-starter/starter.sample.json.
Seeding‑Logik: Wenn Config fehlt, wird SAMPLE_PATH kopiert. Falls Sample fehlt, wird ein Default‑Config‑JSON geschrieben mit einer Tor‑Action inklusive kill_command und kill_sudo: true.
Initialzustand: Beim Start wird pro Action ein Running‑Check durchgeführt und die Off/On‑Buttons entsprechend gesetzt.
Threading/UI: Bei Start/Stop mit sudo wird der Prozess in einem Worker‑Thread ausgeführt und das UI via GLib.idle_add aktualisiert, um UI‑Freeze zu vermeiden.
PID‑Semantik: Der Runner gibt die Prozessgruppen‑ID (PGID) zurück; diese PGID wird für spätere Kill‑Operationen verwendet.
Kill‑Semantik: SIGTERM an Prozessgruppe, 3s warten, danach SIGKILL an Prozessgruppe, falls noch lebendig.

Running‑Detection‑Logik

Wenn kill_command gesetzt ist, wird daraus ein Pattern für pgrep abgeleitet.
Parsing‑Regeln:
Strip leading doas, sudo, pkexec.
Handle sh -c / /bin/sh -c und parse den inneren String.
killall <name> → pattern = <name>, full=false.
pkill [-f] <pattern> → pattern = <pattern>, full=true wenn -f.
Wenn kein kill_command: Pattern aus script ableiten. Default: basename des ersten Tokens; bei Parsing‑Fehlern full=true und Pattern = gesamter String.
pgrep wird ohne sudo als pgrep -x (oder -f) verwendet; mit sudo über pkexec /usr/lib/jaraco-starter/runner pgrep [--full] <pattern>.

Polkit‑Policy‑Fixpunkte

Policy‑Action‑ID ist io.jaraco.Starter.run.
org.freedesktop.policykit.exec.path muss exakt /usr/lib/jaraco-starter/runner sein.

1) `app.py` (GUI + Prozesssteuerung)

Lädt Config, rendert ListBox‑Rows mit Off/On.
Startet Commands via subprocess.Popen (ohne sudo) oder via pkexec + Runner (mit sudo).
Stoppt über:
kill_command (mit optionalem sudo) oder
pkexec runner kill <pid> (sudo‑Fall) oder
os.killpg(pid, SIGTERM) → 3s → SIGKILL.
pgrep wird genutzt, um bestehende PIDs zu erkennen.

2) `runner.py` (privilegierter Helper)

Subcommands: run, shell, pgrep, kill.
Gibt PID der Prozessgruppe zurück.
Wird über Polkit‑Policy freigeschaltet.

Polkit‑Integration

Datei: data/io.jaraco.Starter.policy

org.freedesktop.policykit.exec.path zeigt auf /usr/lib/jaraco-starter/runner.
Standard: auth_admin_keep.

Desktop‑Integration

Dateien in data/:

io.jaraco.Starter.desktop
io.jaraco.Starter.metainfo.xml
io.jaraco.Starter.svg

Packaging (APKBUILD)

python3 setup.py install --root="$pkgdir" --prefix=/usr
runner.py nach /usr/lib/jaraco-starter/runner
Polkit‑Policy nach /usr/share/polkit-1/actions/
Desktop‑Dateien nach /usr/share/applications/ und /usr/share/metainfo/
Icon nach /usr/share/icons/hicolor/scalable/apps/
Sample‑Config nach /usr/share/jaraco-starter/starter.sample.json

Build‑/Install‑Ablauf (postmarketOS)

# Tarball erstellen
make dist

# APK bauen
make abuild

Optional lokale Sample‑Config:

make install-sample

APK‑Installation (lokales Repo)

Nach erfolgreichem Build die folgenden Install‑Anweisungen ausgeben:

echo "/home/user/packages/test" | sudo tee -a /etc/apk/repositories
sudo apk update
sudo apk add jaraco-starter

APK‑Installation (direkt aus Datei)

sudo apk add --allow-untrusted /home/user/packages/test/aarch64/jaraco-starter-0.1.0-r0.apk

Laufzeit‑Verhalten

Bei Start ohne Config wird starter.sample.json kopiert.
Start‑Fehler zeigen einen Dialog.
Stop‑Fehler reaktivieren den On‑Button.

Validierung

App startet ohne Config → Config wird erzeugt.
On startet Skript, Off stoppt es sauber.
sudo‑Actions fordern Authentifizierung via Polkit an.
kill_command überschreibt PID‑Kill.

Call to Action

Du planst, Linux-basierte Geräte oder KI-gestützte Automatisierung produktionsreif zu machen? Wir unterstützen dich von der Hardware-nahen Entwicklung über Container-Plattformen bis hin zu Low-Code-/No-Code-Workflows und MCP-gestützten Toolchains.

Kontaktiere uns – telefonisch unter +49 176 85952637, per Mail an info@jaraco.de oder über unser Kontaktformular.