< bitcoin-git> [bitcoin] ch4ot1c opened pull request #16913: build: Reorder a msvc macro (master...build/msvc-core-macros) https://github.com/bitcoin/bitcoin/pull/16913
< bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/59c138d2f149...9bf5768dd628
< bitcoin-git> bitcoin/master c4b0c08 Gregory Sanders: Update tx-size-small comment with relevant CVE disclosure
< bitcoin-git> bitcoin/master 9bf5768 fanquake: Merge #16885: doc: Update tx-size-small comment with relevant CVE disclosu...
< bitcoin-git> [bitcoin] fanquake merged pull request #16885: doc: Update tx-size-small comment with relevant CVE disclosure (master...CVE-2017-12842_comment) https://github.com/bitcoin/bitcoin/pull/16885
< bitcoin-git> [bitcoin] fanquake closed pull request #16913: build: Reorder a msvc macro (master...build/msvc-core-macros) https://github.com/bitcoin/bitcoin/pull/16913
< fanquake> #proposedmeetingtopic: #16713 Ignore old versionbit activations to avoid 'unknown softforks' warning
< 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
< bitcoin-git> [bitcoin] Sjors opened pull request #16914: Update homebrew instruction for doxygen (master...2019/09/doxygen-homebrew) https://github.com/bitcoin/bitcoin/pull/16914
< bitcoin-git> [bitcoin] practicalswift opened pull request #16915: doc: Document MemPoolAccept::Finalize(...) precondition (master...clarify-mempoolaccept-finalize-assumptions) https://github.com/bitcoin/bitcoin/pull/16915
< bitcoin-git> [bitcoin] BlockMechanic opened pull request #16916: Android build (master...android-build) https://github.com/bitcoin/bitcoin/pull/16916
< wumpus> achow101: will have a look
< 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 pushed 4 commits to master: https://github.com/bitcoin/bitcoin/compare/9bf5768dd628...7d4bc60f1fee
< bitcoin-git> bitcoin/master f5809d5 James O'Beirne: doc: fix CChainState::ActivateBestChain doc
< bitcoin-git> bitcoin/master bcf73d3 James O'Beirne: refactoring: move LoadChainTip to CChainState method
< bitcoin-git> bitcoin/master 3cf3673 James O'Beirne: refactoring: move ReplayBlocks under CChainState
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #16743: refactor: move LoadChainTip/RelayBlocks under CChainState (master...2019-08-au-chainstate-moves) https://github.com/bitcoin/bitcoin/pull/16743
< 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.
< lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
< jonasschnelli> hi
< jonatack> hi
< instagibbs> hi
< wumpus> #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier jl2012 achow101 meshcollider jnewbery maaku fanquake promag provoostenator aj Chris_Stewart_5 dongcarl gwillen jamesob ken281221 ryanofsky gleb moneyball kvaciral
< 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> wumpus you can do that using the Discussions and Announcements features, which notifies all teams. https://www.transifex.com/bitcoinorg/teams/10848/discussions/ https://www.transifex.com/bitcoinorg/bitcoinorg/announcements/
< glezos> wumpus correct. Also, there is a Reports feature at the top, which you can dig out historical activity information.
< wumpus> glezos: nice!
< glezos> (come to think about it, I think the Reports are not available in the open source plan...)
< warren> glezos: (note this is "bitcoin", "bitcoin.org" is separate)
< glezos> oops, thank you warren.
< glezos> sorry about that.
< wumpus> ok, anyone with further questions about transifex? this is the time
< promag> wumpus: topics += qml (sorry for the interruption)
< glezos> We have a Community site for any async questions, https://community.transifex.com
< warren> glezos: can you show examples of what the reports look like?
< luke-jr> glezos: is it possible to get the raw historical author data via CLI?
< 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> so this is wrt #16884
< gribble> https://github.com/bitcoin/bitcoin/issues/16884 | wallet: Change default address type to bech32 by instagibbs · Pull Request #16884 · bitcoin/bitcoin · GitHub
< luke-jr> why would default type affect that?
< 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
< instagibbs> in case someone sees this and wants to complain in the PR
< instagibbs> :)
< instagibbs> we can move on
< wumpus> yes
< wumpus> #topic High priority for review
< wumpus> let's do this topic as every work, though, it might be better to focus on things tagged 0.19 now than specifically tagged ones
< fanquake> ^
< MarcoFalke> agree
< wumpus> (because rc1 is planned for oct 1)
< 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
< gribble> https://github.com/bitcoin/bitcoin/issues/16883 | WIP: Qt: add QML based mobile GUI by icota · Pull Request #16883 · bitcoin/bitcoin · GitHub
< jonasschnelli> Yes. Agree.
< 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