Florian RICHER

My first participation in a KDE PIM Sprint

Mon, 15 Dec 2025 00:00:00 +0000

My First Participation in a KDE Sprint

During Akademy 2025 in Berlin, I signed up for the KDE PIM Sprint. While I had never worked on PIM before, I had contributed to Plasma Mobile, Koko (for OCR implementation, still a work in progress), and Solid (for LED implementation). This was also my first time participating in a KDE Sprint.

I arrived by train from Limoges to Paris at 10:30 PM on Friday. Unfortunately, I couldn’t arrive earlier due to professional commitments, and I had to leave again on Sunday at 5:30 PM.

Starting the Sprint

On Saturday morning, I joined everyone for breakfast. Afterward, we had meetings throughout the morning and part of the afternoon. In parallel, I compiled Merkuro and KMail on my laptop. Normally, I work on my desktop computer, so I needed to compile all the KDE packages on my laptop, which isn’t very powerful. Luckily, I had started the compilation process on the train.

Once the meetings were over, I began working on PIM projects. My first task was to read the codebase to understand the various packages related to Merkuro.

Understanding Merkuro

Merkuro relies on components from Akonadi, KMailTransport, KDE PIM Runtime, and KIdentityManagement.

However, I encountered an issue with distrobox: when Carl and I tried to configure an IMAP account in Merkuro Mail, the password was never saved. After some investigation, I discovered that this was related to KWallet and KSecrets. Since distrobox doesn’t use the Plasma Desktop environment by default, many “basic” KDE services aren’t running in the background.

To fix this, I had to run the following commands:

1
2
3
4


source ~/kde/build/kwallet/prefix.sh
ksecretd &
kwalletd6 &
wait

After that, I successfully configured my first IMAP account in KMail and Merkuro, and I was able to retrieve all my emails from Proton Mail.

Note: The IMAP accounts in KMail and Merkuro are synchronized because both use KIdentityManagement and KMailTransport.

Contributions

