< 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
< 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
< 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>
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
< 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
< 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