Contributors and developers within openSUSE Project recently met to coordinate the Git-based packaging workflow for Leap 16 and discussed how the process applies to the Leap distribution going forward, but not to the rolling-release Tumbleweed, which still needs some work to transition.

The workflow, built on Gitea as the UI platform, represents a shift toward a more transparent, package-centric development. Architectural decisions documented by the project include adopting Git as the sole version control system, using pull requests for change management and standardizing workflows across repositories.

Package sources for all official distributions are hosted at src.opensuse.org/pool. Community packages use branches named leap-x.y, such as leap-16.0. Packages originating from SUSE Linux Enterprise, also known as SUSE Linux Framework One (SLFO), use slfo-main or versioned slfo-x.y branches. When both branch types exist for a package, contributors should work from the leap-x.y branch.

The project relies on several automations to manage the workflow. The workflow-pr bot handles pull request lifecycles, including reviews and merging. The workflow-direct bot synchronizes submodules when changes are pushed to trusted development projects. The obs-staging-bot creates isolated testing environments in the Open Build Service for end-to-end validation. Sources for the automations are available in AutoGits repository. They do not require special permissions to operate and generally operate as regular users in Gitea.

Contributors are encouraged to use standard tooling; the osc client for OBS interactions, git-lfs for handling large files, and obs-git-init for initializing new package repositories are useful. Metadata such as maintainer lists, workflow configurations and project settings are stored directly in Git project repositories, with the obs-scm-bridge service generating Open Build Service metadata on demand. The git-obs tool exists (part of osc package) as an interface to Gitea, including the ability to use any of Gitea’s APIs directly from the terminal.

For community-owned packages, the workflow involves forking the repository, making changes in the appropriate leap-x.y branch and submitting a pull request. Pull requests automatically link to build results for verification. Contributors testing changes before submission can use the osc fork command, which creates a personal branch while preserving OBS project structure.

Packages maintained by SUSE follow separate procedures due to certification requirements. However, public requests for changes to these packages should be submitted through the Leap feature tracker at code.opensuse.org. Submissions are reviewed weekly during Leap features meetings.

During the meeting, participants discussed challenges with the transition. One of the attendees noted the workflow may feel unfamiliar to long-time openSUSE contributors and raised a point about repository initialization and the complexity of replicating OBS frontend functionality through bots. Another attendeee requested clearer mapping between the legacy processes and the new Git-based approach.

A key contributor to the OBS infrastructure emphasized that the goal is to make workflows transparent and reproducible. He invited contributors to report issues directly, and noted that binary-identical builds should be achievable when source transformations are not involved.

Attendees at the meeting acknowledged the need for improved tooling to support coordinated updates across multiple packages.

The project is seeking community support to complete the migration of development projects to the Git-based workflow. Documentation for the git workflow is available at src.opensuse.org and feedback can be submitted via GitHub issues at github.com/openSUSE/openSUSE-git.

Known issues include limitations on pull requests between branches in the package pool for non-collaborators. Work is ongoing to improve staging workflows for Factory to eventually transition to a git workflow.

Find more information, visit the recently update Git Packaging Workflow wiki page.

Veamos en este tutorial cómo instalar una versión anterior de un paquete de software en openSUSE Tumbleweed

Después de una actualización normal de openSUSE Tumbleweed, al reiniciar el sistema para que se tomaran en cuenta las actualizaciones, mi sistema se quedaba congelado a medio camino entre el fin de la pantalla Plymouth de bienvenida de Plasma de KDE y el propio escritorio y no podía hacer nada…

Al final de varias pruebas pude encontrar que mediante Ctrl+Alt+F2 podía ingresar en el sistema y poder manejar mi portátil. Pero al reiniciar volvía a ocurrir lo mismo. Después de varias pruebas sin conseguir nada. Pregunté en las listas de correo y me dieron la clave.

El problema venía ocasionado por una actualización de ddcutil y sobre todo libddcutil5 a su versión 2.2.5-2.1. La opción era volver a una versión anterior del paquete instalado y esperar a que se publicase una solución. Veamos cómo hacer esto.

