danigm.net - work

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.

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.

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.

The end of 2022

danigm — Fri, 30 Dec 2022 00:00:00 +0100

Is the end of 2022 and the beginning of 2023, so it's the right time to look back and see what great things happened during the year, and also it's the time to plan some new year resolutions.

My contribution to GNOME in 2022

I've been focused this year on the GNOME Translation Editor, migrating it to Gtk4. It's not ready yet, but I hope I will be able to have a working version soon™.

It started this summer with one intern from Outreachy, that did some initial work, building with the new Gtk4, and after the summer I started to clean the code and fixing issues, and lately, I'm trying to replace some deprecations for the next Gtk release.

so I'm working on the code, modernizing it, and replacing every usage of GtkDialog and GtkTreeView, and trying to follow the GNOME HIG as much as possible.

Live coding Streaming

I started the year spending a lot of time working on Gtk on live stream on Twitch, but after the summer I was spending less time... I didn't find the time or the energy to do it regularly.

Changes in the business

This year was also a year of changes in my work life. After the summer I left Endless, after three years of working there, to join SUSE.

I really enjoy my time at EndlessOS, the first years working on the Hack Computer and the last year working on the Endless Key. I really like the EndlessOS mission and what I was doing there, with a lot of great people.

But I was looking for something more in my career path, and I had the opportunity to join SUSE. Since September, I'm part of the Python packaging team at SUSE and I've to say that I really love this job. It's a bit different from what I have been doing before, but the maintainer life is something that I enjoy, having the opportunity to contribute to a lot of different projects and debugging and fixing random bugs is one of the most rewarding tasks to do (when you are able to find the problem).

Tumbleweed is now my favourite GNU/Linux distribution and the future of SUSE ALP looks really promising.

Changes in life

This year comes also with a lot of changes in my personal life too! At the beginning of the year I was able to bought a house, so I've now a permanent residency, after a lot of years of changing from one rent house to another one.

And this year was also the year that I was able to get the kickboxing black belt, after almost 8 years of practicing. This is the end of a learning path, and also the beginning of a different one, trying to master this fighting sport.

New year resolutions

2022 was great, but we can make 2023 even better, I'm looking always to learn and improve, so it's good to do some new year resolutions to try to complete during the next year.

Complete the Gtranslator migration to gtk4 and GNOME HIG improvements!
Be more regular with the live coding streams
Give some love to the PyGObject project
Do more serious kickboxing training and loose 10Kg
Play more chess games

That's all! Happy new year and Have a lot of fun...

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:

Endless Orange Week: Hack content creators platform (2)

danigm — Mon, 15 Nov 2021 00:00:00 +0100

The past Friday was the last day of the Endless Orange Week. It was a nice and fun experience, and even if I was not able to do as much as I wanted, we were able to make something that "works" in the Hack project.

The Hack Quest editor

The first step to have custom quests on the Hack app was to complete the Ink language support. We started to work on this some time ago, but never completed the functionality.

I worked on that the first three days, updating the ink library and building the missing pieces to be able to load quests from random paths. I've implemented that in a way that the Hack application is able to receive a path to a .ink file, and it's able to build and run the quets.

The Quests are not just the script, but they have some metadata, like title, subtitle, description, difficulty and the card image to show on the interface. To solve that I defined a "custom quest bundle format", that's bassically a folder with:

questId
quest.jpg
metadata.json
quest.ink

So I also added the functionality to import a bundle zip file and export with the quest information.

I created some command line options to use this new functionality:

  --play-ink=FULL_INK_FILE_PATH                 Start a custom ink quest.
  --import-quest=PATH_TO_BUNDLE_OR_INK_FILE     Import a custom ink quest.
  --export-quest=CUSTOM_QUEST_ID                Export a custom quest bundle.

Quest creation interface and the Inky Editor

The first idea was to try to provide a full quest creation experience in the app, but that was too much, so we decided to simplify the way to create quests and depend on the Inky editor external tool. Manuel Quiñones took some time to update the flatpak application with the latests ink version, so we can use to create custom quests.

The Inky editor provides help about the language, syntax highlighting and a simple way to test the script, so it's a nice tool. The main problem with this tool is that it doesn't provide a way to launch it with a file path so it's not possible to integrate with the Hack app.

So at the end, the Quest creation dialog is just a way to define the metadata and to select the Quest ink files from your filesystem. How the ink script is created is a decision to make for the content creator.

