Como los lectores habituales del blog sabrán,el 28 de febrero de 2024 la Comunidad KDE realizó un importante salto tecnológico, uno que marcó su evolución para los próximos años. Este gran cambio a las librerías Qt 6 nos proporcionó el nuevo escritorio Plasma 6, del que ya he hablado a lo largo de muchas entradas. Pero no solo fue eso, sino que además nos trajo el salto también a KDE Frameworks 6, las librerías propias del proyecto KDE. Hoy 10 de septiembre ha sido anunciado la trigésima actualización de KDE Frameworks 6, el motor del proyecto que soporta todo el resto de la infraestructura. Como extra de este año voy a complementar esta serie con el listado y descripción de los componentes de esta importante pieza de la maquinaria de KDE.

Trigésima actualización de KDE Frameworks 6 y librería KCoreAddons

A pesar de que para los usuarios corrientes esta noticia sea algo confusa ya que no se trata de realzar una nueva aplicación ni de una nueva gran funcionalidad del escritorio, el desarrollo de KDE Frameworks tiene repercusiones directas en él a medio y largo plazo.

Para los que no lo sepan, KDE Frameworks añade unas 83 librerías a la propias de Qt que proporcionan una gran variedad de funcionalidades necesarias y comunes, precisadas por los desarrolladores, testeadas por aplicaciones especí­ficas y publicadas bajo licencias flexibles.

De esta forma, KDE Frameworks se convierte en la base de trabajo de los desarrolladores para realizar sus aplicaciones o sus desarrollos para los entornos de trabajo (escritorio para ordenadores, plasma mobile, etc).

Un buen símil es que KDE Frameworks es como el papel y las herramientas de dibujo para un artista: cuanto mejor sea el papel y mejores pinceles tenga, la creación de una artista será mejor.

Como he dicho, el pasado 28 de febrero de 2024 KDE Frameworks saltó de la versión 5 a la 6, y el 10 de septiembre de 2026 fue anunciado que ya tenemos la trigésima actualización de la rama, es decir, que ha sido lanzado KDE Frameworks 6.30.

Hay que destacar que esta versión forma parte de una srie de versiones mensuales planificadas para poner las mejoras a disposición de los desarrolladores de forma rápida y previsible y que es absolutamente recomendable su actualización.

Más información: KDE |KDE Frameworks en el blog.

Librería KCoreAddons

Tal y comenté el a principio de año, voy a ir describiendo cada una de las librerías que nos ofrece KDE Frameworks. El mes de febrero empecé con la única de Tier 0, o nivel base de KDE Frameworks, Extra CMake Modules (ECM), y desde el mes de marzo inicié la serie de las Tier 1 con Attica, BluezQt,KArchive, KCalendarCore, KCodecs y KConfig.

Este mes seguimos con la séptima librería de KDE Frameworks, KCoreAddons cuya función principal es simplemente añadir extensiones y utilidades a QtCore. Y ya que estamos, ¿qué es QtCore? Pues es el módulo base del framework Qt: contiene las clases fundamentales, no gráficas, sobre las que se construye el resto de Qt.

Todas esta idea, para alguien como yo que no es programador se queda algo corta ya que no entiendo bien que son las clases, así que en un intento de saber más he buscado la definición de clase y me sale que es una plantilla o «molde» que define:

• Datos que va a guardar (llamados atributos o propiedades). Ej: un QString guarda internamente el texto y su longitud.
• Comportamientos que puede realizar (llamados métodos o funciones). Ej: QString tiene métodos como toUpper(), length(), split().

Así, a partir de una clase se crean objetos (instancias concretas). Veamos una analogía: La clase es el plano; el objeto es la casa construida con ese plano.

Por tanto, lo que realmente hace KCoreAddones es añadir clases para el ecosistema KDE basadas en QtCore.

En otras palabras, QtCore aporta las clases base y genéricas (texto, archivos, hilos, tiempo, etc.), pensadas para cualquier aplicación Qt, sin ninguna orientación concreta y KCoreAddons toma esas piezas genéricas y construye clases específicas encima, pensadas para necesidades más concretas que aparecen en aplicaciones de KDE: gestión de tipos MIME, guardado automático, copias de seguridad, generación de aleatoriedad, sustitución de macros en texto, información de usuarios del sistema, etc.

Más información:

• Página principal: https://api.kde.org/kcoreaddons-index.html
• Repositorio Git: https://github.com/KDE/KCoreAddons

Las librerías de KDE Frameworks 6

Las librerías que conforman KDE Frameworks se categorizan, según podemos leer en la documentación de KDE API Reference/KDE Libraries, en varios niveles de complejidad, categorías o, en inglés,Tier, que es como lo vamos a leer en muchos sitios.

De esta forma tenemos el siguiente listado categorizado.

