Fedora

Journaux liées à cette note :

Je pense que la méthode make_srpm est plus simple que Packit pour construire des packages non officiel Fedora sur COPR #fedora, #package, #distribution-linux, #open-source, #linux, #github, #2

Cette note est la suite de la note "J'ai créé fedora-rpm-copr-playground pour apprendre à publier des packages RPM sur Fedora COPR" :

Pour être tout à fait transparent, en rédigeant cette note, j'ai découvert les méthodes tito et Packit.

Je compte mettre à jour stephane-klein/fedora-rpm-copr-playground pour les tester et ensuite publier une nouvelle note de compte rendu.

2026-03-23_1423

Voici ce que Claude Sonnet 4.6 m'a appris au sujet des méthodes Tito et Packit :

Tito (~2008) est issu de l'équipe Red Hat Network / Spacewalk. C'est un outil local de gestion du cycle de vie RPM : il gère le tagging Git (tito tag), incrémente la version dans le .spec, génère automatiquement les changelogs depuis l'historique Git et produit des SRPMs. Ce sont des opérations que le développeur invoque manuellement sur sa workstation, avant de committer et pousser son travail.

Packit (~2019) est un projet Red Hat conçu pour l'ère CI/CD GitHub/GitLab. Son rôle est d'orchestrer automatiquement les builds RPM (via COPR), et optionnellement les soumissions Koji et les updates Bodhi pour les projets intégrés à la distribution officielle Fedora, en réaction à des événements upstream (push, PR, release, ou création d'un tag). Il peut également mettre à jour le changelog à partir des commits, mais cette opération intervient au moment où il prépare la mise à jour vers le dist-git Fedora — non pas comme étape explicite du workflow local du développeur.

La différence fondamentale entre les deux n'est donc pas tant dans quand le build est déclenché — les deux peuvent travailler sur tag — que dans comment le workflow de tagging est géré : avec Tito, c'est le développeur qui crée le tag depuis sa workstation, alors que Packit suppose que le tag existe déjà et déclenche automatiquement le build sur l'infrastructure Fedora (Copr, Koji ou Bodhi selon la configuration) à sa création ou à tout autre événement upstream configuré.

Les deux sont des projets Red Hat gravitant autour de l'écosystème Fedora/RPM, sans que l'un soit le successeur de l'autre. Tito lui-même recommande aujourd'hui Packit pour automatiser les Bodhi updates. Beaucoup de projets Fedora les utilisent d'ailleurs conjointement : Tito pour gérer le versioning et le tagging en local, Packit pour automatiser la distribution en aval.

Sonnet 4.6

J'ai intégré Packit à fedora-rpm-copr-playground, dans la branche bash-packit.

Avant de pouvoir utiliser Packit pour build un package RPM d'un projet qui se trouve dans un repository GitHub, il est nécessaire de suivre un certain nombre d'étapes détaillées dans le "Packit Upstream Onboarding Guide" :

  1. Activer l'application GitHub nommée "Packit-as-a-Service" : https://packit.dev/docs/guide/#github
  2. Ensuite suivre l'étape "Approval" — j'ai perdu du temps dans le playground parce que j'étais totalement passé à côté de cette étape : https://packit.dev/docs/guide/#2-approval
    Voici l'issue GitHub qui a permis l'approbation de mon compte : https://github.com/packit/notifications/issues/716
  3. Créer un projet COPR et ajouter des permissions "admin" à "packit" (voir ligne 18). J'ai automatisé cette étape avec le script /init-copr-project.sh.

Ensuite, j'ai intégré le fichier /.packit.yaml à la racine de mon playground, avec le contenu suivant :

specfile_path: rpm/hello-bash.spec

upstream_package_name: hello-bash
downstream_package_name: hello-bash
upstream_tag_template: "v{version}"

actions:
  create-archive:
    - bash rpm/create-archive.sh

jobs:
  - job: copr_build
    trigger: release
    owner: stephaneklein
    project: hello-bash-packit
    targets:
      - fedora-42
      - fedora-43
      - fedora-44
    preserve_project: true

Je ne vais pas détailler ici le contenu de ce fichier, je vous renvoie vers la documentation officielle :

La configuration trigger: release dans .packit.yaml signifie qu'il faut créer une release GitHub pour obtenir un package. Pour cela j'utilise de script /release.sh qui exécute :

gh release create "$VERSION" --title "Release $VERSION" --generate-notes

Une fois la commande suivante exécutée :

$ ./release.sh v1.0.15

L'exécution du job de génération du package SRPM est visible sur le backend Packit à cette adresse : https://dashboard.packit.dev/jobs/srpm

Une fois ce job terminé, c'est ensuite le backend COPR qui s'occupe de construire les packages RPM pour toutes les distributions indiquées dans le fichier .packit.yaml :

En conclusion, j'ai réussi à configurer Packit pour construire mes packages RPM. Cependant, la configuration est plus complexe que la méthode make_srpm. Selon moi, Packit est à utiliser pour les packages destinés à être intégrés officiellement à Fedora, tandis que make_srpm convient mieux pour les autres.

J'ai installé Claude Desktop sous Fedora #linux, #fedora, #llm, #JaiDécouvert

Anthropic ne propose pas de version GNU Linux de Claude Desktop.

#JaiDécouvert le projet Claude Desktop for Linux qui a repackagé la version de Claude Desktop Windows pour GNU Linux. Ce projet propose des packages pour Debian, Fedora, ArchLinux et NixOS.

Je l'ai installé avec succès sous Fedora avec les commandes suivantes trouvé ici :

$ sudo curl -fsSL https://aaddrick.github.io/claude-desktop-debian/rpm/claude-desktop.repo -o /etc/yum.repos.d/claude-desktop.repo
$ sudo dnf install claude-desktop

J'ai ensuite testé la connexion de Claude Desktop au Filesystem MCP Server lancé en local :

Seul élément négatif pour l'instant : la version Desktop ne permet pas d'utiliser l'extension Claude Counter (extension), contrairement à la version web.

J'ai découvert croc qui permet de partager facilement du texte ou des fichiers entre deux machines distantes #cli, #tooling

Via Claude Sonnet 4.5, j'ai découvert l'existance des projets croc et Magic Wormhole.

Ces deux projets permettent de partager des fichiers entre deux machines.

Voici un tableau comparatif :

Caractéristique Magic Wormhole croc
Langage Python Go (plus rapide)
Reprise transfert ❌ ✅
Multi-fichiers ❌ (un par un) ✅
Vitesse Bon Meilleur
Maturité Plus ancien, stable Plus récent, actif
Stdin/stdout ✅ Excellent ✅ Bon

Claude Sonnet 4.5

J'ai décidé de tester croc.

Sur ma workstation Fedora, j'ai lancé :

$ sudo dnf install -y croc
$ croc --version
croc version v9.6.4-1fce28e
$ croc send --text "Foobar"
Sending 'text' (6 B)
Code is: 8834-lady-protect-senator
On the other computer run

croc 8834-lady-protect-senator

Sur une seconde machine :

$ croc --yes 8834-lady-protect-senator
Receiving text message (6 B)

Receiving (<-192.168.1.108:9009)
Foobar

Ça fonctionne bien, je garde cet outil dans ma boîte à outils 🙂.

Script d'analyse des coûts Aider à partir de l'historique #astuce, #CodeAssistant

J'ai cherché une fonctionnalité pour calculer le coût total de l'utilisation d'Aider sur un projet. Je n'ai rien trouvé dans la documentation ni dans les issues du projet Aider.

Je sais qu'Aider enregistre toutes les informations de session dans .aider.chat.history.md.

Ce fichier contient des lignes du type : "Tokens: 49k sent, 1.9k received. Cost: $0.17 message, $1.68 session".

À partir de ces informations, j'ai généré avec Claude Sonnet 4.5 le script Python aider_cost_analyzer.py.

Installation sous Fedora :

$ mkdir -p ~/.local/bin
$ curl -o ~/.local/bin/aider_cost_analyzer.py https://gist.githubusercontent.com/stephane-klein/3b3808c1b03b7e6ddfc4b22b69fdf776/raw/4262faec0cb2f468ea6b6d8751339b8e8497f005/aider_cost_analyzer.py
$ chmod +x ~/.local/bin/aider_cost_analyzer.py

Exemple d'utilisation :

$ aider_cost_analyzer.py .
Analyzing 1 history file(s) in '.':

.aider.chat.history.md:
  Messages: 30
  Tokens sent: 639,200 | received: 65,613
  Cost: $1.86

============================================================
Total tokens sent: 639,200
Total tokens received: 65,613
Total cost: $1.86

J'ai posté l'issue suivante dans le repository aider-ce : "Calculate cumulative token usage and cost across all Aider sessions".

net-tools est déprécié, je dois remplacer "lsof -i" par "ss -tlnp" #linux, #kernel, #network

J'utilise habituellement lsof -i | grep "8080" pour identifier le processus qui écoute sur le port 8080.

Comme je le mentionnais dans 2025-07-04_1614, j'ai appris net-tools au début des années 2000 et j'ai gardé cette habitude depuis.

D'après Claude Sonnet 4.5, iproute2 est devenu le standard dans Debian, Ubuntu et Fedora vers 2013-2015. net-tools a été supprimé de l'installation par défaut entre 2017 et 2018.

lsof (pour LiSt Open Files) interroge /proc pour récupérer les informations. Cette implémentation, comme tous les outils net-tools, est ancienne et n'utilise pas l'API moderne Netlink.

En 2025, la méthode recommandée pour identifier les processus écoutant des ports est cette commande iproute2 (code source) :

$ ss -tlnp | grep 8080

Explication des options :

  • -t: TCP sockets
  • -l: Listening sockets uniquement
  • -n: Affichage numérique (pas de résolution DNS)
  • -p: Affiche les processus

J'ai écrit cette note et bridge-utils est déprécié, je dois remplacer "brctl" par "ip link" pour m'aider à adopter les commandes modernes iproute2.

Pour apprendre cette nouvelle commande, j'ai ajouté la carte-mémoire suivante dans Anki :

Script qui permet de transformer automatiquement du texte en anglais en fichier audio #anglais, #astuce

J'ai généré avec Claude Sonnet 4.5 le script Python text_to_audio.py. Il me permet de transformer automatiquement du texte en anglais en fichier audio mp3.
J'intègre ensuite ces fichiers dans mes carte-mémoire Anki pour travailler mon anglais.

Installation sous Fedora :

$ mkdir -p ~/.local/bin
$ curl -o ~/.local/bin/text_to_audio.py https://gist.githubusercontent.com/stephane-klein/1406e746f0253956062d4adff7a692bd/raw/8571cdd91cae8ebcd208435daacf431cfc1cd353/text_to_audio.py
$ chmod +x ~/.local/bin/text_to_audio.py

Exemple d'utilisation :

$ text_to_audio.py "Reinforcement Learning from Human Feedback"
Downloading audio for: 'Reinforcement Learning from Human Feedback'
Language: en-GB
URL: https://translate.google.com/translate_tts?ie=UTF-8&tl=en-GB&client=tw-ob&q=Reinforcement+Learning+from+Human+Feedback
Saving to: /home/stephane/english_audio/2025-12-01_Reinforcement_Learning_from_Human_Feedback.mp3

✓ Successfully downloaded to '/home/stephane/english_audio/2025-12-01_Reinforcement_Learning_from_Human_Feedback.mp3'
File size: 28224 bytes

J'utilise actuellement un endpoint HTTP de Google Translator pour générer les fichiers audio, en attendant de trouver une alternative plus open source / communautaire.

Journal du dimanche 16 novembre 2025 à 22:17 #projet-34, #vpn, #admin-sys

Suite à publication des notes "Setup Fedora CoreOS avec LUKS et TPM, non sécurisé contre le vol physique de serveur", "Setup Fedora CoreOS avec LUKS et Tang", j'ai réfléchi à mes prochaines itérations du Projet 34 - "Déployer un cluster k3s et Kubevirt sous CoreOS dans mon Homelab".

Je souhaite réaliser et publier un playground pour étudier et tester les solutions VPN suivantes :

Dans un premier temps, je souhaite pouvoir accéder en ssh aux serveurs de mon Homelab depuis n'importe où. L'objectif est d'utiliser une méthode unique pour me connecter à ces serveurs en utilisant simplement leur hostname, sans avoir à gérer leurs adresses IP locales ni à configurer manuellement des entrées DNS.

Je souhaite tester l'installation de ces solutions sur des serveurs sous CoreOS, ma workstation sous Fedora et sous Android.

Idéalement, je souhaite configurer les services netbird et Tailscale via Terraform.

Je ne pense pas tester tout le suite headscale.

Journal du jeudi 16 octobre 2025 à 00:32 #linux, #fedora, #JaiDécouvert

#JaiDécouvert les conférences Fedora annuelles nommées : Flock (https://fedoraproject.org/flock/)

Ajout de packages dans des distributions atomiques #CoreOS, #linux, #DevOps

Cette note fait partie de la série de notes : "J'ai étudié et testé CoreOS et je suis tombé dans un rabbit hole 🙈".

Note précédente : "Peu à peu depuis 2015, le terme immutable est remplacé par atomic".

Je constate que la plupart des personnes avec qui j'échange pensent qu'une distribution immutable ne permet que d'exécuter des containers Docker ou des applications Flatpak.
En réalité, grâce à la technologie libostree, il est possible d'installer des packages Fedora sur une instance Fedora CoreOS.

Voici un exemple sous Fedora CoreOS que j'ai réalisé avec le playground suivant : https://github.com/stephane-klein/atomic-os-playground.

Je commence par regarder l'état de l'OS avec rpm-ostree status :

stephane@stephane-coreos:~$ rpm-ostree status
State: idle
AutomaticUpdatesDriver: Zincati
  DriverState: active; periodically polling for updates (last checked Sat 2025-09-27 12:43:23 UTC)
Deployments:
● ostree-remote-image:fedora:docker://quay.io/fedora/fedora-coreos:stable
                   Digest: sha256:d196ab492e7cadab00e26511cdc6b49c6602b399e1b6f8c5fd174329e1ae10c1
                  Version: 42.20250901.3.0 (2025-09-14T22:45:05Z)

Je constate que la version 42.20250901.3.0 identifiée par le commit sha256:d196ab...ae10c1 est installée.
Cette version correspond au moment où j'écris cette note à la dernière release du stream stale listé sur cette page https://fedoraproject.org/coreos/release-notes?arch=x86_64&stream=stable.

Maintenant, j'utilise rpm-ostree install … pour installer neovim.

stephane@stephane-coreos:~$ sudo rpm-ostree install neovim
Checking out tree 1e5b81c... done
Enabled rpm-md repositories: fedora-cisco-openh264 updates fedora updates-archive
Updating metadata for 'fedora-cisco-openh264'... done
Updating metadata for 'updates'... done
Updating metadata for 'fedora'... done
Updating metadata for 'updates-archive'... done
Importing rpm-md... done
rpm-md repo 'fedora-cisco-openh264'; generated: 2025-03-19T16:53:39Z solvables: 6
rpm-md repo 'updates'; generated: 2025-09-27T01:07:36Z solvables: 24410
rpm-md repo 'fedora'; generated: 2025-04-09T11:06:59Z solvables: 76879
rpm-md repo 'updates-archive'; generated: 2025-09-27T01:38:59Z solvables: 44216
Resolving dependencies... done
Will download: 40 packages (121.6 MB)
Downloading from 'updates'... done
Downloading from 'fedora'... done
Importing packages... done
Checking out packages... done
Running systemd-sysusers... done
Running pre scripts... done
Running post scripts... done
Running posttrans scripts... done
Writing rpmdb... done
Writing OSTree commit... done
Staging deployment... done
Added:
  binutils-2.44-6.fc42.x86_64
  compat-lua-libs-5.1.5-28.fc42.x86_64
  ...
  neovim-0.11.4-1.fc42.x86_64
  ...
Changes queued for next boot. Run "systemctl reboot" to start a reboot

Neovim a bien été installé, mais je dois reboot pour l'utiliser. Voici ce que me dit rpm-ostree status :

stephane@stephane-coreos:~$ rpm-ostree status
State: idle
AutomaticUpdatesDriver: Zincati
  DriverState: active; periodically polling for updates (last checked Sat 2025-09-27 12:48:33 UTC)
Deployments:
  ostree-remote-image:fedora:docker://quay.io/fedora/fedora-coreos:stable
                   Digest: sha256:d196ab492e7cadab00e26511cdc6b49c6602b399e1b6f8c5fd174329e1ae10c1
                  Version: 42.20250901.3.0 (2025-09-14T22:45:05Z)
                     Diff: 40 added
          LayeredPackages: neovim

● ostree-remote-image:fedora:docker://quay.io/fedora/fedora-coreos:stable
                   Digest: sha256:d196ab492e7cadab00e26511cdc6b49c6602b399e1b6f8c5fd174329e1ae10c1
                  Version: 42.20250901.3.0 (2025-09-14T22:45:05Z)

La pastille ● m'indique la version (nommée déploiement) actuellement utilisée par l'instance.

Lors du démarrage du serveur, grub est configuré pour booter sur le premier déploiement de la liste. Exemple :

Une fois le serveur démarré, je peux voir que la version 42.20250901.3.0 est toujours utilisée, mais avec en plus un layer qui contient le package neovim :

[stephane@stephane-coreos ~]$ rpm-ostree status
rpm-ostree status
State: idle
AutomaticUpdatesDriver: Zincati
  DriverState: active; periodically polling for updates (last checked Sat 2025-09-27 13:04:36 UTC)
Deployments:
● ostree-remote-image:fedora:docker://quay.io/fedora/fedora-coreos:stable
                   Digest: sha256:d196ab492e7cadab00e26511cdc6b49c6602b399e1b6f8c5fd174329e1ae10c1
                  Version: 42.20250901.3.0 (2025-09-14T22:45:05Z)
          LayeredPackages: neovim

  ostree-remote-image:fedora:docker://quay.io/fedora/fedora-coreos:stable
                   Digest: sha256:d196ab492e7cadab00e26511cdc6b49c6602b399e1b6f8c5fd174329e1ae10c1
                  Version: 42.20250901.3.0 (2025-09-14T22:45:05Z)

Neovim est bien accessible :

[stephane@stephane-coreos ~]$ nvim --version
nvim --version
NVIM v0.11.4
Build type: RelWithDebInfo
LuaJIT 2.1.1748459687
Run "nvim -V1 -v" for more info

Avec la commande rpm-ostree apply-live il est même possible de commencer à utiliser le package sans avoir à reboot.
Cette fonctionnalité doit se limité à des petits utilitaires. Pour les composants systèmes, il est conseillé d'effectuer un reboot.

Note suivante : "Système de mise à jour d'Android, Chrome OS, MacOS et MS Windows".

L'origine du nom "Fedora Silverblue" #fedora, #distribution-linux, #histoire

La lecture du document "Team Silverblue - The Origins " m'a appris de nombreuses choses sur les origines de la distribution Fedora Silverblue.

Avant 2018, le prédécesseur de Fedora Silverblue s'appelait "Fedora Atomic Workstation", défini comme : "image-mode container-based Fedora Workstation based on rpm-ostree".

À ses débuts, Fedora Atomic Workstation était un side project, développé et utilisé par quelques membres seulement de l'équipe Project Atomic (version du site de 2017).

Durant la conférence DevConf.CZ de janvier 2018, des participants ont présenté leur projet "Atomic Desktop". Suite à cette présentation, Owen Taylor, Sanja Bonic et Matthias Clasen ont créé un Special interest group (SIG) dédié à ce sujet dans la communauté Fedora : https://fedoraproject.org/wiki/SIGs/AtomicDesktops.

Voici comment le nom "Team Silverblue" a été choisi 2018 par Matthias Clasen et Sanja Bonic :

Couldn’t you come up with a better name?

No.

And in more detail: Matthias and Sanja have vetted over 150 words and word combination for something suitable, starting with tree names and going to atoms, physics, nature, landscapes.

Several other people have been asked to contribute. The entire process lasted for roughly 2 months, culminating in an open discussion of naming in the SIG meeting on April 16.

On April 19, Matthias and Sanja decided for the name Team Silverblue, because it was :

  • available on Twitter, GitHub, and as a .org domain
  • makes sense and sounds nice within the Fedora realm (color alignment)
  • opens up fun and entertaining ways to have swag (silver-blue wigs, sports jerseys with the logo on it, phrasing like “Go, Team Silverblue!”, “Want to join the Team and improve Silverblue?”)
  • works as Fedora Silverblue or Team Silverblue without losing branding investment

source

"Team Silverblue" a ensuite donné le nom Fedora Silverblue.

Le document indique que Red Hat a acquis CoreOS juste quelques jours après le lancement de cette idée de projet par les développeurs. S'agit-il d'une coïncidence heureuse 🤔 ? Le document ne le précise pas.