**** BEGIN LOGGING AT Mon Jun 04 03:00:00 2018
Jun 04 05:16:26 <vishnu_nk> Is there any way to find the time taken for building all individual packages in an image?
Jun 04 05:54:40 <vishnu_nk> Have enabled sstate cache. But still build seems to be slow. Would like to find out what all packages are taking lot of time to build. While using yocto 1.6 build was pretty much faster and after migrating to yocto2.1 build seems slow
Jun 04 05:55:14 <vishnu_nk> If there is some way to findout those packages which takes time, it will be easy for debug
Jun 04 06:25:40 <yocti> New news from stackoverflow: qupzilla compile error in yocto krogoth version <https://stackoverflow.com/questions/50674255/qupzilla-compile-error-in-yocto-krogoth-version>
Jun 04 06:46:35 <angelo_ts> hi gm, how do i inform yocto, in a bbappoend, to build only a subfolder of a git repo ?
Jun 04 07:25:55 <yocti> New news from stackoverflow: Bitbake meta-toolchain-qt5: Error do_populate_sdk <https://stackoverflow.com/questions/50674909/bitbake-meta-toolchain-qt5-error-do-populate-sdk>
Jun 04 09:48:35 <stoke_> Hey, my bitbake-self test is failing the wget tests what should I do from here?
Jun 04 09:48:38 <stoke_> It worked before
Jun 04 09:56:25 <yocti> New news from stackoverflow: Create binary patches & apply using git commands <https://stackoverflow.com/questions/50677861/create-binary-patches-apply-using-git-commands>
Jun 04 10:17:50 <rburton> morning
Jun 04 10:56:36 <yocti> New news from stackoverflow: "git binary diffs are not supported" error while creating binary patches & applying using git commands <https://stackoverflow.com/questions/50677861/git-binary-diffs-are-not-supported-error-while-creating-binary-patches-apply>
Jun 04 11:45:34 <kanavin> rburton: morning, how was the holiday?
Jun 04 11:45:47 <kanavin> I saw the photo of you disembarking from the plane and nothing since :)
Jun 04 12:09:21 <rrerolle> hello, does anyone know a way to only clean non-native parts of the sstate cache ?
Jun 04 13:01:06 <rburton> kanavin: good thanks.  terrible 3g where we were staying!
Jun 04 13:01:17 <rburton> rrerolle: rm?
Jun 04 13:02:04 <rrerolle> rburton: yeah, but I was wondering what to rm
Jun 04 13:02:12 <rrerolle> I went with
Jun 04 13:02:16 <rrerolle> find sstate-cache -type f \! -name "*cross*" \! -name "*native*" \! -name "*gcc*" \! -name "*glibc*"
Jun 04 13:04:57 <rrerolle> find sstate-cache -type f \! -name "*cross*" \! -name "*native*" \! -name "*gcc*" \! -name "*glibc*" -delete
Jun 04 13:05:14 <rrerolle> it does what I want
Jun 04 13:11:24 <kanavin> rburton: I am struggling with the question: just how much of the current perl recipe I should throw away
Jun 04 13:11:35 <kanavin> rburton: I am leaning towards "all of it"
Jun 04 13:11:56 <kanavin> and bring back pieces on a strict as-needed basis
Jun 04 13:20:58 <rburton> kanavin: there's definitely merit in 'burn it down' and bring back what is needed
Jun 04 13:21:05 <rburton> such an old recipe there's going to be a lot of cruft
Jun 04 13:21:24 <kanavin> rburton: one of the more controversial things in that is that I will also throw away the module splitting
Jun 04 13:22:09 <kanavin> people who want it need to drive it as well, or accept that if they do nothing, it goes away
Jun 04 13:22:34 <kanavin> oh, and if Derek doesn't show up soon, the same will happen to python3, enough is enough
Jun 04 13:23:44 <rburton> kanavin: the splitting is theoretically useful though, but i have no idea if perl can be re-split into something more granular if eg only one module is huge
Jun 04 13:27:29 <kanavin> rburton: already 'drained the swamp' for openssl ;)
Jun 04 13:27:38 <kanavin> just waiting for the final 1.1.1 release
Jun 04 13:30:30 <kanavin> rburton: I'll post the RFC patch and we'll see. We can also do AB runs to sort the obvious regressions.
Jun 04 13:30:39 <rburton> yes, thanks kanavin
Jun 04 13:30:43 <kanavin> rburton: and yeah python3 is next in line for this treatment :)
Jun 04 13:41:49 <kanavin> rburton: one thing I am not throwing away though is ptest support
Jun 04 13:42:06 <rburton> good :)
Jun 04 14:12:20 <rrerolle> hello, I'm trying to build a linux-4.16 kernel, and I'm hitting an issue regarding https://www.kernel.org/doc/html/v4.16-rc7/process/changes.html
Jun 04 14:12:49 <rrerolle> more specifically, the fact that "Since Linux 4.16, the build system generates lexical analyzers during build. This requires flex 2.5.35 or later." and "Since Linux 4.16, the build system generates parsers during build. This requires bison 2.0 or later."
Jun 04 14:13:10 <rrerolle> I think I managed to have it working by specifying
Jun 04 14:13:22 <rrerolle> do_kernel_configme[depends] += "bison-native:do_populate_sysroot flex-native:do_populate_sysroot"
Jun 04 14:13:56 <rrerolle> in my kernel recipe. I wonder if it's the correct way to do it, since simply adding bison-native and flex-native to DEPENDS is not enough
Jun 04 14:21:02 <zeddii_home> rrerolle: I have a patch for that issue. I’ll be sending it shortly.
Jun 04 14:38:03 <rrerolle> zeddii_home: ok, nice
Jun 04 14:40:49 <zeddii_home> rrerolle: I’m rebasing/consolidating it with some other changes, but the WIP is here: http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=zedd/kernel-next
Jun 04 14:41:58 <zeddii_home> khem: I saw your messages here about the gcc8 fixes. I’m grabbing them now.
Jun 04 14:43:03 <rrerolle> zeddii_home: great, while you're at it, the oldnoconfig triggers a deprecation warning, it's been replaced by olddefconfig
Jun 04 14:45:06 <zeddii_home> its been like that for ages. I have a set of changes there as well, all to come in the next couple of weeks.
Jun 04 14:45:41 <rrerolle> zeddii_home: ok, thanks for the heads up
Jun 04 14:55:00 <mcfrisk_> hi, linux-libc-headers isn't meant for exposing kernel headers to compile external modules. The shared workdir with STAGING_KERNEL_DIR is for that. But what about exporting custom kernel and driver specific uapi headers? What's the correct way to expose them to userspace? They are not used by libc so in theory linux-libc-headers does not need to change, but I can't find any other sane way to provide the
Jun 04 14:55:07 <mcfrisk_> headers to userspace..
Jun 04 14:59:21 <zeddii_home> mcfrisk: you can (or used to be, I haven’t checked in months) make a custom sysroot export of the headers. As long as they don’t clobber the existing kernel ones, everything will co-exist.
Jun 04 15:03:24 <mcfrisk> zeddii_home: I hacked a do_install append to "make headers_install" to a custom location, but the headers end up in shared word dir instead of sysroot, and now I would need to hack the shared work path to build scripts of all users.. Any way to install the headers with custom path to existing sysroot?
Jun 04 15:04:46 <zeddii_home> yah. sec. I need to find my old hacked header class. I can never get the details right from memory.
Jun 04 15:07:19 <armpit> zeddii_home, any plans on updated 4.4 & 4.9 ?
Jun 04 15:07:42 <zeddii_home> eventually yah.
Jun 04 15:07:58 <zeddii_home> I’m still trying to get my last batch of active kernel updates to show up in oe-core :D
Jun 04 15:09:28 <zeddii_home> mcfrisk: ahah. there it is. I’ve used sysroot_stage_dir to get custom installed uapi (or other) headers, available in the sysroot. but that was mostly before per recipe sysroots.
Jun 04 15:10:55 * armpit wow, we have 8 active kernels
Jun 04 15:11:20 <zeddii_home> I shall become Dr. Death and delete a few shortly. my patch queue is killing me at the moment.
Jun 04 15:11:30 <mcfrisk> zeddii_home: ok, thanks. I will try to do the same..
Jun 04 15:14:20 <armpit> mcfrisk, become Dr. Death ?
Jun 04 15:14:30 <zeddii_home> hehehe ;)
Jun 04 15:15:25 <armpit> zeddii_home, we really need to shelve morty and pyro, that would simplify things for you
Jun 04 15:15:51 <zeddii_home> yah. agreed. I can update the kernels, but really can’t properly test them in that context.
Jun 04 16:25:43 <kanavin> rburton: change of course, sadly far too many recipes in oe-core and meta-oe have perl-module-blahblah in their dependencies
Jun 04 16:26:01 <rburton> of course
Jun 04 16:27:26 <kanavin> rburton: the new perl recipe itself now fully builds in all three variants without warnings or errors \0/
Jun 04 16:29:16 <RP> kanavin: sounds good :)
Jun 04 16:31:23 <kanavin> RP: http://git.yoctoproject.org/cgit.cgi/poky-contrib/tree/meta/recipes-devtools/perl-sanity/perl_5.26.2.bb?h=akanavin/perl-sanity&id=a3554a88a0a4b64716e930a87108d8ba57bf271b
Jun 04 16:31:46 <kanavin> sweet isn't it? :)
Jun 04 16:32:23 <RP> kanavin: that does look quite a bit neater!
Jun 04 16:32:46 <neverpanic> kanavin: have you tried building that in a path that contains the string 'perl5'?
Jun 04 16:32:52 <kanavin> RP: I'll have to bring back the module splitting though, but it should be still decently neat
Jun 04 16:33:06 <kanavin> neverpanic: nope, why?
Jun 04 16:33:12 <neverpanic> Or rather, a build directory that contains that path
Jun 04 16:33:22 <RP> kanavin: I was wondering about the module splitting
Jun 04 16:33:28 <neverpanic> perl configures differently depending on whether it's installed with a prefix that contains 'perl5', IIRC
Jun 04 16:34:40 <neverpanic> https://github.com/neverpanic/poky/commit/9cbdd61d5285422ee33b376d0f71f64f6f00e93a
Jun 04 16:34:49 <neverpanic> This may no longer apply, I tested on a pretty old version
Jun 04 16:35:15 <kanavin> neverpanic: the new recipe is using a completely different build system from buildroot project.
Jun 04 16:35:34 <neverpanic> OK, that's nice :)
Jun 04 16:35:47 <kanavin> neverpanic: the second tarball in SRC_URI
Jun 04 16:36:25 <kanavin> RP: the next recipe to get the same treatment will be python3, but that'll probably come from the luxoft-alex
Jun 04 16:36:44 <kanavin> I have one week to wrap things up, and switch the gear off
Jun 04 16:37:25 <kanavin> If Derek continues to be absent...
Jun 04 16:37:31 <RP> kanavin: a feeling I know all too well. I keep thinking I have a dev environment working, then it doesn;t :(
Jun 04 16:44:56 <kanavin> RP: I'll probably be the non-contributing patch critic for a while :)
Jun 04 16:46:10 <RP> kanavin: patch review is hard...
Jun 04 16:57:49 <yocti> New news from stackoverflow: "git binary diffs are not supported" error using yocto <https://stackoverflow.com/questions/50677861/git-binary-diffs-are-not-supported-error-using-yocto>
Jun 04 17:33:10 <armpit> RP patch review is easier with a few beers
Jun 04 18:09:06 <angelo_ts> hi, can i configure yocto to see the full build command line
Jun 04 18:09:11 <angelo_ts> ?
Jun 04 20:43:40 <sveinse> The libopus_*.bb recipe in meta-openembedded contains this ARM_INSTRUCTION_SET = "arm" statement. What does it do?
Jun 04 20:43:55 <fray> disables 'thumb' instructions when building that component..
Jun 04 20:44:06 <fray> something in it is known to NOT work with thumb
Jun 04 20:44:23 <sveinse> But it does not limit extensions the "other" way, such as neon?
Jun 04 20:44:46 <fray> no.. values are either "arm" or "thumb".. (I think it's thumb and not thumb2)
Jun 04 20:44:54 <sveinse> fray: ok, thanks
Jun 04 20:45:20 <fray> yes, arm and thumb are the only two valid values
Jun 04 20:45:51 <fray> defined in meta/conf/machine/include/arm/feature-arm-thumb.inc
Jun 04 20:52:10 <bemo> trying to understand why "usr/include/linux" isn't showing up in my meta-toolchain build, but not sure where to look
Jun 04 20:54:14 <bemo> any suggestions or pointers?  :)
Jun 04 21:01:48 <fray> userspace needs to include the kernel-headers package.. that SHOULD be included by your libc's -dev package
Jun 04 21:02:30 <fray> libc's -dev should be included from the dev-pkgs applied to populate_sdk.. unless youa re actually building meta-toolchain.. if that is the case, then you have to be specific about the libc and such..
Jun 04 21:04:46 <bemo> it's been touched internally, so not sure how to undo it if someone has excluded the kernel-headers package, but I'll poke around.
Jun 04 21:04:55 <bemo> thanks
Jun 04 21:08:38 <bemo> what is the difference between "-c populate_sdk" and hunting down the installer script, compared to "bitbake meta-toolchain", and using that installer?  (it's quite possible I'm confused)
Jun 04 21:13:39 <kergoth> meta-toolchain includes the packages listed in the recipe, i.e. those in TOOLCHAIN_HOST_TASK/TOOLCHAIN_TARGET_TASK only
Jun 04 21:13:46 <kergoth> -c populate_sdk mirrors the image contents by default
Jun 04 21:13:52 <fray> -c populate_sdk makes an SDK from the image recipe..
Jun 04 21:13:53 <kergoth> i.e. a gui image will include those libraries
Jun 04 21:14:11 <fray> meta-toolchain makes an SDK from whatever meta-toolchain 'says'.. so nothing to as much (or little) as you want..
Jun 04 21:14:18 <fray> most people fine meta-toolchain too complex..
Jun 04 21:15:11 <bemo> okay... tried the "-c populate_sdk" approach as well, and didn't seem to have the usr/include/linux directory either, which sounds strange, if I understand what you're saying.... more poking.  :)
Jun 04 21:15:26 <bemo> thanks!
Jun 04 22:29:24 <kergoth> https://gist.github.com/kergoth/7f24deee6bc6414ed50d2fb5979811bd seem reasonable? blindly quoting without escaping is not a great way to go, even if it's unlikely to cause problems due to other system limitations
Jun 04 22:34:37 <rburton> kergoth: yes.   every use of subprocess which uses a string is a bug imho
Jun 04 22:34:59 <rburton> do you need shell=true?
Jun 04 22:35:52 <kergoth> good point, that's a possibility depending on the semantics of EDITOR/VISUAL
Jun 04 22:36:30 <kergoth> i thought about trying to use pipes.quote() or shlex.quote() or something to construct the string, but as you say, list is superior, and pipes.quote isn't a public function, unlike the shlex ones
Jun 04 22:42:32 <kergoth> it seems like the vars should either be a single path/name or multiple, but shouldn't require shell processing or variable expansion
Jun 04 23:41:47 <needmoreram> is there anyway to pass a python object between two python functions intact?
Jun 04 23:42:31 <needmoreram> I tried using d.setVar() and d.getVar() on the other end, but the ids of both objects are different
Jun 04 23:42:45 <needmoreram> suggesting that setVar() does some sort of a copy on the object
**** BEGIN LOGGING AT Tue Jun 05 02:04:39 2018
**** ENDING LOGGING AT Tue Jun 05 03:00:14 2018