Quote from: Thom on October 05, 2015, 06:31:31 pm

What the bleep is going on! Dam if it's not one thing it's another.

Code: [Select]

admin@seed06:~/.BitShares2_bin$ ls -ls
total 822568
    0 lrwxrwxrwx 1 admin admin       38 Oct  5 18:38 cli_wallet -> cli_wallet_2015-10-05_test6-1-g60b5228
79456 -rwxr-xr-x 1 admin admin 81361534 Oct  5 17:01 cli_wallet_2015-10-05_test6
80464 -rwxr-xr-x 1 admin admin 82394008 Oct  5 18:32 cli_wallet_2015-10-05_test6-1-g60b5228
32304 -rw-r--r-- 1 admin admin 33079187 Oct  5 18:51 test6bin.tgz
    0 lrwxrwxrwx 1 admin admin       40 Oct  5 18:38 witness_node -> witness_node_2015-10-05_test6-1-g60b5228
76960 -rwxr-xr-x 1 admin admin 78803733 Oct  5 17:01 witness_node_2015-10-05_test6
78172 -rwxr-xr-x 1 admin admin 80045408 Oct  5 18:32 witness_node_2015-10-05_test6-1-g60b5228

Major difference in the binaries between those produced on the VPS vs my dev machine. Thought for sure that was the issue, but NOT!

I had no issues before with the build methodology I used for the testnet, now all lthe sudden shit is different. Ultra bummer.

There has got to be a silly stupid change made somewhere. I am going to compile test5 again and see if the binaries differ and if it runs. If it does then whatever is different is not on my end. You all will hear some explitives if that is the case. I doubt it is but I've spent WAY too much time dealing with this today and must go now. If test5 is built and runs without this silly json read error I know something else is the problem.

The only thing that may be the cause on my end I could see is the release flag, since nobody has bothered to answer THAT question. It will SUCK if it turns out that is the culprit. It really wouldn't surprise me tho. It just would be nice if I could get a straight answer. It will require changing wackou's code to fix that, which is not a big deal to do but the point is it shouldn't be necessary and it has cost me alot of time that those tools are supposed to save. The flags he uses to build the code have always worked before.

If the -D CMAKE_BUILD_TYPE=Release definition is so crucial and is not the same as not defining it why is that so damned hard to answer? The build default should be release and the exception debug. Reversing it (if that is what has been done) has screwed at least 2 people.

Edit: just to make sure it wasn't the json file itself I used an old one, but still got the same error.

At the risk of beating that poor horse, forgive me, : ) I still believe it may have to do with the location of your json file.

put the .json file in ~/graphene/programs/witness_node  directory and launch without specifying an explicit location


for example

Code: [Select]

cd ~/graphene/programs/witness_node
wget https://github.com/cryptonomex/graphene/releases/download/test6/oct5-genesis.json.zip
unzip oct5-genesis.json.zip

./witness_node --rpc-endpoint "127.0.0.1:8090"  --genesis-json oct5-genesis.json -d oct5 -s "104.236.51.238:2005"

I also changed nothing about my build process and I did not have any issues.  Hope that helps. : )

I had to take down init node to compile because while it was running I didn't have enough RAM

Sadly there is need for a hardfork for this testnet... this time I promise to upgrade the init nodes.

The issue discovered is that the witness count code was setting a threshold equal to 50% of all stake rather than 50% of voting stake so every witness got voted in unless over 50% of the stake voted for less than everyone.   In other words, the reverse case from the prior hardfork.   

I set the fork time for 24 hours from now.