02:06:06 <hyc> my build hashes match
10:07:16 <TrasherDK1> Arghhh... src/checkpoints/checkpoints.cpp:138:103: error: ‘boost::placeholders’ has not been declared
10:08:53 <TrasherDK1> Last build on May 19, no problems ??
13:26:46 <selsta> TrasherDK1: build release-v0.16 branch
13:27:30 <selsta> or use https://github.com/monero-project/monero/pull/6531
14:50:41 <TrasherDK> selsta: On branch release-v0.16
14:50:42 <TrasherDK> Your branch is up to date with 'origin/release-v0.16'.
14:51:04 <selsta> Which boost version?
14:51:32 <TrasherDK> boost-1.59.0-x86_64
14:52:42 <selsta> Can you update?
14:53:21 <selsta> We added boost 1.73 support which looks like broke support with your version.
14:54:02 <TrasherDK> boost 1.58 should be sufficient according to required dependencies.
14:54:36 <selsta> Yes. The required dependencies have to be updated then.
14:54:41 <TrasherDK> There was a patch to revert the braking change.
14:54:54 <selsta> Which one?
14:55:16 <TrasherDK> So, no more support for Slackware :(
14:55:27 <hyc> why?
14:55:30 <hyc> just install boost yourself
14:57:29 <selsta> Maybe someone can PR a solution that works for boost 1.59 and 1.73 (without #if everywhere)
14:59:01 <moneromooo> I think it's a simple thing to add: #if BOOST_VERSION < 0x17300 (or whatever) #define placeholders:: #endif
14:59:25 <moneromooo> Or namespace placeholders = :: (I dunno the actual syntax, vtnerd_ must do)
14:59:39 <moneromooo> (assuming _1 is not a define itself, it might)
14:59:44 <selsta> TrasherDK: In the meantime you can revert f35ced6d7f00282091a9623bad573132f42a91b0
15:00:07 <moneromooo> I use 1.70, which works like 1.58 in that regard.
15:00:27 <moneromooo> I *think* I tried 1.72 at some point and it also did, though this was a beta version I believe.
15:42:00 <TrasherDK> Reverting did the trick.
15:42:04 <TrasherDK> ./bin/monerod --version
15:42:04 <TrasherDK> Monero 'Nitrogen Nebula' (v0.16.0.0-e4a20231b)
15:44:20 <luigi1111> no re re tag? we are amazing
15:47:09 <fluffypony> first time in history
15:48:36 <moneromooo> Maybe https://github.com/monero-project/monero/issues/6555 will need one :)
16:25:03 <flipchan> any monero based project in need for a developer?
16:32:08 <ErCiccione[m]> flipchan:  You mentioned in -lab that you are a python dev. Take a look at https://github.com/monero-ecosystem
16:40:48 <moneromooo> Oooh, that's the one I meant, not monero community :D
16:43:08 <ErCiccione[m]> :P
17:19:19 <flipchan> cool :)
17:36:12 <selsta> anyone know how to do proper diff between v0.15.0.5 and v0.16.0.0? `git shortlog v0.15.0.5..v0.16.0.0` contains commits that we already had in v0.15.0.5 because we PRed them to both master and branch
17:36:29 <selsta> kinda annoying when writing patch notes
18:04:14 <moneromooo> git diff v0.15.0.5 v0.16.0.0
18:50:15 <iDunk> selsta: git shortlog --cherry-pick --no-merges v0.15.0.5...v0.16.0.0
18:50:33 <iDunk> See if that helps.
18:51:30 <selsta> perfect
18:51:41 <derpy_bridge> <[discord] DynaChip#0559>: What is it
18:53:33 <moneromooo> This one either.
18:53:51 <derpy_bridge> <[discord] DynaChip#0559>: Why do you all have cat pics lol
18:54:19 <derpy_bridge> <[discord] Kayla#5718>: its robothash, irc doesnt have pics, please listen to moneromoo
18:54:20 <derpy_bridge> <[discord] Kayla#5718>: #irc_monero-dev and #irc_monero-research-lab are not for spam
18:55:01 <selsta> iDunk: I tried that previously and it did not work but now it does..
18:55:03 * selsta confused
18:55:20 <iDunk> maybe ... vs ..
18:55:31 <selsta> wow, yep that was the reason
18:55:40 <selsta> I thought they are the same
18:56:01 <derpy_bridge> <[discord] NightH4wk#5036>: Alr works
18:56:47 <derpy_bridge> <[discord] DynaChip#0559>: Yep
18:56:49 <derpy_bridge> <[discord] Kayla#5718>: @NightH4wk same to you, those channels are not for spam, which btw you can look at the right there is not bot so you dont get "xp" writing in the bridged channels
18:56:49 <selsta> Kayla can you mute people if they write unrelated off topic stuff?
18:56:53 <derpy_bridge> <[discord] Kayla#5718>: sure
18:57:21 <derpy_bridge> <[discord] Kayla#5718>: done, sowry about that
18:58:39 <selsta> np
18:58:55 <selsta> moneromooo: do you think the rpc pay bug will require a point release?
18:59:42 <moneromooo> I'd say no, but I'm not quite sure exactly why the wrong time.
19:16:01 <vtnerd_> the syntax would be `#ifdef BOOST_VERSION <= WHATEVER \n using namespace boost::placeholders;\ n #endif`
19:16:18 <vtnerd_> the namespace was added in boost 1.60
19:16:24 <selsta> can you do a PR? not urgent
19:16:45 <vtnerd_> should I have an old copy of boost somewhere to test against
19:16:59 <vtnerd_> s/should/sure/
19:22:35 <moneromooo> It's in headers though, so you'd need to do that a number of times (or else dump a using for whatever's after the include, which isn't very nice).
19:23:24 <moneromooo> So I thought the namespace X = Y thing (and keep the existing patch) would be less intrusive maybe.
19:31:33 <vtnerd_> theres no namespace for the old boost versions. we could define one and then alias global variables into that namespace for consistency so that it doesn't pollute the global namespace for newer boost versions
19:32:26 <vtnerd_> -> namespace X = Y only works with boost 1.60+ or maybe you can do `namespace X = ::` which I dunno seems like a syntax error
19:33:45 <moneromooo> So you can't do namespace placeholders = :: ?
19:33:56 <moneromooo> nvm, I should learn to read.
19:35:23 <moneromooo> Right, I tried, doesn't work, but works with an actual non root namespace. Oh well.
22:08:09 <UkoeHB_> Im looking into how duplicate key images are handled for new blocks being added to the chain. The path seems to be `Blockchain::handle_block_to_main_chain() -> BlockchainDB::add_block() -> BlockchainDB::add_transaction() -> BlockchainLMDB::add_spent_key()`, where `add_spent_key()` tries to add key images to the db and throws an exception when it sees a duplicate. The exception gets caught by
22:08:09 <UkoeHB_> `handle_block_to_main_chain()`, which then calls `tx_memory_pool::add_tx()` on all the block's transactions to clean up. Now, if for example a block has 2 transactions, and `add_block()` successfully calls `add_transaction()` for tx1, but then an exception is thrown for tx2, it would seem like the key images from tx1 would still be in the db when `handle...chain()` catches the exception. This means
22:08:09 <UkoeHB_> `tx_memory_pool::add_tx(tx1)` should be cleaning up those tx1 key images. However, I can't find where it does that. The relevant function for cleaning up appears to be `BlockchainLMDB::remove_spent_key()`, but afaict that only gets called by `BlockchainDB::pop_block() <- BlockchainDB::remove_transaction()`.  So I guess my question is if there is a leak where key images can get added to the db when there is no block
22:08:09 <UkoeHB_> that owns them, or if I am misunderstanding `tx_memory_pool::add_tx()` and it is cleaning up properly after all, or if it is cleaned up somewhere else. Thanks :)
22:10:07 <moneromooo> One thing you might (or might not) have missed is that everything that's written in a db txn is dumped in the bit bucket if that db txn is not committed.
22:21:54 <UkoeHB_> My best guess what that might be is `BlockchainDB::add_block()` calls `BlockchainLMDB::add_block()`, and it also has the line `m_hardfork->add(blk, prev_height);`. That call, and that statement, won't be executed if any transaction throws a `KEY_IMAGE_EXISTS` exception. However, my concern is that `BlockchainLMDB::remove_spent_key()` calls `mdb_cursor_put()` which sounds like it's writing to the db.
22:23:44 <UkoeHB_> add_spent_key*