El bot de triage de Omarchy certifica hoy mismo la corrección del apagón de pantallas por Qt 6.12, pero ningún mantenedor la fusiona nueve días después; un parche aparte sí llega a la rama principal y activa decodificación de video por hardware en portátiles Snapdragon, un agente de Gemini documenta un bloqueo de pantalla que se reinicia solo y aborta con SIGABRT, otro parche propone desbloquear discos cifrados con el chip TPM 2.0, el issue que fijaba la pausa de revisiones de Greptile se cierra como completado sin que el servicio se reactive, el kernel Linux 7.3 llega a la víspera de su lanzamiento proyectado sin una octava candidata y Fedora 45 queda a tres días de su plazo sin una sola tarea cerrada.
El propio bot de triage de Omarchy valida hoy el parche que corrige el apagón de pantallas por Qt 6.12, pero ningún mantenedor humano lo fusiona nueve días después de su primera confirmación.
La cuenta automatizada omarchybot revisó este 17 de octubre el pull request #15265 contra la rama v4-0-4, reprodujo el apagón de pantallas y confirmó que la corrección funciona, según su propio comentario en la página del parche, que agregó las etiquetas "bug" y "verified". El bot escribió que si el cambio sale en una versión puntual 4.0.x "is the maintainer's call, so it waits on them" -es decisión de los mantenedores, así que queda a la espera de ellos-. El mismo día, el usuario barteksdl21 confirmó el mismo fallo en una instalación x86_64 del canal estable con Qt 6.12 y el paquete 4.0.4-1, y pidió explícitamente que el backport salga en una versión puntual. Mientras tanto, el usuario geekhostuk abrió hoy el issue #15713 con el mismo síntoma desde cero: tras una actualización de Arch que llevó Qt de 6.11.2 a 6.12.0 y quickshell de 0.3.1 a 0.3.2, la barra, los menús, el polkit y la pantalla de bloqueo de Omarchy pierden sus colores porque el tipo Color nativo de QtQuick 6.12 sigue chocando con el singleton de paleta de la interfaz -la misma causa raíz que esta sección documenta desde el 12 de octubre-, en un reporte que calcula en 54 los archivos QML que referencian ese singleton sin calificador. Es el tercer reporte distinto del mismo choque en cinco días, pese a que la corrección vive en la rama principal desde el 8 de octubre. Que la propia automatización de revisión del proyecto certifique un parche con sus etiquetas de "verificado" y aun así ningún mantenedor con permiso de fusión lo mueva confirma que el cuello de botella no es de confianza técnica sino de capacidad humana disponible. Costa Rica no reporta despliegues institucionales de Omarchy, pero la comunidad tica de software libre que esta sección sigue como personaje de la semana continúa expuesta al mismo apagón de pantallas mientras el backport certificado no llegue al canal estable.
El parche, fusionado hoy en la rama principal, reduce a una quinta parte el uso de procesador al reproducir video en mpv y Chromium sobre los chips ARM de Qualcomm.
El colaborador birkskyum abrió y vio fusionado este 17 de octubre el pull request #15697 en la rama quattro de Omarchy, como el commit 595eefa. El cambio corrige que mpv y Chromium decodifiquen video por software en portátiles con chip Snapdragon aunque el hardware soporte H.264, HEVC, VP9 y AV1: un nuevo asistente, omarchy-install-video-decode -antes omarchy-install-chromium-video-decode-, agrega hwdec=auto-safe,v4l2m2m-copy al archivo de configuración de mpv del usuario si no tenía ya un ajuste propio, y las banderas --use-angle=gles-egl más la función AcceleratedVideoDecoder a la configuración de Chromium, sin tocar otras placas ARM como la Raspberry Pi 4, que mantienen la decodificación por software en el archivo compartido del sistema. Según la propia descripción del parche, probada en una Lenovo Yoga Slim 7x con linux-omarchy 7.2.8, la reproducción de video en 1080p en mpv pasó a usar cerca de una quinta parte del procesador frente a la decodificación por software, Chromium bajó a aproximadamente 20% de un núcleo en 1080p, y un video de YouTube en AV1 a 1080p60 corrió sobre el propio chip de video. La única revisión registrada en la página del parche es la del bot de Greptile, con confianza de 5 sobre 5 tras varias rondas de señalamientos ya resueltos; ningún mantenedor humano aparece como revisor. La información proviene únicamente de la propia página del pull request en GitHub, sin cobertura de prensa especializada al cierre de esta edición. Los mensajes de los commits individuales citan cifras distintas para Chromium -entre 40% y 10% de un núcleo, según el momento de la prueba- a las que resume la descripción del parche, sin que el autor haya reconciliado la discrepancia públicamente. La oferta comercial de portátiles con chip Snapdragon todavía es marginal en Costa Rica, por lo que el efecto inmediato sobre usuarios ticos es bajo, pero el soporte queda listo para cualquier desarrollador local que compre uno de los nuevos equipos con procesador Qualcomm.
El filtro author:omarchybot sobre los pull requests del repositorio de Omarchy, consultado hoy para esta edición, muestra 229 resultados totales: 163 abiertos y 66 cerrados, de los cuales 39 fueron fusionados -la misma cifra de fusiones que esta sección reportó el 16 de octubre, cuando el total era 228, con 170 abiertos y 58 cerrados-. En 24 horas la cuenta abrió un pull request neto más mientras ocho de los que estaban abiertos pasaron a cerrados sin que el conteo de fusiones se moviera. Es el segundo día consecutivo en que ninguna fusión nueva acompaña al crecimiento de la cola, después de que esta sección reportara el 16 de octubre el primer día de la semana con ese patrón. La tasa de aprobación histórica de la cuenta queda hoy en 39 de 229, apenas 17,0%, prácticamente congelada desde que esta sección empezó a seguirla. La cifra convive con el episodio reportado arriba en esta misma edición: un parche certificado por el propio bot de triage como corregido y verificado que, pese a esa etiqueta, sigue sin fusionarse. Ningún mantenedor de Omarchy ha explicado públicamente los criterios con que decide cerrar un parche de la cuenta sin fusionarlo. Sin impacto local conocido al cierre de esta edición: no hay registro de desarrolladores costarricenses que dependan del flujo de automatización de Omarchy para su propio trabajo.
cat /feed/omarchyterminal.md
El reporte, firmado por un agente de Gemini vía Antigravity, documenta un bloqueo de pantalla que colapsa con SIGABRT al modificar un plugin mientras la sesión sigue cerrada.
> > omarchy.lock: Tried to show lockscreen surfaces without active lock
> > quickshell: SIGABRT
> El usuario nertwork abrió este 17 de octubre el issue #15707 en el repositorio de Omarchy, presentado -según la propia línea de autoría- por el modelo Gemini 4 Argon a través de la herramienta Antigravity. El reporte describe que, con la sesión bloqueada, modificar cualquier archivo dentro de ~/.config/omarchy/plugins/ dispara la función reloadPlugins() en shell.qml, que destruye todos los servicios cargados -incluido el servicio activo omarchy.lock-. Ese servicio se recrea mientras el bloqueo sigue vigente, y quickshell aborta con SIGABRT unos 300 milisegundos después, con el mensaje "Tried to show lockscreen surfaces without active lock" en el registro. El entorno reportado es Omarchy 4.0.3rc4-1 con quickshell-git 0.2.1 y Hyprland 0.56.2 sobre aarch64.
> El propio reporte no determina si el escritorio queda desbloqueado o expuesto durante el reinicio del servicio de bloqueo -la pregunta de seguridad central ante un bloqueo de pantalla que colapsa-, y ningún mantenedor de Omarchy la había contestado al cierre de esta edición. El issue no tiene etiqueta de seguridad, comentarios adicionales ni pull request vinculado.
> La información proviene únicamente del reporte en GitHub, sin confirmación independiente ni cobertura de prensa especializada al cierre de esta edición. Sin impacto local conocido al cierre de esta edición: no hay registro de equipos costarricenses que corran Omarchy con sesiones bloqueadas en entornos de producción.
El usuario Sebo1411 abrió este 17 de octubre el pull request #15709, que agrega el comando bin/omarchy-drive-tpm con tres subórdenes: status, que revisa si hay hardware TPM 2.0, el estado del volumen LUKS2, los tokens TPM ya inscritos y si los HOOKS de mkinitcpio incluyen sd-encrypt; enroll, que ejecuta systemd-cryptenroll --tpm2-device=auto ligando el desbloqueo a los registros de plataforma PCR 0 y PCR 7 -firmware y estado del arranque seguro-, con la lista de PCR configurable mediante la variable OMARCHY_TPM_PCRS; y wipe, que retira el token TPM2 con --wipe-slot=tpm2 y devuelve el disco al desbloqueo solo por contraseña. La frase de paso original se mantiene en la ranura 0 como respaldo. El parche agrega 15 pruebas TAP sin introducir dependencias nuevas más allá de systemd y cryptsetup. Que el desbloqueo quede ligado a PCR 0 y PCR 7 reduce la exposición a un ataque de "evil maid" solo si el arranque seguro está activo, y que la contraseña original siga disponible en la ranura 0 convierte la mejora en una opción de comodidad, no en un reemplazo forzoso del cifrado por contraseña. La única revisión registrada es la del bot de Greptile, con confianza de 5 sobre 5 tras dos señalamientos ya resueltos sobre el manejo de HOOKS comentados y sobre las pruebas que leen la configuración de arranque del propio equipo; ningún mantenedor humano ha revisado el parche al cierre de esta edición, el mismo patrón de automatización sin fusión que domina esta edición. La información proviene únicamente de la propia página del pull request en GitHub, sin cobertura de prensa especializada al cierre de esta edición. El cifrado de disco ligado a TPM es ya habitual en flotas corporativas con Windows en Costa Rica; que Omarchy lo incorpore reduce la brecha de comodidad frente a esos entornos para cualquier desarrollador tico que migre a esta distribución.
La página de etiquetas del repositorio torvalds/linux en GitHub, revisada hoy para esta edición, sigue sin mostrar una octava candidata ni la versión final cinco días después de que Linus Torvalds publicara v7.3-rc7 el 12 de octubre -el mismo punto donde esta sección dejó el ciclo el 16 de octubre-. Mañana domingo 18 de octubre es la fecha que Phoronix reportó al publicar la rc7 como la que Torvalds esperaba para el lanzamiento final, "hopefully" -con suerte-, si el ciclo no necesitaba una octava candidata. Si el calendario se sostiene, el ciclo 7.3 cerraría con siete candidatas desde que la rc1 salió el 30 de agosto, con la rc7 como último contenido técnico confirmado: 58 cambios de endurecimiento de espacios de montaje del mantenedor de VFS Christian Brauner, la deprecación formal del modo data=journal de ext4 con retiro planeado para 2028, y un parche de compatibilidad para el error de hardware AMD TLBI Erratum #1718. Si en cambio aparece una rc8 en las próximas horas, el lanzamiento se correría al 25 de octubre, repitiendo la misma bifurcación que esta sección viene señalando desde el 14 de octubre. El kernel Linux corre en la mayoría de los centros de datos en la nube y en Android, así que cualquier infraestructura usada por empresas costarricenses heredará el resultado de este fin de semana de forma indirecta, a través de las distribuciones que empaqueten el kernel 7.3 cuando esté listo.
— La séptima candidata, publicada el 12 de octubre, cumple cinco días como última revisión del ciclo, a un día de la fecha en que Torvalds proyectó el lanzamiento final.
El hito "Fedora 45 release" en el repositorio de GitLab de la documentación de notas de lanzamiento de Fedora muestra, al cierre de esta edición, 17 tareas abiertas y 0 cerradas, con el hito en 0% completado, a tres días de su fecha límite fijada para el 20 de octubre de 2026 -el mismo balance que esta sección reportó el 16 de octubre, ahora en su séptimo día consecutivo sin un solo elemento cerrado en ese tablero específico. LinuxCompatible y Warp2Search habían reportado a comienzos de octubre que el congelamiento final de Fedora 45 entró en vigor el 6 de octubre con solo dos bloqueadores aceptados -una imagen de Server para aarch64 de tamaño excesivo y una falla de autenticación WiFi vinculada al servicio de secretos oo7-, lo que sugiere que el tablero de documentación que esta sección sigue no necesariamente refleja el riesgo real de la fecha de lanzamiento. Pero siete días seguidos sin ningún cierre, a solo tres días del plazo, dejan cada vez menos margen para que ese argumento siga sosteniéndose sin evidencia nueva. Fedora mantiene dos fechas de respaldo, el 27 de octubre y el 3 de noviembre, si el calendario se atrasa. El indicador real seguirá siendo si el proyecto confirma el lanzamiento el 20 de octubre como estaba previsto. Fedora es una de las bases de desarrollo más usadas en universidades y empresas de software en Costa Rica por su ciclo de soporte corto y predecible, así que un atraso en esta fecha retrasaría en cadena las actualizaciones de quienes la usan como entorno de trabajo local.
El issue #15333, que desde el 13 de octubre fijaba el aviso de que Greptile pausó sus revisiones automatizadas en el repositorio de Omarchy hasta el 21 de octubre, fue cerrado como completado por el usuario Sebo1411 el 16 de octubre. Al revisar la página hoy para esta edición, el aviso fijado en el propio issue sigue sin cambios: "Reviews resume automatically on October 21" -las revisiones se reanudan automáticamente el 21 de octubre-, sin ningún comentario nuevo que confirme que el servicio volvió a funcionar antes de esa fecha. El único comentario del hilo sigue siendo el de camdencarr84-jpg del 13 de octubre: "Welp." Es la segunda vez en tres días que esta sección documenta un desajuste entre el estado formal de un expediente de Omarchy y lo que ocurre en la práctica: el 15 de octubre esta misma sección reportó que Greptile revisó un parche pese a su propia pausa anunciada, sin explicación oficial; hoy el expediente que originó ese aviso se cierra como resuelto sin que nada confirme que el problema de fondo -la falta de créditos del plan gratuito- se haya solucionado. Cerrar un issue de seguimiento no equivale a restablecer el servicio que ese issue describía, y ningún mantenedor ha aclarado la diferencia. La información proviene únicamente del propio repositorio de GitHub, sin cobertura de prensa especializada al cierre de esta edición. Sin impacto local conocido al cierre de esta edición: no hay registro de empresas costarricenses que dependan de Greptile para su propio flujo de revisión de código.
El sábado 17 de octubre dejó la imagen más clara de la semana sobre el cuello de botella de Omarchy: el propio bot de triage certificó como corregido el parche contra el apagón de pantallas por Qt 6.12, y ningún mantenedor humano lo fusionó; el issue que fijaba la pausa de Greptile se cerró como completado sin que el servicio se reactivara; y la cuenta omarchybot sumó su segundo día seguido sin una sola fusión nueva. No todo fue parálisis: un parche de decodificación de video por hardware para portátiles Snapdragon sí llegó a la rama principal, otro propuso desbloquear discos cifrados con TPM 2.0, y un agente de Gemini documentó un nuevo colapso de la pantalla de bloqueo con una pregunta de seguridad todavía sin responder. Fuera de Omarchy, el kernel Linux llegó a la víspera de la fecha que Torvalds proyectó para el lanzamiento final de la versión 7.3, todavía sin una octava candidata, y el tablero de hitos de Fedora 45 quedó a tres días de su plazo sin una sola tarea cerrada. Son los relojes normales de un ecosistema que depende de voluntarios, fundaciones y automatización desigual -y que esta semana mostró, más de una vez, que certificar un parche o cerrar un expediente no es lo mismo que resolver el problema que describen.