There are several changes happening in openSUSE’s rolling release Tumbleweed on a daily basis and integrating systemd-boot into has been evolving.

A shift from the traditional GRUB boot loader is promising better system boot performance and security.

An all-systems-go presentation by Ludwig Nussel sheds some light on the motivations, challenges and future direction of systemd-boot integration in openSUSE.

The primary motivation behind adopting systemd-boot lies in its simplicity and efficiency, especially when handling full-disk encryption. Traditional boot loaders like GRUB require embedding decryption code and key derivation functions that can complicate the boot loader code and the boot process; this could slow down the system at startup. With systemd-boot, these responsibilities are delegated to the Linux Kernel and user space, which helps to streamline the boot process.

MicroOS and Tumbleweed’s use of Btrfs and its snapshotting capabilities adds complexity to the boot process; this is being addressed by integrating systemd-boot with the snapshot management system to ensure each snapshot boots successfully and that kernel updates are handled gracefully within this dynamic environment.

To facilitate this integration, new packaging scripts and tools like sdbootutil were introduced to manage kernel versions, snapshots and boot entries. This tool plays a crucial role in making systemd-boot a practical choice for openSUSE users, as the way that the snapshots are managed are different in MicroOS than in Tumbleweed.

Using sdbootutil, the system will create new Type #1 boot entries in the EFI System Partition (ESP) to represent all the avaliable boot options, which will copy from the snapshot the new installed kernels into this partition. It will also generate good initrd for those snapshots.

When using full disk encryption, sdbootutil will also call the different commands that will update the policies required to automatically unlock the new snapshots using the internal Trusted Platform Module 2.0 (TPM2) device of the system.

Ideally, in the future, some if not all of this functionallity will be exported into systemd itself or other systems components in the distribution. These changes make this tools a good place to experiment, validate or discard the different approaches that openSUSE is leading with systemd-boot.

At this point, systemd-boot support in openSUSE is still considered experimental. Both Tumbleweed and MicroOS yast installers offer systemd-boot as an alternative to grub for the brave. There are also ready-made appliances for qemu that use systemd-boot and full-disk encryption by default.

Ayer mismo comentaba que el equipo de desarrollo de KDE había elaborado una guía para portarlos temas globales a Plasma 6 pretendiendo facilitar la migración de estos elementos tan característicoas de nuestro escritorio a los diseñadores. Pues bien, no sé si el gran Jomada ha seguido esa guía o no pero se ha apuntado el tanto de crear el primer tema Global Para Plasma 6 que ha bautzado con el nombre de Nothing (¿tendrá relación con el gran tema de Depeche Mode?) y que merece ser reconocido en este blog.

Primer tema Global Para Plasma 6: Nothing

Antes lo digo, antes aparece. Ya tenemos disponible para su descarga y aplicación algnos temas globales en la KDE Store. No obstante, y dado que suelo aprovecharme de su trabajo, hoy quiero rendir tributo al primer tema global de Plasma 6 que incluso me pareció ver que estaba incluído en el lanzamiento.

Este tema que destaca por su oscuridad y elegancia, combinando negros y grises, destacando la utiización de un rojo vivo que, evidentmente, contrasta y le mucha vida. Ha sido creado por Jomada, uno de los diseñadores más prolíficos, y en mi humilde opinión, con más gusto del ecosistema de la Comunidad KDE. Para este tema el propio Jorge recomienda el uso del tema de iconos Colloid Grey-black con lo que queda de fábula, como podéis ver en las imagen inferior.

Desde aquí agradezco de antemano el trabajo de estos diseñadores anónimos (porque aunque todo está referenciado poco caso se les hace) que invierten su tiempo en proporcionarnos opciones de tan alta calidad.

Más información: Tema Global Nothing KDE Store

Guía para portar los temas globales a Plasma 6

Debido al lanzamiento de KDE 6 (Plasma, aplicaciones y motor), y como se podía intuir, no solo el API de Plasma utilizada para crear widgets de escritorio (también conocidos como «applets» o «plasmoides«) ha cambiando sino que también se han visto afectados los temas globales, con lo que todos estos paquetes de software que cambian de con un simple click todo el aspecto de tu escritorio deberán ser adaptados ya que se pierde la compatibilidad.

