GNOME, Plasma Releases Make Progress While Tumbleweed Rolls
GNOME 41 has reached openSUSE Factory staging and KDE’s Plasma 5.23 is nearing a release in an openSUSE Tumbleweed snapshot as it progresses through staging.
openSUSE’s rolling release turned out four snapshots this week and updated software packages like Mesa, curl, catfish, PipeWire, Perl and more.
The 20210928 snapshot improved the transferring of data via an update of curl 7.79.1, which made it work with OpenSSH 8.7; the command line tool and library also adjusted a setup to not change connection data upon repeat invokes. An update of inkscape 1.1.1 fixed a crash and improved the startup time of the graphics editor application. Two other packages updated in the snapshot were yast2-network 4.4.26 and yast2-nfs-client 4.4.1; the latter had an update that supports systemd mount options in fstab.
With the 4.16.3 update of the file searching tool catfish, better icon updating and a sidebar background color fix was made in snapshot 20210927. Intel’s dleyna-renderer package updated to 0.7.1; this package, which allows clients to discover and manipulate Digital Media Renderers, provided a build fix and a port to the GUPnP 1.2 object-oriented framework. The desktop environment package menulibre 2.2.3 fixed making diagnostic text selectable on KDE and added support for GNOME-specific categories.
Mozilla Thunderbird 91.1.1 was released in snapshot 20210926. A menu item for disabling subject encryption for a single message was added and the printing of email messages not currently being displayed is no longer supported, which includes printing multiple messages at once. The dnsmasq 2.86 version fixed a bug that caused dnsmasq to lose track of processes forked to handle Transmission Control Protocol Domain Name System connections under heavy loads. Perl 5.34.0 added a patch to fix a build with gdbm 1.20 and fixed a memory leak in regular expression. The rendering of fullscreen zoom was optimized with the gnome-shell 40.5 update, and pipewire 0.3.37 provided some JACK stability improvements with buffer-size and sample rate changes in some apps. Other updates in the snapshot included php7 7.4.24, mousepad 0.5.7, a version bump to ceph, mutter 40.5, python-numpy 1.21.2 and a few updates to YaST packages.
The 20210924 snapshot brought an update of Mesa 21.2.2; the 3D graphics package provides some bug fixes and a ton of work went into getting panfrost closer to being conformant. The creation suite ImageMagick 7.1.0.8 fixed some color conversions and added an option to read a thumbnail of a raw Image and store it as a profile called dng:thumbnail. Chat client pidgin 2.14.7 removed some obsolete translations and fixed a couple leaks. Other packages to update in the snapshot were bubblewrap 0.5.0, webkit2gtk3 2.32.4, gnome-control-center 40.1 and libstorage-ng 4.4.37.
Playing with D-Bus and KDE applications (Part 1)
Juegos portables para Linux en portablelinuxgames.org
Definitivamente, quien no juega en Linux es porque no quiere. Eso si, igual no juega al último triple A que ha aparecido o al que está de moda, pero la cantidad de juegos disponibles, muchos de ellos de gran calidad, es ingente y creciente. Y es más, en muchas ocasiones, su instalación es más que sencilla ya que existen juegos portables para Linux que podemos encontrar en la página web portablelinuxgames.org. ¿Te interesa el tema? Sigue leyendo.
Juegos portables para Linux en portablelinuxgames.org
Lo he confesado en multitud de ocasiones, me encantan los videojuegos aunque no pueda jugar a ninguno por falta de tiempo.
Así que suelo dedicar algo de tiempo a leer sobre ellos, escuchar podcast dedicados y cuando pueda, probar su funcionamiento en mi sistema operativo libre. De hecho, estoy probando como funcionan mis juegos de la tienda Steam en mi KDE Neon (cuando acabe os doy el resultado).
Eso si, he de reconocer que el tema de instalación de juegos en los sistemas GNU/Linux siempre ha sido complicado, como la instalación de cualquier otro tipo de aplicación.
Este problema se está resolviendo poco a poco, de forma lenta pero constante gracias a proyectos como Lutris, del cual he hablado también en el blog.
No obstante, encontrar la páguna web que os comento hoy me llenó de satisfacción por dos motivos: el primero es que encontré una fuente de juegos ejecutables directamente sobre GNU/Linux sin necesidad de instalación; y la segunda, que el proyecto sigue vivo.
De esta forma os presento portablelinuxgames.org, una página que recopila una extensa lista de lanzamientos de juegos, cada uno con su enlace, que se ejecutan directamente sobre tu máquina.

