-->[]

12 septembre. Barcelone. Chaleur, plage, soleil, short, 2 douches par jour.

18 septembre, Marbourg. Froid, bonnet, écharpe, 4 épaisseurs, nez qui coule, feuilles mortes.

Ça calme.

Il y a quelques semaines, Colin Didier, alias errtu, a annoncé qu'il s'était mis à plancher sur un plugin irssi pour Jabber, nommé irssi-xmpp. Comme je l'ai déjà mentionné il y a quelques mois, il existe aussi irssi-jabber qui fait la même chose, mais le développeur est content avec l'état actuel du plugin et n'est pas spécialement motivé pour avancer le développement, alors errtu a décidé de repartir à zéro.

Pour les gens qui connaissent pas irssi, c'est un programme de "tchat" en ligne de commande qui utilise de base le protocole IRC, mais qui peut utiliser d'autres protocoles par le biais d'extensions ou plugins.

Pour les gens qui connaissent pas Jabber, c'est un protocole de messagerie décentralisé, un peu comme les mails: depuis une adresse toto@hebergeur-truc.com on peut discuter avec tata@herbergeur-machin.net, donc personne ne peut avoir le monopole du réseau, et il ne peut pas y avoir de "panne générale". En ce qui concerne l'apparence du bouzin, il y a plusieurs logiciels Jabber, mais dans le cas le plus fréquent ça ressemble grosso-modo à ICQ, MSN Messenger, Yahoo Messenger et consorts: une liste d'ami·e·s, on voit s'illes sont là ou pas, et on peut chatter avec elleux, à deux ou en groupe.

Le problème avec Jabber c'est qu'il n'y avait pas de bon client en mode texte. Bon, et le problème avec irssi (qui est en mode texte, donc) c'est qu'il ne faisait pas de Jabber. Grâce à l'effort amorcé par errtu, paf, c'est bon. Du coup, je me suis dit que c'était la bonne occasion pour en faire un paquet Debian: ça fait longtemps que je voulais apprendre à faire ça, et par ailleurs ça permet de donner davantage de visibilité à irssi-xmpp. J'en ai donc fait un, avec l'aide de Lunar et de la documentation de Debian. Au début je l'ai mis sur un dépôt personnel, puis Lunar m'a proposé de l'envoyer dans l'archive Debian officielle, ce qui m'a permis de me familiariser avec le processus :

• Signaler un ITP (Intent To Package), c'est-à-dire prévenir que je comptais faire un paquet nommé irssi-plugin-xmpp (pour coller à la convention de nommage Debian).
• Premier moment d'émotion: dernières relectures et envoi (upload) du paquet source et du paquet compilé par la personne qui effectue l'envoi (Lunar, dans mon cas, donc compilé pour amd64, qui est l'architecture de sa machine) sur les serveurs Debian. Les paquets envoyés arrivent dans la NEW queue (file d'attente des nouveaux paquets). Ils doivent être validés par les responsables FTP, ce qui constitue un premier niveau de vérifications (compatibilité de la licence avec les critères de liberté de Debian, etc.). Le paquet est resté 6 jours dans la file, ben je peux vous dire que c'est long :)
• Deuxième moment d'émotion: le paquet a enfin été accepté hier. La suite est donc :
  • L'ITP a été automatiquement fermé.
  • Le paquet source et le paquet compilé pour amd64 se sont retrouvés publiquement accessibles dans la file d'entrée des paquets.
  • Des programmes automatiques de compilation (build daemons) se sont mis à construire le paquet pour les architectures manquantes: i386, mips, sparc, powerpc, etc..
• Quelques heures après, le paquet source et les paquets compilés pour chaque architecture ont été rendus disponibles sur le FTP principal de Debian pour la distribution "unstable", puis synchronisés sur les différents miroirs à travers le monde.

Le résultat concret, c'est qu'une personne utilisant Debian unstable peut maintenant installer le paquet irssi-plugin-xmpp via sa méthode d'installation préférée (apt-get, aptitude, synaptic, etc.).