The future

We've no time to complete all we wanted to do, and I didn't create a new release, so this new functionality is still not there. But we'll try to do a release soon.

Simon is working on some interface improvements and also on a new tutorial Quest, so we can introduce the Custom Quest creation tool in the same app.

The Character editor

The other part of this week planning was the character editor. Joana did a really nice work designing the application, the initial assets and the user experience, but I had not too much time to work on the implementation. So I spent just one day working on this.

The main idea was to create a new independent app, and then provide a way to integrate with the Hack application and the custom Quest creation dialog. And it'll be a simple application so maybe it could be useful or interesting for other people, it's a fun way to play around and create random faces.

We just created the application Avatar Creator. I created a simple python Gtk4 application and worked a bit on the basic functionality. So right now it loads a list of svg assets and provide the 3x3 grid. You can click on a grid cell and then choose what basic image should go there.

I added the initial set of basic images, created by Joana, to create this funny robot faces, but the format is simple enough to extend with different "avatar libraries" in the future.

Right now it's also possible to export to png, so the app is functional, but it needs a bit more work.

My idea is to work a bit more in the following weeks, when I have some time, on weekends or holidays and at some point, publish it in flathub. And lets see if there are more developers interested on this app so it can grow.

The application is simple enough to be a good place for GNOME newcomers and it's also a fun project to work on. A simple toy app to create faces that could have some potential, some future ideas:

"Smart" random faces generator
Configurable grid: Maybe is interesting to make it bigger or smaller to play around
Programmed simple base image manipulations, like rotation, mirror, color
Animation creation, maybe be able to export to gif

The Endless Orange Week experience

This week was a really nice experience, because we were working in a "personal" chosen project, that we liked and without the day to day meetings, times schedules and other related work stuff.

But that was not all. In Endless we've different teams that work mostly isolated, because we're working on different fields, we've some overlapping, but we work day to day as small teams, and this week we were all using the same slack channel to show our progress, and it was nice.

Maybe now that we're not a big organization with a lot of workers, we can do something like this more often, it's always good to know more about other coworkers and to learn something that maybe it's not related with your main project, but it could be interesting.

I'm really happy that we did this Endless Orange Week, it's sad that it ended too soon, I'm waiting to learn from my coworkers what amazing things they do during this week and I'm looking forward the next year Orange Week!

Endless Orange Week: Hack content creators platform

danigm — Mon, 08 Nov 2021 00:00:00 +0100

This week (Nov 8 – 12) I am participating in Endless Orange Week, a program where the entire Endless team engages in projects designed to grow our collective learning related to our skills, work and mission.

We propose a project, that could be anything, and then work during the whole week, without distraction. I've choosed to work on the Hack project, that's a really nice project that needs some love, because since the past year, we have other priorities, so there's no time to improve the Hack app.

The project: Hack content creators platform

The Hack application is a "Quest" launcher, and each Quest is an interactive learning experience, a guided introduction to some technology or topic.

Quests are just python scripts, with a simple library to expose messages to the user, ask questions, or wait for desktop events, like launch an application, focus an application, etc. And all these Quests are inside the application, and are created by the Hack team and released with a new Hack app flatpak.

The main idea of the project is to provide a simple Quest editor to allow any Hack user to create and share their our Quests.

To have this Hack content creators platform we'll need:

To simplify the way we create Quests, instead of a python script, we'll uses a Domain Specific Language, called Ink. We started to work on this, but we never ended the support.
To create the interface to be able to import and export custom Quests, that could be zip bundles, with the Ink script and some images.
To create the interface to write the actual Quests and save or bundle.
Create some introductory Quest to explain "how to create your own Quests!".
Create an character editor, to be able to "design" new characters for Quests.

The Quest editor

The Quests will be written using the Ink language, and there's something done before. The first idea is to just provide a text editor and some helpful information about the format, and maybe a button to validate. But if there's time we can use something advanced or even integrate the Inky editor.

The Character editor

Each Quest has a main character, and we've five in the Hack app right now, but it could be great to be able to define new ones for custom Quests. That's the idea of this part of the project.

The initial idea is to have a library of character parts to combine, and the editor will allow the user to combine this parts and maybe change colors, to be able to create unique characters for your Quests.

The Team

