< 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
< 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
< 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>
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>
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] 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)
< 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
< 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
< 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
< 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>
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
< 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