< fanquake>
#678 is more interesting as a quick check, making sure that submitters are only modifying a single dir. However that is still a trivial thing to check anyways.
< wumpus>
fanquake: I think it's difficult, I mwan from a user perspective it's useful to be alerted when signatures diverge, what "m less convinced about is that travis is always the right hammer for the job
< wumpus>
FWIW this is the same feeling that I have with hooking all kinds of things like whitespace linters into travis. If there was a better way to customize the message/icon that appears in the github issue it'd be better.
< fanquake>
I also agree that diverging/"incorrect" signatures should be merged regardless.
< bitcoin-git>
[bitcoin] promag opened pull request #12448: Interrupt block generation on shutdown request (master...2018-02-interrupt-generate-blocks) https://github.com/bitcoin/bitcoin/pull/12448
< promag>
wumpus: what kind of test?
< promag>
generate bigcount and in parallel quit?
< wumpus>
well in this case a test that does generateblock 10000 then sends an interrupt request and checks that bitcoin shuts down cleanly
< wumpus>
though I'd argue this is not an important one to test
< wumpus>
the early-outs in init, are
< promag>
right
< promag>
I was benchmarking stuff and did generate 100000
< wumpus>
(that is where we had two fixes for, in the rc cycle... because early-outs leave the process in an inconsistent, or at least unpexpected state that may cause trouble later)
< promag>
and then I had to kill -9 otherwise it didn't stop
< wumpus>
which is fine, no one does software development perfectly, seeing all potential conseequences to a change (if only!), but illustrates tests are needed
< promag>
and generateBlocks is non main net right?
< wumpus>
if you can use it for mainnet, interrupting *between* blocks isn't going to help you
< wumpus>
even generating one block at the current difficulty with the naive, single-threaded miner meant for regtest is going to take a million years
< provoostenator>
I added an #ifdef ENABLE_WALLET in guiutil.h, but the compiler seems to think this is undefined for this particular file even though I configured with the wallet enabled.
< kallewoof>
provoostenator: you may need to do the HAVE_CONFIG_H deal first? (e.g. compat.h style)
< provoostenator>
kallewoof: thanks, that did the trick. What does it do?
< kallewoof>
provoostenator: it pulls in defines from autoconf etc, I believe
< cfields>
yep
< cfields>
it's so that you can tell the difference between autoconf'd builds and non
< cfields>
for ex, you can (or could at one point) build bitcoind with MSVC, you just have to define all of the stuff that autoconf would've detected for you
< cfields>
gitian builders: v0.16.0rc4 detached sigs are pushed
< cfields>
wumpus: the darwin define for miniupnpc is done universally
< cfields>
I'll nag on the PR
< wumpus>
cfields: whoops so that define is for upnp itself, not a hint to darwin. I thought it was the latter so defining it universally wouldn't hurt.
< cfields>
right. it's unlikely to be an issue, but if it turned out to manifest somewhere, it'd be really nasty to track down
< jcorgan>
is there a how-to-do-gitian-builds-for-fun-and-profit-and-mental-health.md somewhere?
< bitcoin-git>
[bitcoin] DaveFromBinary opened pull request #12452: [Docs] Clarified systemd installation instructions in init.md for Ubuntu users. (master...doc-init-updates) https://github.com/bitcoin/bitcoin/pull/12452
< bitcoin-git>
[bitcoin] Empact opened pull request #12455: Fix bip68 sequence test to reflect updated rpc error message (master...fix-bip68-test) https://github.com/bitcoin/bitcoin/pull/12455
< ProfMac>
I did a gitian build back in 0.14.xx. The process was not well documented, and I could not reproduce whatever I did from my notes. Is the documentation process any better now?
< achow101>
I don't think the problem is documentation but rather that gitian doesn't always work
< MarcoFalke>
It is like Jenga. All the virtualizations or OSes that it depends on pull out sticks and you wait until it breaks
< bitcoin-git>
[bitcoin] Empact opened pull request #12458: Enforce that amount is provided for signrawtransaction prevtxs (master...rawtransaction-amount-required) https://github.com/bitcoin/bitcoin/pull/12458
< esotericnonsense>
is univalue compiled seperately without C++11 ? i'm struggling with my make-fu
< esotericnonsense>
it disagrees with my use of nullptr
< esotericnonsense>
yeah, that's it.
< bitcoin-git>
[bitcoin] Empact opened pull request #12459: Assert compressed / compact keys and sigs are strictly shorter than regular (master...assert-compressed-smaller) https://github.com/bitcoin/bitcoin/pull/12459
< bitcoin-git>
[bitcoin] Empact opened pull request #12460: Assert CPubKey::ValidLength to the pubkey's header-relevent size (master...key-size-check-header) https://github.com/bitcoin/bitcoin/pull/12460
< bitcoin-git>
[bitcoin] Empact opened pull request #12461: Refactor key / signature size consts to be relative to their relevant class (master...key-size-consts) https://github.com/bitcoin/bitcoin/pull/12461
< esotericnonsense>
cfields: if I hack in g++ -std=c++11 into the makefile for univalue that works (I'm currently trying to figure out how to do this properly and fixing up some other compilation errors)
< cfields>
yikes!
< esotericnonsense>
what's yikes? that we weren't using c++11 for univalue? the concept of using it? :)
< cfields>
yikes that we're possibly mixing ABIs in our binaries
< cfields>
I'm surprised we haven't seen issues from that yet
< esotericnonsense>
mmm. unfortunately my knowledge of this stuff has kind of faded after spending years in python-land. slowly getting there again.
< cfields>
heh, no worries
< cfields>
I'll PR a fix, unless you want to drill down into it
< esotericnonsense>
up to you. i'm making a small change to univalue that requires it, but my knowledge of make is very limited (i'
< esotericnonsense>
(i'd just be hacking in -std=c+11 into flags until it works on my box)
< esotericnonsense>
well it doesn't require it because I don't _need_ to use nullptr it's just consistent that way
< bitcoin-git>
[bitcoin] Empact opened pull request #12463: Drop the return argument from CValidationState::DoS and Invalid (master...drop-dos-return) https://github.com/bitcoin/bitcoin/pull/12463
< bitcoin-git>
[bitcoin] Empact closed pull request #12357: Rationalize the CValidationState interface by splitting ::DoS across ::Invalid and ::Corrupt (master...validation-state-corrupt) https://github.com/bitcoin/bitcoin/pull/12357
< cfields>
well, we haven't discussed it afaik, but it makes sense to keep univalue c++03 simply because it already is
< sipa>
cfields: using c++11 may be more efficient
< sipa>
because it gives stl automagival rvalue support
< sipa>
*automagical
< cfields>
sipa: sure. I think it makes sense to discuss bumping. It'd just be senseless to bump for some trivial change
< cfields>
sipa: or did you mean just compiling as c++11?
< jnewbery>
second review beg: #10579 for the same reasons as 10583. (Obviously not as important as anything v0.16 related, but I think for achow's sanity we should merge soon)
< cfields>
'cause, yea, we'd see the rvalue optims from that alone
< gribble>
https://github.com/bitcoin/bitcoin/issues/10579 | [RPC] Split signrawtransaction into wallet and non-wallet RPC command by achow101 · Pull Request #10579 · bitcoin/bitcoin · GitHub
< sipa>
jnewbery: yes, absolutely
< cfields>
beg threshold hit, will review :)
< cfields>
sipa: my immediate concern is catching exceptions across ABIs, though
< jnewbery>
thanks sipa, thanks cfields!
< instagibbs>
i know I've reviewed that PR before... no comments, hm. Will do again.
< bitcoin-git>
[bitcoin] jnewbery opened pull request #12464: Revert "[tests] bind functional test nodes to 127.0.0.1" (master...revert_12200) https://github.com/bitcoin/bitcoin/pull/12464