**** BEGIN LOGGING AT Sat Feb 09 02:59:57 2019 Feb 09 08:55:41 kanavin: Interestingly, python3 upgrade added 1 minute to the build time: https://autobuilder.yocto.io/pub/non-release/20190209-3/testresults/buildperf-centos7/perf-centos7.yoctoproject.org_master_20190209030027_c4f1276.html Feb 09 08:55:49 kanavin: at least I suspect that anyway Feb 09 08:56:33 sorry, https://autobuilder.yocto.io/pub/non-release/20190208-7/testresults/buildperf-centos7/perf-centos7.yoctoproject.org_master_20190208150028_29099c8.html Feb 09 09:41:29 kanavin: is your version of virglrenderer recipe supposed to build for target as well? It depends on mesa directly instead of one of virtual/* providers, so it cannot be built e.g. for targets which prefer mesa-gl Feb 09 11:33:21 New news from stackoverflow: How to overwrite linux system files into the yocto filesystem? Feb 09 16:40:01 RP: I am seeing faster parsing of world builds in my case Feb 09 17:12:49 khem: due to a change? Feb 09 17:31:50 RP: with new python3 Feb 09 17:32:51 khem: you're building in one our own images? Feb 09 17:33:18 RP: the one from core Feb 09 17:33:23 nothing custom Feb 09 17:33:37 khem: nice, that is good to hear/know :) Feb 09 17:33:46 but I have not measured to be precise Feb 09 17:33:49 khem: how much of a speedup roughly? Feb 09 17:34:38 khem: I think I have a patch to teach the build performance reporting code to do the right thing with master-next comparisons with master. Have queued a virtgl build to see Feb 09 17:34:58 kanavin: ^^^ should be interesting Feb 09 17:35:38 i see Feb 09 17:35:52 I think we need qemu-user only for build though Feb 09 17:36:00 khem: agreed Feb 09 17:36:23 khem: that can be done as a separate work item if needed Feb 09 17:57:44 RP: I found the reason for my opkg woes Feb 09 17:58:01 xz is too greedy Feb 09 17:58:14 system is 16cores/16Gb Feb 09 17:58:49 works ok with 16core/32gb Feb 09 17:59:20 I sent a patch to ping max memory for xz to 70% of system it helps Feb 09 17:59:46 khem: your patch doesn't change do_package_write_ipk though Feb 09 17:59:48 its similar issue that we had with ninja where it had its own idea of parallelism Feb 09 18:00:02 hmm Feb 09 18:00:14 khem: I agree we need to limit it Feb 09 18:01:29 i think I sent a wrong version of patch Feb 09 18:01:34 hmm Feb 09 18:01:52 actually I dropped it and was trying to ping --thread Feb 09 18:01:56 pin Feb 09 18:08:46 RP: I think we should be using --threads ${BB_NUMBER_THREADS} Feb 09 18:08:57 along with -M Feb 09 18:09:23 RP: my patch was doing this in meta/classes/package_ipk.bbclass Feb 09 18:09:47 but I want to improve it such that we can pass XZ_DEFAULTS in global environment Feb 09 18:10:08 RP: whats best place for exporting an env variable Feb 09 18:10:22 that way we can control all xz invocations Feb 09 18:11:01 export XZ_DEFAULTS="-M 70% -T ${BB_NUMBER_THREADS}" Feb 09 18:11:13 would like to pass this Feb 09 18:11:44 and remove individual settings of xz in various places Feb 09 18:34:53 khem: shouldn't it be based on parallel make rather than bb threads? Feb 09 19:09:16 we reset PARALLEL_MAKE in recipes quite a bit Feb 09 19:09:41 BB_NUMBER_THREADS achieves current behaviour Feb 09 22:30:00 khem: PARALLEL_MAKE is the parallelisation to have in each recipe, BB_NUMBER_THREADS is how many recipes to run in parallel Feb 09 22:30:12 khem: that is how I see them anyway Feb 09 22:37:43 RP: I am fine with changing to PARALLEL_MAKE but we will be limiting xz for lousy makefiles Feb 09 22:37:49 which is not related even Feb 09 22:38:55 khem: I guess you can argue this both ways :/ Feb 09 22:39:30 khem: we probably need to rework the variables anyway as -j X is a pain to use for non make Feb 09 22:46:07 * armpit back to debugging sumo **** ENDING LOGGING AT Sun Feb 10 02:59:56 2019