Hop, quelques nouvelles : nous sommes très proches de relancer la ĞDev, je suis en train de la lancer localement et de vérifier que mes développements pour industrialiser le lancement d’une nouvelle monnaie n’ont pas causé de régression.
A vue de nez, je dirais que d’ici le week-end du 4 et 5 novembre nous aurons à nouveau une ĞDev en fonctionnement. Peut-être avant si tout se passe bien 
Nous sommes le 5 Novembre, finalement ce ne sera pas ce WE 
Mais je peaufine le processus de livraison dans la CI, nous sommes sur les derniers mètres.
Vous pouvez déjà commencer à potasser votre installation de nœud, notamment ceux qui voudraient faire partie des autorités online dès le lancement (créateurs de blocs). J’en ferai partie.
Si vous connaissez déjà vos clés de session, vous pouvez les déposer dès maintenant sur ce fil, je les inclurai dans la foulée dans le fichier gdev.json. mais je ferai un rappel pour le lancement officiel.
Je déplace dans un nouveau sujet “ĞDev 700” car le Runtime 600 existe déjà en tant que tag Git, et que mes travaux sur Industrialize Releases production (#125) · Issues · nodes / rust / Duniter v2S · GitLab mèneront plutôt à un nouveau réseau ĞDev, rebooté.
Les tickets/MR sont bien alignés avec ce Runtime à venir.
Point sur les tickets qu’il faut réaliser avant de relancer la ĞDev.
Je vous propose d’utiliser ce board centré sur la milestone runtime-700 et les tickets ouverts : Dashboard runtime-700
Note : j’essaierai de mettre en place ces points de suivi de façon régulière désormais, afin de se donner à tous un peu plus de visibilité sur l’avancement du projet Duniter V2.
Il ne reste que deux évolutions non obligatoires pour relancer la ĞDev, il n’y a plus de blocage à ce niveau-là. Il reste par contre deux anomalies qu’il faudrait qualifier @HugoTrentesaux pour savoir si celles-ci sont critiques et doivent décaler le reboot de la ĞDev.
#122 CI/Docker: only publish images for active networks
Evolution de confort, non nécessaire pour le runtime-700. Permet de rationaliser le déploiement des images Docker qui n’ont pas souvent besoin d’être mises à jour.
#134 Add a ĞTest build job on build stage
Là aussi, évolution de confort au niveau de la CI. Non nécessaire pour le runtime-700 mais qui peut être réalisée avant le reboot de la ĞDev.
#129 Reached unreachable at block 1000
A qualifier. Possiblement non gênant pour le reboot de la ĞDev.
#135 Arithmetic underflow in balance transfer integration test
A qualifier. Peut-être non bloquant pour le reboot de la ĞDev.
runtime-701Afin de ne pas bloquer le reboot de la ĞDev, j’ai pris l’initiative de déplacer les autres tickets de runtime-700 vers runtime-701.
J’ai réalisé ce déplacement sur la base des priorités affectées aux tickets (>= P5-sometimesoon) ou à défaut en lisant en détail le ticket.
Les quatre tickets ci-dessus ayant été traités, a priori nous sommes prêts pour relancer la ĞDev.
Je vous invite à relire les fichiers qui paramètrent la monnaie :
gdev.json : pour le paramétrage du Genesisgdev_client-specs.json : pour le paramétrage du clientPour le comité technique et les smiths, nous avons actuellement @Pini @Moul @HugoTrentesaux @tuxmain @1000i100 @vit et @cgeek, est-ce bon pour vous ?
A priori pour le démarrage je me propose de me lancer en solo parmi les autorités online, donc seulement mes sessions_keys de renseignées dans le fichier gdev.json puis vous me rejoignez au fur et à mesure.
Il faut aussi décider de la sudo_key, pour l’instant j’ai laissé celle par défaut.
Il me semble que first_ud et first_ud_reeval sont des timestamps. Dans ce cas les valeurs actuelles sont invalides, donc il faut soit choisir des timestamps une fois que tu sais quand tu vas la lancer, soit laisser None pour les définir à une période après le lancement.
Ça aiderait d’ajouter des commentaires avec les unités (seconde, bloc, session) parce que là c’est dur à lire (les commentaires sont dans le code Rust mais comme il y a 15 structs différentes pour les configs c’est long à retrouver).
Je prépare une branche pour changer ces fichiers vers le format YAML, et je vais commenter les valeurs.
gdev, sauf pour first_ud qui est en timestamp comme dit tuxmaing1-data, ce sera pratique d’avoir le bloc v1 précis auquel les données ont été extraitesJ’ai initié la MR!195. Il y a déjà la conversion YAML et quelques commentaires.
Comme je ne vais pas avoir le temps d’y toucher avant ce soir, je vous invite à y contribuer directement si vous souhaitez faire avancer le sujet.
Vous pouvez tester avec :
cargo run -- build-spec --chain=gdev_live --raw > gdev-raw.json
L’avantage de cette commande est qu’elle affiche des logs d’informations sur le paramétrage, notamment en convertissant les valeurs en jours pour bien se rendre compte de ce que l’on fait :
2023-11-17 22:51:55 currency parameters:
- existential deposit: 1 ĞD
- currency decimals: 2
- membership validity: 73 days
- certification period: 24 hours
- certification validity duration: 146 days
- smith membership validity: 73 days
- smith certification validity: 146 days
- required certifications: 3
- smith required certifications: 3
- max certifications by issuer: 100
- money growth rate: 4.88% every 24 hours
- UD creation period: 4 hours
- distance percent of required referees: 80%
- distance max depth: 5
Le bootnode par défaut est mon nœud gdev.cgeek.fr.
Les données Ğ1 sont celles d’aujourd’hui 08h15 environ.
Le build ARM64 ne semble pas être passé, je relance.
Je n’ai pas pu tester l’image Docker AMD64, je vous laisse ce soin car je n’ai déjà plus de temps pour aujourd’hui (cc @Pini si tu passes par là pour vérifier).
Édit : les images Docker ne sont pas fonctionnelles, nous allons les reconstruire.
Edit 2 : c’est bon ! les images AMD64 et ARM64 fonctionnent toutes les deux, j’ai pu tester :
docker run --rm -it -e DUNITER_CHAIN_NAME=gdev duniter/duniter-v2s-gdev
[...]
2023-11-19 16:22:01 ***** Duniter has fully started *****
2023-11-19 16:22:06 ✨ Imported #3420 (0x930b…f085)
2023-11-19 16:22:06 💤 Idle (2 peers), best: #3420 (0x930b…f085), finalized #3417 (0x810b…2370), ⬇ 231.5kiB/s ⬆ 4.2kiB/s
2023-11-19 16:22:11 💤 Idle (2 peers), best: #3420 (0x930b…f085), finalized #3418 (0x3674…5b89), ⬇ 1.1kiB/s ⬆ 0.7kiB/s
2023-11-19 16:22:12 ✨ Imported #3421 (0xfa18…82d8)
Bon, pour l’instant je suis tout seul, je vous attend
Ne faut-il pas spécifier ton bootnode à cette ligne pour qu’on puisse se connecter à ton client ?
Je n’ai peut-être pas configuré correctement mon instance, voici ce que j’ai :
2023-11-19 17:23:19 💤 Idle (0 peers), best: #64 (0x21cd…21ec), finalized #0 (0xc234…a857), ⬇ 0 ⬆ 0
2023-11-19 17:23:19 ❌ Error while dialing /dns/telemetry.polkadot.io/tcp/443/x-parity-wss/%2Fsubmit%2F: Custom { kind: Other, error: Timeout }
De fait, je ne suis également pas visible dans la télémétrie. J’arrête l’instance pour l’instant.
C’est déjà le cas, sur la branche release/runtime-700.
Aussi, si tu réutilises une ancienne instance, il faut que tu supprimes les anciennes données auparavant. Par exemple avec :
docker run --rm -it --entrypoint duniter duniter/duniter-v2s-gdev purge-chain --chain=gdev -d /var/lib/duniter
Quant à la télémétrie, d’abord il faut t’assurer de voir des logs avec un n° de bloc supérieur à 4,000 (désormais, vu que la chaîne avance). Ensuite, et seulement ensuite, se montrer patient car la télémétrie affiche facilement le message :
❌ Error while dialing /dns/telemetry.polkadot.io/tcp/443/x-parity-wss/%2Fsubmit%2F: Custom { kind: Other, error: Timeout }
Qui signifie simplement que le service de télémétrie est surchargé. Mais ça finit par se décanter.
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.
La compilation pour arm64 ( ou armv8 ou aarch64) se fait via le Dockerfile.
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
