Certains ont dû exploser de joie en lisant le titre, je vous rassure vous ne rêvez pas, non nous ne somme pas le 1er avril (je vous ai vu regarder la date 
).
Bon, trêve de plaisanterie, pourquoi me suit finalement penché là-dessus:
Dans le cadre du débuggage de la ĞDev, j’ai eu besoin d’intégrer try-runtime en urgence, mais try-runtime est cassé dans la version de substrate qu’on utilise (on est sur la version de février, ça a été corrigé depuis). J’ai donc cherry-pick le correctif de parity sur notre fork du substrate, que j’ai dû adapter un peu car c’était basé sur un code plus récent, et dans cette tache j’ai dû gérer des histoires de dépendances optionnelles liées à wasmtime.
Je me suis alors souvenu que @tuxmain m’avais dit aux RML16 que le problème avec ARM venait plus de wasmtime (un interpréteur wasm utilisé pas substrate) que de substrate lui-même.
En travaillant sur try-runtime je ne suis rendu compte que wasmtime est optionnel, si on ne l’inclut pas, substrate utilise wasmi (un autre interpréteur wasm, qui lui conpile pour armv7).
Je me suis alors dit, c’est bizarre que @tuxmain est bloqué là-dessus, puisque wasmtime n’est normalement pas inclus si on compile pour une target qu’il ne supporte pas.
Ça m’a donné envie de re-regarder, j’ai tapé « substrate cross compile arm » dans mon moteur de recherche, et je suis tombé sur ce gist, créé par un dev de parity: Substrate Raspberry PI cross-compile build · GitHub
J’ai adapté ce gist à notre cas (on a besoin d’une version bien spécifique de rust), et ça à juste marché du premier coup 
J’ai donc testé mon binaire fraichement cross compilé sur mon raspberry pi 4… et erreur de GLIBC, mon rapsbian buster est trop vieux
J’ai upgade sur bulleyes, mais mon raspi ne voulait plus démarrer 
Le lendemain matin, ja’i fait une nouvelle install fraiche de bulleyes sur une autre carte SD formatée, et cetet fois mon rpi4 boot de nouveau !!
Je reteste donc le binaire de duniter-v2s, et à ma grande stupéfaction, ça semble fonctionner.
Depuis ce midi j’ai donc un nœud ĞDev mirroir sur mon rpi4 (pas exposé sur internet par contre, et c’est un nœud temporaire monté dans /dev/shm).
Pour ceux qui veulent tester, le binaire est disponible dans les release notes de duniter-v2S v0.1.0:
Svp ne testez que en nœud miroir pour le moment, et faites-moi part de vos retours 
Et voici les instructions de cross-compilation:
Attention: parity ne fournit pas de support officiel pour armv7, ni aarch64, donc ça peut très bien ne plus fonctionner dans de futures versions de subtrate.
Je ne peux pas m’engager à garantir la maintenante du support de armv7 dans la durée, mais on peut utiliser duniter-v2s sur armv7 tant que ça juste marche sans effort particulier de maintenance de notre part.
Gardez dont en tête qu’il est possible que l’on ne puisse plus utiliser duniter-v2s sur arm à l’avenir !
En tout cas tant que ça marche, je suis ok pour qu’on essaye de baser nos benchmarks des poids sur un raspberry pi 4 avec 4 Go de RAM et SSD usb3 (parce que c’est ce que j’ai).
Par contre, j’ai encone besoin d’être rassuré sur la capacité à s’en servir comme noeud authorité créant des blocs. Il faut aussi que je creuse ce qui ça donne en termes de monitoring, je me demande par exemple si ma stack prometheus/grafana est déployable sur un rpi 
Pour limiter les downtime, il faudrait avoir deux rpi, dont l’un contenant un backup du keystore de l’autre, et un sytème automatique qui injecte les sessions keys dans le 2ème rpi si le 1er ne répond plus.
Bref, il y a du boulot pour vérifier l’éventuelle viabilité des raspberry pour la production des blocs.
