DHH abre en persona una solicitud para estabilizar el ícono de wifi, la comunidad documenta cinco fallas nuevas en el escritorio Quickshell, y Linus Torvalds fusiona ocho ramas etiquetadas rc6 sin publicar aún la etiqueta pública del kernel.
David Heinemeier Hansson abrió este sábado una solicitud propia que detiene el parpadeo del ícono de wifi en redes con transición OWE, con una revisión automatizada que la califica segura de fusionar pero de riesgo medio.
David Heinemeier Hansson, fundador de Omarchy, abrió este sábado 3 de octubre de 2026 la solicitud de incorporación de cambios #14133 en el repositorio omacom/omarchy en GitHub, sin fusionar al cierre de esta edición. La solicitud corrige que el ícono de wifi de la barra alterne entre el glifo de desconexión y las barras de señal en cada ciclo de escaneo dentro de una red con modo de transición OWE -un SSID abierto emparejado con un gemelo oculto _owetm_ en el mismo BSSID-, aunque la conexión nunca se cae, según la propia solicitud. La causa, de acuerdo con DHH, es que NetworkManager reporta el punto de acceso bajo el SSID oculto, lo que hace que el perfil visible desaparezca de la lista de conexiones disponibles y que la variable connectedWifiNetwork quede en null entre un escaneo y el siguiente. La corrección, de dos commits, cambia tres cosas: basa la verificación de conectividad de wifi en el estado del dispositivo de red en lugar del SSID visible, mantiene el tipo de conexión como "wifi" cuando el dispositivo está conectado aunque ninguna red aparezca en la lista, y consulta la intensidad de señal del punto de acceso en uso mediante nmcli sin forzar un nuevo escaneo, según la propia solicitud, que incluye una prueba nueva de shell que simula el parpadeo del escaneo y una comparación en vivo de 90 segundos. La revisión automatizada del bot greptile-apps calificó el cambio de riesgo medio pero lo marcó seguro de fusionar, con una confianza de 5 sobre 5 y sin observaciones pendientes, sobre una suite de 4.069 pruebas que pasaron sin fallos, de acuerdo con la misma revisión. La solicitud no tenía mantenedor adicional asignado ni fecha de fusión al cierre de esta edición, y la información proviene únicamente del propio repositorio, sin cobertura cruzada de otro medio especializado. Costa Rica no tiene cifras públicas de usuarios de Omarchy que se conecten a redes OWE -comunes en aeropuertos y cafés que ofrecen wifi abierto con cifrado oportunista-, pero cualquier persona tica en esa situación debería notar el ícono estable recién cuando esta solicitud se fusione.
cat /feed/omarchyactualizaciones.md
El usuario ferpa documentó este viernes que el script que reinicia el escritorio de Omarchy durante una actualización da por terminado al proceso viejo a los cinco segundos exactos, aunque tarde más en cerrar, y deja la sesión sin barra.
> El usuario ferpa abrió este viernes 2 de octubre de 2026 el reporte #14085 en el repositorio omacom/omarchy en GitHub, sin corrección fusionada al cierre de esta edición. El reporte documenta que, durante omarchy update, la barra superior del escritorio Quickshell puede desaparecer por completo porque el script omarchy-restart-shell espera apenas cinco segundos a que el proceso viejo confirme su salida por IPC antes de lanzar el reemplazo; si el cierre tarda más -como le ocurrió al propio ferpa, cuyo registro muestra la solicitud de salida a las 16:05:17 y el fallo del proceso nuevo exactamente cinco segundos después, a las 16:05:22-, el reemplazo choca con la instancia anterior, que todavía no liberó su candado de instancia única, recibe el error "ya hay una instancia en ejecución" y termina sin dejar ningún proceso de barra activo, según el propio reporte. El equipo de ferpa corre Omarchy 4.0.4-1, quickshell 0.3.1-1 y Hyprland 0.56.2-2 sobre un Ryzen 9 5900HX con una RTX 3060 Mobile.
> El reporte describe una falla distinta, aunque de la misma familia, a la que esta sección documentó ayer en los reportes #14013, #14012 y #14014 sobre los comandos update, restart y debug de Omarchy: aquellos señalaban que el candado de instancia única nunca avisa su liberación al supervisor y que la verificación de arranque del escritorio esperaba sólo dos segundos, mientras que el reporte de hoy señala que el propio script de reinicio deja de esperar la salida del proceso viejo a los cinco segundos, sin reintentar ni confirmar que el candado quedó libre. La solicitud #14021, que el colaborador AnPod abrió ayer para alargar la ventana de verificación de arranque, no toca este temporizador de salida, según la propia solicitud, por lo que no hay indicio de que resuelva el caso de ferpa.
> Ni el reporte #14085 ni ninguna solicitud de corrección que lo referencie de forma explícita aparecían al cierre de esta edición, según el propio repositorio, y la información proviene únicamente de esa fuente. Costa Rica no tiene cifras públicas de personas que administren equipos con Omarchy para terceros, pero cualquier desarrollador tico que dependa de la barra de Quickshell para abrir aplicaciones o revisar notificaciones debería esperar unos segundos adicionales -o reiniciar el escritorio a mano- después de cada actualización antes de asumir que el sistema quedó roto.
El historial de cambios de torvalds/linux muestra a Linus Torvalds integrando desde el jueves al menos ocho ramas de subsistemas etiquetadas para la sexta candidata del ciclo 7.3, aunque la etiqueta v7.3-rc6 en sí seguía sin aparecer este sábado.
El historial de cambios del repositorio torvalds/linux en GitHub, consultado por esta sección la mañana de este sábado 3 de octubre de 2026, muestra que Linus Torvalds fusionó entre el miércoles 1 y el sábado 3 de octubre al menos ocho ramas de mantenedores de subsistemas que ya llevan en su propio nombre la referencia a la sexta candidata del ciclo 7.3 -entre ellas 'cifs-fixes-7.3-rc6', 'sound-7.3-rc6', 'random-7.3-rc6-for-linus', 'for-next-tpm-v7.3-rc6' y 'pm-7.3-rc6'-, según los propios mensajes de fusión. La lista de etiquetas del mismo repositorio, revisada por separado, sigue mostrando v7.3-rc5 -publicada el domingo 27 de setiembre- como la referencia pública más reciente del ciclo, sin que v7.3-rc6 apareciera todavía ni en la lista de etiquetas ni en la de lanzamientos al cierre de esta edición. La combinación de ambos datos indica que Torvalds ya está reuniendo el material de la sexta candidata -tal como lo hicieron antes los mantenedores de sonido, aleatoriedad del núcleo (random), TPM y gestión de energía, cada uno con su propia rama nombrada rc6- sin haber publicado todavía la etiqueta pública que marca el corte oficial de esa candidata, un paso que normalmente ocurre horas o un día después de que termina de fusionar ese material, según el patrón que esta sección documentó en ciclos anteriores. Con el sábado ya transcurrido, la candidata rc5 cumple seis días sin sucesora pública, un día más que el margen de dos días que esta sección proyectó ayer sobre una cadencia semanal estricta. La fecha del lanzamiento estable de la versión 7.3 sigue en disputa entre el 18 y el 25 de octubre, sin que ninguna fuente consultada hoy permita despejar cuál de las dos prevalece. Costa Rica no tiene mantenedores identificados en el equipo de desarrollo del kernel, y el efecto de este atraso sobre los usuarios ticos es, en la práctica, nulo mientras las distribuciones que sí usan a diario -como Ubuntu, que esta semana corrigió más de 120 CVE en kernels de ciclos anteriores- no adopten el ciclo 7.3 en una futura versión de soporte extendido.
El usuario Jeffe747 abrió este sábado 3 de octubre de 2026 el reporte #14136 en el repositorio omacom/omarchy en GitHub, sin corrección ni mantenedor asignado al cierre de esta edición. El reporte documenta que, al reactivar una MacBook Air desde suspensión, el cliente de bloqueo de sesión de Quickshell termina con el código de salida 137 -la señal SIGKILL-, lo que hace que Hyprland active por su cuenta la pantalla de bloqueo de emergencia ("lockdead") durante tres o cuatro segundos, antes de que el supervisor de Omarchy detecte el bloqueo huérfano, vuelva a lanzar Quickshell y restaure la sesión con normalidad, según el propio reporte, que incluye registros de journalctl con la secuencia completa. El equipo de Jeffe747 corre Hyprland 0.56.2 sobre el kernel Linux 7.2.5. La causa, según el reporte, es que el cliente de bloqueo se cae durante una ráfaga de actualizaciones de propiedades por D-Bus que NetworkManager dispara justo después de despertar, mientras enumera los puntos de acceso de wifi disponibles; esa ráfaga llega antes de que el cliente de bloqueo termine de inicializarse tras la suspensión, y el proceso muere en lugar de absorber las actualizaciones. El efecto visible -una pantalla de emergencia que aparece y desaparece sola en cada despertar- puede hacer pensar a quien lo sufre que el equipo se congeló, aunque el sistema se recupera solo en unos segundos, según el propio reporte. El reporte no tenía al cierre de esta edición ninguna solicitud de corrección que lo referenciara, y la información proviene únicamente de esa fuente, sin confirmación cruzada de otro medio especializado. Costa Rica no tiene cifras públicas de usuarios de Omarchy en equipos portátiles que suspendan y reactiven con frecuencia -el patrón típico de quien trabaja en varios espacios durante el día-, pero cualquier persona tica en esa situación puede ignorar con tranquilidad la pantalla de emergencia si desaparece por sí sola en pocos segundos.
— El usuario Jeffe747 documentó este sábado que el cliente de bloqueo de Quickshell termina con la señal SIGKILL al reactivar una MacBook Air desde suspensión, lo que deja ver durante segundos la pantalla de emergencia de Hyprland.
El usuario RB211 abrió este sábado 3 de octubre de 2026 el reporte #14106 en el repositorio omacom/omarchy en GitHub, sin corrección fusionada al cierre de esta edición. El reporte documenta que el shell de Omarchy se cae con una falla de segmentación (SIGSEGV) dentro de la librería libQt6QmlModels.so.6, en la función QQuickRepeater::setModel, cada vez que el panel de audio reconstruye su lista de dispositivos tras una señal de PipeWire que retira un nodo -por ejemplo, cuando un par de auriculares Bluetooth se desconecta durante una llamada o termina una transmisión-, según el propio reporte. El equipo de RB211 corre Omarchy 4.0.4 con quickshell 0.3.1, PipeWire 1.6.8 y Qt 6.11.2. La causa, de acuerdo con el reporte, combina dos problemas: el archivo Model.js del panel se vuelve a evaluar en cada contexto de delegado sin la directiva .pragma library, y esa reevaluación revisa primero "typeof module" antes de encontrarse con un objeto modelData que ya quedó en null, lo que termina en una llamada a la tabla de métodos de un puntero nulo. La función refreshDisplayAudioModels() del panel toma una foto de los punteros de los nodos activos, pero un nodo puede destruirse después de esa foto y antes -o durante- que el componente visual termine de dibujarse, según el propio reporte, que propone tres salidas posibles: guardar datos simples (id, nombre, volumen, mudo) en lugar de los objetos de nodo en vivo, agregar la directiva .pragma library o quitar la revisión de "typeof module", y filtrar las entradas nulas antes de pasarlas al componente que las dibuja. Ninguna de las tres salidas propuestas tenía solicitud de corrección abierta al cierre de esta edición, según el propio repositorio, y la información proviene únicamente de esa fuente. Costa Rica no tiene cifras públicas de usuarios de Omarchy con auriculares Bluetooth, pero en centros de llamadas y puestos de trabajo remoto ticos donde esos dispositivos se conectan y desconectan varias veces al día, cualquier persona en esa situación puede ver cómo se le cierra el escritorio completo a media jornada.
El desarrollador Olinkan abrió este sábado 3 de octubre de 2026 el reporte #14101 en el repositorio omacom/omarchy en GitHub, sin corrección fusionada al cierre de esta edición. El reporte documenta que un widget de la barra que ofrece su propio servicio deja de funcionar -el botón no responde a los clics- en cualquier barra clonada o de terceros, aunque la barra oficial omarchy.bar sí funciona: "un widget de la barra alcanza su servicio a través de bar.shell, y bar.shell es el alcance del complemento de la barra, no el del widget", escribió Olinkan en el propio reporte. La causa, según el mismo reporte, es que el sistema inyecta a cada panel su propio alcance de complemento al cargarlo, pero a los widgets de la barra sólo les entrega el alcance de la barra, y la verificación de identidad que hace pluginOwnsTarget() en la API de barras clonadas rechaza la búsqueda del widget por su propio servicio porque llega a través del alcance ajeno de la barra. El mismo sábado, el desarrollador crazybadger abrió por separado el reporte #14130, que documenta que el script omarchy-theme-set-browser-policy reescribe el archivo color.json de forma no atómica: usa install -T, que primero borra el archivo de destino y después crea y llena uno nuevo, lo que deja una ventana breve en la que el archivo de política está ausente o incompleto. Los procesos del navegador que vigilan esa carpeta de política por inotify ven el archivo desaparecer y reaparecer en cada cambio de tema, y crazybadger reporta tres caídas de Chrome que coincidieron con cambios de tema, aunque aclara que la causa no está confirmada por haber otros cambios simultáneos; la salida que propone es reemplazar install por mv después de preparar el archivo temporal en la misma carpeta de destino, para que rename(2) se ejecute de forma atómica. Ambos reportes señalan, con argumentos técnicos distintos, la misma clase de problema: decisiones de la reescritura "Quattro" del escritorio -el cambio de arquitectura de agosto que unificó barra, lanzador, menús y notificaciones en un solo proceso de Quickshell- que todavía no resuelven de forma consistente cómo un componente individual accede a su propio servicio o a su propio archivo de configuración sin pisar a otro. Ninguno de los dos reportes tenía mantenedor asignado ni solicitud de corrección vinculada al cierre de esta edición, y la información proviene únicamente de esas dos fuentes primarias. Costa Rica no tiene impacto local conocido al cierre de esta edición, salvo para quienes ya personalizan Omarchy con barras propias o automatizan cambios de tema, un grupo reducido dentro de la comunidad tica de software libre.
El usuario roonakyadav abrió este sábado 3 de octubre de 2026 la propuesta #14131 en el repositorio omacom/omarchy en GitHub, sin reacción de ningún mantenedor ni etiqueta asignada al cierre de esta edición. La propuesta señala que, al activar la visibilidad de archivos ocultos en GNOME Files (Nautilus 50 o superior), carpetas de configuración esenciales del sistema quedan expuestas, y que presionar Suprimir las manda directo a la papelera sin ninguna confirmación: "al presionar Suprimir, las carpetas van directo a la papelera sin ninguna confirmación, y eso puede dejar la sesión inestable de inmediato", escribió roonakyadav, quien advierte que el daño no siempre se puede revertir con la función de deshacer del propio gestor de archivos. La solución que propone roonakyadav es un servicio en segundo plano, sin interfaz propia, que vigile la papelera mediante inotify, proteja rutas como ~/.config, ~/.local/share, ~/.ssh y ~/.gnupg, restaure de forma automática cualquiera de esas carpetas si termina en la papelera -antes de que algún proceso en segundo plano se caiga por no encontrarlas-, avise a la persona de lo ocurrido, y permita el borrado intencional cuando de verdad se necesite, sin afectar el borrado de archivos y documentos comunes, según la propia propuesta. La propuesta no tenía al cierre de esta edición ninguna solicitud de incorporación de cambios que la implementara, y la información proviene únicamente de esa fuente, sin confirmación cruzada de otro medio especializado. Costa Rica no tiene cifras públicas de personas que empiecen en Linux u Omarchy a través de bootcamps o cursos técnicos locales, pero cualquier persona tica nueva en el sistema que active los archivos ocultos para "ver qué hay" en su carpeta personal queda, hoy, expuesta exactamente al riesgo que esta propuesta busca evitar.
— El usuario roonakyadav propuso este sábado un servicio que restaure de forma automática carpetas como ~/.config, ~/.ssh y ~/.gnupg si un gestor de archivos las manda a la papelera por error, al mostrar los archivos ocultos.
El usuario HerrStolzier abrió este sábado 3 de octubre de 2026 la solicitud #14129 en el repositorio omacom/omarchy en GitHub, que corrige que las habilidades (skills) empaquetadas para agentes de IA instruyan ejecutar "omarchy debug --no-sudo --print", una forma con espacio que no es un subcomando real y termina con el código de salida 127; el binario correcto es omarchy-debug, con guion, ubicado en /usr/bin/omarchy-debug, según la propia solicitud, que corrige la documentación de la habilidad empaquetada de Omarchy, la guía de contribución, la habilidad de reporte de fallas y el manual de línea de comandos, y que hace referencia a los reportes previos #13702 y #12629, donde otros usuarios ya habían señalado el mismo error de documentación. El mismo sábado, el usuario Ashwinhegde19 abrió el reporte #14134, que documenta que los archivos manual/31-dotfiles.md y default/agents/skills/omarchy/hooks.md describen mal cuándo expira el permiso de sudo durante una actualización: afirman que los ganchos (hooks) post-update corren después de que el permiso de sudo se revoca, cuando en realidad corren dentro de la misma ventana compartida de sudo que usa mise, por lo que los comandos sudo dentro de un gancho post-update no piden contraseña, al contrario de lo que dice el manual, según el propio reporte, que señala que docs/update-process.md ya documenta esto de forma correcta. Ashwinhegde19 abrió, también el sábado, la solicitud #14135, que corrige los dos archivos con la descripción errónea para que coincidan con docs/update-process.md. El propio reporte #14134 advierte que el riesgo no es sólo de exactitud: cualquier persona que refuerce sus propios ganchos post-update pensando en el texto equivocado del manual no sabrá que esos ganchos ya corren con permiso de sudo sin pedir contraseña durante la actualización, lo que puede llevar a ejecutar comandos con más privilegio del que la persona cree estar autorizando. Ninguna de las dos solicitudes -#14129 y #14135- tenía mantenedor asignado ni fusión confirmada al cierre de esta edición, según el propio repositorio, y la información proviene únicamente de esa fuente. Costa Rica no tiene cifras públicas de desarrolladores que escriban ganchos personalizados para Omarchy, pero cualquier persona tica que automatice pasos de actualización con base en el manual de dotfiles debería revisar si alguno de sus propios ganchos post-update asume, por error, que necesita pedir contraseña.
David Heinemeier Hansson abre en persona una solicitud para estabilizar el ícono de wifi, la comunidad documenta cinco fallas nuevas en el escritorio Quickshell, y el kernel Linux fusiona ramas rc6 sin publicar todavía la etiqueta.
El sábado 3 de octubre de 2026 quedó marcado por una solicitud que David Heinemeier Hansson abrió en persona para corregir el parpadeo del ícono de wifi en redes con transición OWE, con una revisión automatizada que la calificó de riesgo medio pero segura de fusionar. La comunidad de Omarchy documentó, además, cinco fallas nuevas en el escritorio Quickshell: una barra que puede desaparecer por completo si una actualización no espera lo suficiente a que el proceso viejo cierre, un cliente de bloqueo que se cae al despertar de suspensión y muestra por segundos la pantalla de emergencia de Hyprland, un panel de audio que se cierra con una falla de segmentación al desconectar un Bluetooth, una asimetría de permisos que impide a los widgets de barras clonadas alcanzar su propio servicio, y una reescritura no atómica de un archivo de configuración que un usuario asocia -sin confirmar la causa- a tres caídas de Chrome. Por separado, un usuario propuso un servicio que restaure de forma automática carpetas como ~/.config si un gestor de archivos las manda por error a la papelera, y dos solicitudes corrigieron la documentación oficial sobre el comando de diagnóstico y sobre cuándo expira el permiso de sudo durante una actualización. En paralelo, el historial de cambios de torvalds/linux mostró a Linus Torvalds fusionando al menos ocho ramas de subsistemas ya etiquetadas para la sexta candidata del ciclo 7.3 del kernel, aunque la etiqueta pública v7.3-rc6 seguía sin aparecer al cierre de esta edición, seis días después de la candidata anterior. Esta sección seguirá si la solicitud #14133 de DHH se fusiona, si alguna de las cinco fallas nuevas de Quickshell recibe una solicitud de corrección, y si v7.3-rc6 aparece dentro de los próximos días. Costa Rica no reporta impacto local confirmado de ninguno de estos frentes al cierre de esta edición, pero desarrolladores, administradores de sistemas y la comunidad tica de software libre que usan Omarchy a diario siguen expuestos, en distinta medida, a cada una de las fallas documentadas hoy.