I'm not working alone in this "side" project during the Endless Orange Week, Simon Schampijer and Joana Filizola will be working on this too, so this is a big task but we've a great team. Let's see how far we are able to go during just one week.

The impact

This is just a project to try to keep alive more time the Hack application, without a lot of effort or a whole team behind it. We are not able to put more content there periodically, so if there's a way to create new content easily and (maybe in the future) a way to publish, it'll be possible to create a community around the project.

And we have also new possibilities, in the near future, we can add some Hack content to the Endless Key, and using the Ink language, so this editor could help to bring more content there easily.

And the final piece, the Character editor, could be an independent application, a nice simple application that could be used to create your character for your profile photo, or to generate random character pics.

EndlessOS dual boot with Fedora

danigm — Sat, 25 May 2019 00:00:00 +0200

I've a ThinkPad X1 Yoga, that's basically a ThinkPad X1 Carbon 4th but with a touch screen with a pencil that works like a wacom tablet.

I've this laptop since 2016. The first thing that I did when I received it was install a GNU/Linux operating system. I'm a GNU/Linux user since the year 2000 going through a lot of distributions, Debian, Ubuntu, Archlinux, etc.

When I received this computer I've a customized Archlinux there, and I wanted to dd my harddisk and boot, but I was unable to do that. I didn't know nothing about UEFI and I was unable to boot the Archlinux installer.

So I decided to go ahead and change my main distribution. I installed Fedora and almost all the hardware worked so I keep that one and was happy, until today :P

OStree, the new way of distribute GNU/Linux

With OStree and flatpak, there's a new way to distribute GNU/Linux, instead of use directly a package manager and update each package, we can use OStree and mount the root filesystem as read only and do full OS upgrades without broken packages and dependencies and so. The operating system go as is and the user should try hard to break it.

The other great thing about OStree is that it's like a git repository, so you can have different branches and a history, so you can easily go back and forward, it's really easy to test the beta and go back without breaking your system.

The main problem is that you can't install anything on your OS, you should use contained apps like flatpak or install by hand, you can't use apt-get. But that's okay for a day to day user, a power user always can unlock the OS and use it as a normal GNU/Linux distribution.

I wanted to try one of these distributions. The logical choice was Silverblue because it's a Fedora and I'm using it for three years now, but there's another option, EndlessOS is also OStree based, and I'm working with this OS, so I should give a try and use EndlessOS.

The EndlessOS install process

Like all the new modern GNU/Linux distros, EOS comes with a easy to use installer, you only need to boot from the USB and click next until it's done...

But here we've the first problem. I've more than one partition in my disk:

/dev/sda1: UEFI
/dev/sda3: Fedora /
/dev/sda8: Swap
/dev/sda4: Fedora /boot
/dev/sda6: /home

I want to keep my Fedora (who knows if something bad happens) and try to use the same home partition for my new EOS. But the installer only give me the option to erase all and have a clean system. But that won't stop me.

Let's go back and instead of reformat I will click on Try Endless OS:

What we need to do, Robert McQueen gave me some directions:

The constraints for booting Endless are 1) you use our grub, and 2) the root partition is labelled "ostree"

So if you have an EFI system, you can copy our EFI binaries into the ESP, and create a new partition for Endless, then dd the endless ostree filesystem into it

