Une nouvelle version du logiciel est disponible au téléchargement :
Cette version corrige un bug majeur détaillé dans ce fil : Ğ1 en forks à partir du bloc #206587 qui faisait que la Ğ1 subissait de très nombreux forks ces derniers jours.
Pour profiter pleinement de cette version, il est nécessaire de resynchroniser votre nœud.
@jytou : une version ARM + Windows stp ?
Je vais de ce pas mettre à jour les nœuds 1.7 (g1.duniter.org, remuniter, etc.)
Est-ce normal qu’énormément d’événements passés est disparu des comptes ? paiement et certif en attente par ex
Les événements des deux dernières semaines, oui c’est fortement possible. Surtout cette semaine.
Par contre comme il n’y a pas aujourd’hui d’outil qui les consigne tous, on ne peut pas savoir précisément lesquels.
Oui, je lance ça de suite… j’ai justement passé un peu de temps aujourd’hui à remonter mon vagrant/virtualbox et m’assurer qu’il était fonctionnel (j’ai réinstallé ma machine récemment…).
Re synchro en cours pour moi aussi
Pour le soucis des transactions invisible j’ai observé qu’en redescendant césium en 1.6 elles semblent redevenir visibles.
J’ai un souci avec l’interface pour éditer la release note : le bouton « Attach a file » ne fonctionne pas… je clique dessus… et rien. Je vous assure, j’ai rien bu ce soir. Juste de l’eau.
Edit : j’ai un plus gros problème, la release windows a planté, alors que celle que j’ai faite de la 1.7.11 cet après-midi est très bien passée. Je la relance.
Bravo @cgeek ! et grand merci !
TU veux dire “redescendre Duniter en v1.6 .” 
Oui, en 1.7, il faut ajouter l’option --store-txs sinon l’historiques des transactions n’est pas conservé.
Eh bien j’ai synchro mon nœud avec cette option cet après-midi et je ne vois toujours rien, mais il était en 1.7.11, je sais pas si ça joue. Bon là je le resynchro après MÀJ (avec l’option), à suivre.
J’étais en 1.7.11 cet après midi
Avec césium 1.2.9 pas de transactions Visibles
Avec 1.2.6 transactions ok
7 messages ont été scindés en un nouveau sujet : Impossible d’uploader une release sur GitLab
Release Windows à nouveau plantée. @cgeek Est-ce que quelque chose a changé dans le processus de release ?
En attendant, la release arm est dispo, je suis en train de la tester.
Elle ne marche pas, il manque des choses à l’intérieur, je vais investiguer…
@cgeek mauvaise nouvelle, les releases arm et windows plantent.
Pour la release windows, j’en ai fait une 1.7.12 avec succès cet après-midi. Mais là en 1.7.14, le binaire n’est même pas généré. Le problème étant que mon terminal ne stocke pas assez de lignes (10.000, c’est pas assez) pour que je voie s’il y a de grosses erreurs dans le build. Il doit bien y avoir des logs vagrant quelque part mais je n’arrive pas à les trouver.
Pour l’arm, le binaire est généré, mais il manque des choses à l’intérieur. Au démarrage, on obtient l’erreur suivante :
module.js:557
throw err;
^
Error: Cannot find module 'wotb'
at Function.Module._resolveFilename (module.js:555:15)
at Function.Module._load (module.js:482:25)
at Module.require (module.js:604:17)
at require (internal/module.js:11:18)
at Object.<anonymous> (/opt/duniter/app/lib/wot.js:15:14)
at Module._compile (module.js:660:30)
at Object.Module._extensions..js (module.js:671:10)
at Module.load (module.js:573:32)
at tryModuleLoad (module.js:513:12)
at Function.Module._load (module.js:505:3)
module.js:557
throw err;
^
Est-ce que tu aurais changé quelque chose d’évident dans le process de release qui ferait que certaines choses ne se retrouvent pas dans le .deb final ? Je ne vois pas d’erreur flagrante dans la console.
Edit : je vois que pour la version Windows on télécharge node 9.5. Or je suis resté en 9.4 pour la version arm. Un truc à essayer…
Edit 2 : dans le build windows que je suis en train de surveiller, je vois passer ça à répétition :
default: node-pre-gyp ERR! UNCAUGHT EXCEPTION
default: node-pre-gyp ERR! stack Error: duniter package.json is not node-pre-gyp ready:
default: node-pre-gyp ERR! stack package.json must declare these properties:
default: node-pre-gyp ERR! stack binary.module_name
default: node-pre-gyp ERR! stack binary.module_path
default: node-pre-gyp ERR! stack binary.host
default: node-pre-gyp ERR! stack at validate_config (C:\Users\vagrant\AppData\Roaming\npm\node_modules\node-pre-gyp\lib\util\versioning.js:220:15)
Il me semble que ça arrivait déjà avant, mais je suis pas 100% sûr. Le problème de la build windows étant que même quand tout fonctionne il y a des erreurs node partout en rouge dans la console. Ah, mais si à la fin y a une petite ligne « ok » quelque part (en rouge, elle-aussi, sinon c’est pas drôle, vert ça pourrait laisser penser que c’est ok en fait), c’est que tout s’est bien passé en fait. 
J’adore.
Edit 3 : une autre erreur dont je ne sais pas si elle se produisait avant ou pas :
default: C:\Users\vagrant\duniter\app\lib\common-libs\index.ts
default: C:\Users\vagrant\duniter\app\lib\common-libs\manual-promise.d.ts
default: fs.js:663
default: return binding.open(pathModule.toNamespacedPath(path),
default: ^
default: Error: ENOENT: no such file or directory, open ‘C:\Users\vagrant\duniter\package.json’
default: at Object.fs.openSync (fs.js:663:18)
default: at Object.fs.readFileSync (fs.js:568:33)
default: at Run.parseOpts [as parseArgv] (C:\Users\vagrant\AppData\Roaming\npm\node_modules\node-pre-gyp\lib\node-pre-gyp.js:136:36)
default: at Object. (C:\Users\vagrant\AppData\Roaming\npm\node_modules\node-pre-gyp\bin\node-pre-gyp:24:6)
default: at Module._compile (module.js:660:30)
default: at Object.Module._extensions…js (module.js:671:10)
default: at Module.load (module.js:573:32)
default: at tryModuleLoad (module.js:513:12)
default: at Function.Module._load (module.js:505:3)
default: at Function.Module.runMain (module.js:701:10)
default: ERROR: Le fichier sp‚cifi‚ est introuvable.
default: nwjs-v0.28.1-win-x64.zip
default: System ERROR:
default: Le fichier sp‚cifi‚ est introuvable.
default: Fichier introuvable - *
default: C:\Users\vagrant\duniter\app\lib\common-libs\manual-promise.js
default: C:\Users\vagrant\duniter\app\lib\common-libs\manual-promise.js.map
Il y a aussi ça :
default: npm ERR! code ELIFECYCLE
default: npm ERR! errno 2
default: npm ERR! duniter@1.7.14 prepublish:tsc
default: npm ERR! Exit status 2
default: npm ERR!
default: npm ERR! Failed at the duniter@1.7.14 prepublish script.
default: npm ERR! This is probably not a problem with npm. There is likely additional logging output above.
default: “Ajout du module 1/1 (duniter-ui)…”
default: npm ERR! A complete log of this run can be found in:
default: npm ERR! C:\Users\vagrant\AppData\Roaming\npm-cache_logs\2019-03-29T21_39_59_939Z-debug.log
Tu ne peut pas, il faut ouvrir un ticket pour demander a ce que ce réglage soit implémenté dans l’interface graphique 
Je me demande quand même si le passage à node 9.5 ne génère pas les problèmes des releases arm et windows. Dans la release arm j’ai
npm ERR! code ELIFECYCLE
npm ERR! errno 2
npm ERR! duniter@1.7.14 prepublish:tsc
npm ERR! Exit status 2
npm ERR!
npm ERR! Failed at the duniter@1.7.14 prepublish script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.
npm ERR! A complete log of this run can be found in:
npm ERR! /home/pi/.npm/_logs/2019-03-29T22_16_24_085Z-debug.log
@cgeek j’essaie de trouver la source de mon erreur de release, mais je galère un peu. C’est la dernière erreur npm qui me paraît être la cause. J’ai npm 5.6.0. Est-ce que c’est la bonne version ?
Je n’ai rien changé concernant ces modules, ils sont restés tels quels.
Pour mes versions (poste de dev) :
$ npm -v
5.6.0
$ node -v
v9.11.2Tu peux modifier le fichier de configuration ~/.config/duniter/duniter_default/conf.json et renseigner le bloc comme suit :
"storage": {
"transactions": true,
"wotwizard": false
}
Ne fais pas attention à wotwizard, c’est du spécifique pour cet outil. Mais il te faut le champ storage.transactions à true pour activer le stockage.
@cgeek arg en fait je crois que j’ai trouvé, c’est la seule erreur que je n’ai pas copiée ici :
app/lib/computation/BlockchainContext.ts:104:90 - error TS7006: Parameter ‘p’ implicitly has an ‘any’ type.
104 await indexer.preparePersonalizedPoW(local_vHEAD, this.vHEAD_1, (n:number, m:number, p = “”) => this.dal.range(n,m,p), this.conf)
~~~~~~
Comment est-ce que je corrige ça, moi ? 
Tu travailles en environnement propre ? Si tu as un node_modules/ souillé par une précédente installation, ou si tu as déjà transpilé du TypeScript d’un ancien code source, tu peux avoir ce genre d’erreur.
En plus le transpilateur se gourre, le type est string vu la valeur par défaut.