Tier 0: nivel base de KDE Frameworks, independiente de cualquier otro framework de KDE.
Extra CMake Modules (ECM)
Módulos extra de CMake

Tier 1: dependen solo de Qt (y posiblemente un pequeño número de otras bibliotecas de terceros), por lo que pueden usarse fácilmente en cualquier proyecto basado en Qt.

Tier 2: dependen adicionalmente de frameworks de Tier 1, pero aún tienen dependencias fácilmente manejables.

Tier 3: son generalmente paquetes más potentes y completos, y por consiguiente tienen dependencias más complejas.

Tier 4: pueden ser en gran parte ignorados por los programadores de aplicaciones; este tier consiste en plugins que actúan en segundo plano para proporcionar funcionalidad adicional o integración de plataforma a frameworks existentes (incluyendo Qt).

El único tier de esta categoría o nivel es FrameworkIntegration

En un futuro iremos describiendo cada una de estas librerías, con sus usos más comunes.

• 
  Trigésima actualización de KDE Frameworks 6 y librería KCoreAddonsseptiembre 10, 2026
  El pasado 14 de agosto fue anunciado la vigesimonovena actualización de KDE Frameworks 6, el motor del proyecto que soporta todo el resto de la infraestructura.
• 
  Vigesimonovena actualización de KDE Frameworks 6 y KConfigagosto 18, 2026
  El pasado 14 de agosto fue anunciado la vigesimonovena actualización de KDE Frameworks 6, el motor del proyecto que soporta todo el resto de la infraestructura.
• 
  Vigesimoctava actualización de KDE Frameworks 6 y librería KCodecsjulio 11, 2026
  Actualización de octubre del 2022 de KDE Frameworks
• 
  Vigesimoséptima actualización de KDE Frameworks 6 y librería KCalendarCorejunio 12, 2026
  Actualización de octubre del 2022 de KDE Frameworks
• 
  Vigesimosexta actualización de KDE Frameworks 6 y librería KArchivemayo 10, 2026
  Actualización de octubre del 2022 de KDE Frameworks
• 
  Vigesimoquinta actualización de KDE Frameworks 6 y librería Librería BluezQtabril 11, 2026
  Actualización de octubre del 2022 de KDE Frameworks

La entrada Trigésima actualización de KDE Frameworks 6 y librería KCoreAddons se publicó primero en KDE Blog.

Veremos cómo lanzar un script (o cualquier otra tarea) en un equipo remoto mediante SSH y dejarlo ejecutándose en segundo plano con una sesión de tmux, de forma que siga funcionando aunque cerremos la conexión.

Este artículo surgió como una búsqueda de una necesidad que tenía. Lo que quería era conectarme a un equipo remoto mediante ssh, y en ese equipo remoto, lanzar una tarea, en mi caso dejar corriendo un script, y poder dejarlo funcionando en segundo plano en el equipo remoto aunque me desconectara de ssh.

La solución que encontré fue utilizar tmux, una herramienta que permite crear sesiones de terminal persistentes y volver a ellas más adelante. Podemos iniciar una tarea en el equipo remoto, desconectarnos y dejar que continúe ejecutándose sin necesidad de mantener abierta la conexión SSH. Veamos cómo hacerlo.

Primero defino el escenario, un equipo local desde el que me conecto a un equipo en remoto (ambos con GNU/Linux, por supuesto) mediante ssh. Y en el equipo remoto quiero dejar corriendo un script aunque después me desconecte o incluso apague el equipo local.

Las sesiones en tmux

Una vez conectado mediante ssh al equipo remoto, la clave es ejecutar tmux y abrir una nueva sesión. Según la definición de las sesiones en la web de tmux:

Una sesión tmux es un espacio de trabajo persistente que agrupa ventanas y paneles y continúa ejecutándose en segundo plano incluso después de desconectarse. Las sesiones sobreviven caídas de SSH, cambios de red y cierres de terminales, lo que convierte a tmux en la herramienta estándar para el trabajo con servidores remotos.

Vale, es algo muy sencillo para quien trabaja de administrador de sistemas y se tiene que conectar a equipo, pero yo no lo sabía y por eso este tutorial (para mi yo del futuro y para ti).

Abrir una sesión en tmux en el equipo remoto

Vale, conectados al equipo remoto (en el que tiene que estar instalado tmux, of course!) ahora vamos a abrir una sesión a la que le pondremos un nombre para identificarla (pondremos el nombre que queramos). Para ello en el equipo remoto ejecutamos:

tmux new -s nombre_sesión

Y nos abrirá tmux con la sesión que hayamos nombrado. Ahora podemos hacer lo que necesitemos. En mi caso quiero dejar corriendo un script. Lo ejecuto y lo dejo corriendo

Desconectarse de la sesión

