Testeurs g1-test : nouvelle pré-release 1.6.17 à tester!

@Mententon_03 non ce n’est pas ça car il faut activer cette feature manuellemetn et tu ne l’a pas fait :wink:
Mais de toute façon je ne vois plus aucune trace de ton noeud en 1.6.14 je pense qu’il s’est bien arrêté maintenant :slight_smile:

Merci @jytou, je préfère que tu reste a l’arrêt le temps que le réseau g1-test soit bien rétabli, pour que tu puisse revenir sur g1-test il faudra attendre qu’on publie la 1.6.17, ce qu’on pourrait faire dés ce soir en fait, mais je voudrais juste vérifier que tout les membres de g1-test synchronisés sur la bonne branche arrivent bien a calculer !

Après avoir bidouillé un tantinet le script, j’ai fait une release temporaire pour arm (ce qui m’a permis de tester au passage ma page « comment builder une release arm » sur un autre pi, j’ai (re)découvert que « zip » n’est pas installé par défaut sur raspbian…) bref, je suis dans la synchro, et si ça tourne je pourrai mettre le .deb à dispo.
Edit : c’est quand même mieux si on peut tester les raspberry en mode test aussi… ils génèrent parfois aussi des problèmes. :wink:

1 Like

un fou :rofl:

Non non, la modif est super simple (il fallait la trouver, c’est sûr) :

ligne 37 de release/arch/arm/build-arm.sh, il suffit de rajouter:

cp -a “$INITIAL_DIRECTORY” “$DOWNLOADS”

Et ensuite, on invoque directement ce script :

release/arch/arm/build-arm.sh <tag-bidon>

En fait, le script retélécharge avec git ce qu’on a déjà en local (si on est sur la bonne branche et le bon tag, bien sûr), ce qui est un tantinet inutile dans mon cas. :wink:

Mon nœud semble être dans la course, ça a l’air de tourner correctement.

Pour les joueurs, la version arm est dispo ici

1 Like

Je suis en train de redémarrer mon nœud avec la nouvelle version, il tente de résoudre pas moins de 50 forks ! Je vais le laisser essayer, juste pour voir :slight_smile:

2 Likes

Donc mon nœud a correctement résolu les forks, mais il préfère celui de @Inso et @fbuland ! J’ai tenté de forcer le trait avec une synchro mais rien n’y fait, ces 2 personnages sont plus rapides et mon nœud rejoint systématiquement leur fork.

edit : ah non pas forcément … là j’ai rejoint à nouveau le fork de @elois, @jytou et @nanocryk. Ça va bien finir par se dégager …

edit 2 : astuce : si vous branchez Cesium sur g1-test.cgeek.fr:443, vous aurez une mise à jour automatique de la vue réseau. Ça ne fonctionne pas avec le nœud g1-test.duniter.org:443, je ne sais pas pourquoi !

2 Likes

@cgeek maintenant avec toi on est 4 calculateurs a faire avancer notre branche, celle d’inso et fbuland devrait etre abandonnée :wink:

Peut etre un problème de websocket qui n’ai pas retransmis par le reverse proxy nginx ?

Tu calcules même des blocs…

1 Like

De mon côté, je n’arrive carrément pas à me connecter à ce nœud avec cesium, j’ai une erreur systématiquement. J’en utilise un autre (celui de Jérémy pour l’instant) et ça fonctionne.

1 Like

ha bah inso nous a rejoins maintenant je pense que c’est bon on a rétabli une branche principale :slight_smile:

1 Like

@cgeek de mon coté j’ai appliquer ton correctif hier soir sur 2 de mes 3 nœuds membres g1, et le 3ème continue bien de produire le bug alors que les 2 autres pas du tout depuis presque 24h, pour moi on est bon :slight_smile:

1 Like

C’était lié oui : en fait il y a toujours une histoire de timeout du maintien de la connexion websocket, et durant la migration j’ai dû oublier de rajouter ces instructions :

proxy_read_timeout 86400s; 
proxy_send_timeout 86400s; 

Là ça devrait être bien mieux !

2 Likes

Ah que c’est agréable de voir les forks se résorber tout seul ! :sunglasses: Beau boulot les gars !

3 Likes

Bien joué :thinking:

Ça se rajoute où ces bêtes-là ? Je crains de ne pas avoir suivi ça…

C’est dans la conf Nginx, car si aucune donnée ne transite par les websocket pendant un certain temps (visiblement petit), alors le websocket se ferme.

1 Like

J’ai lancé la version desktop.tar.gz de la 1.6.17.
Reset Data/ Sync sur g1-test.duniter.org 443.

Je reçois bien les blocs venant de g1-test.duniter.org 443.
Mais.
Le WS2P public est activé mais cesium me voit en noeud privé…

L’interface me dit qu’elle attend une meilleure difficulté pour calculer un bloc.
J’ai mis mes identifiants. La clef public est bonne.

J’ai cet inquiétant message d’erreur dans les logs :

2018-01-29T19:37:13+01:00 - error:  Error: ruleIssuerIsMember
    at Function.checkBlock (/mnt/data/Logiciels/duniter-desktop-v20180128.2213.27-linux-x64/app/lib/blockchain/DuniterBlockchain.js:53:19)

Faut-il ouvrir une issue ? C’est un crash sur une fonction on dirait…