< GitHub196>
[bitcoin] luke-jr opened pull request #7340: Replace univalue subtree with proper dependency on external UniValue (master...sys_univalue) https://github.com/bitcoin/bitcoin/pull/7340
< kangx>
hello.
< michagogo>
cfields: detached sigs on the way?
< cfields>
michagogo: signing this very second
< cfields>
there's a snag with one of the descriptors, but nothing to worry about for rc1 i think
< michagogo>
Cool, I'll see if I can kick off my script before I leave
< cfields>
michagogo: you'll have to hand-edit one of the descriptors
< michagogo>
Hm?
< michagogo>
How so?
< cfields>
i'll PR it in a sec, doing sanity checks on the build atm
< michagogo>
(They're hashed, right?
< michagogo>
)
< cfields>
need to remove libc6:i386 out of the osx signer
< michagogo>
Can you just push it to the 0.12 branch, and then I'll check that out instead of the tag?
< cfields>
still need to build from the tag, just change the descriptor locally for the sig attach
< michagogo>
But gitian keeps its own git repo and brings in the tag on its own
< cfields>
yes, but the descriptor is local
< michagogo>
So if that's the only change to the descriptors from the tag, the clone of the repo that I have outside gitian can be checked out to the branch
< michagogo>
Er, can have the branch checked out
< michagogo>
Since its ignored other than the descriptors
< cfields>
you can copy the descriptor to /tmp, it doesn't matter where it lives or what's checked out
< michagogo>
cfields: I know that. I'm saying, it's probably easiest if you just commit the fix to the 0.12 branch, since I assume that needs to be in rc2 anyway.
< cfields>
oh
< cfields>
<cfields> i'll PR it in a sec, doing sanity checks on the build atm
< cfields>
:)
< michagogo>
That way the fixed descriptor can easily be used by checking out 0.12 in the external copy of the repo
< michagogo>
Yeah, just saying that makes the hand-editing unneeded as soon as that's in
< cfields>
sure, gotcha
< GitHub160>
[bitcoin] theuni opened pull request #7342: release: remove libc6 dependency from the osx signing descriptor (master...gitian-quickfix) https://github.com/bitcoin/bitcoin/pull/7342
< cfields>
sigs pushed
< Luke-Jr>
jgarzik: can you 1.0.2 univalue?
< Luke-Jr>
although it might have a bug, so maybe we should figure that out first..
< jonasschnelli>
I guess UniValue is not available over pkg managers, so people need to install the dependency by checking out the git repo and compile?
< GitHub64>
bitcoin/master fa989fb MarcoFalke: [qt] coincontrol workaround is still needed in qt5.4 (fixed in qt5.5)
< GitHub64>
bitcoin/master e1060c5 Wladimir J. van der Laan: Merge pull request #7334...
< GitHub186>
[bitcoin] laanwj closed pull request #7334: [qt] coincontrol workaround is still needed in qt5.4 (fixed in qt5.5) (master...Mf1601-qt55Workaround) https://github.com/bitcoin/bitcoin/pull/7334
< sdaftuar>
i was just looking over the release notes for 0.12 -- am i right in thinking we should highlight chainstate obfuscation and discuss downgrade issues that coudl result?
< sdaftuar>
(i'm not that familiar with the topic but vaguely recall people talking about it before)
< Luke-Jr>
jonasschnelli: or depends/ would presumably also work fine
< Luke-Jr>
sdaftuar: agree
< jonasschnelli>
Luke-Jr: you mean for univalue?
< Luke-Jr>
jonasschnelli: yes, or any other dependency
< jonasschnelli>
Yes. But it would be the first dependency that would require self-compiling.
< Luke-Jr>
only until package managers pick it up *shrug*
< Luke-Jr>
and only in the case of the user compiling in the first place :p
< cfields>
Luke-Jr: i see that pretty often, iirc it happens if something goes wrong during startup
< cfields>
Luke-Jr: mind doing a quick check on #7322 ?
< Luke-Jr>
testing
< cfields>
thanks
< cfields>
<sdaftuar> i was just looking over the release notes for 0.12 -- am i right in thinking we should highlight chainstate obfuscation and discuss downgrade issues that coudl result?
< cfields>
^^ yes
< cfields>
i accidentally ran an obfuscated chainstate on an older version, didn't go well
< Luke-Jr>
it didn't just immediately fail? :x
< cfields>
Luke-Jr: of course, but to a casual user the "why" wouldn't be obvious
< Luke-Jr>
ah
< cfields>
Luke-Jr: aha, i didn't notice the beginning of that stacktrace. facepalm.
< Luke-Jr>
?
< cfields>
Luke-Jr: it's gone off the rails already in main()
< cfields>
Luke-Jr: $1 says if you build univalue static, travis passes
< Luke-Jr>
cfields: that doesn't fix the problem :p
< cfields>
Luke-Jr: sure, just trying to narrow it down
< * Luke-Jr>
stabs Ubuntu for valgrind not working
< cfields>
Luke-Jr: btw, you can test on travis much quicker if you delete the other builders in your .travis file
< cfields>
i've resorted to that once or twice
< Luke-Jr>
I have it reproduced in a gitian VM :P
< cfields>
oh, great
< Luke-Jr>
making univalue static in bitcoin-cli results in bitcoind crashing instead
< Luke-Jr>
so you're probably right
< cfields>
init order issue?
< cfields>
Luke-Jr: maybe there's an issue with cmdline args being parsed via univalue at startup? do you know what the passed-in args are?
< Luke-Jr>
it doesn't seem to matter
< cfields>
any args cause a crash?
< Luke-Jr>
no, it needs at least rpcpassword and a method
< Luke-Jr>
morcos: what's this nonsense about removal of priority code?
< Luke-Jr>
I guess it predates your PR
< * Luke-Jr>
fixes in #7346
< Luke-Jr>
morcos: in any case, please rebase 7347 on top of that
< morcos>
Luke-Jr: I did not add that. I reworded what already was in the release notes that were merged. I think if you read my changes, you'll agree they did not change meaning.
< Luke-Jr>
morcos: yes, noticed that [20:23:38] <Luke-Jr> I guess it predates your PR
< morcos>
oh, sorry, skipped over that
< Luke-Jr>
sorry for having jumped to conclusions at first
< morcos>
Well as you know I think that is what we should do, but I wouldn't have suggested to put it in there without clearly pointing it out, as I know there is not complete consensus on it
< Luke-Jr>
sigh.. reddit.. downvoted for telling people not to use a literally random yum repository for Bitcoin Core ..
< paveljanik>
and the answer was do not trust the source, read it first? ;-)
< PRab>
I'm getting "cannot stat ‘base-trusty-amd64’: No such file or directory" when trying to run gbuild. Any ideas?
< Luke-Jr>
cfields: maybe bitcoin-cli is so simple that it doesn't instantise std::string sufficiently on its own
< cfields>
Luke-Jr: i still suspect that it has to do with the STDCXX debug option on a shared lib, when compiled differently
< PRab>
Luke-Jr: Thanks. I didn't realize I would need to redo any of that. In the past I was able to get away with just following the release-process instructions. I'm guessing it used an older version of ubuntu before.
< Luke-Jr>
I don't understand what that means. I am compiling them the same afaik
< Luke-Jr>
PRab: yes
< Luke-Jr>
jgarzik: so it seems this issue is probably unrelated to univalue, so 1.0.2 tag seems good to go IMO?
< cfields>
Luke-Jr: apparently libstdc++ uses a single address to notate that a string is "empty", and avoids freeing it in that case. If the addresses end up being different, an empty string allocated on the bitcoin side would attempt to be freed by the lib
< cfields>
which would also explain why avoiding the assignment in the header would "fix" the issue
< Luke-Jr>
cfields: hmm
< Luke-Jr>
how is that single address determined? :x
< cfields>
Luke-Jr: you use -fPIC and our hardening opts to build the lib?
< cfields>
(and visibility)
< Luke-Jr>
probably not.. those shouldn't affect ABI though :|
< cfields>
PIC certainly does
< cfields>
though visibility would get ugly, since univalue doesn't handle it
< Luke-Jr>
well, libs are going to be PIC
< JackH>
hi now that we are in bitcoin-core-dev channel, can I suggest something to the core dev's openly
< Luke-Jr>
that last pastebin doesn't make sense with your theory, does it?
< Luke-Jr>
jgarzik: actually, maybe the std::string workaround ought to be in univalue.h?
< cfields>
Luke-Jr: i must admit that one makes no sense to me
< cfields>
unless it's just avoiding them being defined differently
< cfields>
Luke-Jr: i'm going to see if i can reproduce locally
< Luke-Jr>
cfields: want me to just open my VM to you over the net?
< cfields>
oh, sure. that'd be even easier :)
< cfields>
Luke-Jr: not doubting the fix, just trying to understand what's going on
< Luke-Jr>
cfields: I'm currently testing the idea of putting that line in the univalue.h fwi
< Luke-Jr>
fwiw
< cfields>
Luke-Jr: won't that cause nasty link problems?
< Luke-Jr>
I guess we'll find out <.<
< Luke-Jr>
might make the compile much slower though? :/
< Luke-Jr>
perhaps moving the constructors to the lib is the best option
< Luke-Jr>
certainly feels like this build is slower..
< Luke-Jr>
cfields: ok, back to vanilla univalue; all yours
< Luke-Jr>
in case you missed it, the rpc test passed with the template hack
< cfields>
hmm, ok
< Luke-Jr>
(Ctrl-A Esc to use pgup/pgdown keys to scroll in screen)
< Luke-Jr>
(note it freezes the screen until you hit Esc again)