Sommaire
Cher journal,
Toujours dans l’idée de parler des projets open source auxquels j’ai porté de l’intérêt, j’ai décidé qu’il était temps de refaire un journal, comme en mars 2018.
ExchangeCalendar
Comme je le prévoyais au printemps, un gros travail de fond a été nécessaire pour pouvoir réussir à faire tourner l’extension avec Thunderbird 60.
J’ai débuté quelques essais de migration automatique à gros coups de grep et sed pour mettre à jour tout le code JavaScript vieillissant. Seulement, il y avait vraiment beaucoup de code à mettre à jour et je n’étais pas hyper‐confiant sur ces mises à jour automatiques de syntaxe, car les changements d’écriture des boucles JavaScript font que les itérateurs risquent de changer de nature.
J’allais donc abandonner le maintien de cette extension, mais, entre temps, John Bieling, le développeur de l’extension TbSync a ouvert une requête de collaboration entre nos deux projets !
En effet, TbSync était à l’époque capable de ne gérer que les synchronisations avec Exchange via les API ActiveSync, mais comme il l’explique dans son rapport, le logiciel a toujours été prévu pour ajouter d’autres types de synchronisation avec un code commun pour l’interface avec Thunderbird et l’extension Lightning (les calendriers et événements dans Thunderbird).
À ce moment là, il était justement en train de réussir à rendre sa propre extension compatible avec Thunderbird 60 et il était en train d’ajouter la prise en charge de nouveaux types de synchronisation (CalDav et CardDav) à son module. Suite à sa proposition, j’ai essayé de reprendre le code d’ExchangeCalendar et de l’adapter à TbSync.
L’idée était très bonne, car ça permettait de réduire énormément la surface de code à implémenter dans ExchangeCalendar uniquement à la partie back‐end du protocole Exchange Web Services, mais toujours avec un minimum en frontal pour configurer les comptes et choisir les dossiers à synchroniser.
Par la suite, après avoir pris mes vacances en juillet, j’ai décidé de complètement arrêter mes contributions à ce projet bien trop conséquent pour ma personne seule et mes compétences. Comme j’essaie de l’expliquer dans mon message, je pense que la mutualisation des codes est vraiment la bonne voie à prendre, mais je suis clairement en dépression, je ne pourrai pas assumer cette tâche et il me faudra du temps pour peut‐être un jour revenir aider la communauté. 😕 Ce n’était pas une décision évidente à prendre et à exprimer, mais finalement, le choix était très bon, car la communauté d’Exchange Calendar s’est réveillée et, llange a réussi à reprendre mes essais du printemps et à faire fonctionner l’extension avec Thunderbird 60 ! Merci beaucoup à lui. 👏
Finalement, j’ai réussi cet hiver à reprendre son travail et à proposer quelques petites corrections qui permettent de faire fonctionner au mieux l’extension avec Thunderbird 60 (surtout la partie carnet d’adresses que j’utilise tous les jours).
Home Bank
Comme écrit plus haut, j’étais déprimé cet été et j’avais besoin de revoir l’organisation de ma vie personnelle et professionnelle. Comme pour tout le monde, l’organisation familiale se prend à base de budgets plus ou moins clairs et explicites. Pour avoir une bonne idée de ce que je pouvais prendre comme décision, j’ai eu la motivation de reprendre le code de Home Bank pour tenter de proposer une nouvelle interface de gestion des budgets avec un résumé annuelle et mensuel affiché en direct (comme proposé par un autre utilisateur).
Comme je vous l’avais raconté cet été, c’était la première fois que j’ai été confronté à un projet open source dont le code en développement n’était pas accessible.
Merci encore pour vos éclaircissements et, finalement, j’ai reçu une réponse du développeur du projet : il est intéressé par la fonctionnalité et il espère pouvoir l’intégrer dans une future version. Comme vous l’aviez imaginé, le projet est un hobby auquel il s’y consacre quand il a du temps (ce qui n’était pas le cas avec la rentrée scolaire) et, du coup, c’était simplement pour ça qu’il fallait que j’attende plus. Il m’a expliqué également que le code disponible sur le PPA était vraiment très proche du code actuellement en développement et que, par conséquent, il n’y avait pas trop besoin de s’en faire pour la prospérité du développement en cas d’accident. :)
Le code en C m’avait bien plu finalement : bien que ce soit un peu plus lourd à écrire à la mode programmation orientée objet, le C a une syntaxe assez simple à appréhender et à utiliser. Home Bank m’a permis de bien comprendre que l’âge du langage n’est pas du tout un problème pour faire de superbes projets avec !
Actuellement, je reprends mon code pour ajouter quelques fonctionnalités indispensables pour être vraiment utile (ajouter, enlever et renommer des lignes de budgets).
acme-dns-tiny
Depuis mars, j’ai publié la version 2.0, puis la version 2.1 pour suivre les derniers développements des brouillons de la future RFC ACME. Cette RFC permet de définir le processus de délivrance automatisée de certificats X.509, utilisée, entre autres, par les serveurs de Let’s Encrypt. Le script Python acme-dns-tiny permet de faire des demandes de certificats via des ressources DNS installées au bon moment avec la bonne valeur.
Je reçois de temps en temps des retours d’utilisateur assez intéressants. Par exemple, cette semaine j’ai découvert que certains résolveurs DNS lient le nom localhost à 127.0.0.1, et d’autres retournent juste une erreur NXDOMAIN. Je ne sais pas de qui, entre Quad9 et Google est le plus proche des spécifications du DNS, mais ça a permis de révéler une incohérence dans mon script (il essaie de faire des mises à jour alors qu’il sait qu’il ne pourra pas vérifier le résultat).
Pour voir les différences, vous pouvez installer dnsutils sous Debian et faire :
dig A localhost @9.9.9.9
dig A localhost @8.8.8.8xmpp-pane et Ibex
Finalement, j’ai décidé d’abandonner le développement de mon lecteur de flux pubsub XMPP que je nommais xmpp-pane (voir le journal précédent pour plus d’informations). Le problème principal pour moi était que le système de WebExtension est incapable de me proposer un stockage sûr des données utilisateurs. En effet, Firefox ne propose pas de stockage chiffré qui ne serait accessible que via l’extension elle‐même, et je ne pouvais donc stocker nulle part de manière sécurisée les mots de passe utilisateur.
En revanche, comme j’ai décidé de changer de travail, j’ai voulu recommencer à pratiquer des langages tels que C et C++. J’ai donc profité de reprendre l’idée de ce projet, mais de faire cette fois‐ci une application de bureau avec les outillages de Glib, GTK+, libsecret, etc., pour tout gérer correctement.
J’avais bien commencé le développement d’Ibex, jusqu’à cet hiver lorsque…
Hein ? Kadabra évolue !
Un changement de mémoire vive a tué mon serveur auto-hébergé kadabra.adorsaz.ch… Je n’avais pas compris tout de suite que la nouvelle mémoire vive était fautive et j’ai tenté de réparer mon RAID 1 Btrfs… Ce qui a été un désastre et a planté un clou définitif dans le cercueil de mon serveur. Heureusement, je venais d’acheter d’occasion un nouveau Lenovo Thinkpad L500 (série que je ne connaissais pas) pour une autre tâche.
J’ai donc pu rapidement monter un nouveau serveur sous le doux nom d’alakazam.adorsaz.ch (oui, mon enfance a été bercée par les Pokémon 😄). Mes sauvegardes ont très bien fonctionné et je n’ai perdu qu’une journée (environ) de données personnelles (c’est‐à‐dire pas grand’chose pour un jour de travail !). J’en ai profité pour réviser mes différentes configurations et pour utiliser un nouveau système de sauvegardes incrémentielles à coup d’instantanés Btrfs pour figer les données à une date donnée, et à coup de rsync pour synchroniser les dossiers du disque de production avec le disque de sauvegarde.
#!/bin/bash
set -e
set -x
bck_root='/srv/backup/alakazam'
bck_rsync='rsync -a --xattrs --acls --delete --stats '
bckp_psql='sudo -u postgres pg_dump '
# Backup on 10 days at most once by hour
# (So, for one day, we can backup twice for example)
bck_suffix="$(expr $(date +'%d') % 10)_$(date +'%H')"
bck_snapshot="/srv/backup/snapshot/alakazam.${bck_suffix}"
mount -o remount,rw /srv/backup
mkdir -p "${bck_root}/etc/"
mkdir -p "${bck_root}/home/"
mkdir -p "${bck_root}/ldap/"
mkdir -p "${bck_root}/psql/"
mkdir -p "/srv/backup/snapshot/"
mkdir -p "${bck_root}/srv/"
mkdir -p "${bck_root}/var/lib/"
date >${bck_root}/last_sync_start
slapcat -b 'cn=config' >"${bck_root}/ldap/config.ldiff"
slapcat -b 'dc=adorsaz,dc=org' >"${bck_root}/ldap/adorsaz.org.ldiff"
${bckp_psql} ejabberd >"${bck_root}/psql/ejabberd.sql"
${bckp_psql} freshrss >"${bck_root}/psql/freshrss.sql"
${bckp_psql} gitlab >"${bck_root}/psql/gitlab.sql"
${bckp_psql} owncloud >"${bck_root}/psql/owncloud.sql"
${bckp_psql} roundcube >"${bck_root}/psql/roundcube.sql"
${bck_rsync} \
/etc/ "${bck_root}/etc/"
${bck_rsync} \
/home/ "${bck_root}/home/"
${bck_rsync} \
/var/lib/ "${bck_root}/var/lib/"
${bck_rsync} \
--exclude backup \
--exclude kadabra \
--exclude movim/cache \
--exclude nextcloud/cache \
--exclude www/movim/cache \
/srv/ "${bck_root}/srv/"
date >${bck_root}/last_sync_end
if [ -d "${bck_snapshot}" ] ; then
btrfs subvolume delete --commit-after "${bck_snapshot}"
fi
btrfs subvolume snapshot -r "${bck_root}" "${bck_snapshot}"
mount -o remount,ro /srv/backupVous remarquerez que je ne passe pas par une étape de compression, car la destination de ma commande rsync est un système Btrfs monté avec l’option compression. Celle‐ci permet pour chaque nouveau fichier enregistré de le compresser à la volée si c’est utile (selon un test de compression sur un échantillon des données). Comme la compression et la décompression sont réalisées à la volée par le système de fichiers, je peux avoir le bonheur d’utiliser directement rsync et ne plus passer des heures à attendre que mon processeur finisse de tout recompresser avec tar quand je crée la nouvelle archive master (il n’y plus d’archive master, juste des instantanés qui se suivent).
Pour moi, ce script est bien plus lisible et je sais exactement ce qu’il va faire, alors qu’avant j’utilisais backup-manager qui faisait bien son travail, mais qui était impossible à relire et adapter facilement pour moi.
Et voilà, c’est ainsi que 2019 est déjà arrivé et que je n’ai malheureusement pas contribué au code source de LinuxFr.org.
J’espère pouvoir vous refaire un rapport aussi complet l’année prochaine. :)
# depression ou burnout
Posté par NeoX . Évalué à 3.
merci à toi d'avoir participé à tous ces projets.
mais est-ce une depression ? ou simplement un burnout ?
plus le temps de tout gerer boulot, famille, projetS opensource, hobby, sport…
[^] # Re: depression ou burnout
Posté par Adrien Dorsaz (site web personnel, Mastodon) . Évalué à 6.
Alors, c'est une bonne question. Jusqu'à aujourd'hui, je pensais que burn out était simplement la traduction anglaise de dépression.
De ce que j'ai rapidement lu sur Wikipédia, c'est un épuisement profond dû a un facteur externe (travail, enfants…).
J'ai été voir l'article de Wikipédia sur la dépression et ça correspondait plus à mon état de l'été dernier: plus aucune motivation à faire mes hobbys, tristesse profonde, plus aucune estime de moi… Je n'ai lu que les premiers paragraphes et ça correspond bien.
Heureusement, j'ai été mis en arrêt le temps de me remettre d'aplomb (j'avais aussi de la fatigue physique) et de retrouver mes valeurs et reconstruire mon esprit. Maintenant ça va bien mieux ;)
[^] # Re: depression ou burnout
Posté par Philippe F (site web personnel) . Évalué à 8.
Le burn-out emmène vers une dépression, qui elle peut s'installer beaucoup plus durablement que la charge de travail / pression / complications qui ont conduit au burn-out. C'est donc assez sournois, les conséquences persistent longtemps après que les causes aient disparues.
Je parle malheureusement d'expérience…. 2 ans après un burn-out professionnel, je sens que je ne suis plus capable de gérer le niveau de responsabilité professionnelle que je gérai auparavant. Je ne suis pas sur que je pourrai de nouveau le faire dans ma vie.
[^] # Re: depression ou burnout
Posté par Adrien Dorsaz (site web personnel, Mastodon) . Évalué à 3.
Merci pour ton témoignage, c'est plus claire pour moi :)
J'ai aussi remarqué que l'épuisement est sournois : je ne me sentais pas plus fatigué que ça et c'est la doctoresse qui m'a fait prendre conscience que ce n'était pas une petite fatigue, mais un épuisement profond.
C'est après cette prise de conscience que j'ai accepté de me mettre en arrêt et aussi que j'ai averti la communauté d'ExchangeCalendar que je ne pourrai pas m'investir pendant un certain temps.
Je ne pensais pas que l'épuisement à long terme pouvait avoir des conséquences aussi importantes que ce dont tu témoignes!
# Real programmers use c
Posté par El Titi . Évalué à 2.
C'est vraiment un super boulot tout ça.
Sais-tu quand la prochaine release intégrant tes modifs est prévue ?
Le leader du projet n'est toujours pas décidé à migre sous une forge Git ?
[^] # Re: Real programmers use c
Posté par Adrien Dorsaz (site web personnel, Mastodon) . Évalué à 2.
Hello,
Je ne sais pas quand est-ce que la prochaine release est prévue, ça dépend du temps et de la motivation de Maxime :)
Je trouve que les quelques modifications que je suis en train de faire apportent une réelle plus valu à ce merge-request, il vaut peut être mieux attendre encore un peu avant d'utiliser cette fonctionnalité.
Pour la migration vers git, ce n'est pas prévu d'être fait pour l'instant. Maxime m'a dit qu'il préférait d'abord se concentrer sur les dizaines whish / bugs qui sont ouverts et les quelques autres points qu'il voudrait traiter avant de devoir apprendre à utiliser un nouvel outil et devoir changer ses habitudes.
# ExchangeCalendar
Posté par Davy Defaud . Évalué à 3.
Salut Adrien,
Depuis que ma distro a mis à jour Thunderbird en version 60, le carnet d’adresses ne fonctionne plus, comme tu le sais. Je suis donc très intéressé par tes correctifs, mais ta demande d’intégration attend depuis 26 jours une réaction du gestionnaire du projet. :-/
En attendant qu’elle soit intégrée, aurais-tu l’amabilité de nous fournir un lien vers un fichier XPI incluant tes corrections, STP ? :-)
[^] # Re: ExchangeCalendar
Posté par Adrien Dorsaz (site web personnel, Mastodon) . Évalué à 5.
Hello,
Oui, bien sûr, j'ai fait un build depuis ma branche perso
v5a3-trimque j'utilise depuis sur mon poste. Il intègre les 2 PRs en attente.Vous pouvez le trouver sur mon cloud ici:
https://cloud.adorsaz.ch/index.php/s/AmXbatzQoX9S2ix
Si jamais, pour faire vos propre build, il faut juste faire
apt install make zip, allez dans le répertoire et lancermake;-)[^] # Re: ExchangeCalendar
Posté par Davy Defaud . Évalué à 2.
Salut,
Je te remercie, ça fonctionne au poil. :-)
C’est étonnant ce manque de réactivité du gestionnaire du projet pour fusionner tes modifs. Il ne s’agit pourtant pas de nouvelles fonctionnalités, mais de rétablir une fonctionnalité perdue. Est‐il toujours aussi peu réactif ou est‐ce exceptionnel ?
P.‐S. —
apt install make zip, quand on a une distro basée sur RPM… :-/[^] # Re: ExchangeCalendar
Posté par vv222 . Évalué à 3.
Étant mainteneur d’un logiciel libre, je ne trouve pas qu’un mois d’attente dénote d’un quelconque manque de réactivité.
Il ne faut pas oublier que maintenir un logiciel libre se fait souvent en parallèle d’autres activités chronophage, comme par exemple un emploi rémunéré, donc on peut avoir une disponibilité très aléatoire en fonction de plein de choses sur lesquelles on n’a aucun contrôle.
[^] # Re: ExchangeCalendar
Posté par Davy Defaud . Évalué à 3.
Certes, mais il ne s’agit pas d’écrire du code ou de toute autre activité chronophage, mais simplement de fusionner les changements dûment expliqués par Adrien, et ce, afin de rétablir un fonctionnement actuellement déficient.
Je ne fais aucun reproche au mainteneur, je fais juste part de mon étonnement.
[^] # Re: ExchangeCalendar
Posté par vv222 . Évalué à 6.
C’est un piège dans lequel on tombe facilement tant qu’on n’est pas soi-même passé de l’autre côté de la pull request ;) (moi le premier d’ailleurs avant de me lancer dans l’aventure)
En fait la difficulté/durée de la tâche importe peu, c’est de se dégager du temps tout court qui n’est pas évident.
Il peut facilement s’écouler des semaines sans que je ne puisse contribuer d’une quelconque façon à mon propre projet. Et pourtant je suis un passionné qui y dédie la quasi-totalité de mon temps libre avec grand plaisir !
Pour ne rien arranger, quand on a enfin un peu de temps devant soi il est souvent beaucoup plus attirant de le passer à développer soi-même que d’intégrer les modifications de contributeurs. J’essaie d’éviter au maximum ce travers, mais c’est souvent au prix d’une réduction de mon plaisir personnel, donc je comprends facilement que d’autres puissent laisser traîner des pull requests qui pourtant seraient très bénéfique à tous les utilisateurs du logiciel.
Je me rappelle d’un commentaire ici-même, de mémoire de Jehan, qui donnait comme approximation deux mois comme le temps raisonnable avant de relancer le mainteneur d’une application sur ce genre de sujet. De mon expérience (forcément limitée et biaisée bien sûr), c’est une bonne approximation.
Bref, maintenir un logiciel libre plus ou moins largement utilisé est une activité franchement pas évidente, et ça se complique encore plus quand de sympathiques contributeurs viennent nous donner un coup de main ;)
C’est paradoxal, mais plus on nous aide et plus on a de boulot. Ce qui me sauve (et probablement d’autres mainteneurs dans le même esprit) est que je suis toujours très enthousiaste à l’idée d’accueillir de nouveaux contributeurs, et donc essaie de traiter rapidement leurs demandes pour leur donner envie de rester.
La contrepartie, c’est que je laisse plus facilement traîner les requêtes des contributeurs bien habitués au projet, qui ont compris depuis longtemps que je peux laisser une requête sans réponse pendant des semaines voire des mois sans que ça ne signifie que je les ai oublié.
Désolé pour le pavé mais c’est la première fois que j’ai l’occasion de m’exprimer à ce sujet, alors je me suis un peu laissé aller ;)
[^] # Re: ExchangeCalendar
Posté par Davy Defaud . Évalué à 3. Dernière modification le 15 mars 2019 à 16:29.
Ton avis n’était pas inintéressant. ;-)
Pour info, les modifications d’Adrien ont été fusionnées le 15 janvier.
# Une petite erreur s'est glissée dans le script de backup ;-)
Posté par Adrien Dorsaz (site web personnel, Mastodon) . Évalué à 4.
Et voilà, ça fait plus de 10 jours que mon script tourne et je découvre enfin le bug dans les dernières lignes:
Les guillemets simples empêchent l’interprétation de la variable
${bck_snapshot}.Le snapshot n'est donc pas supprimé et comme il est fait en read only avec l'option
-r, la commande suivante refuse de refaire un snapshot par dessus l'existant.[^] # Re: Une petite erreur s'est glissée dans le script de backup ;-)
Posté par Davy Defaud . Évalué à 4.
Oh, l’erreur de débutant ! :-P
J’ai corrigé ton script et, dans un élan de bonté pour te remercier de tes contributions, dont je vais moi‐même profiter, je suis allé jusqu’à corriger ton journal (quelques fautes de français, orthotypographie, répétitions, etc.). Si toutefois une reformulation ne te plaît pas, tu restes l’auteur et tu auras donc le dernier mot, cela va de soi.
Après cette année 2018 qui fut de toute évidence un mauvais cru pour toi, j’espère te porter chance en te souhaitant très sincèrement une bonne et heureuse année 2019.
Amicalement,
Davy
[^] # Re: Une petite erreur s'est glissée dans le script de backup ;-)
Posté par Benoît Sibaud (site web personnel) . Évalué à 10.
Un outil qui peut aider :
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.