freenode #monero-dev

12 May 2021

Official repo: github.com/monero-project/monero || Don’t ask to ask, just ask:) || Non-dev questions -> #monero, please || Next dev meeting is detailed on the Monero meeting issue on Github: github.com/monero-project/meta/issues

• 03:45
  gingeropolous
  are any of these ideas ready for the next fork? monero-project/monero #6456
• 03:47
  gingeropolous
  UkoeHB, knaccc
• 03:48
  gingeropolous
  from what I can tell, the focus has been BP+ and a ringsize bump
• 03:49
  gingeropolous
  though i might keep forgetting
• 04:15
  UkoeHB
  not unless someone has been working to implement them
• 04:20
  gingeropolous
  gotcha. But fundamentally, they are all sound?
• 04:37
  UkoeHB
  yeah there are no outstanding objections I am aware of
• 13:07
  hyc
  wfaressuissia[m]: netstat -tunp: p requires an argument.
• 13:07
  hyc
  netstat -tun shows only unix domain sockets. not interesting for monerod.
• 13:07
  hyc
  I use netstat -nt.
• 13:07
  sethsimmons
  I cannot see wfaressuissia[m] messages in Matrix, looks like there is an issue with his account.
• 13:08
  sethsimmons
  Maybe not voiced or something?
• 13:09
  hyc
  this is after 2 days uptime paste.debian.net/1197339
• 13:09
  hyc
  all the TIME_WAITs are from xmrig polling the RPC
• 13:09
  hyc
  nothing unusual looking at the moment
• 13:11
  hyc
  er... all the 127.0.0.1:18081 TIME_WAITs are. there are one or two others from p2p
• 13:21
  wfaressuissia[m]
  "netstat also showed hundreds of conns in CLOSE_WAIT" there must be some way to list active tcp sockets along with associated process pid
• 13:22
  wfaressuissia[m]
  it's expected that dangling (without associated pid) socket can't be in CLOSE_WAIT state
• 13:23
  wfaressuissia[m]
  in the worst case socket can be left unclosed until timeout of connection timer which is about few minutes
• 13:23
  sethsimmons
  Hey messages :D
• 13:23
  wfaressuissia[m]
  if you have a lot of sockets in CLOSE_WAIT state for along period of time then it's a problem
• 13:24
  hyc
  PID is not relevant here, there are no other active services on that machine. they are all due to monerod aside from my ssh session
• 13:24
  wfaressuissia[m]
  otherwise it's expected that some of them will not be closed immediately
• 13:24
  hyc
  anyway, the last time I mentioned it the monerod had been up for 4 days when it started running out of descriptors due to this problem
• 13:24
  hyc
  this has now only been 2 days so far
• 13:25
  wfaressuissia[m]
  PID will tell whether it's just non-terminated connection by monerod or some black magic problem in mac with CLOSE_WAIT state for dangling socket
• 13:27
  wfaressuissia[m]
  sethsimmons: your messages aren't visible in #freenode_#monero-dev:matrix.org but visible in monerologs.net/monero-dev
• 13:27
  sethsimmons
  I think it's due to the voice restrictions here.
• 13:27
  sethsimmons
  On the IRC side
• 13:28
  asymptotically
  sethsimmons: i can see his messages fine and he's got voice
• 13:28
  sethsimmons
  I can see wfaressuissia[m] now, not sure what changed
• 13:34
  hyc
  nothing changed. I was replying to his message from yesterday
• 13:35
  sethsimmons
  oh
• 16:55
  DisBotXMR2
  <CrimsonKing> test
• 16:55
  DisBotXMR2
  <CrimsonKing> is the relay still working ? Matrix guys, anyone can read this ?
• 17:00
  sethsimmons
  Yes, we can
• 19:39
  luigi1112
  .merges
• 19:39
  xmr-pr
  7349 7665 7666 7667 7668 7670 7677 7678 7680 7681 7682 7685 7686 7687 7688 7689 7690 7691 7694 7695 7696 7697
• 19:40
  mj-xmr
  I hope that 7777 is not going to be taken by a spammer.
• 19:41
  selsta
  .merge- 7706 7689
• 19:41
  xmr-pr
  Removed
• 19:41
  selsta
  luigi1112: these two might get replaced
• 19:41
  selsta
  by a more general fix so I removed them for now
• 19:41
  luigi1112
  7777 is very important agreed
• 19:41
  hyc
  are these tests still going to be testing what they claim, with all these result caching patches?
• 19:42
  selsta
  which one exactly?
• 19:42
  selsta
  we don't cache anything yet
• 19:42
  selsta
  regarding tests
• 19:42
  selsta
  ah you mean not merged ones yet
• 19:45
  hyc
  yeah
• 19:45
  selsta
  I will be careful with cache patches regarding tests (I won't be the one reviewing them)
• 19:47
  selsta
  this is the last place we want to add a bug and not notice broken tests
• 19:55
  hyc
  indeed
• 19:59
  selsta
  If a change is deemed safe, does not make things significantly more complicated and also has a noticeable speedup it should be fine to merge.
• 20:52
  selsta
  .merges
• 20:52
  xmr-pr
  7349 7670 7677 7678 7686 7687 7688 7690 7691 7694 7695 7696 7697
• 21:57
  mj-xmr
  hyc, selsta, me and moneromooo have agreed, that the caching shall be disabled by default, and remain a developers' tool for local runs.
• 21:58
  mj-xmr
  And this is the current state of the caching PR (7469)
• 21:58
  mj-xmr
  Good night
• 21:59
  selsta
  mj-xmr: I think this was related to 7717
• 22:24
  selsta
  .merge+ 7689
• 22:24
  xmr-pr
  Added
• 22:29
  selsta
  luigi1112: please ^ and then also gui today
• 22:30
  selsta
  and gui tag
• 23:25
  ed23
  guys can you help me out with something. Where exactly in the code is if 10 blocks have past since an input of a transaction was created using a prior output?
• 23:25
  selsta
  do you want to remove it?
• 23:25
  ed23
  it seems to me that there is no such check, only a check against the unlock time (which is different )
• 23:25
  ed23
  and set by the user
• 23:26
  ed23
  No I want to understand the code
• 23:26
  selsta
  moneromooo: probably knows
• 23:28
  ed23
  seems like there is no rule like that
• 23:28
  ed23
  Not at the blockchain level, only the wallet level
• 23:30
  ed23
  (besides the user defined unlock time that is bundled with the tx)
• 23:36
  moneromooo
  git show a444f06
• 23:57
  ed23
  thanks a lot moneromooo