Benachrichtigungssteuerung reduziert, Mac-Bootloader-Migration erreicht edge

01Benachrichtigungen kehren zu einem einfachen Schalter für „Nicht stören“ zurück

dhh hat zwei Änderungen verfasst und in quattro zusammengeführt, die die Schlummerfunktion für Benachrichtigungen, die Erkennung von Bildschirmfreigaben sowie das Benachrichtigungspanel und dessen Einstellungen entfernen. In omacom/omarchy#16429:issuecomment-6371608347 erklärte dhh, die Funktion habe noch nicht die von ihm als ausreichend erachtete Qualität erreicht. Es handelt sich um Änderungen auf dem Entwicklungszweig, nicht um eine angekündigte stabile Veröffentlichung.

Mit omacom/omarchy#16430 dient die Glocke nur noch als Schalter für „Nicht stören“. Für Benachrichtigungen gelten feste Regeln: Sie folgen dem fokussierten Bildschirm, weichen Vollbildfenstern, speichern einen Tag Verlauf mit höchstens 100 Einträgen und lassen Bestätigungscodes auch bei aktiviertem „Nicht stören“ durch. Ein Rechtsklick schließt die Karten; mit Super+Shift+Alt+, lassen sich gespeicherte Benachrichtigungen weiterhin wieder einblenden.

02Mac-Bootloader-Migration auf edge veröffentlicht, Hardwarevalidierung steht noch aus

maralcbr hat chriskearney's omacom/omarchy-pkgs#1513 gemergt. Damit wird m1n1-aurora auf einen festgelegten Stand des Quellcodes von omacom/m1n1 umgestellt und ersetzt die nachgelagerten Pakete aura und m1n1-neo. github-actions[bot] meldete in omacom/omarchy-pkgs#1513:issuecomment-6359746568, dass Version 1.6.1.aurora20-3 für aarch64 auf edge verfügbar ist. Das ist eine Veröffentlichung auf edge, keine Freigabe für rc oder stable.

Im Review wurde der Upgrade-Pfad vor dem Merge geändert. maralcbr stellte auf eine virtuelle U-Boot-Abhängigkeit um, damit bestehende Installationen ihren bisherigen Anbieter beibehalten können, erweiterte die weiterhin unterstützte Boot-Matrix für Stage 1 und meldete, dass die abgestimmte Umstellung des Image-Builders übernommen worden sei. Normale Paketupdates ändern Stage 2, ohne eine neue Stage 1 zu registrieren.

scottjones berichtete von einer erfolgreichen Paketmigration in einem frisch angelegten Root-Dateisystem, wies in omacom/omarchy-pkgs#1513:pullrequestreview-5624139147 aber auf Display-Ausfälle bei verschlüsselten M3 Air und Bedenken zur Verlagerung von Stage 1 hin. Laut Vorschlag steht die Hardware-Qualifizierung genau dieses Pakets noch aus. Ein erfolgreicher Build und die Veröffentlichung auf edge belegen diese Kaltstart-Ergebnisse nicht.

03Installer-CI wird auf zehn Installationsvarianten erweitert

emirb hat omacom/omarchy-iso#238 in den F1-Entwicklungsbranch f1/17-receive-path-archinstall-45 gemergt. Die CI baut das ISO einmal und verteilt es auf zehn x86_64-Varianten. Diese decken Verschlüsselung, britische Tastaturbelegung, kleine Datenträger, wenig Arbeitsspeicher, BIOS, Unified Kernel Images und ein langsames Installationsmedium ab. Die Standardvariante und die verschlüsselte Variante durchlaufen sämtliche Integrationsszenarien.

Die Änderung verlagert Tests, die bisher auf einer Workstation liefen, in die CI. Bekannte Fehler beim Zurücksetzen auf den Werkszustand bleiben sichtbar und werden nur anhand des exakten Assertion-Texts und mit einem Ablaufdatum zugelassen. greptile-apps[bot] wies in omacom/omarchy-iso#238:discussion_r4359256431 außerdem auf ein Bereinigungsproblem im lokalen Test-Harness hin: Scheitert ein VM-Start mit keep-running, können simulierte PCI-Server weiterlaufen. Im vorliegenden Review wurde dieser Befund als nicht blockierend eingestuft.

04Installation mit vorgefertigtem Root-Image bleibt im Review

