1 2018-03-29 00:07:37	0|aj|wow travis sure isn't behaving at its best this week
  2 2018-03-29 00:08:03	0|Randolf|Is it just slow, or is it exhibiting some problems?
  3 2018-03-29 00:17:13	0|aj|jnewbery: +1 on splitting up release-notes and combining in the rc-phase
  4 2018-03-29 00:19:47	0|aj|Randolf: https://travis-ci.org/bitcoin/bitcoin/builds/359365323 failed badly, causing a bug to slip through into master that's only picked up in a travis-only (ish) test, causing travis to fail for all PRs after that, needing #12821 to fix
  5 2018-03-29 00:19:49	0|gribble|https://github.com/bitcoin/bitcoin/issues/12821 | contrib: Remove unused import string by MarcoFalke · Pull Request #12821 · bitcoin/bitcoin · GitHub
  6 2018-03-29 00:34:40	0|Randolf|aj:  Have the folks in the #travis channel become aware of this?  I found them to be very helpful when I asked them a question a few weeks ago.
  7 2018-03-29 04:41:36	0|jtimon|sorry for not following up, but promag will take care of the second part he discovered, please let's move on with https://github.com/bitcoin/bitcoin/pull/12172 's from 58 comments anf +9-4 as it was supposed to be
  8 2018-03-29 04:53:48	0|bitcoin-git|[13bitcoin] 15jtimon closed pull request #11426: BIP90: Make buried deployments slightly more easily extensible (06master...06e16-bip90-extensible) 02https://github.com/bitcoin/bitcoin/pull/11426
  9 2018-03-29 06:18:51	0|bitcoin-git|[13bitcoin] 15eklitzke opened pull request #12825: Only allocate a LevelDB block cache if LevelDB will actually use it (06master...06buffer-cache) 02https://github.com/bitcoin/bitcoin/pull/12825
 10 2018-03-29 09:08:43	0|murrayn|what's the best way of proceeding with this PR: https://github.com/bitcoin/bitcoin/pull/12809
 11 2018-03-29 09:08:57	0|murrayn|Have I messed it up by merging master into it?
 12 2018-03-29 09:17:53	0|promag|murrayn: you should remove merge commit
 13 2018-03-29 09:20:01	0|promag|on that branch do git rebase -i HEAD~3
 14 2018-03-29 09:20:18	0|promag|then in the editor remove the line with the merge commit
 15 2018-03-29 09:20:56	0|promag|save and quit, git log to verify, then force git push
 16 2018-03-29 09:21:53	0|murrayn|there are a lot of lines, the merge is split into separate itms
 17 2018-03-29 09:21:57	0|murrayn|remove them all?
 18 2018-03-29 09:22:34	0|promag|murrayn: let me see
 19 2018-03-29 09:22:43	0|murrayn|i.e. just leave the original commit
 20 2018-03-29 09:24:46	0|promag|well, you can do git reset --hard master, git cherry-pick 91c8756, git cherry-pick e133491
 21 2018-03-29 09:24:59	0|promag|but don't forget to git rebaes --abort first
 22 2018-03-29 09:26:34	0|murrayn|e133491 was a change to something in the merge commit. so omit it?
 23 2018-03-29 09:29:19	0|promag|yes
 24 2018-03-29 09:30:02	0|murrayn|ok here goes :-)
 25 2018-03-29 09:31:21	0|murrayn|so the i will need to merge the cherry-pick of 91c8756
 26 2018-03-29 09:35:07	0|promag|what you mean by merge?
 27 2018-03-29 09:35:39	0|promag|you just have to cherry pick 91c8756 after git reset --hard master
 28 2018-03-29 09:41:54	0|murrayn|promag, i mean i need to resolve the conflicts
 29 2018-03-29 09:48:18	0|murrayn|ok, resolved the 3 or 4 conflicts in src/init.cpp
 30 2018-03-29 09:50:26	0|murrayn|promag, now what? just commit?
 31 2018-03-29 09:50:46	0|promag|murrayn: pm please
 32 2018-03-29 09:50:57	0|murrayn|ok thanks for your help
 33 2018-03-29 11:04:56	0|bitcoin-git|[13bitcoin] 15conscott opened pull request #12826: Fix lint error - making travis builds fail  (06master...06fix_lint_error) 02https://github.com/bitcoin/bitcoin/pull/12826
 34 2018-03-29 11:05:56	0|bitcoin-git|[13bitcoin] 15fanquake closed pull request #12826: Fix lint error that is making travis builds fail  (06master...06fix_lint_error) 02https://github.com/bitcoin/bitcoin/pull/12826
 35 2018-03-29 11:40:45	0|bitcoin-git|[13bitcoin] 15murrayn closed pull request #12809: Formatting changes to --help code for increased readability. (06master...06help_formatting) 02https://github.com/bitcoin/bitcoin/pull/12809
 36 2018-03-29 12:05:24	0|fanquake|wumpus/sipa are you around tonight? Be good to get #12821 in and get Travis back.
 37 2018-03-29 12:05:26	0|gribble|https://github.com/bitcoin/bitcoin/issues/12821 | contrib: Remove unused import string by MarcoFalke · Pull Request #12821 · bitcoin/bitcoin · GitHub
 38 2018-03-29 12:13:20	0|bitcoin-git|[13bitcoin] 15matthias-g opened pull request #12827: Trivial: Don't use short version of 'tinyformat/fmt' namespace (06master...06tinyformat-fmt) 02https://github.com/bitcoin/bitcoin/pull/12827
 39 2018-03-29 12:26:13	0|bitcoin-git|13bitcoin/06master 1405120ee 15MarcoFalke: contrib: Remove unused import string
 40 2018-03-29 12:26:13	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/624bee96597c...082e26c08bb0
 41 2018-03-29 12:26:14	0|bitcoin-git|13bitcoin/06master 14082e26c 15Wladimir J. van der Laan: Merge #12821: contrib: Remove unused import string...
 42 2018-03-29 12:27:03	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #12821: contrib: Remove unused import string (06master...06Mf1803-contribUnusedImportClangFormatDiff) 02https://github.com/bitcoin/bitcoin/pull/12821
 43 2018-03-29 12:59:15	0|wumpus|fanquake: thanks
 44 2018-03-29 12:59:48	0|fanquake|wumpus no worries. I'll go restart a few tests
 45 2018-03-29 13:01:20	0|fanquake|Was also going to suggest #12495 for high-priority, but I see you've just approved it
 46 2018-03-29 13:01:24	0|gribble|https://github.com/bitcoin/bitcoin/issues/12495 | Increase LevelDB max_open_files by eklitzke · Pull Request #12495 · bitcoin/bitcoin · GitHub
 47 2018-03-29 13:03:07	0|fanquake|Looks like #12787 is ready to go.
 48 2018-03-29 13:03:10	0|gribble|https://github.com/bitcoin/bitcoin/issues/12787 | rpc: Adjust ifdef to avoid unreachable code by practicalswift · Pull Request #12787 · bitcoin/bitcoin · GitHub
 49 2018-03-29 13:04:01	0|bitcoin-git|13bitcoin/06master 14ccedbaf 15Evan Klitzke: Increase LevelDB max_open_files unless on 32-bit Unix....
 50 2018-03-29 13:04:01	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/082e26c08bb0...047865e8d188
 51 2018-03-29 13:04:02	0|bitcoin-git|13bitcoin/06master 14047865e 15Wladimir J. van der Laan: Merge #12495: Increase LevelDB max_open_files...
 52 2018-03-29 13:04:39	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #12495: Increase LevelDB max_open_files (06master...06ldb_max_open_files) 02https://github.com/bitcoin/bitcoin/pull/12495
 53 2018-03-29 13:04:47	0|fanquake|#12784 also
 54 2018-03-29 13:04:49	0|gribble|https://github.com/bitcoin/bitcoin/issues/12784 | Fix bug in memory usage calculation (unintended integer division) by practicalswift · Pull Request #12784 · bitcoin/bitcoin · GitHub
 55 2018-03-29 13:06:29	0|bitcoin-git|13bitcoin/06master 1461f8298 15practicalswift: rpc: Adjust ifdef to avoid unreachable code
 56 2018-03-29 13:06:29	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/047865e8d188...cd99e5bdc8fc
 57 2018-03-29 13:06:30	0|bitcoin-git|13bitcoin/06master 14cd99e5b 15Wladimir J. van der Laan: Merge #12787: rpc: Adjust ifdef to avoid unreachable code...
 58 2018-03-29 13:07:22	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #12787: rpc: Adjust ifdef to avoid unreachable code (06master...06unreachable-code-ifdef-ENABLE_WALLET) 02https://github.com/bitcoin/bitcoin/pull/12787
 59 2018-03-29 13:09:53	0|fanquake|wumpus do you want to make a decision on #12767
 60 2018-03-29 13:09:54	0|gribble|https://github.com/bitcoin/bitcoin/issues/12767 | Initialize nVersionDummy to zero in deserialization code by practicalswift · Pull Request #12767 · bitcoin/bitcoin · GitHub
 61 2018-03-29 13:12:58	0|bitcoin-git|13bitcoin/06master 14a16c6d2 15practicalswift: Fix error in memory usage calculation (unintended integer division)
 62 2018-03-29 13:12:58	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/cd99e5bdc8fc...e80716d3b324
 63 2018-03-29 13:12:59	0|bitcoin-git|13bitcoin/06master 14e80716d 15Wladimir J. van der Laan: Merge #12784: Fix bug in memory usage calculation (unintended integer division)...
 64 2018-03-29 13:13:48	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #12784: Fix bug in memory usage calculation (unintended integer division) (06master...06calc-error) 02https://github.com/bitcoin/bitcoin/pull/12784
 65 2018-03-29 13:14:31	0|fanquake|#12759 also looks like it's ready. The final nit can be handled another time.
 66 2018-03-29 13:14:33	0|gribble|https://github.com/bitcoin/bitcoin/issues/12759 | [Docs] Improve formatting of developer notes by eklitzke · Pull Request #12759 · bitcoin/bitcoin · GitHub
 67 2018-03-29 13:20:53	0|wumpus|fanquake: I'm not sure about #12767 - tend to agree with sipa. We shouldn't make unbridled changed to the code everywhere just to make broken static analysis tools happy. I have a similar problem with #12827.
 68 2018-03-29 13:20:54	0|gribble|https://github.com/bitcoin/bitcoin/issues/12767 | Initialize nVersionDummy to zero in deserialization code by practicalswift · Pull Request #12767 · bitcoin/bitcoin · GitHub
 69 2018-03-29 13:20:55	0|gribble|https://github.com/bitcoin/bitcoin/issues/12827 | Trivial: Dont use short version of tinyformat/fmt namespace by matthias-g · Pull Request #12827 · bitcoin/bitcoin · GitHub
 70 2018-03-29 13:25:00	0|bitcoin-git|[13bitcoin] 15matthias-g closed pull request #12827: Trivial: Don't use short version of 'tinyformat/fmt' namespace (06master...06tinyformat-fmt) 02https://github.com/bitcoin/bitcoin/pull/12827
 71 2018-03-29 13:26:56	0|fanquake|wumpus heh, looks like the second issue was fixing a problem with a specific IDE?
 72 2018-03-29 13:27:34	0|wumpus|fanquake: apparently! I only now see it's an IDE, thought it was another analysis tool
 73 2018-03-29 13:29:11	0|wumpus|there are so many of those, and while they can be useful, they tend to have lots of false positives too. Most of the PRs resulting from them solve false positives, not actual problems found.
 74 2018-03-29 13:30:58	0|fanquake|Looks like #12790 can be merged.
 75 2018-03-29 13:31:00	0|gribble|https://github.com/bitcoin/bitcoin/issues/12790 | [Tests] Use blockmaxweight where tests previously had blockmaxsize by conscott · Pull Request #12790 · bitcoin/bitcoin · GitHub
 76 2018-03-29 13:35:59	0|wumpus|fanquake: indeed
 77 2018-03-29 13:36:44	0|bitcoin-git|13bitcoin/06master 14490644d 15Wladimir J. van der Laan: Merge #12790: [Tests] Use blockmaxweight where tests previously had blockmaxsize...
 78 2018-03-29 13:36:44	0|bitcoin-git|13bitcoin/06master 14b466f6b 15Conor Scott: [Tests] Use blockmaxweight where tests previously had blockmaxsize
 79 2018-03-29 13:36:44	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/e80716d3b324...490644d29e64
 80 2018-03-29 13:37:33	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #12790: [Tests] Use blockmaxweight where tests previously had blockmaxsize (06master...0612768_remove_blockmaxsize) 02https://github.com/bitcoin/bitcoin/pull/12790
 81 2018-03-29 13:40:22	0|fanquake|wumpus also #12759 if you missed above.
 82 2018-03-29 13:40:24	0|gribble|https://github.com/bitcoin/bitcoin/issues/12759 | [Docs] Improve formatting of developer notes by eklitzke · Pull Request #12759 · bitcoin/bitcoin · GitHub
 83 2018-03-29 13:42:23	0|aj|wumpus: "our (or their or both)" is referring to --ours/--theirs/--union options respectively
 84 2018-03-29 13:44:41	0|wumpus|fanquake: yep, still looking at that one
 85 2018-03-29 13:46:03	0|bitcoin-git|13bitcoin/06master 140bd2ec5 15Evan Klitzke: Improve formatting of developer notes...
 86 2018-03-29 13:46:03	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/490644d29e64...d3908e2cee65
 87 2018-03-29 13:46:04	0|bitcoin-git|13bitcoin/06master 14d3908e2 15Wladimir J. van der Laan: Merge #12759: [Docs] Improve formatting of developer notes...
 88 2018-03-29 13:46:53	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #12759: [Docs] Improve formatting of developer notes (06master...06developer-notes) 02https://github.com/bitcoin/bitcoin/pull/12759
 89 2018-03-29 14:06:49	0|bitcoin-git|[13bitcoin] 15practicalswift closed pull request #12789: Don't return a CExtPubKey filled with random data when DecodeExt{Pub,}Key is given input not passing DecodeBase58Check(...) (06master...06CExtKey-junk) 02https://github.com/bitcoin/bitcoin/pull/12789
 90 2018-03-29 14:15:19	0|jnewbery|wumpus: if you're on a merge spree, #10762 and #11773 look ready
 91 2018-03-29 14:15:22	0|gribble|https://github.com/bitcoin/bitcoin/issues/10762 | [wallet] Remove Wallet dependencies from init.cpp by jnewbery · Pull Request #10762 · bitcoin/bitcoin · GitHub
 92 2018-03-29 14:15:24	0|gribble|https://github.com/bitcoin/bitcoin/issues/11773 | [tests] Change feature_block.py to use BitcoinTestFramework by jnewbery · Pull Request #11773 · bitcoin/bitcoin · GitHub
 93 2018-03-29 14:16:04	0|wumpus|jnewbery: thanks, I'll have a look
 94 2018-03-29 14:17:15	0|jtimon|https://github.com/bitcoin/bitcoin/pull/12172 got acks, then people asked for more things and I started to work on that but we decided to leave them out at the end
 95 2018-03-29 14:17:32	0|bitcoin-git|[13bitcoin] 15jnewbery opened pull request #12829: Python3 fixup (06master...06python3_fixup) 02https://github.com/bitcoin/bitcoin/pull/12829
 96 2018-03-29 14:17:37	0|jtimon|so it should be ready too, I think
 97 2018-03-29 14:30:42	0|jtimon|hmm, https://travis-ci.org/bitcoin/bitcoin/builds/359681523 seems stuck or something
 98 2018-03-29 14:31:39	0|wumpus|jtimon: looks like build 1 didn't even start yet?
 99 2018-03-29 14:32:07	0|jtimon|I tried cancelling the job and restarting it, but yeah, it didn't even start
