Over the past week I worked on merging the atk and at-spi2-atk repositories into at-spi2-core. A quick reminder of what they do:

• at-spi2-core: Has the XML definitions of the DBus interfaces for accessibility — what lets a random widget identify itself as having a Button role, or what lets a random text field to expose its current text contents to a screen reader. Also has the "registry daemon", which is the daemon that multiplexes applications to screen readers or other accessibility technologies. Also has the libatspi library, which is a hand-written binding to the DBus interfaces, and which is used by...

• at-spi2-atk: Translates the ATK API into calls to libatspi, to effectively make ATK talk DBus to the registry daemon. This is because...

• atk: is mostly just a bunch of GObject-based interfaces that programs can implement to make themselves accessible. GTK3, LibreOffice, and Mozilla use it. They haven't yet done like GTK4 or Qt5, which use the DBus interfaces directly and thus avoid a lot of wrappers and conversions.

Why merge the repositories?

at-spi2-core's DBus interfaces, the way the registry daemon works, atk's interfaces and their glue in at-spi2-atk via libatspi... all of these are tightly coupled. You can't make a change in the libatspi API without changing at-spi2-atk, and a change in the DBus interfaces really has to ripple down to everything, but keeping things as separate repositories makes it hard to keep them in sync.

I am still in the process of learning how the accessibility code works, and my strategy to learn a code base, besides reading code while taking notes, is to do a little exploratory refactoring.

However, when I did a little refactoring of bit of at-spi2-core's code, the tests that would let me see if that refactoring is correct were in another repository! This is old code, written before unit tests in C were doable in a convenient fashion, so it would take a lot more refactoring to get it to a unit-testable state. I need end-to-end tests instead...

... and it is at-spi2-atk that has the end-to-end tests for all the accessibility middleware, not at-spi2-core, which is the module I was working on. At-spi2-atk is the repository that has tests like this:

• Create a mock accessible application ("my_app").
• Create a mock accessibility technology ("my_screen_reader").
• See if the things transferred from the first one to the second one make sense, thus testing the middleware.

By merging the three repositories, and adding a code coverage report for the test suite, we can add a test, change some code, look at the coverage report, and see if the test really exercised the code that we changed.

Changes for distributions

Please see the announcement on discourse.gnome.org.

That coverage report is not accessible!

Indeed, it is pretty terrible. Lcov's genhtml tool creates a giant <pre>, with things like the execution count for each line just delimited with a <span>. Example of lcov's HTML.