Mon premier paquet Debian... c'est peut-être bête mais ça fait plaisir. Bon par contre c'est que le début, maintenant faut le maintenir, c'est-à-dire suivre les nouvelles versions et les packager aussi, tenir compte des signalements de bugs, etc.. Quant à irssi-xmpp, l'existence d'un paquet permettra à un peu plus de gens de l'utiliser facilement, et j'espère que ça permettra au programme de s'améliorer encore grâce aux suggestions, signalements de bugs, bouts de code, etc..

Il y a environ 3 ans, j'ai fait un "petit" programme nommé battground. Au début, c'était un petit script shell qui changeait la couleur du fond d'écran suivant l'état de charge de la batterie de mon laptop, le genre de petit script à la con bricolé en 1h dans un moment d'ennui.

Petit à petit j'ai commencé à lui rajouter des petites fonctionnalités, comme par exemple pouvoir configurer la variation des couleurs au fil de la charge, décharge, etc.. J'ai fini par me prendre complètement au jeu et à passer des journées entières dessus, d'ailleurs Marie s'en souvient sûrement encore très bien :) Au final, ce petit script est devenu un truc assez complet, complexe, et compliqué :

• Chaque état de charge a une couleur de base, comme ça on peut savoir d'après la couleur si la batterie est en train de se vider, remplir, si elle a fini de se charger, etc..
• Le pourcentage de batterie (donc entre 0 et 100) est transformé en un autre nombre, comme on veut, par des petites fonctions mathématiques simples, appelées filtres. Par exemple, "reverse" transforme 0 en 100, 100 en 0, 60 en 40, etc.. Autre exemple, "step" arrondit à la dizaine (ou à ce qu'on veut) et produit donc un effet d'échelon. Encore autre exemple, "threshold" transforme tout ce qui passe en-dessous (ou au-dessus) d'une certaine seuil en une valeur fixe, par exemple 0. Il est possible de combiner (composer, pour les matheuses/matheux) plusieurs fonctions ensemble, les unes à la suite des autres. Le nombre final sert à faire varier la teinte de la couleur de base, et idem pour la saturation. Comme chaque filtre est un fichier indépendant très simple, on peut aussi créer soi-même ses propres filtres si on se sent d'humeur matheuse.
• On peut faire des thèmes, qui sont donc la combinaison de couleurs de base et d'une série de filtres. Il y a des thèmes basiques prédéfinis, par exemple un qui met du vert pour la charge, rouge pour la décharge, bleu pour "chargé", et qui se fout du pourcentage de batterie. Un autre thème prêt à l'emploi passe progressivement de noir à blanc en passant par les verts pour la charge, et retourne de blanc à noir mais cette fois en passant par les rouges pour la décharge. C'est très facile de faire ses propres thèmes, du coup c'est un peu comme choisir des assortiments de couleurs de fond d'écran, sauf que ça "bouge".
• Autre détail, on peut choisir le critère de mise à jour de l'information: une seule fois au lancement du programme, à chaque événement ACPI, toutes les 5 minutes, etc.. Les critères disponibles devraient suffire, mais on peut écrire ses propres critères de mise à jour. Je sais pas moi, à chaque réception de mail par exemple :)
• On peut télécommander le programme en le forçant à mettre à jour les couleurs manuellement, en lui faisant relire ses fichiers de configuration, etc..
• À la demande de Lunar qui avait à l'époque un Mac, ça marche aussi sur les Macs, qui n'utilisent pas ACPI pour la gestion de la batterie mais PMU.

Bref, en quelques semaines, le petit script était devenu un machin assez gros. Le seul truc qui n'a jamais changé, c'est que... c'est resté écrit en shell ! C'est bien séparé en plusieurs fichiers et tout, mais le tout combiné, c'est environ 1000 lignes de code.

Aujourd'hui, dans l'idée de faire un paquet Debian, j'ai remis le nez dedans, corrigé quelques trucs, ajouté une gestion du cas "batterie absente", etc.. Mais quand même... il faudrait vraiment refaire ce programme dans un autre langage, par exemple en C, en haskell, en python, ou n'importe quoi mais pas en shell par pitié, parce que là c'est vraiment devenu trop gros. N'empêche, c'était marrant à faire... Je vais peut-être me remettre à l'utiliser, tiens.