Esto es tanto así que ya se ha creado la sección propia para temas de Plasma 6 en la KDE Store, aunque en el momento de escribir este artículo, ya hay casi una decena lo cual es significativo ya que nos augura un buena cantidad de opciones de personalización para nuestro entorno de escritorio en un periodo de tiempo muy corto.

Con la intención de que esto ocurra en el menor tiempo posible y que en breve tengamos un buen número de estas delicas visuales ideales para personalizar nuestro entorno de trabajo los diseñadores de KDE han creado una breve guía para portar los temas globales a Plasma 6.

En esta guía se especifica las novedades (como que ahora los temas son tratados como un kpackage lo que significa que necesitan de un archivo manifest.json para ser utilizados de forma correcta) o los grandes cambios (como que ya no se pueden utilizar enlaces simbólicos para cargar un tema Plasma).

Por supuesto, hay muchos cambios más como el cambio de nombre de las importaciones QML, en los scripts de diseño de escritorio, en las pantallas de bloqueo personalizadas o en los temas de inicio de sesión SDDM

En resumen, una excelente iniciativa que seguro que los desarrolladores de estas pequeñas (o no tanto) maravillas para nuestro

Más información: KDE Develop

La entrada Primer tema Global Para Plasma 6: Nothing se publicó primero en KDE Blog.

Recopilación y traducción del boletín mensual de noticias relacionadas con el software libre publicado por la Free Software Foundation.

La Free Software Foundation (FSF) es una organización creada en Octubre de 1985 por Richard Stallman y otros entusiastas del software libre con el propósito de difundir esta filosofía, frente a las restricciones y abusos a los usuarios por parte del software privativo.

La Fundación para el software libre (FSF) se dedica a eliminar las restricciones sobre la copia, redistribución, entendimiento, y modificación de programas de computadoras. Con este objeto, promociona el desarrollo y uso del software libre en todas las áreas de la computación, pero muy particularmente, ayudando a desarrollar el sistema operativo GNU.

Mensualmente publican un boletín (supporter) con noticias relacionadas con el software libre, sus campañas, o eventos. Una forma de difundir los proyectos, para que la gente conozca los hechos, se haga su propia opinión, y tomen partido si creen que la reivindicación es justa!!

• En este enlace podéis leer el original en inglés: https://www.fsf.org/free-software-supporter/2024/march
• Y traducido en español (cuando el equipo de traducción lo tenga disponible) en este enlace: https://www.fsf.org/free-software-supporter/2024/marzo

Puedes ver todos los números publicados en este enlace: http://www.fsf.org/free-software-supporter/free-software-supporter

Después de muchos años colaborando en la traducción al español del boletín, desde inicios del año 2020 decidí tomarme un descanso en esta tarea.

Pero hay detrás un pequeño grupo de personas que siguen haciendo posible la difusión en español del boletín de noticias de la FSF.

¿Te gustaría aportar tu ayuda en la traducción y colaborar con la FSF? Lee el siguiente enlace:

• https://victorhckinthefreeworld.com/2016/12/22/quieres-ayudar-a-traducir-el-boletin-mensual-de-la-free-software-foundation/

Por aquí te traigo un extracto de algunas de las noticias que ha destacado la FSF este mes de marzo de 2024.

Los demócratas vuelven a la carga, tratando de romper los algoritmos de caja negra abiertos

Del 16de febrero porThomas Claburn

Los legisladores demócratas han propuesto una vez más una legislación para garantizar que el código fuente del software utilizado para las investigaciones criminales pueda ser examinado y esté sujeto a pruebas estandarizadas por parte del gobierno.

El 15 de febrero, los representantes de la Cámara de Representantes Mark Takano (D-CA) y Dwight Evans (D-PA) reintrodujeron la Ley de Justicia en Algoritmos Forenses de 2024, un proyecto de ley que prohíbe el uso de afirmaciones de secretos comerciales o que los abogados defensores revisen el código fuente relevante para casos penales y establece un régimen federal de pruebas para software forense.

