13:10:34 <atomfried[m]> is there anything i need to do with my PR or is everything ok?
13:10:34 <atomfried[m]> https://github.com/monero-project/monero/pull/8033
13:29:40 <netrik182> are there any rough estimations of when CLI and especially GUI are being tagged for release? I'm asking because I want to make a call-for-translators shortly after tagging so they can work on it. Plenty of languages require few strings to be fully translated
13:47:19 <ErCiccione> netrik182: The call for translators need to be done before tagging. After a release is tagged nothing is going in
14:00:56 <selsta> Hmm, I don't think 17.3 is large enough to require new translations
14:42:05 <selsta> .merge+ 8031 8032
14:42:05 <xmr-pr> Added
14:46:33 <netrik182> alright, will do before. thanks erciccione
14:46:33 <netrik182> my question is still somewhat relevant though 
14:48:50 <ErCiccione> You can decide if you want to update the strings now and then call for translators or wait until most of the changes are in and then call for translators. With the former translators have more time but can be that the language files will need to be refreshed more than once. With the latter you have translators working on mostly ready language files, but have less time and can be that there will be changes in the strings that will result in that
14:48:50 <ErCiccione> string showing in english in all languages.
14:50:00 <ErCiccione> my suggestion is too coordinate with the GUI people to make an estimate of how many string changes are planned. If it's not many, i would go for the second option.
14:50:34 <ErCiccione> so i would put pressure on the GUI devs for having all string changes in as soon as possible and right after those are merged call for translators
14:52:04 <ErCiccione> ^ this is assuming we are close to a GUI release
14:54:38 <ErCiccione> i also used to implore the GUI devs to not merge any string change after the language files have been refreshed and you called for translators, unless strictly necessary. That helps :)
16:29:09 <selsta> atomfried[m]: please squash, then it should be ready to merge
16:30:24 <selsta> these 3 PRs need a review before we can put out a release: 8023 8021 7997
16:30:37 <selsta> they are all simple so hopefully someone can take a look
16:33:45 <moneromooo> [...] 7997 [...] simple...  :D
16:34:32 <moneromooo> Or was that a typo in the PR number ?
16:34:57 <selsta> these are all PRs that were already merged, so simple in that sense :P
16:35:19 <selsta> but it might be a bit of work to compare them
16:35:43 <selsta> were already merged, or about to be merged
16:37:43 <moneromooo> The list seems to have a numbr of non bug fix commits. Intended for the release branch ?
16:38:24 <selsta> afaik the only one is the --proxy command, where we decide to include as the "major" feature for v0.17.3.0
16:38:46 <selsta> otherwise it should be bug fixes
16:39:07 <berked[m]> I keep getting std::runtime_error's from monerod, backtracing to librandomx, and I think it even crashed my kernel twice (!?) - any ideas?
16:39:17 <moneromooo> Well, I see the C++14 ones, some logging stuff, more seed nodes (those will be small though).
16:39:50 <moneromooo> Get a kernel that doesn't crash when userland misbehaves :)
16:41:06 <moneromooo> Anyway, be more precise. Is anything not working beyond your kernel ?
16:41:49 <moneromooo> If this is just about log spam, you can start with: --log-level 0,*stack*:FATAL
16:42:22 <berked[m]> Well it's a virtual server, EPYC 7something, 16 cores out of 48, everything works fine
16:44:05 <berked[m]> It crashed yesterday, totally unresponsive, I reboot it.... crashed again a few hours later.  Monerod log is full of those exceptions, everything else is fine.  Had a three month uptime before I started running monerod - the debian testing version
16:44:54 <berked[m]> I've compiled a fresh version but I wanted to get advice before switching to it
16:45:28 <moneromooo> Well, my advice would be check whether it's not going into some swapstorm. I assume you don't have some panic output etc in the kernel logs ?
16:47:27 <berked[m]> Nothing in the logs... the server has 64 GB ram, I don't know if swap is enabled I'll check
16:47:58 <berked[m]> I was wondering if it could be some kind of betwork attack
16:48:45 <moneromooo> 64 ought to be just fine.
16:48:57 <berked[m]> s/betwork/network/
16:49:00 <moneromooo> Could be. You never know. The world is full of assholes.
16:49:05 <moneromooo> It's happened before :)
16:49:18 <berked[m]> Through monerod?
16:50:15 <moneromooo> Well I wouldn't know. It's *possible*, but I dunno whether that's what happened.
16:50:55 <moneromooo> Kernels will usually kill any memory hungry process though when they need space.
16:51:28 <berked[m]> Sure but the whole thing went poof.
16:52:49 <berked[m]> Are there any hardening options I can enable while compiling monerod?
16:55:36 <moneromooo> No. Though you should ensure you firewall everything but 18080 (P2P port).
16:58:56 <berked[m]> Ok I'll check.  Maybe I should tcpdump the traffic to another machine until it crashes
16:59:47 <selsta> I added the C++14 patch because I thought it would be annoying when writing something for master and then having to change it for release branch just because a different CPP version is used.
16:59:59 <moneromooo> OK
17:00:13 <selsta> but others might have different opinions but yes it's not a bug fix
17:02:44 <moneromooo> Oh. Not really hardening, but --limit-up and --limit-down I guess. And maybe --out-peers and --in-peers.
17:03:04 <moneromooo> They limit network traffic amount/time and nubmer of p2p peers, resp.
17:03:10 <moneromooo> max of these.
18:11:19 <vtnerd> selsta : its been audited too, right? so its most likely ready, but I will finish looking over it today
18:22:57 <monerobull[m]> Test
18:24:21 <bridgerton[m]> <monerobull> test
18:24:32 <monerobull[m]> Test2
18:24:52 <bridgerton[m]> <monerobull> discord matrix bridge works for this channel now
19:21:41 <sethsimmons> monerobull: please make the bridge read-only for this channel and #monero-research-lab:matrix.org.
19:22:03 <monerobull[m]> Sure
19:23:30 <sethsimmons> Thanks.
19:28:29 <Save_G[m]> F
20:35:18 <selsta> .merge+ 8021 8037 8023
20:35:18 <xmr-pr> Added
22:52:41 <hyc> sech1: you around? have you run core_tests on a recent arm64 build?
22:53:37 <hyc> getting a SEGV on master https://paste.debian.net/1217977/
22:54:20 <hyc> it's a piece of RandomX code calling into unmapped memory
22:56:41 <hyc> you can see that the calling address on line #22 of the paste resides in executable anonymous memory shown at line #68
22:57:19 <hyc> that and line #70 are the only executable anonymous memory. everything else is from executable files/sharedlibs
23:43:05 <hyc> I've added the info to PR#8031, following up mj-xmr[m]'s comment. but this crash occurs independently of this PR, prob should be its own issue.
23:43:30 <isukarim[m]> Hello everyone ,... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/3efb19e6922e5fd1c4d7f45a209d2461080ed061)
23:50:57 <wfaressuissia> hyc, does it fail with disabled jit for randomx ?