Con el script corriendo en la sesión recién creada, podemos dejarlo corriendo y desconectarnos de la sesión mientras el script sigue funcionando en segundo plano.

Para eso ejecutamos

Ctrl+a d

Aquí cabe destacar que tmux utiliza una combinación de teclas para ejecutar comandos a la que llaman prefix. De manera predeterminada es Ctrl+b, pero yo la tengo modificada a Ctrl+a. Si tu no la has cambiado seguirá siendo Ctrl+b (una combinación de teclas poco cómoda de pulsar)

Por tanto pulsamos (en mi caso) Ctrl+a (soltamos) y después la tecla d, para decirle a tmux que queremos desconectarnos de la sesión.

Tmux se cierra, pero la sesión con nuestro script en segundo plano sigue activa, mostrando en la terminal el mensaje:

[detached (from session nombre_sesion)]

Ahora podemos desconectarnos de ssh si queremos.

Volver a conectarnos a una sesión previa

Más tarde, podremos volver a conectarnos a esa sesión de tmux en la que dejamos corriendo nuestro script. Para ello, podemos hacer que tmux nos de un listado de las sesiones activas, para eso ejecutamos:

tmux ls

Y nos mostraría algo similar a (cambiando nombre y fechas, obviamente):

script_monitor: 1 windows (created Wed Sep  9 15:05:21 2026)
prueba2: 1 windows (created Wed Sep  9 16:41:26 2026)

Vale, pues queremos conectarnos a la sesión script_monitor para eso ejecutamos

tmux a -t script_monitor 

Y se abrirá tmux tal como lo habíamos cerrado previamente, con sus ventanas o divisiones si las hubiera y nuestro script ha estado funcionando todo el tiempo normalmente.

Terminar una sesión

Después ya podremos detener el script y cerrar la ventana de tmux con Ctr+a x y terminará la sesión.

O podremos matar la sesión sin entrar en ella mediante

tmux kill-session -t nombre_sesión

Espero que os haya resultado útil. Yo lo he necesitado estos días para conectarme a mi miniPC desde el portátil y dejar corriendo unos scripts y quería compartirlo por el blog, aunque sé que es un tema que se ha tratado en otros muchos sitios.

Enlaces de interés

• https://tmux.app/sessions/
• https://victorhckinthefreeworld.com/2021/05/17/guia-visual-sobre-tmux/
• https://victorhckinthefreeworld.com/2018/01/23/guia-rapida-de-tmux-expande-las-posibilidades-de-la-consola-de-linux/

Hace mucho tiempo que tenía ganas de traer a esta creadora de contenidos al blog porque su canal rezuma calidad por todos los lados y, por fin, lo hago con un vídeo titulado «35 años de Linux: 35 curiosidades que cambiaron la informática» de «La Chica de Sistemas» con el que conmemoraba el aniversario de un proyecto que ha cambiado el mundo. No os lo podéis perder.

35 años de Linux: 35 curiosidades que cambiaron la informática

El mundo de los creadores de contenido de GNU/Linux en grandes plataformas como Youtube es reducido, algo que parece que está cambiando poco a poco. Si buscas por la red de vídeos más grande la internet (ojalá fuera libre) nos encontramos con canales como «Salmorejo Geek«, «Aprendiendo con Marga«, «Linux Center», «Planeta Tecno«, «Juan J.J. – Linuxeroerrante» , o el extinto «Karla’s Project» (que esperemos que un día vuelva con nosotros). Seguro que me dejo alguno, ponédmelo en comentarios.

A esta lista creciente de canales hay uno que merece la pena subscribirse por muchas razones entre las que destacan la calidad de los mismos y su cadencia: La Chica de Sistemas.

Si visitáis el canal os podéis encontrar vídeos de todo tipo desde filosofía y programación a sistemas operativos y Software Libre, sin olvidar historia, administración de sistemas o tutoriales, en los cuáles La Chica de Sistemas demuestra un amplio conocimiento en todas las ramas de la informática.

Siendo más técnico, y para los que les gustan los números, el canal presenta unos 64 vídeos, no son muchos pero cada vídeo tiene gran calidad por lo que todos son recomendables, y unos 48.000 suscriptores, lo que supone disponer de una comunidad consolidada dentro de un nicho especializado como la administración de sistemas Linux/Unix, la programación y el desarrollo.

Sin más, os dejo el maravilloso vídeo «35 años de Linux: 35 curiosidades que cambiaron la informática» y os invito a suscribiros y a darle a la campanita. Seguro que no os arrepentís… y seguro que no será el único vídeo que promociono desde el blog.

En palabras de su creadora

¿Cómo pasó un proyecto «solo por diversión» a dominar el mundo? En este video exploramos la historia de Linux a través de 35 curiosidades increíbles en su 35 aniversario.

