[00:11:48] merged [00:11:53] ill pull this through to 4.7.0 [00:12:06] do we need anything else in there at the moment? or should i build another RC? [00:14:44] Not sure, I've not found any other issues [00:15:37] okay, so this will merge in #555 #562 #564 [00:17:02] ill kick off my gitian again [00:17:06] its merged [00:18:09] ACK, I've started my gitian build as well [02:30:46] @prole I've posted my gitian hashes [04:14:13] @Goku @aguycalled @prole check it out 😄 [04:14:14] https://cdn.discordapp.com/attachments/416000318149754881/599785693950115840/Screenshot_from_2019-07-14_10-06-55.png [04:14:17] https://cdn.discordapp.com/attachments/416000318149754881/599785709687144458/Screenshot_from_2019-07-14_10-07-32.png [04:14:20] https://cdn.discordapp.com/attachments/416000318149754881/599785720814632970/Screenshot_from_2019-07-14_10-10-34.png [04:14:22] https://cdn.discordapp.com/attachments/416000318149754881/599785730922774548/Screenshot_from_2019-07-14_10-11-41.png [04:15:41] This PR is now ready for review: https://github.com/navcoin/navcoin-core/pull/557 [09:24:13] @mxaddict hashes match mine [09:24:17] publishing the RC builds [09:42:36] @everyone new RC builds of 4.7.0 are available here: https://github.com/navcoin/navcoin-core/pull/545 [09:42:58] :candle_g: [10:00:02] 👏 [10:11:08] post your testnet address if you want some coins [10:19:47] @mxaddict looks great! [10:20:25] i only fear the dao vote warning could be not annoying enough [10:22:21] what others think about it and the new layout [10:22:23] ? [10:38:27] https://cdn.discordapp.com/attachments/416000318149754881/599882388541145088/Adsz.png [10:38:38] https://cdn.discordapp.com/attachments/416000318149754881/599882432614891531/Adsz2.png [10:40:29] https://cdn.discordapp.com/attachments/416000318149754881/599882900120272907/Adsz3.png [14:11:33] @sakdeniz the new dao branch that @aguycalled is working on fixes those issues on the dao page [14:11:52] I also have a PR that removes the navtech related code. [14:14:31] we are also forgetting about the translations with every rc [14:18:16] Yeah, i was going to mention that. [14:18:39] There are some new strings that need to be added to the TS files [14:28:52] https://github.com/navcoin/navcoin-core/blob/master/doc/translation_process.md [14:31:42] https://github.com/proletesseract/navcoin-core/pull/32 @prole [21:53:08] @aguycalled replying to what you said in DM, i will run that node with the txindex to unblock the fcas rating parser [21:53:23] i figured it was something like that but wanted to confirm. [21:54:09] Good morning @prole ! [21:54:11] 😄 [21:54:26] also, i again had that issue where block 2762326 get stuck when i reindex [21:54:55] then i reconsidered, then it synced until that CFund block issue where it thinks the proposal id is 0000000 [21:55:16] Yeah, I've had a few gos at fixing that, I could not really figure out what the cause was. [21:55:22] im trying to see if i can replicate it [21:55:27] reliably [21:55:45] the reindex/reconsider issue isnt the biggest in the world. [21:56:09] Yeah, it easy to fix, just anoying though 🤣 [21:56:12] but the cfund proposal id being 0000 needs to be resolved since it could cause a fork [21:56:29] i think my local version was a few commits behind master, so im trying again [21:56:37] Yes, I've not com accross a reliable way to get that outcome [21:57:08] 2019-07-14 08:21:23 UpdateTip: new best=740f8399137cc0ea9c624a278e3f49b2be9b23e790afbbfa575eb0002979b1d8 height=3286130 version=0x7131e1ff log2_work=73.032936 tx=6866468 date='2019-07-09 08:44:48' progress=0.987749 cache=15.5MiB(30367tx) 2019-07-14 08:21:23 ERROR: CheckBlock() : cant find payment request block 0000000000000000000000000000000000000000000000000000000000000000 [21:57:10] same one right? [21:57:12] What were the steps you did to get the 0000 cfund id? [21:57:26] CheckBlock() : cant find payment request block 0000000000000000000000000000000000000000000000000000000000000000 [21:57:28] This i've seen [21:57:37] But can't get it to break reliably [21:57:44] okay [21:58:06] basically im trying to get a node with tx indexes for the new navpay backend im setting up on hetzner [21:58:33] Nice, so when done, hopefully navpay will no longer randomly die 😄 [21:59:20] so i cloned my local data folder and set the config to the exact same as navpay: server=1 whitelist=127.0.0.1 txindex=1 addressindex=1 timestampindex=1 spentindex=1 zmqpubrawtx=tcp://127.0.0.1:28332 zmqpubhashblock=tcp://127.0.0.1:28332 rpcallowip=127.0.0.1 rpcuser= rpcpassword= uacomment=bitcore [21:59:37] then just ran QT and it asked if i wanted to reindex because i changed the config [21:59:40] choose yes [21:59:53] then it got to 2762326 and i had to reconsider [22:00:03] then after that it is syncing and got to that error [22:00:07] that's all i did [22:00:08] afaik [22:00:27] i am trying the same steps with 4.6.0 [22:00:31] Reindex stuck at 2762326 I can replicate everytime [22:00:39] and i will try again with the latest 4.7.0 [22:00:47] All I have to do is do a reindex + reindex-chainset [22:00:55] On any node [22:01:11] reindex-chainstate do you mean? [22:01:21] Yeah [22:03:37] its such a fuckin pain to test lol because you have to wait like 3 hours to reindex to that block [22:03:52] Exactly [22:04:21] i guess we will have to put in a massive amount of debugging around all the values that could possibly cause the block to be marked invalid [22:04:28] and see what they all are and which one comes out wrong [22:04:47] i think the other issue is more important right now though [22:04:53] because it happened to me on natural sync [22:05:31] I suspect this has to do with the threads running over each other [22:05:37] But I have no idea where [22:06:30] Might be as simple as a lock missing (Like thread 1 is moving ahead of thread 2 and did not use a lock, so thread 2 tries to access data that thread 1 is supposed to provide) [22:06:41] IDK, just trying to throw ideas around [22:07:54] not sure either, but all the times its happened to me so far its always that same payment request from a week ago [22:07:59] https://www.navexplorer.com/block/3286131 [22:09:22] let me confirm i can replicate it reliably and if so ill try to write a unit test that replicates the same situation [22:09:31] and see if i can make a test that fails [22:09:46] Ack [22:10:02] then we at least have a scenario to check against and can ultimately confirm if its been resolved by whatever patch we can make [22:10:18] Yes, makes sense [22:10:46] its gonna take some time since confirming the replication is slow AF [22:10:59] but ill post when i have more info [22:12:07] 👌