Duniter 1.7.14 : résout les forks de la Ğ1 des dernières semaines


#21

@cgeek arg en fait je crois que j’ai trouvé, c’est la seule erreur que je n’ai pas copiée ici :

app/lib/computation/BlockchainContext.ts:104:90 - error TS7006: Parameter ‘p’ implicitly has an ‘any’ type.
104 await indexer.preparePersonalizedPoW(local_vHEAD, this.vHEAD_1, (n:number, m:number, p = “”) => this.dal.range(n,m,p), this.conf)
~~~~~~

Comment est-ce que je corrige ça, moi ? :smiley:


#22

Tu travailles en environnement propre ? Si tu as un node_modules/ souillé par une précédente installation, ou si tu as déjà transpilé du TypeScript d’un ancien code source, tu peux avoir ce genre d’erreur.

En plus le transpilateur se gourre, le type est string vu la valeur par défaut.


#23

Je fais systématiquement un rm -rf duniter puis git clone…

Mais je suppose que tu veux parler de l’environnement de node… je le nettoie comment ?

Sinon tu me dis que tu as node 9.11.2 mais dans le build_arm.sh il y a toujours 9.4.0. Tu veux que je le change ? Par ailleurs, dans mes recherches sur node (c’est une planète que je ne connais pas du tout) nodejs ne supporte apparemment pas la version 9, c’est 8 ou 10. Je suppose que comme d’autres softs les versions impaires sont des versions de dev ?


#24

Je parlais du rm -rf Duniter, donc à priori c’est bon.

Mais vraiment, je n’ai rien changé d’autre que du code TypeScript. Je ne vois pas pourquoi tu aurais la moindre erreur.

Ah si ! Utilise yarn plutôt que NPM.


#25

Euh. J’ai les 2. :smiley: Je ne lance jamais de commande yarn ou npm, ce sont les scripts de release qui font… ce qu’ils ont à faire. :thinking: j’ai raté quelque chose ? :slight_smile:

Et sinon pour le passage à node 9.11.2 ?


#26

Pour node, mieux vaut rester sur une version connue et censée fonctionner. Donc la 9.4.0.


#27

Je suis donc repassé en 9.4.0, j’ai corrigé l’erreur de type et après avoir bidouillé manuellement pour que la ******* de release rafraîchisse pas avec le git… c’est passé. :slight_smile: Arf. En cours de test sur le raspi, qui est en train de synchroniser, apparemment correctement, en tout cas il a l’air d’avoir tous les binaires dont il a besoin (et le .deb fait quelques mégas de plus que celui qui foirait, ce qui est plutôt bon signe).

Bon. Reste la windows maintenant… peut-être le même problème. Ça va être moins drôle pour bidouiller la release. @cgeek tu ferais pas une 1.7.15 avec le fix de l’erreur ? Histoire de m’éviter à faire des contorsions dans tous les sens pour tout faire à la main ? :smiley:


#28

Je veux bien mais je ne peux pas avant dimanche voire lundi :confused:

C’est quand même curieux cette histoire, c’est comme si tu avais une version de TypeScript différente de celle qu’utilise le projet. :thinking:


#29

Bon ok ça ne marche pas, mon champs était déjà a true, j’ai resynchronisé sur un noeud qui contient les transactions g1.presles.fr:443 et c’est pareil, je n’ai que les DU visibles dans cesium et si je fais “afficher tout” par contre je n’ai que les transactions
mon noeud est jardin.foyerruralct.fr:10902
mon cesium est 1.3.6 mais c’est pareil depuis g1.duniter.fr

la valeur storage.transactions=true n’a aucun effet sur duniter-desktop


#30

Le paramètre indiqué est nécessaire mais pas suffisant. Un bug traîne, cf https://git.duniter.org/nodes/typescript/duniter/issues/1340

Une marge request a été proposée donc ça devrait alléger le travail pour @cgeek sur la correction de ce bug… On espère ! :slight_smile:


Liste des opérations indisponible
#31

Je viens d’installer la version arm et ça marche pour moi sur banana pi M2. Bien même.


#32

Bravo @bpresles :slight_smile:

@cgeek : as tu le temps de merger ca ? Ce serait chouette d’avoir une release 1.7 avec le tx/history qui fonctionne.
Car là je n’arrive plus à synchroniser mes noeuds v1.6 (Ca prends des jours, et ca fini sur un fork qui ne se résoud pas…). Autrement dit, plus personne n’a accès à un historique à jour. :frowning:


#33

@kimamila
Pour info, mon noeud g1.presles.fr tourne avec une version 1.7.14 avec le correctif de la merge request, donc avec le tx/history/[pub_key]/times/[start_time]/[end_time] qui fonctionne.


#34

@bpresles super, je confirmes que ca fonctionne.

En revanche c’est quoi comme machine que tu as ? Les perfs sont désastreuses…

Cf ces temps de requetes HTTP : Jusqu’à 18s pour avoir les sources de mon compte !


#35

@jardin En fait même si tu synchronises sur un noeud 1.6 ou un noeud 1.7 avec correctif sur le tx/history/.../times (comme le mien g1.presles.fr), si le tiens est en 1.7 sans le correctif (qui n’est pas encore mergé), alors tu ne verras que les DU sur la vue “Mes opérations” initiale, car un noeud 1.7 non corrigé ne sauvegarde pas les données de la colonnes time dans la table SQLite txs, lors de la synchro.


#36

C’est un simple Raspberry Pi 3, donc oui les perfs sont pas terrible, en particulier quand il calcul. Je vais migrer mon noeud sur un NUC Intel ce soir ou demain.


#37

@kimamila
Voilà, mon noeud tourne maintenant sur le NUC, donc bien plus performant. Ca devrait être beaucoup mieux :slight_smile:

Cela dit faudrait aussi que les autres noeuds aient le correctif :wink:


#38

Pour info : je manque de temps, mais j’essaie de regarder le correctif et, si possible, de le merger cette semaine et livrer une nouvelle version dans la foulée.

@jytou : je ne t’oublie pas !


#39

Pour ma part, je valide ce qui a été fait.
Je peux m’occuper de faire la livraison.
Mais, je ne refuse pas une review par une autre paire d’yeux.


#40

Comme toi, le correctif me semble correct et livrable sans risque.

Par contre la pipeline de la MR est bloquée : https://git.duniter.org/bpresles/duniter/-/jobs/19651