< bitcoin-git>
bitcoin/master 54c7754 fanquake: build: use aarch64 Clang if cross-compiling for darwin on aarch64
< bitcoin-git>
bitcoin/master 5c8820b fanquake: Merge bitcoin/bitcoin#22436: build: use aarch64 Clang if cross-compiling f...
< bitcoin-git>
[bitcoin] fanquake merged pull request #22436: build: use aarch64 Clang if cross-compiling for darwin on aarch64 (master...arm64_macos_cross_clang) https://github.com/bitcoin/bitcoin/pull/22436
< jnewbery>
fanquake: #22096 and #22261 look ready for merge
< bitcoin-git>
[bitcoin] MarcoFalke merged pull request #22232: refactor: Pass interpreter flags as uint32_t instead of signed int (master...2106-refactorFlags) https://github.com/bitcoin/bitcoin/pull/22232
< laanwj>
it's weird that we got rid of REVISION but not BUILD
< MarcoFalke>
Anyone who does use a regex will have to update it. "Breaking" the format will hopefully "notify" anyone that the regex needs update.
< laanwj>
BUILD is the fourth number, we have an optional fourth number now but not a third one
< MarcoFalke>
I don't expect BUILD to be used
< laanwj>
we did use it sometimes
< laanwj>
but I would have expected to now use REVISION for that, as, it's moved by one
< MarcoFalke>
Hmm, worst case is we just use vX.Y+1 instead of REVISION/BUILD
< laanwj>
now we can have, e.g. v22.0.0.2, v22.1.0.3, etc which is fine,
< bitcoin-git>
[bitcoin] hebasto opened pull request #22506: build: Support x86_64 <-> arm64 cross-compiling for macOS (master...210720-xmac) https://github.com/bitcoin/bitcoin/pull/22506
< laanwj>
I'd personally prefer changing BUILD to REVISION
< laanwj>
getting rid of it completely is an option too of course, but I don't see why we should artificially limit ourselves that way
< bitcoin-git>
[bitcoin] MarcoFalke opened pull request #22507: doc: Adjust commit message template for the guix.sigs repo (master...2107-docGuixCommit) https://github.com/bitcoin/bitcoin/pull/22507
< bitcoin-git>
[bitcoin] apoelstra opened pull request #22508: fuzz: replace every fuzzer-controlled while loop with a macro (master...2021-07--fuzzer-loops) https://github.com/bitcoin/bitcoin/pull/22508
< bitcoin-git>
[bitcoin] siv2r closed pull request #22312: changes for wait_for_getheaders to include hash_list (master...modify-wait-getheaders) https://github.com/bitcoin/bitcoin/pull/22312
< jamesob>
Do we ever expect to support an index that actually requires sequential indexing? Jimpo's BaseIndex advertises that it will index sequentially, but at the moment none of the particular indexers require this. Furthermore, we will have BlockConnected events triggering indexing out of order once we start using background chainstates for assumeutxo.
< sipa>
maybe the index itself can handle this if this ever becomes a requirement?
< sipa>
i.e. it'd cache the last block it is synchronized up to, and only does work when that last block changes
< jamesob>
Hm yeah, I think an indexer subclass could potentially override Init or ThreadSync to build itself once background chainstates are out of use
< jamesob>
But anyway I'm thinking of removing the sequential advertisement (which for now only exists in the class documentation) since we don't even make use of that assumption at the moment
< jamesob>
Hm, am I missing something of does txindex (via BaseIndex) not handle reorgs properly? BlockDisconnected events are not handled by BaseIndex and I can't see where unlinked block txns would be removed from the txindex... I guess this isn't a problem so long as inclusion in the index is not ever treated to mean "confirmed in the active chain"
< sipa>
they're not removed no
< sipa>
it allows you to look up transactions in inactive chains, if they haven't been re-confirmed in the main chain
< jamesob>
good to know - maybe I'll make a note of that in the class doc