Der Sprach-Empfang haengt an einem unveroeffentlichten py-cord-Commit

[mdopp]

Herausgelöst aus #60, dessen ursprüngliche Frage — »kommen auf einer DAVE-Gilde entschlüsselte Pakete an?« — mit dem Live-Lauf vom 2026-08-11 mit ja beantwortet ist.

Die Lage

Damit der Sprach-Empfang funktioniert, hängt pyproject.toml an einem festen Commit:

py-cord @ git+https://github.com/Pycord-Development/pycord@326b72acc8d1d952ac002fe07ca65581cf5952bc

Das ist der Kopf von Pycord-PR #3159 (fix/voice-rec-2) vom 2026-07-22. Der PR ist offen, nicht gemergt und kollidiert inzwischen mit dem py-cord-master (mergeable_state: dirty); letzte Bewegung 2026-07-30. Ein Maintainer dort: »Wir sind keine Firma, wir können keinen Termin nennen.«

Warum es nötig ist

Die veröffentlichte 2.8.1 dekodiert in opus.py Opus vor dem Entschlüsseln (_decode_packet Zeile 711 gegen dave.decrypt Zeile 730). Auf einer DAVE-Gilde sieht der Dekoder deshalb Rauschen, wirft OpusError: corrupted stream, und der Empfänger reißt den Mitschnitt ab. Discord erzwingt DAVE seit dem 2026-03-02; ein Versuch, die Fassung 0 zu melden, endet mit WebSocket closed with 4017 — die Sprachverbindung wird dann ganz abgelehnt (am 2026-08-11 ausgeführt und wieder zurückgenommen).

Es gibt also keinen Weg daran vorbei, solange py-cord nichts veröffentlicht.

Was daran das Risiko ist

• Der Fremd-PR kann verschwinden: wird fix/voice-rec-2 gelöscht oder umgeschrieben, ist der Commit unter Umständen nicht mehr abrufbar und der Image-Bau scheitert. Wir nageln auf den Commit, nicht auf den Branchnamen — das schützt vor stillem Wandern, nicht vor Löschung.
• Der Bau braucht git im Image (ist ergänzt) und holt bei jedem Bau aus GitHub.
• Sicherheitsnachbesserungen von py-cord erreichen uns nicht, solange wir auf diesem Stand sitzen.

Ausstiegskriterium

Pycord #3159 gemergt und in einer Veröffentlichung enthalten → zurück auf eine Versionsangabe. Bis dahin bleibt dieses Issue der Beobachtungsposten.

Zu entscheiden

Wollen wir uns gegen das Verschwinden des Commits absichern — etwa durch einen eigenen Fork des Stands, aus dem wir bauen? Das kostet Pflege, macht den Bau aber unabhängig von einem fremden offenen PR.

Startpunkt

pyproject.toml (die festgenagelte Zeile mit Begründung), Dockerfile, Pycord #3159, Pycord #3139

[mdopp]

Kein Bauauftrag — bis auf eine Frage, und die gehört dem Betreiber.

Stand nachgeprüft am 2026-08-12: Pycord #3159 ist weiterhin offen, nicht gemergt, mergeable_state: dirty, letzte Bewegung 2026-07-30. Das Ausstiegskriterium ist also nicht erreicht; der Beobachtungsposten bleibt stehen.

Frage — A oder B?
A — es bleibt beim festgenagelten Fremd-Commit. Billig, aber der Image-Bau stirbt in dem Moment, in dem fix/voice-rec-2 gelöscht oder umgeschrieben wird, und der Zeitpunkt gehört uns nicht.
B — wir spiegeln den Stand in einen eigenen Fork und bauen daraus. Kostet Pflege (Rebase auf py-cord-master, wenn wir ihn brauchen), macht den Bau aber unabhängig von einem fremden offenen PR.

Bei B wird daraus eine Einheit (Fork anlegen, pyproject.toml umhängen, Begründung mitziehen); bei A bleibt dieses Issue schlicht der Wachposten, bis #3159 in einer Veröffentlichung steht.

(autoloop planner)

[mdopp]

Betreiber-Entscheidung 2026-08-12: eigener Fork.

Wir spiegeln den Stand aus Pycord-PR #3159 in einen eigenen Fork und bauen daraus, statt an einem fremden offenen Branch zu hängen, der gelöscht oder umgeschrieben werden kann. Der Image-Bau wird damit unabhängig davon, was im fremden Repo passiert.

Das Ausstiegskriterium bleibt unverändert: #3159 gemergt und veröffentlicht → zurück auf eine Versionsangabe, Fork weg.

Beim Bauen zu klären: wohin der Fork gehört, wie man ihm ansieht, von welchem Upstream-Stand er kommt, und wie man merkt, dass der Ausstieg möglich ist — ein Fork, den niemand mehr beobachtet, ist die schlechtere Lage als der Fremd-Branch.

Das needs-refinement fällt weg.

(autoloop orchestrator)

[mdopp]

Aufgeteilt nach der Betreiber-Entscheidung vom 2026-08-12 (eigener Fork).

Eingeplant: #152 — Fork anlegen, pyproject.toml auf Fork und Commit umhaengen, Begruendung und Ausstiegskriterium an der Zeile mitziehen.

Dieses Issue bleibt der Beobachtungsposten: Pycord #3159 gemergt und veroeffentlicht → zurueck auf eine Versionsangabe, Fork weg. Es schliesst nicht mit #152.

(autoloop planner)

[mdopp]

Wachposten nachgeprueft am 2026-08-24: Pycord #3159 ist weiterhin offen, nicht gemergt, mergeable_state: dirty, letzte Bewegung 2026-07-30. Juengstes py-cord-Release ist v2.8.1 (2026-07-25) und enthaelt den Fix nicht. Ausstiegskriterium nicht erreicht — bleibt geparkt.

_{Erfasst von einem Agenten (Autoloop-Planner).}