Yes, you can now throw away v0.9.12 and move to v0.9.13, of course, if you are not afraid of "13" in the name"Problems encountered while processing some of the proposals data. Look into the log file for details." [log not updated]
Now my nodes are on 12.2, do I need to go to DMT 0.9.13 to fix this?
 Error loading Python lib '/tmp/_MEIGnGR9b/libpython3.6m.so.1.0': dlopen: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.25' not found (required by /tmp/_MEIGnGR9b/libpython3.6m.so.1.0)
dpkg: error processing archive libc6_2.26-0ubuntu2_amd64.deb (--install): installing libc6:amd64 would break locales, and deconfiguration is not permitted (--auto-deconfigure might help)
This issue is related to problems with accessing dashcentral.org, which is used by the app to download external atrributes (proposal name, owner, etc). BTW, Dashcentral.org is now experiencing problems caused by a serius outage of the OVH infrastructure (https://twitter.com/OVH_Status/status/928515258020433921). I think that several masternodes are affected by this too.Still getting, "Error(s) occurred while retrieving proposals external data. Look into the log file for details." and the log file is untouched.
It seems to happen when it's doing, "Reading proposal external attributes (3/3), please wait...".
I have latest python 3.6.3 installed. libc6 version 2.23-0ubuntu9.
I enabled pre-released updates and tried apt dist-upgrade, but it did not upgrade it. I downloaded latest package libc6_2.26-0ubuntu2_amd64.deb and tried to install manually, but it gives me an error
I am struggling over ah hour with it, but without success. Any ideas? Thank you.
Was having the same problem (ubuntu 16.4), all good nowSorry for the delay. I've uploaded another linux binary, compiled on an older linux version, which I hope resolves the problem. Could you download and try again?
Thank you. Now works.Sorry for the delay. I've uploaded another linux binary, compiled on an older linux version, which I hope resolves the problem. Could you download and try again?
You probably have your mn collaterals addresses located in different bip32 paths (e.g. 44'/5'/0'/0/0 and 44'/5'/1'/0/0) and you are trying to sign its UTXOs as a one transaction. If so, the reason is a Trezor's firmware bug. I've reported it to Satoshi Labs - they said they will fix it soon, but I don't know the exact date.
To workaround this issue, send your funds (UTXOs) as a separate transactions for each of your masternodes.