Como no utilizo un sistema de archivos Brtfs que crea puntos de recuperación al que poder regresar si algo ocurre en el sistema, había que buscar otra solución y la encontré.

Mi yo del pasado ya había escrito en 2012 un tutorial sobre cómo instalar otra versión de un paquete de software mediante YaST. Pero las cosas han cambiado mucho y ese tutorial ya no me valía, porque al acceder al menú que describía no había ninguna versión anterior de ese software.

Pero la solución la daban en un hilo describiendo un problema idéntico al mio en los foros de openSUSE. Veamos cómo hacerlo (para mi yo del futuro).

Lo primero descargar una versión anterior de ese paquete. En Tumbleweed, tenemos un historial de todas las versiones de las snapshots publicadas. En concreto la snapshot anterior está disponible en este enlace:

• https://download.opensuse.org/history/20260209/

Desde ahí podremos descargar el paquete .rpm que necesitamos para instalarlo. Para descargarlo podremos hacerlo mediante wget:

wget https://download.opensuse.org/history/20260209/tumbleweed/repo/oss/x86_64/libddcutil5-2.2.1-1.1.x86_64.rpm

Ahora lo instalaremos desde una terminal mediante zypper y la opción –oldpackage que gestiona mejor la instalación de una versión anterior:

sudo zypper install --oldpackage libddcutil5-2.2.1-1.1.x86_64.rpm

Al hacer eso, me daba un conflicto de dependencias por un paquete que depende de ese que quiero instalar y que tiene una versión distinta. Lo resuelvo diciendo que rompa las dependencias del paquete y que puedan estar ambos de diferentes versiones.

Ahora hay que decirle al sistema que de momento y hasta que no llegue una actualización que corrija el problema no actualice ese paquete de software.

Para eso mi yo del pasado también escribió un artículo. Lo primero añadir un bloqueo al paquete en cuestión:

sudo zypper al libdccutil5

al = add lock o añadir bloqueo. Ese paquete quedará bloqueado y no se actualizará. Si queremos ver los bloqueos de paquetes que tenemos en nuestro sistema podremos hacerlo con la oopción ll = list lock

sudo zypper ll

Poco después de mi mensaje en la lista de correo ya una persona había enviado un parche que solucionaba el problema a la espera que desde el proyecto original se corrigiera.

El parche llegó al día siguiente a los repositorios y ya se podría instalar la nueva versión del paquete sin miedo a que causara problemas. Para eso entonces hay que eliminar el bloqueo del paquete mediante rl = remove lock

sudo zypper rl libdccutil5

Y ya podríamos actualizar el sistema y se actualizaría el paquete en cuestión a la versión que ofrece la solución al problema.

La verdad es que fue un susto ver que el sistema no funcionaba como se esperaba, pero la agilidad con la que todo se resolvió es digna de admirar.

Le deseo a mi yo del futuro que este artículo le resulte útil alguna vez y también a ti lector o lectora que por una u otra cuestión has llegado hasta aquí.

Aunque cada vez es más difícil, ya que las IA aprenden de artículos como este para ofrecerte sus soluciones sin dar crédito a quien las escribió a golpe de teclado… en fin ya hace más de 60 años que se cantaba eso de «the times they are a-changin'»

Enlaces de interés

• https://forums.opensuse.org/t/ssdm-starting-on-vt1-on-login-plasma-wayland-starting-freezes-runs-on-other-vt/191795/4
• https://lists.opensuse.org/archives/list/factory@lists.opensuse.org/thread/YBELZW235GACCELO6WEHH4UD7E4DCPH4/
• https://victorhckinthefreeworld.com/2012/10/24/opensuse-instalar-una-version-anterior-de-un-programa/
• https://victorhckinthefreeworld.com/2017/10/17/como-impedir-que-se-instale-un-paquete-en-opensuse/
• https://download.opensuse.org/history/

The openSUSE Project moved forward with a proposed governance structure following a virtual meeting yesterday that drew community members together for a discussion on advancing a leadership framework.

The session was productive with participants reviewing a draft proposal for governing bodies for the project; a Technical Steering Committee, a Community and Marketing Committee, representation of an Infrastructure Team and a Board.

