danigm.net - suse

Take it easy. A guide to avoid burnown during the Vulnpocalypse

danigm — Fri, 05 Jun 2026 12:00:00 +0200

Do not let the AI to remove the fun part from software development. We shouldn't allow gen AI to write software just because it "can". First, we must ask if it "should" do it, and even then, we should ask if we want to delegate the fun part, the thinking, the writing, the learning.

Remember what's important, journey before destination, we are the Code:

Do not let AI to destroy the community, do not let it destroy the technological knowledge commons.

tl;dr

Open Source maintainers are dealing with a lot of new reports and pressure to "fix" the project due to generative AI.

We need to find a way of stopping this and get back to something maintainable before all maintainers get burned out and look for a job in a farm:

100% secure software doesn't exists, so there will be always a possible CVE there. As Spaf said in 1989:

The only truly secure system is one that is powered off, cast in a block of concrete and sealed in a lead-lined room with armed guards - and even then I have my doubts.

Fixing bugs, adds new bugs, and if you need to fix something quick, the probability of new bugs will be higher. Do not forget about the First Law of Programming:

If it works, don't touch it

The amount of CVE reports is lowering the CVE credibility and quality, so if everything is a "high" security issue, we can't prioritize now and these reports are not different from random issues in github. Do not listen to The Boy Who Cried Wolf
Stable software is sable because it doesn't change too much. It's something that we are willing to loose trying to reach the impossible of 100% secure software?

The actual problem

There's a lot of money in AI tech right now, and everyone is trying to make the best gen AI tool or just pretend that their tool is the best.

In relation with the software analysis and writing, targeting the open source is the obvious strategy.

It's interesting to scrap every line of code, patch, pull request, issue and discussion around software to train your model, so AI scrappers are DDoSing open source projects infrastructure.
To promote their tools or themselves, Security Researches are using AI to target any project, reporting High security vulnerabilities, with the only goal of getting a CVE number to say how good they are.

This second point is affecting maintainers, because now you are receiving a lot of poor quality security reports, that are generated with AI and that looks plausible and are hard to read. You need to spend a lot of time to check if there's an actual wolf there or if it's again this boy that's tricking me.

This is burning the energy of maintainers, that instead of doing something productive are wasting their limited time talking with a Stocatic Parrot.

Do not let the AI Bros to use classic manipulation techniques on you!

A lot of open source projects are maintained by volunteers that do the work with passion and love. And even if it's the job that paid your bills, the maintainer can feel the pressure. When someone put a lot of love in something and work on it during years, it's part of his identity, so attacking the software is like attacking the person behind it.

This is nothing new, and a lot of people take advantage of this emotional link to manipulate the maintainer to do something that he do not want to do.

AI bros are using these techniques, do not let them to manipulate you and define your project agenda.

Here's a (not complete) list of known manipulation techniques that you can detect (and disarm!) in your daily community work:

Flooding the queue. Just create so many new issues that the actual maintainers can't deal with it. You feel responsible for the project and feel bad because your TO-DO list is growing.
This software is not secure (doesn't do what I want), I will use this other one instead that's better. The classic, "GNOME doesn't allow me to change this specific preference, I'll use KDE from now on".
This software is low quality, it doesn't follow the (my random) quality standards. Direct attack to the maintainer self-esteem.
Gaslighting software development. LLM are expert at this and people that uses it just copy the tactic. When the maintainer detects something weird and just tries to blame the other person for reporting nonsense and wasting all people time, it starts to invent new arguments and ignore the previous interaction.

So, take it easy, and remember the best clause in almost any software project, THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU:

Disclaimer of Warranty.

THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY
APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT
HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM “AS IS” WITHOUT
WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT
LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND
PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE
DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR
CORRECTION.

Is the software more insecure in 2026?

No. Anyone old enough could remember how insecure old software was. Do you remember windows 98? Do you remember the internet when everything was http (without that little s at the end), when people use ftp to logging into their server and modify the php code directly on production?

It's true that today we have more dependency on technology, but it's also true that everything is more secure, we have more and better cryptography, we have different levels of isolation, virtual environments, containers, virtual machines...

But we have the feeling that since AI can analyse all the software and look for vulnerabilities, we are doomed, because any stupid kid can hack my over engineered GNU/Linux machine!

First, that's not true, you need to know about security to get something useful from any AI tool. But even if it was true, what can you do about it? We need to be practical and find a balance between risk and usefulness, so do not overestimate the risk just because everyone is talking about it right now.

But even then, the security paranoia is not good for anyone. Software is inherently buggy, people write software and makes mistakes, so a possible vulnerability appears. In theory, these bugs are fixed when discovered, so it's always recommended to update to the latest version, because almost all known bugs will be fixed.

But it's also known that new versions comes with new functionality and code, and that means new "unknown" bugs or different behavior. That's a headache, so that's why the stable and Long Term Support are popular distributions, because "if it works, don't touch it".

Stable packages just get the fixes, not new features, but fixes are also code changes, so there's always a possibility to break something, even with a patch update.

The stable software has a lot of value, do not let the AI security paranoia destroy that, and convert everything in a rolling release with the latest and greatest (and possibly broken) software. Sometimes it's better to keep using something old, with known vulnerabilities that you can mitigate, than use the latest with unknown new vulnerabilities that you can't do anything about.

I will fight AI with AI

Please, do not do that. What I was trying to argue during this long post is not a technical problem. The current burnout problem in open source is a social problem, you can't fix it with a new layer of probabilistic tokens.

Community reaction against AI. The current industry push for the usage of AI everywhere is affecting a lot of people, and as a reaction a lot of people are directly fighting back. Using gen AI just sends the message that you do not care enough to do it yourself, and destroy the trust on the project.
It doesn't worth it. Even if the AI works (that it doesn't) it doesn't worth it. Writing code is easier than reviewing, you learn and grow with every new line of code that you write, delegating the fun part and personal growth part to an AI will make you work more miserable and you will be a junior forever.
It doesn't create community. Think about it, it's hard to get someone involved in a software project, but who will want to read or improve the code produced by a gen AI? The only future collaborator will be another AI.

Take it easy

Just remember, you can always say no, there's no hurry, and there's no need to work on something that you don't want just because other people consider that important.

Free Source is something done by people, for people. The software is important, but the community around it is sometimes more important. We use Free source not because it's technically better (that it is), but because we trust who, how and why are writing it.

Remember why are you doing this, do not remove the Fun part, continue with the Just for Fun mood.

openSUSE: The new git workflow

danigm — Fri, 14 Nov 2025 12:00:00 +0100

openSUSE is migrating the package source management from osc to git. I will try to explain here what it is the "git workflow" in openSUSE and give some practical information for contributors and maintainers.

You can find some documentation in the openSUSE wiki

Why?

openSUSE uses Open Build Service to store package sources (.spec files and patches). The source control is similar to subversion, so you can osc checkout, osc commit, osc log, etc. to work with any package source.

I don't know all the reasons to do the change, and different people will find different reasons, to support the change or to be against it. I will just write here what I consider a good reason to migrate:

