<bitcoin-git>
bitcoin/master 1c07500 brunoerg: contrib: make DNS seeds file an argument in CLI
<bitcoin-git>
bitcoin/master 5a80086 MarcoFalke: Merge bitcoin/bitcoin#26701: contrib: make DNS seeds file an argument in C...
<bitcoin-git>
[bitcoin] MarcoFalke merged pull request #26701: contrib: make DNS seeds file an argument in CLI (`makeseeds`) (master...2022-12-seeds-improv) https://github.com/bitcoin/bitcoin/pull/26701
SpellChecker has quit [Quit: bye]
Guyver2 has left #bitcoin-core-dev [Closing Window]
<bitcoin-git>
[bitcoin] fanquake merged pull request #17127: util: Set safe permissions for data directory and `wallets/` subdir (master...20191013-permissions) https://github.com/bitcoin/bitcoin/pull/17127
fiatjaf has joined #bitcoin-core-dev
<hebasto>
#proposedmeetingtopic No longer consider Ubuntu Bionic as a supported build platform
<_aj_>
hebasto: after april, it enters "extended security maintenance" which means security and other updates are only available to "ubuntu pro" (or "advantage") subscribers; that seems "end of life" for our purposes...?
FrancisMr has joined #bitcoin-core-dev
PaperSword has quit [Quit: PaperSword]
<hebasto>
_aj_: indeed
jespada has quit [Remote host closed the connection]
AmunRa has quit [Remote host closed the connection]
AmunRa has joined #bitcoin-core-dev
vasild has quit [Remote host closed the connection]
vasild has joined #bitcoin-core-dev
bugs_ has joined #bitcoin-core-dev
<provoostenator>
How is --m_dir M_DIR of fuzz/test_runner.py supposed to be used? 'Merge inputs from this directory into the corpus_dir.'
<MacroFake>
provoostenator: I think you can specify any directories that should be merged. Like --m_dir /tmp/gen_a --m_dir /tmp/gen_b /into/your/corpora/dir
<provoostenator>
Should it be set to wherever src/test/fuzz/fuzz puts new corpus entries?
<MacroFake>
oh, it is supposed to merge stuff from fuzz farms, that run all fuzz tests.
<MacroFake>
If you only want to merge one target you can just use libfuzzer direclty
<provoostenator>
Ok, so just ignore fuzz/test_runner.py then?
<MacroFake>
yeah
<provoostenator>
It's a bit confusing, because the QA pull request template points to it.
<MacroFake>
oh
<MacroFake>
"pulls welcome"
<provoostenator>
And the explanation around what merging does is a bit sparse.
<MacroFake>
yeah, could link to libfuzzer docs or google/fuzzing docs, or so?
pablomartin has quit [Ping timeout: 248 seconds]
<MacroFake>
hebasto: I wonder if the cmake stuff can be split out for just the tests (fuzz, unit, bench, etc) and continue to compile bitcoind with the existing makefile for one release
<MacroFake>
(Not sure if it makes sense or if it is even possible)
<provoostenator>
It would be easier if the quickstart example used it.
<MacroFake>
provoostenator: Pulls also welcome for that :)
<provoostenator>
Yeah, but can't make those until I understand what I'm doing.
<hebasto>
MacroFake: CMake-based and Autotools-based systems can co-exist for one release
<MacroFake>
but you'd have to compile all (intermediate) libraries twice?
<hebasto>
right; mind elaborating your initial question then?
<MacroFake>
I am asking because I want to get rid of boost test. It seems really archaic with basically no nice features, and ctest might give some.
<MacroFake>
Or what is a modern, nice, and simple unit test framwork these days?
<MacroFake>
Even if the only new feature is a summary at the end, showing the duration of each unit test
<vasild>
Personally, I would choose ctest over boost test for a new project and would be happy to see us switch, but I am not sure whether we use some boost-specific stuff or how much effort is it to do the switch.
<hebasto>
for now, my branch re-uses boost (no unit tests code touched), and uses CTest as a driver
<real_or_random>
I was looking into this for secp256k1 recently but the requirements are somewhat different. We really need something that works with pure C89 and is minimalistic. But there are a bunch of nice C(++) unit test frameworks out there, with different degrees of simplicity vs features
<bitcoin-git>
bitcoin/master faff2ba MarcoFalke: Remove reindex special case from the progress bar label
<bitcoin-git>
bitcoin/master 1bcabe6 MarcoFalke: Merge bitcoin-core/gui#697: Remove reindex special case from the progress ...
<bitcoin-git>
[gui] MarcoFalke merged pull request #697: Remove reindex special case from the progress bar label (master...2301-gui-reindex-👖) https://github.com/bitcoin-core/gui/pull/697
<real_or_random>
https://github.com/Snaipe/Criterion looks awesome for example, though that one tends to be more on the side of more features
<real_or_random>
https://nemequ.github.io/munit/#faq has a nice list but I think this is still all focused on C. I can imagine that there are much more choices if you don't need C support but only C++
hg has joined #bitcoin-core-dev
dviola has quit [Ping timeout: 248 seconds]
dviola has joined #bitcoin-core-dev
<fanquake>
Please don't give us two build systems to maintain at the same time
<fanquake>
The switchover is going to be bad enough, without some weird interim period of having two
<MacroFake>
fanquake: Will it? The makefile won't have to be touched because cmake is added. So the overhead should be ~0, unless one adds a new file or removes one, which seems rare enough.
<MacroFake>
The alternative is that the makefile is removed right away and there is no fallback for users that run into issues
<MacroFake>
real_or_random: Thanks, will take a look at your list
<fanquake>
MarcroFake: I'm not sure what you mean by "the makefile"
<fanquake>
I don't see any benefit to maintaining multiple build systems. If we want to switch to cmake, we should just switch, dropping autotools entirely, after the 25.x branch off.
<fanquake>
It's nice that we are finding more reasons to make the switch. As the current list (from the description in 25797) which is essentially of "better for the gui" and "better for windows", are incredibly weak reasons to break all downstream infra, build scripts, CI, oss-fuzz type integrations, etc etc. Especially when all those users don't care at all about Windows or the GUI.
<fanquake>
Reasoning like, "it's faster", "a new test driver" or "improved clang-tooling integration" are the things we should really be caring about.
jespada has joined #bitcoin-core-dev
<jonatack1>
provoostenator: if you have fuzz builds and fuzzers working on ARM64 macOS Ventura, could you update the macOS section of fuzzing.md? The path looks out of date, and at first try I had issues with the fuzz build
<provoostenator>
My Linux box is faster now :-)
<jonatack1>
Ah ;)
Torben has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] fanquake opened pull request #27056: doc: use arch agnostic clang path in fuzzing doc (macOS) (master...macos_fuzzing_doc_arch_agnostic) https://github.com/bitcoin/bitcoin/pull/27056
AmunRa has quit [Ping timeout: 255 seconds]
<fanquake>
Builds still actually fail on arm64 macOS due to a different issue, but the doc now works for either
<vasild>
What if the automake+cmake interim state is never released? I.e. - release 25, add cmake, interim period where people can try cmake and fall back to automake and cmake stuff gets more testing and improvements, polishing, etc, remove automake, release 26
instagibbs has quit [Ping timeout: 268 seconds]
Torben has quit [Ping timeout: 260 seconds]
salvatoshi has quit [Ping timeout: 268 seconds]
<vasild>
What is the maintenance burden actually? If files are added, removed, renamed, if CXX flags are changed, then that would have to be done in both autotools and cmake. Maybe more?
meshcollider has quit [Quit: :wave:]
instagibbs has joined #bitcoin-core-dev
<fanquake>
People should probably start doing their trying of Cmake before we merge it.
<fanquake>
We're already going to have to maintain both, in some sense, because there are a number of years where the previous release branches (and thus the previous build system) are still supported, after any switchover. Prolonging that by then supporting both for some time turns a multi-year deprecation, into a many-year deprecation.
<fanquake>
How fun is it going to be backporting changes from cmake land to autotools land 🤔
AmunRa has joined #bitcoin-core-dev
salvatoshi has joined #bitcoin-core-dev
as2333 has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] fanquake opened pull request #27057: build: set boost cppflags with --enable-fuzz (master...still_set_boost_cppflags_when_enable_fuzz) https://github.com/bitcoin/bitcoin/pull/27057
<fanquake>
Thise also dont have to be adding/removing files type changes (more rare). Things like adding compile flags/options to work around bugs in compilers would also have to be tested and backported into both.
<jonatack1>
fanquake: thanks for the fixes, testing
salvatoshi has quit [Ping timeout: 248 seconds]
brunoerg has quit [Remote host closed the connection]
brunoerg has joined #bitcoin-core-dev
dougefish has quit [Ping timeout: 248 seconds]
AmunRa has quit [Remote host closed the connection]
martin_2 has joined #bitcoin-core-dev
Talkless has joined #bitcoin-core-dev
jonatack1 has quit [Quit: WeeChat 3.8]
AmunRa has joined #bitcoin-core-dev
jonatack has joined #bitcoin-core-dev
jonatack has quit [Client Quit]
jonatack has joined #bitcoin-core-dev
jonatack has quit [Client Quit]
martin_2 has quit [Ping timeout: 248 seconds]
jonatack has joined #bitcoin-core-dev
martin_2 has joined #bitcoin-core-dev
<pinheadmz>
i followed the build-windows.md guide in WSL in "Windows 10 Home" but had to manually install libboost-dev and libevent-dev... should those be added to the doc? Or am I maybe missing something?
dviola has quit [Ping timeout: 248 seconds]
<jamesob>
glozow instagibbs: in v3-land, package replacement is going to be evaluated on the basis package feerate (as well as other RBF criteria), right? i.e. a replacement parent with same feerate but higher aggregate feerate (when including child) will work?
<jamesob>
*on the basis of
<hebasto>
pinheadmz: it is supposed you are cross-compiling using mingw, so boost and libevent will be compiled as dependencies
john-moffett has joined #bitcoin-core-dev
<instagibbs>
jamesob, you're saying the parent is doublespent, and asking how that is evaluated?
martin_2 has quit [Read error: Connection reset by peer]
<jamesob>
instagibbs: yeah. specific case is you initially broadcast the parent without an ephemeral anchor, but then decide after the fact that you want to do an EA and raise feerate via CPFP - is that workable?
<instagibbs>
ah, situation clear. So the replacement would be considered in the package context, replacing package feerate compared against the existing parent in mempool
<instagibbs>
as well as other rules ala bip125 rule#3
<jamesob>
okay, so that would be workable - as long as you're clearing the original fee of the package being displaced
<jamesob>
(+ other RBF rules)
<instagibbs>
if you can reliably RBF you may not need EA
<instagibbs>
anything presigned, or key access is limited for whatever reason
<jamesob>
right, so the quiet part now said out loud of my example is if you have an unauthenticated spend that is being crafted by an attacker, can you retroactively decide to attach an EA
<instagibbs>
sure, but if you don't have "veto power" over all inputs, the parent tx could become arbitrarily large via attacker
<instagibbs>
(up to package limits not arbitrary)
<jamesob>
right
<bitcoin-git>
[bitcoin] achow101 opened pull request #27058: contrib: Improve verify-commits.py to work with maintainers leaving (master...improve-verify-commits) https://github.com/bitcoin/bitcoin/pull/27058
b_101 has quit [Quit: Lost terminal]
b_101 has joined #bitcoin-core-dev
dougefish has joined #bitcoin-core-dev
FrancisMr has joined #bitcoin-core-dev
dviola has joined #bitcoin-core-dev
Talkless has quit [Quit: Konversation terminated!]
dougefish has quit [Ping timeout: 248 seconds]
jarthur has joined #bitcoin-core-dev
dougefish has joined #bitcoin-core-dev
john-moffett has quit [Remote host closed the connection]
john-moffett has joined #bitcoin-core-dev
Nickname has joined #bitcoin-core-dev
Nickname is now known as Guest9
Guest9 has quit [Client Quit]
Nickname777 has joined #bitcoin-core-dev
Nickname777 has quit [Client Quit]
FrancisMr has quit [Ping timeout: 252 seconds]
___nick___ has joined #bitcoin-core-dev
jonatack has quit [Ping timeout: 260 seconds]
___nick___ has quit [Client Quit]
___nick___ has joined #bitcoin-core-dev
AmunRa has quit [Ping timeout: 255 seconds]
AmunRa has joined #bitcoin-core-dev
dougefish has quit [Ping timeout: 248 seconds]
jespada has quit [Remote host closed the connection]
jespada has joined #bitcoin-core-dev
FrancisMr has joined #bitcoin-core-dev
jonatack has joined #bitcoin-core-dev
PaperSword has joined #bitcoin-core-dev
as2333 has quit [Quit: as2333]
as2333 has joined #bitcoin-core-dev
infernix has quit [Ping timeout: 260 seconds]
brunoerg has quit [Remote host closed the connection]
brunoerg has joined #bitcoin-core-dev
infernix has joined #bitcoin-core-dev
Guest4 has joined #bitcoin-core-dev
Guest4 has quit [Client Quit]
fiatjaf has quit [Remote host closed the connection]
salvatoshi has joined #bitcoin-core-dev
infernix has quit [Ping timeout: 248 seconds]
polar48 has joined #bitcoin-core-dev
fiatjaf has joined #bitcoin-core-dev
polar48 has quit [Quit: Client closed]
infernix has joined #bitcoin-core-dev
hg has quit [Quit: WeeChat 3.8]
AaronvanW has quit [Quit: Leaving...]
pablomartin has joined #bitcoin-core-dev
bugs_ has quit [Quit: Leaving]
bitdex has joined #bitcoin-core-dev
brunoerg has quit [Remote host closed the connection]