< GitHub30>
bitcoin/master fa785d1 MarcoFalke: Use __func__ to get function name for output printing
< GitHub30>
bitcoin/master a55a018 Wladimir J. van der Laan: Merge #8548: [wallet] Use __func__ to get function name for output printing...
< GitHub157>
[bitcoin] laanwj closed pull request #8376: [Wallet][Trivial] Fix exception message to reference actual thrower. (master...2016-07-19-cwallet-sethmasterkey) https://github.com/bitcoin/bitcoin/pull/8376
< GitHub27>
[bitcoin] laanwj closed pull request #8548: [wallet] Use __func__ to get function name for output printing (master...Mf1608-walletFunc) https://github.com/bitcoin/bitcoin/pull/8548
< wumpus>
you can also build from a tag from git yourself, sure, but then it doesn't make sense to ask that the hash is here. You should check the signature on the tag "git tag -v v0.13.0".
< achow101>
Anyone else having problems with gitian on Ubuntu 16.04
< jonasschnelli>
achow101: I'm on Debian 7. Works wonderful with KvM
< achow101>
how do I set it up using kvm? I'm using lxc right now
< jonasschnelli>
Not sure how I did it...
< jonasschnelli>
Did it aprox 1 year ago.
< achow101>
time to hit up the gitian builder docs then
< wumpus>
lxc is slightly more difficult to set up, as it requires some global configuration
< wumpus>
kvm on the other hand doesn't usually work when nested in a VM
< jonasschnelli>
Yes. I guess KVM requires to run the gitian host on a physical machine, although VMWare can emulate KVM in a VM.
< achow101>
wumpus: lxc isn't working for me, and I am not using a vm as the host (thankfully)
< wumpus>
jonasschnelli: right, there is some CPU bit, that if you VM environment supports it, and it is enabled, can allow for nested virtualization :)
< wumpus>
but I'm not aware of anyone using it in that way, it seems awfully specific
< wumpus>
Gavin had a very strange setup at some point where he built in vmware w/ Ubuntu VM directly. But the problem of using an 'alternative' setup is that it may have differences that result in different executables
< wumpus>
(although this is mostly solved with the depends system, there is no reliance on any OS-shipped libraries)
< wumpus>
Lauda: maybe stupid suggestion: can you try running the command again? I have a similar problem which appears only the first time I run something with lxc after VM boot
< wumpus>
the second and later times it just works (TM)
< wumpus>
there's something weird with the LXC setup but I don't know enough about it to debug it
< wumpus>
(it may be that some setup step has to be done in advance which is skipped by gitian, so a race condition happens)
< Lauda>
It's actually a script from achow101, but following the gitian guide also resulted in the same problem (IIRC). Secondary run - http://i.imgur.com/c9CRLo3.png
< Lauda>
Then it proceeds to provide the same errors for each build
< wumpus>
the /dev/shm line is probably where you need to look for the error
< achow101>
for some reason my qemu vm for gitian won't start
< cfields_>
gitian builders: v0.13.0 sigs are up
< MarcoFalke>
pushed both
< cfields_>
MarcoFalke: got it, thanks
< timothy>
hi, when will you release the 0.13 tarballs?
< sipa>
when we have enough gitian builds
< sipa>
presumably in the next day or so
< michagogo>
Looks like it's just one set of signeds short
< michagogo>
(My set is building right now)
< * michagogo>
wishes there were some kind of progress indicator when building
< michagogo>
Apparently someone over at Debian made patches relating to GCC 6 and OpenSSL 1.1 -- has anyone here seen that and looked to see if it makes sense?
< michagogo>
(I mean, someone who actually has the ability to evaluate that... unlike myself :-/ )
< michagogo>
Never mind, I misread
< michagogo>
Looks like both were fixed on our end -- it was just the bugs that were closed by the new uploads
< aj>
michagogo: no, it's not; feel free to open one
< michagogo>
aj: I don't know enough about the code (or code in general) to feel comfortable with that
< michagogo>
s/with/doing/
< michagogo>
I mean, if it breaks earlier OpenSSL it probably needs some kind of configure-time check to activate or not activate the patch
< michagogo>
(Or something)
< gmaxwell>
perhaps we should drop the openssl comparison functions from the tests. :( it's not worth carrying around a bunch of openssl version ifdefs just for tests.
< gmaxwell>
at least for libsecp256k1 we can make the openssl test in configure just not find 1.1
< sipa>
we don't use the EVP_* stuff anymore in 0.13, right?
< gmaxwell>
sipa: look at the patch.
< gmaxwell>
Payment protocol.
< gmaxwell>
sorry I didn't redflag this, I'd also thought we had eliminated all that openssl usage.
< sipa>
oh, i didn't see there was a 'bitcoin' in that URL
< sipa>
i thought you were talking about some generic openssl patches
< gmaxwell>
sipa: no openssl 1.1 has ripped out a bunch of the leaky api.