The proposal is hosted on GitLab. It is designed as a living document that welcomes revision through community input.

The discussions during the meeting proposed that the Technical Steering Committee should begin with five members with a chair elected by the committee. The group would establish clear processes for reviewing and approving technical changes, drawing inspiration from Fedora’s FESCo model. Decisions for the TSC would use a voting system of +1 to approve, 0 for neutral, or -1 to block. A proposal passes without objection. A -1 vote would require a dedicated meeting, where a majority of attendees would decide the outcome. Objections must include a clear, documented rationale.

Discussions related to the Community and Marketing Committee would focus on outreach, advocacy, and community growth. It could also serve as an initial escalation point for disputes. If consensus cannot be reached at that level, matters would advance to the Board.

The Board’s role would center on representation, including coordination with SUSE, governance oversight, conflict mediation, and strategic guidance. Over time, its operational duties may narrow to function like a supervisory body, handling trademarks, budget approval, and final appeals when necessary.

Participants emphasized that cultivating a strong culture of maintainer responsibility remains essential and could be one of the more challenging aspects of bootstrapping a new structure.

Community members are encouraged to submit pull requests to refine the governance draft.

The document is available here. Organizers note that discussions should occur through proposed changes to the text.

No timeline for final adoption was announced. Project contributors will continue discussions through the GitLab repository and future community meetings.

There is a new toy in the house. It is a miniature workstation from HP, built around AMD’s Ryzen AI Max+ PRO 395 chip. If you are interested in the specifications and other details, check the HP product page at https://www.hp.com/us-en/workstations/z2-mini-a.html. In the long run, this box will serve many purposes:

• learning AI, but running as much as possible locally instead of utilizing cloud services
• learning Kubernetes by building everything from scratch on multiple virtual machines
• home server: running complex test environments on a single box (128 GB of RAM should be enough in most cases :-) )
• photo editing using Capture One Pro
• occasional gaming :-)

For now, I have finished unboxing and taken the first steps with Windows. It worked, though I made a mistake during setup and had to reinstall. I do not mind, since I do not like using pre-installed operating systems anyway. At least I know the machine works.

Right now I am hesitant to migrate any production applications or data to the new box. I have already clicked “use the whole disk” instead of creating a partition a few times, so I want to finalize the partitioning before using the box for anything beyond hardware testing. Better safe than sorry :-)

I plan to install a couple of Linux distributions. I mainly use openSUSE on the desktop, but I found instructions for Fedora to accelerate AI on this AMD chip. So, I’ll most likely install both. And, of course, I also plan to install FreeBSD 15 on the machine and see how it works both as a server and as a desktop.

I plan to post updates about my experiences in the coming weeks.

UDP log collection is a legacy feature that does not provide any security or reliability, but is still in wide use. You can improve its reliability using eBPF on Linux in recent syslog-ng versions. Support for eBPF was added to Debian packages while preparing for the 4.11.0 syslog-ng release.

You can learn more about eBPF support in syslog-ng from the documentation or reading my blog at https://www.syslog-ng.com/community/b/blog/posts/syslog-ng-4-2-extra-udp-performance

Right now, packaging changes only affect the syslog-ng nightly Debian / Ubuntu packages and the syslog-ng nightly container image. You can learn more about how to use them in the syslog-ng README on GitHub at https://github.com/syslog-ng/syslog-ng/ Once the syslog-ng 4.11.0 release is available, using the stable syslog-ng packages will include improved UDP support as well.

Are you interested in improving TCP performance for a single or few high traffic connections? You are looking for the parallelize() option: https://www.syslog-ng.com/community/b/blog/posts/accelerating-single-tcp-connections-in-syslog-ng-parallelize The good news is that the required changes are now available in ivykis upstream, so this feature is not limited to our builds anymore.

Originally published at https://www.syslog-ng.com/community/b/blog/posts/udp-reliability-improved-in-syslog-ng-debian-packaging

This is a rudimentary attempt (that surprisingly works) to export passwords from pass to Bitwarden csv format

As a requisite you need to have the private key that protects the passwords, exported as an ASCII armored key (Or whatever the nomenclature is), the important bit is that you export it:

