**** BEGIN LOGGING AT Tue Nov 20 02:59:58 2018 Nov 20 06:56:42 morning folks Nov 20 06:56:46 do we know when the linux-yocto 4.19 branches are coming up? Nov 20 07:18:15 New news from stackoverflow: Yocto: use static library of other recipe, Nov 20 08:30:02 LetoThe2nd: remember my question about `OVERRIDES` and `do_image_tar` yesterday? Turns out it was because of the chosen variable name (`STORAGEMEDIUM`). It breaks bitbake. Another name doesn't O.o Nov 20 08:37:20 T_UNIX: interesting indeed. but no idea why. if you are interested in the inner workings, you can of course grep poky for other uses of the expression "STORAGEMEDIUM" Nov 20 09:04:54 already did. No luck though :-/ Nov 20 09:10:34 I was wrong. Turns out that the (wrong) value that was set for `STORAGEMEDIUM`did apparently match something unintended. Nov 20 09:31:44 Hi, as I couldn't find any reference on this maybe you could give me a hint Nov 20 09:31:48 What is the point in having the LICENSE field set in image/packagegroup recipes? Actually it describes the license of the source code used for the respective package, but, for an image or packagegroup?.. Is this more than a 'we don't have anything better' default? Nov 20 09:51:12 I have a recipe that creates a user and its home directory, /home/user. I also want to create a second recipe that puts some other files in this users home directory, /home/user/somefiles. But when i try to build my image I get a conflict that both recipe A and B tries to install /home/user. Am I using the wrong approach or is there a way to handle this? Nov 20 09:55:03 BlauskaerM: have one create the user and the other DEPEND on it Nov 20 09:56:59 RP: Does DEPENDS and DEPEND hade the same meaning? I tried that but stille get the same error Nov 20 09:57:05 have* Nov 20 10:01:55 BlauskaerM: I mean DEPENDS sorry Nov 20 10:05:18 Hmmm... Will I always get this confligt if i try to install a file in a directory that was created by another recipe or is it because I try to make a new directory (install -d) inside /home/user from recipe B? Nov 20 10:06:40 BlauskaerM: I'm not sure, this does sound like an odd bug and something we should really have a test case for Nov 20 10:09:12 Dont know, get the feeling that its just me who dont really know how to handle things :P Nov 20 10:12:47 BlauskaerM: If we had a testcase it would also give you an example... Nov 20 10:13:32 Kind of new, where can I find the test-cases/examples? Nov 20 10:17:04 BlauskaerM: in this case it would probably be something in meta/lib/oeqa/selftest/cases Nov 20 10:24:16 RP: Found them. See if they can give me some insight Nov 20 10:24:27 Thanks for your time Nov 20 10:24:49 BlauskaerM: we don't have a test case right now, I'm just thinking/wishing we had Nov 20 10:26:28 ahaa Nov 20 11:19:05 New news from stackoverflow: Yocto project, try to add my device driver config into the Linux kernel configuration file Nov 20 11:49:10 New news from stackoverflow: How to setup an Yocto recipe to build from a local git source? Nov 20 11:58:46 RP: Seems to work if I just use mkdir -p /home/user and not install -d Nov 20 11:59:10 Is there a reason to use install instead of mkdir to make a directory Nov 20 11:59:10 ? Nov 20 11:59:47 Question goes to everyone Nov 20 12:51:16 BlauskaerM: that seems very strange as they should do the same thing Nov 20 13:04:03 RP: Yes I forgot to save one of the recepies -_- Nov 20 13:04:36 Same problem as before Nov 20 13:34:40 khem: not sure yet - i'm testing now - should know in a few more minutes Nov 20 14:05:31 khem: yes. Nov 20 14:07:26 beware that file://thumbdrive won't work - should be file:///thumbdrive. see https://en.wikipedia.org/wiki/File_URI_scheme Nov 20 14:24:54 BlauskaerM: I just wrote something to test what you're talking about, http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/t222&id=de3ed9f49fe255e72ac31b7a0d73656c54413529 works Nov 20 14:26:17 what recipe type (recipes-extended, recipes-support, etc) should the wxWidgets library be placed under? Nov 20 14:28:15 RP: Its almost the same situation. In my case I create the home directory in useradd-example (install -d 755 /home/user) and later tries to add a folder in the other recipe (install -d /home/user/somefolder) Nov 20 14:28:42 BlauskaerM: right, the same thing should apply though? Nov 20 14:29:01 BlauskaerM: are you saying it only breaks if its /home? Nov 20 14:29:28 Dont know tbh Nov 20 14:29:49 In the other recipe I do the same thing for /home/root and that seems ok Nov 20 14:30:08 Only seems to be problem with the "new" user Nov 20 14:30:32 Have to see what useradd-example does Nov 20 14:31:08 I use that as a template when creating the user but was some time ago so I forgot what it said Nov 20 14:31:19 Just a sec Nov 20 14:31:55 BlauskaerM: what FILES are you setting? Does it try and include /home/xxx or just the files under /home/xxx/ ? Nov 20 14:32:37 BlauskaerM: I just tried http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/t222&id=4b92d150322e07f098f7c5bd2300c058d953884d which also works Nov 20 14:34:24 I the recipe that adds the user I have FILES_${PN} += "/home/user" and in the other recipe I have FILES_{PN} += "/home/user/somefolder /home/user/somefolder/file1" Nov 20 14:35:57 BlauskaerM: that should be ok. rpm backend? Nov 20 14:36:48 BlauskaerM: I wonder if its because they have conflicting ownership on /home/user Nov 20 14:37:38 rpm backend, sorry dont know that. Is it important to know? Nov 20 14:38:24 file /home/user conflicts between attempted installs of recipe2.aarch64 and recipe1.aarch64 Nov 20 14:38:39 (I changed the names so its not exactly the same error message) Nov 20 14:39:32 But you're right. t222&id=4b92d150322e07f098f7c5bd2300c058d953884d applies to my situation.. Nov 20 14:39:53 Then it must be that im doing something crazy Nov 20 14:41:04 BlauskaerM: I mean in both cases is the ownership of /home/user really user:group rather than root:root Nov 20 14:41:37 BlauskaerM: I wasn't using rpm to test to I'm just rebuilding. rpm is a bit more picky about ownership Nov 20 14:45:14 BlauskaerM: I can't seem to make it break, sorry :/ Nov 20 14:46:51 I appreciate your effort. As I said, I know the problem is on my end so Im gonna remove some code and restart a little bit Nov 20 14:47:10 Your examples should be what I need Nov 20 14:48:37 BlauskaerM: Just noticed there isn't an RDEPENDS in my example. I'll fix that Nov 20 14:49:48 BlauskaerM: still worked... Nov 20 14:56:41 I think the difference is that I create /home/user in useradd-example and then tries to create the other directory /home/user/somefolder in useradd-example-depends Nov 20 14:56:48 Does that work for you? Nov 20 14:57:52 So in useradd-example i do install -d -m 755 ${D}/home/user1 and in useradd-example-depends I do install -d -m 755 ${D}/home/user1/somefolder Nov 20 14:58:53 And set FILES_${PN} += "/home/user1" in useradd-example and FILES_${PN} += "/home/user1/somefolder" in useradd-example-depends Nov 20 14:59:47 I migt be a little bit late to add this but Im using 2.4 Nov 20 14:59:54 If that makes any difference Nov 20 15:05:30 BlauskaerM: I tried that locally too :/ Nov 20 15:07:05 The h*ll im doing wrong :P Nov 20 15:08:34 Its time for refactor man Nov 20 15:14:58 Just one more thing. You might have said it before but if you do chmod -R user1:group1 /home/user1 in useradd-example and chmod -R user1:group1 /home/user1/somefolder in useradd-example-depends, it still works? Nov 20 15:15:15 sorry chown* Nov 20 15:15:22 In both commands Nov 20 15:25:55 BlauskaerM: yes, seemed to Nov 20 15:28:16 * BlauskaerM puts down his glases, buries hes face in his hands and screams a little bit Nov 20 15:40:06 RP: Will try again tomorrow, thank you very much for your time today Nov 20 15:51:50 BlauskaerM: might be an idea to try and build a test case like mine... Nov 20 16:06:50 RP: Get the same issue when I apply some changes to the examples to commited. I can send you a patch tomorrow if you have time and see if you get the same error Nov 20 16:34:25 rburton, kanavin: https://autobuilder.yoctoproject.org/typhoon/#/builders/27/builds/230/steps/7/logs/step1c :( Nov 20 16:47:13 i'm trying to create a recipe for wxwidgets (v3.0.4). their license is "wxWindows Licence" but apparently yocto doesn't know this license: WARNING: wxwidgets: LICENSE value "wxWindows Licence" has an invalid format - license names must be separated by the following characters to indicate the license selection: &|() Nov 20 16:48:45 yates: are you sure someone hasn't already written a recipe for that? Nov 20 16:48:57 https://hashrocket.com/blog/posts/vim-magic-with-abolish-vim - random, but any vim users that don't have this installed should fix that, cause it's fantastic Nov 20 16:48:59 i see it now Nov 20 16:49:04 (as are most of tpope's plugins, but still) Nov 20 16:52:18 coreutils_6.9.bb has LICENSE = "GPLv2+" but i don't see that file in poky/meta/files/common-licenses. how does that work? how do you map files in common-licents to .bb file license strings? Nov 20 16:52:56 i see the file WXwindows, which i guess is the wxwidgets license. so is that simply "WXwindows"? Nov 20 16:53:07 LICENSE = "WXwindows"? Nov 20 16:55:18 apparently the answer to my last question is "yes" Nov 20 16:55:55 yates: yes Nov 20 16:56:06 thank you RP! Nov 20 16:56:38 yates: I'm fairly sure someone has written a recpie for that before. Have you checked layers.openembedded.org? Nov 20 16:56:59 RP: don't have to, it's here in my project Nov 20 16:57:26 poky/meta/files/common-licenses Nov 20 16:57:36 yates: not license, *recipe* Nov 20 16:57:42 oh. Nov 20 16:57:48 yes, i did - only 2.9.5 Nov 20 16:58:16 and it looks like that version had some autoconf quirks. so i'm creating a new one. Nov 20 16:58:23 yates: still probably useful as a reference Nov 20 16:58:27 true Nov 20 16:58:42 * yates facepalms Nov 20 16:58:49 get the license out of there? Nov 20 17:00:36 yates: just an idea... Nov 20 17:01:07 * yates turns red Nov 20 17:05:33 is there a wx recipe? Nov 20 17:06:08 https://i.imgur.com/K4DB0ak.jpg Nov 20 17:06:34 for 2.9.5, whichis getting old now: https://layers.openembedded.org/layerindex/recipe/20507/ Nov 20 17:14:51 for a git SRC_URI, REV is the desired hash of the commit you want, right? Nov 20 17:15:00 SRCREV Nov 20 17:15:57 yes Nov 20 17:20:20 New news from stackoverflow: Yocto Bitbake VMWare Crashes Nov 20 17:59:50 hmm, oe-selftest wiki page is out of date. setting SANITY_TESTED_DISTROS = "" in local.conf does not work, and the default PREFERRED_PROVIDER_virtual/kernel won't do either, since it's linux-yocto for qemux86 Nov 20 18:02:58 kergoth: I'm sure our autobuilder sets SANITY_TESTED_DISTROS Nov 20 18:04:16 ../oe-core/meta/lib/oeqa/selftest/context.py Nov 20 18:04:16 190: if "SANITY_TESTED_DISTROS" in self.tc.td: Nov 20 18:04:16 191: self.tc.logger.error("Please unset SANITY_TESTED_DISTROS in order to run oe-selftest") Nov 20 18:04:31 which sets the exit code to 1, which fails the tests Nov 20 18:04:33 afaict, anyway Nov 20 18:04:40 * kergoth shrugs Nov 20 18:06:26 kergoth: https://autobuilder.yoctoproject.org/typhoon/#/builders/28/builds/242/steps/7/logs/stdio - sets SANITY_TESTED_DISTROS = '' Nov 20 18:07:05 kergoth: I'm guessing empty vals don't make the d -> td transition Nov 20 18:07:12 which is accident rather than design Nov 20 18:41:22 RP: https://8n1.org/14048/3f99 Nov 20 18:41:36 thats latest master-next Nov 20 18:42:08 khem: RP already reported it to the author Nov 20 18:42:43 http://lists.openembedded.org/pipermail/openembedded-core/2018-November/276258.html Nov 20 18:42:48 JaMa: ok, Nov 20 18:43:03 oh so it is not revertable ? Nov 20 18:43:16 I thought it was still hanging in master-next Nov 20 18:45:35 ah curl still went in Nov 20 19:36:48 khem: I haven't reported the nativesdk issue, only a different one Nov 20 19:37:00 khem: curl had an issue? :/ Nov 20 19:37:57 RP: I reported that it regresses recipes in meta-oe Nov 20 19:38:42 for once when the build finished in time Nov 20 19:39:27 khem: I see the email, somehow I missed this :( Nov 20 19:39:36 khem: sorry :/ Nov 20 19:40:23 no worries, usually its good to hold such patches for sometimes so we can sync the changes Nov 20 19:41:18 khem: I do for a while but usually once all the tests pass there isn't any followup :( Nov 20 19:41:26 anyone else seeing postgresql failing to build since last oe-core/sumo update? Nov 20 19:42:54 khem: will try and do better Nov 20 19:42:59 RP: I regress master-next with meta-openembedded and bunch of other layers which is a good test for oe-core especially libs Nov 20 19:43:13 khem: yes, agreed Nov 20 19:43:41 khem: I'm working towards resorting out the autobuilder targets too Nov 20 19:45:01 right now my build round trip is in excess of 24 hrs Nov 20 19:45:11 thats way more than oe-core Nov 20 19:45:48 but I am hoping to improve with some new CPUs that Tom is on lookout one of builder is become better Nov 20 19:46:11 khem: I'm wondering if we can have some basic tests on the main ab Nov 20 19:46:28 Sure that will be good, if AB has cycles Nov 20 19:55:58 khem: working on it :) Nov 20 20:02:21 i'm getting stuck on this recipe at the fetch stage: https://paste.fedoraproject.org/paste/i9E-ATTKOfalab6TkBTu0g Nov 20 20:02:41 here's the recipe (so far): https://paste.fedoraproject.org/paste/t-8KL~lsKd8-y3NNWFsfVg Nov 20 20:03:52 if i specify the hash, then isn't the branch irrelevent? so master should be fine? Nov 20 20:10:09 can anyone take a look please? Nov 20 20:11:03 yates: Specifying the branch can reduce the amount that has to be cloned from the server Nov 20 20:11:40 yates: SRC_URI[sha256sum] is not necessary for a git fetch Nov 20 20:11:41 i have that repo cloned in a separate directory - how can i find the has for a specific tag? Nov 20 20:11:57 ok Nov 20 20:18:14 Hey - are there "devel" packages available in yocto for installing libraries and headers? Nov 20 20:23:22 cslcm: There are -dev packages Nov 20 20:24:24 yates: FYI you probably need to do: S = "${WORKDIR}/git" Nov 20 20:24:27 i'm trying to find one for gstreamer but i can't see any listed Nov 20 20:24:53 cslcm: Where are you looking? Nov 20 20:25:08 https://layers.openembedded.org/layerindex/branch/master/recipes/ Nov 20 20:25:56 cslcm: Ah, they aren't going to show up there... the recipes create the -dev packages Nov 20 20:26:15 ah, so i can just add -dev to a recipe name? Nov 20 20:26:17 maybe? Nov 20 20:26:37 cslcm: Thats the default, so most of the time, yes :) Nov 20 20:27:35 JaMa: still here? Nov 20 20:50:13 JPEW: any idea about gtk+-dev which doesn't seem to exist Nov 20 20:52:17 cslcm: the layer index search recipes, not packages. Nov 20 20:52:27 dev packages are split off by default, for everything Nov 20 20:52:32 as part of the build process Nov 20 20:52:39 you're t alking about runtime, but this is a build tool Nov 20 20:52:59 i need to develop an application on the target device Nov 20 20:53:14 i've found -dev recipes for most of what i need but not for gtk+ Nov 20 20:53:16 again, every recipe splits off development files into a -dev package by default Nov 20 20:53:20 it's not a separate recipe Nov 20 20:53:31 the regular gtk recipe emits -dev packages, just like everything else Nov 20 20:53:33 right but gtk+ is found by yocto and gtk+-dev isn't Nov 20 20:53:40 maybe the plus is an issue? Nov 20 20:53:40 "found by yocto" makes no sense Nov 20 20:53:53 JPEW: the tag i'm interested in is not associated with any branch. Nov 20 20:53:55 yocto is an umbrella project that encompasses many tools, including bitbake+oe+poky, which is used to build distros Nov 20 20:54:00 i know Nov 20 20:54:17 cslcm: describe what you did and the messages you received Nov 20 20:54:51 added gtk+ and gtk+-dev to IMAGE_ISNTALL_append, ran the build, it said nothing provides gtk+-dev Nov 20 20:54:57 excuse the typo Nov 20 20:55:09 yates: That is.... strange. Not impossible, but strange. Nov 20 20:55:51 cslcm: that is very odd... the gtk+ recipe clearly does define an ${PN}-dev package Nov 20 20:57:06 JPEW: "git branch --contains v3.0.4" reports nothing. Nov 20 20:57:20 so apparently that is the case here. Nov 20 20:57:41 cslcm: yep just tried it here, adding gtk+-dev to an image did not give me such an error Nov 20 20:58:05 cslcm: can you paste your *exact* IMAGE_INSTALL_append line? Nov 20 21:00:19 where is the git fetcher? Nov 20 21:00:33 yates: bitbake, as with all the fetchers Nov 20 21:00:33 i'm coming up with nothing here.. Nov 20 21:00:51 kergoth: you mean it's internal to bitbake? not a class anywhere/ Nov 20 21:00:53 ? Nov 20 21:00:55 yes Nov 20 21:01:06 piddle Nov 20 21:01:13 https://github.com/openembedded/bitbake/blob/master/lib/bb/fetch2/git.py Nov 20 21:14:52 i'm completely stumped. i'm not good enough at python to read that, but thanks kergoth. i tried. Nov 20 21:15:45 yates: did you try git branch -r --contains v3.0.4 ? Nov 20 21:16:00 why NOT?!?!? ERROR: wxwidgets-3.0.4-r0 do_fetch: Fetcher failure for URL: 'git://github.com/wxWidgets/wxWidgets.git;protocol=https;tag=v3.0.4'. Unable to fetch URL from any source. Nov 20 21:16:16 yates: if the tag really isn't on any branch then use ;nobranch=1 Nov 20 21:16:20 it's actually fairly common for a tag to not be contained by any branch. it's not good practice, but common. not everyone merges back the version bumps into mainline Nov 20 21:16:30 which tends to break git-describe, etc Nov 20 21:16:42 irritating Nov 20 21:16:49 bluelightning: ok, lemme try that Nov 20 21:18:54 bluelightning: no, i did not, and that worked. https://paste.fedoraproject.org/paste/v0oVC5ParjTs3h-QwYgfDw Nov 20 21:19:49 but.. the nobranch=1 worked. got past the fetch stage. only took 3 hours... Nov 20 21:20:00 ok, so I guess branch=WX_3_0_BRANCH is what you really want there Nov 20 21:20:25 but without specifying a branch, nobranch=1 worked Nov 20 21:20:35 do i really need the branch? Nov 20 21:20:43 right, that is an alternative Nov 20 21:20:45 FYI, devtool upgrade will take care of this kind of stuff for you Nov 20 21:21:37 doesn't devtool upgrade require an old recipe to work with? Nov 20 21:22:06 i didn't want to use the old one - it seemed to have some autotools tweaks that i don't think are necessary any longer. Nov 20 21:22:09 You can't upgrade nothing to something :) Nov 20 21:22:11 ah ok I figured you were upgrading the old one, nm Nov 20 21:22:40 Crofton: no kidding :D Nov 20 21:22:41 no, np - thanks for the help and ideas Nov 20 21:23:08 :) Nov 20 21:23:20 Crofton: Billy Preston says "Nothing from nothin' leaving nothin'"... Nov 20 21:25:47 s/says/said/ Nov 20 21:32:43 would it be that hard to give a github url and a tag or hash to devtool and just let me create a brand new recipe??? Nov 20 21:32:57 s/let me/let it/ Nov 20 21:33:44 "devtool create-github-recipe ..." ? Nov 20 22:03:24 yates: doesn't devtool do that already? Nov 20 22:05:59 yates: also why not just use https://github.com/wxWidgets/wxWidgets/releases/download/v3.0.4/wxWidgets-3.0.4.tar.bz2 Nov 20 22:07:00 i prefer fetching tarballs if possible: faster, easier to mirror, and checksummable Nov 20 22:07:26 fwiw $ recipetool create git://github.com/wxWidgets/wxWidgets.git -B WX_3_0_BRANCH -S v3.0.4 appears to be doing the right thing Nov 20 22:07:37 you do need to know what branch/tag Nov 20 22:17:31 rburton: which version of recipetool are you using? mine does not have a -B or a -S option Nov 20 22:17:43 thud Nov 20 22:17:51 devtool should be used instead but i was being lazy Nov 20 22:18:03 but just using that tarball solves all the git woes Nov 20 22:18:26 (the git fetcher likes to sanity check the sha/branch to be sure you know what you're asking for) Nov 20 22:20:43 i'm past my git woes NOW. i guess that's good to know for the future.. Nov 20 22:21:08 also, it seems like a git repo is more reliable than a tarball Nov 20 22:21:15 other way around imho Nov 20 22:21:31 tarball was generated by the maintainers to be built, doesn't change, has checksums Nov 20 22:21:36 reliable in the sense that it'll be there and be the same tomorrow and in 5 years. Nov 20 22:21:43 ha haahahahhaha Nov 20 22:22:02 you're aware we have a fork of distcc because upstream literally deleted the release tag we were using? Nov 20 22:22:22 at least for tarballs, they'll be in the source mirrors Nov 20 22:22:25 well, no Nov 20 22:23:20 both suck if the maintainers do something stupid, or just disappear Nov 20 22:23:42 at least a known tarball with a known checksum can be found in someone's disk and put online again Nov 20 22:23:43 yeah, or we have a nuclear war Nov 20 22:24:20 rburton: could you not say the same about a repo? Nov 20 22:24:29 fewer people have a complete clone to hand Nov 20 22:24:44 you mean a bare repo? Nov 20 22:25:03 or you mean they don't regularly pull? Nov 20 22:25:14 its just easier to share around a tarball, it's just a single file Nov 20 22:25:27 anyway its late! Nov 20 22:25:39 exit, stage left! Nov 20 22:25:54 gotta run Nov 20 22:27:10 just joking.. Nov 20 22:29:43 is there an "inherit" for source that already has a ./configure, so that you can bypass the autoconf/etc. steps? Nov 20 22:30:35 "inherit autotools" runs autoconf and that seems to be hosing things Nov 20 22:31:03 or do i just implement my own do_compile() in that case? Nov 20 22:38:35 yates: we run autoconf for a reason Nov 20 22:44:37 RP: I see 1e8623ce6b7 ("poky.conf: Add MACHINE to SDK_NAME")... I ran into a similar problem while building SDKs for MinGW and worked around it locally by adding ${SDK_OS} to SDK_NAME Nov 20 22:44:58 It starts making the SDK name really long to add all those in :) Nov 20 22:46:31 JPEW: yes, there has to be a better way :/ Nov 20 22:48:22 RP: why? Nov 20 22:49:18 is it because we are cross-building instead of natively building? Nov 20 22:49:43 yates: basically yes, make sure all of our tweaks take effect and it cross builds well Nov 20 22:51:15 "cross-compiling is hard" - Sun Tzu Nov 20 23:29:39 I am trying to run devtool modify gcc but it errors out with the following message: Nov 20 23:29:39 ERROR: Task do_patch does not exist for target gcc (..../meta/recipes-devtools/gcc/gcc_8.2.bb:do_patch). Close matches:do_fetch Nov 20 23:29:39 Is this the right way to call gcc with modify ? Nov 20 23:30:30 * ERROR: Task do_patch does not exist for target gcc (..../meta/recipes-devtools/gcc/gcc_8.2.bb: do_patch). Close matches: do_fetch Nov 20 23:41:25 gcc sources are provided by gcc-source recipe Nov 20 23:46:35 I tried with devtool modify gcc-source_7.3 and it errors as well. the error i see is ERROR: Unable to find any recipe file matching "gcc-source_7.3" Nov 20 23:49:28 halstead: the non-release structure on pub on the autobuilder is horrible, I'm tweaking it to better match the other releases. We may need to clean up pub Nov 20 23:51:23 chandana73: it's devtool modify gcc-source-7.3, not _7.3 Nov 20 23:57:10 @kergoth: I tried that as well and i get the same error of unable to find any recipe file matching gcc-source-7.3 Nov 21 00:01:46 sounds like you want 8.2 then, if you're looking at gcc_8.2.bb Nov 21 00:26:14 I tried it with 8.2 version as well and im seeing same errors similar to 7.3 Nov 21 01:12:51 the omxplayer recipe won't build :( "SubtitleRenderer.cpp:43:3: error: conflicting declaration 'typedef struct EGL_DISPMANX_WINDOW_T EGL_DISPMANX_WINDOW_T' Nov 21 01:12:51 | } EGL_DISPMANX_WINDOW_T;" Nov 21 01:54:49 filed against meta-raspberrypi https://github.com/agherzan/meta-raspberrypi/issues/336 Nov 21 01:55:44 cslcm: are you building with meta-rpi master ? and secondly are using vc4graphics Nov 21 02:02:39 khem: I was building with master, i've reverted to the commit before that vc4 patch now and it's working. As for vc4graphics - I don't think so. Should I be? Nov 21 02:03:11 is it better than the binary blobs? Nov 21 02:13:23 i'm using wpe-framework in a very demanding application so i need all the performance i can squeeze out of it Nov 21 02:37:49 @khem: actually when I enable MACHIONE_FEATURES="vc4graphics", the omxplayer recipe is excluded due to an "incompatible host" **** ENDING LOGGING AT Wed Nov 21 02:59:58 2018