Dado que se puede utilizar software privativo para encarcelar de por vida a un presunto delincuente, es imperativo que estos programas sean software libre para garantizar un juicio justo.

• https://www.theregister.com/2024/02/16/black_box_government/

El software libre no es la antítesis del éxito comercial

Del 12 de febrero

Un malentendido común con respecto al concepto de software libre, o una pregunta que puede verse planteada por personas en Internet en diferentes salas de chat, foros y demás, proviene de la idea errónea de que «libre» en «software libre» significa libre como tal en «cerveza gratis», es decir, gratis.

En este artículo, Gabriel Cezarin Popovici, pasante del equipo de campañas de la Free Software Foundation (FSF), explica por qué desarrollar software libre y ganar dinero no tienen por qué excluirse mutuamente.

• https://www.fsf.org/blogs/community/free-software-is-not-antithetical-to-commercial-success

Noticias de GNU Emacs de febrero

Del 26 de febrero Sacha Chua

Sacha Chua recopila unos cuantas noticias de este mes de febrero sobre las novedades en GNU Emacs.

• 2024-02-26
• 2024-02-19
• 2024-02-12
• 2024-02-05

Estas son solo algunas de las noticias recogidas este mes, ¡¡pero hay muchas más muy interesantes!! si quieres leerlas todas (cuando estén traducidas) visita este enlace:

• https://www.fsf.org/free-software-supporter/2024/marzo

Y todos los números del «supporter» o boletín de noticias de 2024 en español, francés, portugués e inglés aquí:

• https://www.fsf.org/free-software-supporter/2024

—————————————————————

1) Introduction

The dnf5daemon-server component offers a collection of D-Bus interfaces to interact with the dnf5 package manager on the system. An openSUSE community packager wanted to add the additional D-Bus component to the openSUSE Tumbleweed distribution. New D-Bus system services require a review by the SUSE security team. In the course of this review I found the issues described in this report.

The version of dnf5 I reviewed for this is 5.1.9, and any source code references below are based on the corresponding version tag in the upstream Git repository.

2) D-Bus Interface Design

The dnf5daemon-server offers a main interface “org.rpm.dnf.v0.SessionManager” on which clients can create a new session, which results in a new dynamically allocated D-Bus object being registered on the bus. This session object provides a set of additional D-Bus interfaces for modifying package manager configuration, for installing or removing packages or for inspecting metadata about packages and repositories on the system.

The dnf5daemon-server is running as root and can be autostarted via the D-Bus system bus if it is not already running. Any other users with access to the D-Bus system bus may talk to it.

For certain privileged operations the D-Bus service implements Polkit authentication. Only three operations are protected by Polkit:

• org.rpm.dnf.v0.rpm.RepoConf.write
• org.rpm.dnf.v0.rpm.execute_transaction
• org.rpm.dnf.v0.rpm.Repo.confirm_key

These relate to changing the repository configuration, executing transactions or importing new trusted signing keys. Transactions cover all kinds of changes introduced through the package manager.

All of these operations require auth_admin privileges on Polkit level. The integration of the Polkit authorization logic is correct as far as I can tell.

The per-session D-Bus interface provided by dnf5daemon-server is rather large and many calls take additional key/value maps to tune the behaviour of the package manager logic contained in libdnf5. In summary, the libdnf5 library is attached very closely to the D-Bus system bus via dnf5daemon-server.

3) Local Root Exploit via Configuration Dictionary (CVE-2024-1929)

While the privileged operations mentioned above are correctly protected by Polkit, there are issues with the D-Bus interface long before Polkit is even invoked.

The org.rpm.dnf.v0.SessionManager.open_session method takes a key/value map of configuration entries. A sub-entry in this map, placed under the “config” key, is another key/value map. The configuration values found in it will be forwarded as configuration overrides to the libdnf5::Base configuration. The spot where this happens is found in session.cpp:63.

