Mon nœud g1.librelois.fr est également à jour et resynchronisé.
À noter que le paquet pour armv7 a été buildé sur mon rpi4 qui est désormais sur raspbian 11 (bullseye), si vous être encore sous buster il faut compiler votre propre binaire ou passer à bullseye 
Je regarde ce soir pour mettre à jour le paquet YunoHost.
Si les utilisateurs @YunoHost ne veulent pas attendre, la mise à jour est faisable manuellement en mettant à jour via le paquet Debian, via la méthode à suivre (pas pour ARM) :
wget https://git.duniter.org/nodes/typescript/duniter/uploads/d3a035f686f89ad6357efcdbac893632/duniter-server-v1.8.3-linux-x64.deb
dpkg -i duniter-server-v1.8.3-linux-x64.deb
systemctl restart duniter
Pour ARM, je vais devoir forcer que YunoHost v11.0 soit requis. Cette version fait le passage à Bullseye (v11) qui est sortie il y a une semaine.
L’image docker 1.8.3 (digest f34740fc0545) plante avec ce message dans les logs : 
internal/modules/cjs/loader.js:638
throw err;
^
Error: Cannot find module '../native'
at Function.Module._resolveFilename (internal/modules/cjs/loader.js:636:15)
at Function.Module._load (internal/modules/cjs/loader.js:562:25)
at Module.require (internal/modules/cjs/loader.js:692:17)
at require (internal/modules/cjs/helpers.js:25:18)
at Object.<anonymous> (/duniter/duniter/neon/lib/index.js:3:16)
at Module._compile (internal/modules/cjs/loader.js:778:30)
at Object.Module._extensions..js (internal/modules/cjs/loader.js:789:10)
at Module.load (internal/modules/cjs/loader.js:653:32)
at tryModuleLoad (internal/modules/cjs/loader.js:593:12)
at Function.Module._load (internal/modules/cjs/loader.js:585:3)
g1.trentesaux.fr est en 1.8.3 et synchronisé mais crash à la résolution de fork
En 1.8.3 aussi pour g1.mithril.re
Pourquoi est-ce nécessaire ?
Pour mémoire, je mets en lien la raison de ce hotfix :
Ça semble venir du fait que @cgeek à upgrade à node 16.x, je ne sais pas pourquoi il a fait ça, mais je ne peux pas build duniter locament sous node 16.x, alors que ça marche parfaitement sous node 10.x.
Je viens de rebuild localement l’image docker sous node 10.x et de la force push sur dockerhub.
@vit ça devrait être résolu maintenant, mais il te faudra probablement supprimer l’image pour forcer son retéléchargement.
Sans resync il est impossible de récupérer comme par magie les certifs manquantes dans le fichier wotb.
C’est une erreur, je ne pensais pas que c’était utilisé par un script quelconque. Mais oui, ça builde toujours en 10.x.
Ok, merci pour cette précision. Je suppose qu’il s’agit-il uniquement des certifications en attente, de la piscine ? Autrement, des nœuds v1.8.3 non resynchronisés finiront dans un fork du fait d’une inconsistance. Correct ?
Non ce sont exclusivement les certifications déjà inscrites en blockchain. La piscine n’a pas de lien avec ce bug.
Mais oui, les nœuds 1.8.3 non resynchronisés sont comme des nœuds 1.8.2, et même en pire car ils vont forker sans être d’accord avec les 1.8.3 resynchronisés ni avec les 1.8.2.
C’est-à-dire ?
Voici pour YunoHost :
Je vais pendant un moment ne pas forcer YunoHost/Debian en v11 comme « requirement » pour que les instances YnH ne soient pas prématurément mises à niveau pour pouvoir suivre le hard-fork Duniter/Ğ1. La version ARM va rester en v1.8.2 en attendant pour ne pas casser la màj des instances duniter_ynh/arm.
Une fois YnH/Debian v11 un peu plus établit et un besoin grandissant pour la version ARM, je vais forcer YnH v11 comme pré-requis pour pouvoir bumper la version ARM en v1.8.3.
Changements pour le paquet YunoHost fusionné. La mise à jour devrait être disponible sous peu dans le catalogue des apps YunoHost.
Du côté de mon serveur sur lequel je maintiens mon build custom de Duniter v1 avec des commits de la branche 1.9, j’ai réussi à construire et à faire tourner Duniter avec Nodejs v16. Avec Nodejs v10, j’avais ce problème que je n’ai pas réussi à résoudre avec les solutions proposées.
Nœud https://vit.fdn.org:10900/ mis à jour en 1.8.3 avec docker et resynchronisé avec succès.
Vers l’infini et au-delà ! 
Apparemment rien après une deuxième synchronisation. La première fois Duniter avait crashé après des messages de logs indiquant une résolution de forks.
g1.trentesaux.fr est donc en marche
Dans ce cas, il vaut mieux que ces personnes éteignent leur nœud pour favoriser Duniter 1.8.3.
Par exemple @vincentux ?
II me semble que parmi @YunoHost, il y a @Thatoo qui fait tourner son instance sous ARM.
Dans ce cas, arrêter le nœud le temps de mettre à jour en YnH/Debian v11 pour pouvoir faire tourner Duniter v1.8.3.
Les nœuds 1.8.3 commencent à titiller le réseau :
Il faudrait encore quelques nœuds pour que la puissance de calcul soit compétitive face à la 1.8.2 !
Si on me passe un serveur je veux bien relancer mon noeud 
(plus de place nul part)
Voici le bump v1.8.3 ARM pour YunoHost v11 qui est prêt à l’emploi :
Je ne vais pas le fusionner d’ici un moment, peut être un mois afin de ne pas bloquer les instances non-ARM de pouvoir màj Duniter sans devoir màj YnH. Pour les instances ARM, vous pouvez mettre à jour manuellement avec le paquet Debian ou directement via la branche git de cette MR.
Je serais afk les deux prochaines semaines.
