Les commandes de notification se simplifient tandis que la migration du chargeur de démarrage des Mac arrive sur edge

01Les notifications reviennent à un simple interrupteur Ne pas déranger

dhh a rédigé et fusionné deux modifications dans quattro qui suppriment le report des notifications, la détection du partage d’écran, le panneau de notifications et ses préférences. Dans omacom/omarchy#16429:issuecomment-6371608347, dhh a expliqué que la fonctionnalité n’avait pas atteint le niveau de qualité qu’il jugeait suffisant. Il s’agit de modifications sur une branche de développement, et non de l’annonce d’une version stable.

Avec omacom/omarchy#16430, la cloche sert simplement à activer ou désactiver le mode Ne pas déranger. Les notifications suivent des règles fixes : elles apparaissent sur l’écran actif, s’effacent devant les fenêtres en plein écran, conservent une journée d’historique dans la limite de 100 entrées et laissent passer les codes de vérification même en mode Ne pas déranger. Un clic droit ferme les cartes, tandis que Super+Shift+Alt+, permet toujours de réafficher les notifications enregistrées.

02La migration du chargeur de démarrage des Mac arrive sur edge, en attendant la validation matérielle

maralcbr a fusionné la proposition omacom/omarchy-pkgs#1513 de chriskearney, faisant passer m1n1-aurora à une révision figée du code source d'omacom/m1n1 et remplaçant les paquets en aval aura et m1n1-neo. github-actions[bot] a signalé dans omacom/omarchy-pkgs#1513:issuecomment-6359746568 que la version 1.6.1.aurora20-3 était disponible sur edge pour aarch64. Il s’agit d’une publication sur edge, et non d’une validation pour rc ou stable.

La revue a modifié le parcours de mise à niveau avant la fusion. maralcbr a adopté une dépendance virtuelle à U-Boot pour que les installations existantes puissent conserver leur fournisseur, élargi la matrice de démarrage Stage 1 maintenue et indiqué que le changement coordonné du générateur d’images avait été intégré. Les mises à jour ordinaires des paquets modifient Stage 2 sans enregistrer de nouveau Stage 1.

scottjones a signalé une migration réussie des paquets sur une racine système créée de toutes pièces, mais a soulevé des problèmes d’affichage sur des M3 Air avec chiffrement ainsi qu’une inquiétude concernant le déplacement de Stage 1 dans omacom/omarchy-pkgs#1513:pullrequestreview-5624139147. La proposition indique que la validation matérielle de ce paquet précis reste à effectuer ; une compilation réussie et une publication sur edge ne permettent pas de conclure quant à ces démarrages à froid.

03La CI de l’installateur s’étend à dix variantes d’installation

emirb a fusionné omacom/omarchy-iso#238 dans la branche de développement F1 f1/17-receive-path-archinstall-45. Le dispositif construit l’ISO une seule fois, puis le distribue à dix variantes x86_64 couvrant le chiffrement, les claviers britanniques, les petits disques, la mémoire limitée, le BIOS, les images de noyau unifiées et un support d’installation lent. Les variantes par défaut et chiffrée exécutent l’ensemble des scénarios d’intégration.

Ce changement transfère dans la CI des tests auparavant exécutés sur un poste de travail. Les échecs connus de réinitialisation d’usine restent visibles et ne sont tolérés que si le texte de l’assertion correspond exactement, avec une date d’expiration. greptile-apps[bot] a également signalé dans omacom/omarchy-iso#238:discussion_r4359256431 un problème de nettoyage du banc de test local : un échec de lancement de VM avec keep-running peut laisser fonctionner les faux serveurs PCI. La revue fournie considérait ce point comme non bloquant.

04L’installation à partir d’une image racine préconstruite reste en cours de revue

