**** BEGIN LOGGING AT Mon Mar 28 02:59:58 2016 Mar 28 11:59:35 hello fellows is anyone aware of an nice example recipe of building dbg symbols package i can follow to modify the systemd supporting debug ? Mar 28 12:37:32 hello Mar 28 12:39:59 I'm trying to get a yocto build system to run on different host os version than originally used. It appears that on the prior host os version, one of the target required libraries was libsdl but the package name on this host os version is libsdl1.2-dev. The include and lib paths are the same but the package name is different. Mar 28 12:41:28 During the build, yocto has a meta/recipes/devtoops/qemu/qemu.inc file which specifies libsdl. I changed this to be libsdl1.2-dev but now it fails saying no recipe. closets is nativesdk-libsdl Mar 28 12:41:56 I backed out the change and tried to find where nativesdk-libsdl is specified. I can not find it. Any clue where to look? Mar 28 13:08:14 sgw_: http://termbin.com/rllq Mar 28 13:08:41 sgw_: could you take a look and review it? it is for meta-intel and I don't want to join another mailing list ;) Mar 28 14:20:46 this error about libSDL not installed, puzzles me Mar 28 14:21:13 i have /usb/bin/sdl-config on both hosts which are running yocto. Mar 28 14:21:24 yet on one host it works and on the other it fails. Mar 28 15:00:26 hey Mar 28 15:00:43 I'm building a custom wireshark recipe that needs bash to build Mar 28 15:01:14 i'm setting the DEPENDS to "bash-native perl-native sed-native" as it also depends on perl and sed Mar 28 15:01:40 but i'm not seeing them added to the sysroot as i expect it to be Mar 28 15:01:51 Am I missing something here? Mar 28 15:08:33 for the record i found that these 3 packages are ASSUME_PROVIDED Mar 28 15:08:49 so they don't build at all Mar 28 15:39:17 Has anyone experienced recipes which have not been inbcluded in a build throwing build errors? Specifically for meta-qt5. If so, how did you resolved it or how did you trace where the recipe was being called from? Mar 28 15:40:09 are you not familiar with the concept of dependencies? Mar 28 15:47:12 I must not be. I was under the impression that if I did not include it in local.conf then it would not be included. Mar 28 15:47:53 * armpit khem having a rough start Mar 28 15:48:05 kergoth: I even used bitbake -g to see the dependencies. I did not see anythign depending on qt_svg (the problem recipe) and yet it is still being called Mar 28 15:48:36 riz___: that's incorrect. first of all, local.conf doesn't control what recipes are built much at all. it's the image that does that Mar 28 15:48:50 the local.conf can just add to that extra stuff, or change policy Mar 28 15:48:54 (generally) Mar 28 15:49:33 Correct, but I am adding meta-qt5. So qtsvg would not be included in core-image-base by default Mar 28 15:50:08 I don't see why my build is failing due to qtsvg_git.bb if I never included qtsvg Mar 28 15:51:36 just including metq-qt5 won't cause anything from the layer to actually build unless you opt-in. for the most part meta-qt5 is just a standalone repo of extra recipes, and wont' affect how anything builds Mar 28 15:53:21 I understand. I included it in the bblayers however never included qtsvg in local.conf. I did include other things such as qtbase, qtmultimedia, etc. So I am not understanding why my build is failing due to qtsvg. Mar 28 15:53:29 That is my issue Mar 28 15:54:06 I have come to a standstill because I have no known way of tracing why qtsvg is causing a failure when I have not included it. Mar 28 15:55:26 sounds like you might be misreading the error. what exactly is the failure? can yu put the failing log file on a pastebin? Mar 28 15:56:38 kergoth: http://pastebin.com/kAAGmi6Q Mar 28 15:57:08 That is my error when trying to build meta-toolchain-qt5 Mar 28 15:57:19 you just said you were building core-image-base Mar 28 15:57:19 Or trying populate-sdk Mar 28 15:57:24 meta-toolchain-qt5 is not core-image-base Mar 28 15:57:27 it builds a fair bit more Mar 28 15:57:42 packagegroup-qt5-toolchain-target depends on qtsvg Mar 28 15:57:50 and it's included by default in populate_sdk_qt5.bbclass Mar 28 15:57:52 I meant to say the toolchain/SDK Mar 28 15:57:54 so yes, it's in the dependencies Mar 28 15:58:04 and bitbake -g meta-toolchain-qt5 will show qtsvg Mar 28 15:58:10 so i don't really see wher ethe confusion is coming from Mar 28 15:59:28 I don't see where it is included Mar 28 16:00:02 i just told you where it's included Mar 28 16:00:11 it's pulled in by the bbclass that builds any qt5 sdk. Mar 28 16:00:12 Also, lets say I wanted qtsvg, why does it fail? When I just include it in the build of core-image-base it fails and I get this: http://pastebin.com/MSXhPTzn Mar 28 16:00:40 no idea, i know almost nothing about qt5, so i have no idea why it's failing. just telling you why it's building Mar 28 16:01:17 OK. I see it in packagegroup-qt5-toolchain-target Mar 28 16:01:40 What is the best way to remove that dependency? Mar 28 16:02:14 and line 6 of meta-qt5/classes/populate_sdk_qt5.bbclass includes that packagegroup by default Mar 28 16:02:39 you could try RDEPENDS_${PN}_remove_pn-packagegroup-qt5-toolchain-target = "qtsvg-dev qtsvg-mkspecs qtsvg-plugins" in local.conf Mar 28 16:03:29 or you can create a layer and bbappend the recipe and do it there, i.e. yocto-layer create local 1; bitbake-layers add-layer meta-local; recipetool newappend -e meta-local packagegroup-qt5-toolchain-target; then in the editor that's spawned, do RDEPENDS_${PN}_remove = "qtsvg-dev qtsvg-mkspecs qtsvg-plugins" Mar 28 16:03:42 the append approach is better long term, local.conf is quickest for now Mar 28 16:04:28 btw i found what pulled in qtsvg by grepping meta-qt5. i recommend getting more familiar with it Mar 28 16:05:28 OK. Awesome. I apprecisate the help. I will play around now. I guess I should have tried grepping. Thanks again. Mar 28 16:05:44 np Mar 28 16:06:59 bitbake -g would have shown the dependency, however. bitbake -g meta-toolchain-qt5 Mar 28 16:07:05 if not, that's a bitbake bug and would need reporting Mar 28 16:10:16 I didnt get it to show when doing bitbake -g for core-image-base populate-sdk Mar 28 16:10:26 I will confirm and if so I will report the bug Mar 28 16:12:37 it shouldn't have built for populate_sdk unless you added the packagegroup, afaik, core-image-base doesn't inherit populate_sdk_qt5. woudl expect it to fail for meta-toolchain-qt5, tough Mar 28 16:34:42 halstead: any chance we can get some of the AB workers back? The builds are going very slowly :( Mar 28 17:40:51 RP: does something like https://github.com/kergoth/poky/commit/3d464bb seem reasonable? I wanted to run it by you to check sanity before I think about submission on this. we've done this sort of traceback limiting before, but we were missing it in this spot. also looks like we're missing correct filename/lineno on := expansions Mar 28 17:40:52 * kergoth gets caffeine Mar 28 17:41:03 is there some way to mark just a few of the packages generated from a recipe as architecture-independent? Mar 28 17:41:22 e.g., a documentation package or a test package that only contains architecture-independent scripts Mar 28 17:42:22 Ulfalizer: I think PACKAGE_ARCH can be set on a per-package basis. Mar 28 17:42:55 much like the other package vars, though of course the un-suffixed PACKAGE_ARCH has other effects Mar 28 17:43:48 ah, yeah, you're right. i had missed it when i grep'd for "PACKAGE_ARCH_". Mar 28 17:43:50 thanks Mar 28 17:44:23 doesn't seem to get used that much, but nice to know it's possible Mar 28 19:06:24 What is the best way to search from the terminal what packages have been built into the final image? Mar 28 19:28:00 riz___: there's an image license manifest in tmp/deploy/licenses// Mar 28 19:28:17 riz___: otherwise if you have buildhistory enabled there's a ton of info in there about the image, packages, files, sizes, etc Mar 28 19:28:34 i would recommend enabling buildhistory if you don't have it enabled already. INHERIT += "buildhistory"; BUILDHISTORY_COMMIT ?= "1" Mar 28 19:28:55 the latter is optional, but results in letting you track changes to the buildhistory info over time, since it tracks it with git Mar 28 19:29:04 (see buildhistory-diff) Mar 28 19:42:03 kergoth: Thanks. I see it. To build on my last problem, implementing the dependency removals still did not work. qtsvg still threw an error. I grepped and removed every possible dependency that was there. What is odd to my is that when I just checked out those manifests, qtsvg was never built in BEFORE or after I put the dependency removals. Mar 28 19:42:17 I still have no idea where it is getting the qtsvg from. Mar 28 19:42:25 what "manifests" are you looking at? Mar 28 19:45:38 I looked at the package and license manifests for the custom image Mar 28 19:49:43 just because something was built doesn't mean it'll end up in the image, it depends on why it was pulled in Mar 28 19:49:51 we have plenty of deps which are built but not installed in the image Mar 28 19:50:03 I see Mar 28 19:51:00 I am just teying to see a way to tace where the qtsvg dependency is still coming from. Actually, the reason for this was to see if the local.conf additions I made worked, but from what you are saying that wont help Mar 28 19:53:29 kergoth: http://pastebin.com/ByXLuwr5 - this is what I am still getting. Mar 28 19:55:47 just use bitbake -e. Mar 28 19:55:57 bitbake -e packaggroup-whatever | grep \^RDEPENDS_ Mar 28 19:56:15 see if the value is what you'd expect (i.e. make sure qtsvg isn't listed) Mar 28 19:56:21 if not, your local.conf addition didn't work as expected Mar 28 20:10:22 It seemed to work. So I am not sure where qtsvg is coming form anymore Mar 28 20:10:25 from Mar 28 22:06:03 kergoth: at a first glance I'd say its reasonable. We are certainly missing tracebacks on expansionerrors and it can be a pain Mar 28 22:06:18 kergoth: looks better that some of my local debugging tweaks ;-) Mar 28 22:06:27 heh, k **** ENDING LOGGING AT Tue Mar 29 02:59:58 2016