Cesium > Nouvelle version 1.4.12 (pré-version)

OK, j’ai livré un v1.4.12, qui devrait corriger le problème du livrable -desktop.

@jytou, @bpresles : à vous ! :slight_smile:

EDIT: j’ai changé le titre du post, pour que la version soit la v1.4.12.

3 Likes

Idem avec la 1.4.12. Chose étrange, une tx est passée, que Cesium refusait hier, mais les suivantes sont refusées de la mëme manière.

Je suis éloigné de mon ordi pour quelques jours, je retesterai le blocage de comptes.

Edit-et le logo est toujours un atome d’hydrogène sur Android.

1 Like

Merci @kimamila je confirme que la 1.4.12 s’installe correctement sur ubuntu 18.04 LTS :slight_smile:

1 Like

C’est bon ça roule sous Xubuntu 19.10 !

2 Likes

En fait, ce message indique que des sources de monnaie existes, mais qu’elles ne sont pas encore utilisables. Il s’agit des sources avec condition de dévérouillage complexe.
Le message devra etre adapté pour que ce nouveau cas soit intégré, mais il n’y a pas d’urgence.

En gros, tu as dépensé tout ce que tu pouvais dépensé, par Cesium (sources sans avec condition = SIG() ). Mais ce n’est pas bloquant.

Voilou

1 Like

L’installation de la 1.4.12 a marché pour moi aussi.

Merci @kimamila, @bpresles, @matograine et @Vivakvo :slight_smile:

Le lien vers la v1.4.12 ne fonctionne pas, j’ai la v1.4.10 en plus récente, et la v1.4.3 juste avant.

lien : https://github.com/duniter/cesium/releases

Ca m’étonne, car j’ai pourtant téléchargé la v1.4.12 il y a qques jours. J’aimerais bien vérifier mes dires, quelqu’un peut-il me donner le bon lien ? Je vous remercie.

J’ai peut-être fait une mauvaise manipulation en voulant mettre à jour cesium_ynh.
Ça devrait bon maintenant.

1 Like

Que nenni. Il s’agit d’utiliser le dernier Backchange du compte, qui n’est pas vide. Ce comportement n’apparaît pas sur la v1.4.6. Et je viens de vérifier, ce n’est pas lié à des conditions de lock.

Peut-être que ce bug touche toutes les sources Backchange, mais je ne sais pas trop comment tester ça. J’ai essayé, vraisemblablement le souci arrive lorsqu’il y a une unique source non consommée pour ce compte, et que c’est un backchange.
Ce comportement apparaît tant sur la version de bureau (Debian GNUnux 10) que sur ordiphone androide.

