Et le noeud 1.8.7-rc1 a émis plusieurs blocs valides
Pour le moment tout baigne
Et le noeud 1.8.7-rc1 a émis plusieurs blocs valides
Pour le moment tout baigne
je teste une qemu arm alors, d’ abord buster puis si ça passe pas, les nouveaux nodes bulleyes
edit buster ko manque node v10; bulleyes idem
Bon, après quelques tests je penses que j’ai un soucis, sur la 1.8.7-rc1 :
L’historique de transaction est vide Seule les DU sont visibles…
donc : ne mettez pas vos noeuds à jour, car il faudra sans doute refaire une synchro…
Mince ! Ayant laissé tomber la version Yunohost qui me posait trop de problèmes de synchronisation, je viens d’installer ce matin ta version 1.8.7-rc1 et c’est en train de synchroniser… bon un coup dans l’eau, on verra bien avec la prochaine version corrigée. Merci pour ton travail Amicalement
J’ai cette erreur lorsque je démarre Duniter compilé moi-même :
(node:2602634) Warning: Accessing non-existent property 'padLevels' of module exports inside circular dependency
(Use `node --trace-warnings ...` to show where the warning was created)
Nodejs v16, Rust 1.70.
Dans quelle branche es tu ?
La branche dev (1.9) ou release/1.8
?
Attention a bien prendre la version nodejs 10
Sinon, j’ai commencé une branche pour NodeJS 20 (feature/node-20
) à partir de release/1.8
, mais tous les tests ne passent pas encore. J’ai notamment un soucis avec la migration des Websocket vers “ws” (l’ancienne lib n’est plus maintenu)
Voila @Pini, j’ai corrigé les problèmes de stockage des TXs. La branche release/1.8
est donc prête !
As tu le temps de faire la release ?
EDIT: je fais la lancer directement, finalement.
Est-ce qu’il faut resynchroniser après la mise à jour ?
J’ai essayé de lancer le CI publish
mais ca plante également : publish (#109045) · Jobs · nodes / typescript / duniter · GitLab
J’ai l’impression que ce script essaie de pousser des choses sur le wiki associé au projet Gitlab, mais cette fonctionnalité est désactivée dans les settings :
EDIT : Ça se confirme : si j’active le wiki dans la conf du projet et que je relance le job, l’erreur 403 (accès non autorisé) est remplacée par une 404 (page non trouvée).
Je propose de désactiver cette partie du script de release.
Depuis une certaine version de GitLab, l’API v4 de GitLab est maintenant uniquement accessible via token. Je pense que c’est le problème. Désactiver ce job peut-être une solution. Ce job n’a pas été lancé pour les tags v1.8.{5,6}
.
Il y a bien un toen défini et utilisé à cette occasion dans le script. Je penche plutôt pour l’hypothèse wiki désactivé sans mise à jour du script.
Mon problème est qu’à partir du commit (j’ai fait un bisect) fix(1442): add new computed (and indexed) columns 'issuer' and 'recipient' in... (d7790042) · Commits · nodes / typescript / duniter · GitLab
mon nœud démarre mais crashe immédiatement avec systemd
ou directement avec ./bin/duniter start
.
Je réitère cette question :
Car ça semble être une incompatibilité dans la bdd.
Oui le script de migration que j’avais fait était mauvais, sur une BDD existante.
Je l’ai corrigé (ticket sur le TX storage qui ne fonctionnait pas) cf fichier MetaDAL.
J’ai trouvé un axe pour améliorer grandement les temps de synchro. Je teste ça ce matin.
J’ai fait une synchro, elle a duré environ 1h40
All done in 5821.352 seconds.
Le redémarrage systemd n’a pas pu avoir lieu hier soir, car pas de mot de passe.
Un redémarrage ce matin et ça s’est synchronisé immédiatement
super !
J’ai trouvé d’autres optimisation, que j’ai pushé sur release/1.8
. En résumé, les derniers blocs de la synchro étaient traités plus longuement, à cause d’élagage d’index qui peuvent être déporté uniquement sur le tout dernier bloc. Ce que j’ai fait.
Bon ca changera pas grand chose non plus… c’est juste histoire de finir mes modifs avec un code propre.
=> une release 1.8.7-rc3 est en cours.
J’ai également commencé à faire converger le code de la branche dev
. Je vous tiens au courant pour celle-ci dans un autre post.
@Pini, @Moul dites moi si la dernière RC fonctionne bien chez vous. On va pouvoir faire la release finale je penses.
On a ton accord @cgeek ? Je sais pas si tu as eu le temps de regarder mes derniers commit (un peu fouillis désolé, mais le temps me manque maintenant, mes autres engagements me rappelle à l’ordre)
Ça fonctionne chez moi, pas de problème pour l’instant.
Je ne vais pas regarder, je préfère qu’on livre la version et que l’on avise ensuite. Comme il n’y a pas de changement de protocole ça devrait quand même bien se passer. Et nous ne sommes pas tous obligés de nous mettre à jour.