02:58 < bitcoin-git> [bitcoin] sipa opened pull request #16800: Basic Miniscript support in output descriptors (master...201908_miniscript) https://github.com/bitcoin/bitcoin/pull/16800

06:52 < bitcoin-git> [bitcoin] martinus opened pull request #16801: bulk pool allocator for node based containers (master...2019-08-bulkpoolallocator) https://github.com/bitcoin/bitcoin/pull/16801

07:27 < bitcoin-git> [bitcoin] takinbo opened pull request #16802: scripts: search for next position of magic bytes rather than fail (master...master) https://github.com/bitcoin/bitcoin/pull/16802

09:14 < wumpus> oh nooo what's wrong with travis now

09:15 < wumpus> oh timeouts getting dependencies outside our control again, https://travis-ci.org/bitcoin/bitcoin/jobs/580589335

09:30 < promag> wumpus: am I seeing it right? 10 min timeout?

09:44 < jonasschnelli> manually added peers (like -connect) will not be stored in addrman? Right? So there's currently no way to persist (or even keep in memory) the service flags?

10:27 < darosior> Could someone restart the stopped Travis jobs for s://github.com/bitcoin/bitcoin/pull/16787 please ?

10:28 < darosior> https://github.com/bitcoin/bitcoin/pull/16787 *

10:30 < fanquake> darosior: done

10:30 < darosior> Thanks !

11:26 < bitcoin-git> [bitcoin] MarcoFalke closed pull request #16801: bulk pool allocator for node based containers (master...2019-08-bulkpoolallocator) https://github.com/bitcoin/bitcoin/pull/16801

11:27 < bitcoin-git> [bitcoin] MarcoFalke reopened pull request #16801: bulk pool allocator for node based containers (master...2019-08-bulkpoolallocator) https://github.com/bitcoin/bitcoin/pull/16801

11:36 < wumpus> jonasschnelli: I think you're right

11:37 < wumpus> promag: you're seeing it right, the timeout for that initial part seems to be 10min, independently of the total timeout

11:38 < wumpus> promag: oh I understand, it's after 10 minutes of *no output*

11:39 < wumpus> that has a much lower timeout because it assumes the process is stuck if it's not spamming

12:10 < jonasschnelli> re travis: bitcoinbuilds.org is working smooth.

12:10 < jonasschnelli> I had to reduce the period how long the caches and build artefacts are stored (currently 15days).

12:11 < jonasschnelli> The whole build system was consuming up to 1TB

12:11 < jonasschnelli> Also,... the GitHub checks integration apps works on the basic level

12:12 < jonasschnelli> e.g.: https://github.com/jonasschnelli/bitcoin/pull/13/checks?check_run_id=200229412

14:52 < darosior> fanquake: could you restart the two stop jobs for https://github.com/bitcoin/bitcoin/pull/16787 again please ?.. They have again be stopped for a mysterious reason (the same as last time)

17:15 < bitcoin-git> [bitcoin] MarcoFalke opened pull request #16804: test: Remove incorrect and unused try-block in assert_debug_log (master...1909-testFix) https://github.com/bitcoin/bitcoin/pull/16804

18:22 < sdaftuar_> aj: instagibbs: do you guys agree with my comment here: https://github.com/bitcoin/bitcoin/pull/16421#discussion_r320838962

18:24 < sdaftuar_> if i have that right, then i'll bug matt to make that change now rather than re-address post-merge, because i think it'd be a bit annoying to have one fix in for 0.19 (hopefully) and then change it again afterward to address the case that is overlooked

18:24 < sdaftuar_> but i don't want to stall the PR if i'm getting that wrong somehow! i think the code there is already an improvement

18:32 < instagibbs> that strikes me as correct

18:33 < instagibbs> the comment explaining the behavior is a bit confusing me to(linked in the PR)

18:42 < sdaftuar_> you mean it's confusing, even apart from the point i brought up?

18:43 < sdaftuar_> i actually thought it was pretty good when i read it yesterday, but i also had discussed this with matt in person a while ago, which probably biases my understanding of the text

19:02 < instagibbs> yeah that's what i mean. I mean in general it's hard for me to even talk about relay policy stuff

19:02 < instagibbs> lots of terms and concepts

20:25 < bitcoin-git> [bitcoin] jamesob opened pull request #16805: logs: add timing information to FlushStateToDisk() (master...2019-09-flush-logs) https://github.com/bitcoin/bitcoin/pull/16805

20:57 < sipa> what gcc version is used in travis job 6 (the trusty one)?

20:58 < sipa> it seems to fail on some usage of user-defined literals in #16800, but user defined literals have been supported since gcc 4.7

20:58 < gribble> https://github.com/bitcoin/bitcoin/issues/16800 | Basic Miniscript support in output descriptors by sipa · Pull Request #16800 · bitcoin/bitcoin · GitHub

20:58 < sipa> i can't imagine we're using something older than that

22:38 < sipa> ok, found it

22:38 < sipa> seems in gcc 4.8 you can't use user-defined literals inside macro calls

23:48 < midnightmagic> errors emitted in GCC >= 7.1 complaining about: note: parameter passing for argument of type '__gnu_cxx::__normal_iterator<std::pair<long long int, CKeyID>*, std::vector<std::pair<long long int, CKeyID> > >' changed in GCC 7.1 <-- do I care?

23:57 < sipa> midnightmagic: it's warning you that code compiled passing data of that type around is incompatible with pre-GCC 7.1-compiled code

23:58 < sipa> tl;dr: no