< wumpus> luke-jr: yes, agree we should fix that at the same time
< wumpus> e.g. moving the assets attribution exclusively to debian seems to have been a bad idea
< bitcoin-git> [bitcoin] winder opened pull request #13145: Use common getPath method to create temp directory in tests. (master...master) https://github.com/bitcoin/bitcoin/pull/13145
< fanquake> Even though I know that splitting up the massive bitcoin/bitcoin repo is going to be better in the long term. Sometimes I feel like I'm losing a handle on everything that gets split out. Especially what's in the bitcoin-core/docs repo. Haven't reviewed any of the recent gitian build guide changes.
< fanquake> wumpus #13141 is trivial and mergeable.
< gribble> https://github.com/bitcoin/bitcoin/issues/13141 | [doc] qt: fixes broken link on readme by marcoagner · Pull Request #13141 · bitcoin/bitcoin · GitHub
< wumpus> fanquake: it takes some getting used to, that's sure
< wumpus> but it seems a good way to delegate, to avoid everything having to go through one small bottleneck
< wumpus> fanquake: will take a look
< bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/baf6b4e3f956...57c57df86f14
< bitcoin-git> bitcoin/master 12ad33a marcoagner: [doc] qt: fixes broken link on readme
< bitcoin-git> bitcoin/master 57c57df Wladimir J. van der Laan: Merge #13141: [doc] qt: fixes broken link on readme...
< bitcoin-git> [bitcoin] laanwj closed pull request #13141: [doc] qt: fixes broken link on readme (master...fix_qt_readme_typo) https://github.com/bitcoin/bitcoin/pull/13141
< wumpus> fanquake: though not sure nightmerging is a good idea
< fanquake> wumpus nightmerging?
< wumpus> yes, it's night here
< wumpus> I'm basically still sleeping :p
< fanquake> wumpus hehe. I'm sure you merge enough you can do it in your sleep anyways..
< wumpus> fanquake: that's true
< wumpus> do we really have a problem with #'s in rpc passwords?
< wumpus> I understand that it is convient to use # for defining comments, but did they really have to make it impossible to specify it in program_options? or am I missing something
< fanquake> wumpus yes also reproduced that
< * sipa> votes: removing program_options
< wumpus> well we're going to replace boost program_options so I guess we can think of a way
< luke-jr> we are?
< wumpus> there's a PR for that...
< fanquake> I'm guessing that the rpcauth.py will never generate any strings containing a "#"
< luke-jr> as for comments, requiring a space prior to # (or start-of-line) would seem logical
< wumpus> fanquake: correct - they'd have to adapt rpcauth.py to be able to provide a custom password
< sipa> and even less intuitive
< wumpus> fanquake: which is trivial, might do it...
< luke-jr> using dependencies is strictly better than re-inventing them, but all things considered, I guess this case looks not totally unreasonble :x
< wumpus> we have decided long time ago to slowly move away from boost - and there's no std:: equivalent for program_options
< luke-jr> only in libconsensus..
< sipa> in libconsensus we already did
< wumpus> no, not only in libconsensus
< wumpus> there's even a project open for it https://github.com/bitcoin/bitcoin/projects/3
< luke-jr> I understood it to be using C++ where it has superceded boost
< luke-jr> C++11*
< luke-jr> not some kind of NIH "let's add to the workload by maintaining re-implementations of things others have already done"
< luke-jr> anyway, not worth arguing over until someone proposes reimplementing Qt i guess
< sipa> haha
< wumpus> are you just arguing for arguing's sake now? I'm tired
< wumpus> right
< wumpus> qt is pretty ok as a GUI dependency, as these things go, at least it's not a cursed thing like electron
< luke-jr> I was not seriously suggesting we discuss reimplementing Qt ;)
< fanquake> I assumed we'd be moving to Electron shortly so that we could re-implement everything using WebAssembly ?
< sipa> excellent idea.
< wumpus> luke-jr: oh I thought we were going to move to SDL2, OpenGL and imgui, and do release on steam...
< sipa> wahaha
< * luke-jr> panics
< sipa> i thought bitcoin core was going to become a minecraft plugin?
< wumpus> even better, blocks in 3d
< luke-jr> fun fact: I only began using the GUI when wumpus wrote Bitcoin-Qt ;)
< fanquake> wumpus Probably want to benchmark point and click mining first
< wumpus> luke-jr: same here, the old gui was terrible and needed some special pre-release of wxwidgets with unicode support to compile at all
< wumpus> fanquake: but minecraft already has mining functionality, that's the genius, just have to put a chain between the blocks
< fanquake> :o
< sipa> wumpus: i wonder if that wx unicode ever got actually released
< bitcoin-git> [bitcoin] laanwj opened pull request #13146: rpcauth: Make it possible to provide a custom password (master...2018_05_rpcauth_custom_password) https://github.com/bitcoin/bitcoin/pull/13146
< sipa> wumpus: november 2013
< wumpus> sipa: I'm surprised
< sipa> only 2 years after we switched to Qt :D
< wumpus> yep and that's the release, I'd imagine it'd take much longer to be taken up by linux distributions
< sipa> trusty had it :)
< wumpus> :-)
< sipa> holy crap we have a lot of circular dependencies
< gmaxwell> It's almost as if it were a program and not a utility toolkit. :P
< wumpus> do we at least have a handle on circular dependencies between .a files now?
< wumpus> close, I guess #7965
< gribble> https://github.com/bitcoin/bitcoin/issues/7965 | Remaining instances of ENABLE_WALLET in `libbitcoin_server.a` · Issue #7965 · bitcoin/bitcoin · GitHub
< wumpus> jnewbery: I suppose we can check off 'wallet initialization/verify/shutdown' as well there after #10762?
< gribble> https://github.com/bitcoin/bitcoin/issues/10762 | [wallet] Remove Wallet dependencies from init.cpp by jnewbery · Pull Request #10762 · bitcoin/bitcoin · GitHub
< wumpus> sipa: how does that script work, does it look at the includes only or at the symbols?
< wumpus> oh he left :/
< btc> s
< btc> aa
< btc> hello?
< btc> is anybody there
< bitcoin-git> [bitcoin] practicalswift opened pull request #13148: logging: Fix potential use-after-free in LogPrintStr(...) (master...logprintstr-uaf) https://github.com/bitcoin/bitcoin/pull/13148
< bitcoin-git> [bitcoin] practicalswift opened pull request #13149: Handle unsuccessful fseek(...):s (master...fseek) https://github.com/bitcoin/bitcoin/pull/13149
< bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/57c57df86f14...0bc980b1f65f
< bitcoin-git> bitcoin/master 2a89b0c Wladimir J. van der Laan: rpcauth: Make it possible to provide a custom password...
< bitcoin-git> bitcoin/master 0bc980b Wladimir J. van der Laan: Merge #13146: rpcauth: Make it possible to provide a custom password...
< bitcoin-git> [bitcoin] laanwj closed pull request #13146: rpcauth: Make it possible to provide a custom password (master...2018_05_rpcauth_custom_password) https://github.com/bitcoin/bitcoin/pull/13146
< promag> I would like to know if #13034 is something we want, or if I should remove that from other PR's related to dynamic wallets
< gribble> https://github.com/bitcoin/bitcoin/issues/13034 | Introduce WalletManager by promag · Pull Request #13034 · bitcoin/bitcoin · GitHub
< promag> so please ACK/NACK there
< bitcoin-git> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/0bc980b1f65f...598db389c33e
< bitcoin-git> bitcoin/master 50b6533 Matt Corallo: scripted-diff: Rename SetBestChain callback ChainStateFlushed...
< bitcoin-git> bitcoin/master 9cb6cdc Matt Corallo: Simplify semantics of ChainStateFlushed callback...
< bitcoin-git> bitcoin/master 598db38 Wladimir J. van der Laan: Merge #13106: Simplify semantics of ChainStateFlushed callback...
< bitcoin-git> [bitcoin] laanwj closed pull request #13106: Simplify semantics of ChainStateFlushed callback (master...2018-04-wallet-flush-better-criteria) https://github.com/bitcoin/bitcoin/pull/13106
< bitcoin-git> [bitcoin] laanwj opened pull request #13151: WIP: net: Serve blocks directly from disk when possible (master...2018_05_direct_from_disk) https://github.com/bitcoin/bitcoin/pull/13151
< bitcoin-git> [bitcoin] chris-belcher opened pull request #13152: [WIP] [rpc] Add getaddress RPC command (master...2018-04-rpc-getaddress) https://github.com/bitcoin/bitcoin/pull/13152
< bitcoin-git> [bitcoin] laanwj opened pull request #13153: net: Add missing newlines to debug logging (master...2018_05_log_newlines) https://github.com/bitcoin/bitcoin/pull/13153
< fanquake> wumpus new linter inbound..
< wumpus> fanquake: there is a linter for that, but somehow it didn't catch these!
< fanquake> indeed, didn't realise we were checking that https://github.com/bitcoin/bitcoin/blob/master/contrib/devtools/lint-logs.sh
< fanquake> Also, any suggestions for testing #13151 performance improvements?
< gribble> https://github.com/bitcoin/bitcoin/issues/13151 | WIP: net: Serve blocks directly from disk when possible by laanwj · Pull Request #13151 · bitcoin/bitcoin · GitHub
< wumpus> ideally we'd have some tool or script that simply pulls blocks through P2P
< wumpus> just to measure raw download throughput
< wumpus> I vaguely remember someone mentioning this but I'm not sure where or who
< wumpus> I mean you could try to benchmark by making a node sync from another node locally, but verification at the client side would distort the results
< jonasschnelli> hmmm... LMDB seems to consume ~274 bytes for a txindex entry (32byte hash txid, 32byte blockhash). I wonder where to overhead comes from.
< promag> CBlockIndex::nStatus is protected by cs_main?
< jonasschnelli> promag: Yeah. Seams like. Its definitively mutable.
< promag> ty
< bitcoin-git> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/598db389c33e...ef46c9904b80
< bitcoin-git> bitcoin/master ff2ad2d Wladimir J. van der Laan: Add missing newlines to LogPrint debug logging...
< bitcoin-git> bitcoin/master 4b75dcf MarcoFalke: devtools: Make linter check LogPrint calls
< bitcoin-git> bitcoin/master ef46c99 Wladimir J. van der Laan: Merge #13153: Add missing newlines to debug logging...
< bitcoin-git> [bitcoin] laanwj closed pull request #13153: Add missing newlines to debug logging (master...2018_05_log_newlines) https://github.com/bitcoin/bitcoin/pull/13153
< bitcoin-git> [bitcoin] ryanofsky opened pull request #13154: Trivial: s/SetBestChain/ChainStateFlushed in comments after #13106 (master...pr/flushed) https://github.com/bitcoin/bitcoin/pull/13154
< fanquake> Do you get spammed with emails/notifications if your @ mentioned in a commit body, same as what was happening in PRs?
< ryanofsky> what's the difference between https://github.com/bitcoin and https://github.com/bitcoin-core?
< fanquake> ryanofsky In what regard?
< fanquake> /bitcoin was where bitcoin was migrated to from SF. /bitcoin-core houses some core specific repos such as the website, docs etc
< wumpus> right - bitcoin is the legacy organization, bitcoin-core is where most of the repositories have been moved
< ryanofsky> oh ok, so it's just a legacy thing. i didn't know if they two orgs were supposed to have different purposes, or were run by different people or something
< wumpus> it was originally the plan to move the bitcoin repository too, however since the 'bitcoin core' as currency name bullshit from BCHers, that's probably a bad idea and will only contribute towards user confusion
< BlueMatt> well except bips, which will probably always stay in bitcoin
< wumpus> yes, or a 'bips' organization
< fanquake> The crossover between the "teams" in the two orgs is pretty high. Probably just a few more inactive/older users in /bitcoin
< wumpus> yes, if you're in bitcoin but not in bitcoin-core or vice versa, let me know, invites are supposed to go out for both at the same time
< bitcoin-git> [bitcoin] laanwj pushed 5 new commits to master: https://github.com/bitcoin/bitcoin/compare/ef46c9904b80...ef006d92845a
< bitcoin-git> bitcoin/master 73bc1b7 practicalswift: Initialize editStatus and autoCompleter. Previously not initialized where defined or in constructor.
< bitcoin-git> bitcoin/master f131872 practicalswift: Initialize non-static class members where they are defined
< bitcoin-git> bitcoin/master 1e7813e practicalswift: Remove redundant initializations from the constructor
< bitcoin-git> [bitcoin] laanwj closed pull request #12928: qt: Initialize non-static class members that were previously neither initialized where defined nor in constructor (master...qt-constructors) https://github.com/bitcoin/bitcoin/pull/12928
< rafalcpp> hm is this expected that v0.16.0 crashes on start with built with --with-incompatible-bdb ? this issues are closed #6775 (and #12047). System always had libdb5.3 never had libdb4.x (Debian testing 10 from installation)
< gribble> https://github.com/bitcoin/bitcoin/issues/6775 | Bitcoind v0.11.0 segfaults on startup trying to read wallet. · Issue #6775 · bitcoin/bitcoin · GitHub
< gribble> https://github.com/bitcoin/bitcoin/issues/12047 | Segmentation fault if configured with incompatible BDB · Issue #12047 · bitcoin/bitcoin · GitHub
< wumpus> rafalcpp: usually that means that you have multiple versions of berkeleydb installed, and it's compiling against a different one than it's dynamically linking at runtime
< wumpus> but no, that's not normal, I've been compilng with --with-incompaible-bdb for years, and many others do
< rafalcpp> wumpus: I seen that today on debian 10 and debian 9. so reopen?
< wumpus> better to open a new issue, it's not clear this is the same problem
< wumpus> if it's the same problem then reopening doesn't help - it was a local issue (ABI conflict)
< thelox95> hi?
< bitcoin-git> [bitcoin] practicalswift closed pull request #12665: Add compile time checking for run time locking assertions (master...compile-time-checking-of-runtime-assertions) https://github.com/bitcoin/bitcoin/pull/12665
< jamesob> are there any caveats we know of re: usage of std::mutex/std::lock_guard on windows? I'm seeing some weird unhandled page faults only on windows with pretty vanilla usage of these constructs
< sipa> jamesob: care to create a minimal reproduction?
< jamesob> sipa: yeah, I might have to go down that road
< jamesob> sipa: this is as concise as I've gotten it so far https://gist.github.com/jamesob/fe9a872051a88b2025b1aa37bfa98605
< jamesob> updated with something simpler yet
< jamesob> hm, seems to have to do with thread_local usage
< jamesob> either windows c++11 compiler is subtly busted or I don't understand c++; updated the gist with a patch that makes it work: https://gist.github.com/jamesob/fe9a872051a88b2025b1aa37bfa98605#file-works-cpp-L13
< booyah> jamesob: why this_id would need to be static? instead of simple std::string local variable?
< jamesob> booyah: in the real usecase, we're trying to establish a unique ID per thread on a one-time basis
< sipa> jamesob: wouldn't surprise me if thread_local is broken in some mingw versions
< jamesob> sipa: certainly appears so. I'm just gonna avoid using it altogether on WIN32
< booyah> jamesob: would you report a bug to compiler devels?
< jamesob> booyah: yeah probably
< booyah> jamesob: ##c++ <Svitkona> both are working fine on msvc
< jamesob> as sipa says, it may be a mingw32-specific thing
< booyah> jamesob: maybe this bug? https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83562
< jamesob> booyah: I can't repro that
< sipa> jamesob: wouldn't it be easier to just always use std::this_thread::get_id() ?
< jamesob> sipa: I'd love to do that provided we can assume it's always compatible with boost threads
< sipa> do we use boost threads anywhere?
< sipa> seems we do.
< sipa> alternatively, i expect boost::this_thread::native_handle to always work
< sipa> oh, that may not exist
< jamesob> sipa: even if it did, wouldn't we have to have a bunch of platform-specific cases?
< sipa> if std::this_thread::get_id works everywhere, could we try that?
< jamesob> sure thing
< sipa> also, no need to convert to std::string; you can use std::thread::id as a map key
< jamesob> willdo
< promag> jnewbery: re #10740, should it be possible to specify an absolute path if it's in the walletdir?
< gribble> https://github.com/bitcoin/bitcoin/issues/10740 | [wallet] `loadwallet` RPC - load wallet at runtime by jnewbery · Pull Request #10740 · bitcoin/bitcoin · GitHub
< promag> BlueMatt: mind revisit #12151?
< gribble> https://github.com/bitcoin/bitcoin/issues/12151 | Remove cs_main lock from blockToJSON and blockheaderToJSON by promag · Pull Request #12151 · bitcoin/bitcoin · GitHub