### Author:  [@Pini](https://forum.duniter.org/u/Pini)
#### Post date: [27 February 2023 16:53 UTC](https://forum.duniter.org/t/v2s-g1-data-migration-g1-migrator/9814/21 "2023-02-27T16:53:01Z")
J’essaie de comprendre un peu comment ça marche. Et il me manque une étape : comment sont extraites les données de duniter v1 ? J’ai tenté un `dex export-bc` mais ça ne produit pas ce qui est réclamé par le script python : il râle sur un fichier `ud_value.json` qu’il ne trouve pas.
---
### Author:  [@HugoTrentesaux](https://forum.duniter.org/u/HugoTrentesaux)
#### Post date: [29 May 2023 10:20 UTC](https://forum.duniter.org/t/v2s-g1-data-migration-g1-migrator/9814/22 "2023-05-29T10:20:16Z")
Il semble que `py-g1-migrator` n’ait pas produit de fichier `blocs.json` depuis le 9 mai alors qu’il continue bien à produire les autres fichiers. @poka est-ce que tu as une idée de pourquoi ?
[https://g1-migrator.axiom-team.fr/inputs/](https://g1-migrator.axiom-team.fr/inputs/)
```auto
blocs.json 09-May-2023 04:32 31764096
certs.json 29-May-2023 04:31 63171791
idty.json 29-May-2023 04:31 1507105
transactions_history.json 29-May-2023 04:31 82388659
ud_value.json 29-May-2023 04:31 45
wallets.json 29-May-2023 04:30 2675216
```
Et donc avec ces données le `./main.py` plante en cherchant le bloc d’expiration d’une certification :
```auto
Generate ĞTest genesis with up-to-date Ğ1 data
get ĞTest parameters...
dump ĞTest parameters...
parse identities...
Traceback (most recent call last):
File "/home/hugo/dev/py-g1-migrator/./main.py", line 50, in
identities_wallets = get_identities_and_wallets(opt1)
File "/home/hugo/dev/py-g1-migrator/lib/functions.py", line 82, in get_identities_and_wallets
cert_expire_on_bloc = date_to_bloc_number(blocs[str(cert['writtenOn'])], start_timestamp)
KeyError: '625701'
```
---
### Author:  [@poka](https://forum.duniter.org/u/poka)
#### Post date: [29 May 2023 14:28 UTC](https://forum.duniter.org/t/v2s-g1-data-migration-g1-migrator/9814/23 "2023-05-29T14:28:33Z")
En effet, c’est la [commande](https://git.duniter.org/tools/py-g1-migrator/-/blob/master/docs/generate_inputs_data.sh#L27) `./dex find main_blocks` qui crash au bout d’une vingtaine de secondes:
```auto
$ time yes|./dex find main_blocks -p medianTime -o json
Database opened in 0.085576 seconds.
Killed
real 0m12.755s
user 0m18.913s
sys 0m15.138s
```
Là où les autres commandes `dex` fonctionnent correctement.
Malheureusement dex ne me donne aucune info sur la cause de ce crash.
Je suis sur Duniter v1.8.6 sur cette machine.
J’ai recompilé duniter depuis la branche dev sur mon pc, ainsi que dex, ça synchronise actuellement, je verrai si j’ai le même soucis ici.
Si oui il faudra soit debuguer dex, soit exporter les données de ces blocs autrement.
* * *
edit:
Bon va savoir pourquoi, en passant l’option `-l 1000000` pour définir le nombre de ligne à exporter par dex, et bien la commande fonctionne correctement en exportant toutes les lignes…
A la base je souhaitais simplement isoler la ou les lignes posant problème, pour finalement me rendre compte qu’en voulant debuger, ça règle le problème… 🤷♂️
J’ai donc [mis à jours le script](https://git.duniter.org/tools/py-g1-migrator/-/commit/47a983fdf78e984d35a83a81ed3c3a6a6835a290) en conséquence pour contourner le soucis, qui semble donc venir de dex et non d’une db corrompu (ce que je redoutais).
[Les données](https://g1-migrator.axiom-team.fr/inputs/) sont donc à jours.
---
### Author:  [@HugoTrentesaux](https://forum.duniter.org/u/HugoTrentesaux)
#### Post date: [30 May 2023 00:48 UTC](https://forum.duniter.org/t/v2s-g1-data-migration-g1-migrator/9814/24 "2023-05-30T00:48:29Z")
Super, merci beaucoup pour ce fix, ça me permet de continuer à avancer sur le format du genesis gtest.
J’ai maintenant une POC qui respecte le bon format, il me reste deux champs à remplir :
```auto
"membership_expire_on": XXX,
"next_cert_issuable_on": XXX,
```
pour l’instant j’ai mis des valeurs bidon, et ça me permet de tester la cohérence du genesis en utilisant les tests implémentés en Rust : [node/src/chain\_spec/gtest\_genesis.rs · 5d8ba754739157d7697f6e6396f75c8a6b961fde · nodes / rust / Duniter v2S · GitLab](https://git.duniter.org/nodes/rust/duniter-v2s/-/blob/5d8ba754739157d7697f6e6396f75c8a6b961fde/node/src/chain_spec/gtest_genesis.rs#L362-L404)
Ça m’a permis de trouver une incohérence dans les données : les membres du comité technique sont censés être membres, mais dans `idty.json` on trouve :
```auto
{
"key": "D9D2zaJoWYWveii1JRYLVK3J4Z7ZH3QczoKrnQeiM6mx",
"value": [
{
"member": false,
"uid": "elois",
"writtenOn": 624084
}
]
},
```
alors que elois est censé être toujours membre de la Ğ1. Peut-être un problème en sortie de dex ?
---
### Author:  [@poka](https://forum.duniter.org/u/poka)
#### Post date: [30 May 2023 14:53 UTC](https://forum.duniter.org/t/v2s-g1-data-migration-g1-migrator/9814/25 "2023-05-30T14:53:04Z")
> [@HugoTrentesaux](#):
>
> alors que elois est censé être toujours membre de la Ğ1
Et bien non, les données sont correctes, @elois n’est plus membre de la Ğ1: [https://wotwizard.axiom-team.fr/fr/membres/profil?hash=4C4A05D4D36D5E374C8FC950247F34FDABF465272AAF591A7E49509C953B886E](https://wotwizard.axiom-team.fr/fr/membres/profil?hash=4C4A05D4D36D5E374C8FC950247F34FDABF465272AAF591A7E49509C953B886E)
Il n’a pas renouvelé son adhésion.
---
### Author:  [@HugoTrentesaux](https://forum.duniter.org/u/HugoTrentesaux)
#### Post date: [30 May 2023 18:33 UTC](https://forum.duniter.org/t/v2s-g1-data-migration-g1-migrator/9814/26 "2023-05-30T18:33:57Z")
Ah oui, en effet, j’avais regardé sur Cesium par habitude et je devais être sur un nœud désynchronisé 🤔. Merci ! Entre temps j’ai ajouté le champ `next_cert_issuable_on` mais il me reste à trouver comment obtenir la date d’expiration de l’adhésion avec `dex`.
---
### Author:  [@HugoTrentesaux](https://forum.duniter.org/u/HugoTrentesaux)
#### Post date: [5 June 2023 14:56 UTC](https://forum.duniter.org/t/v2s-g1-data-migration-g1-migrator/9814/27 "2023-06-05T14:56:33Z")
Choses à faire dans `py-g1-migrator` avant de pouvoir lancer une ǦTest:
- récupérer l’information de la `initial_monetary_mass` pour la mettre dans le genesis
- remplir la valeur du champ `membership_expire_on` avec le bloc d’expiration de l’adhésion
- remplir la valeur du champ `next_cert_issuable_on` avec le numéro de bloc de la prochaine certification qu’une identité peut émettre
- utiliser les mêmes index que Duniter +1 ou DataJune (exemple [https://files.datajune.coinduf.eu/global/pseudos.txt](https://files.datajune.coinduf.eu/global/pseudos.txt) avec numéro de ligne = identity index)
---
### Author:  [@HugoTrentesaux](https://forum.duniter.org/u/HugoTrentesaux)
#### Post date: [5 July 2023 10:05 UTC](https://forum.duniter.org/t/v2s-g1-data-migration-g1-migrator/9814/28 "2023-07-05T10:05:21Z")
Les points ci-dessus sont quasiment terminés dans ma branch [hugo-gtest](https://git.duniter.org/tools/py-g1-migrator/-/commits/hugo-gtest). Il reste à relire et à corriger les points suivants :
- corriger date de réévaluation du DU
- décider si l’heure du premier DUv2 est un problème ([Date de création du DU](https://forum.duniter.org/t/date-de-creation-du-du/11375))
- récupérer l’adresse de la trésorerie pour déplacer la monnaie ignorée
- utiliser le bon préfixe ss58 pour les addresses
- comprendre pourquoi la masse monétaire n’est pas strictement égale à la somme des comptes et corriger (cf [Quantité de monnaie sur Duniter](https://forum.duniter.org/t/quantite-de-monnaie-sur-duniter/11373))
- valider que les conversions timestamp → nombre de blocs se font côté py-g1-migrator (implique un léger décalage de timing sur les expirations de certification par exemple, cf utilisations de `date_to_bloc_number`)
---
### Author:  [@cgeek](https://forum.duniter.org/u/cgeek)
#### Post date: [31 August 2023 16:01 UTC](https://forum.duniter.org/t/v2s-g1-data-migration-g1-migrator/9814/29 "2023-08-31T16:01:19Z")
> [@Pini](#):
>
> Et il me manque une étape : comment sont extraites les données de duniter v1 ?
Oui le README ne focalise pas du tout dessus : mais tout se trouve dans le fichier [export-from-v1.8.sh](https://git.duniter.org/tools/py-g1-migrator/-/blob/master/export-from-v1.8.sh?ref_type=heads#L103-114).
En tout cas merci @poka pour cet outil, ça me facilite grandement la tâche.
[Previous page](https://forum.duniter.org/t/v2s-g1-data-migration-g1-migrator/9814.md?page=1)