< jtimon>
although I hope to undo the undoing of that work at some point in the future
< sipa>
jtimon: use non-overlapping begin/end dates :)
< sipa>
jtimon: there should never be a need for conflicts on bits
< jtimon>
but what if all the bits are being used? you know the timeout date, but not the activation date
< sipa>
if you don't schedule more than 9 deployments per year, and have 3 year timeouts, you never run out
< jtimon>
realistically, no, more than 29 concurrent deployments are very unlikely
< jtimon>
ok, if I sacrifice that feature (which is only really necessary without the start date), I think I can maintain the struct-with-the-current-state-of-all-deployments instead of your individual per-deployment cache while separating the warning check from consensus::getflags() like you've done
< * jtimon>
reminds a please please please nit
< aj>
gmaxwell: lightningbot is back on #bitcoin-dev; it was blocked from joining because it wasn't registered with nickserv fwiw
< jtimon>
sipa: thoughts on moving to BIP112 instead of BIP113 as an example?
< sipa>
sure
< sipa>
or both
< GitHub96>
[bitcoin] JeremyRand opened pull request #7603: Build System: Use PACKAGE_TARNAME in NSIS script (master...nsis-tarname) https://github.com/bitcoin/bitcoin/pull/7603
< kanzure>
a friend has asked me for "ideal introductory (closed) pull requests to read". i sadly don't have a good list. any thoughts?
< jtimon>
sipa well, I'm ok with doing both, but if I deploy BIP113 and you don't, my implementation doesn't have any chance to compete with yours in minimal-ness (just like if I don't decouple it from the commits it has from #7563), anyway, the part that really worries me from using BIP113 as example, is the fact that #7565 is making both (itself and #7566 ) fail on travis, and trying the couple of things that I thought could be causing
< jtimon>
it didn't help
< jtimon>
I shouldn't need to fix #7565 for #7566 to pass travis, it was supposed to be a bonus-free-super-clean refactoring, if it doesn't do it at this point, should be out of #7566
< jtimon>
even if it's unrelated, review on #7565 very welcomed as well, specially from @wumpus
< jtimon>
because I unburied it from libconsensus-p3 when I saw his #7552, I'm mainly interested in comments related to the relation bettwen #7552 and #7565 (I just thought it was "almost free" for #7566)
< michagogo>
Re: removing OpenSSL
< michagogo>
IIRC Qt depends on it at build time…
< Luke-Jr>
michagogo: good point, we can never truly remove it completely I guess
< GitHub38>
[bitcoin] jtimon closed pull request #7564: libconsensus-p2a: Preparations to decouple libconsensus from coins.o (master...libconsensus-p2a-coins-cpp-interface-0.12.99) https://github.com/bitcoin/bitcoin/pull/7564
< petertodd>
jtimon: wait, why do you want to decouple bip113? it's a very simple and easy bip, and we really don't want it to become an issue in of itself because it fixes a potential exploit
< jtimon>
petertodd:
< jtimon>
1) I thought travis was going to love #7565 at the first try but after several of them it doesn't seem like one of those times that travis just doesn't like one particular commit id (ie not solved by add space, squash, remove space, squash), I even tried removing the only change in functionality that I would be happy to renounce. Right now I'm reading #7574 , which I supect contains some answers to my future questions about #
< jtimon>
7565.
< jtimon>
TL;DR: #7565 was supposed to only move functionality reducing some redundancy (and adding some at the same time, but I removed that part), too many unexpected fails for a supposedly non-functionality (I mean, I'm not closing the PR, if it get fixed and merged before #7566 or #7575 all the better)
< jtimon>
2) I should't had enumerated if I didn't had two points
< jtimon>
petertodd: in any case, github/bitcoin/jtimon/bip9-0.12.99-bip113-just-in-case should be easy to rebase on top of both #7575 and #7566
< jtimon>
stupid me, just trying to replace bip112 with bip113 told me the answer, rebase!
< * jtimon>
is sorry for thinking out loud
< jtimon>
they cannot all be flag 1U << 10 !
< Luke-Jr>
why not?
< GitHub172>
[bitcoin] jonasschnelli opened pull request #7605: Remove openssl info from init/log and from Qt debug window (master...2016/02/rm_openssl_log) https://github.com/bitcoin/bitcoin/pull/7605
< GitHub138>
[bitcoin] MarcoFalke opened pull request #7606: [depends] builders: No need to set -L and --location for curl (master...Mf1602-curl) https://github.com/bitcoin/bitcoin/pull/7606
< GitHub131>
[bitcoin] MarcoFalke opened pull request #7608: [wallet] Move hardcoded file name out of log messages (master...Mf1602-walletFileName) https://github.com/bitcoin/bitcoin/pull/7608
< michagogo>
Luke-Jr: actually, looks like that's not true
< michagogo>
By default, an SSL-enabled Qt library dynamically loads any installed OpenSSL library at run-time. However, it is possible to link against the library at compile-time by configuring Qt with the -openssl-linked option.
< Luke-Jr>
oh
< michagogo>
To disable SSL support in a Qt build, configure Qt with the -no-openssl option.
< GitHub148>
[bitcoin] AliceWonderMiscreations opened pull request #7609: All files related to my RPM spec file project in one commit (master...master) https://github.com/bitcoin/bitcoin/pull/7609