Almost everyone has moved to git now, so today, git is the default source code management (scm) tool, almost all the people knows about github, so it's good to be "standard".
With the concept of "cheap" branches in git, it could be easier to maintain different versions of the same package, same repository, different branches, instead of actual forks.
Decouple the package source management from build. OBS does a lot of things, moving source code and review process to gitea could reduce the complexity (but requires some integration).

From OBS to gitea

All the development happens in OBS, so the classic workflow happens entirely there:

developer: branch -> checkout -> modify -> commit -> submit request
maintainer: review -> accept/decline

And everything is integrated in OBS that does the corresponding build of the sources, checks with services, forward, etc.

The new workflow changes almost all the interaction from OBS to gitea. OBS is still a really important piece of software in the process, but in the new workflow it's a build backend, so the user interaction will be with the git repo in gitea.

The new git workflow happens in gitea:

developer: fork -> clone -> modify -> commit -> push -> pull request
maintainer: review -> approve/decline

As you may notice, the "default" workflow is very similar, the difference is in the tools, the classic workflow occurs in build.opensuse.org and the new workflow in src.opensuse.org. And the tools to work with the sources are also different, osc in the first one and git in the new workflow.

And with this new workflow, there are some bots in gitea that sends the changes to OBS, so for any pull request created you will have the build results and approval from the bot if everything is building.

How to modify a package (leap 16.0)

Notice that you should have a openSUSE account to work with the gitea instance, and don't forget to configure your ssh key to be able to push using the gitea@src.opensuse.org remote.

So as a contributor, this is the basic workflow to follow to update a package in openSUSE:

