< cfields> yea, forgot my scrollpad doesn't play nice with a default shell config
< Luke-Jr> is there a way to configure the shell to work nicer? :o
< cfields> hmm, don't remember what i did to make it play nice
< Luke-Jr> cfields: back for a bit - anything interesting?
< cfields> Luke-Jr: no, got distracted by something else. probably won't poke at it any more tonight
< Luke-Jr> cfields: did you look further into that -static-stdc++ difference?
< Luke-Jr> or should I check that/
< cfields> Luke-Jr: yea, linked without that. still crashed
< Luke-Jr> hmm
< cfields> oh wait, sec
< cfields> nm, that fixed :)
< cfields> i forgot to re-link the test binary
< Luke-Jr> >_<
< Luke-Jr> so I guess the solution is something like: 1) use static univalue in Travis/depends/releases (until the entire build uses shared libs); and 2) don't use -static-libstdc++ when building for the system
< jgarzik> Luke-Jr, ACK 1.0.2 tag
< cfields> Luke-Jr: all depends are static
< cfields> it was a bug to have it shared anyway, i just didn't say anything because the crash looked like something worth fixing
< Luke-Jr> cfields: so that solution sounds good?
< Luke-Jr> jgarzik: 1.0.2 tag when? ;)
< cfields> Luke-Jr: i don't see the point of having it in depends, personally
< Luke-Jr> cfields: 1) easy install for users; 2) needed for Travis/gitian
< cfields> Luke-Jr: eh? both of those are easier as it is now
< Luke-Jr> cfields: as it is now is just plain broken
< cfields> Luke-Jr: to clarify, in-tree seems fine to me
< Luke-Jr> cfields: to clarify, in-tree is a bug
< cfields> Luke-Jr: i don't really care strongly, but until distros are shipping it and it's easy to apt-get/emerge/yum, moving it out would be premature
< Luke-Jr> no, it's just good software development practice
< cfields> Luke-Jr: good practice is modularizing your code base and creating new upstreams. check. bad practice is making life hard for compilers by making them jump through hoops until those upstreams are rooted.
< Luke-Jr> 1 extra step does not make life hard
< cfields> Luke-Jr: i can clone a huge number of codebases and ./configure && make. anything more than that and my interest plummets quickly.
< cfields> i'm sure i'm not alone
< Luke-Jr> …
< cfields> anything more being: digging through docs, c/p cmdlines, foreign scripts, etc
< Luke-Jr> we already require more
< cfields> ?
< Luke-Jr> apt-get install or equivalent
< Luke-Jr> which you need to read docs to figure out
< Luke-Jr> cfields: how do you get the build to use depends/ without changing the prefix btw?
< cfields> yes, but more likely you'll just ./configure and i'll yell "you need openssl"
< cfields> Luke-Jr: i think that's the only trick that works.
< Luke-Jr> :/
< cfields> er wait, there's an env var
< midnightmagic> d/w 61
< cfields> CONFIG_SITE
< cfields> CONFIG_SITE=depends/foo/share/config.site ./configure
< droark> Is there a reason why the OSX deterministic build notes recommend Xcode 6.1.1 and not 6.2 when grabbing the SDK? Looks like 6.2 is the last version to support Mavericks.
< cfields> should do it, i think
< cfields> droark: the sdk corresponds to the clang version we use
< Luke-Jr> cfields: I wonder if it makes sense to add a --with-depends option to set up the paths
< droark> Okay. Looks like there's a minor revision in there. I thought it wouldn't be a problem but I guess it is, or at least, it's not but 6.1.1 gets everybody on the same page. Correct?
< cfields> Luke-Jr: maybe
< cfields> droark: hmm?
< droark> Looks like 6.1.1 and 6.2 are almost the same unless I'm missing something.
< cfields> droark: we don't use apple's clang
< cfields> (6.2 might be fine. more likely, it just wasn't out yet last time we bumped)
< cfields> once our travis build works on Trusty, we can do another toolchain bump
< cfields> (should be in the next two weeks)
< droark> Cool. Was just curious.
< cfields> also, in the apple world, there's no such thing as a "minor revision". they break things whenever they feel like it :)
< droark> Touché.
< cfields> iirc 10.0.2 (or something like that) changed signing rules in a big way
< cfields> er, 10.10.2
< droark> I think it was 10.9.5, or maybe there were multiple changes? Anyway....
< cfields> sure, that sounds good too :)
< Luke-Jr> cfields: correct way to resolve a relative path to absolute, in configure.ac? :p
< GitHub63> [bitcoin] dcousens opened pull request #7348: MOVE ONLY: move rpc* to rpc/ (master...master) https://github.com/bitcoin/bitcoin/pull/7348
< cfields> Luke-Jr: i believe that one's always voodoo
< Luke-Jr> :|
< Luke-Jr> cfields: `make -C depends HOST=i686-pc-linux-gnu libevent` does not populate depends/i686-pc-linux-gnu/ - any idea why?
< cfields> Luke-Jr: what's with the libevent target?
< Luke-Jr> cfields: I only want libevent built/installed
< cfields> Luke-Jr: heh, depends weren't made to work that way :)
< Luke-Jr> :/
< Luke-Jr> trivial to make it work that way?
< cfields> Luke-Jr: the result is meant to be deterministic, so each package is built in its own staging area, then all packages are installed into the prefix at the end
< cfields> not really :\
< cfields> only option would be something like the NO_QT or NO_WALLET options
< cfields> but i don't like that, it's kinda abusing the system
< Luke-Jr> ok, so depends basically only makes sense for travis/gitian :/
< cfields> yes, it was designed to be a means of reproducing release build conditions reliably
< jgarzik> Luke-Jr, v1.0.2 passed local univalue travis
< Luke-Jr> thanks
< dcousens> when does cs_main need to be locked?
< dcousens> (is there a reference for that?)
< dcousens> (I have a rough idea)
< dcousens> also, whats the difference between EXCLUSIVE_LOCKS_REQUIRED and just using AssertLockHeld?
< GitHub94> [bitcoin] luke-jr opened pull request #7349: Build against system UniValue when available (master...sys_univalue_opt) https://github.com/bitcoin/bitcoin/pull/7349
< GitHub199> [bitcoin] luke-jr closed pull request #7340: Replace univalue subtree with proper dependency on external UniValue (master...sys_univalue) https://github.com/bitcoin/bitcoin/pull/7340
< Luke-Jr> cfields: ok to destroy that VM?
< cfields> sure
< GitHub170> [bitcoin] luke-jr opened pull request #7350: Banlist updates (master...20150703_banlist_updates) https://github.com/bitcoin/bitcoin/pull/7350
< dcousens> Luke-Jr: interesting, but how can I review that merge in any reasonable way? How do I know you haven't just injected some malicious code in there?
< dcousens> I guess I could manually verify it by checking the diffs locally with my own merge?
< Luke-Jr> or just view the diff on github?
< Luke-Jr> but yeah, locally checking is the best way
< dcousens> Assuming the merge was sane (its diff won't appear regardless)
< Luke-Jr> …
< dcousens> nvm
< dcousens> Been so long since I've used merges... forgot the semantics lol
< dcousens> well, more to the point, non-fast-forward merges
< GitHub190> [bitcoin] btcdrak opened pull request #7351: Update Makefile backup URL (master...patch-1) https://github.com/bitcoin/bitcoin/pull/7351
< GitHub4> [bitcoin] btcdrak opened pull request #7352: Update Makefile backup URL (0.12...patch-2) https://github.com/bitcoin/bitcoin/pull/7352
< GitHub195> [bitcoin] btcdrak opened pull request #7353: [0.11] backport "Update Makefile backup URL" (0.11...patch-3) https://github.com/bitcoin/bitcoin/pull/7353
< GitHub58> [bitcoin] rsmoz opened pull request #7354: I have fixed the block size issue (master...master) https://github.com/bitcoin/bitcoin/pull/7354
< paveljanik> OMG
< michagogo> Wow, Qt builds are seriously painful.
< michagogo> BDB needs a rebuild?
< * michagogo> looks at the diff again
< michagogo> What's OBJCXXLD?
< michagogo> TIL that Objective C++ is a thing.
< michagogo> (wait, why are we using that in Linux? I thought ObjC was a Mac thing.)
< michagogo> (or rather, Apple)
< michagogo> cfields: Why does Linux build 32-bit first and then 64, while Windows does it the other way around?
< michagogo> Does that have any effect, and would it be unsafe/noisy/have side effects to change them to match?
< michagogo> It's annoying when you're trying to look at the tailf of build.log to figure out how far along in the build you are.
< GitHub151> [bitcoin] jonasschnelli closed pull request #7354: I have fixed the block size issue (master...master) https://github.com/bitcoin/bitcoin/pull/7354
< jonasschnelli> michagogo: darwin crosscompile uses "OBJCXXLD" in order to make use of apples frameworks (they are objc and are required by Qt)
< michagogo> jonasschnelli: this isn't a darwin crosscompile
< jonasschnelli> And also our source base uses some objc (some tweaks)
< michagogo> this is the gitian linux build
< michagogo> And... really? didn't know that.
< jonasschnelli> Hmm... linux build does use OBJCXXLD?! strange...
< morcos> I haven't reproduced this, I bumped travis and it passed, but I don't know if it was an oddity related to my changed or an underlying issue
< morcos> Anwyay, if anyone else sees wallet.py fail in the maintenance tests again, we should probably look into it
< MarcoFalke> morcos, thx I will look into this tomorrow
< GitHub157> [bitcoin] btcdrak closed pull request #7353: [0.11] backport "Update Makefile backup URL" (0.11...patch-3) https://github.com/bitcoin/bitcoin/pull/7353
< GitHub76> [bitcoin] btcdrak closed pull request #7352: [0.12] backport "Update Makefile backup URL" (0.12...patch-2) https://github.com/bitcoin/bitcoin/pull/7352
< paveljanik> Luke-Jr, what was the solution for error: 'enum_type' is not a member of 'boost::future_errc'?
< paveljanik> thanks! will check it if it helps here - gcc 4.8.3
< Luke-Jr> 4.8.5 here
< paveljanik> BTW - the logs referenced from $topic do not contain 2016...
< paveljanik> (at least the erisian)
< paveljanik> Luke-Jr, passed compile, will test and ACK too