Practically all libdnf5 configuration aspects can be influenced here, as can be seen in the ConfigMain class in config_main.hpp. Already when opening the session via D-Bus, the libdnf5 will be initialized using these override configuration values. There is no sanity checking of the content of this “config” map, which is untrusted data.

There are surely a lot of different ways to exploit this possibility to influence the libdnf5 configuration. The simplest approach to get full root privileges I found is to trick the library into loading a plug-in shared library under control of the unprivileged user.

To do this, the “pluginpath” and “pluginconfpath” configuration entries need to be supplied and need to point to a user-controlled path. There the unprivileged user can place a configuration file that in turn points towards a user controlled shared library. The library will then dlopen() this user controlled shared library, which will lead to full code execution in the context of the root user.

3.1) Proof of Concept

A proof of concept I wrote shows this vulnerability in action. I successfully tested this exploit also on Fedora 39 using dnf5daemon-server version 5.1.10. The only precondition for this exploit is that the dnf5daemon-server package is installed on the system. Any local user, even nobody, can obtain root privileges this way.

3.2) Bugfix

To fix this, I suggested to enforce a whitelist of configuration parameters that are allowed to be overridden. Only a very small subset of values should be allowed for unprivileged clients.

In upstream commit e51bf2f0d such a whitelist enforcement has been implemented for dnf5daemon-server.

3.3) CVE Assignment

Red Hat Product Security assigned CVE-2024-1929 for this issue.

4) No Limit on Number of Open Sessions / Bad Session Close Behaviour (CVE-2024-1930)

There is no limit on how many sessions D-Bus clients may create using the open_session() D-Bus method. In my tests I was able to quickly create about 4,500 sessions and keep them open. For each session a thread is created in dnf5daemon-server. This spends a couple of hundred megabytes of memory in the process. Further connections will become impossible, likely because no more threads can be spawned by the D-Bus service.

In some cases I even managed to cause the D-Bus service to abort() as a result of hitting resource limits. If the service continues running and the client disconnects, then the cleanup code found in SessionManager::on_name_owner_changed() runs for each session that has been created. Each Session holds a ThreadsManager, where the thread associated with each session originates from. It is a thread that is busy-waiting to join other threads, the code for this is found in threads_manager.cpp:33. Since there is a sleep of one second in this thread’s loop it takes about ~4,500 seconds for all the threads from the 4,500 sessions to be joined one by one. The service will be unreachable for more than an hour.

4.1) Bugfix

To fix this, I suggested to limit the number of sessions for each unprivileged user in the system to a sensible value. Also the busy-wait loop in ThreadsManager seems ill-devised. Maybe using a condition variable to inform the cleanup thread of new work would be more efficient. Having a dedicated ThreadsManager and join-thread for each session seems a bit overkill, too.

In upstream commit c090ffeb79 the maximum number of sessions is limited to three sessions. The problematic thread joining behaviour has not been addressed as of now.

4.2) CVE Assignment

Red Hat Product Security assigned CVE-2024-1930 for this issue.

5) Untrusted locale Setting for each Session

Another part of the per-session setup is the use of an untrusted locale setting in session.cpp:54. This string is passed to the C library’s newlocale() function in threads_manager.cpp:92. A danger here is that arbitrary user controlled files or symlinks could be processed by the C library, which could lead to various issues like information leaks, denial of service or even code execution. I looked into the GNU glibc implementation of newlocale(), and luckily it already implements a very careful locale lookup algorithm, that prevents that arbitrary paths are accessed if crafted locale strings are passed to it. This outcome might change if a different C library is used.

Whether anything bad could happen, apart from file system issues, when exotic locales are selected for a thread running in dnf5daemon-server is another question that I did not investigate more closely.

For hardening purposes I suggested that dnf5daemon-server performs a sanity check of the locale string to prevent a string that contains e.g. a slash character / from being used. I don’t know of any upstream commits that address this yet, but upstream stated that they intend to work on this in the future.

6) dnfdaemon-client Demands Full Root

Although the D-Bus service implements Polkit for privileged operations, the dnf5daemon-client refuses to perform privileged operations for non-root users. For example:

