**** BEGIN LOGGING AT Sun Jul 14 03:00:00 2013 Jul 14 14:29:54 Have any of you guys had a random problem with "unknown package" when building an image? My recipe builds totally fine when bitbaking on its own, but when I add it to my image I get this "unknown package" error. Not sure where to start to debug...! Jul 14 14:59:41 pev_: could it be because the main package for the recipe is currently empty and thus an output package for it is never produced? Jul 14 15:06:09 bluelightning: http://pastebin.com/3vHDsgtC Jul 14 15:06:35 Ive just been trying a simple test case to see if I can work out what's going on Jul 14 15:07:55 pev_: you've installed the library into two subdirectories; I think that will mean the default value of FILES_${PN} won't pick it up Jul 14 15:08:27 pev_: you can check by looking in packages-split in the workdir for the recipe Jul 14 15:25:33 bluelightning: Two subdirectories? should just go into ${D}${libdor}/libtest/modules? Jul 14 15:26:24 bluelightning: What am I lookinf for in packages-split? Sorry, not sure what you mean by that... Jul 14 15:26:46 pev_: that's where you can see which files ended up in each package Jul 14 15:26:57 Ah... Jul 14 15:27:16 Thats why I was confued - the .so doesn't seem to be in there at all, just the .c file! Jul 14 15:27:52 So I need to debug my .so until I see the .so end up in there correctly? Jul 14 15:28:01 Sorry, debug the .bb rather Jul 14 15:28:16 pev_: the default value of FILES_${PN} only includes "${libdir}/lib*${SOLIBS}" for libraries (where ${SOLIBS} is ".so.*") Jul 14 15:29:01 pev_: so if you want the installed library to be picked up you need to add "${libdir}/libtest" or similar to FILES_${PN} Jul 14 15:29:19 aren't you getting unshipped file warnings when building the recipe? Jul 14 15:30:16 Ah, yes - I was but hadn't realised that was the meaning! Jul 14 15:30:17 :-D Jul 14 15:31:01 ok, just checking :) Jul 14 15:32:03 pev_: btw in our discussion the other day I forgot to mention that $D (note though, not ${D}) is set when postinstalls run on the host Jul 14 15:32:24 pev_: thus you can use $D in paths to make the script work in both places (or check where it is running if you need to) Jul 14 15:32:34 but maybe you already figured that out Jul 14 15:34:59 Ah, cheers - not yet, I've been trying to get the full build working first (ie this error) before I can move onto debuggint the .conf file munging! Jul 14 16:36:54 So i added FILES_${PN} = "${libdir}/libtest" Jul 14 16:37:12 and now i get Jul 14 16:37:15 ERROR: QA Issue: non debug package contains .debug directory: lib-test path /work/armv7a-vfp-neon-amltd-linux-gnueabi/lib-test/1.0-r6/packages-split/lib-test/usr/lib/libtest/modules/.debug/lib-test.so Jul 14 16:39:55 pev_: yes, you have a debug file in your package. debug files need to be in -dbg packages Jul 14 16:41:17 zecke, Is that something that was created automatically? What should I do then? I'm just building from a trivially simple makefile! Jul 14 16:43:49 pev_: maybe change your glob to "${libdir}/libtest/*.so" ? Jul 14 16:44:08 pev_: or make sure the -dbg package is before your -libtest package in PACKAGES Jul 14 16:46:52 sorry, glob? Jul 14 16:47:05 On the package front I'm only wanting to make one thing...! Jul 14 16:47:21 It's such a simple thing, how hard can it be! :-/ Jul 14 16:49:32 pev_: "man glob", we are building on the shoulders of giants. Jul 14 16:49:39 zecke : http://pastebin.com/U61xGeVb Jul 14 16:49:46 It should be that simple?! Jul 14 16:50:35 zecke: Oh you mean the glob for the package.. Gotcha Jul 14 16:50:36 pev_: I don't see the "FILES_${PN}" you apparently added. ;) Jul 14 16:51:49 pev_: files are picked up in the order declared in PACKAGES Jul 14 16:52:08 FILES_${PN} = "${libdir}/libtest/modules/" Jul 14 16:52:49 If i change to : FILES_${PN} = "${libdir}/libtest/modules/*${SOLIBS}" Jul 14 16:53:04 I get ERROR: Error executing a python function in /workdrive/projects/vibe/src/opt/amltd/poky/meta-vibe/recipes-skeleton/lib-test/lib-test.bb: Jul 14 16:53:10 and a load of nasty debug Jul 14 16:53:30 pev_: can you pastebin it? Jul 14 16:53:44 sure Jul 14 16:54:11 pev_: add this to remove the QA issue: FILES_${PN}-dbg += "${libdir}/libtest/modules/.debug" Jul 14 16:55:32 http://pastebin.com/ED0dnw7L Jul 14 16:56:28 FILES_${PN} = "${libdir}/libtest/modules/" Jul 14 16:56:28 FILES_${PN}-dbg += "${libdir}/libtest/modules/.debug" Jul 14 16:56:37 Generates the python error Jul 14 16:56:49 too Jul 14 16:58:09 pev_: that is odd... try bitbake -c clean lib-test and then try again Jul 14 16:58:48 would incrementing PR help the same? I've been doing that Jul 14 16:59:24 same pyth error after clean Jul 14 17:00:58 actually - given that I've incremented PR to r11 now - why does the python error say "Exception: OSError: [Errno 2] No such file or directory: '/workdrive/projects/vibe/src/vibe_p81_build/tmp/work/armv7a-vfp-neon-amltd-linux-gnueabi/lib-test/1.0-r4/packages-split/lib-test-dbg'" Jul 14 17:01:01 r4? Jul 14 17:01:23 knickers == twisted Jul 14 17:02:47 Is there any more heavy cleaning I can do than -c clean thats a step down from rebuilding everything as I don't want to wait 30 mins...!? Jul 14 17:03:11 pev_: bitbake -c cleansstate lib-test Jul 14 17:03:29 but we're already getting into quite odd behaviour, this shouldn't be happening Jul 14 17:03:34 FWIW I am trying your recipe here Jul 14 17:03:54 cleanstate : still gives same pyth error after! Jul 14 17:04:17 Thanks - it's appreciated! Still mindboggled Im tripped up by something so apparently simple! :-D Jul 14 17:07:02 pev_: you're sure you only have one copy of this recipe accessible from this build configuration? Jul 14 17:08:45 bluelightning, find . -name "lib-test*.bb" says yes Jul 14 17:10:25 ok, I just built it here and it built fine Jul 14 17:12:04 ??? Jul 14 17:12:24 you could try bitbake -e lib-test | less and see what the values of PR and PKGR are Jul 14 17:13:21 both at r11 Jul 14 17:15:42 So you tested the version I pastebinned plus the two FILES_lines as above? Jul 14 17:15:58 pev_: yep, exactly that Jul 14 17:16:11 pev_: what about PKGDEST? what does it say that is at? Jul 14 17:16:40 too late - ive just run through deleting all the dirs manually... Jul 14 17:17:26 hmm, I was hoping we could debug it Jul 14 17:17:30 oh well Jul 14 17:17:36 sorry...! Jul 14 17:18:08 No doubt I'll manage to break it again before too long... Jul 14 17:19:42 pev_: are you using a custom DISTRO, poky, or something else? Jul 14 17:20:41 Its a version of poky - came from some developer here. Its yocto 1.4 with what looks to be a load of stuff from current git put in as well Jul 14 17:21:08 ah ok Jul 14 17:21:16 reason I asked is I wonder if the PR server is enabled Jul 14 17:21:33 Thats waaaay out of my depth... Easy to check? Jul 14 17:21:34 (just trying to think how PR could not be the value you expect it to be) Jul 14 17:22:00 I think bitbake -e | grep ^PRSERV Jul 14 17:23:54 that shows no matches Jul 14 17:24:07 OK, so while that now seems to build the recipe ok Jul 14 17:24:09 hmm ok... that's what I'd expect if it was not enabled Jul 14 17:24:15 I still cant get it into the image.... Jul 14 17:24:48 pev_: if you look in packages-split does the main lib-test package have any files in it? Jul 14 17:25:15 Hm, no the .so, no Jul 14 17:25:23 so back to the original supposition then! :-D Jul 14 17:25:37 FILES_${PN} must still be incorrect hen Jul 14 17:25:39 then Jul 14 17:26:34 er Jul 14 17:26:48 here the main package does have the file in it Jul 14 17:26:59 yep Jul 14 17:27:16 I'd used the *{SOLIBS} but it seemed not to match. Gone back to just the dir Jul 14 17:27:44 right, ${SOLIBS} is designed for versioned libraries, which this isn't Jul 14 17:28:32 Aha. Gotcha Jul 14 17:29:10 Yep, that looks like it's now working, thanks. Now try that with my actual recipe! Jul 14 19:57:01 I'm receiving this when attempting a build of meta-toolchain-qte http://pastebin.com/jxueuk9n I have bzip built so I'm confused? Jul 14 19:59:02 oops pastebin didn't get the whole thing Jul 14 19:59:41 ends on cannot satisfy the following dependencies libz2 (>= 1.0.6) Jul 14 20:01:00 I can do bitbake bzip2 -c devshell and I verified that it is building the 1.0.6 version Jul 14 20:29:46 Is there a common recommendation for handling configuration of package features? I'm trying to lean how to write recipes by packaging linphone, this software however has the option to enable or disable video calls. How should that be handled? Jul 14 20:31:22 Always including the video feature would add quite a list of dependencies, which I guess is not always OK. Jul 14 20:35:15 dnil: e.g. if the video functionality is just a plugin.. always build it but put into a different package Jul 14 20:35:25 dnil: when it influences the core.. then it is more difficult Jul 14 20:36:24 zecke, it influences the core as well as libs that linphone depends on. Jul 14 20:38:49 dnil: then it is a difficult call. If you need video right now, enable it, otherwise not? but that is just my opinion.. maybe there are more specific rules nowadays Jul 14 20:43:55 zecke, Yes, that is what I have done for now. Just curious if there exist any existing best practice how to handle this. One idea I had in this case was to check the machine features for the existence of a screen and allow that to decide video on/off. Jul 14 20:53:01 dnil: we have a mechanism called PACKAGECONFIG which can be used on a per-recipe basis to enable/disable functionality particularly where it might add additional dependencies Jul 14 20:55:44 bluelightning, OK thanks. Found it in the manual now. I will look into that , sounds like what I need **** ENDING LOGGING AT Mon Jul 15 02:59:58 2013