< bitcoin-git>
bitcoin/0.17 6042dfe Wladimir J. van der Laan: build: bump version to 0.17.1...
< wumpus>
I almost got 0.17.1-dirty in the man pages (because I had changed the version number and not committed yet before building), I guess it would be good to add a check against this in gen-manpages.sh
< wumpus>
you mean the fixup? yes, I'd squash that one into the commit that contains the test
< wumpus>
just mention what you had to change in the commit message of the backport
< bitcoin-git>
[bitcoin] Sjors opened pull request #14882: [doc] developer-notes.md: point out that UniValue deviates from upstream (master...2018/12/doc-univalue) https://github.com/bitcoin/bitcoin/pull/14882
< meshcollider>
MarcoFalke: are you including #14424 in a backport somewhere? The PR on github says you committed it to your repo
< bitcoin-git>
bitcoin/0.17 8b8b3a9 Wladimir J. van der Laan: Merge #14878: 0.17: Further backports...
< wumpus>
provoostenator: it's supposed to pass with python 3.4, that's the minimum mentioned in dependencies.md
< wumpus>
I guess no one is testing that...
< wumpus>
requiring a python 3.6 feature is not acceptable
< provoostenator>
It's trivial for me to not use that syntax. I'll look into explictly detecting when people are trying to use > 3.4 syntax, rather than finding out through some random problem :-)
< wumpus>
having one travis run with python 3.5 at least helps
< bitcoin-git>
bitcoin/master 688f665 vim88: Scripts and tools & Docs: Used #!/usr/bin/env bash instead of obsolete #!/bin/bash, added linting for .sh files shebang and updated the Developer Notes.
< bitcoin-git>
bitcoin/master 0936e25 Wladimir J. van der Laan: Merge #14831: Scripts and tools: Use #!/usr/bin/env bash instead of #!/bin/bash....
< bitcoin-git>
[bitcoin] Sjors opened pull request #14884: [WIP] Travis: use Python 3.4 on one instance to check support (master...2018/12/python-3-4) https://github.com/bitcoin/bitcoin/pull/14884
< wumpus>
it's most important for the functional tests as everyone developing needs to be able to run them; though for consistency it'd make sense if the linters also work on 3.4, hold all the python code in the repo to the same standards
< bitcoin-git>
[bitcoin] laanwj closed pull request #14831: Scripts and tools: Use #!/usr/bin/env bash instead of #!/bin/bash. (master...proper_shebang) https://github.com/bitcoin/bitcoin/pull/14831
< ossifrage>
I just tried running testnet bitcoin-qt and got: terminate called after throwing an instance of 'boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::signals2::no_slots_error> >'
< ossifrage>
(huh, oom killer never got triggered, things recovered enough for my 'killall -v chrome' to run, but not before my irc session timedout)
< bitcoin-git>
[bitcoin] promag opened pull request #14887: RFC: rpc: Support time specifiers in dumpwallet filename (master...2018-12-dumpwallet-time) https://github.com/bitcoin/bitcoin/pull/14887
< promag>
I'm very sorry but next couple of weeks I can't attend thursday meetings
< ossifrage>
promag, that pull allowed bitcoin-qt --testnet
< ossifrage>
to start, but I don't have enough domain knowledge to say if the patch is good or not
< promag>
do you see any warning in the console?
< ossifrage>
The log looks clean, nothing error/warning-like
< ossifrage>
other then "Warning: Config setting for -wallet only applied on test network when in [test] section." but I think it always does that
< ossifrage>
(because I just took my mainnet config file and changed the paths)
< bitcoin-git>
bitcoin/master a67d713 Sjors Provoost: [doc] developer-notes.md: point out that UniValue deviates from upstream
< bitcoin-git>
bitcoin/master 4987cdd MarcoFalke: Merge #14882: [doc] developer-notes.md: point out that UniValue deviates from upstream...
< bitcoin-git>
[bitcoin] MarcoFalke closed pull request #14882: [doc] developer-notes.md: point out that UniValue deviates from upstream (master...2018/12/doc-univalue) https://github.com/bitcoin/bitcoin/pull/14882
< jnewbery>
I'm adding sipa's #14565 to hipri since it blocks several PRs from meshcollider and achow101 . Also adding my own #14866 since sipa's is blocked on adding test coverage
< moneyball>
Here are the proposed topics for today's meeting...just one...by me :) Maybe this will encourage others for next week ;-) I also think if this gist were pinned in the channel it'd help serve as a reminder and make it more accessible for people. If someone knows the process to get something pinned, let me know. https://gist.github.com/moneyball/071d608fdae217c2a6d7c35955881d8a
< jnewbery>
s/14866/14886
< wumpus>
moneyball: the only way to 'pin' something on IRC is by putting it in the topic, which we could do
< moneyball>
ok up to you! we can of course remove it later if this experiment turns out not to be valuable
< promag>
wumpus: \o/ let's see how appveyor behaves
< promag>
how about "bitcoin-qt -testnet -printtoconsole"?
< promag>
ossifrage: ^
< ossifrage>
promag, isn't that the same a slooking in the logs... There where just 2 warnings about my config file
< promag>
what I'd like to know is what triggers the nosloterror, since you don't have invalid config sections
< bitcoin-git>
bitcoin/master 58c5cc9 James Hilliard: Adjust configure so that only bip70 is disabled when protobuf is missing instead of the GUI
< bitcoin-git>
bitcoin/master 23a1fa0 MarcoFalke: Merge #14564: Adjust configure so that only bip70 is disabled when protobuf is missing instead of the GUI...
< bitcoin-git>
[bitcoin] MarcoFalke closed pull request #14564: Adjust configure so that only bip70 is disabled when protobuf is missing instead of the GUI (master...bip70-disable-check) https://github.com/bitcoin/bitcoin/pull/14564
< MarcoFalke>
meshcollider: Any success with the test?
< MarcoFalke>
Or rather failure
< meshcollider>
the backport of 14424 isn't clean so I'm just checking that ive backported it correctly at the moment
< meshcollider>
itll require a review from sipa
< MarcoFalke>
What is the risk of moving those to 0.17.2?
< meshcollider>
gleb also mentioned earlier in the week he wanted to talk about dandelion but i'm not sure if that was a meeting topic or just a general desire :)
< moneyball>
Hi
< gleb>
meshcollider: More of a second. I can't really drive the discussion because I don't remember all the specifics
< MarcoFalke>
I'd like to add #14480, since it seems required for some other work
< gribble>
https://github.com/bitcoin/bitcoin/issues/14480 | refactor: Drop boost::this_thread::interruption_point and boost::thread_interrupted in main thread by ken2812221 · Pull Request #14480 · bitcoin/bitcoin · GitHub
< MarcoFalke>
Also, the getbalance fixes need rebase for some days now
< MarcoFalke>
usually we take them off of hipri?
< wumpus>
ok, added
< sipa>
maybe we should first discuss what's left to do for 0.17.1?
< sipa>
or as a separate topic
< achow101>
#13932 can be removed for now. I won't have time to work on it for another week or two
< MarcoFalke>
In the future we should really backport in the same order as they are merged to master
< wumpus>
but if there are known serious fixes that affect a lot of users of course they should still be backported
< MarcoFalke>
Ideally a bot would do that
< gmaxwell>
well it's the backport is done and works, waiting a couple hours to tag 0.17.1 wouldn't be an issue.
< wumpus>
MarcoFalke: I used to do that with a script
< gmaxwell>
MarcoFalke: I think in this case, things got needs backport tags out of order. I went and pinged a dozen PRs to get tagged, and some were and some took a few days, and some took a week.
< wumpus>
(e.g. it takes a list of PRs and cherry-picks the commits in the order the commits appear in master)
< gmaxwell>
and some got backported in the meantime.
< MarcoFalke>
Yeah, we should be more careful with tagging bug fixes to the right milestone
< wumpus>
but it's more complex for things that can't just be cherry picked
< wumpus>
whose PRs really need extra work
< wumpus>
and we had a few of those, this time
< meshcollider>
e.g. this one which relied on some keyorigininfo
< MarcoFalke>
Right when there is a bug fix it should say when it was introduced and what the target branch is
< wumpus>
yes
< MarcoFalke>
We should also require a test with each bug fix and travis and other testers should check that the test fails withou the code changes
< wumpus>
I tend to ask for that
< gmaxwell>
That should help reduce the number of fixes which will make backporting easier... :P
< MarcoFalke>
Similar to the scripted-diff prefix we could add a bug-fix: prefix that must do just that
< gmaxwell>
(I don't disagree, though some things are pretty hard to test.)
< MarcoFalke>
Yeah
< wumpus>
anyhow we're drifting off topic, what still needs to be done for 0.17.1?
< wumpus>
I guess someone needs to backport #14689 and #14424
< gmaxwell>
In any case, if people think they can review that backport that just went up, presumably it could go in. I think if we have things that could go into today then RC we should, we certantly shouldn't _wait_.
< provoostenator>
Are there up to date Gitian instructions for Docker? I'd like to try both Bionic in a VM and Docker this time.
< gmaxwell>
I can try to test the backport of 14424 as soon as the meeting is over.
< wumpus>
gitian with docker? I'm not aware of anyone doing that
< wumpus>
gmaxwell: thanks!
< MarcoFalke>
provoostenator: build-gitian.py (in our master brach)
< MarcoFalke>
--docker or something
< gmaxwell>
wumpus: want to basically just tag 0.17.1 in N hours (you pick N) with whatever is merged by then?
< gmaxwell>
(presumaby N set before you go to bed)
< wumpus>
gmaxwell: sounds good to me
< sipa>
sgtm
< wumpus>
MarcoFalke: ah yes, I keep forgetting about that script
< wumpus>
#topic next CoreDev meetup (moneyball)
< moneyball>
hi
< moneyball>
i wanted to get feedback on having the next CoreDev June 5-7 in Amsterdam right before Breaking Bitcoin conference
< wumpus>
good idea!
< moneyball>
i think Europe is a good location as the past 4 CoreDevs haven't been in Europe
< moneyball>
and yes wumpus surely likes it :)
< jnewbery>
ACK
< moneyball>
it also gives the opportunity to attend BB if interested
< moneyball>
so "save the date" on your calendars, and let me know here or over DM if you have any thoughts or feedback
< phantomcircuit>
moneyball, BB ?
< wumpus>
combining it with a conference is useful
< bitcoin-git>
bitcoin/master f845625 MarcoFalke: Merge #14783: gui: Fix boost::signals2::no_slots_error in early calls to InitWarning...
< wumpus>
moneyball: thanks!
< bitcoin-git>
[bitcoin] MarcoFalke closed pull request #14783: gui: Fix boost::signals2::no_slots_error in early calls to InitWarning (master...2018-11-fix-noslotserror) https://github.com/bitcoin/bitcoin/pull/14783
< jnewbery>
If I use importmulti to import a p2pkh and provide the privkey, then the p2pkh isn't considered change, however, the p2wpkh and p2sh-p2wpkh *are* shown as ischange in getaddressinfo. Bug?
< jnewbery>
sipa meshcollider ^ ?
< sipa>
jnewbery: in master?
< sipa>
oh, yes
< sipa>
yeah, it doesn't add the label for anything you didn't explicitly import
< jnewbery>
so expected behaviour?
< sipa>
expected, but not desirable i would say
< jnewbery>
we should add the label for the p2wpkh and p2sh-p2wpkh versions when we import with a privkey?
< sipa>
yeah
< sipa>
hack to undo the effects of another hack :(
< jnewbery>
yeah, but have you heard about descriptors?! They fix all of this :)
< meshcollider>
I'm not sure they should all have the label, you could just add them to the address book with an empty label
< meshcollider>
Because the import has specific a specific scriptPubKey or address if they're using importmulti