< 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.
< 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>
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
< 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
< 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
< 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.
< 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/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)
< 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)
< 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