< bitcoin-git> [bitcoin] hebasto opened pull request #22281: build: Avoid @GLIBC_2.29 libm symbols when --enable-glibc-back-compat (master...210619-lm) https://github.com/bitcoin/bitcoin/pull/22281
< bitcoin-git> [bitcoin] MarcoFalke pushed 5 commits to master: https://github.com/bitcoin/bitcoin/compare/0f47e01d7d49...e172ea880498
< bitcoin-git> bitcoin/master faff3f3 MarcoFalke: test: Add txin.sequence option to MiniWallet
< bitcoin-git> bitcoin/master fab871f MarcoFalke: test: Remove unused generate() from test
< bitcoin-git> bitcoin/master fab7e99 MarcoFalke: test: Use MiniWallet in test_no_inherited_signaling RBF test
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #22210: test: Use MiniWallet in test_no_inherited_signaling RBF test (master...2106-testMiniWallet) https://github.com/bitcoin/bitcoin/pull/22210
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/e172ea880498...965e93743454
< bitcoin-git> bitcoin/master 906d791 Andrew Poelstra: fuzz: add missing ECCVerifyHandle to base_encode_decode
< bitcoin-git> bitcoin/master 965e937 MarcoFalke: Merge bitcoin/bitcoin#22279: fuzz: add missing ECCVerifyHandle to base_enc...
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #22279: fuzz: add missing ECCVerifyHandle to base_encode_decode (master...2021-06--fuzztestix) https://github.com/bitcoin/bitcoin/pull/22279
< bitcoin-git> [bitcoin] MarcoFalke pushed 6 commits to 0.21: https://github.com/bitcoin/bitcoin/compare/419f9b3b3b7c...926f76cb205c
< bitcoin-git> bitcoin/0.21 65ce833 Andrew Chow: gitian: install signapple in gitian-osx-signer.yml
< bitcoin-git> bitcoin/0.21 2f33e33 Andrew Chow: gitian: use signapple to apply the MacOS code signature
< bitcoin-git> bitcoin/0.21 27d691b Andrew Chow: gitian: use signapple to create the MacOS code signature
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #22191: [0.21] gitian: Use custom MacOS code signing tool (0.21...0.21-signapple) https://github.com/bitcoin/bitcoin/pull/22191
< bitcoin-git> [bitcoin] MarcoFalke pushed 6 commits to 0.20: https://github.com/bitcoin/bitcoin/compare/5d2ebdd2b71f...466acb3fbcf5
< bitcoin-git> bitcoin/0.20 a2650f6 Andrew Chow: gitian: install signapple in gitian-osx-signer.yml
< bitcoin-git> bitcoin/0.20 f834485 Andrew Chow: gitian: use signapple to apply the MacOS code signature
< bitcoin-git> bitcoin/0.20 9c7c0e6 Andrew Chow: gitian: use signapple to create the MacOS code signature
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #22192: [0.20] gitian: Use custom MacOS code signing tool (0.20...0.20-signapple) https://github.com/bitcoin/bitcoin/pull/22192
< bitcoin-git> [bitcoin] klementtan opened pull request #22282: refactor: CheckFinalTx pass by reference instead of ptr (master...CheckFinalTx_ptr_to_ref) https://github.com/bitcoin/bitcoin/pull/22282
< glozow> ariard: thanks, I'll take a look.
< bitcoin-git> [bitcoin] dgoncharov opened pull request #22283: build: Replace $(AT) with .SILENCE. (master...replace_AT_with_dotsilence) https://github.com/bitcoin/bitcoin/pull/22283
< bitcoin-git> [bitcoin] jonatack opened pull request #22284: p2p, refactor: performance improvements to ProtectEvictionCandidatesByRatio() (master...ProtectEvictionCandidatesByRatio-perf-enhancements) https://github.com/bitcoin/bitcoin/pull/22284
< kittywhiskers> noticed the addition of crc32c to the subtree, been a bit since i've seen recent developments
< kittywhiskers> how is a library decided to be committed to the source tree or added as depends pkg?
< kittywhiskers> i get why submodules are not ideal, github doesn't generate source archives with submodule trees but i'm still curious as to how those decisions are made
< sipa> we use git subtrees
< bitcoin-git> [bitcoin] whitslack opened pull request #22285: contrib/init: (OpenRC) use -startupnotify to wait for startup completion (master...openrc-startupnotify) https://github.com/bitcoin/bitcoin/pull/22285
< kittywhiskers> never heard of it till now, a light reading shows that it creates a bit of overhead but that makes sense for a project like core
< sipa> and the decision to use a subtree vs external dependency depends on (a) how tightly consensus code needs it (we don't want consensus-relevant things to just pick whatever version is available on your system and (b) how readily available it is as a package
< sipa> crc32 is a dependency of leveldb, en leveldb is used for the UTXO set, so we want control over the version used
< sipa> libqrencode for example is just used by the GUI, and easily available
< sipa> so that isn't a subtree
< kittywhiskers> makes sense then, just figured that maybe core could fork the repo, issue a core-specific release and link the URL to that archive as a depends pkg
< kittywhiskers> best of both worlds, i'm asking as i'm interested in implementing cmake secp support
< kittywhiskers> just dipping my toes in the pond to see if that's welcome
< sipa> we do have our fork of leveldb; https://github.com/bitcoin-core/leveldb
< sipa> that's what's being subtreed
< kittywhiskers> i thought that repo was abandoned for some reason, huh
< sipa> hmm, maybe we use upstream now
< sipa> i'm not entirely sure!
< kittywhiskers> yeah, the basic dev docs don't mention subtrees anywhere so this is news to me
< kittywhiskers> i've usually just went along with it, just now that i think about it, figured i'd pop in and ask instead of filing a github issue about it :P
< sipa> oh they are documented somewhere
< sipa> in doc/developer-notes.md
< sipa> regarding libsecp256k1... #secp256k1 is probably a better place
< sipa> but in short, there is a (rather slow) ongoing effort of reducing the burden of the build system
< sipa> and we're pretty close to just being able to build by invoking a C compiler in many settings
< kittywhiskers> i did some preliminary work on getting bitcoin core to build using cmake, like how monero does it
< kittywhiskers> that then got me into univalue, secp256k1 and then so on and so forth, luckily leveldb already uses cmake
< sipa> well i don't think bitcoib core will switch to cmake
< kittywhiskers> i don't mean as a replacement, the current system seems more than efficient
< kittywhiskers> merely in parallel
< sipa> ok
< kittywhiskers> though i do think long term with process separation, cmake does seem like a good option
< kittywhiskers> also, turns out the first references to subtrees were five years ago, i should really read more than build-generic.md :P
< kittywhiskers> would a PR that tries to unify all instances of the word "Bitcoin" be welcome?
< sipa> what do you mean?
< kittywhiskers> similar to the PR that unified all uses of BTC across the codebase, now that with the word Bitcoin itself
< kittywhiskers> i think the idea of having a refactor where all references to bitcoin in filenames are replaced with core and all mentions of Bitcoin in the source lead back to a static variable is worth considering
< sipa> i'd need to see the PR to know what you mean... generally PRs that touch code in lots of different places are annoying
< kittywhiskers> yeah, it would break tons of existing PRs so it'll have to be done in small bits
< sipa> that doesn't sound worth doing... just high cost low benefit
< kittywhiskers> afaik there's already precedent with Cryptonote doing something similar, you name the asset something and keep the name separate from the software that implement's the underlying protocol, marking a distinction between the two
< kittywhiskers> yeah, it would be a pain to manoeuvre but figured if done in an organised fashion, it would be viable
< kittywhiskers> starting with class names, filenames and then slowly changing out references across the interface to the static value, in a similar way to something like the CAmount refactor or the ticker refactor
< sipa> oh you mean in the source code, not something observable?
< sipa> i think that's very unlikely to attract reviewer attention
< kittywhiskers> i was hoping to start with non-observable portions and then work up my way to the UI
< kittywhiskers> my interest in this stems from the core's forks resorting to a very liberal use of search-and-replace that makes porting changes to-and-from projects a real inconvenience, even if they're fundamentally based on the same version
< kittywhiskers> i think even litecoin, which is relatively conservative in their use of SaR deals with merge conflicts from inlining
< sipa> no offense, but i couldn't care less about that
< kittywhiskers> eh, fair enough
< kittywhiskers> no offence taken
< kittywhiskers> still think it's a neat refactoring idea, figured i'd ask as there already seemed to be precedent
< kittywhiskers> i don't mind having to rebase the repo again and again, i planned on doing it as a series of scripted-diffs anyways, just wanted to see the response before i sit down and get to it