El fundador de Omarchy cierra el hilo del candado de sesión con un parche propio en vez del que ya había aprobado la comunidad, su bot de triage repasa 25 issues de meses atrás en un solo domingo, un bug de dos meses revela que la culpa es de Hyprland y no de Omarchy, el kernel Linux arma en silencio las piezas de su séptima candidata y Fedora 45 llega a los nueve días sin cerrar una sola tarea.
El fundador de 37signals escribió y fusionó su propia corrección para el candado de sesión que fallaba tras suspender, mientras la propuesta que la comunidad ya había probado sigue sin fusionarse.
David Heinemeier Hansson abrió y fusionó este 11 de octubre el pull request #14978 en el repositorio de Omarchy, con el commit d1a614c sobre la rama quattro, según el historial de cambios en GitHub. El parche agrega una función currentlyLocked() que lee directamente las banderas lockRequested, sessionLock.locked y sessionLock.secure en lugar de confiar en la propiedad locked -que, tras una suspensión, podía quedar en verdadero aunque esas tres banderas estuvieran en falso-; la propiedad original queda reservada solo para dibujar el fondo y el video de la pantalla de bloqueo. Un nuevo archivo de prueba, lock-stranded-recovery-test.sh, falla contra la versión anterior de Service.qml y pasa con el cambio de hoy. En la descripción del propio pull request, Heinemeier Hansson escribió: "a lock request must never trust it" -una solicitud de bloqueo nunca debe confiar en esa propiedad. El parche de hoy no es, sin embargo, la primera corrección que se propuso para este problema. El pull request #14591, de Sebo1411, abordaba el mismo síntoma desde el 8 de octubre con cambios al archivo Service.qml; el usuario Lifferado lo probó en un ThinkPad E14 Gen 7 y lo aprobó el 9 de octubre, y el 10 de octubre shawnyeager pidió explícitamente que se fusionara: "Can we get this merged, please? Seems high prio, even on Edge". Ese pull request sigue abierto sin fusionar al cierre de esta edición. Un segundo intento, el #14823 de shilai-li, fue cerrado hoy por su propio autor y vinculado como reemplazado por el #14978 de Heinemeier Hansson. El patrón confirma lo que esta sección documentó el viernes sobre el mismo subsistema: el fundador retiene la última palabra sobre el núcleo de Omarchy incluso cuando una corrección de la comunidad ya pasó revisión y pruebas en hardware real. La herramienta automatizada greptile-apps calificó el PR #14978 con confianza de 5 sobre 5, pero la página no registra todavía una revisión humana. Costa Rica no reporta despliegues institucionales de Omarchy; la comunidad tica de software libre que sigue el proyecto -personaje de la semana en esta sección- puede actualizar ahora con el candado de sesión corregido, aunque el episodio deja registro de cómo se decide, en la práctica, qué código entra al núcleo del proyecto.
La cuenta automatizada omarchybot comentó este domingo en al menos 25 issues abiertos, con revisiones de Claude Opus 5.5 que en varios casos no tuvieron la segunda opinión de Codex por falta de cupo diario.
El repositorio de Omarchy en GitHub, consultado hoy para esta edición, muestra al menos 25 issues abiertos entre el 9 y el 10 de setiembre -y marcados con la etiqueta "bug" el 27 de ese mismo mes- que recibieron hoy, 11 de octubre, un comentario nuevo de la cuenta colaboradora omarchybot. Entre ellos están el #11119, donde el comando omarchy plugin disable reporta éxito sin desactivar un plugin inexistente; el #11043, donde el salvapantallas no cubre las ventanas fijadas con Super+O por encima de un espacio de trabajo especial de Hyprland, con una corrección propuesta en el pull request #15015; y el #11108, donde omarchy-system-reboot falla si las variables DBUS_SESSION_BUS_ADDRESS y XDG_RUNTIME_DIR no están definidas. En los tres casos, el bot dice haber reproducido el error y haber redactado una corrección, pero ninguna llegó todavía a convertirse en un pull request abierto. El propio comentario del bot explica por qué: "the second opinion (Codex Medium) did not run on this item, because omabot's daily review allowance was spent" -la segunda opinión de un modelo Codex no corrió en ese caso porque se agotó el cupo diario de revisión del bot-, de modo que el único control de calidad sobre esas correcciones fue una pasada de Claude Opus 5.5 sin el segundo modelo que el propio proceso de Omarchy dice usar como contraste. El patrón conecta con lo que esta sección reportó el viernes sobre el parche de reconocimiento facial frenado por código generado con un modelo de Gemini sin segunda revisión humana: Omarchy depende cada vez más de triage asistido por IA para sostener un volumen de reportes que, solo hoy, incluyó 25 issues de meses de antigüedad procesados el mismo domingo. Ninguna de las correcciones que el bot redactó hoy tiene todavía un pull request vinculado ni fecha de revisión por un mantenedor humano. Costa Rica no tiene despliegues institucionales de Omarchy, pero cualquier desarrollador tico que mantenga su propio proyecto de código abierto con un flujo de revisión automatizada similar -Claude Code u otra herramienta agéntica- debería tomar nota de que un cupo diario agotado puede dejar una corrección con una sola pasada de revisión antes de llegar a producción.
cat /feed/omarchycausaraz.md
Un issue abierto desde agosto y reactivado este domingo muestra que Hyprland, el compositor de ventanas que usa Omarchy, descarta la solicitud de bloqueo cuando el monitor desaparece antes de tiempo.
> > CSessionLockProtocol::onGetLockSurface returns without creating the object
> El issue #6628, abierto el 8 de agosto por el usuario akashgagda en el repositorio de Omarchy, documenta que el proceso que dibuja el candado de pantalla puede morir durante un ciclo normal de bloqueo por inactividad, dejando la sesión bloqueada con la pantalla de respaldo "lockscreen app died" de Hyprland -el único remedio, en ese momento, era reiniciar el equipo. El 17 de agosto, el usuario ChristopherClure encontró la causa técnica en el propio Hyprland: la función CSessionLockProtocol::onGetLockSurface del compositor retorna sin crear el objeto de superficie de bloqueo cuando el monitor asociado ya desapareció, pero el cliente ya le había asignado un identificador new_id, por lo que su solicitud posterior de destruirlo dispara un error de protocolo que desconecta al cliente mientras todavía sostiene el bloqueo. Como describió el propio ChristopherClure: "a compositor has to either create a new_id object or raise an error, and it does neither".
> Este 11 de octubre, el issue #11084 -abierto el 10 de setiembre por heat-a11y sobre el mismo síntoma durante la suspensión- recibió un comentario de omarchybot que reprodujo el fallo en una máquina virtual con salidas de video sin cabezal y confirmó que se trata del mismo caso que el #6628: Hyprland 0.56.2 descarta la solicitud de bloqueo cuando una salida de video ya no existe. El propio comentario concluye que el candado que Omarchy propone del lado del cliente "can't prevent the race" -no puede evitar la condición de carrera- y que "the real fix belongs in Hyprland" -la corrección real pertenece a Hyprland. Es, en la práctica, un tercer frente del mismo subsistema de bloqueo que esta sección reporta toda la semana, pero el único de los tres cuya causa no vive en el código de Omarchy.
> Dos meses después del primer reporte, ningún issue ni pull request contra el propio repositorio de Hyprland atiende todavía esta falla, según el hilo público de Omarchy. El bot pidió a quien pueda reproducir el error que comparta un registro con WAYLAND_DEBUG=client. Costa Rica no registra despliegues institucionales de Hyprland ni de Omarchy, pero cualquier usuario tico que use una laptop con salida de video externa y suspenda el equipo con la pantalla bloqueada debería esperar el mismo síntoma hasta que la corrección llegue al compositor.
El historial de cambios de torvalds/linux en GitHub, revisado esta mañana para esta edición, muestra que Linus Torvalds fusionó el 9 y el 10 de octubre al menos cinco ramas de pull request cuyo nombre nombra explícitamente la séptima candidata: net-7.3-rc7, sound-7.3-rc7, vfs-7.3-rc7.fixes, i2c-fixes-7.3-rc7 y edac_urgent_for_v7.3_rc7, junto con otras seis ramas de corrección -pci, mmc, media, pmdomain, dma-mapping y arm64- fusionadas esos mismos dos días sin esa etiqueta explícita en el nombre. Pese a ese volumen de fusiones, la página de etiquetas del repositorio sigue sin mostrar un tag v7.3-rc7 esta mañana: la última candidata publicada sigue siendo v7.3-rc6, del 4 de octubre. Es la primera señal concreta, desde la rc6, de que la séptima candidata está en ensamblaje activo. Cobertura especializada como Phoronix y OSTechnix había proyectado la rc7 para alrededor del 11 de octubre -hoy mismo-, sin que Torvalds lo confirmara de forma oficial todavía. El ciclo 7.3 sostiene, desde la rc1 del 30 de agosto, un ritmo semanal sin excepciones en sus primeras seis candidatas; si la etiqueta de la rc7 se publica horas después del cierre de esta edición, el patrón se mantiene, y un atraso de pocas horas sobre la fecha proyectada no equivale, por sí solo, a una ruptura de ese ritmo. Si la rc7 se confirma esta semana, el lanzamiento estable del ciclo seguiría proyectado para el 18 de octubre, según Phoronix; una octava candidata movería la fecha al 25. Costa Rica no tiene mantenedores identificados en el equipo de desarrollo del kernel; el ciclo 7.3 llegará a los usuarios ticos de forma indirecta, cuando las bases de Ubuntu y Debian que sostienen buena parte de la infraestructura de servidores del país lo incorporen a una futura versión estable.
El tablero de hitos "Fedora 45 release" en la instancia de GitLab del proyecto, consultado hoy para esta edición, sigue mostrando 17 elementos de trabajo abiertos y cero cerrados, con 0% del hito completado a nueve días de la fecha de lanzamiento fijada para el 20 de octubre -el mismo conteo que esta sección reportó el viernes, sin un solo elemento cerrado en los días intermedios. Los dos bloqueadores aceptados en la congelación final del 6 de octubre -una imagen de Server para aarch64 de tamaño excesivo y una falla de autenticación WiFi vinculada al servicio de secretos oo7- siguen en el tablero sin resolución pública reportada. Un tablero estancado en 0% nueve días antes del lanzamiento no es, por sí solo, motivo de alarma: el propio tablero de GitLab mezcla tareas que bloquean el lanzamiento con tareas de documentación o limpieza menor, una distinción que no aclara y que esta sección ya señaló el viernes para no sobrestimar el riesgo. Pero el estancamiento total -ninguna tarea cerrada en cuatro días consecutivos de seguimiento de esta sección- es un dato que matiza la confianza en la fecha del 20 de octubre, sin que exista todavía un anuncio oficial de atraso por parte del proyecto. Fedora mantiene dos fechas de respaldo, el 27 de octubre y el 3 de noviembre, si el calendario se atrasa. Costa Rica no reporta instalaciones institucionales de Fedora -el sector público y bancario que usa distribuciones basadas en Red Hat suele optar por RHEL-, pero laboratorios universitarios de la Universidad de Costa Rica y el Instituto Tecnológico de Costa Rica que usan Fedora Workstation seguirán de cerca si la fecha del 20 de octubre se sostiene.
El domingo 11 de octubre combinó una resolución, un ejercicio de escala y dos desarrollos en marcha. David Heinemeier Hansson fusionó su propia corrección (PR #14978) para el candado de sesión de Omarchy, dejando sin fusionar la propuesta de la comunidad (#14591) que ya tenía pruebas y aprobación, y cerrando una segunda (#14823) como reemplazada. La cuenta automatizada omarchybot comentó en al menos 25 issues de meses de antigüedad el mismo día, con revisiones de Claude Opus 5.5 que en varios casos no tuvieron la segunda opinión de un modelo Codex por falta de cupo diario. Un tercer hilo del mismo subsistema de bloqueo -el issue #6628, abierto en agosto- confirmó que la causa real de otra falla de candado está en Hyprland, el compositor que usa Omarchy, y no en el propio proyecto. Fuera de Omarchy, el kernel Linux 7.3 entró en ensamblaje activo para su séptima candidata, con al menos cinco ramas fusionadas el 9 y el 10 de octubre con "rc7" en el nombre, aunque sin etiqueta oficial todavía; y Fedora 45 llegó a nueve días de su lanzamiento con el mismo tablero de hitos estancado en 0% que mostraba el jueves. Costa Rica no reporta impacto institucional confirmado en ninguno de estos frentes al cierre de esta edición, pero la comunidad tica de software libre que sigue a Omarchy -personaje de la semana en esta sección- tiene hoy evidencia concreta de cómo se decide qué código entra al núcleo de un proyecto cuando compite con el de su propio fundador, y de cómo un bot de revisión automatizada puede procesar un historial de meses en un solo domingo.