ARM-Nightly-Installationen, Arbeitsflächen pro Monitor und Sicherheitskorrekturen für Plugins

01ARM-Edge-ISOs erhalten eine nächtliche Installationspipeline

emirb hat omacom/omarchy-iso#282 am 16. Oktober eröffnet und in quattro zusammengeführt. Die Änderung ergänzt einen nächtlichen Edge-Ablauf für aarch64, der ein ISO erstellt, es unbeaufsichtigt installiert, die Installation zweimal startet und die Installation als N1x wiederholt, bevor eine Veröffentlichung freigegeben wird.

Die Pipeline veröffentlicht ein ISO, eine Prüfsumme sowie Paket- und Kernel-Metadaten. ARM-VM-Abbilder werden von diesem Ablauf weiterhin nicht unterstützt. Es handelt sich um Infrastruktur für Edge-Builds im Entwicklungszweig, nicht um die Ankündigung einer stabilen Version.

02Installer bewahrt Limine-Booteinträge anderer Installationen

birkskyum hat omacom/omarchy-iso#192 von jdvmi00 am 16. Oktober genehmigt und in quattro zusammengeführt. Beim Bereinigen werden nun Bezeichnung, Partition und Loader eines Booteintrags gemeinsam abgeglichen. Dadurch führt eine mehrfach verwendete Limine-Bezeichnung nicht mehr dazu, dass die Bootoption einer anderen Installation zum Löschen ausgewählt wird. Fehler beim Bereinigen werden protokolliert, statt die Installation abzubrechen.

github-actions[bot] meldete erfolgreiche Installationstests sowohl auf x86_64 als auch auf aarch64. Die Änderung wurde in den Entwicklungszweig übernommen; die vorliegenden Nachweise belegen keine stabile Version, die sie enthält.

03Vorschlag gegen Spark-Neustarts im Leerlauf hält am gemeinsamen ARM-Kernel fest

jdvmi00 hat omacom/omarchy-pkgs#1191 am 16. Oktober eröffnet, um Neustarts des NVIDIA DGX Spark im Leerlauf zu verhindern. Die aktuelle Beschreibung führt die Neustarts auf einen Schreibzugriff auf ein DVFSRC-Flag der Firmware zurück und schlägt vor, diesen bei exakt passender Spark-Hardware auszulassen. Die Beschreibung wurde bis zum 19. Oktober aktualisiert und gibt an, dass der Hardwaretest für diesen begrenzten Anwendungsbereich noch aussteht.

birkskyum hinterfragte die enge Hardwareauswahl und wies darauf hin, dass der Schreibzugriff auf anderen GB10-Desktops weiterhin erfolgen könnte. In der zugehörigen Kernel-Diskussion gab ryanrhughes einen einzigen linux-omarchy-Kernel für alle aarch64-Systeme als Richtung vor. jdvmi00 stimmte zu, die Untersuchung in diesem Rahmen fortzusetzen. Die Korrektur für die Neustarts bleibt ein offener Vorschlag; laut aktueller Beschreibung ist das Verhalten auf weiteren GB10- und N1x-Systemen nicht überprüft.

04Jeder Monitor erhält eigene nummerierte Arbeitsflächen

ryanrhughes hat omacom/omarchy#15655 am 16. Oktober eröffnet und am 18. Oktober in quattro zusammengeführt, also nach dem hier betrachteten Berichtstag. Laut aktueller Beschreibung erhält jeder Monitor lokal von 1 bis 10 nummerierte Arbeitsflächen. Tastenkürzel mit Ziffern wirken dadurch auf den fokussierten Monitor, und jede Leiste zeigt die Arbeitsflächen ihres jeweiligen Monitors an.

Der aktuelle Entwurf behält die Monitorzuordnungen über erneute Verbindungen hinweg bei. Beim Abziehen eines Monitors werden dessen Arbeitsflächen auf einem anderen Bildschirm zusammengeführt; wird er wieder angeschlossen, erhalten sie ihre früheren Nummern zurück. Dokumentiert ist außerdem, dass gespeicherte Arbeitsflächenlayouts der Neunummerierung nicht folgen. Diese Einzelheiten stammen aus der nachträglich aktualisierten Beschreibung; die Zusammenführung belegt die Verfügbarkeit im Entwicklungszweig, jedoch keine stabile Veröffentlichung.

05Unabhängige Bildschirmskalierung kommt im Review voran