user$ dnf5daemon-client distro-sync
This command has to be run with superuser privileges (under the root user on most systems).

The code for this is found in various sub-command implementations:

$ grep -r 'throw UnprivilegedUserError' -C 1
dnf5daemon-client/commands/downgrade/downgrade.cpp-    if (!libdnf5::utils::am_i_root()) {
dnf5daemon-client/commands/downgrade/downgrade.cpp:        throw UnprivilegedUserError();
dnf5daemon-client/commands/downgrade/downgrade.cpp-    }
--
dnf5daemon-client/commands/distro-sync/distro-sync.cpp-    if (!libdnf5::utils::am_i_root()) {
dnf5daemon-client/commands/distro-sync/distro-sync.cpp:        throw UnprivilegedUserError();
dnf5daemon-client/commands/distro-sync/distro-sync.cpp-    }
--
dnf5daemon-client/commands/install/install.cpp-    if (!libdnf5::utils::am_i_root()) {
dnf5daemon-client/commands/install/install.cpp:        throw UnprivilegedUserError();
dnf5daemon-client/commands/install/install.cpp-    }
--
dnf5daemon-client/commands/remove/remove.cpp-    if (!libdnf5::utils::am_i_root()) {
dnf5daemon-client/commands/remove/remove.cpp:        throw UnprivilegedUserError();
dnf5daemon-client/commands/remove/remove.cpp-    }
--
dnf5daemon-client/commands/upgrade/upgrade.cpp-    if (!libdnf5::utils::am_i_root()) {
dnf5daemon-client/commands/upgrade/upgrade.cpp:        throw UnprivilegedUserError();
dnf5daemon-client/commands/upgrade/upgrade.cpp-    }
--
dnf5daemon-client/commands/reinstall/reinstall.cpp-    if (!libdnf5::utils::am_i_root()) {
dnf5daemon-client/commands/reinstall/reinstall.cpp:        throw UnprivilegedUserError();
dnf5daemon-client/commands/reinstall/reinstall.cpp-    }

It doesn’t make sense that the client forces users to run as root (and thereby increase the attack surface by running also the client code as root) when the service could authenticate the user via Polkit.

I suggested to drop this root-check code in the client, and rely on the authentication logic in the service side code. If authentication fails, then the client code can still hint at the possibility to run the program as root. I am not aware on any upstream commits that address this yet, but upstream stated that they intend to work on this in the future.

7) General Review Summary

In summary my impression is that the libdnf5 library is too closely connected to the D-Bus system bus. The library itself is unaware of the fact that it is running with partially untrusted input. The dnf5daemon-server code needs to carefully filter untrusted input before it is passed to the generic library code.

8) Timeline

9) References

• dnf5 repository on GitHub
• dnf5 5.1.9 Git version tag (the version that has been reviewed)
• code that imports untrusted configuration settings into libdnf5
• bugfix commit for issue 3)
• bugfix commit for issue 4)

El pasado 28 de febrero fue el megalanzamiento 6 de la Comunidad KDE. De una tacada tuvimos disponible Plasma 6, KDE Gears 24.02 y KDE Frameworks 6, la trinidad del desarrollo de KDE. Pero en realidad faltaba una pieza de este gran engranaje. Me complace compartir con vosotros que Plasma Mobile salta también a Plasma 6, con lo que ya tenemos todas las columnas el proyecto preparadas para seguir evolucionando y llevando el Software Libre a nuevas cuotas de grandeza.

Plasma Mobile salta también a Plasma 6

Se me acumulan los lanzamientos. Tengo pendiente desgranar todos los lanzamiento de la Comunidad KDE pero hoy domingo quiero dedicarlo al proyecto dedicado a los dispositivos más portables que podemos tener en nuestras manos: los smartphones y las tabletas.

Y es que el pasado 1 de marzo fue anunciado que a la estela del Megalanzamiento se realizaba también el salto de Plasma Mobile a las tecnologías Qt6/KF6 de la Comunidad KDE, lo cual significaba una mejora importante y, lo más importante, la sincronización de todos los productos de la «marca» KDE.