El proyecto estuvo parado un tiempo, pero desde este 2021 parece que ha cogido nuevas energías.
Personalmente me he bajado y probado algunos cuantos y lo cierto es que la mayoría funcionan. En definitiva, quien no juega en Linux es porque no quiere.
Establecer un tema oscuro para YaST de #openSUSE en Plasma
¿Eres un fanático de los temas oscuros para tu escritorio Plasma? ¿Quieres también disfrutar de tu tema oscuro preferido en YaST de openSUSE? Estás en el sitio correcto

YaST es la gran herramienta de configuración y gestión de nuestra distribución de GNU/Linux openSUSE. Tiene opciones gráficas para realizar configuraciones de nuestro sistema o para consultar ciertos parámetros o mensajes.
Aunque sigo prefiriendo zypper para la instalación de paquetes de software y actualización de mi sistema, YaST es la herramienta gráfica a la que recurro para gestionar los repositorios, configurar el arranque del sistema, administrar servicios, configurar una IP fija en mi red para mi equipo, etc…
Desde hace unos años me he aficionado a los temas oscuros en mi escritorio Plasma de KDE y cada vez que tenía que abrir YaST con su interfaz clara, era un golpe para mis ojos… hasta ahora.
¿A tí te pasa lo mismo? Veamos cómo ponerle solución
La verdad es que nunca se me había ocurrido que pudiera cambiarle el tema, pero gracias a un gran artículo del blog CubicleNate me dí cuenta de “lo que me estaba perdiendo”.
En su artículo aparecen capturas de pantallas de YaST con un tema oscuro, en vez del tema claro y pensé ¡Eso es lo que yo quiero! ¡Cómo lo ha conseguido! Pues muy sencillo.
YaST al ser una aplicación que gestiona el sistema, requiere de privilegios de root para ejecutarse. Así que debería cambiar el tema del usuario root del sistema en Plasma a un tema oscuro para tenerlo yo también.
Para ello, lo que hice fue ejecutar los ajustes del sistema de Plasma 5 (la versión que tengo en mi Tumbleweed) con el usuario root, por lo que ejecuté lo siguiente en una terminal:
kdesu systemsettings5
Introducimos la contraseña de usuario root de nuestro sistema y ya podemos configurar el tema de nuestro Plasma al tema que queramos, en mi caso seleccioné un tema oscuro que era lo que quería. Guardamos los cambios y cerramos ya estaría.
Ahora cuando se abra YaST u otra aplicación gráfica del usuario root, tendrá el aspecto que nosotros le hayamos dado y se integrará con nuestros gustos y nuestro escritorio del usuario normal.
¿Te animas a probarlo? o quizás ya lo tenías así. ¿Te ha gustado este pequeño truco? Comparte en los comentarios tu opinión.

Librsvg's development branch is now called main
I have just renamed librsvg's master branch to main, as other
modules already have.

