Mise à jour du 22/08/22 16:26 : plusieurs versions ont été produites depuis la création de ce sujet, désormais c’est la version 1.8.5 qui est la plus à jour et qu’il faut utiliser. Le texte ci-dessous a été mis à jour.
Une nouvelle version de Duniter est disponible, c’est un correctif d’un bug qui empêche des personnes légitimes de devenir membre à cause de la règle de distance qui est mal interprétée.
@smith-v1 cette mise à jour est nécessaire pour régler ce bug qui, en plus d’empêcher des membres légitimes de rentrer, crée de la confusion sur les outils comme g1-monit et WotWizard qui indiquent que le dossier devrait passer mais rien ne se passe.
Il est nécessaire de resynchroniser votre nœud duniteraprès mise à jour
Privilégiez le nœud g1.cgeek.fr comme source si vous hésitez, mais n’importe quel nœud synchronisé fera l’affaire.
Merci de mettre à jour votre nœud Duniter dès que possible, les livrables sont à télécharger sur le gitlab :
L’image docker est duniter/duniter:v1.8.5
Il est à noter que cette mise à jour est un hard-fork, le réseau va donc subir quelques secousses :
les nœuds en version 1.8.0, 1.8.1 et 1.8.2 vont refuser les blocs produits par des nœuds 1.8.5, la production de bloc va donc ralentir mais pas être bloquée : en effet les nœuds 1.8.5 vont quand même accepter les blocs des autres versions 1.8.
mais dès que les nœuds 1.8.5 seront majoritaires, un fork réseau va s’opérer
Le paquet yunohost n’est pas encore disponible, si vous utilisez yunohost, nous vous recommandons de couper votre nœud Duniter membre le temps que ce paquet soi disponible afin de ne pas nuire au réseau.
À noter : la synchronisation va effacer la piscine de votre nœud, mais j’ai pris le soin de sauvegarder autant que possible celles du réseau avant de proposer cette version 1.8.3.
Autrement dit mon nœud dispose des données de piscine que je vais propager au réseau au moment opportun, mais d’autres nœuds en disposent aussi (notamment Remuniter, WotWizard et g1-monit).
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) :
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)
Ç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.
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.
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.
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.
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.
Il est nécessaire de resynchroniser votre nœud duniter après mise à jour