gpg --export-secret-keys --armor $YOURFINGERPRINT > private-key.asc

To run simply run, you need to clone the sources from the git repo and inside the directory run:

go run . --private-key private-key.asc --identity alice@example.com

Alternatively you can build it and then run it (Sky is the limit)

You can check usage too by passing --help, It runs fairly fast, and in the end up with a pass_exported_passwords.csv (again see program help for defaults).

A feature that I’d like to add is a support for user plugins, to i.e check if an otp token is duplicated, or if a password is being reused, but that’s for the future

As usual PRs are welcome, specially for adding tests.

PS: “Maybe” I fix the program to be able to be installed via go install $foo (or somebody submits a PR :D)

https://github.com/foursixnine/pass-exporter

En ocasiones dos noticias deben ir unidas. Si esta mañana he hablado de la LliureJam 2026 de València ahora tocas hablar de su primer evento presencial con el Taller de Godot + Charla Licencias Libres organizadas por GNU/Linux València y Hackerspace VLC que se celebrará el sábado, 21 de febrero en los locales de éste último (Carrer Francisco Martínez, 19 Bajo, València 46020)

Taller de Godot + Charla Licencias Libres dentro de la LliureJam 2026 de València

Me complace presentaros un nuevo evento de la Asociación sin Ánimo de Lucro GNU/Linux València, esta vez con la cooperación de Hackerspace VLC, que siguen sus actividades este 2026 con un macro evento:

En palabras de los organizadores:

El sábado 21, nos podremos reunir toda la gente que quiera participar en la LliureJam (o simplemente que quiera aprender sobre Godot y licencias libres) en las maravillosas instalaciones de Hackerspace València.
Empezaremos con un almuerzo a las 10:00 en un bar cercano, para las personas que quieran venir a socializar y conocer a gente.
A las 11:00, haremos una presentación sobre licencias y recursos libres, donde explicaremos de forma muy sencilla lo que implican en garantizar la libertad del usuario. Veremos también dónde poder encontrar recursos para crear nuestro arte que nos garantizan la libertad de usarlos sin problemas, y en particular para la publicación de nuestro arte como contenido libre.
Finalmente, a las 11:30, dará arranque un taller de Godot, uno de los mejores motores de videojuegos que aprender hoy en día (¡y libre!) liderado por Guillem, el coordinador de LliureJam, ¡trata de instalar Godot en tu ordenador por adelantado! Así ganarás un poco de tiempo de aprendizaje.

Más información: GNU/Linux València

¿Qué es LliureJam 2026?

LliureJam 2026 es una «game jam» (un concurso de desarrollo rápido de videojuegos) con un enfoque muy especial: el Software Libre.

Se celebra justamente entre el 20 febrero al 6 marzo de 2026, y a diferencia de otras jams convencionales, aquí no solo importa el juego final, sino también las herramientas que usas para crearlo y cómo lo compartes.

Aunque puedes participar de forma remota a través de su página en Itch.io, el evento tendrá mucha presencia física en Valencia. Por ejemplo, el 21 de febrero hay un Taller de Godot + Charla Licencias Libres en el Hackerspace de València. En breve más noticias.

Y ahora la parte más ética y técnica:

Más información: LliureJam

La entrada Taller de Godot + Charla Licencias Libres dentro de la LliureJam 2026 de València se publicó primero en KDE Blog.

Modern Linux systems are increasingly used to run autonomous, policy-driven services that operate continuously without user interaction. One example is a self-hosted trading agent running on openSUSE Tumbleweed, and can be run on other openSUSE flavors if desired.

There is no flashy interface, no proprietary cloud service, no opaque black box and no paid service that charges a monthly fee. Instead, the system runs reliably 24/7 continuously executing predefined policies in response to market signals.

The setup highlights the use of Linux distributions in the age of decentralized finance. Running autonomous and securely with minimal human intervention is a natural fit for Linux-based operating environments.

Unlike trading apps and services, this approach favors transparency. Configurations are easy. Logs are readable. Services are managed through systemd. When something goes wrong, administrators can inspect, roll back or fine-tune their system without surrendering control to closed platforms.