Desde el primer mensaje de Linus Torvalds hasta cómo el kernel de Linux se convirtió en la base de internet, los superordenadores y hasta los teléfonos que usamos hoy.

Si te apasiona la informática, los sistemas operativos y quieres entender por qué Linux cambió el mundo para siempre, este recorrido por sus secretos mejor guardados es para vos.

El 25 de agosto de 1991, un estudiante finlandés de 21 años publicó un mensaje en Usenet anunciando que estaba desarrollando un sistema operativo libre, «solo por hobby» y que «no sería nada grande ni profesional como GNU».

Treinta y cinco años después, ese experimento casero se convirtió en el kernel Linux: la pieza de software que transformó la historia de la informática y sobre la que corre prácticamente toda la infraestructura digital moderna, desde servidores en la nube y supercomputadoras hasta teléfonos móviles y misiones espaciales.

Para celebrar este 35° aniversario, repasamos 35 historias, secretos de arquitectura, debates históricos y curiosidades que marcaron el camino de esta obra maestra del código abierto.

Si os ha gustado el vídeo y el canal, no dejéis de visitarlo, suscribiros y compartirlo.

La entrada «35 años de Linux: 35 curiosidades que cambiaron la informática» de La Chica de Sistemas se publicó primero en KDE Blog.

There is a question that comes up often in openSUSE forum threads or a Reddit comment section and that is what version of X does one actually get on Leap versus Tumbleweed?

Until recently the honest answer was very often “go look it up yourself, package by package” unless someone actually had the answer.

Now there is a better one.

The openSUSE version diff tool!!! Yes github.com/openSUSE/osdiff tooling generates a complete, machine-built comparison of source package versions across Tumbleweed and the current Leap releases.

The idea of listing source package versions in a consumable format grew out of a discussion community member Axel Braun raised at a weekly Release Engineering meeting. The site republishes itself automatically. No guessing, no anecdotes, no six-month-old blog post. Just the numbers.

The tool pulls the archive indexes straight from download.opensuse.org; this is for open-source software (oss) and non-oss, x86_64 and noarch and it’s done for Tumbleweed, Leap 16.1, and Leap 16.0; then it compares the upstream version of every source package it finds. The result is a single sortable, filterable table with a timestamp on it.

The scale is worth pausing on. A recent run covers 17,532 source packages: 17,143 in Tumbleweed, 10,574 in Leap 16.1, 10,551 in Leap 16.0, with 10,264 present in both Tumbleweed and Leap 16.1. Every package lands in one of five status buckets:

The page carries maintainer information and it is careful about what it claims: only the upstream version is compared, not the RPM release. That distinction matters, and the tool states it up front rather than quietly blurring it.

Open data changes the conversation. The single most valuable thing here isn’t the HTML page. It’s the downloads sitting at the bottom of it: diff.json, diff.json.gz, and diff.csv.

This open data turns a nice webpage into infrastructure. Anyone can pull the JSON, and the shape of the data is stable enough to build on. Which is where use cases start multiplying.

• Prospective users deciding between Leap and Tumbleweed. Someone who needs a specific toolchain version for work can confirm it in ten seconds rather than installing and finding out.

• Media, reviewers, and documentation writers can immediately find information they need to dive deeper into a related topic. This page gives a journalist instant information to help them determine if a flavor of openSUSE has exposure fixes. Distribution comparisons are notoriously prone to stale or half-remembered version numbers, and a wrong number in a review can stick around for years in search results. A citable, timestamped, auto-generated source removes the excuse for guessing. If you write about openSUSE, you now have a footnote you can actually point at.

• Aggregators like DistroWatch where the site tracks package versions across dozens of distributions do enormous manual or semi-manual work to keep tables current. Machine-readable exports of an entire distribution’s package set, refreshed automatically, is exactly the kind of upstream cooperation that makes that work cheaper and more accurate. What do you say DistroWatch? Want to know “what’s in what” tables.

• Packagers and maintainers get immediate knowledge. The tool attaches the maintainer names to those rows so somebody knows who to ask.

• Contributors looking for a first task. One of the hardest parts of joining a distribution project is finding something concrete to do. A filtered list of packages that are behind, with maintainers listed, is a genuinely welcoming on-ramp.

• Sysadmins and platform teams gain quick confirmation for their development. Before migrating a fleet from Leap 16.0 to 16.1, or evaluating whether a workload can move from Tumbleweed to Leap, the practical question is which dependencies shift and by how much. The 16.0-versus-16.1 columns answer that directly, and the CSV drops into a spreadsheet or a diff script without ceremony.

• Developers targeting openSUSE will know which library versions your users will have, this is the compatibility matrix. It also tells you whether your own package is present in Leap at all.

