**** BEGIN LOGGING AT Fri Jan 17 02:59:58 2014 Jan 17 06:54:16 hi all i try build qt4 i got the below error while compiling http://pastebin.com/AYaU4Htx can you please help me Jan 17 14:10:47 hi all Jan 17 14:12:03 Does anyone try to use CAN with core-image-sato-crownbay.hddimg? Jan 17 16:40:32 again on this error : ERROR: QA Issue: non debug package contains .debug directory: fcgi path /work/armv7a-vfp-neon-poky-linux-gnueabi/fcgi-0.25-r0/packages-split/fcgi/www/pages/.debug/fast.fcgi in my recipe, I add : FILES_${PN}-dbg += "/www/pages/.debug" \ FILES_${PN} += "/www" \ and I always get the same error. When the script were installed in /usr/bin I were using FILES_${PN}-dbg += Jan 17 16:40:32 ${bindir}/.debug" and it was working. Any hint here ? Jan 17 16:43:52 weebet: are you using the default PACKAGES list or do you have a custom one in your fcgi recipe? Jan 17 16:46:03 sgw_ I bet I have the default one, because I don't know what is the PACKAGES list Jan 17 16:46:17 sorry, PACKAGES="${PN} Jan 17 16:46:18 " Jan 17 16:49:09 weebet: if all you have is ${PN} in your packages list it won't packge the $PN-dbg files, you need ${PN}-dbg ${PN}, or remove that line and use the default list. Ordering is important for PACKAGES since it is a "greedy" list meaning once it finds files earlier in the list it won't find them again if they are in the same paths later in the list, does that make sense? Jan 17 16:50:11 sgw_ I removed that line and yes it makes sense ! Thank you a lot ! I had this problem for few days !!! You are my today's HERO! Jan 17 16:51:00 weebet: glad to help. Jan 17 17:00:40 anybody knows how to change the default ip address of the gumstix-console-image ? Jan 17 17:22:48 Hi folks - is there a way to specify a minimum image size - that is, if my rootfs is smaller, I'd like Yocto to automatically pad the size to that minimum Jan 17 17:26:29 wrotte: I think you need to set IMAGE_ROOTFS_SIZE Jan 17 17:26:33 wrotte, have you tried IMAGE_ROOTFS_SIZE Jan 17 17:26:36 damn. Jan 17 17:26:39 http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#var-IMAGE_ROOTFS_SIZE Jan 17 17:26:41 two seconds to late :) Jan 17 17:26:42 heh Jan 17 17:27:08 zeddii: btw, while you're here :) I am sending the aufs-util patch for meta-filesystems Jan 17 17:27:27 Thanks guys, that's what I was looking for. It's sometimes hard to locate needles in the haystack that is the exhaustive documentation Jan 17 17:27:30 zeddii: I still didn't test it at runtime, don't have the time I'm afraid Jan 17 17:27:54 wrotte: indeed, no problem Jan 17 17:28:20 bluelightning, cool. I just updated aufs to 3.13, so when you send it, I'll see about taking it for spin. Jan 17 17:28:25 wrotte: FWIW, if I answer with a manual link that shouldn't be construed as "RTFM" - more like "here's some more info so I don't have to type it" :) Jan 17 17:29:04 bluelightning: Certainly wasn't taken that way. Direct links to manuals are always appreciated Jan 17 17:29:10 :) Jan 17 17:41:47 creating an image, I can do : bitbake systemd-custom-script . But when I insert in an image : systemd-custom-script bitbake tells me that it is unable to resolve package systemd-custom-script . Any advice to help me debug this ? Jan 17 17:42:28 weebet: in the first instance, that's a recipe name; in the second instance it's a package name Jan 17 17:43:14 weebet: normally, a recipes produce a main package named the same as itself, but if PACKAGES has been modified in the recipe to remove ${PN} then that may not be the case Jan 17 17:43:26 a recipe produces* Jan 17 17:43:58 weebet: when you say "unable to resolve" what is the exact error? Jan 17 17:45:41 The error was exactly that, unable to resolve. Following your advice, I added PACKAGES = "${PN}" and now it is working ! Today every issue is caused by PACKAGES... one recipe I have to remove PACKAGES, and the other one I have to add it... Jan 17 17:47:38 weebet: that's odd, because ${PN} is already in the default value of PACKAGES, so you shouldn't need to do that Jan 17 17:48:23 Thank you bluelightning ! Jan 17 17:49:17 i take it there were recent changes in the cmake stuff on master? Jan 17 17:49:40 mr_science: there were, yes Jan 17 17:49:54 my mupdf recipe broke last night Jan 17 17:50:21 so did openjpeg but that one i fixed Jan 17 17:50:32 mupdf is a biatch... Jan 17 17:51:28 any hints on appropriate recipe updates? Jan 17 17:53:42 mr_science: rburton sent some related fixes for meta-oe that might be instructive, starting here: http://lists.openembedded.org/pipermail/openembedded-devel/2014-January/093736.html Jan 17 17:55:51 thanks Jan 17 17:56:06 * mr_science is behind on his list reading Jan 17 17:56:43 got to go see the gastro guy yesterday... Jan 17 18:09:32 mr_science : did you ate these ? http://www.amazon.com/Haribo-Gummy-Candy-Sugarless-5-Pound/product-reviews/B000EVQWKC/ref=cm_cr_pr_btm_link_3?ie=UTF8&pageNumber=3&showViewpoints=0&sortBy=byRankDescending Jan 17 18:51:20 Query: Let's say I'm making some changes in the Linux kernel; so I 'bitbake -c devshell'; make my changes; 'bitbake -c compile -f' to build the thing, then 'bitbake -c deploy'; then runqeumu. This is a rather lengthy process. Is there some faster way to test an updated bzImage without manually copying it to the images directory? Jan 17 18:55:00 wrotte: well, you can get rid of the deploy step if you do bitbake -C compile instead of bitbake -c compile -f Jan 17 18:55:34 also, doesn't devshell automatically taint nowadays? I expect bitbake -c devshell kernel; bitbake kernel; would do Jan 17 18:55:34 bluelightning: Ahh, ok. So the '-C' will put the bzimage in the right place? Jan 17 18:55:45 no, -C says 'run this task, then run the default task' Jan 17 18:55:52 kergoth: devshell won't, menuconfig does though Jan 17 18:55:53 which happens to include deploy Jan 17 18:55:57 Gotcha, thanks Jan 17 18:56:00 bluelightning: oh, right, good call Jan 17 18:56:23 The deploy is what seems to take quite a long time Jan 17 18:57:35 the downside to the -C approach is it runs more than just deploy, it'll also re-run the packaging tasks, which can take a while due to the kernel module packaging Jan 17 18:57:44 so your original approach might still be the best for a rapid test cycle Jan 17 18:59:04 well, you should be able to do bitbake -C compile -c deploy Jan 17 19:01:21 good point Jan 17 19:12:43 Aha, thanks Jan 17 19:13:39 sounds like that's the ideal solution for your use case. i wonder if the yocto kernel docs cover that method, or if they still use -f Jan 17 19:20:02 well, I guess it depends on what part of the kernel you're testing Jan 17 19:20:12 if you want to test modules you probably want the packages Jan 17 19:20:53 guess it depends on your delivery mechanism :) Jan 17 19:26:01 I've often thought some kind of mechanism to just update packages for a recipe on the target as part of the build would be useful, but I never got around to trying to write support for that Jan 17 19:52:17 * zeddii just saved 2 minutes off kernel install. Jan 17 19:53:07 \o/ Jan 17 19:53:33 zeddii, rm -rf isn't a valid solution to kernel installing Jan 17 19:56:27 let's just say that the install step, doesn't make me want to poke my eyes out. Jan 17 21:16:55 what, mklibs-native sucks in both python-native and dpkg-native? Jan 17 21:16:57 * kergoth grumbles Jan 17 21:52:12 i love it when upstream pulls the rug out from under my recipes... Jan 17 21:52:41 otherwise i'd have nothing to do... Jan 17 21:53:20 hehe Jan 17 21:53:32 % is helpful at least for non-specific stuff like distro policy adjustments Jan 17 21:53:37 (the PV wildcard) Jan 17 21:54:55 this time the whole cmake dir disappeared Jan 17 21:55:14 recipe uses cmake, new source tree uses autotools Jan 17 21:56:06 ouch Jan 17 21:56:25 yeah, not exactly a quick fix Jan 17 22:17:47 I've had a couple of recent Hilarious Mishaps involving bitbake expansion failures. And in most cases, the first thing I want to do is find out the values of various other variables involved. But, of course, bitbake -e fails because it can't expand those values. Jan 17 22:18:00 And I have a crazy thought, which might be doable, but which I had better run past people before putting time into it. Jan 17 22:18:33 Which is: Have bitbake -e imply a significant change such that exceptions caught during variable expansion are caught and logged, rather than terminating expansion. Jan 17 22:19:23 So instead of getting a fatal error saying just what failed to expand, you get the full normal output, with all the things which expanded successfully displayed with their resulting values, and with an extra log line or two in the failed expansions indicating what went wrong trying to expand them. Jan 17 22:20:48 bitbake -e should be usable, it'll just show the failure messages inline with the output Jan 17 22:20:58 exceptions are supposed to be output as commented text next to the unexpanded value Jan 17 22:21:02 Hmm. Jan 17 22:21:02 if that's not the case it's a bug Jan 17 22:21:11 It is indeed not (always) the case. Jan 17 22:21:27 best to open a bugzilla bug if you can nail it down with a reproducer :) Jan 17 22:21:46 Although that may be specific to some failures. The one that bit me most recently was a kernel bbappend which broke the kernel recipe's attempts to derive branch names and threw FetchErrors. Jan 17 22:22:12 It's also possible that this is a thing which is now fixed in upstream bitbake and not in the slightly older version I'm mostly working with. I might have a look at it, though. Jan 17 22:22:45 Mostly, I wanted to see whether anyone found the idea of bitbake catching the exceptions and reporting them rather than aborting unacceptable, which would be a barrier to further investigation. :) Jan 17 22:22:58 * kergoth nods Jan 17 22:23:09 clearly its acceptable, since thats what it should be doing, and has done int he past ;) Jan 17 22:23:27 -e aborting is pretty useless to everyone, as clearly -e is a debugging aid Jan 17 22:23:32 inspection tools are important Jan 17 22:39:03 Anyone in here know why if I do a build I cannot boot into a u-boot prompt? I know my board settings are correct to boot from the SD card etc. Jan 17 22:39:38 The build succeeded with no errors Jan 18 00:32:55 Hmm, recent kernels require bc, but I don't think we have bc-native being pulled in appropriately at this time Jan 18 00:35:25 right I'm adding it manually in recent enough kernels Jan 18 00:36:20 http://patchwork.openembedded.org/patch/56663/ Jan 18 00:39:50 ah Jan 18 00:40:00 heh, i link landley's original dep reduction patch dropped perl without requiring bc Jan 18 00:40:03 s/link/think **** ENDING LOGGING AT Sat Jan 18 02:59:59 2014