Open-source tooling allows users to deploy and audit their own automation logic without relying on proprietary platforms. A trading agent built on a development platform’s APIs allows anyone with a laptop or Raspberry Pi running openSUSE or other another Linux distribution to operate in 24-hour financial markets.

While this example focuses on trading logic, the architecture applies equally to other continuous workloads such as telemetry processing, monitoring systems, API polling services or data aggregation pipelines.

Trading logic implemented in these systems may adopt a conservative posture; however, this does not eliminate risk. Users reading this assume full responsibility for both market exposure and technical failure modes. This content does not constitute financial advice, but is only showing a use case for the technology available to Linux users.

The agent checks price data and calculates a desired indicator as well as other services. One indicator that can be used is the Relative Strength Index (RSI) of recent candles. When the RSI drops below a threshold, the agent considers buying a digital asset. When the RSI rises above an upper threshold, it considers selling that digital asset.

The example shown operates only in spot markets and avoids leverage.

The example given is not a high-frequency system. It is designed to run quietly, sometimes doing nothing at all.

Running the Agent on openSUSE

The trading agent runs as a standard Node.js service. On openSUSE, it is typically managed using a user-level systemd unit.

Starting the Agent manually:

sudo zypper in nodejs

node --max-old-space-size=8192 dist/bot.js

Running it as a background service:

systemctl --user enable --now jup-bot.service

Monitoring logs:

journalctl --user -u jup-bot.service -f

The approach works identical on Leap, Tumbleweed and MicroOS. MicroOS users can benefit from automatic rollback if a system update ever breaks the runtime.

One of the system’s defining characteristics is that all trading behavior is controlled through environment variables, not hard-coded values.

This makes experimentation safer and easier. Changes can be tested, reverted or tuned without recompiling the application.

Timing and Conditions

Defines how many candles are used for RSI calculation.

RSI_PERIOD=14

Fourteen is a common default for 15-minute charts and balances responsiveness with noise reduction. Shorter periods react faster but generate more signals, while longer periods smooth fluctuations and trade less frequently.

Buy and Sell

Define the thresholds that trigger trades.

RSI_BUY=30
RSI_SELL=70

Lowering the buy threshold makes buy signals more selective, reducing trade frequency. Raising the sell threshold delays exits, also reducing churn. Moving either threshold closer to the midpoint increases trading activity and sensitivity to price movement.

Fine-tuning on openSUSE

openSUSE users often fine-tune in stages rather than all at once.

A conservative configuration might look like:

TRADE_FRACTION=0.40
MIN_SOL_RESERVE=0.20
RSI_BUY=28
RSI_SELL=72
CHECK_INTERVAL_SECONDS=900
COOLDOWN_SECONDS=3600

A more aggressive configuration might look like:

TRADE_FRACTION=0.80
MIN_SOL_RESERVE=0.05
RSI_BUY=30
RSI_SELL=70
CHECK_INTERVAL_SECONDS=900
COOLDOWN_SECONDS=1800

Changes are applied simply by restarting the service.

This use case is not about digital assets or cryptocurrency; it is about demonstrating its use case in the space.

The distribution provides a foundation for autonomous, policy-driven systems that must run as programmed continuously, transparently and easily recover from failure. Whether the task is trading, data aggregation, monitoring or infrastructure automation, the same principles apply.

Running autonomous services on open systems reinforces transparency, recoverability and operational control. Whether the workload is trading, monitoring or automation, openSUSE provides the foundation.

Here are differentiators for each openSUSE flavor. Leap offers enterprise-grade stability for users who prefer slower change and long support cycles; plus there is the option to upgrade to SUSE Linux Enterprise Server for those who want it. Tumbleweed provides up-to-date kernels and libraries, ideal for developers working with fast-moving blockchain SDKs. MicroOS, with its transactional updates and immutable filesystem, is especially well-suited for unattended edge services where reliability and rollback matter more than manual tweaking.

The trading agent may be watching price charts, but the real story here is about control; who has it, how it is exercised, and whether users can see and understand the system they are using. On openSUSE, they can.

Have alot of fun!