J’ai attaché le Runner habituel de Duniter au fork de bpresles afin que la CI passe sur sa Merge Request. Les tests sont passés, nickel.
@bpresles tu as fait un super boulot, non seulement tu as corrigé le bug mais surtout tu as verrouillé le comportement avec un test unitaire. Je te remercie pour cette contribution et pour le coup, je te fais un don personnel de 100DU pour ce travail exemplaire. Merci à toi.
Si ton offre tient toujours, je te laisse faire 
Ok, j’attendais. Je m’en occupe.
Je viens de committer la modif pour rendre possible les releases arm (et potentiellement windows). Je ne l’avais pas fait et du coup je me retrouve à nouveau dans le pétrin pour faire la release. 
J’ai relancé les tests. Ils échouent des fois sur un test de la PoW.
Tu as un autre problème ?
Merci, cela dit ça n’est pas normal que tu aies eu ce bug.
Voici ma version de TypeScript quand en dev:
$ yarn tsc -v
yarn run v1.7.0
$ tsc -v
Version 3.1.6
Donc, TypeScript 3.1.6. Mon hypothèse : tu as une version différente.
Cette nuit (vers 3h00 du matin), il y a eu de nouveaux forks, visiblement résolus depuis. Mais la blockchain a été ralentie de plusieurs heures à cause de cela. D’ailleurs celle-ci a encore environ 3h de retard actuellement.
C’est dommage que l’on ai pas encore d’outil de suivi, ce serait vraiment super de pouvoir visualiser graphiquement ce qui s’est passé. En tout cas Remuniter m’indique qu’il a dans sa BDD 74 forks potentiels à suivre. Du coup je le resynchronise, il semble un peu perdu.
La cause est peut-être que des nœuds migrés en 1.7.14 n’ont pas été resynchronisés (comme indiqué dans le message de livraison ci-dessus), ce qui expliquerait que des soft-forks continuent de se produire. Si c’est un autre problème, tant que nous n’aurons pas d’outils de diagnostics performants, ça risque d’être compliqué d’en comprendre l’origine 
Je me suis demandé si implémenter un client WS2P en Python dans Duniterpy était une perte de temps ou pas. J’ai laissé tombé pour des implémentations plus prioritaires.
Mais j’ai l’impression que cela peut-être utile pour faire le genre d’outils dont tu parles à des fins d’analyses statistiques, pour le debug et la maintenance de Duniter.
De plus je voudrais faire un helper scannant le réseau pour détecter la chaîne majoritaire (pour que tous les clients Python puissent être réellement p2p comme Sakia) et je me demande si utiliser WS2P ne serait pas plus efficace que GVA.
Alors, un client WS2P en Python dans Duniterpy ? Utile ou inutile ?
Cela permettrait de donner un accès “temps réel” à la vie de la blockchain, notamment via les trames WS2P HEAD, mais aussi la réception des blocs et autres données qui transitent via cette API.
Maintenant il est aussi possible d’exploiter BMA pour récupérer ces mêmes trames (via /network/ws2p/heads), mais pas en mode push. Donc il faut puller régulièrement.
L’accès WS2P te permet d’accumuler des données en mode push, donc d’être notifié de tous les événements qui se propagent (ainsi, tu seras notifié du fait qu’un nœud, même planqué derrière sa box en WS2P Privé, change d’état). C’est en effet une voie intéressante pour faire du monitoring.
Juste un petit mot pour dire que mon raspi n’avait jamais aussi bien tourné qu’avec cette version. Il ne “traine” plus et parvient à calculer, lentement mais sûrement, et je ne suis plus obligé de refaire une synchro tous les 3 jours. Je sais pas ce que tu as changé, @cgeek, mais c’est beaucoup plus stable pour mon petit noeud (!).
Ça sera un embranchement que pour lui, car il a un retard majeur par rapport aux autres nœuds du réseau.
Du coup, cet embranchement devrait être rapidement résolut et il rejoindra la branche majoritaire.
Le sujet est traité dans ce post Bug à l’ajout d’une certification d’un non membre dans le bloc à calculer : v1.7.16
Si les forgerons se mettent à jour, ça sera rattrapé plus rapidement. Sinon, oui, l’algorithme du protocole fait que ça sera rattrapé tôt ou tard. Le niveau de difficulté commune de preuve de travail a déjà bien chuté.
Question de néophyte : faisant tourner un nœud Windows, est-il utile ou nuisible que je le fasse tourner dans sa dernière version disponible, à savoir la 1.7.11, ou bien vaut-il mieux que je renonce à faire tourner ce nœud en attendant une nouvelle version Windows ?
Par ailleurs j’ai, selon les nœuds sur lesquels mon Cesium se cale, des différences d’état “membre” ou non et du “nombre de certifications” reçus. Cela vous intéresse-t-il de connaitre ces différences et les nœuds correspondants ?
À ce que je vois, ton nœud écrit des blocs valide dont un tout récemment.
Utile ? Oui, tu participes.
Nuisible ? Je pense pas, si tu écris un mauvais bloc, il sera refusé par les autres nœuds.
Après, il est possible que quelque chose se passe pas bien pour ton nœud, il peut forker ou autre chose.
Car, il y a eu pas mal de correctif depuis.
L’idéal serait qu’on arrive à construire les releases pour Windows. Il me semble que c’est @jytou qui est sur le coup.
Oui, le problème étant que la release windows plante (tout comme l’ARM) et autant j’ai pris le temps d’investiguer l’ARM autant je n’ai pas encore pris le temps d’investiguer jusqu’au bout la Windows. Peut-être qu’avec le correctif que j’ai commité pour l’ARM, la Windows passera aussi, mais je ne peux pas savoir tant qu’il n’y a pas de nouveau tag de release qui intègre mon commit… et ce week-end je n’ai pas eu une minute. 
Peut-être demain.
Sur l’un des deux raspi :
pi@independent:~/duniter_release/duniter $ yarn tsc -v
yarn run v1.3.2
$ tsc -v
/bin/sh: 1: tsc: not found
error Command failed with exit code 127.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
Sur le deuxième :
pi@pi3tv:~/duniter_release/duniter $ yarn tsc -v
yarn run v1.15.2
$ tsc -v
/bin/sh: 1: tsc: not found
error Command failed with exit code 127.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
C’est normal, qu’il ne trouve la commande tsc sur aucun des deux ? Sinon ils ont tous les deux des versions différentes mais il me semble qu’ils ont planté dans la release exactement de la même manière. Bizarre cette histoire.
L’exécutable tsc est livré dans les node_modules/, donc il te faut exécuter yarn au préalable.
Tu peux te faire une petite VM debian en console avec juste duniter-serveur dessus que tu lances au démarrage de windows en attendant la release ? Ça s’installe assez vite, j’ai jamais testé mais je ne vois pas de raison pour que ça marche pas.
Comme ça, t’as la dernière version qui tourne en linux sous windows