Then you should be able to boot, if you add a boot entry for the endless grub to your firmware, or make it the default (by providing the fallback boot64.efi or whatever it's called), or chain load it from another Linux loader

Install EOS with other linux (EFI system)

Boot from USB, select try
Launch the gnome-disk-utility and prepare a partition. I've not free space, but I was able resize my Fedora partition and I split in two of the same size, now I've a new ext4 partition /dev/sda7 with 25GB.
Copy the endless ostree:

$ sudo su
# dd if=/dev/mapper/endless/image3 /dev/sda7

Copy endless grub to EFI. I mounted all partitions in /tmp, the first partition in /tmp/sda1 and the EOS efi in the /tmp/EOS:

# mkdir /tmp/sda1 /tmp/EOS
# mount /dev/sda1 /tmp/sda1
# mount /dev/mapper/endless-image1 /tmp/EOS
# cp -rf /tmp/EOS/EFI/endless/ /tmp/sda1/EFI

Add the new boot entry:

# efibootmgr -c -d /dev/sda -p 1 -L EOS -l \\EFI\\endless\\grubx64.efi

Set as default boot:

# cp /tmp/EOS/EFI/endless/grubx64.efi /tmp/sda1/EFI/Boot/bootx64.efi

Reboot and create my default user. Then I add my home partition to the /etc/fstab file:

UUID=c885e171-1a03-4afb-8519-f9fe26fe92b7 /sysroot/home ext4 defaults 1 2

And because the first user in EOS is the shared account, with UID 1000, I've to change the UID of my user editing the file in /etc/passwd. Then I rebooted again and all works. I've all my flatpak apps installed in the user space working.

So here we're, with a shiny new OS working like a charm:

The EFI and efibootmgr (who needs grub to select the OS?)

I didn't know much about UEFI and I was very impressed about how easy is to update this from GNU/Linux. There's a tool called efibootmgr that does all the work, and you can mount the partition, that's a FAT32, and put files there.

In my ThinkPad, I can boot directly to the UEFI boot menu pressing F12 during the boot, and that menu can be changed using the efibootmgr so it's not needed anymore to use the grub2 OS selection interface, I can use the UEFI menu for that!

This has some disadvantages, if you remove files from the UEFI partition, you can break the whole boot, so review all before any change.

I'm a hacker

danigm — Sun, 17 Feb 2019 00:00:00 +0100

I've the strength of the one that fails, trains and returns

Some time ago I wrote about my interview process trying to get a job at GNOME. After this blog post was published in the GNOME planet, I received a lot of comments from the Great GNOME community.

This guided me to take a look to the companies that was looking for GNOME developers and after some interviews I finally get an offer to work on Endless.

All the process was online, I've been working from home since 2011 and I want to continue like this. I'm living in Málaga, the south of Spain and I was looking for a remote job.

I've a very nice interview process, talking with developers that I knew about from their contributions to free software and these interviews weren't technical, that's a good thing about the free software contribution and the community, if someone wants to know my technical skills, he only need to look to my gitlab or github and he will find a lot of code. These interviews were personal and with some management questions, to know if I'll fit in the team and the company.

I did the interview to work directly on the Endless OS, in the desktop team, but after some interviews I ended in other team, working with the Endless OS and all GNOME technology, but in the Hack Computer.

The hack computer

The hack computer is an educational project. The main idea is to provide a fully functional computer for kids to be their first personal computer and also provide a way to teach kids to hack.

The computer is a usual laptop, with an Endless OS running, and with some extra applications that try to guide kids to explore, modify and finally hack the computer learning in the process about GNU/Linux, the code and that any part of your software can be hacked to make it better, an introduction to the free software and the great world of open source code that you can modify to learn, play or simply because you can.

The way to guide kids to learn is like a video game, with characters that will appears in your desktop and will guide you with tips and challenges and after each quest completed the kid will learn something, playing with his computer.

If you like this and want to collaborate, we're hiring.

Endless OS

The hack computer is built on top of the Endless OS. Endless OS is based on debian and the desktop is a modified gnome shell, but it's not the usual debian derivative, it's based on OSTree. The main difference is that the root filesystem is read only and updates are managed with ostree, that's like a git repository.

This kind of Operating System is easier to maintain, because the user can't modify the base system, so this means that he was unable to break it. All user applications are installed via flatpak, so are independent of the OS version and because of flathub you can install latests version of apps without the need to update the full operating system.

This is the way that Fedora SilverBlue is trying to follow and is a new way to build and distribute GNU/Linux.

The end of an Era

I've been working in Wadobo since 2011. I created that company with two college friends to try to continue hacking like we were hacking in the Seville LUG SUGUS and earn money from that, and we did it for a long time.

We've been working in free software projects and with free software technology, contributing to the community as much as we can and always trying to free our work.

We created some projects that grow up and follow its own path, like the agora voting system, that Edulix (Eduardo Robles) converts in nvotes.

The self employment was a really good experience. I've been doing was I want for a long time, taking time to contribute to GNOME and other projects when I need it, because I was the one deciding what I want to do. But in the other hand, I've been stuck in the local consultancy market for a long time.

I'm not a business man, I'm a developer and I'm based in Spain, where there is no money inverted in innovation or we was unable to find that money, so we were doing django web apps for a living and spending some time in our interests in the extra time we've. So when I found the possibility to work full time in an innovative project, I've no choice.

We'll try to continue with the Wadobo idea, like a group of people interested in free software and new technologies, maybe this will derive into a Linux User Group or maybe in the future someone takes the initiative and build a business around this again.

Hacking

I'm really happy with this change. Endless OS and the hack computer are really great projects with a lot of bleeding edge technology and a really great group of people, and I'm really exited to be able to work with people all around the world in a project with a global vision.

I don't want to leave the roots I've here with my Wadobo friends and the local community and local technology ecosystem. This is also related with the Endless vision. Spain, and here in the south, in Andalucía, we've a technological breach that we try to fill with free software.

I'll continue working with the Seville University, because they give me a lot and I think it's a talent pool, we only need to guide those students to the GNOME community or to other free software communities out there, to save their souls from the privative software and the dark side.

I'll continue supporting initiatives like the Free Software Contest

By the way, I'll be talking about rust in the Seville University the next Tuesday 5th of March 2019, if you're in Seville, come to talk with me :D

GNOME Gtk Developer

danigm — Wed, 05 Dec 2018 00:00:00 +0100

I tried and I failed.

This summer, during the GUADEC 2018, the GNOME foundation announces some job positions. One of that job was for a Gtk+ core developer. I tried to get that job and after a long period I was rejected.

The final developer selected for this possition is Emmanuel Bassi, a very active developer in the core of GNOME and the one that's behind the great The History of GNOME Podcast.

To be honest, I really wanted that job. It's a dream job for me, working fulltime in a free software project, by a foundation, with the great GNOME technology and community.

But I've to say that just when I saw the foundation announcement about this position I thought about ebassi, because as far as I know, he's the best one to do that job. In any case, I wanted to give a try and go for that job, I didn't know about other people going for it, so maybe I can do it.

Some background

I'm working in my own little company since 2010. We're three coworkers with the same percentage of the company, like a cooperative and we work mainly as external consultant for bigger companies. We do a lot of work related with GNU/Linux and free software, but lately we mainly do web apps with python and react, because that's what our current clients ask for.

But the first paid project for wadobo was a GNOME project, I started the company with a small project to improve accessibility in PDF documents, working directly in evince. And then we worked with Qt, QML and other technologies, but I wasn't able to get a paid work on GNOME or Gtk+ since that initial work.

In any case, I continued working in GNOME in my spare time, trying to contribute, first with libgepub, trying to bring epub support to evince, and then to GNOME Books. And the last year I became more active because of Fractal and Gnome Translation Editor (gtranslator). And I've been mentor for the GSoC 2018 and now I've two interns in the Outreachy program.

I've some time to spend in GNOME, but I'm not making money from that, so now I'm starting to look for that actively, because I really want to have more time to spend working with free software.

So, I talked with my coworkers, to be honest with them, and I told them that I was going to try to get the Gtk+ core developer position.

The process

This was a long process, I think that it was long because there was a lot of people for that position.

The Email: I sent the initial email in mid July, with a long description about me and my work in gnome and free software, with a little hope in my heart.
The Survey: Then I received an email with a link to a survey to complete with more information. That was great, because it sounds like I've passed the first cut.
The Interview: At the end of August I received a conglatulations email. My resume was positively reviewed and I'll have a personal interview.

That was really nice and I started to think that maybe it was possible after all.

At the mid of September, I've a video conference meeting with Carlos Soriano and Matthias Clasen. For me was a great interview, talking about my experience, GNOME and Gtk+. Maybe the interview was a disaster and they are just a very nice people being nice with a poor developer, but at the end I thought that it was well and I was very exited about this.

The failure

After a long time without knowing anything, I received the email that I was waiting for. I wasn't selected for the position. The next week, the foundation announces the new staff member and in that moment I noticed that I've had no chance to get the job. He's the better candidate and I'm really happy because this is really good for GNOME.

And now what?

At the end of the process, I think that this was a great experience for me, because this forces me to think about my career, what I want to do in the future and I went through a full selection process, something that I've not done since 2009.

I will continue trying to find the way to work in GNOME or something realated with the GNU/Linux desktop or core technologies.

I did a lot of web development, I've a lot of experience and I'm really good doing web with django, but I really want to go back and work with other technologies, programming in C, the new Rust language and with some low level technologies.

If someone need help, I'm here and I can work as a contractor. For now I'll continue working in Wadobo, trying to find clients that requires desktop or low level work.