**** BEGIN LOGGING AT Tue Aug 19 02:59:59 2014 Aug 19 03:01:41 can anyone tell my why the do_install step here https://gist.github.com/anonymous/c7ab0078c60644f3f81e does not generate an rpm? only the -dbg and -dev rpms Aug 19 03:02:03 i can see all the .o files in my workdir Aug 19 06:32:35 joran_: In the image dir (${D}) you can see all installed files. If that looks correct check the dirs in packages-split. Maybe the main package (with the same name as the recipe) is empty? Then you need to use a FILES_${PN] += ".." to make sure the file ends up in the correct package. The rpm and package splitting is not done by the do_install task, that only installs your files in ${D}. Aug 19 06:34:49 joran_: Also note that you probably can replace your do_install task with 'EXTRA_OEMAKE += "INSTALL_ROOT=${D}"' Aug 19 06:53:01 After I dragged in meta-oe it seems that I get errors like "The URL: '${SAVANNAH_GNU_MIRROR}/gpsd/gpsd-3.7.tar.gz' is invalid and cannot be interpreted" Aug 19 06:53:43 I suspect I have no knowledge about SAVANNAH_GNU_MIRROR Aug 19 06:57:23 aaah, nevermind. had forgotten to change to daisy after cloning. Aug 19 07:56:20 I do not get Yocto.... I am saying bitbake -c cleansstate foo; bitbake -c fetch foo, yet the git directory is empty. What may be going on?! Aug 19 07:57:33 I even tried forcing the fetch with bitbake, but no joy... What more can I do to get the stuff fetched? Aug 19 08:01:20 here you can see the debug log from bitbake fwiw: http://paste.kde.org/pl8cke94m Aug 19 08:03:42 lpapp: Try bitbake -c unpack foo Aug 19 08:06:27 lpapp: fetch downloads to ${DL_DIR}, unpack then unpacks/clones/whatever to ${S} Aug 19 08:12:45 olani: ah, great, thank you. Aug 19 08:30:41 morning all Aug 19 08:32:20 how would I go about solving this? NOTE: multiple providers are available for runtime packagegroup-foo-dbg (packagegroup-foo-dbg, packagegroup-foo) Aug 19 08:32:23 NOTE: consider defining a PREFERRED_PROVIDER entry to match packagegroup-foo-dbg Aug 19 08:33:05 my -dbg image inherits the non-dbg image cause that sets up some stuff... hence the packagegroup-foo thing... shall I move the shared parts out into a common file, or shall I use that PREFERRED_PROVIDER, or what is the best practice? Aug 19 08:33:34 lpapp: other than not having multiple runtime providers, you can't right now: https://bugzilla.yoctoproject.org/show_bug.cgi?id=6149 Aug 19 08:33:35 Bug 6149: normal, Medium, 1.7, paul.eggleton, NEW , Setting PREFERRED_PROVIDER to select between multiple runtime providers does not work Aug 19 08:34:08 bluelightning: ok, so I should put the shared part into a shared include file? Aug 19 08:34:19 no, that won't accomplish anything Aug 19 08:34:27 what are you trying to do exactly? Aug 19 08:35:05 bluelightning: well, I have two images, one debug and one non-debug Aug 19 08:35:16 the debug image is almost the same, except that it gets the -git version of our software. Aug 19 08:35:24 and built with -O0 -g -DDEBUG, etc. Aug 19 08:35:40 why wouldn't that accomplish anything? Aug 19 08:35:52 then, I would not include the non-dbg image into the -dbg anymore, just the shared part. Aug 19 08:36:03 so there could be no clashing stuff IMHO Aug 19 08:36:33 if you just don't call it -dbg you won't have the problem Aug 19 08:37:44 the image, the packagegroup, both or what exactly? Aug 19 08:37:49 (and why will I not have the problem then?) Aug 19 08:40:38 bluelightning: ^ Aug 19 08:40:47 the packagegroup Aug 19 08:40:57 because they then will not overlap... Aug 19 08:45:01 bluelightning: what do you mean by overlap? Aug 19 08:45:17 bitbake only checks if the _names_ overlap, and not the actual package list? Aug 19 08:46:21 what is in PACKAGES goes into RPROVIDES, and that gets checked Aug 19 08:48:05 I am not sure I follow. Aug 19 08:49:51 I guess the solution is to wipe everything away and wait 2 hours. :/ Aug 19 08:50:09 but it is so frustrating to do this all the time for so many issues. Aug 19 08:58:18 bluelightning: I will try out moving the shared part into foo-core-image.inc and include that both in the release and debug images. Aug 19 09:00:18 I think pretty much the whole foo-core-image.inc must be shared, except IMAGE_INSTALL += " packagegroup-foo" since that will be IMAGE_INSTALL += " packagegroup-foo-dbg" in the dbg image. Aug 19 09:03:13 and IMAGE_FEATURES += "dbg-pkgs" + description. Aug 19 09:06:16 hello Aug 19 09:06:16 bluelightning: yeah, strange, I am still getting the warning, although the -dbg image now only contains the -dbg package group, not both. Aug 19 09:07:00 is there a way to gently wipe the main image away to be able to generate the debug without losing all the separate package builds? Aug 19 09:07:03 lpapp: I just read your bug report and I think your problem is that you have packagegroups and/or recipes that have names ending in -dbg. Each recipe/packagegroup may create a package (rpm-file) that is names ${PN}-dbg. Common practice in most linux distributions I believe. These names clash, thus the warning. Or maybe I just misunderstand everything :) Aug 19 09:07:30 lpapp: wiping things out will not solve this, you'll just get the same error again Aug 19 09:07:43 olani: 1) It is not my bugreport 2) OK, well, I will rename it to -git then. Aug 19 09:07:57 bluelightning: nope, because I would type bitbake foo-core-image-dbg Aug 19 09:08:06 olani is correct, the -dbg name is the source of your problems (as I pointed out half an hour ago) Aug 19 09:08:13 it worked yesterday; why I am getting this is because I made the SDK out of the normal image first now. Aug 19 09:08:29 bluelightning: I do not agree that it should be the source of the problem. Aug 19 09:08:34 lpapp: Not a good choice either. Use -debug. Aug 19 09:08:44 IMHO, Yocto should fix it up. It is completely good to have dbg images and hence package groups Aug 19 09:09:03 What is wrong about creating a debug image? As far as I understand, that is the right way of getting a debugable image after all, so why does Yocto not accept the right way? Aug 19 09:09:26 and creating -dbg stuff automatically out of release does not make any sense to me since release is not built with the right flags (obviously). Aug 19 09:09:40 they _do_ need to be separate builds from the ground up. Aug 19 09:10:06 you cannot just get debug stuff out of a non-debug build, or I may have missed something the last ten years in software development :) Aug 19 09:10:10 there is nothing wrong with the use case, it's solely about the naming Aug 19 09:10:22 naming should match the use case IMHO Aug 19 09:10:51 packagegroups already have handling for -dbg packages though, unless you override PACKAGES Aug 19 09:10:56 olani: why not a good choice? -debug, I would _rather_ not use it. How will I know the difference between -debug and -dbg half a year later? Aug 19 09:10:59 so your naming clashes with that Aug 19 09:11:16 (I simply will not, I can guarantee that, and I will struggle) Aug 19 09:11:55 there oughta be a way that I can tell Yocto, _this_ is the dbg stuff that I cooked together. Aug 19 09:12:05 and not what it thinks it is. Aug 19 09:12:14 lpapp: I think -git can be used as a package version suffix in some cases. It might not clash in this case. Aug 19 09:13:18 bluelightning: let me ask you this question: if the release image is not built with -g -O0 for obvious reasons (sparing space), how will PG have handling for -dbg the way that I can debug the image properly? Aug 19 09:13:24 bluelightning: non-stripped != debug. Aug 19 09:13:56 what do you mean by debug? Aug 19 09:14:06 -g -DDEBUG -O0 at the very least. Aug 19 09:14:17 do you mean, you have the symbols such that gdb can display proper backtraces? Aug 19 09:14:56 it seems that Yocto has a fundamental flaw of thinking debug is equal to non-stripped release binaries. Aug 19 09:15:24 I think that should be addressed, otherwise we developers will be locked out from proper debugging, or at least we need to apply sub-optimal workarounds. Aug 19 09:16:26 (or at least Yocto should use those flags automatically for -dbg, although different projects might prefer different flags... which means it should be possible that the developer tells Yocto what -dbg means) Aug 19 09:17:26 could you answer my question please? Aug 19 09:17:41 I think I did: 10:13 < lpapp> -g -DDEBUG -O0 at the very least. Aug 19 09:18:12 so -DDEBUG means no, then Aug 19 09:18:32 we don't have any explicit handling for this kind of situation, no Aug 19 09:18:43 that is my main problem, yeah. Aug 19 09:18:49 I will submit a bugreport for it... Aug 19 09:18:56 could we? possibly, yes, but it would be outside of what we understand with the -dbg packaging we currently have, that is only for debugging symbols Aug 19 09:19:02 it is crucial for cooking proper debug environment. Aug 19 09:19:18 without this, it is painful to make a nice debugging environment which is essential for maintaining software. Aug 19 09:19:20 if you want to implement that, you're more than welcome to do so Aug 19 09:20:31 is there a better workaround than calling it -debug? Aug 19 09:20:46 I already see my colleagues asking for explanation what the difference is between -debug and -dbg, rightfully though... Aug 19 09:20:53 and I cannot use git either ... Aug 19 09:23:14 lpapp: Package names ending in -dbg are reserved by the system, you cannot add any yourself. It's no more complicated than that. It can't be the first time you have happened across reserved identifiers. Aug 19 09:27:15 lpapp: I'm not sure about -git, maybe that works. I just wouldn't recommend it as '-git' is added as part of the version string in some cases. Aug 19 09:45:59 are you saying that this flaw cannot be worked around "nicely"? Aug 19 09:46:26 I would hate spending my time explaning to this to developers why it is called -debug and hear the complaints that it is confusing since I would agree with them. Aug 19 09:46:35 explaining this* Aug 19 09:49:52 I will call it -git for now for sanity and let us see if it breaks at some point... thanks. Aug 19 09:51:19 should I also rename the image from foo-dbg or it is only for the packagegroup here? Aug 19 09:51:23 bluelightning: ^ Aug 19 09:51:57 I can't be sure, but since the image recipe doesn't do any packaging it shouldn't theoretically be an issue Aug 19 09:52:39 lpapp: We do use an image recipe ending in -dbg. That works. Aug 19 09:53:00 ERROR: Nothing PROVIDES 'foo-image-core-dbg' Aug 19 09:53:05 my dbg image does not work anymore? Aug 19 09:53:16 ah, sorry, core-image, not image-core Aug 19 09:53:24 :-) Aug 19 09:53:37 bluelightning: olani ok, thanks, I will leave it there. Aug 19 09:56:52 so why is the -dbg image still not created in ./tmp/work/foo-foo-linux-gnueabi/? Aug 19 09:56:55 olani: bluelightning ^ Aug 19 09:57:14 I do not get the warning, yet it is not created for bitbake foo-dbg, I even tried -c cleansstate before that just in case. Aug 19 09:57:23 I only have the foo image populated in there. Aug 19 09:58:01 what is your bitbake command line? Aug 19 09:58:42 bitbake foo-dbg where foo-dbg is the dbg image name. Aug 19 09:59:04 foo-core-image-dbg to be fair, but yeah Aug 19 09:59:19 I also tried bitbake -c cleansstate foo-core-image-dbg; bitbake foo-core-image-dbg Aug 19 10:00:05 do_rootfs is running fwiw. Aug 19 10:02:51 how can I force to populate it? Aug 19 10:04:01 there shouldn't need to be any forcing Aug 19 10:04:29 bluelightning: ok, so what is the problem then? Aug 19 10:04:36 no idea Aug 19 10:04:42 if it's running do_rootfs then it is building the image Aug 19 10:04:54 it is finishing without issues. Aug 19 10:05:12 bitbake -e foo-dbg | grep ^WORKDIR= if you're unsure as to where the work directory is ending up... Aug 19 10:05:27 I know where it ends up based on the last successful builds. Aug 19 10:05:38 it ought to be beside the foo image, but let me confirm that. Aug 19 10:06:21 tmp/work/foo-foo-linux-gnueabi/foo-core-image-dbg/1.0-r0 Aug 19 10:06:50 I see only pseudo, temp and foo-core-image-dbg-1.0 there, but the last one is an empty directory. Aug 19 10:07:43 this is the image recipe content, fwiw: http://paste.kde.org/prst69mup Aug 19 10:08:24 and the .inc file only has things like these: http://paste.kde.org/pad324bx3 Aug 19 10:29:17 bluelightning: olani do you see any issues with those short files? Aug 19 10:29:32 nothing at a glance Aug 19 10:30:33 bluelightning: ok, thanks. Aug 19 10:30:36 RzR: hi there! Aug 19 10:30:51 hi there didnt know you were hacking on y! Aug 19 10:31:12 btw, i am not Aug 19 10:31:41 RzR: well, I am not hacking on Yocto, just using it. Aug 19 10:34:11 Hi Aug 19 10:35:56 I'm using the BeagleBoneBlack, I want to add an spi module to the system and like to write an kernel module for it (with sockets!!!!). But I need to know how to efficiently modify the device tree from within (openembedded/yocto/poky), can I integrate this in the recipe of my kernel module? Aug 19 10:45:24 RzR: do you wanna build Tizen with Yocto ? Aug 19 10:53:31 Nobody used yocto/openembedded when they had to modify the device tree? Aug 19 10:55:26 bluelightning: can you tell me a workaround? Aug 19 10:55:37 bluelightning: how to enforce the generation? Aug 19 10:55:40 lpapp: I don't know what the problem is... Aug 19 10:55:51 bluelightning: how to pin that down? Aug 19 10:56:39 read logs for the image, add debug messages ... Aug 19 10:58:09 bluelightning: which log is interesting in this case? Aug 19 10:58:24 do_rootfs or something else? Aug 19 10:58:42 well, log.do_rootfs I would have thought, since that's where the actual image construction happens... Aug 19 11:09:00 ok, well, I am wiping stuff away as I cannot find anything. Let us hope it works afterwards. Aug 19 11:10:54 I'm almost positive that won't help, but up to you Aug 19 11:11:51 well, it used to work. Aug 19 11:12:20 and since there is no better idea, I do not have anything to lose either. Aug 19 11:14:32 lpapp: What is you goal? If you just ignore all the problems. What are you trying to achieve? Aug 19 11:16:22 soderstrom: that sounds a bit non-constructive, but of course, you are more than welcome not to "ignore" the problem and provide suggestion! Aug 19 11:18:43 (fwiw I am not paid by Intel or anyone else for working on Yocto, and that is good that way) Aug 19 11:19:58 lpapp: Instead of focusing on the problems, maybe you can take a step back and focus on task at hand? Aug 19 11:20:14 meh Aug 19 11:22:11 That is why I am asking, what is your goal? What are you trying to do? Can you explain it? Aug 19 11:25:31 https://bugzilla.yoctoproject.org/show_bug.cgi?id=6636 Aug 19 11:25:32 Bug 6636: normal, Undecided, ---, saul.wold, NEW , Yocto does not understand what a debug package might really be Aug 19 11:26:54 soderstrom: it is all said above. I do not have time to reiterate it, sorry. Aug 19 11:27:25 nor actual interest since the rebuild already started anyway. Aug 19 11:31:00 lpapp: there are work in progress on that ... but I just came here to find someone who had similar issues w/ gst Aug 19 11:32:06 RzR: what issue ? Aug 19 11:32:08 lpapp: allways diplomatic Aug 19 11:32:25 lpapp: something w/ Qt+gst+libva Aug 19 11:33:24 totally unrelated to yocto project ;) Aug 19 11:36:24 Does bitbake -c cleanstate remove / reset tthe stored sstate-cache info ? Like it never really happened? Aug 19 11:37:15 you mean cleansstate? Aug 19 11:37:38 I've done -c clean but then seen the sstate-cache restore the build data instead of doing an actual rebuild. Aug 19 11:37:45 lpapp: yeah Aug 19 11:37:57 yeah, cleansstate, not clean. Aug 19 11:38:06 Wondering how to do that without a -c cleanall Aug 19 11:38:26 bitbkake -c cleansstate Aug 19 11:38:40 or you can just force whatever action you wish to do again AFAIK. Aug 19 11:38:42 yes, ok, greate. Aug 19 11:38:46 yes, ok, great. Aug 19 11:38:57 no coffee yet this morning. Aug 19 11:56:43 bluelightning: hmm, yeah, it is still empty, grrr. Aug 19 11:57:15 I am so confused; it is likely because of the shared content separation. I will revert that change. Aug 19 12:08:14 bluelightning: the "fun" thing is that ./tmp/deploy/images is populated, just not the root fs ... Aug 19 12:20:34 shouldn't do_rootfs generate an error or at least a warning if it cannot create the rootfs? Aug 19 12:23:25 it won't be solely because of the inc file Aug 19 12:23:36 hey guys Aug 19 12:23:55 can anyone tell my why the do_install step here https://gist.github.com/anonymous/c7ab0078c60644f3f81e does not generate an rpm? only the -dbg and -dev rpms Aug 19 12:24:22 bluelightning: would you like to see the do_rootfs log? I cannot spot anything obvious out of it, even though I see some errors in there, but nothing new. Aug 19 12:24:23 I can see in the image directory it builds all the .o files ... but all I can find in terms of binaries are the -dev and -dbg Aug 19 12:24:27 joran_: In the image dir (${D}) you can see all installed files. If Aug 19 12:24:27 that looks correct check the dirs in packages-split. Maybe the main Aug 19 12:24:27 package (with the same name as the recipe) is empty? Then you need to Aug 19 12:24:27 use a FILES_${PN] += ".." to make sure the file ends up in the correct Aug 19 12:24:30 package. The rpm and package splitting is not done by the do_install Aug 19 12:24:33 task, that only installs your files in ${D}. Aug 19 12:24:39 hey olani cool your still here Aug 19 12:25:05 ok checking noww Aug 19 12:25:09 thanks :) Aug 19 12:27:36 bluelightning: hmm, may it be due to rm_work? Aug 19 12:29:10 lpapp: oh... yes, that would do it Aug 19 12:29:30 yes, I tested it. Aug 19 12:30:03 what is the best practice to exclude that rule for the debug image only? Aug 19 12:30:47 so {workdir}/image/usr/bin is empty Aug 19 12:31:33 {workdir} contains all the .o files Aug 19 12:33:16 im an idiot I think I found it ... Aug 19 12:34:20 dang I feel dumb sometimes Aug 19 12:34:53 its cause it was named something other than its bitbake recipe name in the qmake file Aug 19 12:35:14 so the file was there all along I just didnt see it cause i was looking for the wrong name Aug 19 12:40:59 lpapp: add it to RM_WORK_EXCLUDE Aug 19 12:47:19 bluelightning: is it ok to do that in the -dbg image recipe? Aug 19 12:48:20 lpapp: AFAICT yes Aug 19 12:55:19 bluelightning: I will test it, thanks. Aug 19 13:09:11 khem: I checked the sysroot folder and there is nothing. In the recipe, I installed these libs in /usr/bin but I cannot find them in tmp/sysroot//usr/bin. I guess I must miss something. Aug 19 13:26:55 hi Aug 19 13:27:08 does anyone have experience with QtGstreamer on imx6? Aug 19 13:30:24 I am trying to add video support on imx6...I managed to deploy gstreamer1.x, gst-play-1.0 works with big-bucks-bunny, QT5 works, but I'm struggling to get QtGStreamer example working Aug 19 13:59:23 <_rink> hi all! Aug 19 13:59:29 <_rink> anyone here maintainer of dosfstools ? Aug 19 13:59:37 <_rink> or knowledgable about it? Aug 19 14:00:25 _rink: I'm the maintainer, though I haven't done much maintenance with it lately Aug 19 14:00:44 I think there is a reason we're stuck on an older version but I don't remember offhand what it is Aug 19 14:00:52 <_rink> gplv3 maybe? Aug 19 14:00:58 that could be it yes Aug 19 14:01:00 <_rink> Well Aug 19 14:01:38 we can add a v3 version, just need to keep the v2 one Aug 19 14:01:52 <_rink> there's a pretty annoying but in it, causing it to die due to memory corruption while repating a filesystem Aug 19 14:02:19 <_rink> I made a patch based on the fedora core (i think it was) bug report Aug 19 14:02:26 <_rink> and added a tiny change based on their git history Aug 19 14:02:33 * _rink unsure if that is acceptable to include ? Aug 19 14:02:47 <_rink> the fix is quite trivial if you know what the problem is Aug 19 14:03:50 is the patch against the GPLv2 version though? Aug 19 14:03:57 <_rink> yes Aug 19 14:05:45 ok, as long as it doesn't break anything I think it should be acceptable Aug 19 14:06:41 <_rink> hmmm Aug 19 14:06:49 <_rink> https://bugzilla.redhat.com/show_bug.cgi?id=674095 is where I got the patch from where I based my work on Aug 19 14:06:50 Bug 674095: was not found. Aug 19 14:06:52 <_rink> the patch there is incomplete Aug 19 14:07:13 <_rink> but this patch eppears to be against 3.0.9-4.fc14 Aug 19 14:07:38 <_rink> [not that the code has changed] - and the author does not say anything about licensing Aug 19 14:08:22 ah, in that case we may have a problem Aug 19 14:08:39 <_rink> yeah, thought was much. Aug 19 14:08:56 because the patch was intended for a newer version, we have to assume the license is the same in the absence of some explicit statement to the contrary from the author Aug 19 14:09:12 <_rink> however, the patch there is incomplete Aug 19 14:09:27 <_rink> I could e-mail the author and ask if it's okay to use his 3 lines as gplv2 ? Aug 19 14:09:42 * _rink notes, seems like a lot of work for such a silly patch Aug 19 14:12:01 morning... Aug 19 14:15:59 _rink: it is a bit of a pain I agree; we're not left with much of a choice given the license incompatibility though :( Aug 19 14:16:50 <_rink> bluelightning, well, I'd be willing to do the legwork to get the patch in the tree; should I just e-mail the original author and ask if he agrees with my pathc (which is based on his) being licensed as GPLv2 ? Aug 19 14:17:20 _rink: yes, that would be great if you could do that, hopefully they say yes and then we can include their statement in the patch header Aug 19 14:17:36 <_rink> okay, i'll get back to you on this :) Aug 19 14:35:30 bluelightning: does -c cleansstate make sense on images? Aug 19 14:35:51 not really, do_rootfs isn't an sstate task Aug 19 14:35:51 say, I want to comment the debug-without-src option in my local conf, and regenerate the image respectively? Aug 19 14:36:09 what am I supposed to do to achieve that? Aug 19 14:36:37 it should be able to tell by itself if rebuilding the image is necessary Aug 19 14:36:56 if it can't, that is a bug; you can work around it by doing e.g. bitbake -C rootfs imagename Aug 19 14:38:00 bluelightning: I wonder if debug-without-src actually is more relevant to the individual packages than the image creation. Aug 19 14:38:24 it should flow from those to the image in terms of the signature changing Aug 19 14:42:29 bluelightning: ok, thanks. Aug 19 14:42:53 bluelightning: anyway, I was pretty stupid using this option since the sources will be on the host anyway, so the more the merrier. Aug 19 15:00:36 Does anyone know how to put files into tmp/sysroot folder? Aug 19 15:01:04 aimetis0: what files? Aug 19 15:01:28 just some lib files Aug 19 15:01:41 it is automatically done if you are doing the right things. Aug 19 15:02:57 lpapp: I have two mono packages. Packages A needs some libs built by Package B. I don't know how to put libs in sysroot Aug 19 15:03:57 ah, like that, I do not know. Aug 19 15:04:24 lpapp: I listed Package B as depends in Package A recipe but there is nothing in the sysroot Aug 19 15:06:14 lpapp: but do you know generally how we can put files into sysroot manually regardless of mono? Aug 19 15:09:34 I heard it has something to do with sysroot staging Aug 19 15:10:19 no, but why would you like to get it to there? Aug 19 15:12:41 0x44ad26ec in select () at ../sysdeps/unix/syscall-template.S:81 Aug 19 15:12:42 81 ../sysdeps/unix/syscall-template.S: No such file or directory. Aug 19 15:12:50 I keep getting this with Yocto, when debugging inside, why? Aug 19 15:13:16 aimetis0: there is maybe some renaming? Aug 19 15:13:56 lpapp: because the libs built by Package B is the build time depends of Package A and others. I heard the only way to share them in the build time to put them into the sysroot and list the Package B in the recipes that demand them. Aug 19 15:13:56 you are talking about 'libs' Aug 19 15:14:41 aimetis0: copying and pasting: Aug 19 15:14:43 * DEPENDS = "b" in recipe "a" will translate to a's do_configure task depending Aug 19 15:14:43 on recipe b's do_populate_sysroot task Aug 19 15:15:04 ant_work: Yes, but it is needed in the build time Aug 19 15:15:27 ofc, at configure stage it is expected the headers are staged Aug 19 15:15:52 I'm talking about build, not runtime Aug 19 15:16:16 DEPENDS means a build-time dependency Aug 19 15:16:37 I guess the lib is gettin grenamed and it is not found... Aug 19 15:17:10 ant_work: I declared DEPENDS in recipe but it didn't put anything in the sysroot Aug 19 15:17:36 pls verify Aug 19 15:19:06 ant_work: I am wondering if I need to write the do_populate_sysroot function Aug 19 15:19:25 aimetis0: don't go off-track ;) Aug 19 15:20:16 pls inspect the WORKDIR of the packages and check how these are built and packaged Aug 19 15:22:09 ant_work: Yes, the dependency is built and packed in its workdir Aug 19 15:22:55 aimetis0: what is the exact error you get? Can you paste it? Aug 19 15:23:31 bluelightning: hey, why is Yocto not installing eglibc-source properly? Aug 19 15:23:38 I think that is why I see the above error. Aug 19 15:25:28 ant_work: WebDeviceDiscovery/DeviceDiscoveryImpl.cs(7,7): error CS0246: The type or namespace name `DeviceAutoDiscovery' could not be found. Are you missing an assembly reference? Aug 19 15:26:17 ant_work: it seems that it still could not find the libs it depends Aug 19 15:28:12 what's th eexpected library then? Aug 19 15:29:14 ant_work: the DeviceAutoDiscovery.dll is expected and it is built by the recipe "discover-devices.bb". Aug 19 15:30:51 what do the logs of above recipe say? Is it a private recipe? Aug 19 15:31:16 (google doesn't know about it) Aug 19 15:31:17 ant_work: yes, it is a private recipe Aug 19 15:32:21 check the logs, each task has one Aug 19 15:35:14 ant_work: the situation is that discover-devices.bb builds the dll and the dll is need by decoder-service.bb. Both recipes are private recipes Aug 19 15:37:28 ant_work: I listed discover-devices as dependency of decoder-service. I guess the problem is decoder-services.bb just doesn't know where to get the dll Aug 19 15:40:02 Hi guys, I have a qtmultimedia related question. As far as I can see, qtmultimedia uses GStreamer's xvimagesink for a video support. Why is that hard-coded? I want to use it with e.g. imxeglvivsink. How should I achieve it? Aug 19 15:45:50 aimetis0: I'm sorry to say that but I'd need a crystal ball...first I wonder what you're doing with a .dll (emulator?), second I cannot guess what is installed in the machine sysroot Aug 19 15:46:38 the logs in workdir/recipe/tmp should help you Aug 19 15:47:33 ant_work: in recipe decoder-service, I have put "DEPENDS += discover-devices" and decoder-service.bb expects the dll gets placed in the /src folder. I guess I need to write the do_configure function to place the dll there in the decoder-service recipe. The problem is how do I ask discover-devices.bb to put the dll in sysroot or somewhere else and let decoder-service to get it, put into Aug 19 15:47:33 the source folder, and start to build decoder-service Aug 19 15:50:35 ant_work: the dll is just a shared dynamic library. It is built by discover-devices.bb and it is used by decoder-service.bb to build decoder-service.exe Aug 19 15:51:00 Can you tell what kind of Distro/Image are you building? Aug 19 15:52:41 ant_work: cortexa9hf-vfp-neon, I guess Aug 19 15:53:15 ok, it is a final image for Aug 19 15:53:21 hi khem Aug 19 15:53:45 Hello Aug 19 15:54:01 hello :) Aug 19 15:54:10 ant_work: decoder-service and discover-devices are mono projects Aug 19 15:54:16 aimetis0: then you have one specific sysroot for machine Aug 19 15:55:21 you can verify its path inspecting the log. and run. files under /tmp Aug 19 15:55:31 ant_work: I checked the tmp/sysroot folder and there are three subfolders, imx6qsabresd imx6qsabresd-tcbootstrap x86_64-linux Aug 19 15:56:15 first one is , second is temporary, ignore it, third is -native, the build-host Aug 19 15:57:26 ant_work: log. and run. files are stored in ~/yocto/build/tmp/work/cortexa9hf-vfp-neon-poky-linux-gnueabi/discover-devices/git-r0/temp/ Aug 19 15:57:36 pls check what has been installed in sysroot/imx6qsabresd/usr Aug 19 15:58:59 ant_work: just one folder called crossscripts under sysroot/imx*/usr/bin Aug 19 15:59:36 hm.. then /include, .. /lib... look around Aug 19 15:59:49 the logs should point you to the right path Aug 19 16:00:42 ant_work: I did a complete search in sysroot folder and there is nothing Aug 19 16:01:03 are you then building a -native recipe? Aug 19 16:01:32 where did the recipe put the files? Aug 19 16:01:50 ant_work: what is a -native recipe? Aug 19 16:01:53 what does install and populate_sysroot say? Aug 19 16:02:08 pls read the logs thoroughfully Aug 19 16:02:32 heh, new word ! Aug 19 16:02:47 thoroughly Aug 19 16:03:32 ant_work: I put the dll in ${bindir}, "install -m 0775 ${S}/DeviceDiscovery/obj/Debug/DeviceAutoDiscovery.dll ${D}${bindir}" Aug 19 16:05:15 ant_work: the install log only has two lines: DEBUG: Executing shell function do_install DEBUG: Shell function do_install finished Aug 19 16:05:35 check the run. file as well Aug 19 16:07:07 ant_work: install -m 0775 ~/yocto/build/tmp/work/cortexa9hf-vfp-neon-poky-linux-gnueabi/discover-devices/git-r0/git//DeviceDiscovery/obj/Debug/DeviceAutoDiscovery.dll ~/yocto/build/tmp/work/cortexa9hf-vfp-neon-poky-linux-gnueabi/discover-devices/git-r0/image/usr/bin Aug 19 16:08:08 so as you see it goes indeed in ${D}${bindir} Aug 19 16:08:21 ant_work: yes Aug 19 16:08:50 now I maybe see the problem...I'd not put that in bindir Aug 19 16:08:59 try libdir Aug 19 16:09:03 fray_: ping Aug 19 16:09:39 yup Aug 19 16:09:48 ant_work: you mean I need to change the install path from bindir to libdir? Aug 19 16:09:51 aimetis0: or adjust the other recipe to point to the right dir...maybe it i not in path Aug 19 16:09:58 maybe Aug 19 16:10:08 Anyone seen the 'cpio' image fstype working but cpio.gz not? I'm guessing it could be related to the COMPRESS_CMD stuff Aug 19 16:10:24 also, looks like IMAGE_FSTYPES was never added to the do_rootfs vardeps when things were split into oe.image (yet another missing variable dep..) Aug 19 16:10:27 * kergoth rolls eyes Aug 19 16:10:32 kergoth: .gz and .lzma ok in meta-handheld Aug 19 16:10:35 I've had reports in the past it didn't work -- but those turned out to be kernel configuration Aug 19 16:10:57 ant_work: do you need to see the populate_sysroot log. and run. files as well? Aug 19 16:11:06 fray_: was it you with whom I discussed gdb issues? I cannot recall. Aug 19 16:11:16 probably Aug 19 16:11:51 fray_: so apart from -s and -e, I will also need to specify -directory/-d to the source folders that Yocto generates on the image, yeah? Aug 19 16:13:43 no, the source folders are relative to the debug image.. Aug 19 16:13:50 so the system should resolve those automatically Aug 19 16:15:18 basically the binary has a reference in it to the .debug version, which GDB (on the target) should be able to read automatically.. on the cross side, it should get the reference as well and load.. otherwise you have to load the first .debug manually.. Aug 19 16:15:41 withint he debug symbols is the dwarf information, the dwarf information is written to be '/usr/src//'.. Aug 19 16:15:55 aimetis0: check out the STAGING_ vars in conf/bitbake.conf Aug 19 16:15:58 GDB cross should reference teh /usr/src based on the debug root.. Aug 19 16:16:09 while GDB on the target will just use the path and find the source files directly.. Aug 19 16:16:45 fray_: well, I am getting no such file or directory in gdb Aug 19 16:16:57 on which, the source? Aug 19 16:17:03 yes Aug 19 16:17:05 is it showing you the '/usr/src/debug/recipe/...'? Aug 19 16:17:15 and this is cross? Aug 19 16:17:18 kergoth: fwiw we use INITRAMFS_FSTYPES Aug 19 16:17:41 fray_: I think .debug/foo is found, but that does not contain the source. Aug 19 16:18:05 fray_: I am using gdbserver and gdb. Aug 19 16:18:16 correct, but it should contain the dwarf references to /usr/src/debug.. which path is it saying "/no such file or directory' to? Aug 19 16:19:06 fray_: 81 ../sysdeps/unix/syscall-template.S: No such file or directory. Aug 19 16:19:25 906 src/foo.c: No such file or directory. Aug 19 16:19:29 src/foo.c is my own file. Aug 19 16:19:31 ahh.. ok.. there will be some sources that are not available Aug 19 16:19:49 Did you compile this using OE, or directly with the compiler? Aug 19 16:20:13 fray_: bitbake foo-core-image-dbg Aug 19 16:20:33 if you compiled with OE, it build the -dbg package and moved all of the references.. if you build this one item by hand, the reference won't be moved and you'll have to add an additional source search path to GDB Aug 19 16:20:37 ./tmp/work/foo-foo-linux-gnueabi/foo-core-image-dbg/1.0-r0/rootfs/usr/src/debug/foo/AUTOINC+0c2cbe33e653afa335ca25156d293552001228fa-r0/git/src/foo.c Aug 19 16:21:05 fray_: I am only using bitbake, nothing outside of it in this experiment. Aug 19 16:21:07 the syscall-template.S and a few others usually won't be available to you.. these files are not available to the code that does the redirect.. Aug 19 16:21:17 fray_: if I specify -d ./tmp/work/foo-foo-linux-gnueabi/foo-core-image-dbg/1.0-r0/rootfs/usr/src/debug/foo/AUTOINC+0c2cbe33e653afa335ca25156d293552001228fa-r0/git/src/ for gdb, it can see the source Aug 19 16:21:22 but it cannot find it by default ... Aug 19 16:21:24 ok, then check the log files for the build of your app.. check that there are no warnings or errors from the do_package step that were missed.. Aug 19 16:21:36 the debugedit program should have written the references directly.. Aug 19 16:21:52 ok, well, apparently it did not then. Aug 19 16:21:56 The other thing you can do is use readelf and dump the dwarf information. You should see the source references in the dwarf info Aug 19 16:22:18 debugedit will give diagnostics on not being able to find (and thus not rewrite) specific debug files.. Aug 19 16:22:46 those won't be available in the -dbg file... like I said, the syscall one is usually the case.. since that is inherited from the libgcc.a... but your .c file should be avaialble Aug 19 16:22:51 fray_: no sign of warnings and errors. Aug 19 16:23:14 then check the readelf output for the dwarf symbols (of the .debug file) and see what the source references are.. Aug 19 16:24:37 fray_: how to do that? Aug 19 16:24:55 I'll look quickly.. Aug 19 16:25:01 readelf -a foo | grep -i dwarf -> gives no results. Aug 19 16:25:15 --dwarf-depth=N Do not display DIEs at depth N or greater Aug 19 16:25:16 --dwarf-start=N Display DIEs starting with N, at the same depth Aug 19 16:25:16 or deeper Aug 19 16:25:16 not foo, the .debug version.. Aug 19 16:25:22 do not worry, that is foo Aug 19 16:25:24 .debug/foo Aug 19 16:25:30 with the long pa th Aug 19 16:27:08 still looking for the right option Aug 19 16:27:59 readelf --debug-dump .debug/foo Aug 19 16:28:05 look at the output for Aug 19 16:28:28 DW_AT_comp_dir and DW_AT_name Aug 19 16:28:48 the -dir- entry specifies the directory of the debug source, while the -name- is the filepath within that directory Aug 19 16:28:58 too bloated output Aug 19 16:29:32 anyway, it shows the right directory. Aug 19 16:29:36 yet the source is unavailable. Aug 19 16:29:53 from a busybox I had handy: Aug 19 16:29:54 <18> DW_AT_name : ../sysdeps/i386/start.S Aug 19 16:29:54 <30> DW_AT_comp_dir : /home/mhatle/git/oss/oe-core/build-toolchain-sdk/tmp-eglibc/work/i586-windriver-linux/lib5-eglibc/2.19-r0/eglibc-2.19/libc/csu Aug 19 16:30:17 in that case, it's a file that was outside of the sources for busybox.. so it didn't get rewritten as it can't find the file.. Aug 19 16:30:42 ... but in the following case, it did ... Aug 19 16:30:42 <20e> DW_AT_name : (indirect string, offset: 0x511): libbb/appletli Aug 19 16:30:42 b.c Aug 19 16:30:43 <212> DW_AT_comp_dir : (indirect string, offset: 0x26c): /usr/src/debug/busybox/1.22.1-r32/busybox-1.22.1 Aug 19 16:31:02 I do not know why Yocto is generating wrong .debug/foo Aug 19 16:31:13 it surely does not work. Aug 19 16:31:19 whats 'wrong' with it? You said the path changed -- but GDB isn't finding it? Aug 19 16:31:36 in the example above.. the first case can't be resolved.. there is no way around that.. Aug 19 16:31:49 the second case worked fine and it was rewritten and the file is available at that path Aug 19 16:32:05 path changed? Wait, what? Aug 19 16:32:17 I am just saying that I cannot browse the source code since gdb cannot find it. Aug 19 16:32:32 I understadn that.. the dwarf symbols are what tell GDB what to browse.. Aug 19 16:32:39 if the dwarf info is wrong, GDB won't find it.. Aug 19 16:32:50 ok, so it is wrong then, or the issue is elsewhere. Aug 19 16:32:51 so start with is the dwarf correct or not.. if it's correct.. then there is a different issue Aug 19 16:33:25 So is the DW_AT_comp_dir of your foo.c correct (as it would appear on the target filesystem)? Aug 19 16:33:39 format is /usr/src/debug/// Aug 19 16:34:23 yes Aug 19 16:34:34 yet, gdb does not find it, regardless. Aug 19 16:34:48 if the path is written properly.. and then you verify the file DW_AT_comp_dir/DW_AT_name exists in the -dbg package.. then we know the files are correct, and it's a GDB configuration item Aug 19 16:35:24 Inside of GDB there is a 'set substitute-path' option, that will allow you to tell GDB to replace '/usr/src' with your local rootfs path... try that.. Aug 19 16:35:42 I already use set sysroot Aug 19 16:36:08 https://sourceware.org/ml/gdb/2014-08/msg00077.html Aug 19 16:36:23 you will have to determine what the path that the cross-gdb is trying to read is.. I don't have a simple way to reproduce this at this time.. (I don't have any rootfs or targets confgiured to try it) Aug 19 16:37:11 looking at that email.. the syscall-template.S won't be found.. you need to ignore that Aug 19 16:37:14 well, all I can say is that it does not work. Aug 19 16:37:17 however the src/bar.c should be Aug 19 16:37:25 well, it is not. Aug 19 16:37:36 HOWEVER, I would have expected GDB to say '/usr/src/debug/recipe/ver/path/src/bar.c" Aug 19 16:38:05 and since it did not, I don't know what path it's trying to load Aug 19 16:38:26 again, it should be referencing the two DWARF entries to build a full path and referencing it inside of the sysroot Aug 19 16:38:40 too many "should be" :) Aug 19 16:38:42 thats what it -should- be doing, if it's not, I don't know if it's a GDB bug, or something else Aug 19 16:40:24 well, can I say that I am extremely annoyed? Aug 19 16:40:32 as an end user I expected this just to work. :( Aug 19 16:40:49 I guess the workaround is to put shitload of -d parameters into the gdb command, but it is uncool. Aug 19 16:41:01 or figure out why it's not working and lets get it fixed.. Aug 19 16:41:18 I have no any idea why it does not work, nor any clue what to look for, whatsoever. Aug 19 16:41:27 sysroot + dwarf symbols.. and/or the path substitution should resolve everything.. again if it doesn't something is wrong Aug 19 16:42:50 I think I will work it around anyhow; and I am letting Don Quixote stay in his book. Aug 19 16:46:41 fray_: http://paste.kde.org/poejyt397 -> this is the dwarf thingie. Aug 19 16:47:36 fray_: is this OK? Aug 19 16:49:38 I don't see anything obviously wrong with it Aug 19 16:50:38 fray_: and with the gdb command? Aug 19 16:55:26 fray_: the thing is that I do not even know what or where to debug to pin this issue down... it just looks so esoteric ... Aug 19 16:57:24 * lpapp is wiping stuff away again to see if that fixes it .... Aug 19 16:57:38 all I can suggest is to have GDB (debug?) print out the path it's looking for.. but the sysroot is obviously working with the binary bits.. since they're loading Aug 19 16:58:43 fray_: I do not know how to print that out. Aug 19 16:58:48 sysroot is obviously good, yeah. Aug 19 17:19:27 fray_: btw, why shall I ignore the first warning anyhow? Shouldn't Yocto be able to generate that properly? Aug 19 17:24:23 fray_: also, will you be able to verify this today or tomorrow whether it works for you? Aug 19 17:26:49 no, the referenced item is coming from gcc.. we don Aug 19 17:26:58 we don't know the path to the GCC support files.. Aug 19 17:27:12 why not? Aug 19 17:27:15 thus it can't be automatically determined.. and the .S files are rarely needed for debugging.. Aug 19 17:27:45 gcc static files (libgcc.a) are set into the .a archive at GCC build time, along with the couple of .o files that are always linked in.. Aug 19 17:28:17 since they are all .o references they can't be investigated and rewritten using the standard debugedit program. So there is no way to interogate and replace the dwarf symbols. Aug 19 17:28:42 the files though are rarely used for any regular debug purpose, as they're the _start (pre main), _end and syscall type info.. Aug 19 17:29:03 everything else (dynamically linked) will have the .debug and related rewritten and access to those files via the debugedit rewrite of the dwarf references Aug 19 17:29:08 it may be useful at times, e.g. mixing the toolchain. Aug 19 17:29:37 yes, the files themselves are likely visible to the system, but one recipe doesn't know how to get the debug of another recipe.. it's a limitation of the system Aug 19 17:30:24 so why not fix the system then? Aug 19 17:31:30 1) it's not worth it, as those files generally aren't used to debug.. 2) it's never cause me an issue.. so I havn't bothered to change it.. 3) it's never caused any of my customers an issue.. so I've never bothered to fix it.. Aug 19 17:32:14 if you need it.. suggest a fix.... but the fix itself will be in the gneeration of the gcc libgcc.a.. not in your recipe or the standard package processing.. it's very unique to this one set of early files Aug 19 17:32:20 (might affect a small piece of glibc as well) Aug 19 17:33:13 well, anyway, if you do not have more ideas, will you have time to try to reproduce it any soon? Aug 19 17:34:01 I'm not sure.. I would like to make sure this is working in the next few weeks.. but I don't know when I will get to it at this point.. (I've got a lot of product planning and personal things going on right now.. so my time is pretty limited for the next couple weeks) Aug 19 17:34:05 I am probably not doing anything magical in here, just standard Yocto, so it is probably easy to reproduce. Aug 19 17:34:18 yes, like I said, what you are doing should work, as far as I can tell.. Aug 19 17:35:27 well, the workaround for the whole gdbserver mess in Yocto is to mount a network filesystem and use full gdb on the target. Aug 19 17:35:45 (well, mess in my case, might not be for others) Aug 19 17:36:35 it has been three days now that I am trying to get this gdb(server) thing work without much success. Aug 19 17:36:46 have been trying* Aug 19 17:36:55 it is getting out-of-order now so that I need to find workarounds. Aug 19 17:38:48 I think someone should blog about how to use gdbserver with Yocto successfully. Aug 19 17:38:56 I could not find any good tutorial about it step-by-step. Aug 19 17:39:50 (which is kind of surprising since debugging is a very important part of the software development process) Aug 19 17:46:44 at one point there were instructions.. last time I looked was around YP 1.0 - 1.2 time frame Aug 19 17:47:17 the yprm is not enough for this Aug 19 17:47:30 yes, there are some standalone commands, but nothing like a step-through guide with a dummy example. Aug 19 17:49:59 (and as the practice shows that is not enough) Aug 19 21:19:26 Hey everybody Aug 19 21:19:54 Can anyone help me figure out why my LCD is shutting off after 15 minutes? Aug 19 21:35:56 theguy, console driver blanking automatically maybe ? Aug 19 21:37:22 setterm -blank 0 Aug 19 21:37:31 and see what happens. Aug 19 21:44:36 My system doesn't have setterm. I was hoping to solve the problem without it if possible? Aug 19 21:45:19 This is what I've tried so far: Aug 19 21:45:32 theguy, look for "blank" under /sys/class/graphics Aug 19 21:46:05 ok I'll look Aug 19 21:46:31 There's no "blank" under /sys/class/graphics Aug 19 21:46:41 oh Aug 19 21:46:51 oh there is under /sys/class/graphics/fb0 Aug 19 21:47:41 I've tried echo 0 > /sys/class/graphics/fb0/blank Aug 19 21:47:47 I've also tried: Aug 19 21:47:52 passing consoleblank=0 to bootargs Aug 19 21:47:58 modifying drivers/tty/vt/vt.c with static int blankinterval = 0; Aug 19 21:48:06 echo -e -n '\033[9]' > /dev/tty1 Aug 19 21:48:10 without any effect Aug 19 21:50:26 i had the same problem.. i ended up unbinding the driver vtcon Aug 19 21:51:10 apparently, after rechecking my history Aug 19 21:52:01 Oh, can you elaborate a little bit? What does that driver do? Aug 19 21:52:04 but it sounds like it might not do the trick in your case Aug 19 21:52:31 vtcon, virtual console Aug 19 21:52:48 it was responsible for blanking during no activity Aug 19 21:53:28 echo 0 > /sys/class/vtconsole/vtcon1/bind Aug 19 21:53:42 Thanks! I'll give that a try Aug 19 21:56:10 Just rebuilding the system now so can't test immediately, but I'll try and sign on here again tomorrow and let you know how it goes **** ENDING LOGGING AT Wed Aug 20 02:59:59 2014