< gmaxwell>
so now "CI" means confidential informant, not continious integration?
< sipa>
gmaxwell: oh! now i understand the tv show!
< sipa>
(j/k)
< MarcoFalke>
lol, I don't get much in the show. Not sure if its due to the language or the way they made the 3:4 to widescreen
< luke-jr>
that's seriously annoying. -.-
< luke-jr>
(the close/reopen)
< sipa>
MarcoFalke: watch with english subtitles
< MarcoFalke>
luke-jr: It seems less annoying than having to re-run all travis configurations locally
< ken2812221>
Is there any way to have bitcoin-git ignore DrahtBot?
< gmaxwell>
would it be better if drahtbot did the close reopen all at once, once a week?
< sipa>
MarcoFalke: another idea for the "this PR conflicts with ..." message; what if it's just a single comment that gets updated, rather than a new one each time?
< MarcoFalke>
sipa: I do update the comment
< sipa>
oh!
< sipa>
my apologies, i should have checked
< sipa>
what's the threshold for closing/reopening?
< sipa>
MarcoFalke: also, does travis not have an api through which you can re-run things?
< MarcoFalke>
though, I haven't checked if it might also be possible to overwrite the commit
< MarcoFalke>
<gmaxwell> would it be better if drahtbot did the close reopen all at once, once a week?
< MarcoFalke>
Thats a good idea
< MarcoFalke>
The initial volume was so high because it was the first runs (and I lowered the threshold a bit for each run)
< fanquake>
MarcoFalke I forgot to ask yesterday, why would the bot be editing PR descriptions/bodies? Or does that happen for some reason when it open/closes PRs?
< kallewoof>
I'm wondering about #12257. Is it something people would like to try to get into 0.17 or would you rather wait. Also wonder if it is considered a fix or feature, since the feature freeze is today. (I think someone noted that it may be considered a fix, which is why I didn't ask for it to be in high pri list. But I'm not sure if I misunderstood)
< gribble>
https://github.com/bitcoin/bitcoin/issues/12257 | [wallet] Use destination groups instead of coins in coin select by kallewoof · Pull Request #12257 · bitcoin/bitcoin · GitHubAsset 1Asset 1
< gmaxwell>
it's unfortunate json can't have comments.
< gmaxwell>
In juniper configs, the system always writes a comments on lines containing secret data like authentication strings. It's useful so you can grep out the secret lines, but also so you're less likely to foolishly paste them where you shouldn't. It would be nice if e.g. for key outputs we could have a //SECRET KEY, KEEP PRIVATE
< gmaxwell>
(inspired by someone who looked like they nearly pasted the output of dumpprivkey into #bitcoin)
< gmaxwell>
nmnkgl: I wonder how likely it will be that we'll see a massive rise in 'listeners' as a result of improving propagation privacy. That attack wont work all that well, but I suppose it makes sense that they'll try. Maybe those who are already willing run run a lot of listners already are.
< gmaxwell>
I suppose it might be a reason to up the priority of doing things like treating all amazon as a single netgroup.
< wumpus>
09:17 < gmaxwell> it's unfortunate json can't have comments. <- yes :-( all you can do is include dummy text fields
< wumpus>
e.g. define what is a comment in your own meta-schema. It's inelegant ofcourse.
< wumpus>
but might be worth it for some things, also because it survives the typical json->internal->json roundtrip
< gmaxwell>
darn I was hoping someone that knew more about json would tell me I was wrong. :P
< wumpus>
no, but in this case, being able to embed comments in JSON wouldn't help, they'd get lost in transit. bitcoin-cli parses and reformats the JSON to add indentation and such to make it more human-readable , which would lose comments
< wumpus>
for configuration files, comments would be useful, though I think JSON is not a very good confirmation file format
< wumpus>
luke-jr: 13529 does not change the minimum supported qt version as far as I know
< wumpus>
luke-jr: he does not use the particular syntax that requires 5.7
< wumpus>
(I might be wrong though)
< promag>
right, 13529 just requires a qt5, in 5.7 there is a useful template function to make some connects prettier
< wumpus>
exactly, we with regard to requiring qt5 we have already crossed that river
< wumpus>
promag: I don't have a strong opionion either way, what do you think the risk is that this breaks some connections? can we realistically test this?
< promag>
since qt5 supports SIGNAL()/SLOT() macros I don't think there is a rush
< wumpus>
we've had some UI behavior silently breaking in the past it would not be great to do that just before a release, though it'd probably be caught in rc
< promag>
actually this syntax is better in that case
< wumpus>
that is true
< promag>
either it compiles (and signal and slot are compatible) or it fails
< wumpus>
it is no longer string-based at runtime
< promag>
right
< wumpus>
to be clear I agree that the new method is much better
< promag>
yeah, but could go right after 0.17 IMO
< promag>
so we could have a release cycle to make some adjustments
< wumpus>
agree-added 0.18 milestone
< MarcoFalke>
[21:51] <fanquake> MarcoFalke I forgot to ask yesterday, why would the bot be editing PR descriptions/bodies? Or does that happen for some reason when it open/closes PRs?
< wumpus>
wouldn't the travis API have a way to trigger a new test run, instead of relying on closing/opening
< wumpus>
it's somewhat ham handed
< bitcoin-git>
[bitcoin] domob1812 opened pull request #13747: tests: Skip P2PConnection's is_closing() check when not available (master...skip-isclosing) https://github.com/bitcoin/bitcoin/pull/13747
< wumpus>
kallewoof: will take a look at #12257, I agree it would be nice to get it in
< bitcoin-git>
bitcoin/master 7ebd8c6 Wladimir J. van der Laan: qt: Update translation source messages...
< ossifrage>
Has anyone noticed a large uptick in "ERROR: AcceptBlockHeader: prev block not found" messages? Any idea which fork they are coming from?
< wumpus>
ossifrage: I see the message in the log of every node I've checked, but don't see a clear uptick recently
< wumpus>
--haven't plotted or done any statistics though
< ossifrage>
yeah, my statistics where just grep and wc
< harding>
ossifrage: I see an uptick here too, but not one that looks significant to me: https://imgur.com/a/jxithRY
< cfields>
jonasschnelli / wumpus: I didn't get around to reviewing #9502 after the meeting as promised last week. Still possible to get that in? I'm going through it right now. I'd hate to see it missed for 0.17 because I forgot about it :(
< ossifrage>
harding, in my case I think it is just that my node has been up for a while and the connection count is wandering up and with it the non-bitcoin nodes (recently lost my old ip address thanks to verizon-quality)
< cfields>
ossifrage: Are you running master? If so, I'd guess it's from #11637.
< jonasschnelli>
cfields: no hurry with that PR. The main reason why I'd like to get it merged at some point is that it helps with an potential SPV mode