La proposition omacom/omarchy-iso#216 de emirb, toujours ouverte, installerait une image racine préconstruite, puis ajouterait les paquets propres à la machine, au lieu d'extraire environ 940 paquets pendant l’installation. La proposition d’intégration attribue la conception de l’image racine à hegjon. Dans omacom/omarchy-iso#216:issuecomment-6364126768, github-actions[bot] a fait état d'installations réussies en VM en 41.6 secondes sur x86_64 et en 23.8 secondes sur aarch64, avec des temps de construction de l’ISO plus longs.

hegjon a publié une revue automatisée dont certaines observations ont été vérifiées ponctuellement à la main, notamment sur l’initialisation de l’identité de la machine, les images de démarrage de noyaux supplémentaires et la gestion du repli en cas d’échec de réduction. Plus tard, greptile-apps[bot] a signalé dans omacom/omarchy-iso#216:discussion_r4359565646 qu’une recherche du nombre de paquets demandait encore le paquet linux standard plutôt que le noyau de l’image sélectionnée. Ces observations portent sur des révisions précises ; le compte rendu d’installations réussies en VM ne prouve pas que tous les points soulevés ont été résolus. La PR d’intégration reste ouverte.

05La protection des icônes d’applications web progresse avec des correctifs pour les redirections et IPv6

La proposition omacom/omarchy#16343 de hizawye, toujours ouverte, limite les icônes découvertes automatiquement à l’origine de la page finale et vérifie les redirections avant d'envoyer des requêtes vers leurs destinations. Au fil de la discussion, hizawye a ajouté une limite au volume de données lues sur les pages, la résolution des adresses d’icônes par rapport à la page finale et la conservation des identifiants uniquement lorsque le schéma, le nom d’hôte et le port effectif restent identiques. Les URL d’icônes explicitement fournies par l’utilisateur conservent leur comportement actuel.

Dans omacom/omarchy#16343:issuecomment-6368320917, omarchybot a fait état d'une vérification par un agent de la dernière révision examinée, comprenant 26 cas ciblés et un véritable serveur IPv6. Cette vérification faisait suite au correctif de hizawye sur des comparaisons qui interprétaient les crochets des adresses IPv6 comme des motifs. La proposition attend toujours une décision des responsables de maintenance concernant environ 250 lignes de traitement des URL et leur recoupement avec d’autres changements relatifs aux icônes. Ses contrôles de noms d’hôte ne constituent pas un filtrage des adresses privées, et les icônes de CDN volontairement exclues peuvent être remplacées par la favicon fournie par Google.

06L’enquête sur les blocages identifie un rappel de récupération mémoire de binder resté enregistré

Dans omacom/omarchy#15950:issuecomment-6358826873, omarchybot a attribué les blocages signalés lors de la récupération mémoire à un module binder_linux externe au noyau qui échouait à se charger aux côtés du binder intégré au noyau. Son analyse a identifié un chemin d'erreur laissant un rappel de récupération mémoire enregistré après la libération du code du module. Le bot a signalé trois blocages de l’agent après la tentative de chargement, contre aucun lors de trois essais témoins sans ce chargement, sans toutefois parvenir à capturer le texte de l'oops de l’agent.

hamedtareqhamed a fourni un autre rapport de plantage impliquant la journalisation du pare-feu. omarchybot a expliqué comment la mémoire libérée du module pouvait faire apparaître le même défaut dans différentes fonctions réseau. jhnct a ensuite indiqué dans omacom/omarchy#15950:issuecomment-6371695054 que la suppression du module avait mis fin aux oops observés. Le ticket reste ouvert, et l’enquête précise qu’elle n’explique pas un signalement antérieur sur le noyau 7.2.5-3.

07La proposition de suppression des empreintes efface le stockage du lecteur avant les enregistrements locaux

scottjones a ouvert omacom/omarchy#16403 pour exécuter fprintd-delete tant que le service et les enregistrements locaux des empreintes existent encore. La proposition actuelle vise les lecteurs qui stockent les empreintes sur l’appareil : supprimer d’abord les enregistrements locaux peut rendre leurs copies sur l’appareil inaccessibles. Elle demande aussi l’autorisation sudo avant toute modification et signale les échecs d’effacement sur le lecteur tout en poursuivant la suppression.