emirb's offener omacom/omarchy-iso#216 würde ein vorgefertigtes Root-Image installieren und gerätespezifische Pakete ergänzen, statt während der Installation rund 940 Pakete zu entpacken. Der Vorschlag zur Übernahme baut nach eigener Angabe auf hegjon's Root-Image-Entwurf auf. github-actions[bot] meldete in omacom/omarchy-iso#216:issuecomment-6364126768 erfolgreiche VM-Installationen mit 41.6 Sekunden auf x86_64 und 23.8 Sekunden auf aarch64, bei längeren ISO-Buildzeiten.

hegjon veröffentlichte ein automatisiertes Review, dessen Befunde teilweise von Hand stichprobenartig geprüft wurden. Es ging unter anderem um die Initialisierung der Maschinenidentität, zusätzliche Kernel-Boot-Images und den Umgang mit dem Fallback beim Verkleinern. Später wies greptile-apps[bot] in omacom/omarchy-iso#216:discussion_r4359565646 darauf hin, dass eine Abfrage der Paketanzahl weiterhin das Standardpaket linux statt des ausgewählten Image-Kernels anforderte. Diese Review-Befunde beziehen sich auf bestimmte Revisionen; der Bericht über erfolgreiche VM-Tests belegt nicht, dass alle Bedenken ausgeräumt sind. Der PR zur Übernahme ist weiterhin offen.

05Schutz für Web-App-Icons kommt mit Korrekturen für Weiterleitungen und IPv6 voran

hizawye's offener omacom/omarchy#16343 beschränkt automatisch gefundene Icons auf den Origin der endgültigen Seite und prüft Weiterleitungen, bevor deren Ziele abgerufen werden. Im Verlauf der Diskussion ergänzte hizawye eine Begrenzung der beim Seitenabruf gelesenen Daten, die Auflösung relativer Icon-Adressen anhand der endgültigen Seite und die Weitergabe von Zugangsdaten nur bei gleichem Schema, Hostnamen und effektivem Port. Für ausdrücklich vom Nutzer angegebene Icon-URLs bleibt das bisherige Verhalten bestehen.

omarchybot berichtete in omacom/omarchy#16343:issuecomment-6368320917 über eine Worker-Verifikation des zuletzt geprüften Head-Stands mit 26 gezielten Testfällen und einem echten IPv6-Server. Vorausgegangen war hizawye's Korrektur von Vergleichen, die IPv6-Klammern als Muster behandelt hatten. Eine Maintainer-Entscheidung über die rund 250 Zeilen zur URL-Verarbeitung und Überschneidungen mit anderen Icon-Änderungen steht weiterhin aus. Die Hostnamenprüfungen filtern keine privaten Adressen. Bei bewusst ausgeschlossenen CDN-Icons kann auf Google's Favicon zurückgegriffen werden.

06Untersuchung von Systemhängern findet nicht abgemeldeten Binder-Callback zur Speicherrückgewinnung

In omacom/omarchy#15950:issuecomment-6358826873 führte omarchybot die gemeldeten Hänger bei der Speicherrückgewinnung darauf zurück, dass ein außerhalb des Kernel-Quellbaums entwickeltes binder_linux-Modul nicht zusätzlich zur integrierten Binder-Implementierung des Kernels geladen werden konnte. Die Analyse fand einen Fehlerpfad, bei dem ein Callback zur Speicherrückgewinnung registriert bleibt, nachdem der Modulcode freigegeben wurde. Der Bot meldete drei Worker-Hänger nach dem Ladeversuch und keinen in drei Kontrollläufen ohne diesen Versuch, konnte jedoch den als 'Oops bezeichneten Fehlertext des Workers nicht erfassen.

hamedtareqhamed lieferte einen weiteren Absturzbericht, der die Firewall-Protokollierung betraf. omarchybot erläuterte, wie freigegebener Modulspeicher denselben Fehler in unterschiedlichen Netzwerkfunktionen sichtbar machen könnte. Anschließend berichtete jhnct in omacom/omarchy#15950:issuecomment-6371695054, dass die beobachteten Oops-Fehler nach dem Entfernen des Moduls ausblieben. Das Issue ist weiterhin offen. Die Untersuchung erklärte ausdrücklich nicht eine frühere Beobachtung unter Kernel 7.2.5-3.

07Vorschlag zur Fingerabdruckentfernung löscht zuerst den Leserspeicher und dann lokale Datensätze

scottjones eröffnete omacom/omarchy#16403, damit fprintd-delete ausgeführt wird, solange der Dienst und die lokalen Registrierungsdaten noch vorhanden sind. Der aktuelle Vorschlag betrifft Lesegeräte, die Fingerabdrücke auf dem Gerät speichern: Werden zuerst die lokalen Datensätze gelöscht, sind die Kopien auf dem Gerät unter Umständen nicht mehr erreichbar. Außerdem fordert der Ablauf vor Änderungen sudo-Rechte an und meldet Fehler beim Löschen auf dem Lesegerät, setzt die Entfernung aber fort.

