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 !
3 Likes
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.
Nouvelle version Duniter 1.8.4
Je viens de publier une nouvelle version suite à la manifestation d’un vieux bug (#1434) du fait des nombreux forks qui se créent.
Cette mise à jour n’est pas obligatoire mais vivement conseillée en lieu et place de la 1.8.3, elle permet une plus grande stabilité du nœud (en théorie : exit les blocages dans la résolution de fork).
Pas besoin de resynchroniser si vous l’avez déjà fait en 1.8.3, sinon il faut le faire.
cc @Blacksmith, et notamment @EtK @vincentux @Philou @HugoTrentesaux qui ont subit cette anomalie et dont le nœud est bloqué.
7 Likes
Serveur migré en v1.8.4. J’ai testé l’image docker avant sur mon serveur g1test (je savais que ça servirai encore un peu ) parce que bon hein, chat échaudé… 
2 Likes
Mis à jour également, mon noeud était bloqué aussi, merci pour le correctif
1 Like
Fait chez moi avec le tag spécifique de l’image docker duniter/duniter:v1.8.4
Ce serait top par contre de màj le tag latest car il pointe toujours sur la 1.8.2 si je ne me trompe pas.
Par ailleurs, j’en profite pour vous partager un petit repo léger (avec docker-compose et qui gère les répertoires locaux pour les data et les keychain éventuelles) qui me simplifie la vie :
3 Likes
En parallèle de mes aventures avec polkawallet_sdk, j’ai relancé un noeud 1.8.4 cet aprem sur un bout de serveur, mais ma connexion ssh est tombé après 3h de sync et 75% d’apply…
Je retente une sync demain, en screen cette fois ci …
1 Like
Services tiers mis à jour :
- Remuniter : 1.7.22
- g1-monit : 1.7.22
- gannonce : 1.7.22
- wot-wizard : 1.7.22
- nœud g1.duniter.org : 1.8.4
Pour ce dernier, la synchro est toujours en cours et prend beaucoup de temps. J’éditerai ce message une fois celle-ci terminée.
edit : g1.duniter.org resynchronisé.
3 Likes
Fait 
1 Like
Je viens de relancer la sync avec 1.8.4.
Est-ce que ce correctif est appliqué sur la branch dev, du coup en buildant dev je devrait avoir GVA et correctif à jour ?
Je demande car je vois que le dernier commit sur dev date de 3 jours par elois, mais avec les différentes dépendance j’ai un peu du mal à suivre vos commits…
Je rappel juste que g1-stats et donc carte.monnaie-libre.fr et quelques autres services ont besoin de GVA pour avoir des données à jours (possible de faire avec BMA mais nécessite de reprendre du vieux code qui s’exécute en ~3h au lieux de quelques secondes pour récupérer la liste des pubkeys notamment, de mémoire…). Et le dernier noeud GVA encore actif sur lequel tous ces services reposent auj est celui d’elois.
Je savais pour wot-wizard, mais je ne savais pas que tous ces autres services étaient encore “bloqués” sur 1.7.x, c’est la même raison que pour wot-wizard, besoin d’accès direct aux dbs de Duniter ?
Maintenant que j’ai vu ton message et compris que cette branche était utilisée, oui, je viens de pusher.
Oui.
2 Likes
Voilà mon noeud est en ligne:
Je n’ai pas fait de config réseau particulier, je pense que ça doit suffire en accès privé pour participer au réseau
1 Like
Oui parfait, je le vois bien en WS2P à jour et synchronisé 
1 Like
Pour suivi : à ce stade, nous en sommes à 34% (11/32) nœuds membres en nouvelle version, c-à-d en version 1.8.4 ou 1.8.3 ou 1.7.22 ou 1.7.21, toutes compatibles.
Il ne manque donc plus que 16% soit 6 membres avant qu’un hard-fork définitif du réseau ne se produise.
À vous de jouer 
la correction effectuée n’était pas suffisante, je dois encore creuser le sujet et publierai une v1.8.5 dès que possible.
8 Likes
Quelques nœuds parmi les pairs de g1.duniter.org listés avec Kazou à notifier pour monter en version.
| nœud | version |
|---|---|
| g1.openmyprojects.com:443 | 1.8.2 |
| g1.cloud-libre.eu:443 | 1.8.2 |
| g1.nuaje.fr:443 | 1.8.2 |
| monnaie-libre.ortie.org:443 | 1.8.2 |
| duniter.occitanet.fr:443 | 1.8.2 |
| g1.soberaniadigital.net:443 | 1.8.2 |
| g1.cuates.net:443 | 1.8.2 |
| g1.texu.es:7443 | 1.8.2 |
| g1.bounceme.net:33607 | 1.8.1 |
1 Like
upgrade en 1.8.5 done
2 Likes
Nouvelle version Duniter 1.8.5 disponible
Contrairement à ce que je pensais, la version précédente ne corrigeait pas le bug provoquant le blocage des nœuds 1.8.3 (#1434). La version 1.8.5, oui. 
- Si votre nœud n’est pas bloqué : vous pouvez mettre à jour sans resynchroniser.
- Si votre nœud est bloqué : une resynchronisation est nécessaire (sur nœud g1.cgeek.fr par exemple).
L’image Docker duniter/duniter:v1.8.5 a été publiée et l’image latest a été mise à jour.
Explication
J’ai cette fois-ci réussi à reproduire précisément le bug sur ma machine et à isoler le code fautif : il s’agit d’une véritable erreur qui traîne depuis plusieurs années dans la couche bas niveau de Duniter dans l’indexeur des expirations d’adhésion.
Concrètement : si un membre perdait son adhésion dans un bloc et que ce dernier était défait au cours d’une résolution de fork, alors Duniter plantait et corrompait ses index, rendant impossible l’ajout de nouveaux blocs.
Je pensais avoir réglé le problème en v1.8.4 car un autre bug m’a sauté aux yeux à peu près au même endroit et qui avait la même forme. Mais je me suis trompé, et n’ayant pas réussi à reproduire le bug j’ai parié qu’il s’agissait de cela. Mais cette fois je suis assez confiant puisqu’un test a reproduit et confirmé l’anomalie.
Pour la petite histoire, le correctif ne tient pas à grand-chose : il suffit de remplacer un « d » par un « s » pour que le fonctionnement soit correct. C’est d’ailleurs de la confusion entre ces 2 notions proches expires_on et expired_on que le bug est né.
9 Likes