• Researchers and the merely curious can have a lot of fun with the open-data. Full-distribution version data, published openly on a recurring basis, is a dataset. Software-ecosystem researchers and people who just enjoy graphing things now have raw material that didn’t exist in convenient form before.

Having Leap package versions visible alongside Tumbleweed’s is a meaningful shift in how a release gets communicated. Historically, “what will be in the next Leap?” was answered in release notes near the end of the cycle, or reconstructed by people willing to dig through OBS. Publishing the state of the in-development distribution as it evolves means the community can see the release taking shape rather than being handed a finished summary.

Small tools like this rarely get the attention they deserve, but a table that is always correct, always current, and freely downloadable quietly removes an entire category of friction from a project. We hope you enjoy it.

Me alegra compartir con todos vosotros la quinta actualización de Plasma 6.7, continuando así la serie de revisión de software que le dotará de más estabilidad, mejores traducción y resolución de errores. Estas actualizaciones son 100% recomendables y casi obligatorias para cualquier usuario ya que lo único que hacen es mejorar la versión sin comprometer sus funcionalidades.

Quinta actualización de Plasma 6.7

No existe Software creado por la humanidad que no contenga errores. Es un hecho incontestable y cuya única solución son las actualizaciones. Es por ello que en el ciclo de desarrollo del software creado por la Comunidad KDE se incluye siempre las fechas de las mismas siguiendo una especie de serie de Fibonacci.

Así que me congratula en presentar que hoy martes 8 de septiembre de 2026, unos meses después de liberar el código de Plasma 6.7 la Comunidad KDE presenta la quinta actualización de errores.

Más información: KDE

Las novedades generales de Plasma 6.7

Aprovecho para realizar un listado de las novedades generales de Plasma 6.7:

• Escritorios virtuales por pantalla: Ahora es posible configurar escritorios virtuales de forma independiente para cada monitor.
• Prueba del volumen del micrófono: Se ha añadido una herramienta para comprobar los niveles de entrada de audio, facilitando el diagnóstico de problemas con el micrófono.
• Caracteres especiales en teclado virtual: Al usar el teclado virtual, es posible mantener pulsada una tecla para acceder a los caracteres especiales asociados a ella.
• Interruptor rápido de temas: Se incluye un nuevo control para cambiar instantáneamente entre los temas globales claros y oscuros.
• Calendario lunar vietnamita: Se ha integrado este calendario en el sistema para permitir su uso junto al gregoriano.
• Mejora en «Aplicaciones en segundo plano»: La bandeja del sistema ahora muestra también las aplicaciones que utilizan el sistema de segundo plano moderno, frecuente en paquetes Flatpak.
• Monitorización de impresión: El icono de la bandeja del sistema para impresoras ahora muestra una placa indicando el número de trabajos activos.
• Gestión de colas de impresión: Se ha introducido una nueva herramienta para gestionar colas de impresión, diseñada tanto para un uso doméstico sencillo como para la gestión avanzada de múltiples impresoras.
• Acceso rápido a escritorios en Vista general: Desde la Vista general (Meta + W), ahora es posible cambiar entre escritorios virtuales usando el ratón o las teclas RePág y AvPág.
• Favoritos por arrastrar y soltar: Se ha simplificado la gestión de favoritos en los lanzadores y menús de aplicaciones mediante la función de arrastrar y soltar.

Más información: KDE

• 
  Tantas maneras de hacer clic y desplazarse – Esta semana en Plasmaseptiembre 5, 2026
  Bienvenidos a «Tantas maneras de hacer clic y desplazarse» de «Esta semana en Plasma», donde nos presentan como se sigue preparando Plasma 6.8 para ser un nuevo hito en el desarrollo de este entorno de trabajo libre.
• 
  Las aplicaciones de QtWidgets se unen a Union – Esta semana en Plasmaagosto 29, 2026
  Bienvenidos pues a «Las aplicaciones de QtWidgets se unen a Union» de «Esta semana en Plasma», donde nos presentan como se sigue preparando Plasma 6.8 para ser un nuevo hito en el desarrollo de este entorno de trabajo libre.
• 
  Mejoras en la interfaz y en el rendimiento – Esta semana en Plasmaagosto 22, 2026
  «Mejoras en la interfaz y en el rendimiento» de «Esta semana en Plasma», donde nos presentan como se está preparando Plasma 6.8 para ser un nuevo hito en el desarrollo de este entorno de trabajo libre.

La entrada Quinta actualización de Plasma 6.7 se publicó primero en KDE Blog.

Después de 25 años, ha llegado el momento de pasar el relevo del proyecto Packman. Si no se encuentra a nadie que desee continuar con Packman, se suspenderá el proyecto el 31/12/2026.

El pasado 27 de agosto de 2027 en un correo en alemán e inglés a la lista de correo del proyecto, se anunciaba que los actuales responsables del proyecto Packman tenían intención de dejar su papel y pasarle el testigo a quien quisiera hacerse cargo.

