Se simplifican los controles de notificaciones mientras la migración del gestor de arranque de Mac llega a edge

01Las notificaciones vuelven a un sencillo interruptor de No molestar

dhh creó e integró dos cambios en quattro que eliminan el aplazamiento de notificaciones, la detección de pantalla compartida, el panel de notificaciones y sus preferencias. En omacom/omarchy#16429:issuecomment-6371608347, dhh explicó que la función no había alcanzado el nivel de calidad que consideraba aceptable. Son cambios en una rama de desarrollo, no el anuncio de una versión estable.

omacom/omarchy#16430 deja la campana como interruptor del modo No molestar. Las notificaciones siguen reglas fijas: aparecen en la pantalla que tiene el foco, dejan espacio a las ventanas a pantalla completa, conservan un día de historial con un máximo de 100 entradas y permiten que los códigos de verificación atraviesen el modo No molestar. El clic derecho descarta las tarjetas, mientras que Super+Shift+Alt+, sigue permitiendo volver a mostrar las notificaciones registradas.

02La migración del cargador de arranque de Mac llega a edge, pendiente de validación en hardware

maralcbr integró omacom/omarchy-pkgs#1513, de chriskearney, que pasa m1n1-aurora a una revisión fijada del código fuente de omacom/m1n1 y sustituye los paquetes derivados aura y m1n1-neo. github-actions[bot] informó en omacom/omarchy-pkgs#1513:issuecomment-6359746568 de que la versión 1.6.1.aurora20-3 ya estaba disponible en edge para aarch64. Se trata de una publicación en edge, no de una validación para rc o estable.

La revisión modificó la ruta de actualización antes de la integración. maralcbr pasó a una dependencia virtual de U-Boot para que las instalaciones existentes puedan conservar su proveedor, amplió la matriz de arranque de Stage 1 que se mantiene y comunicó que el cambio coordinado en el generador de imágenes ya se había integrado. Las actualizaciones habituales de paquetes modifican Stage 2 sin registrar un nuevo Stage 1.

scottjones informó de una migración correcta de paquetes en un sistema raíz creado desde cero, pero señaló fallos de pantalla en un M3 Air con cifrado y una posible dificultad con la reubicación de Stage 1 en omacom/omarchy-pkgs#1513:pullrequestreview-5624139147. La propuesta mantiene pendiente la validación en hardware de ese paquete concreto; una compilación correcta y su publicación en edge no acreditan esos resultados de arranque en frío.

03La integración continua del instalador se amplía a diez variantes de instalación

emirb integró omacom/omarchy-iso#238 en la rama de desarrollo F1, f1/17-receive-path-archinstall-45. El proceso genera la ISO una sola vez y la distribuye entre diez variantes x86_64 que cubren cifrado, teclados británicos, discos pequeños, poca memoria, BIOS, imágenes unificadas del kernel y un medio de instalación lento. Las variantes predeterminada y cifrada ejecutan todos los escenarios de integración.

El cambio lleva a la integración continua una cobertura que antes se ejecutaba en una estación de trabajo. Los fallos conocidos del restablecimiento de fábrica siguen siendo visibles y solo se admiten si coinciden con el texto exacto de una aserción y tienen una fecha de caducidad. greptile-apps[bot] también señaló en omacom/omarchy-iso#238:discussion_r4359256431 un problema de limpieza del entorno local de pruebas: si falla el arranque de una máquina virtual con keep-running, pueden quedar activos servidores PCI simulados. La revisión aportada consideró que este hallazgo no impedía continuar.

04La instalación mediante una imagen raíz pregenerada sigue en revisión

La propuesta abierta omacom/omarchy-iso#216, de emirb, instalaría una imagen raíz pregenerada y añadiría paquetes específicos de la máquina, en lugar de extraer unos 940 paquetes durante la instalación. La propuesta de integración reconoce a hegjon el diseño de la imagen raíz. En omacom/omarchy-iso#216:issuecomment-6364126768, github-actions[bot] informó de instalaciones correctas en máquinas virtuales de 41.6 segundos en x86_64 y 23.8 segundos en aarch64, con tiempos de generación de la ISO más largos.

hegjon publicó una revisión automatizada con comprobaciones manuales puntuales de algunos hallazgos, entre ellos la inicialización de la identidad de la máquina, imágenes adicionales de arranque del kernel y la gestión de la alternativa cuando falla la reducción de tamaño. Más tarde, greptile-apps[bot] señaló en omacom/omarchy-iso#216:discussion_r4359565646 que una consulta del número de paquetes seguía solicitando linux estándar en lugar del kernel de la imagen seleccionada. Son hallazgos de revisión correspondientes a revisiones concretas del código; el informe de éxito en máquinas virtuales no demuestra que se hayan resuelto todos los problemas. La PR de integración sigue abierta.

05La protección de iconos de aplicaciones web avanza con correcciones de redirecciones e IPv6

La propuesta abierta omacom/omarchy#16343, de hizawye, restringe los iconos descubiertos automáticamente al origen de la página final y comprueba las redirecciones antes de solicitar sus destinos. Durante la discusión, hizawye añadió límites a la lectura de páginas, la resolución de iconos respecto a la página final y la conservación de credenciales únicamente cuando coinciden el esquema, el nombre de host y el puerto efectivo. Las URL de iconos proporcionadas expresamente por el usuario conservan su comportamiento actual.

