OK, j’ai livré un v1.4.12, qui devrait corriger le problème du livrable -desktop.
EDIT: j’ai changé le titre du post, pour que la version soit la v1.4.12.
OK, j’ai livré un v1.4.12, qui devrait corriger le problème du livrable -desktop.
EDIT: j’ai changé le titre du post, pour que la version soit la v1.4.12.
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.
C’est bon ça roule sous Xubuntu 19.10 !
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
L’installation de la 1.4.12 a marché pour moi aussi.
Merci @kimamila, @bpresles, @matograine et @Vivakvo
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.
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):
"outputs": [ "100:2:SIG(d88fPFbDdJXJANHH7hedFMaRyGcnVZj9c5cDaE76LRN)", "900:2:SIG(HMMQ6n4sapK9wSASsXhrLYaGpCxtaqoyoPhXxudRckzS)"
Testé avec amour et obstination
Sinon :
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 :
Je vais regarder. As tu bien fait tes tests sur le même noeud Duniter ?
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
Bonjour,
Sur Debian 10, v1.4.12 desktop, extension Cesium+ activée
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é.
@kimamila @Moul les livrables ne sont plus disponibles, la dernière avec livrables est la 1.4.3 du 26 aout
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
.
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
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.