< wumpus>
achow101: looks like it's already been restored? in any case, if people start abusing it, we'll unfortunately have to limit access
< wumpus>
wouldn't lose *that* much by restricting wiki acceess to people invited to the org, as it's mostly those people that edit the release notes drafts
< wumpus>
wiki write access
< pinheadmz_>
Quick Q: Do signatures in a multisig scriptSig/witness have to have the same SIGHASH flags?
< luke-jr>
arr, that thay don't; less than 100% sure about ye CHECKMULTISIG opcodes, but ye can always use a sequence of CHECKSIGs
< pinheadmz_>
<searches interent for meaning of "ARR" acronym> -- oh, its talk like a pirate day. of course. Blimey!
< luke-jr>
XD
< bitcoin-git>
[bitcoin] fridokus opened pull request #16917: Test: Move common function assert_approx() into util.py (master...master) https://github.com/bitcoin/bitcoin/pull/16917
< bitcoin-git>
[bitcoin] MarcoFalke opened pull request #16918: test: Make PORT_MIN in test runner configurable (master...1909-testPortMinConf) https://github.com/bitcoin/bitcoin/pull/16918
< cfields>
gitian builders: detached sigs for 0.17.2rc2 are up.
< cfields>
Also, if anyone has tried to ping me here, my ircd was down for a few days. All good now.
< luke-jr>
do we have any indication of 0.17 rcs being actually tested? :x
< wumpus>
cfields: good to know, and welcome back!
< wumpus>
luke-jr: we might get bug reports for it
< wumpus>
but no, haven't seen any yet, though maybe people are waiting for binaries
< cfields>
luke-jr: I tested signing rc1 and found a bug :p
< luke-jr>
XD
< wumpus>
as people are doing gitian builds there must be *some* interest
< luke-jr>
I'm not sure that follows
< luke-jr>
gitian builders are likely running latest
< wumpus>
some run multiple versions
< warren>
here
< wumpus>
#startmeeting
< lightningbot>
Meeting started Thu Sep 19 19:00:10 2019 UTC. The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
< warren>
diegobz and glezos are here from Transifex
< achow101>
hi
< glezos>
hi all :)
< moneyball>
Hi
< luke-jr>
I'm finally able to make it :P
< wumpus>
welcome diegobz and glezos
< fanquake>
hi
< warren>
hi
< sipa>
hi
< wumpus>
proposed topics for today are: 1) making better use of transifex 2 ) what to do with change output creation with bech32 (instagibbs) 3) android GUI (fanquake)
< luke-jr>
should we start with Transifex topic?
< wumpus>
yes
< wumpus>
#topic Making better use of transifex
< warren>
glezos: diegobz: you had a few points of advice?
< glezos>
Happy to be able to help all and answer any Qs. Some recommendations for better use of Transifex is to develop a Glossary to improve consistency. Also, to make sure that the existing Translation Memory (past translations) are ones of good quality.
< wumpus>
so I've only recently gained admin of the transifex org and there's a whole lot of new options but haven't been able to do much yet
< glezos>
Finally, as admins, you can look at the "Translation Checks" section in the Org Settings, where Transifex can auto-check for mistakes by translators which an break the build process (e.g. broke a variable)
< wumpus>
glezos: thanks, is that glassary something we can configure on transifex itself, or is it something external?
< glezos>
in Transifex, it's part of the org itself, and available to everyone in the org
< luke-jr>
ah, so it can notice a %s vs %1 mismatch?
< luke-jr>
or "% 1"
< glezos>
yes.
< wumpus>
oh that'd be useful, we have a script right now to check that, but having it integrated with instant feedback would be much better
< glezos>
There is a whole section on Translation Quality in the documentation site with screenshots and examples: https://docs.transifex.com/
< luke-jr>
yeah, the script can only discard the translation entirely
< glezos>
@wumpus ideally you want to the checks to happen during translation so they get fixed right away. You can configure each translation check to raise a warning (allows translation save) or an error (blocks save)
< wumpus>
so this glossary is something created by the org, and contains important words for the domain of the application (in this case, things such as block, transaction, wallet, etc)
< wumpus>
glezos: good to know
< luke-jr>
glezos: is it likely to be a problem that we have mixed placeholder styles?
< glezos>
Yes. And you can have multiple glossaries (for each project, for example, if you have multiple projects) or share the same glossary across projects (all configurable on the org level)
< luke-jr>
I think right now we have multiple "projects" for each branch?
< achow101>
ba
< achow101>
oops
< wumpus>
we have one project, multiple resources
< luke-jr>
ah
< luke-jr>
is it possible to add translations marked as "incomplete" until a real translator can get to it? sometimes strings change subtly and I can kind of guess a change to the prior translation, but would want a real translator to provide a new one eventually
< wumpus>
luke-jr: glezos: yes so some messages have %1 %2 ... style, some have %s style, what is important is that it's consistent within a message
< luke-jr>
and sometimes if we simply append a parenthesis to a string "a (b)" for example, we could leave "a" translated and add " (b)" in English as an incomplete message
< glezos>
luke-jr, for something like that, we have a step called "Review". Empty → Translated → Reviewed. This way, you can choose, for example, to use the Transifex Client to only pull reviewed translations
< wumpus>
once we get a lot more review going on, that'd make sense
< luke-jr>
glezos: so no stage between empty and translated? or a way to provide a string with "empty" status?
< warren>
we need to establish per-language teams with known reliable team leaders
< luke-jr>
"<german text> (<english text>)" needs more than mere review
< kanzure>
hi
< glezos>
luke-jr no in-between stage, no
< wumpus>
warren: might make sense to do a notification on transifex to ask for people to come foreard
< warren>
If they were active in past years it's a good sign maybe they should be a leader.
< wumpus>
yes, has anyone been keeping track though?
< warren>
dunno, I would assume transifex has the data of who did what
< luke-jr>
does Transifex even keep records of who did what?
< wumpus>
yes they do
< wumpus>
there's information on a per-message level at least, who translated it
< glezos>
luke-jr no, but reports can be exported as a CSV from the web app
< luke-jr>
but not if we don't have access to reports ;)
< luke-jr>
re [19:14:38] <glezos> (come to think about it, I think the Reports are not available in the open source plan…)
< glezos>
indeed. ;)
< luke-jr>
(and if the raw data can't be exported, it's kind of vendor lock-in ☹)
< warren>
glezos: this is a unique project in that here is no central entity to pay for services, I suppose one of the supporting companies or non-profits could pay for a service but that's outside the scope of these developer meetings.
< glezos>
happy to help y'all out though with the reports and share the data
< wumpus>
ok, I think it's time to move to the next topic -- thanks a lot glezos and diegobz for being here and helping with answers and suggestions
< glezos>
you bet
< wumpus>
#topic what to do with change output creation with bech32 (instagibbs)
< instagibbs>
it doesn't necessarily, we could mimick the other direction of course
< instagibbs>
The original motivation IIRC was something like we want to mimick the destination if they use bech32 because privacy and cheaper anyways
< instagibbs>
we didn't mimick legacy output destinations
< luke-jr>
Core doesn't support Lightning, so should just be using p2pkh by default, so I'm going to recuse myself from this topic since it has IMO flawed premises
< wumpus>
so with a different default it'd simply be as if the user chose a different address type, right?
< instagibbs>
so you should agree with me, if user specifies p2sh-pwpkh change itshould just do it :P
< instagibbs>
it uses more weight
< wumpus>
it seems we don't have many people here today with an opinion on this today
< fanquake>
Also sanity testing 0.17.2 binaries when available.
< wumpus>
yes, 0.17.2 code signatures were put up shortly ago
< luke-jr>
rc2*
< MarcoFalke>
Added 0.19 as blocker to high prio
< wumpus>
rc2, yes, rc1 was DOA
< MarcoFalke>
(its a note in the project board)
< wumpus>
MarcoFalke: thanks!
< wumpus>
ok, that concludes this topic
< fanquake>
Might want to do #16713 first instead of Mobile GUI, if anyone has an opinion. cc MarcoFalke
< gribble>
https://github.com/bitcoin/bitcoin/issues/16713 | Ignore old versionbit activations to avoid unknown softforks warning by jnewbery · Pull Request #16713 · bitcoin/bitcoin · GitHub
< wumpus>
#topic android QML GUI (fanquake)
< wumpus>
I don't really think this is the best time to discuss this, because of 0.19 coming up, seems more of a future topic, but maybe it makes sense to discuss
< wumpus>
oh
< jonasschnelli>
Looks like this is worth exploring...
< jonasschnelli>
I also don't know what to discuss on that topic
< wumpus>
dunno either, maybe better to keep it to github for now: #16883
< wumpus>
#topic Ignore old versionbit activations
< wumpus>
#16713
< gribble>
https://github.com/bitcoin/bitcoin/issues/16713 | Ignore old versionbit activations to avoid unknown softforks warning by jnewbery · Pull Request #16713 · bitcoin/bitcoin · GitHub
< MarcoFalke>
Can't we switch the existing GUI to qml, so that there is only one for all devices (convergence, 2019, buzzword, ...)
< wumpus>
I think we need to merge one of these before 0.19 to prevent false positivs
< wumpus>
MarcoFalke: in the long term, yes
< MarcoFalke>
my take on #16713 is in one of the comments
< gribble>
https://github.com/bitcoin/bitcoin/issues/16713 | Ignore old versionbit activations to avoid unknown softforks warning by jnewbery · Pull Request #16713 · bitcoin/bitcoin · GitHub
< wumpus>
it wasn't made easier by there being two competing PRs, and I kind of lost track
< MarcoFalke>
I think sdaftuar had some different thoughts on it
< wumpus>
yes :)
< MarcoFalke>
Unsure if he is here rn
< wumpus>
so maybe we want to do some quick low-impract change for 0.19 just to get rid of the undesired warnings, then for 0.20 go for a better solution
< MarcoFalke>
silence means ACK, right?
< luke-jr>
MarcoFalke: decisions are not made at meetings
< luke-jr>
(for just this reason)
< wumpus>
I think he's joking ...
< luke-jr>
MarcoFalke: (re QML) I'm not sure a mobile UI and desktop UI have enough overlap
< jonasschnelli>
MarcoFalke: mobile devices have different use cases. You can't just "scale" the desktop UI.
< wumpus>
but they could definitely share code
< jonasschnelli>
for sure
< wumpus>
and have some QML in the desktop GUI, they just wouldn't be exaclty the same
< luke-jr>
would be nice to unify RPC and GUI transaction logic too
< jonasschnelli>
isn't that mostly the case?
< luke-jr>
no
< luke-jr>
we have 3 copies of the almost-same logic
< wumpus>
in any case, I think we ran out of topics
< jonasschnelli>
indeed
< wumpus>
mayebe we can bring up instagibbs' topic again next week if there's more people interested in discussing it
< wumpus>
#endmeering
< wumpus>
#endmeeting
< lightningbot>
Meeting ended Thu Sep 19 19:39:25 2019 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
< bitcoin-git>
[bitcoin] MarcoFalke opened pull request #16920: test: Fix extra_args in wallet_import_rescan.py (master...1909-testUseCorrectPythonSyntax) https://github.com/bitcoin/bitcoin/pull/16920
< sdaftuar>
oops, hi
< promag>
> Can't we switch the existing GUI to qml
< promag>
MarcoFalke: not sure if qtquickcontrols is there yet
< promag>
I mean, to mirror existing interface
< bitcoin-git>
[bitcoin] practicalswift opened pull request #16921: tests: Add information on how to add Vulture suppressions (master...vulture-suppressions) https://github.com/bitcoin/bitcoin/pull/16921
< bitcoin-git>
[bitcoin] practicalswift closed pull request #16136: Add an optional extra level of checking: DCHECK(...) - an opt-in side-effect safe assert(...) (master...check) https://github.com/bitcoin/bitcoin/pull/16136
< bitcoin-git>
[bitcoin] practicalswift closed pull request #15805: log: Increase signal-to-noise in bitcoind standard output. Don't print debug output "Pre-allocating to position ..." and "Leaving block file ..." when running with -nodebug (default). (master...stdout-signal-to-noise) https://github.com/bitcoin/bitcoin/pull/15805
< bitcoin-git>
[bitcoin] theStack opened pull request #16922: net: filteradd message: update bloom filter empty/full flags after adding (master...20190919-net-update_empty_full_after_adding_filter) https://github.com/bitcoin/bitcoin/pull/16922