Look for the source package in the pool (https://src.opensuse.org/pool)
Fork it in your user space, click the top right button. Skip this step if you have forked before
Clone your fork and work on that repo, create a new branch, modify the spec file, add new soures, etc. And make sure to update the .changes file accordingly, you can still use osc vc to do that.
You can build locally your package with osc build, as usual, but you will need to specify the build project:

$ git obs meta pull
$ git obs meta set --project openSUSE:Backports:SLE-16.0
$ osc build

Once you are happy with your changes, you can commit, push to your fork and then you can create a Pull Request. The pull request should target the pool repo and desired product branch. Right now you can just target leap-16.0, as factory is not migrated yet.

Devel projects

Some devel projects have been migrated now to git, so a similar workflow is available to modify these packages in Tumbleweed. The development of these packages is not happening in the pool, so you need to find first the devel project.

There's no simple way to discover the actual package devel source, as far as I know the easier way is:

Look for the devel project of the package in the Factory list, (ex python-pytest)
Go to the devel project in OBS (ex devel:languages:python:pytest)
Click on the link This project is managed in SCM

Once you have located the desired package to modify, the workflow is similar to what I explained before, but instead of forking from pool, you should fork from the devel project. For example if you want to modify python-pytest you should fork from https://src.opensuse.org/python-pytest/python-pytest, and create the pull request for that repo, to the main branch.

Adding a new package follows a different process that's documented in the wiki

What's migrated?

As I said, the migration is happening right now, so not everything is migrated. The first project migrated was the Leap 16.0. And we are slowly migrating some devel projects.

Right now from the python-maintainers team, we've started the migration of two subprojects:

You can find more information about the migration current state in the wiki: https://en.opensuse.org/opensuse:obs_to_git#codestream_project_status_table

GNOME Tour in openSUSE and welcome app

danigm — Tue, 21 Oct 2025 12:00:00 +0200

As a follow up of the Hackweek 24 project, I've continued working on the gnome-tour fork for openSUSE with custom pages to replace the welcome application for openSUSE distributions.

GNOME Tour modifications

All the modifications are on top of upstream gnome-tour and stored in the openSUSE/gnome-tour repo

Custom initial page

A new donations page. In openSUSE we remove the popup from GNOME shell for donations, so it's fair to add it in this place.

Last page with custom openSUSE links, this one is the used for opensuse-welcome app.

opensuse-welcome package

The original opensuse-welcome is a qt application, and this one is used for all desktop environments, but it's more or less unmaintained and looking for a replacement, we can use the gnome-tour fork as the default welcome app for all desktop without a custom app.

To do a minimal desktop agnostic opensuse-welcome application, I've modified the gnome-tour to also generate a second binary but just with the last page.

The new opensuse-welcome rpm package is built as a subpackage of gnome-tour. This new application is minimal and it doesn't have lots of requirements, but as it's a gtk4 application, it requires gtk and libadwaita, and also depends on gnome-tour-data to get the resoures of the app.

To improve this welcome app we need to review the translations, because I added three new pages to the gnome-tour and that specific pages are not translated, so I should regenerate the .po files for all languages and upload to openSUSE Weblate for translations.

Log Detective: GSoC 2025 (part 2)

danigm — Wed, 27 Aug 2025 07:00:00 +0200

This week is the last week of Google Summer of Code for this year edition, and I'll do a summary of what we have been doing and future plans for the Log Detective integration in openSUSE.

I wrote a blog post about this project when it starts, so if you didn't read, you can take a look.

All the work and code was done in the logdetective-obs github repository.

Aazam, aka the intern, also wrote some blog post about his work.

Initial Research

The idea of the project was to explore ways of integration of LogDetective with the openSUSE dev workflow. So we started collecting some build failures in the openSUSE build service and testing with log detective to check if the output is smart or even relevant.

The intern creates a script to collect log from build failures and we store the LLM answer.

Doing this we detected that the log-detective.com explain is very slow and the local tool is less accurate.

The results that we got weren't too good, but at this point of the project is something expected. The model is being trained and will improve with every new log that users send.

Local vs Remote, model comparison

The logdetective command line tool is nice, but LLM requires a lot of resources to run locally. This tool also uses the models published by fedora in huggingface.co, so it's not as accurate as the remote instance that has a better trained model and is up to date.

In any case, the local logdetective tool is interesting and, at this moment, it's faster than the deployed log-detective.com.

Using this tool, Aazam did some research, comparing the output with different models.

logdetective apache-arrow_standard_x86_64.log\
  --model unsloth/Qwen2.5-Coder-7B-Instruct-128K-GGUF\
  -F Qwen2.5-Coder-7B-Instruct-Q4_K_M.gguf\
  --prompt ~/prompt.yaml

So using other specific models, the logdetective tool can return better results.

The plugin

openSUSE packagers uses the osc tool, to build packages in build.opensuse.org. This tool can be extended with plugins and we created a new plugin to use log-detective.

So a packager can get some AI explanation about a build failure with a simple command:

$ osc ld -r -p devel:languages:python --package python-pygame --repo openSUSE_Tumbleweed
🔍 Running logdetective for python-pygame (openSUSE_Tumbleweed/x86_64)...
Log url: https://api.opensuse.org/public/build/devel:languages:python/openSUSE_Tumbleweed/x86_64/python-pygame/_log
🌐 Sending log to LogDetective API...
 The RPM build process for the `python-pygame` package failed during the
`%check` phase, as indicated by the "Bad exit status from /var/tmp/rpm-
tmp.hiddzT (%check)" log snippet. This failure occurred due to seven test
failures, one error, and six skipped steps in the test suite of the package.



The primary issue causing the build failure seems to be the traceback error in
the `surface_test.py` file, which can be seen in the following log snippets:



[[  278s] Traceback (most recent call last):
[  278s]   File "/home/abuild/rpmbuild/BUILD/python-
pygame-2.6.1-build/BUILDROOT/usr/lib64/python3.11/site-
packages/pygame/tests/surface_test.py", line 284, in test_copy_rle
]
[[  278s] Traceback (most recent call last):
[  278s]   File "/home/abuild/rpmbuild/BUILD/python-
pygame-2.6.1-build/BUILDROOT/usr/lib64/python3.11/site-
packages/pygame/tests/surface_test.py", line 274, in
test_mustlock_surf_alpha_rle
]
[[  278s] Traceback (most recent call last):
[  278s]   File "/home/abuild/rpmbuild/BUILD/python-
pygame-2.6.1-build/BUILDROOT/usr/lib64/python3.11/site-
packages/pygame/tests/surface_test.py", line 342, in test_solarwolf_rle_usage
]



These traceback errors suggest that there are issues with the test functions
`test_copy_rle`, `test_mustlock_surf_alpha_rle`, and `test_solarwolf_rle_usage`
in the `surface_test.py` file. To resolve this issue, you should:



1. Identify the root cause of the traceback errors in each of the functions.
2. Fix the issues found, either by modifying the test functions or correcting
the underlying problem they are testing for.
3. Re-build the RPM package with the updated `surface_test.py` file.



It's also recommended to review the other test failures and skipped steps, as
they might indicate other issues with the package or its dependencies that
should be addressed.

Or if we are building locally, it's possible to run using the installed logdetective command line. But this method is less accurate, because the model used is not smart enough, yet:

$ osc build
[...]
$ osc ld --local-log --repo openSUSE_Tumbleweed
Found local build log: /var/tmp/build-root/openSUSE_Tumbleweed-x86_64/.build.log
🚀 Analyzing local build log: /tmp/tmpuu1sg1q0
INFO:logdetective:Loading model from fedora-copr/Mistral-7B-Instruct-v0.3-GGUF
...

Future plans

Adding submit-log functionality to osc-ld-plugin. In-progress. This will make it easier to collaborate with log-detective.com, allowing openSUSE packagers to send new data for model training.
Gitea bot. openSUSE development workflow is moving to git, so we can create a bot that comment on Pull Request with packages that fails to build. Something similar to what fedora people have for centos gitlab
Add a new tab to log-detective.com website to submit logs directly from OBS

This was an interesting Summer of Code project. I learned a bit about LLM. I think that this project has a lot of potential, this can be integrated in different workflows and an expert LLM can be a great tool to help packagers, summarizing big logs, tagging similar failures, etc.

We have a lot of packages and a lot of data in OBS, so we should start to feed the LLM with this data, and in combination with the fedora project, the log-detective could be a real expert in open source RPM packaging.

Log Detective: Google Summer of Code 2025

danigm — Mon, 09 Jun 2025 12:00:00 +0200

I'm glad to say that I'll participate again in the GSoC, as mentor. This year we will try to improve the RPM packaging workflow using AI, as part of the openSUSE project.

So this summer I'll be mentoring an intern that will research how to integrate Log Detective with openSUSE tooling to improve the packager workflow to maintain rpm packages.

Log Detective

Log Detective is an initiative created by the Fedora project, with the goal of

"Train an AI model to understand RPM build logs and explain the failure in simple words, with recommendations how to fix it. You won't need to open the logs at all."

As a project that was promoted by Fedora, it's highly integrated with the build tools around this distribution and RPM packages. But RPM packages are used in a lot of different distributions, so this "expert" LLM will be helpful for everyone doing RPM, and everyone doing RPM, should contribute to it.

This is open source, so if, at openSUSE, we want to have something similar to improve the OBS, we don't need to reimplement it, we can collaborate. And that's the idea of this GSoC project.

We want to use Log Detective, but also collaborate with failures from openSUSE to improve the training and the AI, and this should benefit openSUSE but also will benefit Fedora and all other RPM based distributions.

The intern

The selected intern is Aazam Thakur. He studies at University of Mumbai, India. He has experience in using SUSE as he has previously worked on SLES 15.6 during his previous summer mentorship at OpenMainFrame Project for RPM packaging.

I'm sure that he will be able to achieve great things during these three months. The project looks very promising and it's one of the things where AI and LLM will shine, because digging into logs is always something difficult and if we train a LLM with a lot of data it can be really useful to categorize failures and give a short description of what's happening.

Python 2

danigm — Mon, 27 Jan 2025 12:00:00 +0100

In 2020, the Python foundation declared Python 2 as not maintained anymore.

Python 2 is really old, not maintained and should not be used by anyone in any modern environment, but software is complex and python2 still exists in some modern Linux distributions like Tumbleweed.

The past week the request to delete Python 2 from Tumbleweed was created and is going through the staging process.

The main package keeping Python 2 around for Tumbleweed was Gimp 2, that doesn't depends directly on Python 2, but some of the plugins depends on it. Now that we've Gimp 3 in Tumbleweed, we are able to finally remove it.

Python 2

The first version of Python 2 was released around 2000, so it's now 25 years old. That's not true, because software is a living creature, so as you may know, Python 2 grew during the following years with patch and minor releases until 2020 that was the final release 2.7.18.

But even when it was maintained until 2020, it was deprecated for a long time so everyone "should" have time to migrate to python 3.

Py3K

I started to write python code around the year 2006. I was bored during a summer internship at my third year of computer science, and I decided to learn something new. In the following months / years I heard a lot about the futurist Python 3000, but I didn't worry too much until it was officially released and the migration started to be a thing.

If you have ever write python2 code you will know about some of the main differences with python3:

print vs print()
raw_input() vs input()
unicode() vs str
...

Some tools appeared to make it easier to migrate from python2 to python3, and even it was possible to have code compatible with both versions at the same time using the __future__ module.

You should have heard about the six package, 2 * 3 = 6. Maybe the name should be five instead of six, because it was a Python "2 and 3" compatibility library.

Python in Linux command line

When python3 started to be the main python, there were some discussion about how to handle that in different Linux distributions. The /usr/bin/python binary was present and everyone expect that to be python2, so almost everyone decided to keep that relation forever and distribute python3 as /usr/bin/python3, so you can have both installed without conflicts and there's no confusion.

But python is an interpreted language, and if you have python code, you can't tell if it's python2 or python3. The shebang line in the executable python scripts should point to the correct interpreter and that should be enough like #!/usr/bin/python3 will use the python3 interpreter and #!/usr/bin/python will use python2.

But this is not always true, some distributions uses python3 in /usr/bin/python like Archlinux or if you create a virtualenv with python3, the python binary points to the python3 interpreter, so a shebang like #!/usr/bin/python could be something valid for a python3 script.

In any case, the recommended and safest way is to always use python3 binary because that way it'll work correctly "everywhere".

Goodbye

It's time to say goodbye to python2, at least we can remove it now from Tumbleweed. It'll be around for some more time in Leap, but it's the time to let it go.

Hackweek 24

danigm — Fri, 22 Nov 2024 12:00:00 +0100

It's the time for a new Hack Week. The Hack Week 24 was from November 18th to November 22th, and I've decided to join the New openSUSE-welcome project this time.

The idea of this project is to revisit the existing openSUSE welcome app, and I've been trying to help here, specifically for the GNOME desktop installation.

openSUSE-welcome

Right now after installing any openSUSE distribution with a graphical desktop, the user is welcomed on first login with a custom welcome app.

This custom application is a Qt/QML with some basic information and useful links.

The same generic application is used for all desktops, and for popular desktops right now exists upstream applications for this purpose, so we were talking on Monday morning about it and decided to use specific apps for desktops.

So for GNOME, we can use the GNOME Tour application.

gnome-tour

GNOME Tour is a simple rust/gtk4 application with some fancy images in a slideshow.

This application is generic and just shows information about GNOME desktop, so I created a fork for openSUSE to do some openSUSE specific customization and use this application as openSUSE welcome in GNOME desktop for Tumbleweed and Leap.

Desktop patterns, the welcome workflow

After some testing and investigation about the current workflow for the welcome app:

x11_enhanced pattern recommends opensuse-welcome app.
We can add a Recommends: gnome-tour to the gnome pattern
The application run using xdg autostart, so gnome-tour package should put the file in /etc/xdg/autostart and set to hidden on close.
In the case of having a system with multiple desktops, we can choose the specific welcome app using the OnlyShowIn/NotShowIn config in desktop file

So I've created a draft PR to do not show the openSUSE-welcome app in GNOME, and I've also the gnome-tour fork in my home OBS project.

I've been testing this configuration in Tumbleweed with GNOME, KDE and XFCE installed and it works as expected. The openSUSE-welcome is shown in KDE and XFCE and the gnome-tour app is only shown in GNOME.

Next steps

The next steps to have the GNOME Tour app as default welcome for openSUSE GNOME installation are:

Send forked gnome-tour package to GNOME:Next project in OBS.
Add the Recommends: gnome-tour to patterns-gnome to GNOME:Next project in OBS.
Make sure that any other welcome application is not shown in GNOME.
Review openQA tests that expect opensuse-welcome and adapt for the new application.

rpmlint: Google Summer of Code 2024

danigm — Thu, 30 May 2024 00:00:00 +0200

I'm glad to say that I'll participate again in the GSoC, as mentor. This year we will continue the work done during the past year, as part of the openSUSE project.

So this summer I'll be mentoring an intern and we'll continue working on improving the testing framework of the rpmlint project.

This year we've a better testing framework, thanks to the work done during the past Summer of Code, by Afrid. So the goal for this year is to try to modernize existing tests and remove as much files as possible from test/binary directory, replacing those with mock packages defined with python code.

The selected intern is Luz Marina Montilla Marín. She has done some initial work in the rpmlint project, creating the mock packages for some tests and we've just started with the work to do during the GSoC program, evaluating the tests that we've right now and planning were to start.

She studies at Córdoba, Spain, my hometown. Every year I try to reach young people at different local universities, here in Andalucía, and sometimes I'm able to convince some students to participate, like the GSoC 2020, when Alejandro Dominguez, from Seville, were working on Fractal. So I'm happy that I'm increasing the number of free software developers in my local community :D

I'm sure that she will be able to achieve great things during these three months, so I'm looking forward to start to code and see how far can we go.

Python 3.13 Beta 1

danigm — Wed, 22 May 2024 00:00:00 +0200

Python 3.13 beta 1 is out, and I've been working on the openSUSE Tumbleweed package to get it ready for the release.

Installing python 3.13 beta 1 in Tumbleweed

If you are adventurous enough to want to test the python 3.13 and you are using openSUSE Tumbleweed, you can give it a try and install the current devel package:

# zypper addrepo -p 1000 https://download.opensuse.org/repositories/devel:languages:python:Factory/openSUSE_Tumbleweed/devel:languages:python:Factory.repo
# zypper refresh
# zypper install python313

What's new in Python 3.13

Python interpreter is pretty stable nowadays and it doesn't change too much to keep code compatible between versions, so if you are writing modern Python, your code should continue working whit this new version. But it's actively developed and new versions have cool new functionalities.

New and improved interactive interpreter, colorized prompts, multiline editing with history preservation, interactive help with F1, history browsing with F2, paste mode with F3.
A set of performance improvements.
Removal of many deprecated modules: aifc, audioop, chunk, cgi, cgitb, crypt, imghdr, mailcap, msilib, nis, nntplib, ossaudiodev, pipes, sndhdr, spwd, sunau, telnetlib, uu, xdrlib, lib2to3.

Enabling Experimental JIT Compiler

The python 3.13 version will arrive with an experimental functionality to improve performance. We're building with the --enable-experimental-jit=yes-off so it's disabled by default but it can be enabled with a virtualenv before launching:

$ PYTHON_JIT=1 python3.13

Free-threaded CPython

The python 3.13 has another build option to disable the Global Interpreter Lock (--disable-gil), but we're not enabling it because in this case it's not possible to keep the same behavior. Building with disabled-gil will break compatibility.

In any case, maybe it's interesting to be able to provide another version of the interpreter with the GIL disabled, for specific cases where the performance is something critical, but that's something to evaluate.

We can think about having a python313-nogil package, but it's not something trivial to be able to have python313 and python313-nogil at the same time in the same system installation, so I'm not planning to work on that for now.

Where's my python code?

danigm — Sat, 03 Feb 2024 00:00:00 +0100

Python is a interpreted language, so the python code are just text files with the .py extension. For simple scripts it's really easy to have your files located, but when you starts to use dependencies and different projects with different requirements the thing starts to get more complex.

PYTHONPATH

The Python interpreter uses a list of paths to try to locate python modules, for example this is what you can get in a modern GNU/Linux distribution by default:

Python 3.11.7 (main, Dec 15 2023, 10:49:17) [GCC] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.path
['',
 '/usr/lib64/python311.zip',
 '/usr/lib64/python3.11',
 '/usr/lib64/python3.11/lib-dynload',
 '/usr/lib64/python3.11/site-packages',
 '/usr/lib64/python3.11/_import_failed',
 '/usr/lib/python3.11/site-packages']

These are the default paths where the python modules are installed. If you install any python module using your linux packaging tool, the python code will be placed inside the site-packages folder.

So system installed python modules can be located in:

/usr/lib/python3.11/site-packages for modules that are architecture independent (pure python, all .py files)
/usr/lib64/python3.11/site-packages for modules that depends on the arquitecture, that's something that uses low level libraries and needs to build so there are some .so files.

pip

When you need a new python dependency you can try to install from your GNU/Linux distribution using the default package manager like zypper, dnf or apt, and those python files will be placed in the system paths that you can see above.

But distributions doesn't pack all the python modules and even if they do, you can require an specific version that's different from the one packaged in your favourite distribution, so in python it's common to install dependencies from the Python Package Index (PyPI).

Python has a tool to install and manage Python packages that looks for desired python modules in PyPI.

You can install new dependencies with pip just like:

$ pip install django

And that command looks for the django python module in the PyPI, downloads and install it, in your user $HOME/.local/lib/python3.11/site-packages folder if you use --user, or in a global system path like /usr/local/lib or /usr/lib if you run pip as root.

But the usage of pip directly in the system is something not recommended today, and even it's disabled in some distributions, like openSUSE Tumbleweed.

[danigm@localhost ~] $ pip install django
error: externally-managed-environment

× This environment is externally managed
╰─> To install Python packages system-wide, try
    zypper install python311-xyz, where xyz is the package
    you are trying to install.

    If you wish to install a non-rpm packaged Python package,
    create a virtual environment using python3.11 -m venv path/to/venv.
    Then use path/to/venv/bin/python and path/to/venv/bin/pip.

    If you wish to install a non-rpm packaged Python application,
    it may be easiest to use `pipx install xyz`, which will manage a
    virtual environment for you. Install pipx via `zypper install python311-pipx` .

note: If you believe this is a mistake, please contact your Python installation or OS distribution provider. You can override this, at the risk of breaking your Python installation or OS, by passing --break-system-packages.
hint: See PEP 668 for the detailed specification.

virtualenvs

Following the current recommendation, the correct way of installing third party python modules is to use virtualenvs.

The virtualenvs are just specific folders where you install your python modules and some scripts that make's easy to use it in combination with your system libraries so you don't need to modify the PYTHONPATH manually.

So if you've a custom project and want to install python modules you can create your own virtualenv and use pip to install dependencies there:

[danigm@localhost tmp] $ python3 -m venv myenv
[danigm@localhost tmp] $ . ./myenv/bin/activate
(myenv) [danigm@localhost tmp] $ pip install django
Collecting django
...
Successfully installed asgiref-3.7.2 django-5.0.1 sqlparse-0.4.4

So all dependencies are installed in my new virtualenv folder and if I use the python from the virtualenv it's using those paths, so all the modules installed there are usable inside that virtualenv:

(myenv) [danigm@localhost tmp] $ ls myenv/lib/python3.11/site-packages/django/
apps  contrib  db        forms  __init__.py  middleware   shortcuts.py  templatetags  urls   views
conf  core     dispatch  http   __main__.py  __pycache__  template      test          utils
(myenv) [danigm@localhost tmp] $ python3 -c "import django; print(django.__version__)"
5.0.1
(myenv) [danigm@localhost tmp] $ deactivate

With virtualenvs you can have multiple python projects, with different dependencies, isolated, so you use different dependencies when you activate your desired virtualenv:

activate $ . ./myenv/bin/activate
deactivate $ deactivate

High level tools to handle virtualenvs

The venv module is a default Python module and as you can see above, it's really simple to use, but there are some tools that provides some tooling around it, to make it easy for you, so usually you don't need to use venv directly.

pipx

For final python tools, that you are not going to use as dependencies in your python code, the recommended tool to use is pipx.

The tool creates virtualenv automatically and links the binaries so you don't need to worry about anything, just use as a way to install third party python applications and update/uninstall using it. The pipx won't mess your system libraries and each installation will use a different virtualenv, so even tools with incompatible dependencies will work nicely together in the same system.

Libraries, for Python developers

In the case of Python developers, when you need to manage dependencies for your project, there are a lot of nice high level tools for managing dependencies.

These tools provides different ways of managing dependencies, but all of them relies in the use of venv, creating the virtualenv in different locations and providing tools to enable/disable and manage dependencies inside those virtualenvs.

For example, poetry creates virtualenvs by default inside the .cache folder, in my case I can find all poetry created virtualenvs in:

/home/danigm/.cache/pypoetry/virtualenvs/

Most of these tools add other utilities on top of the dependency management. Just for installing python modules easily you can always use default venv and pip modules, but for more complex projects it's worth to investigate high level tools, because it'll make easy to manage your project dependencies and virtualenvs.

Conclusion

There are a lot of python code inside any modern Linux distribution and if you're a python developer it's possible to have a lot of python code. Make sure to know the source of your modules and do not mix different environments to avoid future headaches.

As a final trick, if you don't know where's the actual code of some python module in your running python script, you can always ask:

>>> import django
>>> django.__file__
'/tmp/myenv/lib64/python3.11/site-packages/django/__init__.py'

This could be even more complicated if you start to use containers and different python versions, so keep you dependencies clean and up to date and make sue that you know where is your Python code.

Hackweek 23

danigm — Fri, 10 Nov 2023 00:00:00 +0100

Hack Week is the time SUSE employees experiment, innovate & learn interruption-free for a whole week! Across teams or alone, but always without limits.

The Hack Week 23 was from November 6th to November 10th, and my project was to gvie some love to the GNOME Project.

Before the start of the Hack week I asked in the GNOME devs Matrix channel, what project needs some help and they gave me some ideas. At the end I decided to work on the GNOME Calendar, more specifically, improving the test suite and fixing issues related to timezones, DST, etc.

GNOME Calendar

GNOME Calendar is a Gtk4 application, written in C, that heavily uses the evolution-data-server library. It's a desktop calendar application with a modern user interface that can connect handle local and remote calendars. It's integrated in the GNOME desktop.

The current gnome-calendar project has some unit tests, using the GLib testing framework. But right now there are just a few tests, so the main goal right now is to increase the number of tests as much as possible, to detect new problems and regressions.

Testing a desktop application is not something easy to do. The unit tests can check basic operations, structures and methods, but the user interaction and how it's represented is something hard to test. So the best approach is to try replicate user interactions and check the outputs.

A more sophisticated approach could be to start to use the accessibility stack in tests, so it's possible to verify the UI widgets output without the need of rendering the app.

With gnome-calendar there's another point of complexity for tests because it relies on the evolution-data-server to be running, the app communicates with it using dbus, so to be able to do more complex tests we should mock the evolution-data-server and we should create fake data for testing.

My contribution

By the end of the week I've created four Merge requests, three of them have been merged now, and I'll continue working on this project in the following weeks/months.

I'm happy with the work that I was able to do during this Hack Week. I've learned a bit about testing with GLib in C, and a lot about the evolution-data-server, timezones and calendar problems.

It's just a desktop calendar application, how hard it could be? Have you ever deal with dates, times and different regions and time zones? It's a nightmare. There are a lot of edge cases working with dates that can cause problems, operations with dates in different time zones, changes in dates for daylight saving, if I've an event created for October 29th 2023 at 2:30 it will happens two times?

A lot of problems could happen and there are a lot of bugs reported for gnome-calendar related to this kind of issues, so working on this is not something simple, it requires a lot of edge case testing and that's the plan, to cover most of them with automated tests, because any small change could lead to a bug related to time zones that won't be noticed until someone has an appointment at a very specific time.

And this week was very productive thanks to the people working on gnome-calendar. Georges Stavracas reviews my MR very quickly and it was possible to merge during the week, and Jeff Fortin does a great work with the issues in gitlab and leading me to most relevant bugs.

So after a week of going deep into the gnome-calendar source code it could be a pity to just forget about it, so I'll try to keep the momentum and continue working on this project, of course, I'll have just a few hours per week, but any contribution is better than nothing. And maybe for the next summer I can propose a Google Summer of Code project to get an intern working on this full time.

Updating GNOME shell extensions to GNOME 45

danigm — Fri, 03 Nov 2023 00:00:00 +0100

The new version of the GNOME desktop was released more than one month ago. It takes some time to arrive to the final user, because distributions should integrate, tests and release the new desktop, and that's not something simple, and it should integrate in the distribution release planning.

So right now, it's possible that there's just a few people with the latest version of the desktop right now, just people with rolling release distros or people using testing versions of mayor distributions.

This is one of the reasons because a lot of gnome-shell extensions aren't updated to work with the latest version of GNOME, even after a few months, because even developers doesn't have the latest version of the desktop and it's not something "easy" to install, without a virtual machine or something like that. Even if the update is just a change in the metadata.json, there should be someone to test the extension, and even someone to request this update, and that will happen once the mayor distributions release a new version.

I'm using Tumbleweed, that's a rolling release and GNOME 45 is here just after the official release, but of course, a lot of extensions are not working, and in the infamous list of non working extensions there where the three that I'm maintaining right now:

mute-spotify-ads, extension to mute the spotify app when it's playing ads.
calc, a simple calculator in the alt+F2 input.
hide-minimized, hide minimized windows from alt+tab and overview.

The correct way

The correct way to maintain and update a gnome-shell extension should be to test and update "before" the official release of GNOME. It should be something easy for me, using Tumbleweed I can just add the GNOME Next repository, install the new desktop when it's in beta stage, and update the extension there.

But that's something that require an active maintainership... And right now what I do is to update the extensions when they are broken for me, so just when I need them, and that's after I get the new desktop and I find some time to update.

I know that's not the correct way and this produces a bad experience for other people using the extensions, but this is the easier thing to do for me. Maybe in the future I can do it correctly, and provide a tested update before the official release, maybe using snapper to be able to go back to stable, without the need of using virtual machines.

Update your extension to GNOME 45

The update to GNOME 45 was a bit more complex than previous ones. This version of the shell and gjs change a lot of things, so the migration it's not just to add a new number to the metadata.json, but requires incompatible changes, so extensions that works for GNOME 45 won't work for previous versions and vice versa.

But the people working in gnome-shell does a great work documenting and there's a really nice guide about how to upgrade your extension.

The most important part is the import section, that now it has a different syntax.

// Before GNOME 45
const Main = imports.ui.main;

// GNOME 45
import * as Main from 'resource:///org/gnome/shell/ui/main.js';

And some changes in the extension class, that now can inherit from existing ones to provide common usage, like preferences window:

import Adw from 'gi://Adw';

import {ExtensionPreferences, gettext as _} from 'resource:///org/gnome/Shell/Extensions/js/extensions/prefs.js';

export default class MyExtensionPreferences extends ExtensionPreferences {
    fillPreferencesWindow(window) {
        window._settings = this.getSettings();

        const page = new Adw.PreferencesPage();

        const group = new Adw.PreferencesGroup({
            title: _('Group Title'),
        });
        page.add(group);

        window.add(page);
    }
}

One year of Tumbleweed

danigm — Fri, 06 Oct 2023 00:00:00 +0200

More than a year has passed since I switched to openSUSE Tumbleweed Linux distribution, in both, my work computer (for obvious reasons) and in my personal computer and I can say that I'm really happy with the change.

Tumbleweed is a rolling release distribution, and in this kind of distributions there are a lot of changes every week, if you want the latest software, this kind of distribution is the way to go. But with high update frequency you are exposed to some kind of instability, it's impossible to have the latest changes without some broken program here and there, because not everyone is able to follow upstream changes without some weeks or months to update.

My distro history

I've been always a Linux user, since I get my first computer at 2003. In those days I was using a debian base distribution called knoppix. Then I switched to ubuntu when it appeared around 2004. But at that time I was a computer science student and I was exploring the whole free software and Linux ecosystem, so I was changing my distribution every time that I found a new one.

Like a lot of distro-hoppers, at some point I landed at ArchLinux and there I discovered the rolling release concept. And that was my home for some time, it was nice to have the latest available software just after the release.

At some point I bough a new computer and it was too new to work correctly with the kernel distributed in ArchLinux, so I tried different distributions and at that moment Fedora was the distro that works without too much complications with that computer, so I picked that one.

In 2019 I started to work at Endless and at that time I should try the EndlessOS, so I played a bit with the dual boot, having Fedora and EndlessOS at the same time. That was the first time that I get in contact with immutable distributions, something that's getting more popular everyday, but this distributions rely a lot on containers (flatpak, podman) and, even being something that could work, as a software engineer, I don't feel comfortable enough needing a container with another distribution to do something that could be in my system.

In 2022 I started to work at SUSE and for the first time I tried the openSUSE distribution until today.

The Tumbleweed

Today I've three different computers with Tumbleweed running. One for work, Thinkpad T14s, one for personal usage, Dell inspiron 5490, and another one as a personal media server, Libre computer La-frite.

The best thing of having Tumbleweed for me is that I get the latest GNOME as soon as it's released. And another big thing for this distribution is how easy it's to fix something upstream thanks to the Open Build Service, but I work everyday with that, so I'm biased. For sure, any other community distribution has different ways to contribute, but I find this one easy enough.

Even being a rolling release distro, Tumbleweed doesn't break a lot. I can't say that it's stable, because the API of everything is broken everyday, but the distribution is tested for every release and at least some level of package compatibility check is done. That makes Tumbleweed a good distribution and I can update without fearing some weird package breakage.

I usually update my work and personal laptops once a week, and la-frite not so often, maybe every 6 months.

With the default installation, Tumbleweed uses btrfs with snapshots, and it's really easy to go back and forward using the snapper tool. So it's really easy to go back to a good state if the distribution is broken for some reason, and wait for a fix.

The problems that I found during this year

Some problems with the NVidia graphic card in my Dell laptop, some times the kernel and the driver were not working correctly. I had to use snapper to get the NVidia working again, but fixed a few days later.
Currently I'm having some random crashes because some bug with amdgpu and wayland and mutter, but it's not too annoying for me to go back, so I didn't use snapper this time and I'm facing this random crashes waiting for the fix.

Long live the Tumbleweed

So far so good. Tumbleweed is a nice distribution that I'm enjoying. It's not getting in the way and I can find almost anything that I need for work, programming, gaming, media, etc. I'm really happy with this distribution and it's the perfect distribution for people like me, that want to have the latest things.

I know that there are other openSUSE flavors that are interesting, like the immutable ones, Leap or the latest one Slowroll, but Tumbleweed is the one for me.

rpmlint updates (August 2023)

danigm — Wed, 30 Aug 2023 00:00:00 +0200

We are at the end of the summer and this means that this year Google Summer of code is ending.

The recent changes applied now in the main branch include:

Remove usage of pkg_resource because it's deprecated.
Fix elf binary check with ELF files with a prefix.
New check for python packages with multiple .pyc files for different python versions.
Improve the testing framework (merged the work done during the GSoC 2023)

Summer of Code 2023 updates

The summer of code is ending and the work done by Afrid was good enough to be merged, so I merged it the past week.

I'm really happy with the work done during the GSoC program, now we've a more simple way to define tests for rpmlint checks mocking the rpm, so it's not always needed to build a fake rpm binary for each new test. This will make a lot easier to create simple tests, so I hope that we can increase the code coverage using this new framework.

During this time Afrid has extended the FakePkg class, so it's possible now to define fake metadata and files with fake tags and attributes. It's not complete and it's not a simple task to replace all the rpm binaries used for tests, because the Pkg class and RPM tags is a complex thing, but the current state allow us to replace a lot of them. Afrid has replaced some of the tests that uses binaries, but in the following months we can continue working on this and replace more.

After this work, we can now start to use more the FakePkg class in tests, so another task that we can do is to provide some common fake pkgs to use in different tests and new checks, so now it's possible to create fake packages with dynamic random data, so we can extend tests with fuzz testing and maybe this will help to improve the tool reliability.

Conclusion

I've participated as mentor several times now in the summer of code, and outreachy, and almost always was a good experience. With the gnome foundation in previous programs and this year with opensuse. These two communities are very open to collaboration and makes the whole process really simple, for me as mentor, and also for the intern.

I want to congratulate Afrid, because it was nice to work with him during this summer, he has done a great work, not just technically, but communicating, asking and finding his own solutions without requiring a continuous guidance.

He is very passionate and looks like a nice person, so I hope that he will continue around the open source, it could be opensuse, rpmlint or any other community, but this kind of people is what you want to find in any community.

After many years collaborating with different free software communities, it's amazing that there are so many great people in every project, of course you can find toxic communities and people, but in my experience, that's usually just noise, there are a lot of nice people out there, doing a great work, and I'm happy that young people like Afrid can be part of the free software movement, because this is what makes the free software great, the people that is working on it.

So Thanks a lot to Google for another summer of code, thanks to SUSE for letting me, and encourage me, to mentor, and thanks to all the free software developers that are out there.

I encourage everyone to participate in this kind of programs, for interns, it's a good opportunity to learn and to make some money working on free software, for mentors it's an opportunity to get some help in your project and help newcomers to be part of the community.

Have a lot of fun!

Python in openSUSE Tumbleweed

danigm — Sat, 05 Aug 2023 00:00:00 +0200

openSUSE Tumbleweed is a rolling release distribution, so it's ideal for developers and users that like to have the bleeding edge software.

It's also really "stable" to be a rolling release, from time to time you can find a broken package because of one package is updated and another one is not compatible yet, but it's something that doesn't happen too often thanks to openqa tests, so you don't need to worry about a breaking system.

You can find the Python interpreter and a lot of python modules in every Linux distribution, but Tumbleweed does an interesting thing for Python.

Default Python version (python3 -> python-3.11)

If you don't worry about the python version, you can just rely on python3. In Tumbleweed python3 is not a real package, but the default python version provides python3, so depending on when you install python3 you will get a different package, if you install it today (August 2023) you'll get python311.

In your system you'll have the /usr/bin/python3 binary that points to the default python, so you don't need to worry about the current version, you'll have there the default Python version for the operating system.

In addition to the Python interpreter, you can find in the distribution a lot of python modules, but again you can use the default version, so, for example, if you want to install poetry, you just use zypper install python3-poetry and that will install the real package python311-poetry.

Multiple python versions (3.8, 3.9, 3.10, 3.11)

Besides the default Python, in Tumbleweed you can also find other supported Python interpreters. Right now you can find all the Python versions currently supported by the Python Foundation, from 3.8 to 3.11.

For Python 3.8 you'll only find the interpreter, because the python modules are not built anymore, but for all the other versions you can find almost the same modules.

All python modules that provide binaries uses the update-alternatives, so you can configure in your system the version that you want to use as default. For example, if you want to use the 3.9 version of poetry, having installed different versions you can decide what /usr/bin/poetry points to:

$ sudo zypper in python311-poetry python39-poetry
$ sudo update-alternatives --config poetry

/usr/bin/python3 is a link provided by the default python package, so you can't modify with update-alternatives, so if you want to use a different python version, make sure to do the correct call with the full name python3.9, and use the correct shebang in your python scripts, for example #!/usr/bin/env python3.9.

What happens when default changes?

This way of distributing Python interpreter and modules is useful, because you don't need to update your software to work with the latest Python version, if your software requires another version, you can just install and continue using it, even on a bleeding-edge distribution like Tumbleweed.

But this method has some problems. When the default Python interpreter is changed in the distribution, all packages that depends on python3 will be updated, and that works correctly. But if you have installed some python module using the python3 prefix, that package, and all dependencies, is not updated automatically.

For example, if you installed python3-poetry when python3.10 was the default system, and then the distribution updates the system Python to python3.11, you don't get the python311-poetry package by default, you'll need to install it again. This could break you software, because if you use python3 and the dependencies are not updated, you'll find that some dependencies are not installed after updating.

For that reason, when the default python is changed in Tumbleweed, if you've software that rely on python3 you should make sure to install dependencies again by hand. And also you can do a cleanup and remove all old version packages that you don't need anymore.

If you just want the latest version you can just do all at once with a simple script like this:

#!/bin/bash
# up-py-tw.sh

FROM=$1
TO=$2

if [ $# -lt 2 ]
then
    echo "Usage:   up-py-tw.sh FROM TO"
    echo "example: up-py-tw.sh 310 311"
    exit 0
fi

echo "Updating python packages from $FROM to $TO"

OLDP=$(zypper -q search -i python${FROM}-* | tail --lines +4 | cut --delimiter \| --fields 2)
NEWP=$(echo $OLDP | sed "s/python${FROM}/python${TO}/g")

sudo zypper in $NEWP
sudo zypper rm $OLDP

You should verify what will be installed and what will be removed to make sure that just the python related packages are removed. It's possible that other packages depend on a python version that's older than the system one and that's okay.

Beta version (3.12.0b4)

In Tumbleweed, right now you can find all the supported Python versions, but it's not just that. At this moment you can also find the beta version of the next Python interpreter.

$ sudo zypper in python312

So if you are adventurous and want to test some new feature in the next Python release, you can do it with the version provided there. This version could also be used by openSUSE packagers to test the packages before the Python version is released so it allow us to prepare everything for the release and it could be in the distribution earlier and more tested.

Development

All this multiple python versions is done at distribution level and usually there's only one source package that produces the python39-foo, python310-foo and python311-foo. The source package is usually called python-foo and can be found in the Python devel project.

These packages spec uses the python-rpm-macros to generate all the versions from one source. If you're a packager you can find more information on the openSUSE wiki about Python Packaging.

rpmlint updates (July 2023)

danigm — Thu, 06 Jul 2023 00:00:00 +0200

I'm spending some time every week working in the rpmlint project. The tool is very stable and the functionality is well defined, implemented and tested, so there's no crazy development or a lot of new functionalities, but as in all the software, there are always bugs to solve and things to improve.

The recent changes applied now in the main branch include:

Update the usage of rpm to not use old API.
Fixes for rpmdiff -v, check for NULL char, special macros in comments and spell checking of description in different languages.
Move all the metadata from setup.py to pyproject.toml.
Releasing rpmlint as pre-commit hook
Improvements to the PythonCheck in the dependency checking.

Summer of Code 2023 updates

The first month of the Summer of Code has passed and Afrid is doing a great job there. We've now a draft Pull Request with some initial changes that allow us to mock rpm packages in tests so it's easier to create new tests without the need of creating a binary package.

The first step done was to extend the existing FakePkg class to allow us to define package files and some package metadata.

Now he's working in replacing all of the test_python.py tests that uses binaries rpm to something that doesn't needed.

The idea is to replace as much tests as possible to reduce the number of rpm binaries and after that, provide helper functions, decorators and classes to make it easy to write tests, writing less code.

Roadmap

In any software project there's always room for improvements, fixes and enhancements. If the project is there for enough time, it's even more critical to modernize the code to reduce the technical debt.

My plan for 2023 is to improve the tests around rpmlint as much as possible. First with the GSoC project, making it easier to write more tests, improving the testing tools that we've. And after the summer, improving the test coverage.

There's also a tool that shares some of the ideas with rpmlint, spec-cleaner, it's also written in Python, so the next step, after the tests improvements will be to take a deep look into the code of these two tools and try to integrate in some way. Maybe it's possible to refactor the common code into an external module, maybe we can bring some ideas from spec-cleaner to rpmlint. Not sure yet, but that'll be my next step.

Don't forget that this is free software, so you can participate too! If you find any issue in rpmlint or have an idea to improve it, don't hesitate and create a new issue.

rpmlint: Google Summer of Code 2023

danigm — Tue, 16 May 2023 00:00:00 +0200

I'm glad to say that I'll participate again in the GSoC, as mentor. This year will be a bit different from the previous ones, because I'm not mentoring a GNOME project but a openSUSE project.

I started to work at SUSE the past year and with this new job I get involved in the openSUSE community and I started to contribute to rpmlint.

So this summer I'll be mentoring an intern and we'll work on improving the testing framework of the rpmlint project.

The rpmlint project is a command line tool to check rpm packages, the correctness of these kind of packages and warn the packagers about usual problems or good practices. It's widely used in all Linux distributions based on rpm, mainly SUSE and RedHat.

It is written in Python and uses pytest for testing the code. Right now there are a lot of .rpm binary packages, to check different functionality, but that way of testing makes a bit hard to write new tests and to maintain with changes. The idea of this GSoC project is to extend the testing framework of rpmlint to support an easy way of writting tests that doesn't require a real rpm, something that can mock what it's in the .rpm binary and try to replace some of the current binary tests with this new mock.

The selected intern is Afrid Hussain. He has done some initial work in the rpmlint project, solving some minor issues and we're now preparing the work to be done during the GSoC program. I'm sure that he will be able to achieve great things during these three months, so I'm looking forward to start to code and see how far can we go.

Hackweek 2023

danigm — Tue, 03 Jan 2023 00:00:00 +0100

Hack Week is the time SUSE employees experiment, innovate & learn interruption-free for a whole week! Across teams or alone, but always without limits.

This year the Hack Week was this week, the last week of January and for my first SUSE hack week I decided to work in something funny, LILS.

Linux Immersive Learning System (LILS)

I don't think that this is a good name, but don't focus on it. The main idea of this project is to create some basic machinery to be able to write "interactive" tutorials or games using the INK language.

This is not an original idea, indeed all I've done is something that's currently working on EndlessOS, and was the main idea behind the dead project Hack Computer, you can even take a look to the Hack app in flathub. But I wanted to work around this, and create something simpler, from scratch.

I wanted to build something simple, with just Python, and make it simple enough to be able to build other tools on top. The design is simple, an INK parser, with a simple game runner. In the INK script you can define commands, to do something special, and wait for events with listeners, to wait for an event in the OS to continue.

With this basic functionality it's possible to build different user interfaces for different environments. And the original idea was to make the commands and listeners something extensible with a simple API, but that's something that I have not done yet, it's all Python functions without extension point.

The code can be found in github.

The INK parser

The most complex part of this project is the INK language parser. The Ink parser is free software and there's a Linux version that you can use to parse and compile to json, but I wanted to create my own parser with Python.

I've spent most of the Hack Week time fighting with the parser and indeed was the most challenging and fun part, because I've not worked a lot with parsers and it's not something easy as pie 😛️.

I remember creating a java compiler long time ago, when I was in the Seville University, for the Language Processors course. We did that with ANTLR, so starting from that, and looking for a Python lib, I found the Lark project. So if you like regular expressions, writing a grammar is a lot more FUN.

At the end I was able to support some basic INK language with support for:

Text
Tag support
Options, with suppress text support
Knots, Stitches and Diverts
Include other .ink files
Variable definition and basic operations
Knots and Stitches automatic visiting count variables
Conditional options using variables

It still fails in some cases, the comments and TODO placed in between text is not detected correctly and there's a lot of complex stuff that's not supported yet, but with what's supported right now it's possible to create complex scripts with loops and complex game graphs, so it's good enough to build games just with it.

GNOME shell extension

To integrate with the system I've done a simple GNOME shell extension. The extension just shows the text as bubbles and options as buttons, it's really simple and I've no time to make it something ready to be used, but I was able to make something usable.

To be able to run the LILS python library from gjs I've created a simple dbus service that exposes the basic InkScript class functionality as a dbus API.

I was thinking about being able to change the desktop background, depending of the value of a background variable in the script and do something similar to play music and sounds, so it could be a cool game engine with some additions.

SUSE Hack Week

So this Hack week was really fun and I learned a lot. It's really great that SUSE does things like this, letting us work in different projects for a week, to learn, to grow or to just explore different paths.

SUSE is my new distribution (new job)

danigm — Sun, 18 Sep 2022 00:00:00 +0200

This week I've started to work at SUSE. I'll be working as Python Specialist, in the packaging team, so I will go back to work on packaging and distribution after more than ten years. My first job in 2008 was working on a Ubuntu based local distribution, Guadalinex, so packaging and distribution work is not something new for me.

Python

Python was the first language that I fell in love. I learned to write code with C and C++, but when I discovered Python, in 2006, I found a really nice language to be able to create amazing things really fast and with a great community behind.

I'm very happy for this new opportunity to be able to collaborate to the Python distribution in all the SUSE flavours, and also to be able to collaborate in the creation of one of the most famous and used Linux distributions.

Tumbleweed

As part of this job change I've also installed SUSE Tumbleweed for the first time. Tumbleweed is a rolling release distribution with the latests packages. In the past I was using other rolling releases distributions like Arch, but this one looks more user friendly.

I've not spent a lot of time here, but from the point of view of a GNOME developer, I can say that it's a great distribution for development with updated packages, and it looks "stable". You can choose the desktop to use on installation and the GNOME desktop is there without any customization that I've detected, so it looks like it's a good vanilla GNOME desktop distribution.

Endless, it's not the end

I'm not working for EndlessOS now, but it's not the end. I've been working here for almost 4 years. At first I worked on the Hack Computer and after that project didn't work, I was working on the Endless Key.

During this time I've also collaborated a bit with the EndlessOS distribution, and I can say that's a really nice distribution to use, the ostree usage for the whole filesystem is a great idea, and the amount of content that comes with the installation is really good.

The EndlessOS Foundation Goal is to reduce the digital divide, providing content and tools for offline people, centered on kids. This is a great mission and in the future, if I find the opportunity to help my local community, I'll try to use the EndlessOS tools and content to provide good learning content for kids without online access.

I was very happy these years at Endless, and I've learned a lot from different great people. It's incredible the number of talented software engineers that are related to Endless, and for me it was a real privilege to be able to share this space and mission for a few years.

The future!

So there we go, I'm exited for this change, and also sad about leaving a great project, but life is change and we should go ahead and think about the future! And my future is green now.

And if you don't know how to pronounce it, here you've a music video: