< aj> is this channel working?
< luke-jr> aj: ?
< sipa> aj: can't speak for this channel, but i'm currently tinkering with a PR, so i think that counts as working?
< luke-jr> XD
< wumpus> the bot was asleep for a while (made a mistake in yaml syntax, it's so easy) should be fixed now
< wumpus> is it that ime of the month to ignore appveyor failures again
< jnewbery> wumpus: #21051 fixes an appveyor failure, so if PRs rebase on master they should work again
< gribble> https://github.com/bitcoin/bitcoin/issues/21051 | Fix -Wmismatched-tags warnings by hebasto · Pull Request #21051 · bitcoin/bitcoin · GitHub
< bitcoin-git> [bitcoin] S3RK opened pull request #21063: wallet, rpc: update listdescriptors response format (master...listdescriptors_format) https://github.com/bitcoin/bitcoin/pull/21063
< wumpus> luke-jr: knots linux gitian build is running out of disk space here, i guess due to the added powerpc platforms
<@wumpus> fanquake_: can you talk again now?
<@wumpus> restored, that didn't make a difference
< fanquake_> ping
<@wumpus> hey !
< sipa> hi
< fanquake> success
<@wumpus> PSA: if you find yourself unable to talk here or change your nick, make sure you're identified with nickserv
< bitcoin-git> [bitcoin] fanquake opened pull request #21064: refactor: use std::shared_mutex & remove Boost Thread (master...use_std_shared_mutex) https://github.com/bitcoin/bitcoin/pull/21064
< wumpus> so boost::preprocessor, boost::thread soon to be gone, boost::filesystem also on the horizon
< wumpus> boost::date_time is only used in one function ParseISO8601DateTime but this ran into some issues last time as there's no good c++11 replacement #17245
< gribble> https://github.com/bitcoin/bitcoin/issues/17245 | wallet: Remove Boost from DecodeDumpTime by elichai · Pull Request #17245 · bitcoin/bitcoin · GitHub
< fanquake> yes. there are two funcs in there that are trivial to replace, and probably should just be done. ParseISO8601DateTime is more difficult.
< wumpus> boost::signals2 is used in quite a lot of places
< wumpus> (most notably gui and other interfaces)
< wumpus> boost::algorithm stuff is trivial to replace when we want to
< sipa> and boost::multiindex is used by mempool and txrequest, and i don't think a replacement outside boost even exists for that
< wumpus> that leaves boost::multi_index and boost::process, I think we'll be stuck with those for now
< sipa> multi_index is header only, which is less of a pain i guess
< wumpus> right
< wumpus> multi_index is the only one that offers unique functionality
< wumpus> we could look into factoring it out into a separate library some day
< wumpus> but yes header-only is good in this case
< wumpus> we might reach the point where we don't need to *compile* boost anymore
< fanquake> also, the boost::system we compile in depends is already a dummy library
< fanquake> It has one symbol, that is dummy_symbol() iirc
< wumpus> hah why
< sipa> literally, "dummy_symbol" ?
< fanquake> it's basically been deprecated, think possibly even removed in a later Boost version
< fanquake> sipa yea
< fanquake> 0000000000000000 T boost::system::dummy_exported_function()
< sipa> loi
< wumpus> so it's just there so that software doesn't need to change their -l.... linker flags
< aj> sipa: let's replace boost::multi_index with sqlite!
< wumpus> aj: i had the same cursed thought once but managed to keep it to myself :)
< wumpus> i'm sure it would be possible but also a very large change to how things are done and it's unclear what the performance impact would be, also it makes sqlite a required dependency which i'm not sure is great
< wumpus> and leveldb, the database we already have a strong dependency on, doesn't offer indexing functionality
< aj> wumpus: might create encoding issues and stuff too, since each field needs to be sql'ed not just an entry in a struct
< real_or_random> https://github.com/bitcoin-core/secp256k1/pull/889 cirrus ci doesn't build this PR. I suspect because the author doesn't have write permission.
< real_or_random> but "Require approval for builds from users without write permissions" is not enabled in cirrus settings?!
< wumpus> aj: it's something to be careful with, though sqlite explicitly supports binary data in parametrized queries iirc
< wumpus> (clightning makes fairly heavy use of this)
< wumpus> real_or_random: hmm let's see
< wumpus> I don't think the author needs write permission normally for cirrus builds we have these enabled for all PRs on bitcoin
< bitcoin-git> [bitcoin] laanwj pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/f72d80b07af8...1e69800d5e60
< bitcoin-git> bitcoin/master 12f5028 Hennadii Stepanov: refactor: Move STRINGIZE macro to macros.h
< bitcoin-git> bitcoin/master e99db77 Hennadii Stepanov: Drop boost/preprocessor dependencies
< bitcoin-git> bitcoin/master 1e69800 Wladimir J. van der Laan: Merge #21059: Drop boost/preprocessor dependencies
< bitcoin-git> [bitcoin] laanwj merged pull request #21059: Drop boost/preprocessor dependencies (master...210201-macro) https://github.com/bitcoin/bitcoin/pull/21059
< wumpus> from the Finnish translation: "Avaa %1 -debug-loki tämänhetkisestä data-hakemistosta. Tämä voi viedä muutaman sekunnin suurille lokitiedostoille." .... i don't think -debug-loki is quite right :)
< wumpus> or maybe it is, it's not a translation of an option but of "Open the %1 debug log file from the current data directory. This can take a few seconds for large log files."
< setpill> loki is Finnish for log
< wumpus> setpill: right, i somehow didn't expect that, but makes sense then!
< bitcoin-git> [bitcoin] MarcoFalke pushed 7 commits to master: https://github.com/bitcoin/bitcoin/compare/1e69800d5e60...384e090f9345
< bitcoin-git> bitcoin/master dbf779d Troy Giorshev: Clean PushMessage and ProcessMessages
< bitcoin-git> bitcoin/master f2a77ff Troy Giorshev: Add CaptureMessage
< bitcoin-git> bitcoin/master 4d1a582 Troy Giorshev: Call CaptureMessage at appropriate locations
< Kiminuo> Hi, I was thinking that it would be nice to replace: https://github.com/bitcoin/bitcoin/pull/20744/files#diff-2bd57d7fbec4bb262834d155c304ebe15d26f73fea87c75ff273df3529a15510R1819 with a function. So I did https://github.com/bitcoin/bitcoin/pull/21052/files#diff-56faa53f40da7bfc47077d7c93254d0d1f7eba69a3c5d88f67be9505f334178eR42 but this is problematic because it introduces a new circular dependency: fs -> random -> logging -> fs where I add
< Kiminuo> the edge "fs -> random".
< Kiminuo> So I think this approach is not good. Do you agree?
< Kiminuo> (Unless there is a better place to put "GetUniquePath" but it seems to me that fsbridge is ideal for this.)
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #19509: Per-Peer Message Capture (master...message-dump) https://github.com/bitcoin/bitcoin/pull/19509
< Kiminuo> There are many different possible solutions for the "GetUniquePath" function implementation that I can think of:1
< Kiminuo> 1. One can leave it as it is in https://github.com/bitcoin/bitcoin/pull/20744/files#diff-2bd57d7fbec4bb262834d155c304ebe15d26f73fea87c75ff273df3529a15510R1819. I don't like this too much though. Hence the PR.
< Kiminuo> 2. One can probably use "#include <random>" to avoid using "#include random.h". That sounds doable but it sounds like too much maintenance burden for such primitive function.
< Kiminuo> 3. Or more simply, use rand() from <cstdlib> with some seed.
< Kiminuo> 4. Maybe some simple transformation based on current time (like hashing?) would suffice here.
< Kiminuo> wumpus, ^ do you possibly have an opinion on this?
< real_or_random> wumpus: oh the PR is simply not rebased on the newest master and so it does not have the .cirrus.yml...
< wumpus> Kiminuo: util/getuniquepath.cpp :-)
< wumpus> Kiminuo: imo, the best way to solve circular dependencies is to just factor it out to a new module
< wumpus> Kiminuo: I definitely prefer sticking with our own random generator and not libc's
< wumpus> real_or_random: whoops
< Kiminuo> wumpus, yeah, util/getuniquepath.cpp can be done. But is it preferable?
< Kiminuo> I mean from some grand scheme of things.
< real_or_random> wumpus: I wonder if it's possible to configure Cirrus to run on the merge result instead of the PR branch. There's a "Config resolution strategy" setting but it's not documented
< bitcoin-git> [bitcoin] fanquake opened pull request #21065: build: make macOS HOST in download-osx generic (master...correct_host_download_osx) https://github.com/bitcoin/bitcoin/pull/21065
< wumpus> Kiminuo: to me it is
< Kiminuo> wumpus, ok. Interestingly, I though you would not like this solution the most.. so I skipped it in my list. :-D
< wumpus> I mean, small compilation units allow for the most specific dependency management (and speed up build time too)
< wumpus> also the unique path code is only used in the tests
< wumpus> thinking of it, you could even put it inside the test-specific utils under src/tests
< Kiminuo> Yeah. When somebody needs it outside of tests, it can be refactored.
< bitcoin-git> [bitcoin] hebasto opened pull request #21066: build: Drop boost-system dependency (master...210202-system) https://github.com/bitcoin/bitcoin/pull/21066
< bitcoin-git> [bitcoin] jonatack closed pull request #20877: netinfo: user help and argument parsing improvements (master...netinfo-help-follow-ups) https://github.com/bitcoin/bitcoin/pull/20877
< bitcoin-git> [bitcoin] jonatack reopened pull request #20877: netinfo: user help and argument parsing improvements (master...netinfo-help-follow-ups) https://github.com/bitcoin/bitcoin/pull/20877
< bitcoin-git> [bitcoin] x4e opened pull request #21067: Fix whitepaper link in ReadMe (master...fix-whitepaper-link) https://github.com/bitcoin/bitcoin/pull/21067
< bitcoin-git> [bitcoin] fanquake closed pull request #21067: Fix whitepaper link in ReadMe (master...fix-whitepaper-link) https://github.com/bitcoin/bitcoin/pull/21067
< luke-jr> wumpus: in my experience, because gitian copies all the caches in even if not used
< luke-jr> wumpus: if you use KVM gitian, https://github.com/devrandom/gitian-builder/pull/172
< luke-jr> something wrong with master
< luke-jr> /home/dev/Bitcoin/bitcoin/wt1/src/pubkey.cpp:180: undefined reference to `secp256k1_xonly_pubkey_parse'
< luke-jr> build system failing to detect a need to rebuild something? :/
< luke-jr> (this working tree location last used to build for previous-releases testing)
< luke-jr> autogen didn't help; explicit configure did
< setpill> Trying to get guix building working in docker... Running into this error https://gist.github.com/setpill/3f7fbb7a0767f9d6939db5c1373588e6
< setpill> Seems to always happen at the same point
< setpill> Some context; running docker with --privileged, image based on https://github.com/fanquake/core-review/blob/master/guix/Dockerfile with only change being to add macOS SDK stuff
< setpill> Is this a known error that is caused by me somehow having overlooked a crucial instruction?
< ishaqm> for a simulation, i want to modify regtest so that blocks require mining. Would hard-coding a higher difficulty in CRegTestParams work?
< bitcoin-git> [bitcoin] hebasto closed pull request #21066: build: Drop boost-system dependency (master...210202-system) https://github.com/bitcoin/bitcoin/pull/21066
< luke-jr> reminder: 38 minutes until ##Taproot-activation meeting
< bitcoin-git> [bitcoin] practicalswift opened pull request #21068: Add GitHub Codespaces integration to allow for easy onboarding of future generations of contributors (master...github-codespaces) https://github.com/bitcoin/bitcoin/pull/21068
< miketwenty1> Between Noon and 5 pm EST on March 30th (Tuesday).. There will be a remote speaking opportunity for a bitcoin core developer at a "Open Source 101" event. The idea would be someone who can explain about how the project is maintained, how people can contribute, why it's important, etc. Less about the bitcoin tech and more about the project and contribution to the project. I imagine history would also be a very interesting piece
< miketwenty1> of this. If you're interested please email me mtidwell021@gmail.com and I'll give you more details.
< miketwenty1> I imagine maybe achow101, sipa, jnewbery, or someone else, would know a good person for this?, or may be interested yourselves.
< luke-jr> wumpus: I don't know of a single open source software package that bundles fonts…
< wumpus> luke-jr: no idea, but I don't really see a problem with it, as there's fonts available with a free enough license
< wumpus> this is similar to static linking imo -- be as independent as possible from what happens to be installed on the system
< luke-jr> wumpus: except most of our static linking isn't detrimental to user experience
< luke-jr> and fonts are fairly stable in compariosn
< wumpus> assuming that fonts are installed corrently when they are not (or somehow not locatable) can also be detrimental to the user experience
< wumpus> not sure about that, we've had quite some of these reported issues throughout the history of the project, especially with monospace fonts
< wumpus> always had very ugly hacks to work around it, i think shipping a font is realtively clean
< wumpus> for building from source i'm sure we could add an option to not embed them
< wumpus> this is only about the distributed binaries
< sipa> wumpus: you know we do have -chain=X, right? ;)
< wumpus> sipa: we do?!?
< wumpus> no, I was not aware that ever got merged
< wumpus> seems absolutely superior to "radio button" options like -regtest -testnet
< wumpus> though it's a bit weird to have both
< aj> wumpus: geez, read the code sometime!
< wumpus> aj: hehe
< aj> wumpus: (i was going to quote the bit where it checks you only specify one of -chain, -signet etc, but now i can't find it, so apparently i should read the code sometime too)
< sipa> git grep -- '"-chain"'
< wumpus> aj: that's the code that #21039 changes
< gribble> https://github.com/bitcoin/bitcoin/issues/21039 | refactor: dont throw in GetChainName() by fanquake · Pull Request #21039 · bitcoin/bitcoin · GitHub
< jonatack> i could see why software clients might use -chain= but cli examples seem to always be -regtest, -testnet, -signet iirc
< jonatack> seems handier for manual cli use
< jonatack> (my interpretation of why having both can make sense)
< aj> sipa: no, everyone should know all the code by heart, without having to grep, clearly
< wumpus> yes it's clearly something way too many people are used to by now
< aj> less typing when invoking "bitcoin-cli -testnet .." etc is a win
< sipa> yeah, and -testnet -regtest also exist far longer thaj -chain
< wumpus> aj: for the client it's absolutely a good thing
< wumpus> I agree, it's better seen as '-testnet is a shorthand for -chain=test`
< wumpus> though that's not how the argument parsing code works at the moment
< jonatack> yes
< wumpus> I don't think it even protects aginst multiple -chain=X like it does against -testnet -regtest ?
< sipa> indeed
< aj> should have the same protection as other options that aren't meant to be vectors?
< wumpus> "src/bitcoin-cli -chain=test -chain=main getblockchaininfo" doesn't raise any error here, it's interpreted as just -chain=main
< wumpus> which is fine, it's the same behavior as for other duplicated options, i just meant that the explicit protection that the shorthand network arguments have is different
< wumpus> it's slightly inconsistent but also not big deal
< wumpus> okayy, restarting the knots gitian linux build for the third time, hopefully i made the disk image large enough this time...
< wumpus> to be honest i'm not actually sure why gitian bothers with a disk image at all for lxc, it's a container, it could just use a directory of the host, but anyhow
< sipa> i suspect for historic reasons
< wumpus> make the base image a .tar.gz and unzip it, voila, new target
< sipa> lxc was added later, i think
< wumpus> right i wouldn't be surprised if that's the entire explanation
< fanquake> setpill: if you remove "https://guix.carldong.io" from https://github.com/fanquake/core-review/blob/master/guix/Dockerfile#L44 and rebuild the docker image, it should work.