01Den Standard-Kernel für den Systemstart im Update-Menü auswählen
dhh hat omacom/omarchy#15966 verfasst und in den Quattro-Entwicklungszweig übernommen. Sind mehrere Kernel installiert, bietet Update jetzt ein Kernel-Menü an, das nach einer Authentifizierung Limine's Standardauswahl ändert, den ausgewählten Kernel neu baut und eine Benachrichtigung mit Neustartoption anbietet. Unter Direct Boot verweigert der Befehl den Wechsel. Schlägt ein Wechsel fehl, versucht er, die vorherige Boot-Konfiguration wiederherzustellen.
In der Diskussion wurde eine bewusste Einschränkung akzeptiert: Bei manuell bearbeiteten Boot-Reihenfolgen, die mit einem Platzhalter beginnen, kann das Häkchen für den aktuellen Kernel fehlen. dhh erklärte, dass die mitgelieferten Einstellungen und der Auswahlbefehl exakte Kernel-Namen verwenden. 
greptile-apps[bot] akzeptierte diese Abwägung und zog den Hinweis in omacom/omarchy#15966:discussion_r4339204956 zurück.
02Monitor-Umschaltung und schwebende Arbeitsflächen bewahren persönliche Layouts
dhh hat zwei Korrekturen von 
zihaomu in den Quattro-Entwicklungszweig übernommen. Mit omacom/omarchy#16147 bleiben beim erneuten Aktivieren eines Bildschirms Modus, Position und Skalierung seiner bestehenden, namentlich zugeordneten Monitorregel erhalten. Mit omacom/omarchy#16143 greifen persönliche Regeln für schwebende Fenster, die nach gespeicherten Arbeitsflächenmodi registriert werden, schon vor dem Öffnen des ersten passenden Fensters. Das verhindert unerwünschte Größenänderungen und einen späteren Wechsel ins Kachellayout.
omarchybot berichtete, beide Probleme reproduziert und die Korrekturen auf eigens dafür bereitgestellten, anschließend verworfenen Omarchy-Workern geprüft zu haben. Das Display-Review benannte auch die Grenze der Korrektur: Angepasste Monitorregeln mit Platzhaltern oder Beschreibungen können ihr Layout weiterhin verlieren. Die Änderung für schwebende Arbeitsflächen korrigiert Zuständigkeiten und Ausschlüsse; eine allgemeine Lösung für die anfängliche Aushandlung der Fenstergröße ist damit nicht nachgewiesen.
03Pakete für das Surface Pro 11 sind angekommen, die Entscheidung über die Geräteeinrichtung steht noch aus
turbineBMW's Vorschlag zur Einrichtung des Surface Pro 11 ist unter omacom/omarchy#14390 weiterhin offen. Unterstützende Commits wurden in den master-Zweig des Paket-Repositorys übernommen. Sie betreffen WLAN, Audio, Kamerarouting, die Kopplung des Flex Keyboard, das Aufwachen aus dem Ruhezustand, Stifteingabe und Umgebungslichtsensorik. Die Paket-Commits beschreiben eine Veröffentlichung im edge-Kanal; diese ist von der Annahme der Geräteeinrichtung zu unterscheiden.
birkskyum's Review verlangte, die reinen ARM-Pakete aus den Offline-Spiegeln für x86_64 auszuschließen und eine Installation mit veröffentlichten Paketen abzuschließen. Der Ausschluss wurde als omacom/omarchy-iso@886f2899f1bb im Quattro-Zweig des ISO-Repositorys festgeschrieben. turbineBMW berichtete in omacom/omarchy#14390:issuecomment-6323783042 von einer erfolgreichen Neuinstallation auf einem Surface.
omarchybot erklärte anschließend, dass die Voraussetzungen auf Autorenseite erfüllt seien. Die Einordnung und die Wahl zwischen konkurrierenden Unterstützungsansätzen erforderten aber weiterhin eine Entscheidung der Maintainer. Die vorgeschlagene Einrichtung richtet sich an das OLED-Modell; LCD- und X-Plus-Varianten liegen weiterhin außerhalb des getesteten Umfangs.
05Vorschlag für natives Podman benennt Grenzen bei Migration und Wiederherstellung
acrogenesis eröffnete omacom/omarchy#16173, um Podman zur nativen Container-Engine zu machen, mit optionaler Docker-Kompatibilität. Der Vorschlag verwaltet Entwicklungsdatenbanken über Benutzerdienste ohne Root-Rechte, erhält Daten bei unterstützten Docker-Migrationen und stellt den Windows-Starter auf authentifiziertes Podman mit Root-Rechten um. Dessen Laufwerk und Zugangsdaten bleiben dabei erhalten. Der Vorschlag ist weiterhin offen.
greptile-apps[bot] bezweifelte, dass die Paketabfragen alternative Docker-Anbieter erkennen. acrogenesis berichtete, das tatsächliche pacman-Programm mit isolierten Paketdatenbanken getestet und festgestellt zu haben, dass diese Anbieter korrekt aufgelöst wurden. In omacom/omarchy#16173:discussion_r4337709418 stufte der Autor den Hinweis daher als Fehlalarm ein. Er unterscheidet außerdem zwischen den aktuellen Ergebnissen gezielter Tests und früheren Laufzeitnachweisen: Eine vollständige Installation und Engine-Migration wurden für den überarbeiteten Vorschlag nicht erneut durchgeführt.
06Captive-Portal-Vorschlag pausiert Tailscale-Exit-Nodes während der Anmeldung
dhh eröffnete omacom/omarchy#16186, um die Verbindungserkennung auf Omarchy's eigenen Endpunkt umzustellen und die Anmeldung an Captive Portals zu verbessern. Der vorgeschlagene Portal-Befehl pausiert vorübergehend einen aktiven Tailscale-Exit-Node, überwacht die Verbindung und aktiviert ihn nach der Anmeldung wieder. Das Netzwerkpanel würde außerdem keine irreführenden Paketverlustwerte anzeigen, solange kein Internetzugang besteht.
greptile-apps[bot] wies auf eine von der Spracheinstellung abhängige Abschlussprüfung hin, durch die der Exit-Node pausiert bleiben könnte, sowie auf Benachrichtigungstexte, die die Übersetzungskataloge umgehen. Der Vorschlag ist weiterhin offen. dhh's Beschreibung nennt außerdem im Browser zwischengespeichertes HSTS als bekanntes Hindernis und hält fest, dass weder das tatsächliche Pausieren eines Exit-Nodes noch ein realer Captive-Portal-Ablauf bislang getestet wurden.
07Schutzmaßnahme im Installer soll verhindern, dass unlesbare Partitionstabellen vorhandene Daten gefährden
emirb eröffnete omacom/omarchy-iso#307, nachdem er einen Installationsablauf für freien Speicherplatz identifiziert hatte, der eine vorhandene Partition für eine neu angelegte halten könnte, wenn das anfängliche Lesen der Partitionstabelle fehlschlägt. Eine bestehende Omarchy-EFI-Partition könnte dann formatiert oder beim Zurückrollen gelöscht werden.
Der noch offene Vorschlag verlangt, dass die Partitionstabelle vor und nach dem Anlegen erfolgreich gelesen wird und danach genau eine zusätzliche Partition vorhanden ist. Lässt sich das Ergebnis nicht sicher zuordnen, bricht die Installation ab, statt zu raten. 
github-actions[bot] meldete in omacom/omarchy-iso#307:issuecomment-6322688377 erfolgreiche Installationstests sowohl auf x86_64 als auch auf aarch64.
08Live-ISO soll den Kernel starten, der auf dem PC tatsächlich installiert wird
emirb's noch offener Vorschlag omacom/omarchy-iso#310 sieht vor, in der Live-Umgebung auf gewöhnlichen PCs linux-omarchy zu starten. Für Rechner, die Apple als Hersteller melden, soll linux-t2 erhalten bleiben. So soll der später installierte Kernel bereits vor der Installation erprobt werden, statt ihm erstmals nach dem Bootloader und der Aufforderung zum Entsperren des Laufwerks zu begegnen.
Der Vorschlag nimmt beide Kernel in das x86_64-Abbild auf und rechnet mit einer Vergrößerung um etwa drei Prozent. github-actions[bot] meldete in omacom/omarchy-iso#310:issuecomment-6328144501 erfolgreiche Installationstests für x86_64 und aarch64. Der Vorschlag wurde noch nicht übernommen.
11Paketverfolgung erhält authentifizierte Abrufe und begrenzte Wiederholungsversuche
Mit emirb verbundene Commits zur Paketpflege wurden in master übernommen, um die unzuverlässige Verfolgung von Upstream-Änderungen zu verbessern. omacom/omarchy-pkgs@4f04db9a0506 ergänzt authentifizierte GitHub-API-Anfragen und erzwingt für betroffene Abrufe HTTP/1.1. Die Commit-Beschreibung führt viele der jüngsten Ausfälle auf gemeinsam genutzte Kontingente für anonyme API-Anfragen zurück, andere auf HTTP/2-Fehler.
omacom/omarchy-pkgs@b4c15a6898b2 ergänzt eine begrenzte Zahl von Wiederholungsversuchen bei vorübergehenden Fehlern und speichert Downloads zunächst zwischen, bevor deren Inhalt ausgegeben wird. Dadurch werden nach erneuten Versuchen keine unvollständigen Antworten aneinandergehängt. Ein begleitender Commit entfernt die allgemeinen stündlichen Fehlermeldungen zur Branch-Verfolgung aus Basecamp. Fehlgeschlagene Actions-Läufe und paketspezifische Protokolle bleiben erhalten.