Si no encontraban a nadie que tuviera conocimientos, tiempo y dinero para mantenerlo, el próximo 1 de enero de 2027 todo sería ya historia después de 25 años de servicio.

Llevo utilizando openSUSE desde 2011, más o menos, y desde siempre, nada más instalar el sistema, a la hora de configurar los repositorios, una de las primeras cosas que siempre hacía, era añadir el repositorio Packman en openSUSE y darle además una prioridad mayor frente a los repositorios oficiales de openSUSE.

Así que cuando me he enterado de la noticia, me he sentido primero un poco descolocado y después me he dado cuenta, que nunca podemos dar nada por sentado para siempre.

¿Qué es el repositorio Packman?

Según las propias palabras del proyecto:

Nos dedicamos a agrupar el software en paquetes para facilitar la instalación y la desinstalación en un entorno linux. Con ello pretendemos sobre todo publicar los paquetes de software que o bien no están incluidos en las distribuciones o bien la versión incluida está ya desfasada.

Por principio, Packman, está abierto a todas las distribuciones. Pero la distribución para la cual ofrecemos paquetes depende en definitiva de la distribución que use o apoye cada uno de los miembros del equipo PackMan.

Actualmente los paquetes que ofrecemos son básicamente para SUSE Linux, pero también existen paquetes para Fedora.

Packman es un repositorio de software no oficial de openSUSE muy completo y de gran calidad, hasta tal punto que muchos de quienes utilizamos openSUSE lo consideramos casi oficial y la propia Comunidad de openSUSE lo recomienda. Hoy si no cambia la situación será algo que haya que cambiar.

Me permito traducir el correo, ya que al ser la fuente oficial encontraremos los motivos que han llevado a esta situación y un poco de historia al respecto.

Cómo empezó todo y quién lo hizo posible

La idea original de Packman surgió de Waldemar Brodkorb, quien co-inició el proyecto en ese momento. Pascal Bleser desarrolló entonces el sitio web (con Marc). Pascal también se ocupó de los patrocinadores y organizó servidores espejo antes de finalmente dar un paso atrás. Desde el principio, Marc creó y administró toda la gestión del repositorio, así como la infraestructura de correo electrónico.

A lo largo de todos estos años, pagó el alojamiento de su propio bolsillo (aparte de algunas donaciones e ingresos publicitarios) y se encargó del diseño técnico y el mantenimiento. En 2005, Stefan (Botter) se incorporó con un servidor de réplica y desde 2013 gestiona los servidores de compilación, de los que también es responsable financiera y técnicamente. Desde hace varios años, Stefan también es moderador de la lista de correo de Packman.

Pero – y queremos enfatizarlo explícitamente – Packman nunca fue solo nuestro proyecto. No habría sido posible sin los muchos empaquetadores trabajadores durante todos estos años. Gente que vino, mantuvo los paquetes y finalmente se fue de nuevo. Gente que se quedó años o décadas. Sin todos vosotros, Packman nunca habría llegado tan lejos. Queremos agradeceros muy sinceramente por ello.

Por qué lo dejamos

25 años es mucho tiempo. Y si somos sinceros: Packman alcanzó su cenit hace algún tiempo. Las distribuciones han evolucionado. Flatpak y otros mecanismos han reducido la necesidad de muchos paquetes clásicos de Packman. Ambos nos hemos dado cuenta de que ya no podemos reunir la energía ni el tiempo que Packman necesita. Preferimos terminarlo de forma consciente y transparente antes que dejar que se desvanezca lentamente, dejando a los usuarios con paquetes huérfanos al final.

En cuanto a la infraestructura

Cualquiera que desee continuar con Packman debe configurar su propia infraestructura. Estamos preparados para documentar nuestro conocimiento y ofrecer apoyo asesor durante la configuración. Además, estamos listos para entregar los scripts que gestionan la publicación y firma de paquetes. Marc continuará gestionando la gestión del dominio y la lista de correo, siempre que se encuentren sucesores para las demás áreas.

Se buscan sucesores

Buscamos a una persona o un equipo dispuesto a continuar con Packman: hosting, infraestructura de compilación, gestión de repositorios y coordinación comunitaria. Dividir estas tareas entre varias personas es absolutamente concebible.

También nos gustaría invitar a opiniones sobre modelos alternativos. Una pregunta obvia: ¿Podría Packman (o al menos partes de él) transferirse al OpenSUSE Build Service (OBS)? Sin embargo, hay una restricción importante: Packman solo existe porque el OBS oficial mantiene una lista negra de aplicaciones y no puede construir los códecs multimedia exactos que definen a Packman. No obstante, merece la pena plantearse la pregunta de nuevo y debatir qué modelos serían factibles hoy en día.

