00:25 <K-ballo> hkaiser: the attachment didn't make it.. did you just finish the registration?

00:27 <K-ballo> something wrong with thunderbird, I could download the attachment straight from gmail

00:41 <K-ballo> the bot is identifying itself but still doesn't make it into the channel somehow

00:44 <ste||ar-github> [hpx] K-ballo deleted new-branch-test at 389ca4a: https://github.com/STEllAR-GROUP/hpx/commit/389ca4a

00:44 <K-ballo> there we go

00:47 <hkaiser> thanks K-ballo

04:41 <heller> jbjnr: what do you suggest?

07:23 <jbjnr> heller: we need to find whatever is causing random fails.

07:26 <heller> ok, let's do it

07:26 <heller> a less random testing would help here ;)

07:27 <zao> Too bad I didn't finish my soak tester idea :)

07:27 <jbjnr> less random?

07:27 <jbjnr> the tests are run on the same conditions every time

07:28 <heller> are they?

07:28 <heller> I thought we have a random selection of compilers and debug/release?

07:40 <jbjnr> no, that's a new feature I'm working on to enable more combinations of setting to be tested, currently, the tests ar the same every time (apart from gcc/clang switch)

07:43 <heller> ok

07:43 <heller> still, the gcc/clang doesn't help to get the same failures all the time

07:43 <heller> I think we should go all in

10:02 <ms[m]1> heller, jbjnr: I'm trying to run a few different setups for every PR, but a couple of problems are slurm timeouts and running out of quota on scratch (cleanup helps, but I'm getting it now with more builders as well)

10:02 <ms[m]1> Of course we have our own timeouts as well...

10:03 <heller> yeah ... it's a problem

10:10 <jbjnr> ms[m]1: there was a bug in the pycicle cleaup that I fixed the other day. It might help you if too amny old build/src dirs are hanging around

10:11 <heller> I wish we had a cloud service where we could run those things without limitations..

10:11 <jbjnr> daint is pretty good.

10:11 <jbjnr> we're running a lot

10:11 <heller> ok

10:12 <jbjnr> next pycicle fixes might allow a better utilization of resources. Now that I've added random configs, you can spawn N builds per PR, so doing 10 per PR with random cominations of settings will give us tons of coverage, but I have to add extra job control to prevent resource overuse too, so dependencies and queues of jobs are next.

13:44 <diehlpk_work> nikunj97, https://stellar-group.org/2018/08/gsoc-18-final-documentation-for-q-c-run-time-replacement/

14:12 <ms[m]1> diehlpk_work: hey, did I read your email from a few weeks ago correctly that you wanted final reports for the ste||ar blog three days ago latest?

14:27 <nikunj97> diehlpk_work, see pm please

14:28 <nikunj97> ms[m]1, that's correct, the final submission day for the blog was on 3rd of Aug. This would then help diehlpk_work to add them to the site and provide us with the links

14:50 <hkaiser> nikunj97: see pm, pls

15:34 <diehlpk_work> ms[m]1, Yes, so we have enough time to validate that the blog post is accroding the guidelines from Google

15:35 <diehlpk_work> and our studnets have enough time to improve the final submisison

15:35 <diehlpk_work> It is very important to hold the rquirements

16:11 <ms[m]1> diehlpk_work: okay, no problem, that makes sense

16:11 <ms[m]1> I just had a meeting with jakub and he'll be posting on his own blog

16:11 <ms[m]1> hkaiser: so is there anything we can do about appveyor? do you have access to logs?

16:48 <hkaiser> ms[m]1: not sure, IIRC it simply runs out of memory or time

17:36 <ms[m]1> Hmm, all right, I guess some digging in the build history is needed... You're not aware of any changes on apoveyor's side?

18:00 <nikunj97> hkaiser, did you get free time to review my PR? I think #3385 and #3368 will not require much of your time. #3367 can however take some time, so you can review it whenever you have adequate amount of time.

20:59 <jgolinowski> ms[m]1, yt?

22:57 <jgolinowski> ms[m]1, I commited to the opencv PR. I tested it on all tests and it works as the previous version. As for the answer to the message I started the sketch in the "communication" gdoc