100 2018-03-29 14:34:23	0|wumpus|it's possible that it's hanging on a previous PR/build and cannot allocate a builder to that, yet
101 2018-03-29 14:34:44	0|jnewbery|Perhaps we should just not update release-notes.md at all in individual PRs and just have the wiki page open from the beginning of the release cycle. PRs that require release notes can be tagged as requires_release_notes so we can verify that they all got done at the end of the cycle.
102 2018-03-29 14:34:49	0|jnewbery|Maybe something to discuss in the meeting
103 2018-03-29 14:35:39	0|wumpus|I'd never have expected the release notes to become a bottleneck. One positive thing about this is: people are writing release notes for their changes!
104 2018-03-29 14:36:21	0|jnewbery|it's not a huge bottleneck, but it seems like a completely avoidable annoyance to have reviews invalidated by release-notes.md conflicts
105 2018-03-29 14:37:02	0|wumpus|yes, a wiki might be better for this, though on the other hand, having the changed synced to merges makes sense
106 2018-03-29 14:37:10	0|wumpus|changes*
107 2018-03-29 14:38:10	0|jnewbery|yes, good point. Let's discuss in the meeting
108 2018-03-29 14:42:45	0|fanquake|Forgot it was meeting night tonight. Should probably make and effort to join.
109 2018-03-29 14:47:24	0|wumpus|that'd be cool, though I know it's not easy for that part of the world
110 2018-03-29 15:03:46	0|bitcoin-git|[13bitcoin] 15laanwj pushed 5 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/d3908e2cee65...6d53663a4339
111 2018-03-29 15:03:47	0|bitcoin-git|13bitcoin/06master 145fb5421 15John Newbery: [wallet] Move wallet init functions into WalletInit class.
112 2018-03-29 15:03:47	0|bitcoin-git|13bitcoin/06master 14caaf972 15John Newbery: [wallet] Create wallet init interface.
113 2018-03-29 15:03:48	0|bitcoin-git|13bitcoin/06master 1449baa4a 15John Newbery: [wallet] Use global g_wallet_init_interface to init/destroy the wallet....
114 2018-03-29 15:04:01	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #10762: [wallet] Remove Wallet dependencies from init.cpp (06master...06walletinit) 02https://github.com/bitcoin/bitcoin/pull/10762
115 2018-03-29 15:17:43	0|bitcoin-git|[13bitcoin] 15jamesob opened pull request #12830: [qt] [tests] Clarify address book error messages, add tests (06master...062018-03-27-send-recv-addressbook-error) 02https://github.com/bitcoin/bitcoin/pull/12830
116 2018-03-29 15:36:18	0|bitcoin-git|[13bitcoin] 15laanwj pushed 6 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/6d53663a4339...f0f9732d05d7
117 2018-03-29 15:36:19	0|bitcoin-git|13bitcoin/06master 143898c4f 15John Newbery: [tests] Tidy up feature_block.py...
118 2018-03-29 15:36:19	0|bitcoin-git|13bitcoin/06master 145cd01d2 15John Newbery: [tests] Fix flake8 warnings in feature_block.py
119 2018-03-29 15:36:20	0|bitcoin-git|13bitcoin/06master 14fc02c12 15John Newbery: [tests] Add logging to feature_block.py
120 2018-03-29 15:36:42	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #11773:  [tests] Change feature_block.py to use BitcoinTestFramework (06master...06refactor_p2pfullblocktest) 02https://github.com/bitcoin/bitcoin/pull/11773
121 2018-03-29 15:47:48	0|bitcoin-git|[13bitcoin] 15MarcoFalke opened pull request #12831: [WIP] Run unit tests in parallel (06master...06Mf1803-qaUnitParallel) 02https://github.com/bitcoin/bitcoin/pull/12831
122 2018-03-29 18:02:12	0|wumpus|wtf is up with travis: https://travis-ci.org/bitcoin/bitcoin/jobs/359847093  - looks like it creates a shallow clone, then tries to check out an older commit
123 2018-03-29 18:02:31	0|wumpus|I think this happens before our own script kicks in
124 2018-03-29 18:07:13	0|arubi|wumpus, the config tab shows '"depth": 1'
125 2018-03-29 18:07:51	0|arubi|so for some reason .travis.yml is set to that..?  weird
126 2018-03-29 18:09:46	0|wumpus|but that's nothing new
127 2018-03-29 18:09:50	0|ken2812221|Maybe this job must be auto-cancelled
128 2018-03-29 18:10:48	0|wumpus|depth was changed to 1 in fa79016ab0d23aa3d2c0322ab6be90b37dcd01c1, that's two week ago, not sure why it'd start giving problems now
129 2018-03-29 18:11:10	0|wumpus|fa44af5cd2152a21da9ef3e48c073a668bf2df27 added depth: false
130 2018-03-29 18:11:20	0|arubi|hm
131 2018-03-29 18:11:23	0|wumpus|(feb 10)
132 2018-03-29 18:11:30	0|wumpus|before that, we had no depth defined in the yml
133 2018-03-29 18:17:41	0|wumpus|(which effectively means depth=1 IIRC)
134 2018-03-29 18:19:52	0|arubi|it's 50 I think
135 2018-03-29 18:24:26	0|wumpus|so maybe it'd be better to remove the depth specification and leave it up to travis again
136 2018-03-29 18:25:54	0|wumpus|on the other hand, this way it spends less time building old master commits :-)
137 2018-03-29 19:00:41	0|sipa|meeting time?
138 2018-03-29 19:00:45	0|jnewbery|hello
139 2018-03-29 19:01:03	0|eklitzke|hi
140 2018-03-29 19:01:12	0|provoostenator|hi
141 2018-03-29 19:01:25	0|bitcoin-git|[13bitcoin] 15Sjors opened pull request #12833: WIP [qt] move QSettings to bitcoin.conf where possible (06master...062018/03/bitcoin-conf-rw) 02https://github.com/bitcoin/bitcoin/pull/12833
142 2018-03-29 19:01:48	0|achow101|meting?
143 2018-03-29 19:02:04	0|sipa|meeting, me think
144 2018-03-29 19:02:12	0|jamesob_|yo
145 2018-03-29 19:03:27	0|sipa|wumpus: ?
146 2018-03-29 19:03:34	0|jimpo|hi
147 2018-03-29 19:03:50	0|lightningbot|Meeting started Thu Mar 29 19:03:52 2018 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
148 2018-03-29 19:03:50	0|lightningbot|Useful Commands: #action #agreed #help #info #idea #link #topic.
149 2018-03-29 19:03:50	0|wumpus|#startmeeting
150 2018-03-29 19:03:54	0|BlueMatt|my high-priority: #11775 (yay, I have one again)
151 2018-03-29 19:03:55	0|gribble|https://github.com/bitcoin/bitcoin/issues/11775 | Move fee estimator into validationinterface/cscheduler thread by TheBlueMatt · Pull Request #11775 · bitcoin/bitcoin · GitHub
152 2018-03-29 19:04:02	0|wumpus|(DST sucks)
153 2018-03-29 19:04:21	0|wumpus|#bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr btcdrak sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier jl2012 achow101 meshcollider jnewbery maaku fanquake promag provoostenator
154 2018-03-29 19:04:35	0|kanzure|hi.
155 2018-03-29 19:04:37	0|cfields|hi
156 2018-03-29 19:05:19	0|wumpus|#topic high priority for review
157 2018-03-29 19:05:40	0|jnewbery|BlueMatt: needs rebase again. Sorry!
158 2018-03-29 19:05:40	0|wumpus|BlueMatt: added
159 2018-03-29 19:05:57	0|instagibbs|hi
160 2018-03-29 19:06:12	0|BlueMatt|jnewbery: well its a trivial rebase that shouldnt materially effect review
161 2018-03-29 19:06:19	0|jamesob_|I'd like to nominate ryanofsky's #10244. The burden of rebasing/conflict resolution is high and I think it's in pretty good shape (though needs rebase atm).
162 2018-03-29 19:06:23	0|gribble|https://github.com/bitcoin/bitcoin/issues/10244 | Refactor: separate gui from wallet and node by ryanofsky · Pull Request #10244 · bitcoin/bitcoin · GitHub
163 2018-03-29 19:06:34	0|provoostenator|agreed
164 2018-03-29 19:06:51	0|BlueMatt|can we make that a topic? I'd like to discuss it in more depth
165 2018-03-29 19:07:09	0|BlueMatt|(10244, that is)
166 2018-03-29 19:07:22	0|jnewbery|+1. Seems to be getting some review traction. It'd be a shame for that to go to waste
167 2018-03-29 19:07:41	0|wumpus|#topic separate gui from wallet and node  (#10244)
168 2018-03-29 19:07:45	0|gribble|https://github.com/bitcoin/bitcoin/issues/10244 | Refactor: separate gui from wallet and node by ryanofsky · Pull Request #10244 · bitcoin/bitcoin · GitHub
169 2018-03-29 19:08:32	0|ryanofsky|did you have a question BlueMatt?
170 2018-03-29 19:08:35	0|BlueMatt|yea, sec
171 2018-03-29 19:08:59	0|wumpus|I've... already said everything I wanted to said about that, won't repeat myself
172 2018-03-29 19:09:16	0|BlueMatt|so I guess I'm more of a fan of this than the wallet/main split, but I feel like we need to think a bit harder about the api between the gui/wallet+main before we go split it
173 2018-03-29 19:09:28	0|BlueMatt|I mean some of these things maybe shouldnt be blocking calls
174 2018-03-29 19:09:37	0|wumpus|TBH we discussed this at the new york meeting
175 2018-03-29 19:09:50	0|wumpus|and the agreement was that this could be improved after it goes in
176 2018-03-29 19:09:55	0|BlueMatt|ok, well I will shut up, then, if its been beaten to death
177 2018-03-29 19:09:56	0|BlueMatt|ok, nvm
178 2018-03-29 19:10:09	0|wumpus|I'm ok with that. I'd have preferred to make the GUI asynchronous first
179 2018-03-29 19:10:18	0|wumpus|but Iom' not going to beat that topic to death
180 2018-03-29 19:10:18	0|wumpus|right
181 2018-03-29 19:10:22	0|ryanofsky|api is definitely meant to be improved, especially the init stuff which is pretty ugly
182 2018-03-29 19:10:29	0|kanzure|are there any big blockers to asynchronous gui things?
183 2018-03-29 19:10:36	0|BlueMatt|yea, I mean that was what I was gonna say, but if there was agreement its not worth re-opening the book on that to discuss
184 2018-03-29 19:10:39	0|wumpus|no, it's just a different set of work
185 2018-03-29 19:11:18	0|wumpus|it's somewhat orthogonal to this - my gut just hates blocking RPC calls in GUI threads, it's more of an instinctive revulsion than anything I can explain, so I'll just go along
186 2018-03-29 19:11:37	0|jamesob_|this PR introduces no RPC calls
187 2018-03-29 19:11:44	0|provoostenator|I think part of the understanding was that this interface should be considered very much not final.
188 2018-03-29 19:11:51	0|BlueMatt|jamesob_: it introduces a whole new rpc interface...
189 2018-03-29 19:11:54	0|wumpus|it does, it introduces an RPC layer between the wallet and the core
190 2018-03-29 19:12:01	0|provoostenator|Just having _an_ interface was step one.
191 2018-03-29 19:12:04	0|wumpus|please don't deny that
192 2018-03-29 19:12:10	0|BlueMatt|anyway, next topic?
193 2018-03-29 19:12:20	0|wumpus|yes, any other topic suggestions?
194 2018-03-29 19:12:31	0|sipa|wumpus: i think jamesob_ means RPC as in the existing JSON RPC system
195 2018-03-29 19:12:38	0|sipa|not RPC as a generic term
196 2018-03-29 19:12:48	0|jamesob_|correct
197 2018-03-29 19:12:53	0|wumpus|ok, yes, RPC is a general term for cross-process calls
198 2018-03-29 19:13:12	0|ryanofsky|jamesob_, an earlier version of this pr did mention ipc, but i took that stuff out
199 2018-03-29 19:13:13	0|jnewbery|This first step isn't cross-process
200 2018-03-29 19:13:37	0|BlueMatt|lol, ok, so any topics *aside* from debating rpc/ipc/whatever terminology?
201 2018-03-29 19:13:42	0|wumpus|yes...
202 2018-03-29 19:14:10	0|jnewbery|topic suggestion (quick one): release notes conflicts
203 2018-03-29 19:14:33	0|wumpus|#topic release notes conflicts
204 2018-03-29 19:14:38	0|jnewbery|I don't think it's a major issue, but it is irritating to have reviews invalidated due to release notes conflicts
205 2018-03-29 19:14:55	0|jnewbery|options: 1) do nothing because it's not a huge issue
206 2018-03-29 19:14:56	0|wumpus|could do them in a separate commit, at the end
207 2018-03-29 19:15:07	0|sipa|do we know if githubdeals correctly with the gitattributes merge=union stuff?
208 2018-03-29 19:15:12	0|wumpus|oh wait that doesn't help with rebases...
209 2018-03-29 19:15:16	0|achow101|Maybe we should have the release notes dev wiki thing continuously up and people just add stuff to it as needed
210 2018-03-29 19:15:31	0|jnewbery|2) don't use release_notes.md and just use a wiki for the whole release cycle
211 2018-03-29 19:15:44	0|jnewbery|3) have separate release_notes files for each PR and merge them at the end
212 2018-03-29 19:15:45	0|BlueMatt|I mean as long as its a separate commit no reason to invalidate reviews
213 2018-03-29 19:15:47	0|jnewbery|4) ?
214 2018-03-29 19:16:14	0|sipa|4) is the merge=union thing?
215 2018-03-29 19:16:27	0|jnewbery|merge=union doesn't help with github I think
216 2018-03-29 19:16:30	0|achow101|I prefer 2
217 2018-03-29 19:16:39	0|sipa|i don't like 2
218 2018-03-29 19:16:45	0|sipa|too much process overhead
219 2018-03-29 19:16:53	0|wumpus|achow101: I think the only argument against 2 is that it decouples the merge from the release mode update
220 2018-03-29 19:16:59	0|wumpus|notes*
221 2018-03-29 19:17:03	0|ryanofsky|an option 4) would be to insert 50-100 blank lines in the file, and add release new notes in the blank space. this would avoid most conflicts
222 2018-03-29 19:17:07	0|jnewbery|sipa: https://github.com/isaacs/github/issues/487
223 2018-03-29 19:17:11	0|cfields|outside the box: notes can be added as individual files and aggregated at the end
224 2018-03-29 19:17:21	0|wumpus|so the author of the PR has to update the wiki after their thing was merged
225 2018-03-29 19:17:22	0|sipa|jnewbery: right, but we also.don't really use github for merges
226 2018-03-29 19:17:27	0|wumpus|cfields: unless they somehow interact :)
227 2018-03-29 19:17:35	0|sipa|i mean more... how does it affect our github merge scriot etc
228 2018-03-29 19:17:39	0|jnewbery|cfields: I think that's 3
229 2018-03-29 19:17:43	0|sipa|which compares with the github merge
230 2018-03-29 19:17:53	0|instagibbs|sipa, would be annoying to see conflict on GUI and just hope it's a merge we can avoid directly handling
231 2018-03-29 19:18:03	0|sipa|instagibbs: fair
232 2018-03-29 19:18:05	0|cfields|jnewbery: ah yes, missed 3.
233 2018-03-29 19:18:09	0|sipa|i think my preference is 3
234 2018-03-29 19:18:12	0|wumpus|cfields: I mean, sometimes an update to the release notes updates/extends earlier text - though
235 2018-03-29 19:18:13	0|sdaftuar|i like 3 too
236 2018-03-29 19:18:14	0|instagibbs|maybe i need to learn that tool better, might give a better view of it
237 2018-03-29 19:18:14	0|jamesob_|I like 3
238 2018-03-29 19:18:14	0|ryanofsky|link describing option 4: https://about.gitlab.com/2015/02/10/gitlab-reduced-merge-conflicts-by-90-percent-with-changelog-placeholders/
239 2018-03-29 19:18:27	0|BlueMatt|option n) leave release notes as a comment on pr and tag the release-notes-needed issue
240 2018-03-29 19:18:29	0|wumpus|cfields: storing it *per section* would still help!
241 2018-03-29 19:18:30	0|BlueMatt|easy to merge at the end
242 2018-03-29 19:18:35	0|BlueMatt|and they exist in the pr itself
243 2018-03-29 19:18:41	0|ryanofsky|i also like 3 best
244 2018-03-29 19:19:02	0|wumpus|'leave it to the maintainer at the end' is not an option :p
245 2018-03-29 19:19:21	0|sipa|it may be a release notes file per "feature" too, i think, if multiple PRs sequentially update the se thing
246 2018-03-29 19:19:38	0|jnewbery|sipa: sounds reasonable, if they're serial
247 2018-03-29 19:19:44	0|sipa|right
248 2018-03-29 19:19:52	0|jimpo|Yeah, I like the idea of basically having a file for each section in the current release notes
249 2018-03-29 19:19:57	0|wumpus|I mean what you want to avoid is that *unrelated* PRs collide in the release notes
250 2018-03-29 19:20:15	0|sipa|wumpus: yyp
251 2018-03-29 19:20:20	0|wumpus|if PRs that already affect the same thing collide, that's not too bad, because the code likely does too
252 2018-03-29 19:22:34	0|wumpus|so yes, 3 sounds like a good idea to me, though it might be overdesign for something that doesn't cause too much trouble in practice, I wonder if anyone will actually do it
253 2018-03-29 19:23:03	0|sipa|we can see how it plays out
254 2018-03-29 19:23:08	0|jnewbery|if it's in the developer notes, then I think people will do it
255 2018-03-29 19:23:19	0|jnewbery|I'll do it for my PRs to avoid conflicts
256 2018-03-29 19:24:01	0|jamesob_|could add a lint step to the build that fails if the PR touches the main release notes files as well as src/ files
257 2018-03-29 19:24:01	0|wumpus|definitely needs to be in the developer notes, like "what directory to use for partial release notes'
258 2018-03-29 19:24:08	0|wumpus|oh no no more lints
259 2018-03-29 19:24:29	0|jnewbery|I think that's probably enough discussion. As long as the maintainers don't object to partial release notes then individual contributors can start using them
260 2018-03-29 19:24:36	0|wumpus|I get quite angry if yet another redundant python import breaks travis
261 2018-03-29 19:24:50	0|jamesob_|suggestion retracted :)
262 2018-03-29 19:24:56	0|instagibbs|I don't even think there's contribution notes yet
263 2018-03-29 19:25:01	0|instagibbs|for release notes
264 2018-03-29 19:25:04	0|wumpus|jamesob_: sorry :)
265 2018-03-29 19:25:07	0|instagibbs|i had to ask promag
266 2018-03-29 19:25:11	0|jnewbery|wumpus: is that not caught in the PR's travis run?
267 2018-03-29 19:25:25	0|wumpus|jnewbery: I think it is
268 2018-03-29 19:26:53	0|sipa|topic suggestion: avoid undefined behaviour when it shouldn't matter? (#12789)
269 2018-03-29 19:26:55	0|gribble|https://github.com/bitcoin/bitcoin/issues/12789 | Dont return a CExtPubKey filled with random data when DecodeExt{Pub,}Key is given input not passing DecodeBase58Check(...) by practicalswift · Pull Request #12789 · bitcoin/bitcoin · GitHub
270 2018-03-29 19:27:09	0|wumpus|#topic avoid undefined behaviour when it shouldn't matter?
271 2018-03-29 19:27:15	0|jtimon|ryanofsky: why not just create a separated pr editing the release notes after the actual pr doing things has been merged?
272 2018-03-29 19:27:29	0|BlueMatt|"shouldnt"
273 2018-03-29 19:27:34	0|sipa|i bring it up here because it may be something we should or shouldn't have as a guideline
274 2018-03-29 19:28:07	0|sipa|for example,  should you initialize a variable that isn't read anywhere, because soke compiler warning fails to understand it isn't being read?
275 2018-03-29 19:28:20	0|sipa|argument in favor: more deterministic failures
276 2018-03-29 19:28:22	0|BlueMatt|oh, well that isnt "shouldnt"
277 2018-03-29 19:28:32	0|BlueMatt|that is "doesnt, but compiler warns"
278 2018-03-29 19:28:36	0|sipa|argument against: reduces the ability for tools to detect things stativally
279 2018-03-29 19:29:01	0|provoostenator|Other argument in favor: means a linter can catch all uninitialized variables.
280 2018-03-29 19:29:01	0|sipa|well i say shouldn't, because reviewers may be wrong and the compiler may be right
281 2018-03-29 19:29:06	0|wumpus|jtimon: that's a possibility too, though like the wiki option it decouples the code change from the release notes change itselff
282 2018-03-29 19:29:22	0|wumpus|jtimon: also: EVEN MORE PRs :(
283 2018-03-29 19:29:34	0|jtimon|wumpus: yep, although I guess the bigger drawback is more prs
284 2018-03-29 19:29:36	0|jtimon|right
285 2018-03-29 19:29:40	0|BlueMatt|I mean if its at all tricky to show that it *wont* be read, then should def follow the compiler, but the nonstop stream of "this compiler is shit and warned on something that it shouldnt be" prs is....not ideal
286 2018-03-29 19:29:59	0|wumpus|yeah...
287 2018-03-29 19:30:22	0|BlueMatt|honestly of all those pros/cons, the pr volume is probably the most important imnsho
288 2018-03-29 19:30:23	0|wumpus|so many *fix some and some false positive for my crappy static analysis tool/compiler with warnings jacked up*
289 2018-03-29 19:30:34	0|sipa|i generally dislike the "compiler/analyzer/linter/tool doesn't understand X, let's initialize everything to shut it up"
290 2018-03-29 19:30:40	0|wumpus|me too
291 2018-03-29 19:30:45	0|wumpus|just fix your tools FFS
292 2018-03-29 19:30:57	0|bitcoin-git|[13bitcoin] 15MarcoFalke closed pull request #12823:  doc: Switch release-notes.md to union merge  (06master...06Mf1803-docGitattributes) 02https://github.com/bitcoin/bitcoin/pull/12823
293 2018-03-29 19:31:15	0|wumpus|if it's correct, human-understandable C++ code and we know there's no problems with it, it should not be changes because compiler blabla
294 2018-03-29 19:31:28	0|wumpus|too risky, too
295 2018-03-29 19:31:29	0|sipa|or improve the code so it is easier for tools (and humans) to see it is correct
296 2018-03-29 19:31:39	0|wumpus|if it's not broken don't change it
297 2018-03-29 19:31:45	0|sipa|true
298 2018-03-29 19:31:54	0|sipa|ok, just wanted to hear opinions about this
299 2018-03-29 19:32:09	0|wumpus|unless it's a refactor to prepare for osmething else, of course, but that wasn't the premise :)
300 2018-03-29 19:32:49	0|wumpus|so I think we agree
301 2018-03-29 19:32:53	0|sipa|yes
302 2018-03-29 19:32:56	0|wumpus|any other topics?
303 2018-03-29 19:33:47	0|jtimon|BlueMatt: I don't know, will more volume of prs specific to release notes be that much more cumbersome?
304 2018-03-29 19:34:04	0|wumpus|jtimon: yes. In that case I prefer the wiki
305 2018-03-29 19:34:08	0|BlueMatt|less so than code-change pr volume
306 2018-03-29 19:34:12	0|BlueMatt|but whatever
307 2018-03-29 19:34:22	0|jnewbery|wumpus: I agree
308 2018-03-29 19:34:30	0|wumpus|that's why we have the wiki-phase at all before releases, to prevent a jungle of update-release-notes PRs
309 2018-03-29 19:34:31	0|jtimon|yeah, I mean, I don't have a strong opinion either way
310 2018-03-29 19:34:49	0|wumpus|(which will also conflict with each other! though easier to rebase..)
311 2018-03-29 19:35:02	0|ryanofsky|jtimon, imo including release notes along with changes makes changes easier to understand, and also probably more well thought out
312 2018-03-29 19:35:05	0|wumpus|yes, it's better than code-change PR volume that's for sure
313 2018-03-29 19:35:15	0|wumpus|ryanofsky: hey that's a good point
314 2018-03-29 19:36:17	0|jtimon|sipa: sometimes warning are useful, sometimes they are not and it's alright to leave them there. but not sure what the discussion is. nobody is proposing we use -Werror, right?
315 2018-03-29 19:36:30	0|wumpus|I remember seeing the 'release notes per item' before in some project, not sure which
316 2018-03-29 19:36:57	0|jtimon|ryanofsky: I agree, but then you have to deal with rebases, I don't see a way around it
317 2018-03-29 19:37:22	0|wumpus|jtimon: warning being good or evil wasn't what the topic was about
318 2018-03-29 19:37:42	0|sipa|jtimon: my view is (for example) that if you systemativally initialize every variable (even those for which you know won't be used), you will lose the ability for the compiler to give you warnings about accidentially uninitialized things
319 2018-03-29 19:38:03	0|jtimon|wumpus: that's what I'm saying, that I'm not sure what the topic is
320 2018-03-29 19:38:13	0|sipa|this is more general than just compiler warnings, and variable initialization though
321 2018-03-29 19:38:26	0|wumpus|at ASML we had that as part of the C coding standard - every, single, variable had to be initialized
322 2018-03-29 19:38:39	0|wumpus|no I don't think we need that here :)
323 2018-03-29 19:39:42	0|cfields|sipa: yes, i really like newer gcc/clang's ability to warn about being unitialized for one or more paths
324 2018-03-29 19:40:25	0|wumpus|I do think all class variables should be initialized in the constructor, in general
325 2018-03-29 19:41:47	0|cfields|wumpus: agreed, but I'd like to start using more c++11 member-initialization for trivial types as it's so much less verbose
326 2018-03-29 19:41:49	0|wumpus|cfields: they had that in the static analyzer for quite a while, now it moved to a compiler warning, a good thing
327 2018-03-29 19:42:14	0|cfields|right
328 2018-03-29 19:42:52	0|wumpus|cfields: yes, that's a nicer syntax
329 2018-03-29 19:43:40	0|wumpus|ok, any other topics?
330 2018-03-29 19:44:21	0|sipa|seems not
331 2018-03-29 19:44:22	0|wumpus|#endmeeting
332 2018-03-29 19:44:23	0|lightningbot|Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-03-29-19.03.log.html
333 2018-03-29 19:44:23	0|lightningbot|Meeting ended Thu Mar 29 19:44:25 2018 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
334 2018-03-29 19:44:23	0|lightningbot|Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-03-29-19.03.html
335 2018-03-29 19:44:23	0|lightningbot|Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-03-29-19.03.txt
336 2018-03-29 19:57:37	0|cfields|out of curiosity, does the c spec allow for compilers to ignore initializers if a value is always set before it's used?
337 2018-03-29 19:58:03	0|wumpus|only if there are no side effects
338 2018-03-29 19:58:11	0|cfields|i'm wondering if compilers are allowed to do the opposite optimization: you always initialize, but it removes them when possible.
339 2018-03-29 19:58:52	0|BlueMatt|the compiler could run any obvious part of your program and just change the program to have the same effective in/out results, so....yes?
340 2018-03-29 19:59:05	0|wumpus|^^
341 2018-03-29 19:59:24	0|BlueMatt|see-also: crypto-memset
342 2018-03-29 19:59:45	0|wumpus|the C spec wouldn't say anything on that, because it's not visible to the code in any path
343 2018-03-29 19:59:48	0|luke-jr|ETA until compilers try to do IBD for you?
344 2018-03-29 19:59:51	0|luke-jr|☺
345 2018-03-29 20:00:11	0|BlueMatt|luke-jr: they'll fail on the first net access :(
346 2018-03-29 20:00:29	0|luke-jr|BlueMatt: yes, I'm joking :P
347 2018-03-29 20:01:03	0|wumpus|luke-jr: only if you manage to do blockvalidation in c++78 metaprogramming
348 2018-03-29 20:01:51	0|wumpus|(or maybe it's already possible with current standards, at least compile time hashing is already possible :-)
349 2018-03-29 20:02:36	0|cfields|heh
350 2018-03-29 20:03:26	0|BlueMatt|rust has a fucking full ast interpreter in the front-end compiler now, to in the future run anything with no io as a constexpr.......
351 2018-03-29 20:05:28	0|wumpus|that's an interesting choice
352 2018-03-29 20:05:57	0|BlueMatt|or, well, thats a possible future use for it, but they have an interpreter in the front-end
353 2018-03-29 20:06:05	0|wumpus|the drawback with c++ compile-time metaprogramming has always been that it's really slow, as it's circuitous because it (ab)uses features meant for something else. So, why not just include an ast interpreter.
354 2018-03-29 20:06:34	0|wumpus|(compile-time slow, I mean)
355 2018-03-29 20:09:19	0|wumpus|so apparently the Tor project is working on porting parts to rust
356 2018-03-29 20:12:01	0|wumpus|not sure what parts, but it has always been an exclusively C codebase before
357 2018-03-29 20:12:06	0|booyah|also, what for
358 2018-03-29 20:12:29	0|booyah|after decades it's probably rather safe from low-level errors, isn't it
359 2018-03-29 20:12:36	0|wumpus|hehe :)
360 2018-03-29 20:12:46	0|wumpus|that's anyone's guess, really
361 2018-03-29 20:12:57	0|BlueMatt|seems premature tbh to me, mostly cause if you want to, eg, compile it on debian stable you have to use a super-old version of rust and end up getting a billion warnings from recent versions telling you to use new syntax :(
362 2018-03-29 20:13:43	0|sipa|cfields: not only can they, i believe that SSA transforms will pretty much automatically do that
363 2018-03-29 20:13:43	0|wumpus|debian stable is the problem there
364 2018-03-29 20:14:20	0|BlueMatt|wumpus: true, but, what, you're gonna not support debian stable? so...you lose, what, 1/5 your users?
365 2018-03-29 20:14:47	0|cfields|sipa: so there's no (performance) downside of initialize-by-default as a rule?
366 2018-03-29 20:14:57	0|wumpus|BlueMatt: but the only way to pressure them into upgrading their rust version is likely for major projects to start using it, it's always a chicken/egg problem
367 2018-03-29 20:15:25	0|BlueMatt|why would they make an exception to their ship-only-insanely-out-of-date-software rule for a *compiler*?
368 2018-03-29 20:15:30	0|wumpus|if e.g. bitcoin would start using it, no one would care, but something like tor has quite a lot of influence I think
369 2018-03-29 20:15:35	0|BlueMatt|that seems like the one thing they'd be least likely to make an exception for
370 2018-03-29 20:15:47	0|wumpus|oh we'll see
371 2018-03-29 20:17:18	0|wumpus|I'm glad someone is taking the initative there that's not me
372 2018-03-29 20:18:47	0|BlueMatt|lol, well at least we succeeded at getting them to stop shiping bitcoin
373 2018-03-29 20:18:49	0|wumpus|firefox is likely the main pusher for (decent) rust support in distros
374 2018-03-29 20:18:51	0|BlueMatt|maybe if the tor folks also succeed
375 2018-03-29 20:19:07	0|BlueMatt|debian already stopped shipping firefox a long time ago :p
376 2018-03-29 20:19:13	0|BlueMatt|(because of this exact issue, too....)
377 2018-03-29 20:19:34	0|wumpus|huh? really?
378 2018-03-29 20:19:52	0|BlueMatt|iceweasel, yo
379 2018-03-29 20:20:13	0|wumpus|iceweasel is simply a rebranded firefox
380 2018-03-29 20:20:26	0|BlueMatt|yes, but they had to because they wanted to ship super old versions and that wasnt allowed
381 2018-03-29 20:20:26	0|wumpus|because of some license issue...
382 2018-03-29 20:20:41	0|BlueMatt|afair
383 2018-03-29 20:21:13	0|BlueMatt|(among other issues)
384 2018-03-29 20:21:24	0|wumpus|shipping old versions of browsers is really dangerous
385 2018-03-29 20:21:49	0|BlueMatt|yes, just pointing out that debian was so headstrong in their desire to do stupid insecure shit that they rebranded firefox for it....
386 2018-03-29 20:22:51	0|wumpus|yes I didn't know that was the reason
387 2018-03-29 20:23:19	0|BlueMatt|i mean i may be misrecalling, but I believe that was one of the things that violated the acceptable-use license that firefox required to use their branding
388 2018-03-29 20:23:24	0|BlueMatt|(among a few other issues)
389 2018-03-29 20:27:10	0|cfields|I thought debian was back to firefox now?
390 2018-03-29 20:27:21	0|cfields|iirc the tm issue was resolved somehow
391 2018-03-29 20:28:25	0|BlueMatt|seems like it, yes, still, my point stands
392 2018-03-29 20:35:00	0|bitcoin-git|[13bitcoin] 15laanwj pushed 3 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/f0f9732d05d7...252c1b0faef4
393 2018-03-29 20:35:01	0|bitcoin-git|13bitcoin/06master 145de2b18 15John Newbery: [contrib] fixup security-check.py Python3 support
394 2018-03-29 20:35:01	0|bitcoin-git|13bitcoin/06master 14f50975b 15John Newbery: [contrib] fixup symbol-check.py Python3 support
395 2018-03-29 20:35:02	0|bitcoin-git|13bitcoin/06master 14252c1b0 15Wladimir J. van der Laan: Merge #12829: Python3 fixup...
396 2018-03-29 20:35:45	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #12829: Python3 fixup (06master...06python3_fixup) 02https://github.com/bitcoin/bitcoin/pull/12829
397 2018-03-29 20:47:04	0|sipa|cfields: there is when the compiler can't figure out the value is unused
398 2018-03-29 20:48:18	0|sipa|but in the naive situatiin where there are no branches/loops that conplicate flow analysis, sure
399 2018-03-29 20:58:43	0|bitcoin-git|13bitcoin/06master 146feb46c 15Evan Klitzke: Add --with-sanitizers option to configure...
400 2018-03-29 20:58:43	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/252c1b0faef4...de6bdfd78f22
401 2018-03-29 20:58:44	0|bitcoin-git|13bitcoin/06master 14de6bdfd 15Wladimir J. van der Laan: Merge #12692: Add configure options for various -fsanitize flags...
402 2018-03-29 20:59:22	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #12692: Add configure options for various -fsanitize flags (06master...06sanitize) 02https://github.com/bitcoin/bitcoin/pull/12692
403 2018-03-29 21:01:13	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #12774: Issue #10542 Signmessage doesn't work with segwit addresses (06master...06master) 02https://github.com/bitcoin/bitcoin/pull/12774
404 2018-03-29 21:08:30	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #12124: [wallet] Remove segwit status check (06master...06master) 02https://github.com/bitcoin/bitcoin/pull/12124
405 2018-03-29 21:09:24	0|sipa|m-m-m-multiclose PR
406 2018-03-29 21:09:34	0|wumpus|hehe
407 2018-03-29 21:28:30	0|wumpus|hm we should probably have discussed #12764 at the meeting
408 2018-03-29 21:28:32	0|gribble|https://github.com/bitcoin/bitcoin/issues/12764 | Remove field in getblocktemplate help that has never been used. by conscott · Pull Request #12764 · bitcoin/bitcoin · GitHub
409 2018-03-29 21:29:15	0|wumpus|not sure if having the help conform to BIP22 or to our current implementation of it is better
410 2018-03-29 21:31:01	0|luke-jr|wumpus: I'd be inclined to just point to BIP 22 and leave the docs at that.
411 2018-03-29 21:36:37	0|wumpus|that'd be another option
412 2018-03-29 22:26:59	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/de6bdfd78f22...3b62a9138657
413 2018-03-29 22:27:00	0|bitcoin-git|13bitcoin/06master 143b62a91 15Wladimir J. van der Laan: Merge #12172: Bugfix: RPC: savemempool: Don't save until LoadMempool() is finished...
414 2018-03-29 22:27:00	0|bitcoin-git|13bitcoin/06master 14cb1e319 15Jorge Timón: Bugfix: RPC: savemempool: Don't save until LoadMempool() is finished
415 2018-03-29 22:27:34	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #12172: Bugfix: RPC: savemempool: Don't save until LoadMempool() is finished (06master...06b16-bugfix-savemempool) 02https://github.com/bitcoin/bitcoin/pull/12172