< fanquake> MarcoFalke Did you untag some PRs that had "Need Backport" tags? I'm sure there were more than 4 yesterday..
< fanquake> Yea, like #13192. If your untagging PRs, could you comment as to why they no-longer need backport?
< gribble> https://github.com/bitcoin/bitcoin/issues/13192 | [tests] Fixed intermittent failure in p2p_sendheaders.py. by lmanners · Pull Request #13192 · bitcoin/bitcoin · GitHub
< promag> wumpus: MarcoFalke: should tag #13160 bugfix?
< gribble> https://github.com/bitcoin/bitcoin/issues/13160 | wallet: Unlock spent outputs by promag · Pull Request #13160 · bitcoin/bitcoin · GitHub
< provoostenator> Friday chart fun at #12404
< gribble> https://github.com/bitcoin/bitcoin/issues/12404 | Prune more aggressively during IBD by Sjors · Pull Request #12404 · bitcoin/bitcoin · GitHub
< ZiNC> Is it going to be merged for 0.16.1?
< luke-jr> provoostenator: is that based on EC2 measurements? if so, it's just noise to me
< provoostenator> It is. I (or someone else) can try to reproduce on a physical machine. I think it's too consistent to be jus noise though.
< provoostenator> These machines were running for almost a week; you'd expect other tenants to come and go.
< luke-jr> provoostenator: I suggest a raspi ;)
< provoostenator> The cache usage of course is deterministic.
< luke-jr> but you may have a point there
< provoostenator> I actually ordered 2x Orange Pi Plus 2E and 1x Nanopi Neo Plus 2...
< provoostenator> 2 GB and 1 GB RAM respectively. Afaik both slightly better than the lastest Rasperry Pi, and not much more expensive.
< ZiNC> Does the prune size affect the behavior?
< provoostenator> Regarding EC2, just for comparison, the i3.2xlarge, which has a large enough SSD drive to avoid pruning and enough memory to max dbcache, just did a full IBD in 4 hours.
< provoostenator> A similar machine, but with pruning (on master), took about twice as long, but I haven't done an exact comparison.
< provoostenator> So for a project I'm working on, I just spin up a big machine, do the IBD, manually prune at the end and then downgrade.
< provoostenator> That costs about $4
< provoostenator> luke-jr: without more data I'd prefer to merge your variant to be on the safe side
< luke-jr> can always improve later
< provoostenator> Yeah, it might be worth trying more aggressive prunes again once we find a way to keep more of the cache in memory.
< bitcoin-git> [bitcoin] jhfrontz opened pull request #13320: Ensure gitian-build.sh uses bash (master...patch-1) https://github.com/bitcoin/bitcoin/pull/13320
< jhfrontz> I'm trying to do a Gitian build of Bitcoin Core on a stock (just installed from a liveUSB) Ubuntu 18.04 distro using the instructions at https://github.com/bitcoin-core/docs/blob/master/gitian-building.md#initial-gitian-setup . I keep running into situations where gitian-build.sh (or one of the scripts it calls) need to do some sort of interactive edits (e.g.., asking for confirmation on a package installation/customization
< jhfrontz> nd the script inevitably fails.
< jhfrontz> I'm assuming I'm missing some bootstrapping (that isn't otherwise handled by the build script). But maybe it's not even supposed to work on Ubuntu?
< sipa> it's certainly supposed to work on ubuntu
< sipa> but ubuntu 18.04 is pretty recent; maybe people haven't gone through it
< jhfrontz> Hmm, ok. Is there a better/stabler Ubuntu version that stands a higher probability of succeeding?
< jhfrontz> 17.10 says it's from Oct 2017.
< sipa> yes, the version numbers are YY.MM :)
< jhfrontz> hah, ok, tnx
< sipa> travis uses trusty (14.04)
< jhfrontz> ok, I'll try that; thanks!
< ken2812221> jhfrontz: If you are using lxc 3.0, you'll need to apply PR#178 of gitian-builder.
< gribble> https://github.com/bitcoin/bitcoin/issues/178 | Link with libpthread on Linux, required by libboost_thread. by wizeman · Pull Request #178 · bitcoin/bitcoin · GitHub
< ken2812221> And modify /etc/default/lxc-net, replace "lxcbr0" to "br0"