En palabras de sus desarrolladores:

El equipo de Plasma Mobile se complace en anunciar el lanzamiento de Plasma 6 para dispositivos móviles.
Ha sido un largo año de desarrollo y adaptación desde nuestra última versión importante del shell, así como de las aplicaciones móviles.

Y, a continuación, nos invitan a leer su larga entrada donde describen las novedades más detacadas y nos emplazan visitar una entrada específica Devin de para conocer los detalles técnicos de Plasma 6 en Plasma Mobile.

Más información: Plasma Mobile

¿Qué es Plasma Mobile?

Para los que no lo conozcan Plasma Mobile es la alternativa libre a interfaz gráfica para smartphones de la Comunidad KDE, hablé de él hace un tiempo y, poco a poco, se está convirtiendo en un clásico del blog.

Su idea es muy simple, tras conquistar tu escritorio KDE la Comunidad también quiere conquistar tu teléfono móvil… aunque todavía lo tenga complicado por todas las limitaciones de hardware que todavía tiene este campo de la tecnología.

No obstante, confiemos que de igual forma se han ido conquistando los ordenadores de sobremesa, portátiles y servidores, lleguemos un día que podamos tener libertad total en nuestros smartphones.

Y para cuando eso ocurra la Comunidad KDE estará preparada para ello y por eso está confeccionando un catálogo más que decente de aplicaciones con tecnología adaptativa.

La entrada Plasma Mobile salta también a Plasma 6 se publicó primero en KDE Blog.

Hace unos días lo comentaba, los grandes cambios de versiones tienen una cara extremadamente positiva ( ya que de lo contrario no se realizarían) y algunos aspectos negativos como puede ser un número de bugs más alto de lo habitual o la pérdida de funcionalidades o plasmoides temporal… o la imposibilidad de usar temas globales si no se hacen algunos cambios. Como ocurrió con los plasmoides, el equipo de desarrollo de KDE ha elaborado una guía para portar los temas globales a Plasma 6 y que pretende facilitar la migración de estos elementos tan característicoas de nuestro escritorio. En mi opinión, como dije con los plasmoides, una extraordinaria iniciativa.

Guía para portar los temas globales a Plasma 6

Como ya se podía intuir, no solo el API de Plasma utilizada para crear widgets de escritorio (también conocidos como «applets» o «plasmoides«) ha cambiando para la versión Plasma 6.0 sino que también se van a ver afectados los temas globales, con lo que todos estos paquetes de software que cambian de con un simple click todo el aspecto de tu escritorio deberán ser adaptados ya que se pierde la compatibilidad.

Esto es tanto así que ya se ha creado la sección propia para temas de Plasma 6 en la KDE Store, aunque en el momento de escribir este artículo, no hay ninguno creado, lo cual es significativo y, evidentemente, deber ser solucionado con rapidez.

Con la intención de que esto ocurra en el menor tiempo posible y que en breve tengamos un buen número de estas delicas visuales ideales para personalizar nuestro entorno de trabajo los diseñadores de KDE han creado una breve guía para portar los temas globales a Plasma 6.

En esta guía se especifica las novedades (como que ahora los temas son tratados como un kpackage lo que significa que necesitan de un archivo manifest.json para ser utilizados de forma correcta) o los grandes cambios (como que ya no se pueden utilizar enlaces simbólicos para cargar un tema Plasma).

Por supuesto, hay muchos cambios más como el cambio de nombre de las importaciones QML, en los scripts de diseño de escritorio, en las pantallas de bloqueo personalizadas o en los temas de inicio de sesión SDDM

En resumen, una excelente iniciativa que seguro que los desarrolladores de estas pequeñas (o no tanto) maravillas para nuestro

Más información: KDE Develop

La entrada Guía para portar los temas globales a Plasma 6 se publicó primero en KDE Blog.

Tumbleweed es una distribución de GNU/Linux «Rolling Release» o de actualización contínua. Aquí puedes estar al tanto de las últimas novedades.

openSUSE Tumbleweed es la versión «rolling release» o de actualización continua de la distribución de GNU/Linux openSUSE.