timothygwright schlug in omacom/omarchy#15665 eine Monitorauswahl oberhalb der Skalierungsvorgaben im Anzeigepanel vor. Der Vorschlag vom 16. Oktober ermöglicht es außerdem, mit dem Skalierungsbefehl eine benannte Ausgabe anzusteuern. Sind mehrere Bildschirme aktiv, werden Änderungen per Tastenkürzel am fokussierten Monitor für jede Ausgabe separat gespeichert. Der Vorschlag ist weiterhin offen.

Nach dem Review berichtete timothygwright über Korrekturen bei der Tastaturauswahl weiter hinten aufgeführter Bildschirme, beim Erhalt der Einstellungen nach dem Abziehen eines Monitors und bei der Beibehaltung von Rotationsfeldern in durch Semikolons getrennten Einstellungen. Anschließend meldete greptile-apps[bot] alle drei Befunde als behoben. Der Autor gab außerdem an, das Panel mit zwei physischen Bildschirmen geprüft zu haben; diese Validierung beruht auf den Angaben des Mitwirkenden.

06AI Edit und Lock Screen Explorer veröffentlichen geprüfte Sicherheitskorrekturen

Die Veröffentlichung von omacom/omarchy-plugin-marketplace#11847 für AI Edit wurde am 16. Oktober abgeschlossen, nachdem HANCORE-linux Lesezugriffe auf die Zwischenablage entdeckt hatte, die die gemeinsam genutzte Shell blockieren oder ihre Ressourcen aufbrauchen konnten. paulmiddelkoop ersetzte das native Einfügen durch ein separates Leseprogramm mit einem Limit von 4 MiB und zwei Sekunden. Ein späterer Befund betraf den Werkzeugzugriff von Codex, über den sich zusätzlich zum ausgewählten Text auch lokale Bilder hochladen ließen. paulmiddelkoop meldete, diesen Zugriff deaktiviert zu haben, und HANCORE-linux bestätigte beide Korrekturen, bevor github-actions[bot] die Veröffentlichung bekannt gab.

Auch die Veröffentlichung von omacom/omarchy-plugin-marketplace#10783 für Lock Screen Explorer wurde abgeschlossen. HANCORE-linux identifizierte ein optionales Hilfsprogramm für die Rotation von Boot-Themes, mit dem sich eine Berechtigung zur Aktualisierung des Startbildschirms zur Codeausführung mit Root-Rechten ausweiten ließ. Das Update von SirJul1337 ergänzte eine Administratorabfrage, um ein installiertes Hilfsprogramm beim Upgrade zu entfernen. Anschließend bestätigte HANCORE-linux den Entfernungsablauf, die versiegelten Boot-Themes sowie frühere Korrekturen an Zwischenablage und Berechtigungen und genehmigte das Update.

github-actions[bot] bezeichnete die Überprüfung der Veröffentlichung von AI Edit als automatisiert und die von Lock Screen Explorer als durch einen Maintainer geprüft. Beide Hinweise beschränken die Überprüfung auf den exakten Stand im Marketplace und grenzen sie ausdrücklich von einem Sicherheitsaudit ab.

07VPN-DNS-Vorschlag erhält Reproduktion durch einen Worker und wirft eine konkretere Kompatibilitätsfrage auf

Der offene Vorschlag omacom/omarchy#14350 von Alumniminium ersetzt die globale DNS-Überschreibung von NetworkManager durch Anbietereinstellungen in WLAN- und Ethernet-Profilen sowie einen Dispatcher-Hook. Damit soll der gewählte öffentliche DNS-Anbieter erhalten bleiben, während VPN-Verbindungen Resolver für private Namen bereitstellen können.

Am 16. Oktober sagte Alumniminium zu, einen vorhandenen Test zu aktualisieren. Später meldete omarchybot eine Reproduktion durch einen Worker: Private WireGuard-Namen ließen sich mit der Implementierung in quattro nicht auflösen, mit dem Vorschlag dagegen schon, während Ethernet weiterhin Cloudflare-DNS nutzte. Der Bot berichtete außerdem, die Behandlung von Adressfamilien korrigiert zu haben, deren NetworkManager-Methoden DNS-Einstellungen ablehnen.

Der Vorschlag wartet weiterhin auf eine Maintainer-Entscheidung zu Bridge-, Bond- und VLAN-Uplinks, die laut Bericht in der Implementierung weiterhin die per DHCP zugewiesenen DNS-Server verwenden, sowie auf die Abstimmung mit sich überschneidenden Änderungen. omarchybot meldete erfolgreiche gezielte Tests, aber auch Fehler in der umfassenderen Shell-Testsuite. Die vorliegenden Ergebnisse belegen damit gezielte Fortschritte, jedoch keine vollständig erfolgreiche Testsuite.