¿Qué pasa si no encuentran a nadie que desee continuar?

Si no se encuentra sucesor o alternativa antes del 31/12/2026, descontinuaremos el proyecto: las compilaciones, servidores de compilación y alojamiento de repositorios se desactivarán. Los repositorios dejarán de ser accesibles a partir de entonces.

Agradecimientos

Durante muchos años, Packman ha sido un proyecto muy cercano a nuestro corazón. Agradecemos a todos los que han contribuido a lo largo de los años: Waldemar por la idea original, Pascal por el trabajo inicial en la web, el proyecto openSUSE y especialmente el equipo de Open Build Service, patrocinadores y servidores de réplica, los empaquetadores que vinieron y se fueron, y quienes se quedaron. A los operadores de servidores de réplica, a los usuarios que reportaron errores y a todos los que nos apoyaron con comentarios constructivos.

Esperamos que se encuentre a alguien que continúe el proyecto. Si no, nos marchamos con la buena sensación de haber creado algo grandioso para la comunidad durante 25 años.

Gracias por todo. Un saludo cordial, Marc Schiffbauer y Stefan Botter

He omitido algunas secciones del correo original por ser muy técnicas, y mantener la esencia del anuncio, que es que Packman dejará de estar disponible con el comienzo de 2027… si nadie toma el relevo.

Personalmente tirándo un comando: zypper search -i -r ftp.gwdg.de-openSUSE_Tumbleweed

Me da información de los paquetes de mi sistemas instalados desde ese repositorio y que son unos cuantos. La mayoría software o librerías relacionadas con el audio, VLC, ffmpeg, etc…

Algunos se podrán sustituir por otros repositorios, como el propio para VLC, que incluirá sus códecs y con otros habrá que ver de qué manera solucionarlo.

Desde aquí mi gratitud a las personas que lo pusieron en marcha y han mantenido este importante recurso durante 25 años de historia. Han realizado un gran trabajo, que espero que siga adelante, pero que si no es así no ha desmerecido su dedicación y trabajo.

Enlaces de interés

• https://lists.links2linux.de/pipermail/packman/2026-August/018314.html
• https://forums.opensuse.org/t/packman-discontinued-from-jan-1st-2027-but-heres-your-chance/195731
• http://packman.links2linux.org/
• https://es.opensuse.org/Repositorios_comunitarios#Packman

The openQA test suite for openSUSE and SLE has a test module called tests/console/sudo.pm. It verifies that sudo works: passwords, shells, sudoers rules, environment isolation. Basic stuff. It runs tens of thousands of times per year and takes about 9 minutes each time. That adds up.

Where the time goes

There is no single bottleneck. The test uses expect to interact with password prompts. Every sudo call goes through credential cache reset, process spawn, password entry, and result verification. It does this 20 times because the test runs the full suite twice with slightly different sudoers configurations.

Gwenview, el visor de imágenes de la comunidad KDE, es una gran conocido por los usuarios. Pero ahora ya hay quien trata de sustituirlo por Photos un visor más moderno

Los usuarios de Plasma, llevamos utilizando el visor de imágenes Gewnview desde siempre, o eso parece, porque lleva con nosotros más de 25 años ¡casi nada!

Por cierto, allá por el 2021 publiqué en el blog un artículo del motivo de ese curioso nombre:

• https://victorhckinthefreeworld.com/2021/10/05/por-que-la-aplicacion-gwenview-de-kde-tiene-ese-extrano-nombre/

Pero ya hay quien propone pasarle el testigo del visor de imágenes de KDE a otro programa llamado Koko y que cambiaría su nombre a Photos.

El motivo es simple. Adaptar Gwenview a los nuevos estándares que tiene la comunidad de KDE con su software supondría el tener que reescribir buena parte del código, con lo que eso conlleva: Inestabilidad, depuración, etc.

Las nuevas personas que contribuyen con código ya no lo hacen en Gwenview por estar un poco desfasada.

Por eso, se ha promocionado a Koko, que nació en 2017 como una aplicación para móviles y que ha ido creciendo en funcionalidades para también dar el salto como aplicación de escritorio ofreciendo como mínimo lo mismo que Gwenview, pero con un código más moderno que atrae más a nuevos desarrolladores.

Vale, habrá cosas que eches en falta respecto a Gwenview, pero serán las mínimas y además Koko aka Photos trae nuevas funcionalidades en la gestión de tus imágenes en tu escritorio.

Puedes probar este software y empezar a hacer esa migración de una aplicación a otra o seguir utilizando Gwenview tal como estabas acostumbrado hasta ahora.

¿Ya has probado Photos? Yo la acabo de instalar en mi equipo desde los repositorios de openSUSE Tumbleweed y estoy empezando a conocerla.

