**** BEGIN LOGGING AT Tue May 21 09:33:43 2019 May 21 09:41:39 Hello, a general question regarding GNU Makefile. Is there any difference between the following 1) FOO=bar make target 2). make target FOO=bar May 21 09:49:54 Chaser, 1) is environment variable, 2) is argument variable May 21 09:58:46 hi May 21 10:22:05 mihai: ah true thanks. May 21 10:26:07 hi - are there instructions available anywhere on how to reproduce locally the builds done on autobuilder.yoctoproject.org ? May 21 10:36:08 bluca, not really, but you can start with http://git.yoctoproject.org/cgit/cgit.cgi/yocto-autobuilder2/about/ and http://git.yoctoproject.org/cgit/cgit.cgi/yocto-autobuilder-helper/about/ May 21 10:37:06 thanks - just trying to repro a build failure with a patch that doesn't happen with the distro I work on May 21 11:29:59 question about mesa (packaging): enabling certain drivers (i.e. `etnaviv imx`) via PACKAGECONFIG results in identical copies of swrast (mega-driver?) in `${prefix}/${libdir}/dri/` May 21 11:30:05 is that intended? May 21 11:39:45 New news from stackoverflow: Yocto "Failed to run qemu: Could not initialize SDL(x11 not > available)" May 21 14:10:24 hi. I tried to add python3-pyelftools-native recipe to yocto. I added it under CORE_IMAGE_EXTRA_INSTALL and added BBLAYERS =+ "${METADIR}/meta-sca" in bblayers.conf - but I'm getting the following error: May 21 14:10:26 ERROR: Task do_populate_sdk in /home/user/workspace_agl/meta-agl/meta-agl/recipes-core/images/agl-image-minimal.bb rdepends upon non-existent task do_package_write_rpm in /home/user/workspace_agl/meta-sca/recipes-python/python-pyelftools-native/python3-pyelftools-native_0.25.bb May 21 14:11:04 link to the recipe: https://layers.openembedded.org/layerindex/recipe/96664/ - help someone? May 21 14:11:12 naknick: adding a -native recipe to an image is rather nonsensical May 21 14:14:09 naknick: a -native recipe basically makes only sense as a dependency, be it a direct or an indirect one May 21 14:15:17 LetoThe2nd: lets make it simple. I want to add 'scons' package (which you can get by apt-get) and 'pyelftools' module to python3 - how should I do it? May 21 14:16:51 naknick: first, this is not related to apt-get in any way whatsoever May 21 14:17:09 naknick: and where do you want which package? on the building host, or on the target? May 21 14:17:22 I know. I'm talking about the parallel way under Ubuntu May 21 14:17:39 on the target of course May 21 14:17:45 naknick: do not talk about parallel unrelated ways, it is just confusing May 21 14:17:52 ok May 21 14:18:02 naknick: so, if you want something on the target, it is not a -native package May 21 14:18:46 so should I use this one? https://layers.openembedded.org/layerindex/recipe/32221/ May 21 14:19:16 and this one: https://layers.openembedded.org/layerindex/recipe/4846/ May 21 14:19:47 naknick: yep. if you want pyelftools on the target, then the first link you pasted is the way to go. at least technically, i have no idea how well the layer "meta-measured" is maintained. May 21 14:20:18 naknick: the python-scons recipe shouldbe fine. May 21 14:21:55 LetoThe2nd - OK. If I don't have meta-measured layer under yocto-root folder - how should I add it? May 21 14:25:07 You get a copy and add the layer to your conf/bblayers.conf May 21 14:26:04 usually by cloning the layer with git into a local directory May 21 14:29:39 naknick: don't forget the add the layers meta-measured depends on as well May 21 14:29:59 though it'll probably notify you of any missing package May 21 14:36:01 naknick: just like any other layer too. you look at the layer index, get its repository url, clone it, checkout the branch that matches your poky version, and add it to bblayers.conf May 21 14:39:39 sanderer - it only depends on openembedded-core May 21 14:39:48 kanavin_: any ideas on https://autobuilder.yoctoproject.org/typhoon/#/builders/15/builds/852 ? May 21 14:40:15 naknick: then you should add that to your bblayers.conf as well May 21 14:40:28 LetoThe2nd - thanks. this is what I did (with git clone) - but I wasn't sure that's the correct way. thanks May 21 14:51:38 RP: looking into it May 21 15:01:11 YPTM: Armin is on May 21 15:01:28 YPTM: Randy joined May 21 15:01:48 * RP must have the wrong number May 21 15:02:27 https://zoom.us/j/990892712 May 21 15:05:27 YPTM: Joshua Watt here May 21 15:06:43 I'm a little confused, I thought there wasn't going to be a second YPTM this month....? May 21 15:10:24 New news from stackoverflow: Bitbake: How to list all recipe and append files used in an image? May 21 15:50:54 Hmm, why does enabling multiconfig cause bitbake to parse every time I run it? May 21 15:52:52 JPEW: it shouldn't May 21 15:53:20 JPEW: the reproducibility test looks useful btw, thanks May 21 15:53:36 RP: it's a start :) May 21 15:54:48 JPEW: yes, and gives us an idea where problems have crept in (perl and debug section ordering) May 21 17:40:57 Is there an equivalent to "bitbake -e" (with no recipe, just the base config) for a multiconfig? e.g. "bitbake -e multiconfig:foo" May 21 17:46:15 Is anyone active in the NPM Fetcher code? I am wondering how up-to-date this wiki page is - https://wiki.yoctoproject.org/wiki/TipsAndTricks/NPM May 21 18:08:23 JPEW: hmm, possibly not May 21 18:08:42 scottrif: someone sent patches recently but I know little about it May 21 18:09:59 RP: I am just trying to see if that wiki page is up to date. And if not, maybe someone could describe the changes. May 21 18:12:42 scottrif: I don't know for sure but I don't think its changed much if at all recently May 21 18:12:51 I think I must be doing something wrong with multiconfig... it's *so* slow... bitbake spends minutes "Parsing recipes" before it starts to build... AFAICT, it's fully utilizing the parsing cache May 21 18:13:15 RP: Okay - thanks. I will assume it is accurate for today's YP version. May 21 18:13:23 JPEW: then where is it spending time? May 21 18:13:33 JPEW: BuildStarted events? May 21 18:16:06 Not specifically sure.... I ran with -DDD and all I really see is a stream of "EXCLUDE FROM WORLD" messages while it is working May 21 18:23:34 JPEW: does that mean its somewhere in taskdata or runqueue building the runqueue? May 21 18:24:09 ah, the exclude from world is loading the data from the parsing cache May 21 18:24:14 I think its even before that.... its loading the parsing cache from disk (I think) May 21 18:24:16 right May 21 18:24:17 how big is the parsing cache? May 21 18:24:24 ~500 MB May 21 18:24:51 JPEW: do single builds of each of the multiconfigs as a single entity take very long? May 21 18:25:28 My parsing cache files for poky are 20MB May 21 18:25:38 Oh.... hmm May 21 18:26:00 JPEW: lots of layers? Extra cached metadata? May 21 18:26:11 I'm just running "bitbake -e core-image-minimal" at this point May 21 18:26:38 how many multiconfigs May 21 18:26:39 ? May 21 18:26:56 1 multiconfig... counting laters, j/s May 21 18:27:03 *counting layers May 21 18:27:11 1 mc shouldn't do that May 21 18:27:27 I've done this with 8 May 21 18:27:54 We have poky + meta-gplv2 + all meta-openembedded + a few BSP layers May 21 18:28:18 that doesn't sound like 20 -> 500 MB May 21 18:28:24 Indeed. May 21 18:28:30 have you tried cleaning the cache out the way? May 21 18:28:33 Ya May 21 18:29:01 try dropping the layers, see if that helps? May 21 18:30:30 Ah, looks like it might be due to our egregious path lengths: May 21 18:30:35 $ strings bb_cache.dat.970655f7939278e71b469f38eab47355 | wc -c May 21 18:30:36 422344027 May 21 18:32:21 JPEW: I'm surprised/sad that has such a poor effect on our cache May 21 18:33:36 err, this also weird, it looks like the same file is showing up in multiple places that it doesn't exists in the cache May 21 18:34:05 JPEW: that is less unusual, we have to cache that we looked for a file which didn't exist May 21 18:34:17 (in case it exists next time) May 21 18:38:52 Ah, ok. I think this is compounding then, we have ~30 layers (which is *way* too many), long paths, and adding the multiconfig put it over the edge May 21 18:39:17 Oddly, without multiconfig the cache is only 99MB. I would have exepected it to only double with 1 multiconfig May 21 18:39:49 That is odd :/ May 21 18:43:14 kanavin_: new problem: https://autobuilder.yoctoproject.org/typhoon/#/builders/23/builds/850 :( May 21 19:07:21 Ok, something is definetly weird about mutilconfig parsing caching: https://pastebin.com/Kdck6UjX May 21 19:11:09 I'm seeing a problem where kernel-devsrc isn't including the arch/x86/include/generated/ . Specifically the file early_ioremap.h isn't found when doing a build on the target, which should be in arch/x86/include/generated/asm/early_ioremap.h. The file is in the source tree in the work directory on the host. Based on messages, it looks like this may have caused it? 52fd2993784b4218f5df4f343e7da45d964df305 I'm May 21 19:11:10 also having to go into the source directory and manually run "make -C tools objtool" May 21 19:22:58 rewitt: the build of objtool is expected. No binaries / tools are packaged in devsrc May 21 19:23:07 ok it looks like "make-mod-scripts_1.0" would fix the objtool problem? May 21 19:23:11 as for the missing header, we simply haven’t had anything that needed it yet, and hence it isn’t there. May 21 19:23:25 devsrc only includes needed files, therefore is lazy initialization. May 21 19:24:06 zeddii: What's the best approach then, a bbappend for kernel-devsrc? May 21 19:24:36 it depends. what are you building ? If it is common enough, and is only a header. We could take a patch to devsrc to add the header file. May 21 19:26:08 it's dpdk, but for "reasons" we're not using meta-dpdk, which of course wouldn't have the issue. May 21 19:26:59 specifically the igb_uio.ko module fails May 21 19:27:34 interesting. I don’t see that as an invalid use, so a patch would make sense. if you copy me (bruce.ashfield@gmail.com), I can grab it for my queue. May 21 19:28:01 zeddii: Ok I'll try to put a patch together for the list, thanks May 21 19:28:39 zeddii: Would you want only the necessary header files cherrypicked for this case, or go ahead and grab all of generated? May 21 19:29:29 was kicked out there. May 21 19:29:57 ok I'll repost: zeddii: Would you want only the necessary header files cherrypicked for this case, or go ahead and grab all of generated? May 21 19:30:23 just the one. we aren’t taking any else of it now, so I’d control the dependencies. May 21 19:30:36 zeddii: Ok got it, thanks May 21 19:30:59 it’s a slippery slope. May 21 19:31:20 we grab lots of generated files for the staging kernel dir, but not devsrc. May 21 19:31:52 rewitt: now that I think of it, I wonder if there’s a way to just regen it on target ? that would be more consistent. I just lost my chat history. what was the file again ? May 21 19:31:52 zeddii: I understand, it's a bit of a weird scenario too because nothing is actually generated, that header is checked into generated and just includes the asm-generic version May 21 19:32:13 zeddii, can we make perf use py3? May 21 19:32:56 zeddii: x86 is the only arch that has files checked into a generated directory as fars as I can tell, the other archs do not have a "generated" under include May 21 19:32:57 Crofton: .. probably ? I haven’t checked on it recently to see if all the parts are py3 safe. May 21 19:33:11 I shoudl remind you py2 is eol :) May 21 19:33:37 And stops me building images with only python3, if I install perf May 21 19:34:02 ah. my friend perf. May 21 19:34:36 rewitt: what was the header again ? I’m not seeing any generated directory in my 5.0 kernel tree. May 21 19:34:38 zeddii: The file was early_ioremap.h May 21 19:34:43 heh. thanks! May 21 19:34:46 I'm on 4.19.13 May 21 19:35:03 I suppose I should create a bug for that May 21 19:35:26 I recently found that perf looks for slang by check if /usr/include/slang.h exists..... this breaks cross-compiling if you don't have slang on the build host :( May 21 19:35:42 ouch May 21 19:35:48 perf is basically junk ;) and we force it to sort of cross build :D May 21 19:36:32 rewitt: ok. switching to 4.19. so this copy has to be safe for all kernels. Is this a stock 4.19 ?? May 21 19:36:36 The weird part about that is that there is AFAICT a pkg-config for slang, and the Makefile uses pkg-config for another package 2 lines later.... I think it's just an old anacronism May 21 19:37:54 There’s never anything non-wierd about perf’s build. May 21 19:40:06 zeddii: It's a preempty rt kernel, but it looks like I was wrong those files aren't in the tree. *bitten by a .gitignore* May 21 19:41:05 * zeddii has been there May 21 19:41:18 Is there any reason I wouldn't be able to use oe.utils.conditional when setting INHERIT? May 21 19:41:26 zeddii: It would then make sense to generate the headers on the target, not sure of the make command to do that. But, yeah it doesn't really make sense to put them in the devsrc since they are actually generated May 21 19:42:07 rewitt: that is the intention of the devsrc. If headers are typically generated, their dependencies are in the source we copy and then one of the targets (i.e. make prepare, etc) generate them. May 21 19:42:51 rewitt: but if it isn’t possible to generated them, it is also done that we copy both from ${B} and ${S} into devsrc, so it isn’t inconsistent to copy it if there’s no other way. May 21 19:43:02 zeddii: alright, I'll see if I can't figure out the target to generate that header file May 21 19:43:09 man, that sentence had a lot of typos May 21 19:44:04 rewitt: ping me as required. I’ll be stepping out in about 45 mins, but will be back again later in Eastern time. May 21 19:44:20 zeddii: Ok, thanks. May 21 19:48:19 Ah damn. To answer my own question, INHERIT is expanded by bitbake before base.bbclass is included and it's base.bbclass that imports all those nice helper functions May 21 19:57:01 zeddii: Looks like modules_prepare does everything I need, which completely makes sense. This is the first time I've ever built out of tree modules on the target. :-/ May 21 19:57:25 phew! that’s the easiest answer. glad it is working so far! May 21 19:58:53 Yeah, I like when the only thing not working is my brain :) May 21 19:59:37 naw. you notice that I had no doubts that something could be missing :D It is relatively complete, but there’s always something lurking. May 21 20:00:35 zeddii, bad news, on recent Fedora perf uses py2 May 21 20:01:17 hmm. we may have to blaze the trail here :D May 21 20:01:49 better news May 21 20:01:51 https://bugzilla.redhat.com/show_bug.cgi?id=1536656 May 21 20:01:52 Bug 1536656: was not found. May 21 20:03:00 yocti: shhhh May 21 20:03:01 zeddii: Error: "shhhh" is not a valid command. May 21 20:03:14 crofton. cool. May 21 20:03:16 * zeddii reads May 21 20:04:21 looks like we can switch then. If you assign the bug to me, I can look into it. May 21 20:04:31 OK, I'll do that in a bit May 21 20:12:54 Someone need's to implement "shhhh" for yocti May 21 20:22:48 hi rewitt! Nice to see you're still playing with yocto occasionally! :) May 21 20:24:41 RP: Only when they force me to ;) May 21 20:28:51 zeddii, https://bugzilla.yoctoproject.org/show_bug.cgi?id=13358 May 21 20:28:52 Bug 13358: normal, Undecided, ---, bruce.ashfield, NEW , perf depends on python2, this blocks creating python3 images May 21 20:33:21 rewitt: shame it has to be under duress but still good to see you :) May 21 20:34:44 RP: Its not really under stress. I'm just working on different things. I did meet with Paul, Ross and Tim though, and they said I should come back :) May 21 20:37:20 rewitt: we all miss you! :) May 21 21:20:22 anyone else seeing dependency loops with oe-core updates from today? May 21 21:21:26 rewitt: nice to see you back here May 21 21:22:38 my guess is that it's caused by "util-linux: Add missing ptest dependencies" May 21 21:23:04 JPEW: multiconfig does parse things n times, because it has separate taskdata objects so its expected to be slower, but it shouldnt be THAT slow May 21 21:24:03 aehs29: Ya, I would expect it to be 2 times slower and the cache to be 2 times bigger when adding 1 multiconfig... it appears to be about 5 times slower and bigger May 21 21:34:50 JPEW: yeah theres something fishy going on there May 21 21:35:02 I *think* I may have found it May 21 21:37:14 Ah, excellent May 21 22:02:30 JPEW: what was it? May 21 22:02:43 http://lists.openembedded.org/pipermail/bitbake-devel/2019-May/020028.html May 21 22:04:48 JPEW: awesome May 21 22:14:43 JPEW: nice find! :) May 21 22:15:14 JPEW: proves that optimisation is still somewhat useful! May 21 22:41:47 New news from stackoverflow: How to build Qt5 sdk in Yocto for Raspberry PI? May 22 00:42:08 New news from stackoverflow: SOME / IP kommunication with Yocto Linux meaning? **** ENDING LOGGING AT Wed May 22 03:02:00 2019