< fanquake> promag: thanks
< bitcoin-git> [bitcoin] Empact reopened pull request #13226: Optimize SelectCoinsBnB by tracking the selection by index rather than by position (master...select-bnb-by-index) https://github.com/bitcoin/bitcoin/pull/13226
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/2aab8a6dd0b5...fd7a770d32af
< bitcoin-git> bitcoin/master faa8dfd MarcoFalke: ci: Bump macOS image to big-sur-xcode-12.5
< bitcoin-git> bitcoin/master fd7a770 MarcoFalke: Merge bitcoin/bitcoin#22122: ci: Bump macOS image to big-sur-xcode-12.5
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #22122: ci: Bump macOS image to big-sur-xcode-12.5 (master...2106-ciMac) https://github.com/bitcoin/bitcoin/pull/22122
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/fd7a770d32af...001116719191
< bitcoin-git> bitcoin/master 5f23531 Kiminuo: CRegTestParams: Use `args` instead of `gArgs`.
< bitcoin-git> bitcoin/master 0011167 MarcoFalke: Merge bitcoin/bitcoin#22135: CRegTestParams: Use `args` instead of `gArgs`...
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #22135: CRegTestParams: Use `args` instead of `gArgs`. (master...feature/2021-06-02-chainparams-n-gArgs) https://github.com/bitcoin/bitcoin/pull/22135
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/001116719191...a9435e34457e
< bitcoin-git> bitcoin/master 3737126 practicalswift: Mark `CheckTxInputs` `[[nodiscard]]` (out-param `txfee` only set if call i...
< bitcoin-git> bitcoin/master a9435e3 MarcoFalke: Merge bitcoin/bitcoin#22065: Mark `CheckTxInputs` `[[nodiscard]]`. Avoid U...
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #22065: Mark `CheckTxInputs` `[[nodiscard]]`. Avoid UUM in fuzzing harness `coins_view`. (master...nodiscard-CheckTxInputs) https://github.com/bitcoin/bitcoin/pull/22065
< bitcoin-git> [gui] promag opened pull request #354: Refactor open date range to use std::optional (master...2021-06-date-range) https://github.com/bitcoin-core/gui/pull/354
< bitcoin-git> [bitcoin] promag opened pull request #22136: Add --disable-rpc configure option (master...2021-06-disable-rpc) https://github.com/bitcoin/bitcoin/pull/22136
< bitcoin-git> [bitcoin] MarcoFalke opened pull request #22137: util: Properly handle -noincludeconf on command line (master...2106-utilTake2) https://github.com/bitcoin/bitcoin/pull/22137
< jonasschnelli> #proposedmeetingtopic: Bitcoin Code Signing Association Switzerland
< michaelfolkson> #proposedmeetingtopic Reviewing progress of fortnightly Core subsystem (P2P, wallet, GUI etc) meetings
< bitcoin-git> [bitcoin] jonatack opened pull request #22138: script: fix spelling linter raising spuriously on "invokable" (master...fix-spurious-linter-spelling) https://github.com/bitcoin/bitcoin/pull/22138
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/a9435e34457e...d331e262f5b2
< bitcoin-git> bitcoin/master 8050eb4 Jon Atack: script: fix spelling linter raising spuriously on "invokable"
< bitcoin-git> bitcoin/master d331e26 MarcoFalke: Merge bitcoin/bitcoin#22138: script: fix spelling linter raising spuriousl...
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #22138: script: fix spelling linter raising spuriously on "invokable" (master...fix-spurious-linter-spelling) https://github.com/bitcoin/bitcoin/pull/22138
< bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/d331e262f5b2...6fe012c6bd6a
< bitcoin-git> bitcoin/master ab86ac7 Hennadii Stepanov: build, qt: Make QWindowsVistaStylePlugin available again (regression)
< bitcoin-git> bitcoin/master 6fe012c fanquake: Merge bitcoin/bitcoin#22133: build, qt: Make QWindowsVistaStylePlugin avai...
< bitcoin-git> [bitcoin] fanquake merged pull request #22133: build, qt: Make QWindowsVistaStylePlugin available again (regression) (master...210602-style) https://github.com/bitcoin/bitcoin/pull/22133
< bitcoin-git> [bitcoin] fanquake opened pull request #22139: test: add type annotations to util.get_rpc_proxy (master...type_annotations_get_rpc_proxy) https://github.com/bitcoin/bitcoin/pull/22139
< bitcoin-git> [bitcoin] jonatack opened pull request #22140: p2p, refactor: remove unneeded CNetAddr::UnserializeV1Array() (master...p2p-remove-unused-UnserializeV1Array) https://github.com/bitcoin/bitcoin/pull/22140
< bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/6fe012c6bd6a...fcfd37f3f9dc
< bitcoin-git> bitcoin/master 3b36395 João Barbosa: depends: Fix qt.mk for mac arm64
< bitcoin-git> bitcoin/master fcfd37f fanquake: Merge bitcoin/bitcoin#22123: depends: Fix qt.mk for mac arm64
< bitcoin-git> [bitcoin] fanquake merged pull request #22123: depends: Fix qt.mk for mac arm64 (master...2021-06-fix-aarch64_darwin) https://github.com/bitcoin/bitcoin/pull/22123
< * fanquake> requests an embargo on future Qt PRs
< hebasto> fanquake: accepted
< promag> fanquake: you mean just on depends?
< fanquake> promag: yes. Although I'm just being selfish, and trying to save myself rebase hassle
< fanquake> Will open a (mostly working) draft PR shortly that will explain
< promag> ah kk
< hebasto> fanquake: will it solve the problem #20641 aims to solve?
<@gribble> https://github.com/bitcoin/bitcoin/issues/20641 | depends: Use Qt top-level build facilities by hebasto · Pull Request #20641 · bitcoin/bitcoin · GitHub
< laanwj> right just on build system ones, not GUI changes in general
< fanquake> It's not super clear to me what that PR is trying to achieve. Although I don't think these changes would make it any less possible
< promag> since you are around, what you think about --disable-rpc? (or similar)
< hebasto> fanquake: "integrate new modules into static builds"
< fanquake> Sure, but what new modules do we need?
< laanwj> because this is the right moment to merge last-minute GUI change PRs, before the translation freeze
< hebasto> fanquake: QML, ofc
< fanquake> That seems like a much larger discussion, which needs good motivation, and buy in from multiple devs, before we worry about hacking up the builds system to support it
< laanwj> i don't see a point for --disable-rpc, why increase compile time complexity?
< fanquake> I also have very little interest in rewriting our GUI in a new language.
< laanwj> all the different compile-time combinatorial complexity makes it really hard to cover all possibilities, they all take work to maintain
< promag> laanwj: be able to build without support for rpc - build for mobile for instance
< laanwj> fanquake: it's not like you need to do that :)
< hebasto> oh, it seems you missed the Project Horizon presentation :)
< laanwj> promag: why wouldn't rpc be useful on mobile?
< laanwj> it's not like the RPC code is large compared to anything else, if you're going the 'embeddes sytsems need to minimize code' angle
< hebasto> QML seems the right way to lure designers into the GUI development
< promag> laanwj: just a way to be on the safe side?
< laanwj> the safe side of what?
< laanwj> just run with server=0 if you don't want to open a RPC port
< laanwj> even more, even the GUI needs most of the RPC code because of the debug console
< promag> laanwj: ok, didn't think of that
< hebasto> one of the QML use case right now is #16883
<@gribble> https://github.com/bitcoin/bitcoin/issues/16883 | WIP: Qt: add QML based mobile GUI by icota · Pull Request #16883 · bitcoin/bitcoin · GitHub
< promag> laanwj: actually the RPC code seems to be already well split
< laanwj> but i don't see why RPC would be a bad thing inherently on mobile, sure, access control works differently, but you might still want to give other applications access in some cases-or even use the cli through somethig like termux
< promag> laanwj: we can build with --disable-wallet think its reasonable to to have the
< promag> same thing for rpc
< bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/fcfd37f3f9dc...8837f1ebde05
< bitcoin-git> bitcoin/master a58868d Hennadii Stepanov: build: Makes rcc output always deterministic
< bitcoin-git> bitcoin/master 8837f1e fanquake: Merge bitcoin/bitcoin#21654: build, qt: Make Qt rcc output always determin...
< bitcoin-git> [bitcoin] fanquake merged pull request #21654: build, qt: Make Qt rcc output always deterministic (master...210411-rcc) https://github.com/bitcoin/bitcoin/pull/21654
< promag> but I agree it shouldn't add burden
< laanwj> i really don't like that but anyhow
< promag> what? the option? or to maintain the option?
< laanwj> both
< promag> so just use runtime control
< laanwj> i think both run-time and compile-time configurability of bitcoind is getting out of hand, and i see this specific change as a good example of something that isn't really needed
< laanwj> yes
< promag> i guess you also dont like --without-libevent
< laanwj> we already disable RPC by default in bitcoin-qt iirc, and have always done so
< laanwj> for fact, no, i don't
< laanwj> but that's mostly because the original plan for libevent was to use it for P2P as well
< promag> ok, I'll close the draft
< laanwj> nothing happened with that so i feel less strongly about that now
< promag> oh really?
< promag> fanquake: who said rewrite gui?
< laanwj> libevent's http server isn't *that* great, but also, no way we want to implement and maintain our own
< fanquake> My assumption is that if people want a new language to write the gui in, which is what I understand qml to be, we would be rewriting
< fanquake> god forbid we end up with 2 guis
< hebasto> 2 guis seems awful
< laanwj> it could make sense for a transitional phase but yea...
< fanquake> 2 guis actually being 6 or 8, or maybe 10+ by the time you take into various platforms and runtime modes and etc etc
< laanwj> i don't disagree with the point that qt widgets is basically dead, development-wise, and QML is (with regard to Qt) the future
< fanquake> It's also unclear how easy a transition to qt 6 is going to be. Given they've seemingly thrown support for autotools / pkg-config out the window
< hebasto> the idea is to implement Bitcoin Design Guide ideas in new widgets with QML, making transition on widget/window base
< fanquake> If we want to move to 5.15, we'll need to start maintaining x libs in depends, because at that version qt is no longer bundling them in tree
< hebasto> is reverting back pkg-config support in Qt6 plans?
< laanwj> wait, they removed pkg-config support? oh no... that's another boost level monstriosity
< fanquake> "Somewhat important", but doesn't seem to have any sort of priority
< laanwj> it's so nice to be able to use pkg-config instead of manually scanning the system in the configure scripts (like we have to do for boost, often failing)
< laanwj> well, let's stick with qt5 at least until that is fixed
< laanwj> i wonder what they suggest autotools-based projects *do*, is cmake the only option now?
< promag> regardless I'll be working on qml gui, fork is fine to me and lack of qml in depends isn't a blocker
< laanwj> promag: qml + qt5 is fine with me
< promag> laanwj: yup they went cmake
< hebasto> qt 5.15 is, actually, qt 6.beta, so there could be less benefits to move to qt 5.15
< promag> re qt6 I'm just waiting to 6.2
< promag> qtquick controls still lacks lots of features compared to qt widgets
< laanwj> there is no direct mapping, no
< promag> treeview and tableviews suck
< hebasto> promag: re "qml in depends isn't a blocker" -- compiling only with system packages?
< promag> hebasto: yes - why do we want qml now in depends?
< laanwj> fwiw i also maintained the qt based GUI as a fork for a fair while before it was merged upstream
< promag> laanwj: exactly
< laanwj> though we might want to limit changes to the interface for a while
< hebasto> promag: to make standard guix releases
< laanwj> so it's less of a rebase nightmare
< promag> same thing ryanofsky is doing with multiprocess
< hebasto> promag: have you the QML fork already?
< laanwj> (that was no option at the time because the GUI and core were joined at the hip, there's better separation now)
< promag> hebasto: no :)
< hebasto> laanwj: what are drawbacks if QML fork of the GUI will live under bitcoin-core?
< laanwj> hebasto: do you prefer a new repository or is a branch of the existing gui repository ok?
< hebasto> a dedicated branch in the current GUI repo should be fine; promag what do you think?
< hebasto> won't it break the interaction between the GUI and the main repos?
< laanwj> you would have to be more careful in that case with force-pushes and rebases
< laanwj> wouldn't want to overwrite the master branch accidentally
< hebasto> right
< laanwj> but no, in principle there is no reason why branches in the bitcoin-core/gui repo would interfere with anything in bitcoin/bitccoin
< fanquake> Yes, please nothing that's is going to interfere with the actual repo, or generate any more commits then the GUI repo already does etc.
< promag> only reason for another repo is to have different maintainers
< laanwj> better to create a new repo then maybe
< hebasto> ^ ok
< bitcoin-git> [bitcoin] laanwj pushed 4 commits to master: https://github.com/bitcoin/bitcoin/compare/8837f1ebde05...907d636e5e76
< bitcoin-git> bitcoin/master 985430d Russell Yanofsky: test: Add gui test for wallet receive requests
< bitcoin-git> bitcoin/master 62252c9 Russell Yanofsky: interfaces: Stop exposing wallet destdata to gui
< bitcoin-git> bitcoin/master f5ba424 Russell Yanofsky: wallet: Add IsAddressUsed / SetAddressUsed methods
< bitcoin-git> [bitcoin] laanwj merged pull request #21353: interfaces: Stop exposing wallet destdata to gui (master...pr/nodestg) https://github.com/bitcoin/bitcoin/pull/21353
< laanwj> gah i can't even fork gui into a new project under bitcoin-core
< fanquake> I'm happy for anyone to experiment, but certainly not at the expense of frequent code churn, notification noise, etc etc for the actual repo.
< laanwj> *sigh* github
< laanwj> fanquake: yes, agree
< fanquake> Given recent dicussions / interactions on the GUI repo, I'm very happy that we've got it split out
< laanwj> fanquake: same
< laanwj> it just makes sense, the *kind* of discussion is very different
< hebasto> laanwj: re "gah i can't even fork gui into a new project under bitcoin-core" -- could this be worked around?
< laanwj> hebasto: yes, i think if you fork it, rename it, and then move the project to bitcoin-core you can work around it
< promag> fanquake: +1 thats why I said fork originally
< laanwj> alternatively i can fork it from bitcoin/bitcoin that might work buut it'd make less sense semantically, or maybe create a new repo without 'forked from' connection but that has other drawbacks, github is silly in that way
< hebasto> I don't think github let me fork the repo that is already forked under the same username
< laanwj> AHHH of couuurse you're right
< laanwj> maybe i can fork it into an organization that doesn't have a fork of bitcoin yet and do the trick
< hebasto> hope you will success
< laanwj> "bitcoin-core already has a repository in the bitcoin-core/gui network" gah
< laanwj> at least i trieeed
< hebasto> laanwj: re "create a new repo without 'forked from' connection but that has other drawbacks" -- what drawbacks?
< laanwj> you can't create a PR directly in that case
< laanwj> nor can other people with a fork of the existing repo send you PRs
< bitcoin-git> [bitcoin] promag closed pull request #22136: Add --disable-rpc configure option (master...2021-06-disable-rpc) https://github.com/bitcoin/bitcoin/pull/22136
< bitcoin-git> [bitcoin] jnewbery opened pull request #22141: net processing: Remove hash and fValidatedHeaders from QueuedBlock (master...2021-06-blocks-in-flight) https://github.com/bitcoin/bitcoin/pull/22141
< hebasto> I think they are acceptable, wrt github restrictions
< laanwj> fanquake: regarding qt dependencies we already have the 'problem' that the release binaries don't support wayland (#19950), due to our static linkage of qt (not that there's any good alternative)
<@gribble> https://github.com/bitcoin/bitcoin/issues/19950 | [Linux] Add wayland support · Issue #19950 · bitcoin/bitcoin · GitHub
< laanwj> hebasto: ok, what would you like the repo to be called, gui-qml?
< hebasto> lgtm
< hebasto> laanwj: thanks!
< laanwj> hebasto: it's set up, same permissions as for gui, let me know if you need anything else
< promag> github ninja
< laanwj> hehe
< bitcoin-git> [bitcoin] fanquake opened pull request #22142: [WIP] build: split depends Qt into native and target builds (master...split_qt_again) https://github.com/bitcoin/bitcoin/pull/22142
< bitcoin-git> [bitcoin] laanwj closed pull request #21760: Add -flushwalletinterval command line arg (master...flushwalletinterval) https://github.com/bitcoin/bitcoin/pull/21760
< bitcoin-git> [bitcoin] jonatack opened pull request #22143: p2p: pass spans in CNetAddr by reference to const (master...netaddress-pass-spans-by-reference-to-const) https://github.com/bitcoin/bitcoin/pull/22143
< bitcoin-git> [bitcoin] jonatack closed pull request #22143: p2p: pass spans in CNetAddr by reference to const (master...netaddress-pass-spans-by-reference-to-const) https://github.com/bitcoin/bitcoin/pull/22143
< bitcoin-git> [bitcoin] laanwj pushed 14 commits to master: https://github.com/bitcoin/bitcoin/compare/907d636e5e76...07ededa30c94
< bitcoin-git> bitcoin/master 0f1c58a Jon Atack: test: update feature_proxy to torv3
< bitcoin-git> bitcoin/master f8e9400 Jon Atack: p2p: remove torv2/ADDR_TORV2_SIZE from SetTor()
< bitcoin-git> bitcoin/master c56a1c9 Jon Atack: p2p: drop onions from IsAddrV1Compatible(), no longer relay torv2
< bitcoin-git> [bitcoin] laanwj merged pull request #22050: p2p: remove tor v2 support (master...torv2-remove-support) https://github.com/bitcoin/bitcoin/pull/22050
< achow101> are we going to do 0.20.2rc2?
< sipa> do we have tor v3 support in 0.20?
< sipa> i forget if it was 0.20 or 0.21
< achow101> I think that was 0.21
< sipa> indeed, 0.21
< sipa> that's kind of unfortunate if we want to do a new 0.20 release
< achow101> is it hard to backport torv3?
< sipa> it means backporting bip155
< laanwj> not sure how big of a problem it is, people can still use tor, just not hidden services
< sipa> that's fair, we can get away by putting it in the release notes
< laanwj> i expect it would be an awful lot of work to backport
< laanwj> p2p code changed a lot since
< laanwj> for something that is going to see very little testing
< sipa> good point, yes
< sipa> it was half a dozen PRs probably
< laanwj> as for 0.20.2rc2, sure, let's do that
< sipa> at least PRs 19360 19534 19841 19845 19628 20119 19954 20564 20661
< bitcoin-git> [bitcoin] laanwj pushed tag v0.20.2rc2: https://github.com/bitcoin/bitcoin/commit/5d2ebdd2b71f
< laanwj> ^^
< bitcoin-git> [bitcoin] sipa opened pull request #22144: Randomize message processing peer order (master...202106_rand_peers) https://github.com/bitcoin/bitcoin/pull/22144
< Kiminuo58> laanwj: Thank you for having a look at https://github.com/bitcoin/bitcoin/pull/21422. A silly question - why clang 13? It's not even released yet, is it?
< laanwj> #startmeeting
< core-meetingbot> Meeting started Thu Jun 3 19:02:03 2021 UTC. The chair is laanwj. Information about MeetBot at https://bitcoin.jonasschnelli.ch/ircmeetings.
< core-meetingbot> Available commands: action commands idea info link nick
< jonasschnelli> hi
< hebasto> hi
< kvaciral[m]> hi
< michaelfolkson> hi
< sipa> hi
< laanwj> Kiminuo58: correct, one of my builds uses clang from git, I'm not sure the error happens with other versions I thought I'd note it because it completely blocks compilation
< laanwj> #bitcoin-core-dev Meeting: achow101 _aj_ amiti ariard BlueMatt cfields Chris_Stewart_5 darosior digi_james dongcarl elichai2 emilengler fanquake fjahr gleb glozow gmaxwell gwillen hebasto instagibbs jamesob jarolrod jb55 jeremyrubin jl2012 jnewbery jonasschnelli jonatack jtimon kallewoof kanzure kvaciral laanwj lightlike luke-jr maaku marcofalke meshcollider michagogo moneyball morcos
< laanwj> nehan NicolasDorier paveljanik petertodd phantomcircuit promag provoostenator ryanofsky sdaftuar sipa vasild
< achow101> hi
< jonatack> hi
< darosior> hi
< jarolrod> Hi
< laanwj> two proposed meeting topics for today: Bitcoin Code Signing Association Switzerland (jonasschnelli), Reviewing progress of fortnightly Core subsystem (P2P, wallet, GUI etc) meetings (michaelfolkson)
< laanwj> any last minute ideas for topics?
< laanwj> #topic High priority for review
< core-meetingbot> topic: High priority for review
< laanwj> https://github.com/bitcoin/bitcoin/projects/8 currently has 11 blockers, 0 bugfixes, 0 chasing concept ACK
< laanwj> anything to add/remove or that is ready for merge?
< dongcarl> Would like to add #21866, where we say farewell to global chainman
<@gribble> https://github.com/bitcoin/bitcoin/issues/21866 | [Bundle 7/7] validation: Farewell, global Chainstate! by dongcarl · Pull Request #21866 · bitcoin/bitcoin · GitHub
< achow101> #22051 has 4 acks
<@gribble> https://github.com/bitcoin/bitcoin/issues/22051 | Basic Taproot derivation support for descriptors by sipa · Pull Request #22051 · bitcoin/bitcoin · GitHub
< laanwj> we are getting close to the point where we need to prioritize what we still want to make into 0.22
< provoostenator> hi
< jonatack> pushed a (close-to-final?) big update to #21261, hoping it can be tagged/merged for v0.22
<@gribble> https://github.com/bitcoin/bitcoin/issues/21261 | p2p: update inbound eviction protection for multiple networks, add I2P peers by jonatack · Pull Request #21261 · bitcoin/bitcoin · GitHub
< laanwj> feature freeze is the 15th according to #20851
<@gribble> https://github.com/bitcoin/bitcoin/issues/20851 | Release schedule for 22.0 · Issue #20851 · bitcoin/bitcoin · GitHub
< laanwj> which is in less than two weeks
< jonatack> (been working on it behind the scenes these past weeks with helpful offline review feedback from vasild)
< laanwj> achow101: yes, that one seems ready for merge
< laanwj> dongcarl: added
< laanwj> jonatack: tagged for 22.0
< laanwj> anything else for high prio?
< laanwj> #topic Bitcoin Code Signing Association Switzerland (jonasschnelli)
< core-meetingbot> topic: Bitcoin Code Signing Association Switzerland (jonasschnelli)
< jonasschnelli> The swiss association is now officially registered
< laanwj> congrats!
< jonasschnelli> Which means we can get code signing certificates again
< laanwj> also for macosx?
< jonasschnelli> It comes with some maintenance costs as we needed a domicile...
< jonasschnelli> macOS should be no problem
< jonasschnelli> (also the current macOS cert is still valid for a few months)
< laanwj> i guess we could use the coredev funds for that
< jonasschnelli> the question is, do we want to keep the swiss association or do we want to focus on the US LLC?
< jonasschnelli> agree with the coredev funds
< provoostenator> Maybe keep them both for a while?
< jonasschnelli> Yes. That's also what I thought provoostenator
< laanwj> yeah some redundancy couldn't hurt
< achow101> I think it makes sense to keep both as a backup
< jonasschnelli> okay... lets keep it and see when we might want to use it
< provoostenator> Can we have certificates from both at the same time too? (but only use one)
< achow101> I was also thinking we could alternate every year, so after say 9 months, try to get a cert using the other org. that would give us 3 months to work out any issues with getting a cert issued
< laanwj> that sounds sensible to me
< jonasschnelli> agree
< laanwj> #topic Reviewing progress of fortnightly Core subsystem meetings (michaelfolkson)
< core-meetingbot> topic: Reviewing progress of fortnightly Core subsystem meetings (michaelfolkson)
< michaelfolkson> So with the Libera transition I thought it would be a good point to discuss how the subsystem meetings are going, how they could be improved etc
< michaelfolkson> The P2P ones started with a really good format https://github.com/bitcoin-core/bitcoin-devwiki/wiki/P2P-IRC-meetings
< michaelfolkson> But they've kind of run out of steam in recent weeks
< michaelfolkson> The wallet one appears to struggle with attendance a lot of the time (from what I've seen)
< michaelfolkson> I like the idea of them, I personally would like to hear what people are working on but that's just me, sample size of 1
< michaelfolkson> Perhaps 2 weeks is too regular, come round too often. Do you think attendance would be better if they were monthly?
< michaelfolkson> I think there are GUI meetings on Jitsi or at least there were
< provoostenator> I don't often show up for wallet meetings, but when I do, I find them useful.
< laanwj> wouldn't this be better to discuss in those meetings themselves, with the people attending them?
< provoostenator> (or at least quick)
< achow101> I don't think having them more or less frequently would make that much of a difference
< achow101> it isn't that much effort to have a short meeting with little discussion
< michaelfolkson> laanwj: I guess but I thought it might be useful to compare notes
< jonatack> provoostenator: achow101: agree
< achow101> but it's still useful to have the meetings for when there are things to discuss
< michaelfolkson> achow101: I think the expectation that not many will attend means that other people don't bother
< provoostenator> I don't like the time of day, but timezones are just what they are: annoying.
< jarolrod> The “GUI” meetings on jitsi are not really core dev related
< jarolrod> I think it’s fair to say there are no GUI meetings
< achow101> michaelfolkson: I don't think that's necessarily true
< jonatack> the p2p ones are really late now for CET people, so e.g. vasild and i don't attend, but i get value from reading the meeting log the next day
< michaelfolkson> But ok I'll bring up in the subsystem meetings and see how we can encourage attendance, participation
< achow101> I think that frequently, it appears that few people are attending because no one speaks. but when there is actually something to discuss, there are many more people speaking than you may think
< michaelfolkson> As I said the P2P ones started really strongly but have lost steam in recent weeks
< achow101> I suspect many people just lurk with IRC open during the meetings
< michaelfolkson> With P2P contributors were posting on the dev wiki what they were working on but I don't think many people are bothering anymore
< michaelfolkson> I like the idea but you can't force people to do it
< laanwj> the libera migration was kind of brutal, maybe not everyone caught up yet
< michaelfolkson> Indeed, this week appears quiet with Libera and Miami
< michaelfolkson> But I think the trend started before then
< laanwj> in any case it's going to fluctuate
< michaelfolkson> Ok thanks, I will bring up in the individual subsystem meetings.
< provoostenator> Even with low attendance the logs can be useful for later, so you can even just have a monologue :-)
< jonatack> the wallet meetings are cool as-is IMO :)
< michaelfolkson> Good to know the feedback, thanks
< laanwj> anecdotally i don't think doing the meeting less often results in higher attendance, if anything it makes people forget about it more :)
< jonatack> yup
< michaelfolkson> Ok leaving as is seems the preference
< laanwj> i think that concludes today's meeting
< laanwj> thanks everyone who still made it :)
< laanwj> #endmeeting
< core-meetingbot> topic: Bitcoin Core development discussion and commit log | Feel free to watch, but please take commentary and usage questions to #bitcoin | Channel logs: http://www.erisian.com.au/bitcoin-core-dev/, http://gnusha.org/bitcoin-core-dev/ | Meeting topics http://gnusha.org/bitcoin-core-dev/proposedmeetingtopics.txt / http://gnusha.org/bitcoin-core-dev/proposedwalletmeetingtopics.txt
< core-meetingbot> Meeting ended Thu Jun 3 19:26:31 2021 UTC.
< jonatack> o/ fare-thee-well, global chainstate
< laanwj> it was a long journey
< bitcoin-git> [bitcoin] laanwj pushed 10 commits to master: https://github.com/bitcoin/bitcoin/compare/07ededa30c94...c7dd9ff71b9c
< bitcoin-git> bitcoin/master 4b1cc08 Pieter Wuille: Make XOnlyPubKey act like byte container
< bitcoin-git> bitcoin/master 31df02a Pieter Wuille: Change Solver() output for WITNESS_V1_TAPROOT
< bitcoin-git> bitcoin/master 41839bd Pieter Wuille: Avoid dependence on CTxDestination index order
< bitcoin-git> [bitcoin] laanwj merged pull request #22051: Basic Taproot derivation support for descriptors (master...202105_taproot_derive) https://github.com/bitcoin/bitcoin/pull/22051
< hebasto> laanwj: update-translations.py informs about multiple format specifiers mismatches; what is the best way to inform translators about that?
< laanwj> hebasto: i don't know ... maybe a notification with a list in it of languages and messages affected
< laanwj> alternatively, if they're straightforward we could fix them ourselves
< hebasto> fix them ourselves on Transifex, right?
< laanwj> yes
< hebasto> ok, I'll try it
< laanwj> often it's something trivial like 4% instead of %4
< hebasto> you are right
< hebasto> how do right-to-left systems work?
< laanwj> string index 0 is rightmost, index len-1 is leftmost
< luke-jr> pretty sure %4 still tho, not 4%
< hebasto> luke-jr: thanks
< sipa> well if your editor is LTR, i'd expect you'd see all strings in source code for RTL languages in reverse
< laanwj> it will still be %4 when displayed from left-to-right
< hebasto> most of mismatches are 4% for right-to-left systems
< laanwj> e.g. the % must have an index below the 4
< luke-jr> if you're looking at it RTL, it might look like 4% while being "4%" in byte order
< luke-jr> err "%4" in byte order
< laanwj> yes
< * luke-jr> wonders if the fileformat change enabled us to have translations marked "incomplete" on Transifex?
< laanwj> i guess theoretically the import script could automatically correct for this specific case when it knows (through some language db) whether it is right-to-left and left-to-right ... though it would be preferable if the translators simply learned to do it right
< luke-jr> I have a script for filling in missing translations based on close matches, but ideally we'd still want a translator to look over and approve (or retranslate) them
< hebasto> luke-jr: on transifex.com translation level for 22.x looks pretty high for active languages
< hebasto> so file format had no effect on translation status
< hebasto> but it dropped the "reviewed" status
< hebasto> is there a way on transifex to see if a language is RTL or LTR?
< bitcoin-git> [gui] hebasto opened pull request #355: qt: Avoid ambiguous interpreting of placeholders (master...210603-placeholder) https://github.com/bitcoin-core/gui/pull/355
< luke-jr> hebasto: IIRC % in format strings need to be replaced by % or such, not sure if that applies to Qt
< nanotube> btw, the website still seems to point to freenode irc (e.g., at the bottom here: https://bitcoincore.org/en/2021/05/01/release-0.21.1/ ). not sure if someone wants to update it to point to libera.
< harding> nanotube: yeah, I think we decided here https://github.com/bitcoin-core/bitcoincore.org/pull/778#issue-651534929 not to change historical documents like release blogs.
< nanotube> harding: ok sounds reasonable, just making sure it was not forgotten. :)
< hebasto> laanwj: luke-jr: jonasschnelli: may I ask you to look into https://github.com/bitcoin-core/gui/issues/356?
< luke-jr> looks straightforwardish. kinda surprised it isn't a standard check though
< luke-jr> hebasto: enabled for XLIFF only as a warning for now
< hebasto> luke-jr: thanks
< luke-jr> hebasto: is there one I can look at to verify it worked?
< hebasto> let me see...
< luke-jr> looking at a random one, it looks like the placeholders appear like that %1% you thought was a problem
< luke-jr> and now the %1% looks sane
< hebasto> luke-jr: lang Malayalam, 22.x, id 120
< hebasto> looks great
< luke-jr> hmm, I don't see the warning on it when I view
< hebasto> place holder is well-formed, but no warnings
< hebasto> maybe raise level to "error"?
< luke-jr> I removed the extra space on the end and saved, then the warning showed
< luke-jr> so I guess it just didn't re-check existing stuff
< hebasto> hmm, warning could be ignored
< luke-jr> I assume that's the difference between error and warning
< luke-jr> but hopefully translators aren't going to do that? :P
< hebasto> what are drawbacks if level will be set to "error"?
< luke-jr> I guess if I made a mistake it might be more annoying
< hebasto> isn't not merging wrong translated string into the release more annoying?
< luke-jr> we already have a check for that
< hebasto> our check just ignore such strings without any feedback to translators
< luke-jr> I don't feel strongly about whether it's error or warning
< luke-jr> well, translators get preemptive feedback now ☺
< hebasto> right, let see how it will be used by them
< bitcoin-git> [gui] hebasto closed pull request #355: qt: Avoid ambiguous interpreting of placeholders (master...210603-placeholder) https://github.com/bitcoin-core/gui/pull/355