omarchybot a signalé la réussite des vérifications logicielles, puis demandé des éléments de validation sur du matériel réel. scottjones a testé l’ordre de suppression sur un MacBook Pro M2 Max et un MacBook Neo, puis a réussi à enregistrer de nouveau le même doigt. Dans omacom/omarchy#16403:issuecomment-6370352605, omarchybot a distingué la réussite de ce nouvel enregistrement d’une preuve de suppression et demandé si un avertissement était apparu lors de l’un ou l’autre essai. La PR reste ouverte ; les résultats fournis attestent l’ordre testé et la possibilité d’utiliser ensuite le lecteur, mais ne confirment pas l’effacement dans l’enclave.

08Une proposition de radar météo ajoute la lecture animée pour les lieux situés aux États-Unis

wesleygrimes a ouvert omacom/omarchy#16406 pour afficher les dix derniers relevés NEXRAD sous les prévisions météo, avec lecture animée, navigation dans la séquence et horaires respectant le format de l’horloge. La proposition active le radar par défaut, le masque hors de la couverture du NWS et n’effectue aucune requête radar lorsqu’il est désactivé. L’ouverture du panneau lorsque le radar est activé transmet des coordonnées arrondies au service météo et demande des tuiles radar et cartographiques aux fournisseurs indiqués.

greptile-apps[bot] a indiqué dans omacom/omarchy#16406:issuecomment-6366926786 que les problèmes précédemment relevés concernant les prévisions pour les lieux désignés par leur nom et l’accès au clavier avaient été corrigés. wesleygrimes fait état de vérifications de la suite de tests complète, des thèmes et de l’affichage de droite à gauche. La fonctionnalité reste une proposition ouverte dépendant d’une autre PR ; la prise en charge du radar n’est pas encore livrée.

09NOVA ajoute la configuration d’assistants de programmation, tandis que sa vérification pour la place de marché reste ouverte

Yangass a annoncé plusieurs versions successives de NOVA dans la demande de vérification omacom/omarchy-plugin-marketplace#12377, toujours ouverte. Elles ajoutent une configuration soumise à approbation pour un assistant OpenCode utilisant un modèle local, ainsi que des profils pour les lanceurs Claude Code, Codex et Antigravity installés. NOVA préserve les autres profils, valide les lanceurs et les dossiers de projet, et laisse les outils en ligne gérer leur propre connexion.

Yangass a également signalé un correctif lié à l'organisation du manifeste dans Ollama 0.40, qui faisait échouer les contrôles de révision pour des installations de modèles pourtant valides. Ces informations sur les versions et les résultats des tests proviennent de l'auteur. github-actions[bot] a enregistré la compatibilité avec Quattro pour la version cible demandée, 0.17.1, mais le socle de sécurité nécessite toujours une revue manuelle. L’état publié sur la place de marché reste inchangé tant que la publication n’a pas abouti.

10La demande de vérification de Plug est retirée après un problème relevé dans la gestion du presse-papiers

weedwhitesandwine a fermé la demande de vérification de la mise à jour de Plug et demandé le retrait de sa fiche de la place de marché. Dans omacom/omarchy-plugin-marketplace#12459:issuecomment-6358501211, l’auteur a reconnu le problème lié au presse-papiers et expliqué ne plus avoir le temps de maintenir Plug au niveau exigé par les revues. Cela confirme le retrait de la demande de vérification et une demande de suppression de la fiche, mais pas une suppression effective.

Pour rappel, le 22 octobre, HANCORE-linux avait confirmé un correctif antérieur concernant les redirections HTTP et le propriétaire du pair, mais avait identifié un champ de texte natif modifiable dont la gestion automatique du presse-papiers pouvait lire une offre de données sans limite de taille dans le shell partagé. Le retrait met fin à cette tentative de vérification sans présenter ce dernier problème comme résolu.