Yeah ! 
et tu es bien sur le client 0.7.0, il faut que je le fasse aussi prochainement, j’ai démarré la GDev à partir d’un build Docker local.
Comment as-tu compilé pour ARM ?
Les scripts compilent pour armv7 et non aarch64 or une dépendance ne compile pas pour armv7.
D’ailleurs la toolchain n’est pas à jour dans docker/cross-arm.Dockerfile, je ne sais pas si c’est voulu.
J’ai réussi à compiler en musl sans Docker pour aarch64. (musl = exécutable statique portable) (téléchargeable ici)
Je vais faire un script dockerless.
Edit: par contre quand j’essaie de lancer le nœud j’ai un out of memory alors que j’ai plus de 4Go libre.
1 Like
La compilation pour arm64 ( ou armv8 ou aarch64) se fait via le Dockerfile.
1 Like
Super ! Il va y avoir pas mal de travail pour bien profiter de ce réseau, on pourra en discuter ce soir. Je vois que tu as publié les specs au format raw, mais il me manque les specs au format json pour démarrer l’indexeur.
Est-ce que tu aurais le bloc précis ? Ce serait intéressant comme info si jamais on doit debugger la migration. Et est-ce qu’il y avait des messages de warnings comme des certifications expirées ? Ce serait bien d’avoir le fichier g1-data.json aussi ^^
[edit] le g1-data pourrait être également publié ici : https://dl.cgeek.fr/public/backup-g1-duniter-1.8.7.tgz
1 Like
J’ai ajouté 8Go de swap et toujours OOM. Idem en retirant toutes les options optionnelles.
$ duniter --chain gdev700.json
2023-11-20 11:51:15 Duniter
2023-11-20 11:51:15 ✌️ version 0.7.0-c4773062fb5
2023-11-20 11:51:15 ❤️ by Axiom-Team Developers <https://axiom-team.fr>, 2021-2023
2023-11-20 11:51:15 📋 Chain specification: ĞDev
2023-11-20 11:51:15 🏷 Node name: tuxmain-polux-smith-gdev
2023-11-20 11:51:15 👤 Role: AUTHORITY
2023-11-20 11:51:15 💾 Database: ParityDb at /home/pi/.local/share/duniter/chains/gdev/paritydb/full
2023-11-20 11:51:15 ⛓ Native runtime: gdev-700 (duniter-gdev-1.tx1.au1)
Error: Service(Client(Backend("IO Error: Out of memory (os error 12)")))
Il y a plusieurs issues sur Polkadot/Substrate à propos d’OOM ou de fuites mémoires mais seulement dans certaines phases de consensus, et jamais avec ce message. J’essaie de trouver d’où ça vient mais il faudrait arriver à installer valgrind ou lldb en arm64 (les dépôts raspbian bullseye sont uniquement en armv7).
Edit: C’est dans sc_service::new_full_parts, à cause du backend db. D’ailleurs ne comprends pas pourquoi les builds armv7 marchent puisque parity-db ne supporte que x86-64 et aarch64.
Edit: Finalement ça marche après suppression de l’ancienne db. C’est tout de même un bug de parity-db.
Il y a un problème chez moi avec la commande pour purger la chaîne :
Dans le container, /var/lib/duniter pointe sur mon dossier de données contenant chains/gdev/paritydb/full et pas .local/share/duniter/chains/gdev/paritydb/full
docker exec -ti home_duniter_validator.1.nalo348fqf89gavs2joq40c48 duniter purge-chain --chain=gdev
Are you sure to remove "/var/lib/duniter/.local/share/duniter/chains/gdev/paritydb/full"? [y/N]: y
"/var/lib/duniter/.local/share/duniter/chains/gdev/paritydb/full" did not exist.
Dans telemetry, je ne vois que mes deux nœuds en 0.7.0. Et seul le validator avance sur une nouvelle chaîne de blocs, le RPC reste sur l’ancienne…
Le fichier a bien été produit mais j’ai oublié de l’ajouter aux assets de la release. C’est corrigé dans le code et corrigé dans la release.
Oui, les tables LevelDB du dump indiquent : #657075.
Tout le détail se trouve dans les logs de ce job.
Il est dans les fichiers de la release, ça fait partie des livrables 
Je préfère qu’il soit dans la release plutôt que les fichiers d’input, puisque précisément ce n’est pas un fichier d’entrée mais un fichier intermédiaire généré par la CI dans son processus de création de la release.
Tu as raison, je vais éditer mon post plus haut, il faut lancer avec l’option -d /var/lib/duniter :
purge-chain --chain=gdev -d /var/lib/duniter
3 Likes
Je ne comprends pas tout à fait comment fonctionne la CI, mais a priori on ne publie les specs qu’une fois (au démarrage d’un réseau) alors qu’on peut faire des publications de runtime régulièrement (pour mettre à jour le réseau). Est-ce que comme tu l’as fait ces fichiers seront ajoutés à chaque release de runtime ou uniquement au démarrage d’un nouveau réseau ?
Chouette, facile, à retenir en plus ><
- 12 certifications expirées (normal en 30 minutes)
- 5319 adhésions expirées, pas la peine de les afficher toutes, uniquement les adhésions qui n’étaient pas expirées au bloc de l’export
actual monetary_mass (8,457,743,556) and initial_monetary_mass (8,457,771,775) do not matchsoit 28219 de différence, ~ ok pour 282 Ğ1
Comme pour l’instant nous sommes susceptibles de redémarrer régulièrement le réseau, la CI builde tous les fichiers à chaque release. Ensuite libre à nous ensuite de mettre à jour les raw-specs dans le code (étape 3) puis de relivrer une image Docker du Client (étape 4, voir le détail des étapes).
Mais effectivement à terme, la plupart des fichiers ne seront plus à livrer.
DU réévalué maintenant et à une valeur de 14.00 ĞDev c’est correct selon les paramètres qui ont été choisis je suppose ?
Oui
1 Like
On ne s’est pas bien compris quand j’ai retravaillé sur le format du genesis de l’indexeur. Je n’utilisais pas la struct custom GenesisIndexerExport, mais les chainspecs au format json (mais pas raw). En gros j’utilisais la sortie de duniter build-spec (pas la sortie de duniter build-spec --raw ni la sortie optionnelle quand la variable d’environnement DUNITER_GENESIS_EXPORT est définie). Donc ce qu’il me manque là si je ne veux pas changer le format d’entrée de l’indexeur, c’est bien les specs au format json (pas raw).
Je pourrais peut-être partir des raw specs pour revenir au format “pas raw”, mais ce serait plus pratique de les avoir directement.
Ou alors je pourrais le re-générer si je connaissais le DUNITER_GENESIS_TIMESTAMP puisque ça devrait être déterministe, mais je ne connais pas cette valeur. Je pourrais essayer de rétro-ingénierer cette valeur, mais ce n’est pas très propre.
[edit] je pars pour l’instant de ce timestamp : 1700388302
Ce fichier est aussi sur la page de releases : fichier gdev.json.
Ok, en fait j’avais juste pas les yeux en face des trous ! Merci
On devrait pouvoir le recréer en faisant :
duniter build-spec --chain ./node/specs/gdev-raw.json 1> ./node/specs/gdev.json
mais curieusement ça donne un fichier raw 
Je me suis trompé, désolé, c’était plutôt #679340 (l’autre valeur, c’était le dump que j’avais fait le 31/08/2023).
Le n° de bloc, ainsi que son medianTime seront désormais consignés par py-g1-migrator.
Il me manquait l’information du bloc courant à au moment de la génération du Genesis pour pouvoir faire ce filtre. Étant donné le point ci-dessus, j’ai pu apporter un correctif.
La valeur précise peut se déduire des logs, notamment ceux qui indiquent “Building chain spec” :
2023-11-19 10:04:34 Building chain spec
Le timestamp précis serait donc plutôt autour de 1700384674 . Mais après quelques essais, je n’ai pas réussi à le reproduire localement. [edit] : ah oui, je n’ai pas testé avec le Runtime produit par srtool, c’est pour ça.
En tout cas, j’ai créé la MR!199 pour finaliser la release et merger les modifications apportées durant le processus. Je t’invite à la relire.
2 Likes
Super super ! On commence a avoir lissé pas mal de rugosités, je continue de travailler sur les indexeurs parce que j’en tirerai sûrement quelques retours et je ferai une relecture à froid plus tard, il n’y a pas d’urgence à merge ça.
J’ai implémenté ChangeOwnerKey dans Ğcli (en deux minutes, par copier-coller de link account), et ça me permet de me rappeler une autre raison pour laquelle on migrait les identités des forgerons dans le genesis :
gcli -S cesium identity change-owner-key -s "... mon mnemonic ..."
Cesium id:
Cesium password:
transaction submitted to the network, waiting 6 seconds...
Pallet error: SmithSubWot::NotAllowedToChangeIdtyAddress
Les forgeons n’ont pas le droit de migrer leur identité.
Donc je suis partagé entre deux solutions :
- révoquer mon adhésion forgeron, migrer mon identité, puis redemander l’adhésion forgeron
- devenir forgeron avec ma clé actuelle
L’inconvénient de la deuxième option est que je ne pourrai pas utiliser mon identité dans polkadotjs app, donc il faudra que j’implémente tout dans Ğcli. Je pense donc partir sur la première option.
2 Likes
Oui c’est la principale raison qui m’avait poussé à permettre le switch des adresse v1/v2 dans py-g1-migrator, pour que les smiths puissent utiliser gecko.
1 Like