This is what I did:
- Rename the local branch, and push it:
git branch -m master main
git push origin main
-
Change the default branch in gitlab; for librsvg this is in the repository settings / Default branch - change that to
main. -
Set the same protection for the
mainbranch as there was formaster, if any - repository settings / Protected branches -> create a new protection and copy the settings frommaster. -
Unprotect the
masterbranch so I can delete it - repository settings / Protected branches -> unprotect themasterbranch. -
Delete the
masterbranch in the branches list. -
Update the CI and build scripts: for librsvg it was just
.gitlab-ci.yml. -
Update your documentation: for librsvg it was just
COMPILING.md. -
Notify the release team; I created an issue and one for gnome-build-meta.
Update 2021/Sep/30: Extra things which Philip Withnall suggested:
-
Notify
gnome-i18n@gnome.orgso they can update the damned-lies software. (Librsvg has no translations). -
See if any project have a
librsvg.wrap(for Meson?) and notify them. I don't think I'm using search engines correctly... -
Re-protect the
masterbranch to prevent people accidentally pushing to it. Since that branch no longer exists, gitlab lets you create a protection by glob matching on a name, not an actual branch.
Update 2022/Jul/06: Some extra configuration to update:
- If your project has gitlab badges, verify that they point to the
mainbranch in settings/general/badges. You can use%{default_branch}as part of the badge URLs to avoid hardcoding names.
If you have a local checkout, you can do this:
# update from upstream
git fetch origin
# switch to your local master branch
git checkout master
# rename your local branch
git branch -m master main
# Remove the old upstream...
git branch --unset-upstream
# ... and set the new one
git branch -u origin/main
That's all!
Software obsoleting faster than Hardware
When I started my career, I was lucky to work on a legendary Operating System named Novell Netware. I got my first job because of a hacking adventure that me and my roommate Arvind did in our college on top of an upatched Netware installation. The reliability and robustness of Netware may make you believe in magic. But it was just a well-engineered, old-school product. One of the most popular instances of its robustness, was the epic uptime of 16 years as covered in arstechnica.
(Image courtesy: Arstechnica)
This was not an one-off situation either. We had multiple customers with years of uptime. In one of the academic institutes, the uptime was well into decades, that multiple sysadmins changed, but the netware box tirelessly worked on. At some point of time, nobody knew where the server was physically located, as nobody looked at it as everything worked fine.
In almost all the cases, the hardware failed before the software. The software was engineered so well that it would have run forever on superior hardware (albeit not so efficiently capable of using the modern hardware in its true potential). Those days, even the hardware was built to last for decades. It was the good old times before the planned obsolescence.
Fast forward to today, 2021. I have a Redmi 4 android phone, built by the mass manufacturer Xiaomi. I bought it on May 30th 2017 and still use it everyday. I always purchase things for long-term. I believe in BuyItForLife principles. I maintain my hardware properly (Fully discharge and then recharge, handle with care etc.). Even my prior phone, a Motorola E398 lasted me a about a decade, before the charger gave up.
Today during the lunch break, I went out looking in search of a home. My ever busy teammate Seshachalam sent a message to me on Slack at that time. I got a notification in the Android pull-down notifications. I tried to open Slack to see the message and got this error message:
Why people think that I am an IBM Power Champion?
Whenever I talked to people about POWER, someone asked if I am an IBM Power Champion. My response was that I do not even know what it is, and I am not affiliated with IBM in any way. Recently I came across a blog by Torbjörn Appehl which describes what is an IBM Power Champion and lists the European champions: https://builtonpower.com/2021/09/the-2021-ibm-power-champions-in-europe/.
Finally I know what an IBM Power Champion is, and I feel honored to be mistaken to be one of them :-) Normally I do not care much about titles: I have seen too many empty people with well sounding titles, and fantastic people without any titles. Even with this background I’d be proud to wear the IBM Power Champion badge. However, being a loud POWER advocate does not mean that I feel that I am active enough to warrant this badge.
I must admit, that knowing what an IBM Power Champion is, I am not surprised at all, that I was mistaken for an IBM Power Champion. I am a long time POWER user. Started with RS6000 boxes almost 30 years ago. I helped to install the largest POWER server in Hungary at the turn of the century. I supported Linux on the Genesi Pegasos, a PowerPC workstation, for many years. I was an active contributor and moderator on the power-developer forums and on power.org. And recently I support syslog-ng on POWER. POWER9 provided the best syslog-ng performance for years, and I have a strong suspicion that after a short break the release of POWER10 gives back the performance crown to the POWER architecture. Tead the article I wrote based on my OpenPOWER conference talk last year to see my history in detail and that I am not that active recently: I’m a POWER user
So why do people have the impression that I actively work on POWER technologies? I guess it’s because of my job. If I am enthusiastic about a technology, I talk about it loud and clear. Even if it is not part of my job. And my enthusiasm is contagious. I am a technology evangelist, and by definition it means that I advocate technologies and help them in many possible ways. For my job I work with sudo and syslog-ng, however if I like something, it receives the same treatment – in my free time. You can learn more about being an open source evangelist from my article on opensource.com: What is an open source evangelist?
Of course, I have plans related to POWER, even if I’m not too active. I’d love to test syslog-ng on a POWER10 server. However I’m patient. No matter how much I love syslog-ng, an IBM Power E1080 server is an overkill for syslog-ng both in price and performance. Especially that syslog-ng has an upper limit of 64 threads, and this server has more cores than that :-) But once POWER10 is more widespread and there are smaller boxes available as well, I’d love to verify my assumption, that POWER10 is the currently available best CPU for syslog-ng :-)
And what can I say to POWER and POWER users? Live long and prosper!
Testing Day para Plasma 5.23 edición 25 aniversario
Con el objetivo de que el próximo Plasma, el escritorio de la Comunidad KDE, sea lo más estable y pulido posible, se ha organizado un Testing Day para Plasma 5.23 edición 25 aniversario el próximo viernes 1 de octubre. ¿Te interesa? Sigue leyendo.
Testing Day para Plasma 5.23 edición 25 aniversario
Para los que lo desconozcan, un Testing Day es una jornada que tiene como objetivo buscar y reportar errores de un determinada pieza de Software.
Es este caso, y con la mente puesta en que la próxima versión de Plasma sea la mejor posible, se ha organizado para el viernes 1 de octubre una de estas sesiones.