Photos permite la edición de las imágenes con el editor de Spectacle, pudiendo recortar, redimensionar, voltear la imagen y también etiquetar imágenes, mostrar su información, poder compartirlas por diversos medios, etc…

Enlaces de interés

• https://apps.kde.org/es/koko/
• https://pointieststick.com/2026/09/06/photos-a-proposed-replacement-for-gwenview/
• https://apps.kde.org/es/gwenview/

Veamos cómo hacer que dos (o más) pestañas se sincronicen cuando hagamos «scroll» en una de ellas en el editor Kate de KDE

Editando un texto, tenía abierto el editor Kate de KDE con dos pestañas una al lado de la otra y necesitaba que al desplazar el texto, las dos se movieran a la vez, lo que me ahorraría tiempo.

Ya en un artículo anterior, vimos cómo poder hacer eso mismo en el editor Vim. Aquí tienes el enlace:

• https://victorhckinthefreeworld.com/2020/12/23/curso-de-vim-sincronizar-el-scroll-en-dos-ventanas-del-editor-vim/

Y para hacerlo en el editor Kate de KDE vamos a seguir los pasos siguientes.

Abrimos Kate con las dos pestañas divididas. Pueden ser el mismo documento en dos pestañas distintas, pueden ser distintos documentos, pueden ser más de dos pestañas.

Teniendo las pestañas divididas con los textos que queramos sincronizar al hacer «scroll» o desplazarlo en la pantalla, vamos a menú Ver → Vista dividida → Conmutar sincronización de desplazamiento.

Veremos que en la esquina superior derecha del documento aparece un icono como de una cadena. Situamos los dos documentos en las líneas que queremos sincronizar y pulsamos en los iconos de las pestañas a sincronizar, en las dos o en más si tuviéramos más.

Ahora al desplazar el texto veremos como ambas pestañas se desplazan a la vez pudiendo así revisar texto, compararlo, o lo que necesitemos hacer.

Si queremos dejar de sincronizar la pestaña, volvemos a pulsar sobre el icono y ya podremos desplazarnos libremente y pudiendo volver a utilizarlo cuando volvamos a necesitarlo.

A mí me ha resultado muy útil y resulta que ha hubo una persona de la comunidad de KDE que pensó en hacerlo. Bien por esa persona.

¿Te ha resultado útil? ¿Algún truco de Kate que quieras compartir?

Google Summer of Code is now over for openSUSE.

This summer, we had the privilege of mentoring eight contributors.

Mario Marín Hinojosa enhanced the openSUSE git workflow build results. He blogged about his progress and you can already see in it action on br.opensuse.org. See an example for devel:languages:python:Factory!

Akash Kumar wrote the foundation for an Uyuni on Kubernetes storage benchmark. This meant enhancing sumaform, the deployment tool used by the CI, to work with an existing Kubernetes cluster. He also wrote cucumber tests in the Uyuni test suite to benchmark the reposync and the download of packages from several minions. There are still other tests to add and he documented this all in the github mentoring issue. Akash will give a presentation at the openSUSE.Asia Summit in Yogyakarta in about a month; come and get to know him!

Digvijay Rawat worked on a AI agent to help with the root cause analysis of errors on Linux machines managed by Uyuni. He documented how it works, how to install it and what is left to be done in his repository. He also prepared a demo video to show how it off.

Geetansh Goyal added an MQTT publisher to Uyuni so its events can be used in automation. He also added Node Red nodes to use those events. His work is described in his repository. Tell us your use cases. Geetansh also presented at the openSUSE conference and would like to start buildin an openSUSE mirror and community in India. Find out how Geetansh described his Google Summer of Code experience.

Himanshu Jaiswal helped porting the Uyuni API docs to openAPI and Swagger. This was not just the matter of rewriting the doc from the current Javadoc to the new format, but also adding automation for it and fixing the many errors that came up. He documented the state of his project in a gist for the curious to take a look or help.

Jay Prakash added an mgrctl get command to wrap up the Uyuni API in a similar way to kubectl get. This only supports systems and system groups for now, but has been written with extensibility in mind to reduce the work needed for other Uyuni objects. He documented his work in a special git repository.

Surya Srinivasan worked on a native support of LDAP in Uyuni. With his work in, configuring the use of an LDAP server could be done from the Uyuni web interface! He described his work and what remains to be done in a gist.

Anuj Agrawal began the program this summer with us, but had to resign as he started working for Google. Congrats!! He started a chat bot project to help get started with openSUSE. The project uses a local SLM and RAG and was already nicely kicked out. To know more about the project, check out the code and documentation in his repository or read Anuj’s blog post about the openSUSE Assistant.

Many thanks to all eight of them for their involvement. We are looking forward to keep working with you all. Many thanks also to those who mentored them, gave time and patience to help them get started with contributing to openSUSE.