Hagamos un repaso a las novedades que han llegado hasta los repositorios esta semana.

Y recuerda que puedes estar al tanto de las nuevas publicaciones de snapshots en esta web:

• https://victorhck.gitlab.io/tumbleweed_snapshots/

El anuncio original lo puedes leer en el blog de Dominique Leuenberger, publicado bajo licencia CC-by-sa, en este este enlace:

• https://dominique.leuenberger.net/blog/2024/03/opensuse-tumbleweed-review-of-the-week-2024-09/

Esta semana se han publicado 6 nuevas snapshots (0223, 0225, 0226, 0227, 0228, y 0229) con cambios tan importantes como estos:

• libjxl 0.10.0 & 0.10.1
• Samba 4.19.5
• Linux kernel 6.7.6
• mdadm 4.3
• Mozilla Firefox 123.0
• chrony 4.5
• openSSH 9.6p1
• fwupd 1.9.14
• exiv2 0.28.2
• Ruby 3.2 ha sido eliminado: esto incluye todas las gemas de ruby y el interpretador de ruby 3.2

Y para próximas actualizaciones, se está trabajando en:

• ImageMagick 7.1.1.29
• openblas 0.3.26
• openjpeg 2.5.1
• KDE Frameworks and Plasma 6
• KDE Gear 24.02.0 – Requiere KDE Frameworks 6
• Systemd 255.3
• dbus-broker
• libxml 2.12.x
• GCC 14

Si quieres estar a la última con software actualizado y probado utiliza openSUSE Tumbleweed la opción rolling release de la distribución de GNU/Linux openSUSE.

Mantente actualizado y ya sabes: Have a lot of fun!!

Enlaces de interés

• ¿Por qué deberías utilizar openSUSE Tumbleweed?
• zypper dup en Tumbleweed hace todo el trabajo al actualizar
• ¿Cual es el mejor comando para actualizar Tumbleweed?
• ¿Qué es el test openQA?
• http://download.opensuse.org/tumbleweed/iso/
• https://es.opensuse.org/Portal:Tumbleweed

——————————–

Dear Tumbleweed users and hackers,

This week was truly crazy for the staging masters — apologies to Ana for flooding you with requests. Many contributors have been busy preparing our packages for RPM 4.20 (which is still at least half a year out – but we preferred to fix things now rather than being under pressure then). When the effort started on Feb 20, we had 2066 spec files that would have failed to build with RPM 4.20. Today, just 10 days later, we have less than 700 – and many requests in the queue to address those.

Of course, that’s not everything that happened this week. We have again delivered six snapshots (0223, 0225, 0226, 0227, 0228, and 0229) with the following changes:

• libjxl 0.10.0 & 0.10.1 (this time the update went without fallout)
• Samba 4.19.5
• Linux kernel 6.7.6
• mdadm 4.3: stricter on naming devices posix compliant
• Mozilla Firefox 123.0
• chrony 4.5
• openSSH 9.6p1
• fwupd 1.9.14
• exiv2 0.28.2
• Ruby 3.2 has been removed: this includes all the ruby gems AND the ruby 3.2 interpreter

The staging lists and backlog are largely filled with the same old topics:

• ImageMagick 7.1.1.29
• Python 3.x fixes for CVE-2023-6597 (TmpDir cleaning)
• openblas 0.3.26: breaks python-networkx, and python-scikit-learn
• openjpeg 2.5.1: breaks ghostscript
• KDE Frameworks and Plasma 6: Staging turns out to be messy
• KDE Gear 24.02.0 – Requires KDE Frameworks 6
• Systemd 255.3
• python 3.9 deprecation: we decided to postpone this a little but, due to the still large fallout from Python 3.12 addition. Removing a Python flavor will require us to rebuild all the Python packages for the new builds to drop the python39 flavor. Too many packages fail to build at this moment.
• dbus-broker: a big step forward; upgrades seem to be an issue that needs to be addressed
• libxml 2.12.x: slow/no progress
• GCC 14: phase 2: use gcc14 as the default compiler