Para apuntarse basta con comentarlo en la sala de Matrix de Plasma (accesible desde Libera IRC con #plasma) y descargar una distribución con la beta de Plasma Beta. También se puede utilizar la imagen KDE Neon.
Además, Jonathan Riddell, promotor de esta iniciativa, habilitará máquinas en shells.com para aquellos que no puedan montar su propia versión de Plasma 5.23 Beta.
La actividad se realizará desde las 11:00 UTC hasta las 23:00 UTC en las cuales se solucionaran cualquier duda sobre reportes de errores.
Si puedes participar sería estupendo, y si no, cualquier difusión de esta iniciativa será más que bienvenida.
Más información: Jonathan Esk-Riddell’s Diary
Plasma 5.23 Beta: Pruébalo y reporta errores
Si quieres participar en la iniciativa y no te viene bien el horario no te preocupes, el reporte de errores de Plasma 5.23 está abierto las 24 horas de día, los 7 días de la semana.
De hechos debéis pensar que en muchas ocasiones los errores existen porque no le han aparecido al grupo de desarrolladores ya que no se han dado las circunstancias para que lo hagan.
Para ello debes instalarte esta beta y comunicar los errores que salgan en bugs.kde.org, tal y como expliqué en su día en esta entrada del blog.
Un concurso puesto en marcha por la #FSFE para promocionar el #softwarelibre entre la juventud
La Free Software Foundation Europe (FSFE) organiza un concurso enfocado a los más jóvenes para promocionar y difundir el software libre y además poder ganar premios en metálico

La FSFE es una organización sin ánimo de lucro con más de 20 años de historioque defiende y promociona el software libre y tiene su radio de acción en Europa.
Entre sus acciones, además de defender la libertad del software, llevar a cabo campañas de liberación de software, etc, también está la de difusión del software libre.
Uno de los puntos claves en la promoción es darlo a conocer entre las generaciones más jóvenes de entre 15 y 18 años para asegurar una continuación en los valores y filosofía del software libre.
Y en este mes de octubre de 2021 empieza la iniciativa de la FSFE de poner en marcha un concurso para esa generación de jóvenes con la que poder ganar premios en metálico y a la vez difundir el software libre, la colaboración y las tecnologías.
El concurso en cuestión le han llamado “youth hacking 4 freedom” y tiene las siguientes condiciones básicas para participar:
- Los participantes deben tener entre 14 y 18 años y deben registrarse en yh4f.org
- El evento inicial tendrá lugar el 10 de octubre de 2012.
- El registro de participantes está abierto hasta el 31 de octubre de 2021.
- Seis ganadores serán galardonados con premios en metálico (2 x 4.096€, 2 x 2.048€, 2 x 1.024€) y un vaje a Bruselas.
- La competición se lleva a cabo de forma telemática. La Ceremonia de Premiados se llevará a cabo en Bruselas.
Deberán programar algo que quieran, no hay límites ni hay directrices. La única condición es que sea software libre que se puede estudiar, modificar y compartir. Puede ser algo original o pueden contribuir a algún proyecto, indicando después cuales han sido sus aportes.
Se anima a participar a todos aquellos jóvenes que quieran y que crean que pueden aportar algo, toda participación es bienvenida. Se hará algo grande o no, pero sin duda quedará el poso del software libre para siempre.
Durante el tiempo que dura el proceso no es necesario que se emplee todo el tiempo a trabajar en el proyecto. Se puede hacer a intervalos, atendiendo a otras actividades como estudios, diversión, etc! 
El código será revisado por personas con experiencia en programación para decidir quienes serán quienes merezcan los premios. No hay mejores ni peores, pero en función de la edad y del software presentado se evaluará.
También te podrán preguntar sobre tu proyecto para saber los motivos que te llevó a tal elección de las distintas características de tu software.
Animo a estudiantes a participar y a profesores a que animen a los estudiantes a unirse en este concurso. Para promocionar el software libre y un poco de ciencia entre tanta superficialidad reinante…
Échale un vistazo a las bases y a las condiciones, y aímate a dar el paso…
Software libre, para una sociedad libre.
Enlaces de interés
- https://fsfe.org/news/2021/news-20210928-01.es.html
- https://fsfe.org/activities/yh4f/
- https://fsfe.org/activities/yh4f/faq.es.html
- https://fsfe.org/index.es.html

Digest of YaST Development Sprints 131 & 132
This is our third blog post since summer started in Europe and also the third time in a row we write a combined blog post for two development sprints. And it’s also the third consecutive report focused on improvements to the existing codebase rather than on new shiny features. That covers:
- Rethinking some aspects of the management of software, keyboard layouts and NTP configuration
- Heavy work in the internals of yast2-users
- Improvements in the way YaST handles libYUI plugins
- Visual fixes in the packages manager
- More progress in the release tools
Diving into our own history
After 22 years of constant development of the same codebase, it’s not surprising that some parts of YaST2 are a bit intricate. As you know, we are lately investing time in an attempt to shed some light on some of those internals. During these latest sprints it was time for checking the configuration of the NTP client, the behavior of the keyboard layouts, the way we manage software and the administration of users and groups in already installed systems.
We don’t have much finished stuff to present yet, but we expect important changes in those four areas in the future. Regarding the management of users, we hope to report big improvements in the next blog post. Changes in the other three areas are more targeted to the mid-term, but we will keep steadily working on it.
Graceful Handling of Missing libYUI Components
And talking about YaST history and software that is still evolving after more than twenty years, we cannot forget about libYUI - the cornerstone that allows YaST to run in both graphical and text modes. LibYUI is a modular library that offers several backends (like Qt or ncurses) and also a plugins system to implement advanced widgets. So the user can install only one of the given backends or just a subset of all the available widgets. But such flexibility can be a double-edged sword.
During this sprint, we improved how YaST handles the situation in which a missing combination of plugin and backend is needed to perform the action requested by the user. The description of this pull request offers a detailed overview of the situation and the implemented solution, including screenshots.
Where is my header?
Did we mention flexibility comes with a price? :wink: Just multiply the different ways in which YaST can be used by all the architectures and environments supported by the (open)SUSE distributions and you’ll get a glimpse of all the things that can go wrong.
Recently we got a report about YaST not displaying the names of the categories in the list that shows the patches that can be installed in the system. It took us weeks to reproduce the error because it worked just fine in all the systems we tried, including virtual machines and bare metal. But turns out there was indeed in problem… visible only when executing YaST in a KVM virtual machine with a Plasma desktop.
But we finally caught the bug and you can see a screenshot and the corresponding fix in the description of this pull request.
Release Tools: Polishing
As our readers already know, the YaST Team is also trying to help with the maintenance and evolution of the (open)SUSE release tools. And nothing makes the source code more maintainable than getting rid of it. So after some months of discussions, we managed to identify and drop eight obsolete tools.
We also keep improving the documentation, not only for the tools in the repository but also updating and extending the information available in the openSUSE wiki about the openSUSE development process. Last but not least, we improved the automated tests for the tools, hopefully making them more understandable for newcomers in the process.
More news to come
Hopefully the next report will contain more details about finished work and actually released features. Meanwhile, we promise to keep working if you all promise to keep having fun!

