< fanquake> Would anyone be opposed to having a "configuration.md" in /docs/ that explains ./configure usage and dependency -> configure option mappings?
< fanquake> At the moment there's so much random configure documentation shotgunned all over the place. I think it'd make sense to put it all in one place, and always point back to that from other docs.
< luke-jr> fanquake: ./configure --help?
< fanquake> luke-jr: Is your suggestion is to replace every mention of configure options/related info in all the documentation with "go look at ./configure --help"? I don't think that's the answer, unless we want to add a lot more info to that configure output.
< fanquake> We also do mention that in the docs at least once already: https://github.com/bitcoin/bitcoin/blob/master/doc/build-unix.md#additional-configure-flags
< luke-jr> dunno, aside from dependencies (which have a dedicated doc file) what else is there to say?
< fanquake> Well at the moment there's configure related suggestions/info spread out all through the build-* files, productivity.md, dependencies.md, developer-notes.md etc. So clearly a fair bit.
< fanquake> Although a lot of it's repeated, hence why I think consolidating is worthwhile. I'll PR some changes and everyone can take a look.
< bitcoin-git> [bitcoin] fanquake opened pull request #16677: gui: remove unused PlatformStyle::TextColorIcon (master...remove_unused_text_coloricon) https://github.com/bitcoin/bitcoin/pull/16677
< fanquake> I've just merged #16674, however the PR hasn't been auto-closed, and the bot obviously hasn't shown up here. Looking at https://www.githubstatus.com/, it could be a GitHub issue.
< gribble> https://github.com/bitcoin/bitcoin/issues/16674 | refactor: remove obsolete qt algorithm usage by fanquake · Pull Request #16674 · bitcoin/bitcoin · GitHub
< bitcoin-git> [bitcoin] fanquake merged pull request #16674: refactor: remove obsolete qt algorithm usage (master...remove_obselete_qt_usage) https://github.com/bitcoin/bitcoin/pull/16674
< bitcoin-git> [bitcoin] shargon opened pull request #16678: [validation] static_assert to ensure width in unit class (master...fix-uint) https://github.com/bitcoin/bitcoin/pull/16678
< bitcoin-git> [bitcoin] shargon closed pull request #16678: [validation] static_assert to ensure width in unit class (master...fix-uint) https://github.com/bitcoin/bitcoin/pull/16678
< bitcoin-git> [bitcoin] shargon opened pull request #16679: [validation] static_assert to ensure width in unit class (master...fix-unit-base) https://github.com/bitcoin/bitcoin/pull/16679
< bitcoin-git> [bitcoin] fanquake pushed 4 commits to master: https://github.com/bitcoin/bitcoin/compare/6dfa9efa3f55...868a8cea1550
< bitcoin-git> bitcoin/master fea33cb fanquake: refactor: replace qStableSort with std::stable_sort
< bitcoin-git> bitcoin/master 59373e3 fanquake: refactor: replace qSort with std::sort
< bitcoin-git> bitcoin/master 153d9dd fanquake: refactor: replace qLowerBound & qUpperBound with std:: upper_bound & lower...
< bitcoin-git> [bitcoin] MarcoFalke pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/868a8cea1550...52b9797119d5
< bitcoin-git> bitcoin/master fa8cd6f MarcoFalke: util: Add Join helper to join a list of strings
< bitcoin-git> bitcoin/master faebf62 MarcoFalke: rpc: Use Join helper in rpc/util
< bitcoin-git> bitcoin/master 52b9797 MarcoFalke: Merge #16670: util: Add Join helper to join a list of strings
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #16670: util: Add Join helper to join a list of strings (master...1908-utilStringJoin) https://github.com/bitcoin/bitcoin/pull/16670
< bitcoin-git> [bitcoin] jtimon opened pull request #16680: Preparations for more testchains (master...b19-testchains-qt) https://github.com/bitcoin/bitcoin/pull/16680
< jtimon> I don't think https://github.com/bitcoin/bitcoin/pull/8994 needs conceptual review, it needs review and testing
< jtimon> on the other hand, I think #16524 #16526 and #16527 do need conceptual review
< gribble> https://github.com/bitcoin/bitcoin/issues/16524 | Wallet: Disable -fallbackfee by default by jtimon · Pull Request #16524 · bitcoin/bitcoin · GitHub
< gribble> https://github.com/bitcoin/bitcoin/issues/16526 | A: Refactor: Chainparams: readability by jtimon · Pull Request #16526 · bitcoin/bitcoin · GitHub
< gribble> https://github.com/bitcoin/bitcoin/issues/16527 | B: Get rid of Params().RequireStandard() by jtimon · Pull Request #16527 · bitcoin/bitcoin · GitHub
< bitcoin-git> [bitcoin] jtimon opened pull request #16681: QA: Adapt BitcoinTestFramework for chains other than "regtest" (master...b19-testchains-tests) https://github.com/bitcoin/bitcoin/pull/16681
< emilengler> How do I write a release note?
< emilengler> Like is there a file for the upcoming release where PR authors can append their change?
< bitcoin-git> [bitcoin] jnewbery opened pull request #16682: net_processing: Disconnect blocks-only peers that send us tx INVs (master...2019-08-disconnect-blocksonly-violators) https://github.com/bitcoin/bitcoin/pull/16682
< jonatack> emilengler: https://github.com/bitcoin/bitcoin/blob/master/doc/developer-notes.md#release-notes then see release note commits for examples
< emilengler> jonatack: thanks
< meshcollider> meeting?
< jnewbery> hi
< jonasschnelli> hi
< provoostenator> hi
< jeremyrubin> hi
< ariard> hi
< sipa> hi
< dongcarl> hi
< meshcollider> ping wumpus
< dongcarl> 0 received, 100% packet loss
< jonasschnelli> #startmeeting
< lightningbot> Meeting started Thu Aug 22 19:03:23 2019 UTC. The chair is jonasschnelli. Information about MeetBot at http://wiki.debian.org/MeetBot.
< lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
< jonasschnelli> There are no proposed topics
< jonasschnelli> (so far)
< meshcollider> #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier jl2012 achow101 meshcollider jnewbery maaku fanquake promag provoostenator aj Chris_Stewart_5 dongcarl gwillen jamesob ken281221 ryanofsky gleb moneyball
< jonasschnelli> #topic high priority for review
< gleb> hi
< jonasschnelli> Anything to change?
< achow101> hi
< wumpus> test
< jonasschnelli> pong
< wumpus> wow, i'm visible now?
< meshcollider> wumpus: Yep
< wumpus> apparently I wasn't authenticated with freenode so no one was seeing my messages? this was really strange\
< wumpus> was already surprised why the meetingstart bot wasn't working
< achow101> how long has wumpus been shouting into the void?
< jonasschnelli> heh
< meshcollider> provoostenator has had similar issues before I think
< wumpus> about five minutes :)
< jeremyrubin> we miss anything good?
< jonasschnelli> omg... must have felt terrible
< wumpus> no, about the same jonasschnelli did :)
< harding> FYI,I saw "hi" or similar from the following people. If you're not listed, you might be muted. meshcollider jnewbery jonasschnelli provoostenator jeremyrubin ariard sipa dongcarl gleb achow101 (and, just now, wumpus).
< provoostenator> meshcollider: indeed, that's always fun
< wumpus> so anyhow, feel free to keep chairing the meeting
< meshcollider> So far no one has any topics
< jonasschnelli> Looks like non of the high prio PR's are ready to merge,...
< dongcarl> #proposedmeetingtopic upgrade to C++17
< jtimon> hi
< jonasschnelli> #topic upgrade to C++17 (dongcarl)
< dongcarl> I looked at the history a little, and there was a PR for upgrading to C++14
< wumpus> I think no one was prepared for that one
< jeremyrubin> What are the major new features?
< dongcarl> I believe that 17 has a lot of functionality that would simplify our codebase
< wumpus> would it replace any boost use?
< dongcarl> wumpus: Yes, I believe we rely on boost::optional
< wumpus> what would be minimum supported clang and gcc? which linux distros carry those? what about debian stable?
< wumpus> I think we have our own optional<>
< wumpus> but that's not really a big deal
< dongcarl> our own optional is just a wrapper around boost optional
< kanzure> hi
< dongcarl> Also c++17 has a filesystem module
< dongcarl> The minimum for ALL 17 is GCC8
< dongcarl> debian stable is on 8
< dongcarl> and RHEL dts is on 8
< achow101> are we going to just skip 14?
< wumpus> ubuntu 18.04 still has 7.4.0
< wumpus> ther's no way we're going to do this yet, imo, sorry
< dongcarl> Okay
< wumpus> achow101: 14 was not worth it, 17 probably is, but it's imo too early
< wumpus> but others might have other opinions
< dongcarl> Ubuntu has 8 packaged
< achow101> most of gcc 7 has 17
< wumpus> yes, but the default is 7.4.0
< achow101> err... gcc 7 has most of 14
< wumpus> I don't really want to cause people trouble for no good reason
< achow101> *17
< jeremyrubin> there doesn't seem to be too much new in 14+17
< jeremyrubin> the filesystem module seems compelling tho
< dongcarl> this is the only feature that requires GCC8: http://wg21.link/p0512r0
< jeremyrubin> But IIRC wumpus had some work that was replacing the fs module
< wumpus> has anyone tried replacing boost filesystem with it in our usage? anything missing?
< ryanofsky> wumpus, any people you are worried about in particular? i'd expect most non-developers to just use binaries and not be affected
< sipa> for a long time we had C++11-minus-thread_local as guideline; perhaps there is something similar for C++17 that would bring the compatibility up?
< wumpus> ryanofsky: I'd like bitcoind to be easily buildable on a wide range of systems such as VPSes and such
< wumpus> many people build bitcoin from source
< sipa> i'd like c++17, but not until it's easily supportable on all reasonable systems
< ryanofsky> so we are worried about the type of person who knows how to build bitcoin from source, but not how to install an updated compiler
< dongcarl> GCC7 has everything but one obscure C++17 feature: https://gcc.gnu.org/projects/cxx-status.html#cxx17
< dongcarl> What systems are we concerned about?
< wumpus> please, installing an updated compiler can be nasty on some platforms
< wumpus> gcc7 as requirement might be ok, but 8 is not
< ryanofsky> wumpus, i guess i'm not aware...
< dongcarl> I'm sorry I misspoke
< sipa> also, there is a historical case of a miner not wanting to update because he couldn't get a c++11 compatible compiler or something
< wumpus> I think we should have this discussion on github, not in the meeting
< MarcoFalke> I'd say that installing a package (compiler or anything) not through a package manager should not be encouraged by us
< dongcarl> Okay
< ryanofsky> yeah, it'd be good to know specifics of who would be affected
< jnewbery> why is this off-topic for a meeting?
< meshcollider> So C++17-class_template_argument_ddeduction might be ok then
< wumpus> MarcoFalke:yes it sounds strange to me
< wumpus> jnewbery: it's not off topic
< wumpus> but I think this requires a fair amount of research, to see what is affected and what not
< wumpus> and als o*why* we want this
< wumpus> and maybe someone actualy implementing the fs stuff using std filesystem and seeing what comes up
< wumpus> it seem a bit random to just propose 'oh let's bump the requirement to c++17'
< MarcoFalke> There was an issue on C++14 and it was rejected because centos and similar didn't ship a C++14 compiler. Unless this changes, we don't even need to chat about C++17
< wumpus> but that might be just me
< sipa> well when we eventually want to switch to c++17 we will want to discuss it in the meeting
< dongcarl> I'm sorry, I might be mis-remembering, but in the previous C++14 PR, someone requested for things like this to be discussed in a meeting
< jnewbery> I think it's useful to solicit opinions in a meeting
< dongcarl> So that's what I did
< sipa> but it sounds like we may not have enough information right now
< wumpus> dongcarl: sure
< dongcarl> I'll open an issue, we'll discuss there
< jonasschnelli> ack
< wumpus> ack, thanks
< jonasschnelli> I guess it needs a rational. Benefits / risks / user-costs
< wumpus> right
< jonatack> hi
< meshcollider> Centos still has 4.8.5 from what I can see
< MarcoFalke> jup
< MarcoFalke> So first we'd need to wait for centos 8 to come out and then give users plenty of time to upgrade
< wumpus> it'd be too late for 0.19 anyhow, but probably not 0.20 (in half a year) then either
< MarcoFalke> apparently they have an rc out
< wumpus> a reminder that 0.19 release date is getting pretty close, soft string freeze is 2019-09-01, feature freeze 2019-09-15, that's less than a month
< sipa> thanks
< wumpus> we probably should start prioritizing features for review that need to make it in for 0.19
< wumpus> or at least, would be nice to make it in
< MarcoFalke> quick. Merge all the things!111!!!
< wumpus> heh
< wumpus> ok, any other topics?
< wumpus> #endmeeting
< jonasschnelli> #endmeeting
< lightningbot> Meeting ended Thu Aug 22 19:30:33 2019 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
< elichai2> Is it ok to open an issue listing wanted features in 14+17 and then I/we can update current status of compilers and OSs? (and say if these features are even worth it)
< wumpus> elichai2: sure, but I think dongcarl is opening an issue about it
< dongcarl> elichai2: I'll link you
< elichai2> ok dongcarl send the link and i'll comment there :)
< jtimon> I don't think it belonged in the meeting, but as said, I don't think #8994 needs the "needs conceptual review" tag, while #16524 #16526 and #16527 need it (specially the last 2, since they compete with each other)
< gribble> https://github.com/bitcoin/bitcoin/issues/8994 | Testchains: Introduce custom chain whose constructor... by jtimon · Pull Request #8994 · bitcoin/bitcoin · GitHub
< gribble> https://github.com/bitcoin/bitcoin/issues/16524 | Wallet: Disable -fallbackfee by default by jtimon · Pull Request #16524 · bitcoin/bitcoin · GitHub
< gribble> https://github.com/bitcoin/bitcoin/issues/16527 | B: Get rid of Params().RequireStandard() by jtimon · Pull Request #16527 · bitcoin/bitcoin · GitHub
< gribble> https://github.com/bitcoin/bitcoin/issues/16526 | A: Refactor: Chainparams: readability by jtimon · Pull Request #16526 · bitcoin/bitcoin · GitHub
< bitcoin-git> [bitcoin] BlockMechanic opened pull request #16686: Fix missing destructor in class (master...master) https://github.com/bitcoin/bitcoin/pull/16686
< dongcarl> Is there a better way to terminate message deserialization early (when you encounter absurdities) than to throw an exception in `Unserialize` and catching it in `ProcessMessages`?
< provoostenator> Sorry for the join/leave noise. Vanity IPv6 address achieved :-)
< provoostenator> (brushing up my IP tables understandings, because I'm reorganzing my DNS seeds)
< bitcoin-git> [bitcoin] elichai opened pull request #16687: Taproot :) (master...taproot-rebase-52b9797) https://github.com/bitcoin/bitcoin/pull/16687
< bitcoin-git> [bitcoin] jnewbery closed pull request #16687: Taproot :) (master...taproot-rebase-52b9797) https://github.com/bitcoin/bitcoin/pull/16687
< bitcoin-git> [bitcoin] jkczyz opened pull request #16688: log: Add validation interface logging (master...2019-08-validation-logging) https://github.com/bitcoin/bitcoin/pull/16688
< bitcoin-git> [bitcoin] ariard opened pull request #16689: Add missing fields in some rpc wallets helps (master...2019-08-missing-fields-rpcs-help) https://github.com/bitcoin/bitcoin/pull/16689