12:04:12 So, apparently i missed some action in these couple of days. 2 of my nodes (including a seednode) were either ddosed or had the +2 problem. Using the latest banlist seem to have solved for now. 12:04:27 i saw selsta's post. Any PR i should be running? 12:05:33 maybe try 7189 and 7191 12:06:57 Ok. They both have failing checks. I guess it's a problem of the buildbot 14:37:59 .merge+ 7188 14:37:59 Added 14:40:42 .merge+ 7189 14:40:42 Added 17:19:38 ping luigi1111w Snipa we would need merges today 17:27:21 k 17:31:27 branch with 7189 and 7191 seems to be working fine without blocklist. 17:33:04 moneromooo: we need both 7154 and 7188 right? 17:34:05 Yes. 17:37:09 .merge+ 7190 7191 17:37:10 Added 17:42:45 we need one review for 7192 afterwards we have everything for the next point release 17:45:25 I pushed a bit more to 717[56]. 17:45:55 Got bored waiting to push after merges and it was conflicting so... 17:58:40 ok 7175 and 7192 need a review 18:07:10 moneromooo: error: ‘num_txes’ was not declared in this scope 18:07:21 meh 18:07:24 7175 18:07:32 Guess I should have held out more for merges. 18:09:03 reverted, I'll PR separately later 18:09:16 this was with everything merged 18:09:19 soo something is missing 18:17:21 moneromooo in 7192 you changed it to "buffer_ssl_init_fill = bytes_transferred;" because you use message_peek, so data is not removed from the buffer? 18:18:31 Yes. 18:18:37 in 7175, where did m_requested_fluffy_block_txes.insert() go, lol 18:18:49 it doesn't insert stuff into this set anymore 18:19:44 I removed it ? AFAICT it was never here... 18:20:10 I saw some commit where you added m_requested_fluffy_block_txes.insert() somewhere, but it's not there now 18:20:12 The extra patch above fixed that fwiw. But it seems to rely on another patch. 18:20:19 Where do you add elements to this set? 18:20:23 Yes. 18:20:32 AFAIK it was always broken. 18:22:02 so how does 7175 work? That set is always empty 18:24:49 It uses a separate set from the one it was hijacking. 18:25:17 It might be it was fine in practice, but why chance it. 18:26:55 so before if(!context.m_requested_objects.empty()) could trigger, now it can't trigger because new set is always empty 18:27:00 something like for future use? 18:27:43 Maybe. 18:28:13 I've not tried to see if it could end up in crosstalk. 18:29:03 I just thought that (1) it's possible it could, seeing the code and (2) using a separate set is basically free. 18:29:38 Let's rephrase 1: 18:29:46 .merge+ 7192 7193 18:29:46 Added 18:30:11 Not having tried to make it do so, I estimate that having crosstalk has a non zero probability. 18:30:40 only if block hash = tx hash for some block and tx 18:30:49 Maybe someone can prove it can't happen, in which case I can drop the patch. 18:30:52 probability is so small it will never happen 18:31:13 OK, at this point I'll just drop it and avoid all the extra talk. 18:31:18 having separate set is still better 18:31:43 because it's different hash we're looking for there 18:32:00 ideally we would use different C++ types for these hashes across the codebase 18:32:23 Well, yes. But several people have asked about the patch, despite it being trivially simple from my pov so.. 18:32:37 that would catch all errors where we pass tx hash to function working with block hashes, for example 18:33:14 Note that it's still broken, even reusing the same var. 18:33:35 I noticed, yes 18:33:51 at least it will not waste CPU cycles running this code now 18:35:03 .merge+ 6931 18:35:03 Added 18:43:53 .merges 18:43:53 -xmr-pr- 6931 7086 7098 7099 7138 7139 7145 7146 7154 7155 7161 7172 7173 7174 7175 7176 7180 7181 7182 7183 7188 7189 7190 7191 7192 7193 19:11:06 rapid blocks lately too... really notice if you have --block-notify on to a sound like an alarm bell... 19:21:30 Kronovestan: https://community.xmr.to/blocks/frequencies/ 20:30:55 ugh. for static, how do i fix these. (.text+0x2c): undefined reference to `udev_device_get_action' 20:33:02 I only see a shared lib in libudev-dev on Ubuntu 18.04. 20:34:16 yeah it was libudev. didn't have it installed. 20:59:06 @selsta did Luigi get to em? 20:59:13 .merges 20:59:13 -xmr-pr- 6931 7086 7098 7099 7138 7139 7145 7146 7154 7155 7161 7172 7173 7174 7175 7176 7180 7181 7182 7183 7188 7189 7190 7191 7192 7193 20:59:29 not yet 20:59:30 Doesn't look like it. Lemme wake up and I'll get merging once my brain's kicked in. 20:59:40 thanks 21:35:01 .merge+ 7196 7197 21:35:01 Added 21:36:05 .merge- 7196 7197 21:36:05 Removed 21:42:20 .merge- 7175 7176 21:42:20 Removed 21:42:25 Both were closed by Moo 3 hours ago 21:44:37 K, first pass on master is done. Waiting for the merge list to update and I'll do release-17 21:56:34 .merges 21:56:34 -xmr-pr- 7139 7146 7155 7161 7174 7181 7183 7189 7191 7193 21:56:40 Ah, delightful. 21:57:45 Apologies I didn't get to it yesterday, was w/ the fam for most of yesterday, and ran way later than expected. 22:15:57 np we were busy with current attack anyway 22:17:11 moneromooo: 7196 7197 need rebase 22:17:24 7193 is pending a second confirm, it's technically the same as 7192, but want to verify that vtnerd's issues are satisifified. 23:29:30 selsta, can add 159.89.114.14 to the list it's syncing+2 for me 23:31:50 Kronovestan: thanks, done 23:42:18 OK 23:45:00 done 23:54:26 .merge+ 7196 7197 23:54:27 Added 23:55:01 .merges 23:55:01 -xmr-pr- 7193 7196 7197