**** BEGIN LOGGING AT Tue Jul 12 02:59:58 2016 Jul 12 04:18:21 q Jul 12 08:55:06 bitbake does not support hg:// URLs in SRC_URI, right? Jul 12 08:57:30 I get ExpansionError, failure expanding variable SRCPV, MissingParameterError: URL 'hg://...' is missing the required parameter 'module' Jul 12 09:05:11 the docs say it is supported, but I had the same issue with svn, you just have to specify a module (the trunk or a branch generally) Jul 12 09:06:37 mathieu_la: SRC_URL="hg://...;module=mymodule", right? Jul 12 09:06:57 yes Jul 12 09:07:17 Ok, so it's a reference to hg, not to something in oe? Jul 12 09:07:25 i.e. a branch? Jul 12 09:07:42 yes it's about what is in your tree Jul 12 09:08:19 in my case I directed the url to the top folder and module=trunk Jul 12 09:34:50 how do I restart building a recipe from the beginning? Jul 12 09:39:03 what do you mean? you can clean the building of recipe with "bitbake -c cleansstate " Jul 12 09:40:05 bitbake [recipe] -C unpack will tell it to do a build and force unpack to happen, so it does a full build Jul 12 09:41:45 I'm learning yocto, and are bringing up a recipe for the first time, so please be patient with me. I'm reading the man, but there's a lot of new concepts to take in Jul 12 09:41:56 or -c rebuild (I think) Jul 12 09:42:20 lewiatan: bitbake -c cleanslate resulted in "task do_clean slate does not exist for target" Jul 12 09:42:37 -c cleanall should clean everything (including the downloading part) Jul 12 09:42:47 it's cleansstate, not cleanslate Jul 12 09:42:51 it is "cleansstate" Jul 12 09:43:06 bah :P Jul 12 09:43:31 and of course after that you need to start recipe again with "bitbake " Jul 12 09:44:04 the derivation of cleansstate is "clean shared state", where "shared state" if often shortened to "sstate" Jul 12 09:44:30 the top-step nature of clean then build is why I endorse -C unpack, as its a single command Jul 12 09:57:25 rburton: but does "-C unpack" clean/remove old build directory? I personally use bash function for that that first: does cleansstate or cleanall and second: builds the recipe that was just cleaned Jul 12 10:07:11 Hi. If I change only the URL in a recipe because it changed on the server, will that trigger a rebuild of the package? Jul 12 10:11:32 hi, I may have asked this three years ago when coming to Yocto, so pardon me, but can you remind me again why the branch has to be specified properly when using SRCREV to work? I thought the hash identifier was unique. Jul 12 10:27:15 what is the advantage over sandboxing recipes with devtool, rather than doing the same thing in-tree? Jul 12 10:34:59 if I specify SRC_URI="file://" does it copy the files before building them? Does it build it in-source? Jul 12 10:53:31 I trying to run bitbake-layers show-layers (while reading the dev. manual). I then get: ERROR: Only one copy of bitbake should be run against a build directory Jul 12 11:05:13 lewiatan: if your using autotools or cmake then the build directory is always removed before a build, so "it depends" Jul 12 11:05:33 lpapp: iirc its basically a sanity check Jul 12 11:05:52 ok. thanks rburton Jul 12 11:06:36 lpapp: you can disable the sha-is-on-branch check if you have to grab a srcrev which isn't on any branch Jul 12 11:08:54 lpapp: looks like bitbake a9112a introduced the check Jul 12 11:09:47 rburton: right, so I was going to try removing the branch specification whether the SRCREV would work on its on then. Jul 12 11:10:11 when both specified, in our Yocto version, the branch takes precedence, apparently. Jul 12 11:10:36 is that a very old bitbake? Jul 12 11:11:08 with SRCREV=abc and branch=foo you should be unpacking rev abc on branch foo, or erroring Jul 12 11:11:49 rburton: daisy Jul 12 11:14:52 Can I get bitbake to show all the commands only pertaining to one receipe? Jul 12 11:15:06 sveinse: bitbake -e [recipe]? Jul 12 11:15:19 sveinse: do you mean what it will run for a particular task? Jul 12 11:15:59 In my recipe bitbake -C unpack does not work. It apparently does not start over. It says task do_unpack does not exist, and then it start to compile Jul 12 11:16:34 no unpack is quite unusual Jul 12 11:17:05 might be worth trying -C do_unpack just in case there was a bug in an older version :) Jul 12 11:17:43 This being a qt application, I have a custom do_configure() section which runs qmake, but I cannot find any output showing me that it has run qmake. This is why I want to start over Jul 12 11:18:19 there are classes to do qmake for you Jul 12 11:19:28 I use require recipes-qt/qt5/qt5.inc, which is what our subcontractor did for a similar qt application Jul 12 11:19:38 and that would be why nothing works Jul 12 11:20:01 Then I don't understand why the other qt app works... hmm Jul 12 11:20:10 is your app qt5? Jul 12 11:20:23 yes Jul 12 11:20:30 https://github.com/meta-qt5/meta-qt5/blob/master/recipes-qt/tufao/tufao_1.2.1.bb is fairly simple Jul 12 11:20:41 basically, inherit cmake_qt5 if its using cmake with qt5 bits Jul 12 11:20:56 or https://github.com/meta-qt5/meta-qt5/blob/master/recipes-qt/qsiv/qsiv_1.1.bb if its using qmake Jul 12 11:21:13 all you *need* is the meta-qt5 layer, inherit qmake, and you're done Jul 12 11:21:19 erm, inherit qmake5 Jul 12 11:21:48 the only reason to inherit qt5.inc is if you're writing a qt5 recipe Jul 12 11:22:11 so i'd have a moan at your contractor :) Jul 12 11:22:14 Now I'm actually even more confused. How can this other app work then... Jul 12 11:22:33 Yes, it seems I have to Jul 12 11:22:41 well, qt5.inc isn't going to tragically break the recipe, its just stupid Jul 12 11:22:55 share their recipe if you'd like a review done of it :) Jul 12 11:22:56 This is one of the reasons I'm/we're learning yocto now Jul 12 11:24:23 if you're using a fairly recent yocto, then the recipetool command is great at writing starting points for recipes Jul 12 11:24:27 I've been doing embedded linux systems for many years, but yocto is somewhat a handsful I'd admit Jul 12 11:24:52 So pardon me for asking stupid and basic questions :D Jul 12 11:24:55 just do recipetool create [some uri] and it will write a starting point Jul 12 11:25:05 no need, that's what this channel is for :) Jul 12 11:30:09 I have some login issue with krogoth, it seems that 20 char passwords do not work (8 char works) Jul 12 11:30:54 I found some related issues with tinylogin (now part of busybox), how do I check if I'm using it? Jul 12 11:31:23 can I get bitbake to output everything for a specific recipe or step (do_configure) while running bitbake? Jul 12 11:33:40 sveinse: bitbake -e recipe will have the shell in the output if you grep it, or go to the work dir and eg temp/run.do_configure has the full script that runs Jul 12 11:34:55 whoah, that was verbose Jul 12 11:35:04 yeah pipe though less ;) Jul 12 11:35:18 you did say "everything" ... Jul 12 11:36:45 well, I still haven't found the output I'm looking for, so yes, my bad: I meant the execution of the task, which would be running qmake and getting its output in this case Jul 12 11:38:26 the output would be in temp/log.do_configure Jul 12 11:38:46 run.do_configure will have you running qmake, unless what you're doing is not working Jul 12 11:38:54 as i said, just inheriting the right qmake5 class should do everything for you Jul 12 11:39:00 for actual help, share the recipe Jul 12 11:40:58 firstly, bitbake -e did not run qmake output. Secondly, I have added qmake5, and I saw some configure output, so I think its working. Lastly, I will share it Jul 12 11:41:14 Do you always use the tmp/ log output for output? Isn't that tedious? Jul 12 11:43:18 mine is in tmp/work/cortexa9-vfp-neon-poky-linux-gnueabi/mypkg/1.0-r0/temp/log.do_configure which is a handsfull Jul 12 11:45:21 well, that's the output from running what you told it to do Jul 12 11:45:44 personally i use "bb" to see logs easily Jul 12 11:45:53 github:kergoth/bb Jul 12 11:46:10 "$ bb log mypkg configure" is a lot easier Jul 12 11:47:04 rburton: aha, right! I would think that using this very long path would seem to tedious Jul 12 11:47:42 what in the recipe controls where it is built: I have tmp/work: all-poky-linux, cortexa9hf-vfp-neo-poky-linux-gnueabi, cortexa9hf-vfp-neo-mx6qdl-poky-linux-gnueabi and so on? Jul 12 11:47:42 looks like I'll have to add another repo in my installation, this seems really handy Jul 12 11:49:22 sveinse: your machine and its tune controls where it ends up Jul 12 11:53:57 Is it difficult to write an image recipe? We have a custom image format that we ultimately will have to integrate with yocto Jul 12 11:58:59 I notice that the log.do_configure does not contain the command it executes, only its output. Is that possible to read somewhere? Jul 12 12:00:17 Yes.... run.do_configure Jul 12 12:00:50 This logging scheme is apparently going to take some getting used to... Jul 12 12:01:43 hm there is a way to get the sh output in the logs Jul 12 12:01:53 tbh, probably sensible to enable that Jul 12 12:03:09 is yocto always building in-source? Jul 12 12:04:27 up to the recipe (or class, really). autotools and cmake default to out of tree Jul 12 12:04:44 if qmake does in tree but its trivial to make it out out of tree then it should be fixed to do that Jul 12 12:04:45 qmake as well? do you know? Jul 12 12:05:05 my knowledge of qt is limited at getting it out of oe-core and into other layers so i don't need to care about it Jul 12 12:05:34 we have always built qt, qmake qt apps, linux kernel out of tree, so yes, its possible Jul 12 12:09:37 is it possible to temporarily disable parallel builds, or do I need to edit my local.conf to do it? Jul 12 12:11:57 PARALLEL_MAKE = "-j 1" bitbake [recipe] should override it I guess Jul 12 12:12:42 (without spaces of course) Jul 12 12:13:39 mathieu_la: heh, yeah. shell parsing is different that bb rules ;) Jul 12 12:17:58 hmm. I've changed SRC_URI, and bitbake -C unpack does not do much Jul 12 13:10:36 How do I reset everything pertaining to a recipe? That is delete states, output, everything? Jul 12 13:22:27 bitbake -c cleansstate erase every output, but does not redownload the code when SRC_URI has changes. bitbake -C unpack does not have any impact Jul 12 13:26:05 -c cleanall will also delete from DL_DIR, so forcing you to re-download the tarball Jul 12 13:26:25 of course you only need to do that if you changed the tarball and need to re-fetch it Jul 12 13:27:20 rburton: Its hg src repo, not a tarball Jul 12 13:28:50 ah, you want to set SRCREV to ${AUTOREV} so it will fetch and incorporate updates on every build Jul 12 13:30:32 rburton: actually I'm stuck further behind than that: I created a recipe based on a file location using devtool, and I've later edited SRC_REV to point to the upstream code. Now, I've deleted my local file location, but I just can't get it to take. Jul 12 13:31:05 even running bitbake -c cleanall, and then rerunning the recipe, it wants to configure the old now gone directory.... Jul 12 13:31:27 There is some state stuck here somewhere Jul 12 13:32:32 sveinse: likely something wrong with the recipe, can you share it? Jul 12 13:32:48 which paster? Jul 12 13:33:01 anyone Jul 12 13:33:35 (some channels ban you if you pick the wrong one :P ) Jul 12 13:34:42 https://bpaste.net/show/f4899bb3a29c Jul 12 13:38:58 sveinse: you likely need to set S (where the sources have ended up). it defaults to ${WORKDIR}/${PN}-${PV}, which works for 99% of tarballs but i doubt it works for this Jul 12 13:39:29 no idea what directories the hg fetcher uses, for git you need to use S="${WORKDIR}/git" Jul 12 13:39:35 rburton: yes, let me try that Jul 12 13:40:03 also you can remove section and homepage, and hopefully paralllel_make - fix your app instead :) Jul 12 13:41:38 rburton: Oh, the parallel_make is because I know it does not compile, and I'd like to view the cause without other interleaving msgs. It will be gone :D Jul 12 13:42:05 heh fair enough :) Jul 12 13:44:39 btw, perhaps hg support is dodgy. I see no effort trying to clone with hg anywhere. Jul 12 13:44:46 As a development effort, is it possible to configure SRC_URI such that it will copy it from a local location, not just use it directly? Jul 12 13:46:50 for the general situation where you want to use a local clone instead of the canonical upstream, then yes you can use the externalsrc class. Jul 12 13:47:23 aahhhhh and d'oh: devtools crates workspace/appends/myapp.bbappend where it sets EXTERNALSRC and co! Jul 12 13:47:28 the hg fetcher is definitely less used than the others Jul 12 13:49:08 well our company use hg (after having a serious comparison between hg and git a few years back). Hg won due to better windows support at the time. Boy, I regret that we did so! Jul 12 13:51:59 :) Jul 12 13:56:10 I can delete the whole .bbappend file when it only contains EXTERNALSRC and EXTERNALSRC_BUILD right? Jul 12 13:57:51 if you dont want those yeah Jul 12 13:58:17 why is devtool splitting the recipe like this? Jul 12 13:58:42 Took me a few hours to find it :( Jul 12 13:58:51 armpit: would you be willing to take 9383 then? Jul 12 13:59:12 sveinse: because the appends are not needed in the recipe and shouldn't be accidently committed Jul 12 14:00:13 So it will override the official SRC_URI and enable one to work local only before going to the real deal, right? Jul 12 14:05:20 not before, instead of Jul 12 14:06:13 it didn't work. I commented out the lines in the .bbappend file, but it still does not fetch the sources after -c cleanall :( Jul 12 14:07:51 bitbake -C unpack also had no effect Jul 12 14:07:59 to be honest, I Jul 12 14:08:11 I'm giving up soon... Jul 12 14:08:40 just delete the bbappend to be sure its gone Jul 12 14:12:48 rburton: That seemed to work, its now fetching mercurial host tools. Commenting the bbappend file wan't enough for some reason Jul 12 14:13:56 should have been, but working now Jul 12 14:18:29 next complication: SRC_URI fails if it looks like this "http://dkhg.local/hg/QtApp" as its missing module, but hg clone fails if it looks like this "http://dkhg.local/hg/QtApp;module=default" Jul 12 14:18:39 Is there another way to specify the module? Jul 12 14:19:24 why does the clone fail? Jul 12 14:19:27 literally never used hg Jul 12 14:20:21 It sais "http://dkhg.local/hg/QtApp;module=default" is not a valid URL for a hg repo Jul 12 14:20:35 oh Jul 12 14:20:36 It smells like a parsing bug in bitbake Jul 12 14:20:40 what's your SRC_URI? Jul 12 14:20:45 the above Jul 12 14:20:54 its not, as neither of those say hg:// Jul 12 14:21:24 Sorry, manual typeout error, it sais hg:// Jul 12 14:22:55 yeah might be a bug in the fetcher. bitbake/lib/bb/fetch2/hg.py, probably _buildhgcommand() is a good place to start Jul 12 14:23:53 darn, the lake is deeper than I'd hoped it would be it seems :( Jul 12 14:25:17 Can you do a "URL;name=foo" and SRC_URI[name.module=... Hmm, no because name would interfer Jul 12 14:26:29 it looks like its expecting SRC_URI=hg://host.name/path;module=modulename Jul 12 14:26:48 and shuffles that into the relevant command line Jul 12 14:29:00 khem: thanks Jul 12 14:29:37 rburton, 9383 sure Jul 12 14:39:56 armpit: can you take ownership then, thanks Jul 12 14:40:42 np Jul 12 15:15:00 I'm trying to make a clean build (ie new build directory) of daisy. However my host system uses arch which has long since switched to gcc 5.x and then 6.x as the default compiler. Can I tell poky to use say, gcc-4.9 instead? Jul 12 15:16:30 I've tried symlink-hacking gcc to be 4.9, but that's not enough, likely because I still get newer versions of other parts like the standard library(?) Jul 12 15:18:37 Is it possible to run bitbake without the "interactivity" where it updates the console, but rather print every task it executes? Jul 12 15:20:24 pipe to cat is the easy way Jul 12 15:21:03 simonl: set BUILD_CC etc Jul 12 15:21:38 simonl: http://pastebin.com/hjJnvGBU <— from my local.conf from when i was testing gcc5 on my host Jul 12 15:22:34 rburton: awesome, I'll give that a try! Jul 12 15:26:33 I'm finally getting this compilation going! Jul 12 15:27:10 How do you access host tools? Use inherit for them? Jul 12 15:27:27 Anyone with any example references for it? Jul 12 15:28:46 sveinse: just use them Jul 12 15:28:54 they're still on the path Jul 12 15:29:12 Apparently not: protoc command not found Jul 12 15:29:19 where is it on your host? Jul 12 15:29:28 path does get reset a bit Jul 12 15:31:52 if thats protobufs then theres a recipe in meta-oe you can depend on to built the binaries natively Jul 12 15:33:28 rburton, yes, It's in meta-oe/recipes-devtools/protobuf/, so I assume it hasn't been built yet. Hence I lack a dependency or something? Jul 12 15:33:32 yes Jul 12 15:33:42 DEPENDS=protobuf-native Jul 12 15:34:08 rburton: thanks! Jul 12 15:36:19 rburton: isn't it protobuf-compiler-native? Jul 12 15:36:43 In order to get protoc Jul 12 15:36:52 yeah maybe :) Jul 12 15:36:56 never used it Jul 12 15:37:00 sveinse: ^ Jul 12 15:37:24 I recetnly spent one day fighting with that until I realized it was in protobuf-compiler :) Jul 12 15:40:32 Do I need to do something when I change DEPENDS statements? It seems none of the above proposals work Jul 12 15:42:59 simonl: if you want to build daisy with gcc5, I do have a set of patches that will let you do that. Jul 12 15:50:14 Apparently I need to run something for it to parse DEPENDS changes. I'm running toaster, and it shows no depends on other packages Jul 12 15:51:48 How can I restrict a native recipe so that it can be only build on x64 machines? Jul 12 15:52:08 I was told to use COMPATIBLE_MACHINE some days ago, but all the examples I see use that for restricting the TARGET machine Jul 12 15:57:42 billr: that'd be nice! Jul 12 15:57:49 simark1: ^ I can't get it to build protoc... Jul 12 15:58:28 simonl: send me a PM with your email address Jul 12 15:59:07 learner: what if the build host is something else? Jul 12 16:00:21 when do you use DEPENDS="something" and DEPENDS+="something" ? Jul 12 16:00:43 How do you know which one to use? Jul 12 16:05:38 If I run bitbake protobuf-native manually first, then my build continues. Its apparently that my depends haven't been reread Jul 12 16:09:09 are you using memory-resident bitbake? Jul 12 16:09:23 (oe-init-buildenv-memres) Jul 12 16:12:50 rburton: just refuse to build, show an error Jul 12 16:12:58 the recipe won't work in no x64 machines Jul 12 16:14:25 How do I modify $PATH on a per-task basis? I'd like to write a function that adds entries to $PATH depending on what BB_TASKDEPDATA contains. Jul 12 16:15:40 neverpanic: not sure you can Jul 12 16:15:48 yeah, that's what I feared Jul 12 16:16:09 Unfortunately the other solution would be building a native sysroot for each task with its dependencies, and that's also pretty cumbersome Jul 12 16:18:07 we really should implement support for per-recipe sysroots based on its deps one of these days, it should be doable Jul 12 16:18:19 but in theory the PATH thing should be possible, i think a prefunc could modify the env and affect the main task.. not sure, though Jul 12 16:18:28 also i haven't had my caffeine yet, so .. Jul 12 16:19:05 The problem with per-recipe native sysroots is that you configured that piece of software for a certain prefix, so you cannot easily move it Jul 12 16:19:22 Except using tricks such as overlayfs or mount namespaces of course, but I wanted to avoid those for now. Jul 12 16:19:45 we relocate native sysroot content all the time, just when the sstate archive is created/extracted, via sed replacements. not pretty, but.. Jul 12 16:20:32 Hm, maybe I can do that as well for the native sysroot and hardlink for the target sysroot then. Jul 12 16:20:54 we do that in our current custom build server (in which we are replacing with Yocto, btw). We did it by massively deleting, and redeploying the sysroot foreach package. Jul 12 16:21:27 Its great for the security of the packages (control leakage and such), but the devs hate it, since its consumes more time Jul 12 16:22:36 Well, I have a working proof of concept using overlayfs in a mount namespace, but that only works with user namespaces and on distributions that allow overlayfs in mount namespaces (i.e. recent Ubuntu) Jul 12 16:22:50 I was trying to get this implemented in a way that could be upstreamable Jul 12 16:41:14 halstead: https://gist.github.com/kraj/6caf2a31ff4701c784c2337b4cf0669f Jul 12 16:41:22 halfhalo: I am trying to use pwclient Jul 12 16:41:30 it used to work fine with old instance Jul 12 16:51:35 Looking khem. Jul 12 16:52:49 khem, Can you update your .pwclientrc to point at https://patchwork.openembedded.org/xmlrpc/ ? Jul 12 16:52:53 And try again? Jul 12 17:00:18 halstead: ok so I had http so changing to https helped Jul 12 17:00:37 hmm. My qt app package fails on missing linux_types.h Jul 12 17:06:21 sveinse: its probably assuming that it can look in /usr for something Jul 12 17:07:59 Hmm, is PARALLEL_MAKE="" in a recipe global? If yes, would PARALLEL_MAKE_mypkg="" work? Jul 12 17:08:58 in a recipe, everything is scoped to the recipe Jul 12 17:09:36 basically the data is a CoW database which is populated with the distro and local conf files, and then cloned for each recipe Jul 12 17:09:45 so you can't impact other recipes from inside a recipe Jul 12 17:09:58 rburton: ok. I got the include resolved. The only thing remaining is the dependency on protobuf which apparently does not work Jul 12 17:10:47 I can call bitbake protobuf-native, and things work out. But it does not build protobuf-native, if I mention it in DEPENDS="protobuf-native" Jul 12 17:11:01 ...or protobuf-compiler-native as previously suggested Jul 12 17:11:16 How can I debug a recipes depends? Jul 12 17:12:41 I seriously don't understand how this depend system in yocto works Jul 12 17:13:18 sveinse: bitbake -e | grep "^DEPENDS" Jul 12 17:14:29 khem: ok, so it sais protobuf-native. How can I check if this package has been built? Jul 12 17:15:35 is protobuf-native providing some tools which will generate linux_types.h Jul 12 17:15:59 khem: No, that issue is resolved :D Jul 12 17:17:03 ok so it the dependency on protobuf then protobuf-native wont help Jul 12 17:17:24 if you are using some libs and APIs from protobuf then you have to depend on protobuf Jul 12 17:17:45 not on native version of protobuf which is for build host not target host Jul 12 17:18:27 khem: if I manually run bitbake protobuf-native prior to my build, then my recipe build finds protoc and continues Jul 12 17:18:46 Hence, I think I need to depend on protobuf-native Jul 12 17:22:29 simark1 suggested earlier that I need to depend on protobuf-compiler-native, yet it does not remedy the case. Nor does bitbake know about any recipes with that name Jul 12 17:23:43 Isn't the purpose of DEPENDS=xyz to run the full bitbake xyz process prior to its own compile? Jul 12 17:24:42 specifically, DEPENDS=xyz means the do_populate_sysroot task of xyz will be run before do_configure in the recipe with the DEPENDS Jul 12 17:26:27 yes, and I assume do_populate_sysroot on a native package implies installing the files into its sysroot, right? So why isn't it when I write DEPENDS="protobuf-native", when running bitbake protobuf-native first works? Jul 12 17:27:05 hey, does anyone have experience with the device tree changes needed to bring up a camera? Jul 12 17:29:14 sveinse: no idea, it works fine for every other recipe we have Jul 12 17:29:21 you must be doing something wrong Jul 12 17:29:29 might want to pastebin the recipe for us to examine Jul 12 17:31:36 kergoth: Not much to look at, the only thing added is this DEPENDS = "protobuf-native" to this: https://bpaste.net/show/f4899bb3a29c Jul 12 17:32:33 kergoth: The qt app source make use of protoc Jul 12 17:33:22 (No wonder our consultants can charge us a lot for Yocto customization :P ) Jul 12 17:40:57 This has been my very first day with Yocto, and I have have a lot to learn, that is for sure. Lots of getting used to, especially with logging/output. And this elusive dependency system and how to debug it Jul 12 17:41:45 rburton, thanks for all your help today. It has been very valuable and I really appreciate it. Jul 12 18:01:49 if i'm trying to configure my device tree to enable a serial camera - do i need to make a patch like this: http://www.xilka.com/kernel/3/3.14/3.14.30/source/Linux-3.14.29-ov5647-20150126.patch which adds a specific entry for that camera into the device tree? Jul 12 18:10:19 When we build our Qt application under a Yocto SDK, we set an environment file which, amongst many, defines SDKTARGETSYSROOT. How do I set an equivalent set of variables from within a recipe? Jul 12 18:11:20 Specifically, is there an environment variable the Qt app can use to test that it is compiling under Yocto? Jul 12 18:17:45 sveinse: ok so that answers my first question. Which is you are using protoc tool from native package Jul 12 18:18:07 now can you change DEPENDS = "xxx" to DEPEND += "xxx" Jul 12 18:19:32 typo, thanks. typo or subtle difference? Jul 12 18:19:51 typo, DEPENDS is correct Jul 12 18:19:53 I am just thinking if there are more dependencies Jul 12 18:20:08 oh yes DEPENDS Jul 12 18:21:30 I've installed protobuf-native manually, so I won't know until I remove protobuf. I can erase it by running bitbake -c cleanall protobuf-native, right? Jul 12 18:22:51 yes Jul 12 18:23:24 then do bitbake your-recipe Jul 12 18:26:17 khem: Nope, did not trigger build of protobuf-native Jul 12 18:29:20 can you show your recipe ? Jul 12 18:32:01 khem: https://bpaste.net/show/3412c6c5b117 Jul 12 18:32:42 Its highly work in progress, so you'll parden me for the do_configure() mess. I'm working on how to pass options to qmake Jul 12 18:50:34 sveinse: EXTRA_QMAKEVARS_{PRE,POST}, iirc Jul 12 18:53:21 neverpanic: Worked brilliantly, thanks Jul 12 18:55:01 One catch thou: Qmake needs a CONFIG statement which is based on the combination of two recipe vars. I need some lookuptable/logic to find the correct value to give to qmake Jul 12 18:55:47 Can I run a conditional script in recipe setting a var based on that script? Jul 12 18:56:10 You can even do it in a variable: ${@python code that returns the value you need} Jul 12 18:58:19 Can I do something like this: https://bpaste.net/show/887b670c7d93 Jul 12 18:58:35 neverpanic: ok, does the py script need to be a py oneliner? Jul 12 18:58:49 e.g. https://p.dnnr.de/odn8gg98Ko_98m7n Jul 12 18:59:11 neverpanic: right, brilliant, thanks Jul 12 19:00:15 btw, how do you determine that protobuf-native isn't being built? If you have built it previously it will just be extracted if you need it, it will likely not be recompiled. Jul 12 19:01:05 neverpanic: I haven't. Its just not available in path for the qt app I'm compiling Jul 12 19:03:32 sveinse: check $BUILDDIR/tmp/sysroots/x86_64-linux/usr/bin (assuming you're on a 64bit build machine) Jul 12 19:04:27 neverpanic: I have. I test it with find . -name protoc from the top of the build Jul 12 19:04:41 So even broader search Jul 12 19:08:01 how do you trigger the build of your recipe then? Jul 12 19:08:25 just built protobuf-native and i have ./x86_64-linux/usr/bin/protoc in my sysroots Jul 12 19:08:27 Also, LIC_FILES_CHKSUM isn't necessary if you set LICENSE = "CLOSED" Jul 12 19:08:56 neverpanic: the CLOSED is just a temporary means, it will be replace by the actual license Jul 12 19:09:03 so provide evidence that it can't be found, instead of just saying so Jul 12 19:09:31 ie the shell output and evidence that the build isn't just trying to run /usr/bin/protoc Jul 12 19:26:45 rburton: https://bpaste.net/show/8f2715df9208 Jul 12 19:30:51 sveinse: whats's bitbake -e sp | grep -E ^DEPENDS= Jul 12 19:31:46 yeah i was thinking "i bet qmake5 is stupid" Jul 12 19:32:53 (can I run bitbake -e while another build is running?) Jul 12 19:32:58 no :/ Jul 12 19:33:10 well you can if you're using memres bitbake, but don't do that yet - it's not ready Jul 12 19:33:35 I'll wait for this build to finish :) Jul 12 19:33:59 currently suspicious about the makefile Jul 12 19:34:06 like is it doing something stupid like resetting PATH Jul 12 19:34:39 yeah, the qmake5.bbclasses I can see all use DEPENDS_prepend, so they should be fine Jul 12 19:34:42 rburton: Then you should never get to know qmake. Whoa, I loathe that tool Jul 12 19:36:58 This is going to be a manual typeover: DEPENDS="qtbase-native virtual/arm-poky-linux-gnueabi-gcc virtual/arm-poky-linux-gnueabi-compilerlibs protobuf-native" Jul 12 19:37:07 ^ neverpanic Jul 12 19:37:54 looks sane to me Jul 12 19:38:12 yes, it does Jul 12 19:38:24 well, I'll leave this for now. its late Jul 12 19:38:39 Thank you very much, both of you! Jul 12 19:40:47 sveinse: considered porting to cmake? :) Jul 12 19:41:17 rburton: Not my call. I'm not part of the Qt team. Jul 12 19:42:03 But it looks to me that qmake is working fine. Its the fact that protoc isn't installed into the x86_64 sysroot even when I specify it with DEPENDS that is the cause for this Jul 12 19:42:23 totally works for me, so no idea Jul 12 19:42:42 jup Jul 12 19:43:06 presumably this is source you can't share? Jul 12 19:44:14 not all of it, no. not yet at least Jul 12 19:45:07 and I'm fearing some intermixing with the imx BSP machine setup that cause some ill effect with protoc. Jul 12 19:45:30 well, one solution is MACHINE=qemux86 bitbake myrecipe, and see what happens Jul 12 19:46:18 yes, that was the plan. (going to be exciting to see how qt5 makes it out there) Jul 12 22:00:40 Hi I am trying to use plymouth to display boot screen using yocto... but am not able to do so. Has anyone tried incorporating plymouth into yocto and successfully booted a graphical splash screen? Jul 12 23:16:33 megha_dey: are you using systemd ? Jul 12 23:17:01 megha_dey: its not integrated with sysvinit but should work out of box with systemd as init manager Jul 13 00:53:52 khem:yes I am using systemd **** ENDING LOGGING AT Wed Jul 13 02:59:58 2016