00:43:53 jeffro256[m]: just responded 00:49:59 .merges 00:50:00 -xmr-pr- 8348 8513 8519 8534 8538 8547 8548 8551 8552 8553 8554 8555 8556 00:50:01 yes 01:25:03 ukoehb: for 8329 Im just confused about the removal of some of the checks that I commented on 01:25:43 couldn't issues arise with intermediate messages too? or I am missing why the kludge specifically for the post-kex message was added 01:34:15 vtnerd: the only check removed was 'is the multisig account done with kex?' if you pass in messages when kex is done then there will be a downstream error 01:35:11 we need some way to get the post-kex message when an account is done with kex 01:35:48 sorry: the only check removed was 'is the multisig account done being set up?' (includes kex and the post-kex verification check) 01:36:49 if you think we should bite the bullet and add an rpc endpoint for the post-kex message, I can do that 01:39:02 although without https://github.com/monero-project/monero/pull/7852, it's hard to actually test if the post-kex message is available at the end of kex (i.e. the round before `wallet2::multisig(&ready) -> ready == true;`) 02:23:14 Is there a way to stop a CI build in the middle without force pushing? 03:59:10 im just following the instructions from here: https://github.com/monero-project/monero/tree/master/contrib/gitian 03:59:49 ./gitian-build.py -j 4 -o android --detach-sign --no-commit --build $GH_USER $VERSION 03:59:56 this is failing with 04:00:12 cp: cannot stat 'base-bionic-amd64': No such file or directory 07:10:28 has anyone had time to check this out? https://pastebin.com/0ectpHLs 07:13:51 user01cs98: not sure about the answer but paste is expired in case you didn't realize 07:16:38 my bad here it it https://paste.debian.net/1253281/ 07:19:37 user01cs98: did you realize when you use 127.0.0.1 and localhost you used different ports 07:20:12 sorry not 127.0.0.1 but 10.10.1.105 and localhost 07:22:28 also both monerod and monero-wallet-rpc bind port 18089 for some reason, of course there will be problems 07:24:24 sech1: small thing : i just started compiling xmrig on a fresh fedora box, dependency installation line doesn't have some of the fundamentals like automake and tar :D 07:24:40 the very minimal installation of fedora doesn't even have tar lol 07:26:37 something like suggesting sudo dnf groupinstall "C Development Tools and Libraries" may have more coverage. ofc somebody who can't figure this out by himself is in much bigger trouble 08:46:35 jeffro256[m]: yes, but only in your repository 08:47:18 MeowingCat: you have to use the docker commands 09:26:42 selsta: IMO #8076 is ready for merge to master now, after jberman signed off the rebase and the latest (quite small) changes. Can you please have a look? 10:16:47 rbrunner: I was mostly curious how this patch works with large mempools 10:17:08 or txpool 14:52:04 yeah there should be an option in the dropdown 14:52:14 oops, I was scrolled up sorry, ignore 17:25:49 does anyone know what --install-service is? https://github.com/monero-project/monero-gui/issues/4023#issue-1367417025 17:26:24 oh, it actually exists 17:29:04 I think it's a windows specific daemon replacement. 17:29:19 Because windows always special. 17:46:12 .merges 17:46:12 -xmr-pr- 8348 8513 8519 8534 8538 8547 8548 8551 8552 8553 8554 8555 8556 18:06:57 right it just tells windows to auto-start a process as a headless service 18:16:35 Anyone, by chance, tested whether the daemon automatically pops block off the wrong chain (and subsequently syncs to the correct chain) if a user forgot to upgrade and used 0.17 to sync? 18:19:04 this should happen automagically because 0.18 chain is longer now 18:20:01 Does it use old fork rules to pop ? I doubt it. 18:20:15 If not, it has the potential to bork the chain. 18:21:17 moneromooo: Could you elaborate? Not sure I understand the question correctly 18:23:14 This is about the system that will pop blocks with the wrong version on startup. 18:24:03 I was asking whether, when popping these blocks, which happens with the new code, the consensus rules applied to the popped blocks were using the version from the blocks (old) or the new one. 18:24:26 The blocks were added with the old rules, so in order for the popping to properly revert, they should be reverted using the old rules. 18:24:45 So I was asking which rules version was used to pop. 18:25:10 If anyone knows offhand. 18:25:45 I know monerod will decide which rules to use based on height, which suggests the wrong version would be used, unless special care was taken. 18:26:05 (which it might have) 18:27:00 The difference between old code and new code is that, based on height, thy'll select differemt rules for blocks with height past the fork that got added in the new version, which the old version doesn't know about. 18:27:44 Quite often, there'll be no relevant difference in block popping, but it's not a given. 18:28:41 And if there are differences, pushing with old verison nad popping wit hnew version will not be idempotent. 18:28:52 If you'll forgive the spelling. 19:02:04 Thanks for clarifying, I understand now (though don't have a proper answer) 19:02:50 I asked in the first place because I was assisting two users where it seemed the daemon was not popping blocks 19:08:14 Is it trying and failing, or just not doing ? I think it should say so on default log settings. 19:08:41 In any case, "pop till before the fork height using the old version, then update" will always work. 19:09:12 (hopefully) 19:40:28 dEBRUYNE: users were able to just run the v0.18 daemon after updating too late and it worked correctly 20:47:45 moneromooo: I will have to check my conversations with them, will get back to you on that