08Untersuchung eines Sperrbildschirmabsturzes reproduziert rasches Entfernen einer Bildschirmausgabe

MarlonAzevedo ergänzte omacom/omarchy#9156 um einen Bericht vom 16. Oktober über einen AMD-Laptop, dessen Shell abstürzte, nachdem im gesperrten Zustand ein Monitor und ein USB-Hub angeschlossen worden waren. Die wiederhergestellte Bildschirmsperre meldete einen sicheren Status, blieb jedoch schwarz, sodass ein Hard-Reset erforderlich war.

Anschließend berichtete omarchybot, mit neueren Paketen einen Absturz durch einen Protokollfehler reproduziert zu haben, indem im gesperrten Zustand eine virtuelle Bildschirmausgabe erstellt und sofort wieder entfernt wurde. Der Trace deutete auf eine Race Condition zwischen einer Anfrage für eine Sperrbildschirmfläche und dem Entfernen der Ausgabe hin. Der Bot führte diesen Absturz auf Hyprland zurück, ließ das anschließende Verhalten mit schwarzem Bildschirm aber ausdrücklich ungeklärt.

Das Issue bleibt offen. Der Bot berichtete, dass die Untersuchung keine auf Omarchy begrenzte Fehlerbehebung ergeben habe. Ob das Abschalten des Bildschirms vermieden oder eine virtuelle Bildschirmausgabe beibehalten werden soll, überließ er als Designentscheidung einem Maintainer.

09Eyes schlägt lokale Bildschirmbeschreibungen vor; Datenschutzprüfungen werden noch begutachtet

Chessing234 eröffnete omacom/omarchy#15660 am 16. Oktober. Die aktuelle Beschreibung schlägt Eyes vor: einen auf Aufruf ausgeführten Bildschirmaufnahmebefehl, der ein lokales Bildanalysemodell bittet, einen Bildschirm zu beschreiben, eine Frage zu beantworten oder ein Objekt zu lokalisieren, ohne es anzuklicken. Die Beschreibung wurde nach dem Berichtszeitraum aktualisiert und nennt Tests mit Ersatzkomponenten statt eines durchgängigen Tests mit einem echten Modell.

In Review-Kommentaren vom 16. Oktober identifizierte greptile-apps[bot] eine Lücke zwischen der Prüfung, ob der Passwortmanager fokussiert ist, und der Aufnahme. Außerdem blieben temporäre Screenshots nach einem Abbruch bestehen. Dies sind Review-Befunde zum untersuchten Stand, keine unabhängigen Nachweise für das Verhalten der aktuellen Implementierung. Der Vorschlag bleibt offen.

10Super plus Umschalt plus S wird zum Screenshot-Tastenkürzel

Der quattro-Commit omacom/omarchy@51bfd1dbaa1b fügt Super plus Umschalt plus S für Screenshots hinzu und verlegt Google Maps auf Super plus Umschalt plus Alt plus S. TripleU613 ist als Beteiligter aufgeführt; als Autorenname des Commits ist TripleU angegeben.

Der Commit-Verlauf dokumentiert, dass eine vorgeschlagene Migration verworfen wurde, die persönliche Tastenbelegungen umgeschrieben hätte, da Paketupdates die Dateien mit den Standardbelegungen ersetzen. Dies ist eine per Commit übernommene Änderung im Entwicklungszweig und kein Nachweis für eine stabile Veröffentlichung.

11Aurora-Kernel ermöglicht das Booten in QEMUs virt-Maschine

Mit omacom/omarchy-pkgs@1cc8d4436ab3 wurde Unterstützung für generische PCIe-Hosts und die PL011-Konsole in master aufgenommen. Dadurch kann der Aurora-Kernel virtuelle Datenträger und Netzwerkgeräte erkennen und eine Konsole in QEMUs virt-Maschine bereitstellen, einschließlich der UTM-Konfiguration auf Apple Silicon.

malik-na ist als Beteiligter aufgeführt; als Autorenname des Commits ist Naeem Malik angegeben. Die Paketrevision steigt auf 12, während die festgelegte Quellversion unverändert bleibt. Laut Commit-Beschreibung binden die hinzugefügten Treiber an Device-Tree-Knoten, die in Apples Hardwarebeschreibungen nicht vorkommen.