(Librsvg's coverage report is pretty terrible as well; grcov's HTML output is a bunch of color-coded <div>. Example of grcov's HTML.)

Does anyone know code coverage tools that generate accessible output?

Veamos cómo podemos enviar un mensaje mediante un bot de Telegram cuando cambie la IP pública de nuestro router en casa

Hace un tiempo escribí una entrada en el blog sobre cómo mandar un correo electrónico cuando cambie la dirección IP pública de nuestro router casero.

En aquel caso había una tarea cron que ejecutaba de manera periódica un pequeño script en bash que monitorizaba la dirección de nuestra dirección IP pública en el router casero y enviaba un correo electrónico cuando la IP cambiaba.

En este caso vamos a tener una tarea cron en un equipo que esté siempre encendido, por ejemplo una Raspberry Pi, que tengamos como servidor y ejecutará un script en Python.

El script enviará un mensaje de Telegram, mediante un bot que deberemos crear, cuando cambie nuestra dirección IP, así podemos monitorizar el cambio.

Lo primero que vamos a hacer es crear un bot en Telegram para que el script en Python pueda pasarle el texto a mostrar cuando la dirección IP cambia.

Para crear el bot, utilizaremos el asistente para crear bots en Telegram llamado @BotFather, donde nos pedirá el nombre de nuestro bot, una pequeña descripción.

Podremos configurarlo mucho más, pero para empezar y para lo que lo vamos a usar, con eso será más que suficiente.

Al crearlo, nos proporcionará un token API, que es una secuencia de números y letras, que deberemos copiar y tener guardado en un sitio seguro.

Ese token lo deberemos pegar en el script de Python en la parte superior donde pone token, para que quede algo similar a esto:

token = "bot0123456789:AbCdEfGhjhlU8AVw3VE4293aV1c70R"

Ahora también deberemos enviar un mensaje al bot para abrir una conversación desde la cuenta del usuario que queremos que reciba las notificaciones de cambio de IP.

Ahora deberemos obtener el ID de la conversación, para eso podemos hacerlo con un bot existente llamada @get_id_bot. Escribimos eso en la conversación con nuestro bot y se mostrará una serie de números que son la ID de la conversación:

Copiaremos también ese número y lo pegaremos en el script de Python:

chatID = 4221111234

Como complemento a todo este proceso de crear un bot, Lorenzo Carbonell aka Atareao, ha escrito una serie de artículos para sacarle todo el jugo a esto de los bots en Telegram, empezado por lo básico. Echa un vistazo en este enlace:

• https://atareao.es/tutorial/crea-tu-propio-bot-para-telegram/

Ahora vamos a descargar el script en cuestión y complementarlo con los datos de token e ID necesarios y propios de nuestro caso.

El script está alojado en un repositorio de GitHub yo lo he modificado un poco para que muestre los textos en español. Para descargarlo podemos hacerlo mediante:

wget https://raw.githubusercontent.com/PJR1988/IP_Reporter_bot-/main/IPbot.py

Lo hacemos ejecutable mediante:

chmod +x IPbot.py

Ahora en nuestro equipo deberemos tener instalado Python y deberemos instalar el paquete necesario mediante:

pip3 install requests

Creamos una tarea cron para que ejecute nuestro script de manera automática, digamos que cada 5 minutos, quedando tal que así (cambiando la ruta a tus necesidades):

# Envía un mensaje a Telegram mediante un bot
*/5 * * * * /usr/bin/python3 /home/victorhck/Scripts/IPbot.py

Y con eso ya estaría. Yo lo tengo configurado en mi Raspberry Pi que está funcionando todo el día. Si lo quieres probar, puedes hacerlo ejecutándolo en tu equipo y ver si funciona.

El script crea una carpeta oculta llamada .IP y dentro un archivo llamado IP.txt donde guarda la IP antigua. Obtiene la nueva y la compara con esa.

Si son distintas actualiza el archivo con la nueva dirección y envía el mensaje mediante el bot. Si la dirección no cambia, simplemente no hace nada.

Si quieres probar si funciona, puedes editar el archivo .IP/IP.txt modificar manualmente la IP almacenada y guardar los cambios. Al ejecutarse el script, y ver que son distintos datos enviará el mensaje.

Gracias al usuario Pablo que fue quién creó el código y me enteré gracias a que lo compartió en el canal de Telegram Linux y Tapas.

Sirva este pequeño y sencillo ejemplo como introducción a los bots de Telegram y para empezar a «cacharrear» con ellos.

Con cierto retraso con el grueso de las celebraciones os invito a participar en Flisol 2022 de Quito, Ecuador, que se celebrará el próximo 4 de junio de 9 a 17 horas, y que como el resto de eventos vuelve a ser presencial. Es el momento de conocer detalles.

Flisol 2022 de Quito el próximo 4 de junio

La información es sencilla, si estás por Quito, por la Universidad Central del Ecuador tienes una cita el próximo sábado, 4 de junio de 2022 de 09:00 a 17:00.

Este evento viene cargado de charlas y talleres, como podemos ver a continuación, ya que se van a utilizar tres salas para poder abarcar todo lo que nos han preparado la organización compuesta por el Centro de Autonomía Digital y OpenLabEC, Laboratorio ciudadano de tecnologías y cultura libre, con los siguientes o-organizadores Universidad Central del Ecuador y la Red de investigación de conocimiento, hardware y software libre.

Auditorio de la Facultad de Filosofía

Charlas: Salón Máximo

Talleres: Sala 404 – 4to piso

Más información: Flisol Quito

¿Qué es Flisol?

Para los que todavía no conozcan Flisol, se trata de un evento «… de difusión de Software Libre más grande en Latinoamérica y está dirigido a todo tipo de público: estudiantes, académicos, empresarios, trabajadores, funcionarios públicos, entusiastas y aun personas que no poseen mucho conocimiento informático…»

La entrada Flisol 2022 de Quito el próximo 4 de junio se publicó primero en KDE Blog.

Members of SUSE and openSUSE have deleloped several Work Groups (WG) to discuss the formation of the Adaptable Linux Platform. Below readers can see the latest brief from the various WGs involved in the open-source project.

The System Management WG has been progressing with the branding of Cockpit. They have been experimenting with attempts to containerize it; though outside of a possible chance to use wormholing, it doesn’t look promising. They do continue to add functionality to YaST in cointainers at a good pace.

The ALP Virtualization team has taken some technical decisions regarding support, etc. In their first technical meetings regarding VMs inside of containers, some work was done looking for the best approach and blocking points.

In the Build Service Next-Generation WG, the initial feedback shows little interest in a git-based packaging approach. Software as a Service options via git hosting continue to be very expensive, though on-premises options should be considered. A self-hosted Gitea appears to be the best option so far, while the current discussions for Large-File-Storing-in-Git have been paused at this time.

The Components delivery & lifecycle WG’s goal is to find an alternative way to ship packages with different lifecycles. With this in mind, the group has been gathering input on RHEL’s modularity, in order to compare and learn what they can from them.

The Confidential Computing WG has been collecting information to determine where they want to be in the long term, and what can be achieved in a given period of time. This allows them to establish a timeline within Confidential Computing to support upstream projects in their endeavors.

The Container Management Frontend WG strongly favors Podman for it’s systemd integration, potentialy allowing for services-as-containers and RPM-delivered services. Docker may be required as well, along with Rancher and nerdctl/containerd embedded with their products. The group would appreciate feedback on the technology decision from other WGs, as so far there was none.

The Container Easy Deployment and Installation WG has been discussing problem space and preliminary research into quadlet and systemd portable services, etc.

The Community WG has drafted a communications plan and identified topics that are relevant to the current state of the project. Weekly meetings have been established and publish minutes are available at https://etherpad.opensuse.org/p/weeklymeeting. Group encourages all other WG to make public updates on their own, and recomemends YaST team as a role model.

The Deployment/Management Framework WG is looking to identify and decide on which configuration and management tool will be the next generation. The two current options looking best to meet customers needs and integrate into the rest of SUSE’s products look to be SALT and Ansible.

The Desktop WG is looking into a remote-Wayland-based remote desktop with a focus on a headless GNOME solution. Other discussions are focused on lightweight windows managers and desktops without Xorg, containerizing the GNOME core stack, and Nvidia open source kernel modules in Wayland.

The Documentation WG is starting to update the look and feel of the documentation pages for better navigation.

The Data Processing Unit (DPU) Integration team is looking into ongoing business and technical discussions with Dell.

Full-disk encryption experts are looking to use LUKS2 for TPM-auto unlocking (on systems which support it) and to design simple and secure, yet easy to use encrypted systems.

The High Performance Computing WG is participating in multiple community projects to develop and enhance a state-of-the-art deployment systems.

The Installation and Deployment WG is discussing an evolution of the traditional installer, including modularity to make it more useful. There may also be an option to create customized images on the fly for deployment.

The Kernel and Live Patching team is currently busy with the launch of Userspace Live Patching.

Kernel Performance Testing has kicked off with a focus on defining the scope and setup during biweekly calls and a mailing list for furthing discussions.

Qualiting Engineering assigned representatives to most other workgroups and planned a kicked off a meeting and created a slack channel.

Security Framework WG has benn constitued and held a kick off call. Discussions are being held on how to make a smooth switch from AppArmor to SELinux and how to prepare for it.

The Telemetry WG has been collecting data needed to summarize requirements to measure subscriptions.

There will be several discussions at the openSUSE Conference the next couple days. People interested in ALP news and WGs can register for the conference and watch the discussions online.

Red Hat Enterprise Linux 9 became generally available recently. Version 3.35 of syslog-ng has been part of EPEL 9 (the semi-official extra software repo for RHEL maintained by Fedora packagers) for a while and now I enabled a few more destination drivers. I also enabled RHEL 9 support in my unofficial Git snapshot packages, so I can support RHEL 9 together with other RHEL and Fedora versions on the next syslog-ng release.

You can read the rest of my blog at https://www.syslog-ng.com/community/b/blog/posts/rhel-9-syslog-ng-news

There are situations where you cannot avoid giving a user full shell access through sudo. A shell with administrative privileges gives complete control over your hosts. Until recently, sudo could only log the start of the shell, not the commands executed within it. You could record sessions with sudo, but watching recordings is boring, time consuming and can still be subverted. Version 1.9.8 introduced logging of sub-commands, but that is not yet available on many systems. An alternate approach is to use auditd to log commands started from a root shell.

From this blog you will learn how to use auditd to log commands from a sudo-run root shell, why it is better to use the sub-command logging built into recent sudo releases, and why you should still record sessions with sudo.

You can read the rest of my blog at https://www.sudo.ws/posts/2022/05/looking-inside-sudo-shell-sessions-auditd-session-recordings-log_subcmds/

Como es tradicional, aunque no sé porqué el año pasado no lo hice, hoy quiero comner las participación de KDE en Google Summer of Code 2022 (GSoC). A lo largo de muchos años, esta simbiosis entre la Comunidad KDE y el gigante multicolor ha sido muy provechosa para ambos, como hemos visto en muchas ocasiones en el blog, esperemos que éste también lo sea.

La participación de KDE en Google Summer of Code 2022

El equipo de KDE es uno de las Comunidades que siempre intentan colaborador con los proyectos sobre Software Libre que suele organizar cualquier compañía, y Google no es ninguna excepción.

Este año tenemos bastantes estudiantes mejorando sus habilidades al tiempo que mejoran las aplicaciones del ecosistema KDE. De esta forma según leemos en el blog de novedades de KDE, también conocido como el Dot, tenemos un articulo de Johnny Jazeix que nos cuenta que:

• Snehit Sah añadirá soporte para Spaces en NeoChat. Spaces es una herramienta de Matrix que nos permite descubrir nuevas salas y también una forma de organizar tus habitaciones en categorías.
• Suhaas Joshi trabajará en la gestión de permisos para las aplicaciones Flatpak y Snap en Discover.
• Quoc Hung Tran, implementará en un nuevo plugin para procesar el reconocimiento óptico de caracteres (OCR) para DigiKam.
• Phuoc Khanh LE dedicará su tiempo para mejorar los algoritmos del Clasificador de Calidad de Imagen, también para DigiKam.
• Smit Patil trabajará en la configuración del sistema Plasma, rediseñando los diferentes módulos al portarlos a QtQuick.
• Aastha Chauhan trabajará en la adición de un Tux programable, una actividad de comparación y el juego Adivina 24 para GCompris.
• Samarth Raj trabajará una actividad de análisis gramatical y otra de uso de los complementos del 10 para sumar números, también para GCompris.
• Xu Che añadirá elipses perfectas para el píxel en Krita que permitirá que los artistas del píxel puedan utilizar Krita de forma más eficaz.
• Reinold Rojas trabajará en la exportación de una imagen a SVG en Krita; un proyecto que proporcionará más opciones para compartir archivos con Inkscape, y ayudará a crear imágenes traducibles con texto para Krita Manual sin conocimiento de Inkscape,

Si te interesa el desarrollo de estos proyectos te invito a seguir sus progresos a través de las entradas de su blog en el KDE Planet.

¿Qué es GSoC?

Vía Somos Libres he encontrado esta magnífica descripción del programa GSoC:

Google Summer of Code (GSoC) es un evento organizado por Google, cuyo objetivo es hacer participar a varios estudiantes en el desarrollo de determinados proyectos Open Source elegidos por Google. Cada grupo debe cumplir con una lista de tareas específicas que deben realizar y elegidas por el representante del proyecto, también conocido como mentor.

Los objetivos del GSoC son:

• Crear y liberar código Open Source para el beneficio de todos.
• Inspirar a los jóvenes desarrolladores a participar en el desarrollo de aplicaciones Open Source.
• Ayudar a los proyectos Open Source a identificar a nuevos y posibles desarrolladores.
• Dar a los estudiantes la oportunidad de trabajar en algo relacionado a sus estudios. Dar a los estudiantes una mayor exposición a situaciones del mundo real de desarrollo de software.

En definitiva, una excelente iniciativa que beneficia a todo el mundo.

La entrada La participación de KDE en Google Summer of Code 2022 se publicó primero en KDE Blog.

Con el lanzamiento de Plasma 5.8 de enero de 2017 llegó una funcionalidad llamada Look and Feel que nos permitía mediante un simple click de cambiar todo Plasma: sus temas, esquema de colores, cursores del ratón, conmutador de ventanas, pantalla de bloqueo, etc. Esta funcionalidad ha ido creciendo en número de aportaciones en la Store de KDE y hasta ha cambiado de nombre a Temas Globales (Global Themes) siendo en estos momentos más de 368 los temas elegibles. Entre ellos se encuentra Plasma Deck un tema global inspirada en la consola de Valve, la Steam Deck.

Plasma Deck, el tema global de la Steam Deck para tu escritorio

Hace relativamente poco la compañía de videojuegos Valve, la consola GNU/Linux llamada Steam Deck, que viene a convertirse en la gran apuesta por el mercado hardware de este tipo de dispositivos de una compañía que ya domina la parte del Software.

El lanzamiento no me dejó indiferente ya que la Steam Deck está relacionada con el universo de la Comunidad KDE ya que su interfaz gráfica es un escritorio Plasma sobre una distribución GNU/Linux Arch.

Es por eso que no es de extrañar que en la KDE Store haya aparecido un Tema Global inspirado en la Steam Deck que, como no, recibe el nombre de Plasma Deck, una creación de x-varlesh-x, un viejo conocido del blog.

Este tema oscuro destaca por sus iconos coloridos y que contiene los siguientes elementos:

• Aurorae decoration theme
• Plasma theme
• Icon theme
• Color scheme
• Animated splash (con sonido)

Más información: Plasma Deck

Y como siempre digo, si os gustan estos Temas Globales (ex-Look & Feel) para Plasma podéis “pagarlo” de muchas formas en la nueva página de KDE Store, que estoy seguro que el desarrollador lo agradecerá: puntúale positivamente, hazle un comentario en la página o realiza una donación. Ayudar al desarrollo del Software Libre también se hace simplemente dando las gracias, ayuda mucho más de lo que os podéis imaginar, recordad la campaña I love Free Software Day 2017 de la Free Software Foundation donde se nos recordaba esta forma tan sencilla de colaborar con el gran proyecto del Software Libre y que en el blog dedicamos un artículo.

La entrada Plasma Deck, el tema global de la Steam Deck para tu escritorio se publicó primero en KDE Blog.