< bitcoin-git> [bitcoin] fanquake closed pull request #20440: build: fix determinism issue when building qt with Clang 8 (master...no_echo_fix_clang_qt_determinism) https://github.com/bitcoin/bitcoin/pull/20440
< bitcoin-git> [bitcoin] fanquake closed pull request #20436: depends: Add a nasty qt hack to work around clang non-determinism (0.21...fix-clang-qt-determinism) https://github.com/bitcoin/bitcoin/pull/20436
< wumpus> luke-jr: it's often like that, the "nothing in computers is really new since the 60's" effect :)
< wumpus> I do remember old discussions about compiler determinism (I think 90's?), it was something that mostly came up for niche safety critical systems, there were some really strong voices in gcc compiler devs that didn't regard it as necessary, because there was the perception it was at odds with some heuristic/randomized optimization algorithms
< bitcoin-git> [bitcoin] MarcoFalke opened pull request #20456: test: Fix intermittent issue in mempool_compatibility (master...2011-testFixMempool) https://github.com/bitcoin/bitcoin/pull/20456
< bitcoin-git> [bitcoin] laanwj pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/e9a1c9fbdea9...1b75f2542d15
< bitcoin-git> bitcoin/master fabecce MarcoFalke: net: Treat raw message bytes as uint8_t
< bitcoin-git> bitcoin/master 1b75f25 Wladimir J. van der Laan: Merge #20432: net: Treat raw message bytes as uint8_t
< bitcoin-git> [bitcoin] laanwj merged pull request #20432: net: Treat raw message bytes as uint8_t (master...2011-netBytesUint8) https://github.com/bitcoin/bitcoin/pull/20432
< bitcoin-git> [bitcoin] laanwj pushed 8 commits to master: https://github.com/bitcoin/bitcoin/compare/1b75f2542d15...86bf3ae3b57e
< bitcoin-git> bitcoin/master b33af48 Andrew Chow: Include wallet/bdb.h where it is actually being used
< bitcoin-git> bitcoin/master a58b719 Andrew Chow: Do not compile BDB things when USE_BDB is defined
< bitcoin-git> bitcoin/master 6ebc41b Andrew Chow: Enforce salvage is only for BDB wallets
< bitcoin-git> [bitcoin] laanwj merged pull request #20202: wallet: Make BDB support optional (master...opt-sqlite-bdb) https://github.com/bitcoin/bitcoin/pull/20202
< promag> time to ditch -rpcuser -rpcpassword from daemon?
< wumpus> not sure, really, I think a lot of people are still using them (including me), and it's documented all over the place
< promag> I know
< wumpus> it has always been a difficult thing to deprecate
< wumpus> it's a simple way to specify the user and password *shrug*, does it really complicate the code that much
< promag> no no, I'm just asking X)
< wumpus> sure but I mean an argument like 'it complicates the authentication code a lot' would be in favor of removing them
< promag> it doesn't
< promag> on bitcoin-cliu
< promag> err
< promag> on bitcoin-cli we are sending cookie as authorization: basic ... header
< promag> I think this should be authorization: bearer
< wumpus> lots of other software does that too by now
< wumpus> I don't really see a reason to change it
< promag> do you think it's a reasonable change to do in -cli?
< wumpus> nah, to me it feels like a sudden change out of the blue
< promag> we could start by fixing our clients (cli and test framework)
< wumpus> don't we have any bugs to fix
< promag> ok
< promag> also invalid -rpcauth are just silently ignored, Russel suggested to log and fail init
< promag> makes sense to you?
< wumpus> agree on that
< wumpus> silently ignoring errors is the biggest sin
< promag> ok, also agree
< wumpus> we've come a really long way in that regard!
< wumpus> still remember opening #1044 in frustration :)
< gribble> https://github.com/bitcoin/bitcoin/issues/1044 | Problems with command-line options silently ignored · Issue #1044 · bitcoin/bitcoin · GitHub
< promag> heh opened from 2012 to 2018
< wumpus> yess
< wumpus> not for lack of proposals though, it was just difficult code to change
< wumpus> the code is a lot more organized now
< bitcoin-git> [bitcoin] practicalswift opened pull request #20457: util: Make Parse{Int,UInt}{32,64} use locale independent std::from_chars(…) (C++17) instead of locale dependent strto{l,ll,ul,ull} (master...locale-independent-parseint) https://github.com/bitcoin/bitcoin/pull/20457
< bitcoin-git> [bitcoin] Sjors opened pull request #20458: test: add is_bdb_compiled helper (master...2020/11/use_bdb) https://github.com/bitcoin/bitcoin/pull/20458
< Kiminuo> Hi, can I run locally this test https://cirrus-ci.com/task/6292799064637440?command=ci#L3354 to repeat it exactly? Meaning, to run it in Docker to reproduce the issue.
< wumpus> don't know about docker, but you can run the test suite locally with test/functional/test_runner.py
< Kiminuo> true, but the issue is that I don't see that specific error
< Kiminuo> there is some difference between my environment and of that test
< wumpus> it should be possible to run the ci/* stuff in docker I just don't know exactly how
< Kiminuo> yeah. I was looking for some instructions but I was not successful.
< wumpus> looks like there's something in the readme https://github.com/bitcoin/bitcoin/tree/master/ci
< Kiminuo> ha
< Kiminuo> good, thanks
< bitcoin-git> [bitcoin] MarcoFalke opened pull request #20459: rpc: Fail to return undocumented return values (master...2011-rpcDoc) https://github.com/bitcoin/bitcoin/pull/20459
< vasild> MarcoFalke: I think s/std::fs/std::filesystem/ is warranted in #20460
< gribble> https://github.com/bitcoin/bitcoin/issues/20460 | C++17 std::fs · Issue #20460 · bitcoin/bitcoin · GitHub
< bitcoin-git> [bitcoin] promag opened pull request #20461: qa: Validate -rpcauth arguments (master...2020-11-validate-rpcauth) https://github.com/bitcoin/bitcoin/pull/20461
< bitcoin-git> [bitcoin] laanwj pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/86bf3ae3b57e...b0c9024a7cf6
< bitcoin-git> bitcoin/master 68c2ef1 Andrew Chow: Fix version string in Windows and Mac installers
< bitcoin-git> bitcoin/master b0c9024 Wladimir J. van der Laan: Merge #20449: build: Fix Windows installer build
< bitcoin-git> [bitcoin] laanwj merged pull request #20449: build: Fix Windows installer build (master...fix-gitian-installers) https://github.com/bitcoin/bitcoin/pull/20449
< fanquake> Is it really a surprise when Qt's build system does neither what you've told it to do, or what it's told you it's going todo
< fanquake> Apparently this was more obvious if you'd read the release notes from 3 versions prior
< wumpus> qt's build system is so special
< wumpus> wish they would just switch to one of the standard ones
< fanquake> You tell it to build in c++1z mode (our qt is a little old heh), it tells you it's going to build in c++1z mode, it instead just builds in c++11 mode
< wumpus> 'z' is the verilog symbol for high impedance so it's read as a '1' of course
< fanquake> ah yes of course
< wumpus> well it's good to realize this while in the rc phase i guess
< fanquake> This should only be an issue for master. I'm going to flick all the c++17 switches in depends
< wumpus> right, 0.21 is still entirely built in c++11 mode
< bitcoin-git> [bitcoin] laanwj pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/b0c9024a7cf6...555b5d1bf940
< bitcoin-git> bitcoin/master a52ecc9 fanquake: build: set minimum supported macOS to 10.14
< bitcoin-git> bitcoin/master 555b5d1 Wladimir J. van der Laan: Merge #20419: build: set minimum supported macOS to 10.14
< bitcoin-git> [bitcoin] laanwj merged pull request #20419: build: set minimum supported macOS to 10.14 (master...macos_minimum_10_14) https://github.com/bitcoin/bitcoin/pull/20419
< wumpus> fanquake: I don't entirely understand the outstanding issue in #20422, does it block merge?
< gribble> https://github.com/bitcoin/bitcoin/issues/20422 | build: mac deployment unification by fanquake · Pull Request #20422 · bitcoin/bitcoin · GitHub
< fanquake> wumpus: probably. The issue is that with those changes, if you're on macOS and run make deploy (with the latest mac_alias installed), it will fail, due to what I think is a bug in mac_alias. The cross-compile is unaffected, because we are pinned to the previous version of mac_alias in depends. As a workaround, mac users could also install the previous version.
< fanquake> This hasn't been an issue for mac users until now, because the Python currently used by the native mac build would construct and run an "Applescript", which would modify the dmg during creation (also the source of the annoying "popup" behaviour).
< fanquake> I just haven't been motivated to figure out what the issue is with mac_alias is yet
< wumpus> thanks for explaining, it's more clear to me now
< wumpus> maybe the new version of mac_alias is broken or at the least incompatible with what we do
< fanquake> The previous version came out ~2.5 years ago, so it's quite possible something has broken/changed in a backwards incompatible way.
< fanquake> The new version also adds support for new versions of records as well
< bitcoin-git> [bitcoin] luke-jr opened pull request #20462: RPC/Wallet: unloadwallet: Clarify docs/error when both the RPC request and wallet_name parameter specify a wallet (master...unloadwallet_namematch_pt1) https://github.com/bitcoin/bitcoin/pull/20462
< wumpus> "NameError: name 'kind' is not defined" is a really strange error on assignment to kind
< wumpus> wait... https://github.com/al45tair/mac_alias/blob/master/mac_alias/alias.py#L282 doesn' look like valid python at all
< wumpus> you can't just end a line with assignment targets in ,
< wumpus> would have worked with (kind, volname, ...) with paranthesis around it
< luke-jr> what is cr ACK O.o
< wumpus> fanquake: so clearly an upstream issue!
< wumpus> luke-jr: huh?
< wumpus> I guess cr=code review
< luke-jr> aha, makes sense
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to 0.20: https://github.com/bitcoin/bitcoin/compare/a2fa11f9de78...75bf23d8613a
< bitcoin-git> bitcoin/0.20 fa074d2 MarcoFalke: Revert "Merge #19606: Backport wtxid relay to v0.20"
< bitcoin-git> bitcoin/0.20 75bf23d MarcoFalke: Merge #20399: Revert "Merge #19606: Backport wtxid relay to v0.20"
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #20399: Revert "Merge #19606: Backport wtxid relay to v0.20" (0.20...2011-prepare020release) https://github.com/bitcoin/bitcoin/pull/20399
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/555b5d1bf940...2ee954daaee5
< bitcoin-git> bitcoin/master b87caf1 Sjors Provoost: test: add is_bdb_compiled helper
< bitcoin-git> bitcoin/master 2ee954d MarcoFalke: Merge #20458: test: add is_bdb_compiled helper
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #20458: test: add is_bdb_compiled helper (master...2020/11/use_bdb) https://github.com/bitcoin/bitcoin/pull/20458
< achow101> Should I reopen #20447 for the 0.21 branch?
< gribble> https://github.com/bitcoin/bitcoin/issues/20447 | depends: Patch qt_intersect_spans to avoid non-deterministic behavior in LLVM 8 by achow101 · Pull Request #20447 · bitcoin/bitcoin · GitHub
< MarcoFalke> Is everyone on the clang-9 train? If not, it could make sense for master as well
< hebasto> achow101: I vote for that
< achow101> i think it's reasonable to merge into master and then revert when clang 9 is merged
< hebasto> sounds good
< achow101> i think there's some hesitation about clang 9 because apple has only blessed clang 8 for the sdk we use
< hebasto> I read about that many times in our community, but every time without justification
< achow101> the concern is that clang 9 could have introduced something which apple doesn't like
< achow101> I don't have an opinion on this since I work with neither clang nor macOS
< hebasto> yes, I understand the concern. but is it in real life?
< achow101> afaik there aren't any problems, just vague "maybe there's an edge case"
< vasild_> Ditch old compilers!
< hebasto> new owns have memcmp bug
< MarcoFalke> that's gcc, not clang
< wumpus> definitely for master I'd say just upgrade the compiler
< wumpus> for 0.21 I'd be okay with that as well
< promag> ryanofsky: I think we are discussing in the wrong place, sorry provoostenator
< promag> ryanofsky: with you approach the async function would block right? for instance with Qt::BlockingQueuedConnection. Is this fine?
< wumpus> but for 0.21 I'm also fine with patching the build system or qt spans function, I very much don't like that as a long term solution
< miketwen_> hey .. still trying to figure out what I need to do to get my PR merged for gitian.sigs. Also, fanquake: the newest merged commit in gitian sigs with oliver gugger is breaking the verify script. https://github.com/bitcoin-core/gitian.sigs/issues/1316
< miketwenty1> in reference to my gitian PR. https://github.com/bitcoin-core/gitian.sigs/pull/1307. Would someone tell me what this needs to be merged in.
< bitcoin-git> [bitcoin] MarcoFalke opened pull request #20464: refactor: Treat CDataStream bytes as uint8_t (master...2011-dataStream) https://github.com/bitcoin/bitcoin/pull/20464
< wumpus> you shouldn't have to do anything to get your PR for gitian.sigs merged, it's just that rc1 was kind of abandoned so no one is probably in a hurry
< wumpus> I'll merge it
< wumpus> oh already is okay
< miketwenty1> yeah.. Marco got me
< miketwenty1> thanks though.. will keep my eye out on rc2 or 21.1
< wumpus> great :)
< bitcoin-git> [bitcoin] MarcoFalke opened pull request #20466: test: Fix intermittent p2p_finerprint issue (master...2011-testIntFixp2p) https://github.com/bitcoin/bitcoin/pull/20466
< bitcoin-git> [bitcoin] sipsorcery closed pull request #20392: WIP: Switch appveyor build from Release to Debug (master...msvc-appveyor-debug-build) https://github.com/bitcoin/bitcoin/pull/20392
< bitcoin-git> [bitcoin] MarcoFalke pushed 4 commits to master: https://github.com/bitcoin/bitcoin/compare/2ee954daaee5...cb89e1884585
< bitcoin-git> bitcoin/master fa1f949 MarcoFalke: ci: Run nowallet ci config on cirrus
< bitcoin-git> bitcoin/master fa73674 MarcoFalke: ci: Run i686 centos ci config on cirrus
< bitcoin-git> bitcoin/master fa7a438 MarcoFalke: ci: Fix doc typos in .cirrus.yml
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #19179: ci: Run ci configs on cirrus (master...2006-ciCirrus) https://github.com/bitcoin/bitcoin/pull/19179
< luke-jr> wumpus: might make sense to get Win/Linux rc1 out there for testing at least?
< wumpus> I'm not sure what's the wait for rc2 now
< wumpus> but if it takes much longer to decide which of the competing determinism fixes to do for mac I'd agree, this doesn't affect any other OSes
< wumpus> it doesn't even really affect testing for macos
< wumpus> in any case people that can build from source can test rc1 fine
< luke-jr> but they could have tested master too :P\
< wumpus> sure, almost no difference at the moment
< achow101> would it be reasonable to change CFeeRate::GetFee to always round up?
< bitcoin-git> [bitcoin] dongcarl closed pull request #20019: depends: Properly pass $PATH to configure and pin (master...2020-09-resolve-PATH-prepending-madness) https://github.com/bitcoin/bitcoin/pull/20019
< bitcoin-git> [bitcoin] tylerchambers opened pull request #20468: build: don't allow manpages to be generated for binaries built from a dirty branch (master...fix-20412) https://github.com/bitcoin/bitcoin/pull/20468
< aj> wumpus: re bitcoin-util; would be happy to add "grind" to bitcoin-tx and have a new PR that introduces a bitcoin-util that at least does a few things
< bitcoin-git> [bitcoin] dergoegge opened pull request #20469: build: Avoid secp256k1.h include from system (master...fixincludeorder) https://github.com/bitcoin/bitcoin/pull/20469
< wumpus> aj: I just don't see the principal distinction between bitcoin-util and bitcoin-tx
< sipa> bitcoin-tx only operates on transactions, and allows multiple operations on it
< wumpus> if we would have known in advance that people would want to add utility functions that don't necessarily have to do with transactions, the better name would have been bitcoin-util, but that ship has sailed
< sipa> not sure how you'd integrate non-tx-mutating operations into it
< sipa> i guess you can integrate all bitcoin-tx's operations into a -util, by only allowing one operation per invocation
< wumpus> having only one 'general utilities' binaries would be nice at least
< wumpus> binary*
< luke-jr> library*
< wumpus> I don't particularly want the same as for the fuzzers
< wumpus> it'd be a library if that wasn't so difficult to do in a useful cross-platform usable way
< wumpus> a library has to handle all kinds of things like multi-threaded clients, different dynamic linking concepts, ABIs, bindings to different languages etc etc
< wumpus> try calling from bash into a library
< wumpus> computing is such a mess and we're not going to solve that in this project !!!
< fanquake> we've just decided to solve money instead; because that's much less of a mess!
< sipa> haha
< wumpus> ... well one giant mess at a time is fair isn't it
< midnight> make friends with bunnie and offer accommodation for coreside precursor support if necessary :-D
< * midnight> ducks
< wumpus> let's pretend these things are sepaate and can be solved one at a time, just for old times sake
< luke-jr> fanquake: lol
< wumpus> if not it's such a total screaming madness it's not even addressable
< wumpus> midnight: heh
< luke-jr> I mean, we already need to address threading for our own use…
< luke-jr> bindings don't have to be our problem either, and ABIs are fairly straightforward
< luke-jr> (perhaps not for the user side, but for the library developer)
< wumpus> well it's easier to offer it as an utility, it doesn't rule out making it a library later
< wumpus> there are more design decisions involved inthat.
< wumpus> blame POSIX or the UNIX model or whatever you want *shrug* but as it stands, a process it the most straightforward interface
< luke-jr> it would be nice if C grew the annotations needed to automate bindings
< wumpus> yes
< luke-jr> would also make for better compile-time warnings I bet
< aj> wumpus: i guess i think everything you currently use bitcoin-tx for should switch to psbt's; and it'd be easier to do that via a new command
< wumpus> it would also have been less of a problem to have different binaries (if you want a binary per entry point) if dynamic libraries were more standardized across platforms, right now we use, by necessity, a semi-static linking approach, so every binary ends up duplicating everything it links
< wumpus> because evertyhing is broken it ends up at a (pre-)80's common denominator
< wumpus> aj: you mean the current bitcoin-tx would be deprecated in the long run?
< aj> wumpus: yeah
< aj> wumpus: leave it as-is for compatability for a while of course
< sipa> aj: having a psbt standalone utility would be awesome
< sipa> (i don't have an opinion on inside bitcoin-util or elsewhere)
< wumpus> that makes sense, though I don't see how it relates to the signet grinding functionality
< aj> sipa: #14671 proposes that
< gribble> https://github.com/bitcoin/bitcoin/issues/14671 | Utility to replace RPC calls that dont need wallet or chain context · Issue #14671 · bitcoin/bitcoin · GitHub
< wumpus> it seems kind of detached from everything so you could just as well add it to anything
< sipa> aj: that seems to lack the most useful one :p
< sipa> something that you give one or more PSBTs, and one or more descriptors, and it updates/processes/signs everything it knows how to
< aj> sipa: that needs wallet info?