I also opened a small merge request based on Carl’s recommendation regarding the unnecessary use of Layout.fillWidth: true (MR #595).

Next, I tried to add a new identity in Merkuro, but it wasn’t saved. This time, the issue wasn’t related to KWallet. Instead, it was because when the identity was passed as a property to the component, it was copied. So, when I modified the identity, it only modified the copy, not the “main” identity reference itself. This happened because Identity is a QGadget type, not a QObject see the definition here.

To fix this, I changed the property type to the backend type. I could then access the current identity using backend.identity. I updated all occurrences in the code and opened the following merge requests:

MR #38 to fix the Cryptography component.
MR #40 to fix the remaining identity information.

Finally, I started investigating why I didn’t receive any errors when trying to add an IMAP account related to KSecrets. It seems to be managed here.

I left the Sprint having started work on the “Add an Identity” feature, which you can follow here.

Conclusion

I really enjoyed participating in the KDE Sprint. It was wonderful to catch up with Carl again. I’m truly grateful for the time he took to help me get up to speed with the project. The discussions with Laurent were also incredibly engaging, and even my brief conversation with Ingo was meaningful, though I still struggle a bit with spoken communication.

Once I’m less busy personally, I plan to:

Migrating the Waydroid implementation to Plasma Workspace, as discussed with Carl.
Continuing my contributions to PIM.
Helping out with KAIChat.

Looking forward to the next opportunity to collaborate with the KDE community!

Useful links

Official KDE PIM Sprint 2025 Blog post

Gitlab projects:

Configurer kde-builder sur des bases immuables et lancer un projet KDE

Sun, 06 Oct 2024 00:00:00 +0000

Introduction

Les systèmes d’exploitation à base immuable, tels que NixOS ou Fedora Atomic, offrent de nombreux avantages en termes de stabilité et de sécurité. Cependant, ils présentent également des défis uniques pour les développeurs, notamment lorsqu’il s’agit de configurer des environnements de développement comme kde-builder. Dans ce post, nous explorerons comment surmonter ces obstacles en utilisant des outils comme distrobox ou toolbox, permettant ainsi aux développeurs de profiter des avantages des systèmes immuables tout en conservant la flexibilité nécessaire pour travailler efficacement avec kde-builder.

Préparer son environnement

Introduction

La préparation de l’environnement de développement est essentielle pour utiliser kde-builder sur des systèmes immuables. Les outils et étapes varient selon la distribution : Fedora Atomic intègre toolbox, facilitant le processus, tandis que NixOS nécessite la configuration manuelle de distrobox. Je vais donc dans un premier temps expliquer comment installer distrobox sur NixOS. Ensuite, je finirais par la configuration générale pour Fedora Atomic et aussi pour Nix OS.

Installation de distrobox sur Nix OS

Pour installer distrobox, il suffit de rajouter dans sa configuration configuration.nix ou dans son flake la configuration suivante:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33


# Active docker
virtualisation.docker = {
 enable = true;
};

# Rajoute l'utilisateur au group docker pour éviter d'utiliser la commande sudo tout le temps.
# Par contre, ça rajoute un risque d'élévation de privilège sur le système
# Voir le warning ici https://docs.docker.com/engine/install/linux-postinstall/#manage-docker-as-a-non-root-user
users.users.<user>.extraGroups = [ "docker" ];

# On peut aussi l'ajouter en rootless
virtualisation.docker.rootless = {
 enable = true;
 # L'option setSocketVariable définit la variable DOCKER_HOST pour l'instance Docker rootless pour les utilisateurs normaux par défaut.
 setSocketVariable = true;
};

# Si vous souhaitez utiliser podman à la place
virtualisation.containers.enable = true;
virtualisation = {
 podman = {
 enable = true;

 # Ajoute l'alias `docker` pour une utilisation plus transparente avec les outils compatibles docker seulement
 dockerCompat = true;

 # Nécessaire pour que les conteneurs sous podman-compose puissent communiquer entre eux.
 defaultNetwork.settings.dns_enabled = true;
 };
};

# On rajoute distrobox
environment.systemPackages = with pkgs; [ distrobox ];

Une fois la configuration ajouté, il suffit de taper la commande:

Sans flake

1

nixos-rebuild switch

Avec flake

1

nixos-rebuild switch --flake [path du flake]#[nom de la configuraiton]

Normalement, vous devriez avoir la commande distrobox de disponible. Si c’est le cas, vous pouvez allez à cette étape

Création du container pour travailler

NixOS Distrobox

Pour créer le container avec distrobox, on peut passer par ce fichier distrobox.ini

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


; Nom de notre environnement
[kdedev]
image=quay.io/fedora/fedora:latest
; Change le home directory si vous souhaitez isoler votre environnement de travail de votre home directory host
home="${HOME}/.distrobox_home/kdedev"
; Uniquement si vous possedez une carte NVIDIA. Distrobox va intégrer des patchs pour mieux gérer les intégrations avec NVIDIA.
nvidia=true
; Si vous souhaitez faire une image rootless
root=false
; Pull l'image durant la création de l'environnement
pull=true

Ensuite, il suffit de taper la commande pour créer notre environnement nommé kdedev

1

distrobox assemble create

Une fois l’environnement créer, il reste une dernière étape à faire. Je recommande de rajouter ceci dans votre ~/.bashrc ou dans le bashrc situé dans le container configuré avec home:

1

alias new_shell="env -u PATH -u QML2_IMPORT_PATH -u QT_PLUGIN_PATH -u NIXPKGS_QT6_QML_IMPORT_PATH -u XDG_CONFIG_DIRS bash -l"

Vous pouvez l’éditer plus facilement en allant dans votre environnement de travail avec:

1

distrobox enter kdedev

Cet alias peut-être utile pour retirer les variables d’environnements que rajoute NixOS. Sur Fedora Atomic, ça ne pose pas de problème, car ils respectent la FHS donc les librairies pointent au même endroit que dans le container. Sauf que Nix OS ne respecte pas la FHS (pour de bonnes raisons), donc on peut avoir des conflits lors de la compilation ou de l’exécution de programme que l’on aura compilé avec kde-builder.

La FHS est une structure de fichier normalisé dans le monde Linux plus d’info ici

Pour l’utiliser, une fois dans votre environnement de travail, il suffit de faire:

1
2


distrobox enter kdedev # Pour rentrer dans votre environnement de travail
new_shell

Fedora Toolbox

Pour la configuration avec Fedora Toolbox, c’est assez simple, car Fedora intègre tout par défaut. Il suffit de taper la commande:

1

toolbox create -r [numéro de release fedora] [nom de l'environnement]

Dans notre cas, ça sera:

1

toolbox create -r 40 kdedev

Note: À l’heure ou j’écris le post, j’ai encore des soucis pour lancer kwin avec Fedora Toolbox. J’ai des problèmes de permission sur les DRM. Je pense que c’est lié à selinux.

J’obtiens l’erreur ci-dessous lors du lancement de kwin_wayland

1

KMS: DRM_IOCTL_MODE_CREATE_DUMB failed: Permission denied

DRM : C’est Direct Rendering Manager et non Digital Rights Management pour plus d’infos

Test de notre environnement

Avant de lancer notre test, il faut installer kde-builder. Vous pouvez voir mon post précédent ici ou vous pouvez suivre ce lien qui est le même que dans le post.

Rappel Il faut l’installer dans votre environnement créé juste avant.

1

distrobox enter kdedev

NixOS Distrobox

1

toolbox enter kdedev

Fedora Toolbox

Une fois votre environnement configurer, normalement vous pouvez tester de compiler solid avec la commande :

1

kde-builder solid

Puis de lancer solid avec la commande:

1

source "$HOME/kde/build/solid/prefix.sh" && solid-hardware6 list

Voilà 🙂 Normalement vous êtes prêt à travailler sur KDE avec un système immuable.

Note pour le démarrage de KDE Plasma Mobile

Pour plasma-mobile, il est nécessaire de configurer d’autres variables d’environnements. Voici le script que j’utilise :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


source "$HOME/kde/build/plasma-mobile/prefix.sh"

QT_QPA_PLATFORM=offscreen plasma-mobile-envmanager --apply-settings

# Environment variables
export QT_WAYLAND_DISABLE_WINDOWDECORATION=1
export QT_QUICK_CONTROLS_MOBILE=1
export PLASMA_PLATFORM=phone:handheld
export QT_QUICK_CONTROLS_STYLE=org.kde.breeze

QT_QPA_PLATFORM=wayland dbus-run-session kwin_wayland --xwayland "plasmashell -p org.kde.plasma.mobileshell" --width 360 --height 720

Source

Vous pouvez aussi lancer le menu du haut sans lancer tout kwin avec le script :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


source "$HOME/kde/build/plasma-mobile/prefix.sh"

QT_QPA_PLATFORM=offscreen plasma-mobile-envmanager --apply-settings

# Environment variables
export QT_WAYLAND_DISABLE_WINDOWDECORATION=1
export QT_QUICK_CONTROLS_MOBILE=1
export PLASMA_PLATFORM=phone:handheld
export QT_QUICK_CONTROLS_STYLE=org.kde.breeze

qmlscene-qt6 "$HOME/kde/src/plasma-mobile/tests/ActionDrawerTest.qml"

Découverte de Nix et de Flake

Fri, 04 Oct 2024 00:00:00 +0000

Introduction

Avant de commencer, je tiens à dire que j’ai fait ce post en partie pour l’entreprise Unova où je travaillais. Je tiens à les remercier pour m’avoir autorisé à réutiliser le contenu sur mon site.

Nix est un gestionnaire de paquets basé sur le langage Nix. Il permet de gérer facilement une configuration système, d’un projet ou même d’un package (logiciel) et surtout de s’assurer de la reproductibilité de la configuration. Cependant, par défaut, Nix ne permet pas de “lock” la version de la configuration sur l’ensemble des machines. C’est pour cela que les développeurs développent Flake.

Flake est une feature experimentale qui permet de lock les dépendances sur une version très précise. Un peu comme le Gemfile.lock ou même le package-lock.json.

Grâce au coté déclaratif de Nix, on peut par exemple facilement tester un outils sans devoir l’installer de manière permanente sur sa machine avec :

1
2
3
4
5
6
7


nix run nixpkgs#cowsay Salut # Lance directement la commande cowsay avec l'argument Salut

nix shell nixpkgs#cowsay # Prépare un shell avec la commande cowsay dedans
cowsay Salut # La commande est disponible
exit # On revient sur notre shell de base

nix-collect-garbage # On nettoie les dépendances inutiles (Supprime cowsay)

Ou même configurer son shell existant pour pouvoir développer sur un logiciel

1

nix develop nixpkgs#cowsay # Prépare le shell actuel avec toutes les dépendances nécessaires pour compiler et exécuter cowsay

Attention: Il créer un shell avec les outils nécessaires pour travailler dessus, mais ne récupère pas le projet en lui-même.

Le langage Nix

Nix est un langage de programmation dédié pour la configuration d’une machine ou compilation de programme donc il peut être compliqué à prendre en main. Il est différent des langages traditionnels, on peut le voir comme un language de construction d’un attribut set qui sera utilisé ensuite.

Un attribut set peut-être vu comme un objet JS.
1
{ a = 12; b = 14; }

Je ferrais surement un post pour expliquer plus en détail le langage car il est assez complexe. J’ai rajouté quelques liens utiles ici

Structure d’un Flake

Partie `inputs`

1
2
3
4


inputs = {
 nixpkgs.url = "github:nixos/nixpkgs/nixpkgs-unstable";
 flake-utils.url = "github:numtide/flake-utils";
};

Dans cette exemple, on peut voir que j’ai rajouté les dépendances nixpkgs et flake-utils.

La dépendance nixpkgs correspond au repo github nixpkgs. En général, on l’utilise pour récupérer des packages ou utiliser les outils mis à disposition par les contributeurs de NixOS.

On peut retrouver dans le repo.

/nixos Contiens la configuration pour nixos (La distribution basée sur Nix)
/pkgs Contiens tous les packages (ex: ruby_3_3)

Les nouveaux packages doivent être mis dans le sous-dossier by-name. C’est un nouveau standard du projet. Les packages déjà existants migrent dessus petit à petit. Si un package manque, n’hésitez surtout pas à contribuer au projet.

lib Contiens plein d’outils pratiques comme makeLibraryPath ou makeIncludePath
doc Contiens la doc ^^
maintainers Contiens la liste de tous les mainteneurs des packages.

La dépendance flake-utils contient des helpers pour faciliter la configuration pour un ensemble de systèmes (x86_64-linux, x86_64-darwin, …).

darwin Correspond au système Mac OS

Partie `outputs`

Outputs est une fonction qui prend en paramètre un attribute set avec pour attributs self et les dépendances déclarées dans la partie inputs.

Dans le cas ou l’on a les dépendances suivantes:

1
2
3
4
5


inputs = {
 nixpkgs.url = "github:nixos/nixpkgs/nixpkgs-unstable";
 flake-utils.url = "github:numtide/flake-utils";
 mon-input-custom.url = "github:mongithub/monprojet";
};

On aura les entrées suivantes dans outputs:

1
2
3
4
5
6
7
8


outputs = { self, nixpkgs, flake-utils, mon-input-custom }:
# ^^^^^^^ ^^^^^^^^^^^ ^^^^^^^^^^^^^^^^
# Doit avoir le même nom que dans les inputs
{
 devShells.x86_64-linux.default = {...};
 packages.x86_64-linux.default = {...};
 nixosConfigurations.x86_64-linux.default = {...};
}

Les attributs que l’on peut retrouver dans outputs sont:

devShells Des environnements de développement.
nixosConfigurations Des configurations de NixOS (La distribution Linux)
darwinConfigurations Des configurations pour Mac OS En savoir plus
packages Des packages (Docker, ruby, go, rust, …)
[...]

Exemple de flake

Dans cette example, j’ai déclaré un environnement de travail utilisable avec la commande nix develop. J’ai rajouté en dépendances la librairie openssl, la commande redis et un script au lancement du shell.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25


{
 description = "Ma description";

 inputs = {
 nixpkgs.url = "github:nixos/nixpkgs/nixpkgs-unstable";
 flake-utils.url = "github:numtide/flake-utils";
 };

 outputs = { self, nixpkgs, flake-utils }:
 flake-utils.lib.eachDefaultSystem (system:
 let
 pkgs = import nixpkgs { inherit system; };
 in
 {
 devShells = rec {
 default = pkgs.mkShell {
 inputsFrom = with pkgs; [openssl];
 packages = with pkgs; [redis];
 shellHook = ''
 echo "Votre shell est configuré"
 '';
 };
 };
 });
}

Mettre à jour le `flake.lock`

Le flake.nix vient avec un fichier flake.lock qui permet de vérrouiller la version de chaque input. Si on souhaite mettre à jour nos packages pour notre projet. Il est nécessaire de le mettre à jour.

On retrouve deux commandes:

nix flake update Mets à jour tous les inputs
nix flake lock --update-input <input> Mets à jour uniquement un input en particulier

Débugger sa configuration avec la console nix

Il existe une console depuis la version expérimentale de nix nix-command. On peut y accéder avec la commande nix repl.

Normalement, on doit avoir un shell comme ci-dessous

1
2
3


$ nix repl
Welcome to Nix 2.18.2. Type :? for help.
nix-repl>

Dedans, on peut écrire n’importe quoi en nix mais aussi lui demander de charger notre configuration flake avec l’aide de la commande :lf [path racine ou ce trouve le flake]

lf est l’abréviation de Load Flake

1
2
3
4


$ nix repl
Welcome to Nix 2.18.2. Type :? for help.
nix-repl> :lf .
Added 13 variables.

Une fois chargé, on peut accéder aux outputs avec outputs.<type de conf>.<system>.<nom>

Tips : Vous pouvez appuyer deux fois sur Tab pour avoir de l’aide.

Vous pouvez aussi facilement vérifier votre configuration nix avec la commande
1
nix flake check .

Fonctionnement des environnements de développement

Utiliser un devShell

Les devShells permettent de configurer des environnements par défaut. On peut y accéder avec l’aide de la commande nix develop [path du flake]#[nom de l'environnement].

Ex: nix develop .#default

Le path par défaut est déjà le répertoire courant et la configuration utilisée par défaut est également default Donc la commande nix develop suffit dans notre cas, mais si on configure par exemple outputs.devShells.<system>.monshell. Dans ce cas, il faudra utiliser nix develop .#monshell ou nix develop /home/user/monflake#monshell

On peut accéder aux environnements utilisés pour développer n’importe quel package nix. Par exemple, si l’on souhaite aider au développement de ruby. On peut lancer une console de développement avec la commande nix develop nixpkgs#ruby ou même voir la configuration d’un package avec nix edit nixpkgs#ruby

On remarquera qu’ici j’utilise nixpkgs et pas le path du flake. Ça permet d’utiliser la configuration d’un package depuis nixpkgs directement.

Attention Pour des logiciels compilés, en général, il faut d’abord configurer le compilateur via les phases du logiciel. ex: configurePhase et ensuite compiler le logiciel ex: buildPhase . Les phases peuvent varier en fonction du logiciel.

Configurer son propre devShell

Voici une configuration de shell avec des commentaires pour expliquer le fonctionnement.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68


outputs = { self, nixpkgs, flake-utils }:
 # Génère une configuration avec l'ensemble des systèmes par défaut
 # aarch64-linux => ARM sur Linux
 # aarch64-darwin => M1, M2, M3, ... sur MacOS
 # x86_64-linux => AMD et Intel sur Linux
 # x86_64-darwin => Intel sur MacOS
 #
 # Pour configurer avec une liste précise de systèmes, vous pouvez utiliser cette fonction
 # flake-utils.lib.eachSystem ["aarch64-linux" " x86_64-darwin"] (system: [...])
 # Voir plus https://github.com/numtide/flake-utils
 #
 # Les éléments d'un tableau ne sont pas séparés par une virgule ex: [ 12 14 ]
 flake-utils.lib.eachDefaultSystem (system:
 let
 # Importe les packages pour le système.
 pkgs = import nixpkgs { inherit system; };
 # Le mot clef inherit équivaut à import nixpkgs { system = system };
 # On peut aussi inherit depuis autre chose
 # { inherit (pkgs.ruby) pname; } renverra { pname = "ruby" }
 in
 {
 devShells = rec {
 # rec Permet d'utiliser les variables dans le même attributs set
 # Exemple:
 # { a = 12; b = a + 2; } => error: undefined variable 'a'
 # rec { a = 12; b = a + 2; } => { a = 12; b = 14; }
 #
 # Attention, car parfois, on peut faire des infinites recurse par accident.
 #
 # Exemple:
 # rec { a = b + 2; b = a + 2; } => error: infinite recursion encountered
 #
 # Car a dépend de b pour fonctionner, mais b dépend également de a

 # On utilise la fonction pkgs.mkShell qui contient tout ce qui nous faut pour créer notre environnement de travail
 default = pkgs.mkShell {
 # On rajoute des dépendances pour la compilation comme les librairies
 inputsFrom = with pkgs; [ openssl ];
 # On rajoute des binaires ou des librairies pour l'execution
 packages = with pkgs; [ redis minio ];
 # with pkgs permet d'éviter de faire [ pkgs.redis pkgs.minio ]

 # On créer une variable d'environnement
 MY_CUSTOM_ENV_VAR = "test";

 # Parfois nécessaire pour lancer des projets avec des librairies comme Ruby par exemple.
 # *_LIBRARY_PATH permet de dire à l'OS ou chercher les librairies.
 # Il faut le rajouter par exemple si on rencontre le soucis `Could not open library 'libsodium.so.23'`
 # LD_LIBRARY_PATH => Linux
 # DYLD_LIBRARY_PATH => MacOS
 LD_LIBRARY_PATH = pkgs.lib.makeLibraryPath(with pkgs; [libsodium]);
 DYLD_LIBRARY_PATH = pkgs.lib.makeLibraryPath(with pkgs; [libsodium]);

 # Parfois nécessaire pour configurer des projets comme Ruby avec bundle
 # Certaines gems Ruby génèrent un fichier .c avec du code en dure et surtout un `#include <malib.h>` dedans.
 # Sauf qu'ils utilisent pas les outils de configuration du compilateur fournis par les OS. Donc, il faut créer des variables d'environnements pour dire au compilateur ou chercher les fichiers requis.
 # C_INCLUDE_PATH => Pour le language C
 # CPLUS_INCLUDE_PATH => Pour le language C++
 C_INCLUDE_PATH = pkgs.lib.makeIncludePath(with pkgs; [libsodium]);
 CPLUS_INCLUDE_PATH = pkgs.lib.makeIncludePath(with pkgs; [libsodium]);

 # Le shellHook est un script lancé au lancement du shell
 shellHook = ''
 echo "Votre shell est configuré avec MY_CUSTOM_ENV_VAR = $MY_CUSTOM_ENV_VAR"
 '';
 };
 };
 });

Liens utiles

Pour apprendre nix

Pour trouver des packages

https://search.nixos.org/packages

Repository officiel de nixpkgs

https://github.com/NixOS/nixpkgs

Pour connaître l’état d’une Pull Request

https://nixpk.gs/

Compiler un paquet Postmarket OS

Sun, 18 Feb 2024 00:00:00 +0000

À propos de Postmarket OS

Postmarket OS est une distribution basée sur Alpine conçut pour fonctionner sur téléphone, tablette ou sur Raspberry PI. La communauté autour du projet propose un ensemble d’outils comme pmbootstrap qui permet de configurer et d’installer Postmarket OS sur son téléphone. On peut aussi l’utiliser pour compiler son propre paquet et l’installer sur son téléphone facilement.

Configuration de notre environnement de travail

Avant de pouvoir l’utiliser, il faut d’abord l’installer depuis ce lien.

Une fois installé et configuré, il faut d’abord préparer son environnement de travail. Il est parfois nécessaire de mettre à jour le repository pmaports en local. On peut le faire assez facilement avec la commande :

1

pmbootstrap pull

Met à jour le repository pmaports.git cloné en local.

Le repo pmaports.git stocke tous les paquets Alpine avec le fichier APKBUILD utilisé par le serveur de compilation.

Le fonctionnement est similaire à PKGBUILD pour les utilisateurs de Archlinux

Ce fichier contient toute la procédure pour préparer les sources, compiler le paquet depuis les sources, le numéro de version ainsi que la procédure pour vérifier si le paquet fonctionne correctement. Généralement on utilise les tests du projet comme les tests unitaires ou les tests fonctionnels.

On peut également mettre à jour le cache de la commande apk même si c’est pas forcément obligatoire.

1

pmbootstrap update

Met à jour le cache de la commande APK depuis l’environnement de travail

L’environnement de travail se situe par défaut dans le dossier $HOME/.local/var/pmbootstrap/

Si on a déjà un environnement de travail en cours et qu’il contient du cache ou un travail en cours, on peut le réinitialiser assez facilement avec la commande :

1

pmbootstrap zap

Supprime le dossier de la commande chroot pour repartir de 0

La commande chroot permet de changer la racine Linux. Par exemple, on peut faire chroot $HOME/mon_dossier et à partir de ce moment-là, / pointera vers $HOME/mon_dossier dans notre shell actuel.

C’est très utilisé par pmbootstrap pour configurer le système Alpine.

Pour ceux qui veulent utiliser une autre branche, on peut également changer la branche disponible sur le repository.

1

git -C $workdir checkout [branch]

$workdir par défaut se situe dans le dossier $HOME/.local/var/pmbootstrap/cache_git/pmaports/

Exemple de branche utile : kde-nightly

Compilation de notre paquet Alpine

Maintenant, on va pouvoir compiler n’importe quel paquet avec la commande.

1

pmbootstrap build [nom_du_paquet]

Par exemple, on peut compiler plasma-mobile (Attention le paquet est long à compiler)

1

pmbootstrap build plasma-mobile

Par défaut, pmbootstrap va recompiler l’intégralité des dépendances du projet pour s’assurer que notre test sera reproductible. Cependant, lorsque l’on souhaite juste tester un truc, ça peut-être ultra long.

On peut donc utiliser deux options pour nous aider:

-i Permet de dire de compiler uniquement les dépendances du paquet défini dans le fichier APKBUILD
-n Permet d’éviter de compiler les dépendances du paquet défini dans le fichier APKBUILD

Avec le combot des deux options, ça nous évite de tout recompiler.

On a aussi l’option -mp qui peut-être pratique pour changer de mirroir si le téléchargement est lent ou si l’on souhaite télécharger des paquets nightly.

Un mirroir est un serveur utilisé pour télécharger les dépendances

On utilise cette option de cette manière:

1
2
3


pmbootstrap \
 -mp https://nightly.postmarketos.org/plasma-mobile/packages/ \
 -mp http://mirror.postmarketos.org/postmarketos/

On a aussi d’autres options comme:

--details-to-stdout : Affiche le fichier de log dans la console
-j N : Défini le nombre de core CPU utilisé pour la compilation
-t [En seconde] : Le nombre de secondes sans nouveau log dans le fichier avant d’abandonner la compilation
--src : Change les sources du paquet. Par défaut ce sont les sources définies dans le fichier APKBUILD
--arch [arch] : L’architecture CPU du téléphone

Un exemple concret d’une commande que j’ai utilisé pour recompiler ma version de plasma-mobile avec mes changements.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


pmbootstrap \
 -mp https://nightly.postmarketos.org/plasma-mobile/packages/ \
 -mp http://mirror.postmarketos.org/postmarketos/ \
 --details-to-stdout \
 -j 32 \ # Pour utiliser toute la puissance de mon CPU
 -t 3600 -v \ # La compilation est ultra longue donc pmbootstrap abandonne la build avant la fin de la compilation
 build plasma-mobile \
 --src $home/plasma-mobile/ \
 --arch aarch64 \ # Mon téléphone utilise l'architecture aarch64 (ARM64)
 -i \
 -n

Attention

Avant de compiler depuis le repository Nightly, il faut d’abord rajouter la clef de signature
1
2
wget https://nightly.postmarketos.org/plasma-mobile/pmos@local-662fcd2f.rsa.pub
mv pmos@local-662fcd2f.rsa.pub $(pmbootstrap config work)/config_apk_keys/
Source : https://wiki.postmarketos.org/wiki/Nightly

Si vous souhaitez avoir plus d’informations, il suffit de taper la commande

1

pmbootstrap build --help

Et pour avoir les arguments généraux

1

pmbootstrap --help

Envoie du paquet compilé sur le téléphone

Une fois le paquet compilé, il suffit de demander à pmbootstrap de l’envoyer sur notre téléphone via la connexion SSH. Avec pmbootstrap, on utilise la commande sideload comme dans l’exemple ci-dessous.

1
2
3
4
5
6


pmbootstrap sideload plasma-mobile \
 --host [SSH HOST] \
 --port [SSH PORT] \
 --user [SSH USER] \
 --arch [ARCH] \
 --install-key

On a les arguments suivants :

--host [SSH HOST] (Ex: 192.168.1.1)
--port [SSH PORT] (Ex: 22)
--user [SSH USER] (Ex: 192.168.1.1)
--arch [ARCH] : Permet de modifier la valeur définie pour le téléphone (Ex : aarch64)
--install-key : Permet d’installer la clef utilisée pour la vérification des paquets de la machine actuelle.

Tout gestionnaire de paquet comme APK, vérifie si le paquet est valide par rapport à la signature électronique du mainteneur du paquet. Dans notre cas, la signature ne sera pas valide, car le paquet n’est pas compilé par le mainteneur original donc il suffit de rajouter notre signature.

Pour revenir en arrière, il suffit de taper la commande ci-dessous depuis le téléphone ou depuis la connexion SSH

1

sudo apk upgrade -a

APK va réinstaller les paquets depuis les repos officiels.

En cas de problème liée à des conflits de fichier, on peut utiliser cette commande

1

sudo apk fix --force

Cette commande va forcer APK à écraser les fichiers en conflit.

Ma première contribution à KDE

Fri, 12 Jan 2024 00:00:00 +0000

Rapide rappel à propos de KDE

KDE est un projet qui a pour but de développer des logiciels open-source. Le projet comporte plusieurs éléments les plus connus.

KF5 ou KF6 est un ensemble de librairies utilisées pour le développement de l’ensemble des logiciels de KDE. Il est basé sur la librairie QT.

Exemple : Kirigami que l’on peut voir comme un “flutter”.

Note:

KF5 => Basé sur QT5

KF6 => Basé sur QT6

Plasma Shell est l’environnement de bureau développé pour Linux.

Ma configuration

Pour développer sur KDE, KDE fournis un utilitaire assez puissant kdesrc-build. Il permet de configurer l’IDE, compiler, exécuter et gérer les dépendances avec l’aide d’une seule ligne de commande.

Pour le configurer, il suffit de suivre la procédure sur ce lien.

EDIT: Aujourd’hui, il est recommandé d’utiliser kde-builder. C’est le même outil sauf qu’il est écrit en python au lieu de perl. C’est plus simple pour les développeurs qui souhaitent contribuer au projet, car python est plus connu. La configuration reste exactement la même.

Pour plus d’info

Mes premières difficultés

Il faut savoir que quand j’ai commencé à vouloir contribuer au projet KDE. Le projet était en train de migrer de QT5 à QT6. Donc, les configurations nécessaires pour compiler correctement la version 6 était nettement plus compliqué que maintenant. Il n’y avait aucune documentation pour migrer la configuration fournie de base, il fallait fouiller sur Github ou sur les blogs pour réussir à avoir la configuration. Aujourd’hui, il suffit juste de suivre le lien ci-dessus et on peut directement travailler sur KDE 6.

Pour le développement sur KDE Plasma 6, j’ai dû faire quelques réajustements sur le fichier ~/.config/kdesrc-buildrc.

J’ai changé la branche par défaut avec l’option branch-group kf6-qt6. Elle permet de cloner les repositories correctement et d’ajouter l’option cmake -DBUILD_WITH_QT6=on. J’ai aussi changé les fichiers de configuration utilisées pour obtenir le résultat ci-dessous.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


global
 branch-group kf6-qt6
 [...]
end global

include ~/kde/src/kdesrc-build/data/build-include/kf6-common-options.ksb
include ~/kde/src/kdesrc-build/data/build-include/kf6-frameworks.ksb
include ~/kde/src/kdesrc-build/data/build-include/kf6-workspace.ksb
include ~/kde/src/kdesrc-build/data/build-include/kf6-applications.ksb
include ~/kde/src/kdesrc-build/data/build-include/kf6-kdepim.ksb

Configurations utiles

Désactiver l’arrêt de la compilation lors d’une erreur de compilation.

En général, kdesrc-build s’adapte et retire tous les projets qui dépendent de la dépendance qui n’a pas réussi à compiler. Le projet était encore en cours de développement donc les erreurs de compilations étaient très régulières. J’ai tout simplement désactivé avec l’option stop-on-failure false.

Activer le support des LSP

C’est très pratique si on utilise VSCode ou même n’importe quel outil qui supporte les LSP.

Il suffit d’activer les options:

compile-commands-linking => true
compile-commands-export => true

Générer les projets VSCode

Il va générer automatiquement les workspaces VSCode avec les extensions recommander et le paramètrage par défaut. Ça permet de travailler dans de très bonne condition avec VSCode.

Il suffit de l’activer avec generate-vscode-project-config true

Options utiles pour la commande kdesrc-build

-D : Pour ne pas inclure les dépendances dans la compilation

Exemple: kdesrc-build -D kate

-S : Pour ne pas mettre à jour les sources

Exemple: kdesrc-build -S kate

Ma contribution

J’ai contribué sur le support de la lampe torche pour l’environnement Plasma Mobile. La lampe torche fonctionnait uniquement sur les pinephones en utilisant le fichier en dure /sys/devices/platform/led-controller/leds/white:flash/brightness (Source). J’ai réécris le module pour que ça fonctionne de manière générale sur tous les téléphones.

Rappel sur le fonctionnement du noyau Linux autour des leds

Pour comprendre comment la fonctionnalité, un petit rappel s’impose autour du fonctionnement des leds avec le noyau Linux. Dès qu’une led est détecté par le noyau, il va mettre à disposition plusieurs fichiers. On les trouvent dans le dossier correspondant au driver et aussi à l’emplacement physique sur la carte mère ou sur le SOC. Mais on peut aussi les trouver plus facilement dans le répertoire /sys/class/leds/.

sys => Fichiers système class => Trier par class. leds => La class leds. On peut trouver aussi par appareil bluetooth, puce tpm, …

On disposent de plusieurs fichiers importants :

brightness : Permet de changer ou de récupérer l’intensité de la led actuelle.
max_brightness : Permet de connaitre l’intensité max de la led.
color : Ce fichier n’existe pas tout le temps mais permet d’avoir la couleur de la led.
Le reste des fichiers ne sont pas important pour nous.

Explication du fonctionnement de mon code petit à petit

Tout d’abord, il faut savoir que j’utilise la libraire Udev. Il est prévu que je migre vers la librairie Solid une fois le support des leds ajoutées. Udev pour faire simple, c’est une librairie qui permet d’interagir avec les appareils assez directement sans intermédiaire. La librairie permet également de lister, filtrer, détecter si un appareil est connecté/déconnecté, ….

Pour commencer, je dois d’abord instancier Udev avec pour l’utiliser par la suite.

1

struct udev *udev = udev_new();

Ensuite, je liste tous les périphériques qui m’intéressent donc ceux appartenant à la class leds. Pour ça, il me suffit de créer un énumerateur sur lequel on appliquera tous les filtres.

On peut voir une class comme une catégorie d’appareils.

1

struct udev_enumerate *enumerate = udev_enumerate_new(udev);

J’applique le filtre pour lister uniquement ceux qui appartiennent à la class leds.

1
2
3


#define TORCH_SUBSYSTEM "leds"
...
udev_enumerate_add_match_subsystem(enumerate, TORCH_SUBSYSTEM);

J’applique le filtre pour lister uniquement ceux qui ont dans le nom flash ou torch.

1
2


udev_enumerate_add_match_sysname(enumerate, "*:torch");
udev_enumerate_add_match_sysname(enumerate, "*:flash");

Puis je lance le scan avec mes filtres.

1

udev_enumerate_scan_devices(enumerate);

Au début, il faut savoir que je prenais le premier appareil avec le code ci-dessous mais certain téléphone ont une torche de couleur jaune et blanche. Certain utilisateur malheureusement ne pouvait pas utiliser la fonctionnalité.

1
2


struct udev_list_entry *devices = udev_enumerate_get_list_entry(enumerate);
struct udev_list_entry *entry = udev_list_entry_get_next(devices);

Source

Donc, j’ai changé le code avec le code ci-dessous qui permet d’itérer sur tous les appareils.

1
2
3
4
5
6
7
8
9


struct udev_list_entry *devices = udev_enumerate_get_list_entry(enumerate);
struct udev_list_entry *entry = nullptr;

struct udev_device *device = nullptr;

udev_list_entry_foreach(entry, devices)
{
 [...]
}

Pour chaque appareil, j’ai récuperé le répertoire ou se situe l’appareil avec le code ci-dessous qui me renvoie par exemple: /sys/devices/platform/led-controller/leds/white:flash.

1

const char *path = udev_list_entry_get_name(entry);

J’instancie une instance udev_device pour interagir avec lui depuis le répertoire.

1

struct udev_device *device = udev_device_new_from_syspath(udev, path);

Et à partir de là, il me suffit de lire les fichiers dont j’ai besoin.

1

const char *maxBrightness = udev_device_get_sysattr_value(device, "[NOM DU FICHIER]");

Je lis d’abord le fichier ‘color’ et je regarde si la couleur est blanche sinon je continue. Si je ne trouve pas de led de couleur blanche, je prends la dernière valeur récupérée.

Une fois pour chaque appareil trouvé, il me reste plus qu’à récupérer les infos dont j’ai besoin. Donc, la luminosité maximale max_brightness et la luminosité actuelle brightness pour correctement initialiser l’interface de Plasma Mobile.

Quand je souhaite changer la valeur, je dois d’abord convertir la valeur entière en chaîne de charactère.

1

const_cast<char *>(m_torchEnabled ? "0" : m_maxBrightness)

Ensuite, je change la luminosité

1

udev_device_set_sysattr_value(m_device, "brightness", nouvelle_valeur_en_char_*);

Si vous le souhaitez, vous pouvez retrouver le fichier dans son intégralité ici

Info utile pour débugger KDE Plama Mobile depuis Postmarket OS

Le fichier de log se situe dans ~/.local/state/tinydm.log

À propos de moi

Mon, 01 Jan 0001 00:00:00 +0000

Introduction

Passionné d’informatique depuis mon plus jeune âge, mon parcours est marqué par une curiosité insatiable et un désir constant d’apprendre. Dès l’enfance, j’ai plongé dans le monde de l’électronique, allant jusqu’à assembler mon premier ordinateur à partir de pièces récupérées. Cette expérience précoce a nourri ma fascination pour la technologie.

À 12 ans, j’ai fait mes premiers pas en programmation avec les scripts Batch, avant de me plonger rapidement dans le langage Java. Cette maîtrise m’a permis de créer des jeux vidéo en 3D utilisant OpenGL avec LWJGL 2/3, et même de participer à des compétitions de programmation de jeux vidéo en Java.

Mon parcours académique m’a conduit d’un BAC STI2D à un DUT Informatique à l’IUT de Limoges, où j’ai découvert Linux, devenu depuis mon système d’exploitation principal. J’ai ensuite poursuivi avec une Licence Professionnelle en développement web et du Big Data. Ces formations ont considérablement élargi mes horizons et renforcé mes compétences techniques.

Au fil des années, mon expertise s’est considérablement étendue. Du développement web avec React, Ruby on Rails, Symfony, Tailwindcss et Bootstrap, à la création d’applications mobiles avec Flutter, en passant par le développement système en Rust, j’ai acquis un large éventail de compétences. Ma passion pour les nouvelles technologies reste intacte, comme en témoigne mon intérêt récent pour l’intelligence artificielle.

Ce qui me caractérise, c’est ma soif d’apprentissage constante et ma capacité à m’adapter rapidement aux nouvelles technologies. Chaque projet est pour moi une opportunité d’approfondir mes connaissances et de relever de nouveaux défis, toujours guidé par ma curiosité et mon enthousiasme pour l’innovation technologique.

Expérience professionnelle

Axyus (CDI)

Développeur Web, Mobile et Système | Octobre 2024 - Aujourd’hui

Unova (CDI) - 5 ans et 1 mois

Développeur Web, Mobile et Système | Septembre 2019 - Octobre 2024

3D (WebGL / Godot Engine)
Front (React, Flutter, Tailwindcss, Bootstrap, SolidJS)
Back (Symfony, Ruby on Rails)
Devops (Rust, Docker, Gitlab-CI)

Limouzik (Divers) - 2 ans et 3 mois

Développeur Web, Application 2D et Devops | Avril 2017 - Juillet 2019

CDI (11 mois) | Septembre 2018 - Juillet 2019
- Site web (Symfony, Bootstrap, ReactJS)
- Application v2 (Unity 3D)
- Serveur (Docker, Gitlab-CI, Nginx)
Alternance (1 an) | Septembre 2017 - Août 2018
- Site web (Symfony, Bootstrap, ReactJS)
- Application v1 (ReactJS, Webpack)
- Serveur (Docker, Gitlab-CI, Nginx)
CDD (1 mois) | Juillet 2017
- Site web (Symfony, Bootstrap, ReactJS)
- Application v1 (ReactJS, Webpack)
Stage (3 mois) | Avril 2017 - Juin 2017
- Site web (Symfony, Bootstrap, ReactJS)
- Application v1 (ReactJS, Webpack)

Compétences

Langages de programmation

Java
JavaScript / Typescript
Ruby
C#
Rust

Technologies et frameworks

Docker
Nginx / Traefik
CI/CD (Gitlab CI, Github Actions)
OpenGL
Linux | Utilisation quotidienne + développement

Soft skills

Travail en équipe
Résolution de problème
Conception
Autonomie

Formation

Licence Professionnelle en développement web et du Big Data

IUT du Limousin | 2017 - 2018

DUT Informatique

IUT du Limousin | 2015 - 2017

Bac STI2D SIN

Lycée Jean Favard (Guéret) | 2012 - 2015

STI2D : Sciences et Technologies de l’Industrie et du Développement Durable
SIN : Systèmes d’Information et du Numérique

Concours

Global Game Jam édition 2019

Lieu : 3iL - Limoges
Date : 25 janvier 2019 - 27 janvier 2019
Thème : What home means to you
Objectif : Développer un jeu en 48h à partir du thème donné
Participants : Ezyrath, Fabien87, Flavien, MrDev023 (Moi), php4ever, spoutnik87
Technologie employée : Unity 3D
Projet : Cauchemar en forêt

Global Game Jam édition 2017

Lieu : 3iL - Limoges
Date : 20 janvier 2017 - 22 janvier 2017
Thème : Waves
Objectif : Développer un jeu en 48h à partir d’un thème donné
Participants : emiko, Fiesta87, MrDev023 (Moi), TheKitolex
Technologies employées : Java 1.8 et le moteur graphique que j’ai conçu pour l’occasion avec LWJGL 3
Projet : Beach Fighter

Global Game Jam édition 2016

Lieu : 3iL - Limoges
Date : 29 janvier 2016 - 31 janvier 2016
Thème : Ritual
Objectif : Développer un jeu en 48h à partir d’un thème donné
Participants : Aliths, dikaios, Fiesta87, MrDev023 (Moi), TheKitolex
Projet : Bifrost Saver’s
Outils utilisés: Java 1.8 et ACM Graphics

Nuit de l’info édition 2016

Lieu : Bordeaux
Date : 1er décembre 2016 - 2 décembre 2016
Thème : Venir en aide aux réfugiés
Objectif : Développer un projet WebGL en 8h
Équipe : echo “Avis de template”
Slogan : Qui sème le vent récolte le Template
Projet : Lien vers le projet GitHub
Résultats :
- 1er prix WebGL
- 1er prix Méthode agile

Search

Mon, 01 Jan 0001 00:00:00 +0000

Florian RICHER

My first participation in a KDE PIM Sprint

My First Participation in a KDE Sprint

Starting the Sprint

Understanding Merkuro

Contributions

Conclusion

Useful links

Configurer kde-builder sur des bases immuables et lancer un projet KDE

Introduction

Préparer son environnement

Introduction

Installation de distrobox sur Nix OS

Création du container pour travailler

NixOS Distrobox

Fedora Toolbox

Test de notre environnement

Note pour le démarrage de KDE Plasma Mobile

Découverte de Nix et de Flake

Introduction

Le langage Nix

Structure d’un Flake

Partie inputs

Partie outputs

Exemple de flake

Mettre à jour le flake.lock

Débugger sa configuration avec la console nix

Fonctionnement des environnements de développement

Utiliser un devShell

Configurer son propre devShell

Liens utiles

Compiler un paquet Postmarket OS

À propos de Postmarket OS

Configuration de notre environnement de travail

Compilation de notre paquet Alpine

Envoie du paquet compilé sur le téléphone

Ma première contribution à KDE

Rapide rappel à propos de KDE

Ma configuration

Mes premières difficultés

Configurations utiles

Désactiver l’arrêt de la compilation lors d’une erreur de compilation.

Activer le support des LSP

Générer les projets VSCode

Options utiles pour la commande kdesrc-build

Ma contribution

Rappel sur le fonctionnement du noyau Linux autour des leds

Explication du fonctionnement de mon code petit à petit

Info utile pour débugger KDE Plama Mobile depuis Postmarket OS

Archives

À propos de moi

Introduction

Expérience professionnelle

Axyus (CDI)

Unova (CDI) - 5 ans et 1 mois

Limouzik (Divers) - 2 ans et 3 mois

Compétences

Langages de programmation

Technologies et frameworks

Soft skills

Formation

Licence Professionnelle en développement web et du Big Data

DUT Informatique

Bac STI2D SIN

Concours

Global Game Jam édition 2019

Global Game Jam édition 2017

Global Game Jam édition 2016

Nuit de l’info édition 2016

Search

Partie `inputs`

Partie `outputs`

Mettre à jour le `flake.lock`