Pour reproduire (je donne le compte que j’ai utilisé comme exemple, utilisez-en un autre):

  1. créer un compte bidon, par exemple HMMQ6n4sapK9wSASsXhrLYaGpCxtaqoyoPhXxudRckzS : ID/MDP 33333333
  2. virer 1000 GT sur ce compte, d’un coup. Il y a donc une source unique avec SIG(HMMQ…) comme unlock.
  3. connecté comme HMMQ…, faire un virement de 100GT. Il y a donc un backchange de 900GT, le compte n’est pas vide comme on peut le voir au Bloc #464 392 :
  "outputs": [
  "100:2:SIG(d88fPFbDdJXJANHH7hedFMaRyGcnVZj9c5cDaE76LRN)",
  "900:2:SIG(HMMQ6n4sapK9wSASsXhrLYaGpCxtaqoyoPhXxudRckzS)"
  1. éventuellement attendre que le virement passe en blockchain si vous voulez vraiment être sûr.e.
  2. refaire un autre virement.
  3. TADAA ! Cet autre virement est refusé, avec l’erreur indiquée plus haut. :fireworks:
  4. Pour renvoyer un nouveau virement, il faut fermer et rouvrir l’app Cesium. Même déconnecter/reconnecter ne suffit pas. Et le problème se reproduit après un virement.

Testé avec amour et obstination :smiling_face_with_three_hearts::crazy_face:

Sinon :

  1. Cesium s’installe bien sur Debian 10 \o/
  2. Le logo de Cesium sur androide est un atome d’hydrogène (ce qui chagrine Mendeleiev, vous en conviendrez)
4 Likes

Merci pour tes tests.
Cependant, je ne comprends pas : dans le cas que tu indique, il n’y a plus de condition de déverrouillage complexe, sis ? Si non, il s’agit d’un comportement que nous devions déjà avoir avant.
Et lerreur semble ainsi justifié : le nouvelles sources n’étant pas encore validées en BC, elle ne peuvent pas etre consommée de suite. Logique non ?
En d’autres termes, il manque de change. Ca me parait un soucis différent.

Non effectivement, il n’y a plus de conditions de déverrouillage complexes. Mais ce comportement n’apparaît pas dans la v1.4.6, je t’invite à le constater par toi-même.

Non, justement, je reçois l’erreur même après que les sources ont été enregistrées en BC. Je n’ai pas attendu le délai de 6 blocs. Mais encore une fois, ce comportement est spécifique aux v1.4.11 et 12 (je n’ai pas testé la 10).

D’autre part, en règle générale Cesium n’attend pas que les sources soient enregistrées, je crois. Je crois avoir déjà vu des tx chaînées dans un bloc, émises par Cesium.

Comme relancer Cesium permet de faire un unique nouveau virement, je soupçonne que lorsque je dépense la dernière source valide, cette info est enregistrée temporairement, alors même qu’un backchange valide revient bien au compte.

De mon point de vue, ce souci apparaît après le debug du blocage par des sources complexes, donc ça semble lié. Mais différent,oui.

edit - d’autre part, c’est un souci différent, mais très gênant pour :

  • celles et ceux qui utilisent des fonds Ğmixés uniquement en dépense : un seul versement sur le compte, et ensuite il faut redémarrer Cesium entre chaque nouveau versement
  • les curieuses et curieux qui découvrent la ML et ont reçu un premier don. Iels devront passer leur premier Ğmarché à relancer Cesium à chaque paiement ? A mon avis, iels lâcheront l’affaire bien avant de demander à être certifié.e.s
1 Like

Je vais regarder. As tu bien fait tes tests sur le même noeud Duniter ?

1 Like

G1-test.cgeek.fr, oui.

Bonjour Benoit,

Pour la partie espéranto, cette version corrige bien les dates absolues, mais il reste des problèmes d’affichage concernant les dates relatives (ou durées) + la licence déjà traduite en espéranto mais qui n’apparaît qu’en anglais (ce doit être la licence par défaut).

Pour corriger cela, il faudrait fusionner les corrections que j’ai réalisées dans les merge requests 596 (2 fichiers js) à 599 (licence au format .md).
Voir sur git.duniter.org : Merge requests · clients / Cesium-grp / Cesium · GitLab

A propos de fusion de corrections, je me demandais s’il valait mieux faire des merge requests sur git.duniter.org ou des pull requests sur github (GitHub - duniter/cesium: Webapp and Smartphone client for Duniter network).

Merci d’avance pour tes conseils, et bien sûr pour la prise en compte de mes dernières corrections.
Yves

3 Likes

Bonjour,

Sur Debian 10, v1.4.12 desktop, extension Cesium+ activée

  • les graphes de statistiques de la monnaie n’aparaissent pas
  • le graphe des statistiques des transactions reste « en attente » avec le logo qui tourne
  • le graphe d’historique d’un compte n’apparaît pas
  • les prix sont indiqués en « undefinedĞ1 »

Par contre, ceci ne se produit pas sur la version .zip.
Quelqu’un.e d’autre que moi reproduit-iel sous Debian 10 ? Ou bien c’est un souci de connectivité local ?

edit - ce bug ne se reproduit pas, désolé.

1 Like

@kimamila @Moul les livrables ne sont plus disponibles, la dernière avec livrables est la 1.4.3 du 26 aout :confused:

La 1.4.12 est encore passée en draft. Cette fois ça ne devrait pas être moi. J’y ai pas touché depuis.
Je la repasse en pre-release.

2 Likes

Bonsoir,.
Au cas où le ticket soit passé inaperçu sur gitlab, je signale ici que le logo de l’appli mobile Cesium a changé depuis la version 1.4.10, et je me demandais si c’était normal.
Voir le ticket https://git.duniter.org/clients/cesium-grp/cesium/issues/852.
Merci

3 Likes

Tu n’est pas le seul dans ce cas : @matograine a soulevé le problème un peu plus haut :

1 Like

Bonjour,
Je viens de tester la version 1.4.12 aux RML 14 à Toulouse, notamment pour effectuer des transactions avec mon téléphone, et je me suis aperçu d’un problème très gênant : le scanner de QR-code a disparu.
J’ai donc dû réinstaller rapidement la version 1.3.11 pour bénéficier de cette fonctionnalité qui me semble devenue presque indispensable.
Dans un second temps, j’ai testé toutes les versions depuis la 1.3.11 et visiblement le scan a disparu depuis la version 1.4.3.
J’espère que cette fonctionnalité pourra être remise avant de mettre une nouvelle version de Cesium en opérationnel. Je vais aussi faire un ticket sur gitlab.

4 Likes