omarchybot comunicó en omacom/omarchy#16343:issuecomment-6368320917 la verificación por un agente ejecutor de la última revisión examinada, que incluyó 26 casos específicos y un servidor IPv6 real. Esto ocurrió después de que hizawye corrigiera comparaciones que habían tratado los corchetes de IPv6 como patrones. La propuesta sigue a la espera de una decisión de los mantenedores sobre unas 250 líneas de gestión de URL y su solapamiento con otros cambios en los iconos. Las comprobaciones de nombres de host no filtran direcciones privadas, y los iconos de CDN excluidos deliberadamente pueden sustituirse por el favicon de Google.

06La investigación de los bloqueos identifica una función de recuperación de memoria de binder que queda registrada indebidamente

En omacom/omarchy#15950:issuecomment-6358826873, omarchybot atribuyó los bloqueos notificados durante la recuperación de memoria a un módulo externo binder_linux que no lograba cargarse junto al binder integrado en el kernel. Su análisis encontró una ruta de error que deja registrada una función de devolución de llamada para recuperar memoria después de liberar el código del módulo. El bot informó de tres bloqueos del agente ejecutor tras intentar cargarlo y de ninguno en tres ejecuciones de control sin ese intento, aunque no pudo capturar el texto del oops del agente.

hamedtareqhamed aportó otro informe de fallo relacionado con el registro del cortafuegos. omarchybot explicó cómo la memoria liberada del módulo podía hacer que el mismo defecto se manifestara en distintas funciones de red. Posteriormente, jhnct informó en omacom/omarchy#15950:issuecomment-6371695054 de que eliminar el módulo había detenido los oops observados. La incidencia sigue abierta y la investigación dejó expresamente sin explicar un caso anterior en el kernel 7.2.5-3.

07Una propuesta para eliminar huellas borra primero el almacenamiento del lector y después los registros locales

scottjones abrió omacom/omarchy#16403 para ejecutar fprintd-delete mientras aún existen el servicio y los registros locales de inscripción. La propuesta actual aborda los lectores que almacenan las huellas en el propio dispositivo: borrar primero los registros locales puede dejar inaccesibles las copias del dispositivo. También solicita sudo antes de realizar cambios e informa de los fallos al borrar huellas del lector mientras continúa con la desinstalación.

omarchybot informó de que las comprobaciones de software habían pasado y después solicitó pruebas en hardware. scottjones probó el orden de eliminación en un MacBook Pro M2 Max y un MacBook Neo, y pudo volver a registrar el mismo dedo. En omacom/omarchy#16403:issuecomment-6370352605, omarchybot distinguió entre un registro posterior correcto y una prueba de borrado, y preguntó si alguna de las dos ejecuciones había mostrado una advertencia. La PR sigue abierta; los resultados aportados acreditan el orden probado y la posibilidad de seguir usando el lector, pero no confirman el borrado del enclave.

08Una propuesta de radar meteorológico añade reproducción para ubicaciones de Estados Unidos

wesleygrimes abrió omacom/omarchy#16406 para mostrar los diez últimos barridos de NEXRAD debajo de la previsión meteorológica, con reproducción, desplazamiento por la secuencia y horas que respetan el formato del reloj. La propuesta activa el radar de forma predeterminada, lo oculta fuera de la cobertura del NWS y no realiza solicitudes de radar cuando está desactivado. Al abrir el panel con el radar activado, se envía información de ubicación redondeada al servicio meteorológico y se solicitan teselas de radar y mapas a los proveedores indicados.

greptile-apps[bot] informó en omacom/omarchy#16406:issuecomment-6366926786 de que se habían corregido los problemas señalados anteriormente en la previsión para ubicaciones identificadas por nombre y en el acceso mediante teclado. wesleygrimes comunica comprobaciones de la batería completa de pruebas, los temas y la presentación de derecha a izquierda. La función sigue siendo una propuesta abierta que depende de otra PR, no una prestación de radar ya publicada.

09NOVA añade la configuración de asistentes de programación mientras sigue abierta la verificación del marketplace

Yangass informó de sucesivas versiones de NOVA en la solicitud de verificación abierta omacom/omarchy-plugin-marketplace#12377. Estas añaden una configuración sujeta a aprobación para un asistente OpenCode con un modelo local, además de perfiles para los lanzadores instalados de Claude Code, Codex y Antigravity. NOVA conserva los demás perfiles, valida los lanzadores y las carpetas de proyectos, y deja que las herramientas en línea gestionen su propio inicio de sesión.

Yangass también informó de una corrección para la estructura de los manifiestos de Ollama 0.40, que había provocado que instalaciones válidas de modelos no superaran las comprobaciones de revisión. Estos resultados de versiones y pruebas son informes del autor. github-actions[bot] registró compatibilidad con Quattro para la versión objetivo solicitada, 0.17.1, pero los requisitos básicos de seguridad siguen necesitando una revisión manual. La instantánea del marketplace no cambiará hasta que la publicación se complete correctamente.

10Se retira la verificación de Plug tras un hallazgo sobre el portapapeles

weedwhitesandwine cerró la solicitud de verificación de la actualización de Plug y pidió que se retirara su ficha del marketplace. En omacom/omarchy-plugin-marketplace#12459:issuecomment-6358501211, el autor aceptó el hallazgo sobre el portapapeles y explicó que ya no tenía tiempo para mantener Plug al nivel que exigían las revisiones. Esto acredita la retirada de la solicitud y la petición de eliminar la ficha, no que esta ya se haya eliminado.

Como antecedente, el 22 de octubre, HANCORE-linux había confirmado las correcciones anteriores de una redirección HTTP y de la comprobación del propietario del proceso remoto, pero había identificado un campo de texto nativo editable cuya gestión automática del portapapeles podía leer una oferta de datos sin límite de tamaño en el shell compartido. La retirada pone fin a este intento de verificación sin dar por corregido ese hallazgo pendiente.