omarchybot meldete erfolgreiche Softwareprüfungen und forderte anschließend Nachweise von echter Hardware an. scottjones testete die Reihenfolge der Entfernung auf einem M2 Max MacBook Pro und einem MacBook Neo und konnte danach denselben Finger erneut registrieren. In omacom/omarchy#16403:issuecomment-6370352605 unterschied omarchybot zwischen erfolgreicher Neuregistrierung und einem Nachweis der Löschung und fragte, ob bei einem der beiden Durchläufe eine Warnung aufgetreten sei. Der PR ist weiterhin offen. Die vorliegenden Ergebnisse belegen die getestete Reihenfolge und die anschließende Nutzbarkeit, aber keine bestätigte Löschung aus der Enklave.

08Wetterradar-Vorschlag ergänzt Wiedergabe für US-Standorte

wesleygrimes eröffnete omacom/omarchy#16406, um unter der Wettervorhersage die letzten zehn NEXRAD-Aufnahmen anzuzeigen, mit Wiedergabe, Navigation entlang der Zeitleiste und Zeitangaben im eingestellten Uhrzeitformat. Der Vorschlag aktiviert das Radar standardmäßig, blendet es außerhalb des NWS-Abdeckungsgebiets aus und stellt bei deaktiviertem Radar keine Radaranfragen. Beim Öffnen des aktivierten Panels werden gerundete Standortdaten an den Wetterdienst gesendet sowie Radar- und Kartenkacheln von den genannten Anbietern angefordert.

greptile-apps[bot] meldete in omacom/omarchy#16406:issuecomment-6366926786, dass die zuvor gefundenen Probleme mit Vorhersagen für benannte Orte und der Tastaturbedienung behoben seien. wesleygrimes berichtet von Prüfungen der gesamten Testsuite, der Themes und der Darstellung von rechts nach links. Die Funktion bleibt ein offener Vorschlag, der von einem weiteren PR abhängt; Radarunterstützung wurde damit noch nicht ausgeliefert.

09NOVA ergänzt Einrichtung von Programmierassistenten, Marketplace-Verifikation bleibt offen

Yangass berichtete im offenen Verifikationsantrag omacom/omarchy-plugin-marketplace#12377 über mehrere aufeinanderfolgende NOVA-Veröffentlichungen. Diese ergänzen eine zustimmungspflichtige Einrichtung eines OpenCode-Assistenten mit lokalem Modell sowie Profile für installierte Claude-Code-, Codex- und Antigravity-Launcher. NOVA erhält andere Profile, validiert Launcher und Projektordner und überlässt den Online-Werkzeugen die jeweilige Anmeldung.

Yangass meldete außerdem eine Anpassung an Ollama 0.40's Manifeststruktur, durch die zuvor gültige Modellinstallationen bei Revisionsprüfungen durchgefallen waren. Diese Angaben zu Veröffentlichungen und Testergebnissen stammen vom Autor. github-actions[bot] dokumentierte Quattro-Kompatibilität für die angefragte Zielversion 0.17.1, die zugrunde liegende Sicherheitsprüfung erfordert aber weiterhin ein manuelles Review. Der Marketplace-Snapshot bleibt bis zu einer erfolgreichen Veröffentlichung unverändert.

10Plug-Verifikation nach Review-Befund zur Zwischenablage zurückgezogen

weedwhitesandwine schloss den Verifikationsantrag für das Plug-Update und bat darum, den Marketplace-Eintrag zu entfernen. In omacom/omarchy-plugin-marketplace#12459:issuecomment-6358501211 akzeptierte der Autor den Befund zur Zwischenablage und erklärte, keine Zeit mehr zu haben, Plug auf dem in den Reviews geforderten Niveau zu pflegen. Damit sind der Rückzug und der Antrag auf Entfernung belegt, nicht jedoch eine bereits erfolgte Entfernung aus dem Marketplace.

Zum Hintergrund: Am 22. Oktober hatte HANCORE-linux bereits eine Korrektur der HTTP-Weiterleitung und der Prüfung des Peer-Eigentümers bestätigt. Zugleich wurde ein bearbeitbares natives Textfeld gefunden, dessen automatische Zwischenablageverarbeitung ein Datenangebot ohne Größenbegrenzung in die gemeinsam genutzte Shell einlesen konnte. Der Rückzug beendet diesen Verifikationsversuch, ohne den verbleibenden Befund als behoben darzustellen.