**** BEGIN LOGGING AT Thu Jun 05 02:59:58 2014 Jun 05 06:15:24 morning Jun 05 06:59:33 mago_ : I have an image recipe called x_image.bb and another called y_image.bb. I am trying to create x+y_image.bb using both. So I included "require y_image.bb" in "x_image.bbappend" and added the line "IMAGE_INSTALL += "y_image". Jun 05 06:59:44 Am I doing it right? Jun 05 07:25:49 milan__: i don't think you need the last part. each image recipe should add their own 'packages' in IMAGE_INSTALL. when you combine the 2, IMAGE_INSTALL should be populated with both content. Jun 05 07:26:19 of course you need to make sure that none of your image is 'reseting' IMAGE_INSTALL, so you need to use += (append) Jun 05 07:27:11 also, i think you want to put require y_image and require x_image in x+y_image recipe Jun 05 07:27:33 if you add something in x_image.bbappend, it will be used only when building x_image recipe, not x+y_image Jun 05 07:29:42 ndec: Ahh yes...precisely that's what I want. Expanding x_image with extra packages from y_image. Hence the x_image.bbappend. Jun 05 07:30:10 ok, so you don't want x+y_image recipe, in fact. Jun 05 07:31:03 ndec: Yes...Sorry for making in confusing with x+y. The idea is to extend x_image only. Jun 05 07:31:34 ok. then yes you can add require y_image in x_image.bbappend Jun 05 07:31:51 then when you build x_image it will parse (and include) the content of y_image recipe Jun 05 07:31:58 ndec: but if there are common packages as part of both x_image & y_image, will it take care internally? Jun 05 07:32:07 IMAGE_INSTALL += y_image is not valid. Jun 05 07:32:30 what do you mean by 'common packages'? Jun 05 07:32:36 yes ... got the IMAGE_INSTALL part. Thanks Jun 05 07:33:18 you define what gets pulled into an image by specifying the packages in IMAGE_INSTALL. basically if you require y_image from x_image, then you just add more packages in IMAGE_INSTALL Jun 05 07:33:31 the dependencies are managed like for any image Jun 05 07:35:01 Ok...since we sometimes get warnings saying a package is provided by two package groups...and we need to provide the PREFERRED_PROVIDER Jun 05 07:35:14 Hence asked this question Jun 05 07:35:43 i see. but that's a different problem then. Jun 05 07:36:24 Well my x_image and y_image are contsisting of packagegroups Jun 05 07:36:45 if x_image pulls in foo1 and y_image pulls in foo2 which both provides the same 'files', yes, you will get issues. Jun 05 07:37:33 e.g. one (x) consists of packagegroup-core-lsb & and the other(y) packagegroup-core-lsb-core Jun 05 07:37:37 in fact adding require y_image in .bbappend is exactly as if you copy/paste the y_image.bb file content into x_image.bb. Jun 05 07:38:11 Hmm...got it! Jun 05 07:38:36 Then I may need to manually resolve these package conflicts when they appear I guess ? Jun 05 07:38:54 yes. Jun 05 07:39:32 Ok...let me try that part out now then. Thanks a lot for helping me out :) Jun 05 07:39:58 in your example, i believe core-lsb is a superset of core-lsb-core already. so that should work. Jun 05 07:40:30 Exactly ! It's a superset actually. Jun 05 08:08:18 good morning Jun 05 08:38:45 ndec: Is it possible to include a line into local.conf based upon arch ? e.g. lsb tests are specific to x86 & ppc only...so I want to add a conf file to local.conf when ARCH is x86 or ppc ? Jun 05 08:39:51 what do you want to put in this conf file? Jun 05 08:40:20 some DISTROOVERRIDES & DISTRO_FEATURES stuffs Jun 05 08:41:10 i don't think you can do exactly that. but you can use MACHINE overrides when setting variables Jun 05 08:41:25 e.g. IMAGE_INSTAL_append_armv7 = " foo" Jun 05 08:41:25 ok Jun 05 08:41:47 hmm...fine. Let me try that. Jun 05 09:06:25 morning all Jun 05 11:03:25 how can I ask Yocto to install libraries/headers into my SDK as well ? Jun 05 11:12:34 rink_, see TOOLCHAIN_TARGET_TASK and TOOLCHAIN_HOST_TASK Jun 05 11:13:01 and "-c populate_sdk" Jun 05 11:13:55 it seems by default it won't add things to the SDK - suppose I want to add libsdl2 there? Does this involve messing with .bbappend then ? Jun 05 11:14:45 rink_, do you use "-c populate_sdk" for creating the SDK ? If so, if you have libsdl2 in your target image, it should put libsdl-dev in the SDK Jun 05 11:15:10 rink_, you can add additional packages using the two variables ^ Jun 05 11:24:24 hmm populate_sdk is different from meta-toolchain ? Jun 05 11:28:35 hello Jun 05 11:28:57 I'd like to use a custom device tree with my custom bps Jun 05 11:29:00 bsp Jun 05 11:29:20 anybody having a minute to assist me? asking google did not help so far Jun 05 11:29:46 I'd rather not set up a separate kernel source branch Jun 05 11:36:03 rink_, i think populate_sdk is the preferred way for creating sdk's Jun 05 11:36:36 rink_, it will include developer/debug packages for the target image in the sdk Jun 05 11:47:43 petero, what I did was just add the file to the kernel using a .bbappend and set it using KERNEL_DEVICETREE Jun 05 11:48:31 i thought i'd put it under files in my bps's recipes-kernel/linux Jun 05 11:48:49 and set that variable in my linux-yocto_3.10.bbappend file Jun 05 11:48:54 but two questions remain Jun 05 11:49:16 KERNEL_DEVICETREE is set in my machine's conf file, not in my kernel recipe Jun 05 11:50:06 second: if i add the dts file to my SRC_URI, how do i refer to that file in the KERNEL_DEVICETREE variable? is it ${S}? Jun 05 11:50:43 rink_: I created a packagegroup-qt5-toolchain-target.bbappend and added stuff there Jun 05 11:51:52 is there a simple way to have a recipe produce two packages, and then include one of them depending on image name? Jun 05 11:52:47 petero, what I did was: in recipes-kernel/linux/linux-imx-3.10.17/git/arch/arm/boot/dts/ place the files i needed Jun 05 11:53:25 rink_, thanks, i will try that Jun 05 11:53:29 in the "linux-imx_3.10.17.bbappend", SRC_URI += file://git/arch/arm/boot/dts/... Jun 05 11:53:37 and keep the KERNEL_DEVICETREE in the machine conf Jun 05 11:53:55 only one TODO for me: the file is built correctly now and placed in the tmp/deploy/images/ dir Jun 05 11:54:05 but it won't be part of the tar.bz2, no idea why that is Jun 05 11:54:30 I think my bbappend misses a line for that, but haven't dug into it yet Jun 05 11:56:00 rink_: if you add kernel-devicetree to your IMAGE_INSTALL you should get the dtb in /boot. not sure if that is what you wanted. Jun 05 11:56:46 oh, thanks, that's what I need Jun 05 11:57:14 and kernel-image to get the zImage/uImage there as well Jun 05 11:57:16 tasslehoff, and then refer to that device tree by a boot parameter? Jun 05 11:58:15 petero: isn't that a u-boot environment variable? Jun 05 11:58:24 new at device tree myself :) Jun 05 11:58:53 yeah, getting a bit confused %-/ Jun 05 11:59:23 have to do some homework on that, first Jun 05 11:59:48 I currently make a manual uboot boot script Jun 05 11:59:58 need to figure out how to plug that into yocto Jun 05 12:04:29 rink_: on my targets (beagleboard & wandboard) the boot.scr will be sources automatically if put in the correct place. Jun 05 12:04:59 for me the right place is fat32 boot-partitions on mmc Jun 05 12:15:59 rink_, tasslehoff, thanks for your help Jun 05 12:17:06 can anyone point me to somewhere where there is an explanation for how to make a recipe that produces two packages Jun 05 12:18:38 http://www.yoctoproject.org/docs/1.1/poky-ref-manual/poky-ref-manual.html#splitting-an-application-into-multiple-packages Jun 05 12:18:43 OK, found it Jun 05 12:29:42 xerent_: that's the 1.1 manual, that's ancient Jun 05 12:34:51 is the information out of date? Jun 05 12:35:40 basically I have a recipe which compiles an app and produces three binaries. in one image configuration, I want one of the binaries to be included, and in another, all three. Jun 05 12:35:51 well, I would always go for the version of trhe manual that matches the version of the build system that you are using Jun 05 12:36:08 newer manuals also have much more content Jun 05 12:36:45 to be fair in this specific case I think that section has hardly changed Jun 05 12:37:52 the basic concepts to be aware of is the order of PACKAGES matters; the first package listed whose FILES value matches a file, gets the file Jun 05 12:38:41 you also need to be selective when setting FILES - you shouldn't have symlink .so files in non-dev packages for example Jun 05 12:38:56 you'll get warnings for situations like that though Jun 05 12:39:19 my packages will be very simple, three binaries only Jun 05 12:40:12 now I added PACKAGES =+ "foo" to my recipe and also FILES_foo =+ "bar1" and FILES_foo =+ "bar2" Jun 05 12:40:28 but do_rootfs fails because it can't find the package "foo" Jun 05 13:00:49 it seems only the binary bar0 is installed into the PN package Jun 05 13:00:59 and the foo package is not being created at all Jun 05 13:07:06 hmm - anyone can help? The gpu-viv-bin-mx6q recipe installs a lot of useful libraries and header files, but also samples in /opt/viv_samples that only take up a lot of space Jun 05 13:07:28 so I made a ..bbappend with 'do_install_append() { rm -rf ${D}/opt/viv_samples }' Jun 05 13:07:38 which 'works' but it no longer installs anything on the target anymore Jun 05 13:07:40 what did I miss ? Jun 05 13:33:16 if I'm building an image where I have put INCOMPATIBLE_LICENSE = "GPLv3" and then want to build a -dev version of the same image but allow the extra packages like GDB to be GPLv3, can I do exceptions from that INCOMPATIBLE_LICENSE or will I have to skip that and use PREFERRED_VERSION in order to get the GPLv2 versions of e.g. coreutils? Jun 05 13:45:57 xerent_: it'll be because it's empty - empty packages are not produced Jun 05 13:46:24 xerent_: either the file is going into another package (because it matched first based on the order of PACKAGES) or you didn't get the FILES value correct in order to pick up the file Jun 05 13:54:56 OK, so I have to install all three binaries, and then for each subpackage add a subset of those binaries accordingly? Jun 05 14:00:20 otavio: you here? Jun 05 14:00:33 rink_: hi Jun 05 14:00:45 quick q, sure you can answer this immediately :) Jun 05 14:00:55 fighting with gpu-viv-bin- as usual :) Jun 05 14:01:06 I need the libs/headers, but want to get rid of the 200MB+ of samples it also installs Jun 05 14:01:07 lol Jun 05 14:01:45 so I've made a ..bbappend file with do_install_append() { rm -rf ${D}/opt/viv_samples } Jun 05 14:01:52 but then it no longer installs anything Jun 05 14:01:57 and I don't understand why Jun 05 14:03:21 I fear you need: ALLOW_EMPTY_${PN} = "1" Jun 05 14:05:34 bluelightning: http://pastebin.com/S78XGasH <- maybe your experienced eye can spot my mistake in a second Jun 05 14:05:36 What does that mean/do ? Jun 05 14:06:52 xerent_: /usr/local/bin/ in FILES vs. /usr/bin/ in do_install ? Jun 05 14:07:05 xerent_: also, use ${bindir} instead of /usr/bin Jun 05 14:07:14 well, in another recipe it works fine to use /usr/local/bin Jun 05 14:07:31 I could use bindir variable just as well though Jun 05 14:07:49 well doh Jun 05 14:07:54 there's my issue I suppose Jun 05 14:08:02 I'm looking at two differentl ocations Jun 05 14:08:03 xerent_: well, we don't generally use /usr/local in our build system; but even if we did the two places must match up ;) Jun 05 14:08:12 someone quick, hand me a gun Jun 05 14:08:15 I must shoot myself Jun 05 14:08:16 rink_: allow empty packages to be made so -dev packages can be installed Jun 05 14:08:38 ... but it still has to install the actua llib*.so on the target Jun 05 14:14:24 otavio, is it because the recipe contains FILES_{$PN} += "/opt", which is empty Jun 05 14:14:32 well now I get "Files/directories were installed but not shipped". feels like I'm missing something important about how this is supposed to work Jun 05 14:15:33 xerent_: that means whatever you have in FILES is not picking up those files Jun 05 14:16:15 the 1.1 manual says "Files included by earlier packages are skipped by latter packages." Jun 05 14:16:28 could that be the a problem, since I want to include one file in both packages Jun 05 14:17:03 xerent_: right, you cannot do that Jun 05 14:17:17 xerent_: the way to handle that is, set up dependencies such that one package pulls in another Jun 05 14:17:33 ah Jun 05 14:17:47 you can even have a dummy package that pulls in two others if desired - you'd just need to set ALLOW_EMPTY_ = "1" to let it be created even if empty Jun 05 14:18:09 DEPENDS_foo = "bar" ? Jun 05 14:18:15 RDEPENDS_foo Jun 05 14:18:23 R for runtime Jun 05 14:18:37 ok Jun 05 14:19:24 bah, why is this so damn hard for me :(( Jun 05 14:19:42 if anyone have a minute; http://git.yoctoproject.org/cgit/cgit.cgi/meta-fsl-arm/tree/recipes-graphics/gpu-viv-bin-mx6q/gpu-viv-bin-mx6q.inc installs a lot of stuff in /opt/viv_samples which I want gone from my target image Jun 05 14:20:02 I tried adding a do_install_append() as listed before which throws it all away, doesn't help at all. Jun 05 14:20:31 rink_: what does your do_install_append do? Jun 05 14:20:37 can you pastebin it? Jun 05 14:21:14 http://pastebin.com/dYEQ94gQ Jun 05 14:21:26 rink_: I've found that soft and furry keyboards is helpful when continously banging one's head against it Jun 05 14:21:40 +having Jun 05 14:22:05 [also tried the pastebin without /*, so just the directory - does not make any differece] Jun 05 14:22:29 xerent_: you're positive that path is correct? not a case of _ vs - ? (because -f with rm will mean it will not error out if you happened to have that wrong) Jun 05 14:23:03 er, rink_ not xerent_ sorry Jun 05 14:23:37 doesn't error out with just-r Jun 05 14:24:03 btw, the pastebin is the Only content of my .bbappend Jun 05 14:24:36 if I comment out the rm line, it works but the viv_samples stuff is still there Jun 05 14:27:49 rink_: maybe I'm misunderstanding - what exactly happens *with* the stuff in the bbappend? Jun 05 14:28:31 well, the end result is that the 'gpu-viv-bin-mx6q' package isn't installed in the target image Jun 05 14:29:21 let me rewind for a bit Jun 05 14:30:00 I've made "recipes-graphics/gpu-viv-bin-mx6q/gpu-viv-bin-mx6q_3.10.17-1.0.0-hfp.bbappend" in my custom layer Jun 05 14:30:43 with what I placed on pastebin Jun 05 14:30:57 with the 'rm' line active, it installs absolutely nothing in my target image Jun 05 14:31:00 well this is odd, I get QA warnings about no GNU_HASH in elf binaries for all three binaries, so they're packaged somehow, and then it fails on "Files/directories were instaleld but not shipped" Jun 05 14:31:11 so what's not shipping Jun 05 14:31:12 :D Jun 05 14:31:41 if I remove the line, or place 'echo' or whatever in it (I can find the echo in the logs, so I know it's using my bbappend file) it does install Jun 05 14:35:57 .debug stuff is not shipping Jun 05 14:36:20 xerent_: you'll need to add that to FILES_${PN}-dbg Jun 05 14:37:03 xerent_: this may be of interest (from the work-in-progress manual): http://www.yoctoproject.org/docs/1.7/ref-manual/ref-manual.html#ref-qa-checks Jun 05 14:37:11 or actually, I'll just replace my PACKAGE line with a prepend Jun 05 14:37:15 that seems to work Jun 05 14:37:37 issue was that I had no -dbg package in the PACKAGE variable Jun 05 14:37:42 ah yes I forgot to mention that, it's best to prepend/append to the existing value of PACKAGES in most cases Jun 05 14:37:42 and I did not know one was required Jun 05 14:38:04 it's only "required" if you have debug symbol files Jun 05 14:38:27 maybe i'm confusing things because no binaries are installed Jun 05 14:39:44 rink_: you can see exactly what goes into the package by looking in packages-split under the workdir for the recipe Jun 05 14:40:07 bitbake -e | grep ^WORKDIR= to find the workdir if you need to Jun 05 14:40:16 why isn't there also a packages-epic-split directory? ;) Jun 05 14:41:52 hmmm it seems the gpu-viv-bin-mx6q directory will be empty without the opt thing (as libs are places in libgles2-mx6-dev, etc) Jun 05 14:42:04 does it just skip those if the 'main' dir is empty ? Jun 05 14:42:31 maybe the others are only pulled in via that package? Jun 05 14:42:38 how would they otherwise get into your image? Jun 05 14:43:32 well in the packages-split folder, I see for example gpu-vv-bin-mx6q which only has 'opt' Jun 05 14:43:49 and e.g. libegl-mx6 which has '/usr/lib/libEGL.so' Jun 05 14:44:20 what I don't understand is, given the recipe at http://git.yoctoproject.org/cgit/cgit.cgi/meta-fsl-arm/tree/recipes-graphics/gpu-viv-bin-mx6q/gpu-viv-bin-mx6q.inc, why would it skip the lib* things ? Jun 05 14:44:36 even if I set ALLOW_EMPTY_${PN} = "1" in the ..bbappend file Jun 05 14:49:26 well this is rich Jun 05 14:49:45 either I made a typo, because setting ALLOW_EMPTY_${PN} = "1" in the bbappend seems to fix it Jun 05 15:00:52 ndec: is there a syntax to combine multiple ARCHs under a single IMAGE_INSTALL_ ? Jun 05 15:01:45 e.g. x86_64 ia64 i486 i 586 etc Jun 05 15:09:46 rink_: works? Jun 05 15:16:13 bluelightning: does IMAGE_INSTALL works with rprovides names? Jun 05 15:21:34 yes, IMAGE_INSTALL is supposed to work with rprovide names Jun 05 15:21:48 there may be cases where it doesn't, but it SHOULD work Jun 05 15:23:36 it is failing at me Jun 05 15:23:47 I have package-i586 Jun 05 15:23:52 which provides package Jun 05 15:24:02 and package in IMAGE_INSTALL Jun 05 15:24:05 and it fails Jun 05 15:26:11 fray: package-i586 has rprovides to package Jun 05 15:27:09 which package management type? Jun 05 15:27:12 rpm Jun 05 15:30:55 bluelightning: my issues are resolved now, thanks for the help Jun 05 15:31:07 and since I'm not working tomorrow, have a nice weekend Jun 05 15:31:21 xerent_: no problem, and the same to you :) Jun 05 15:31:38 otavio: with opkg yes, with rpm no Jun 05 15:31:47 otavio: there is a bug open for rpm Jun 05 15:32:28 bluelightning: ah good to know Jun 05 15:33:02 https://bugzilla.yoctoproject.org/show_bug.cgi?id=5024 Jun 05 15:33:03 Bug 5024: normal, Medium, 1.7, paul.eggleton, NEW , RPM backend cannot handle RPROVIDES in IMAGE_INSTALL Jun 05 15:33:15 oh look, it's assigned to me... :( Jun 05 15:36:05 bluelightning: I need to use something like IMAGE_INSTALL_x86-64 & IMAGE_INSTALL_ppc . Is there a way to combine both of these into a single block ? Jun 05 15:36:41 milan__: you can use _append_x86-64 and _append_ppc instead Jun 05 15:36:51 bluelightning: give me the # later, please Jun 05 15:37:21 otavio: ok, but I did just link it above... Jun 05 15:37:30 milan__: btw, this is the sort of thing that MACHINE_ESSENTIAL_RDEPENDS / MACHINE_ESSENTIAL_RRECOMMENDS are supposed to help with Jun 05 15:38:23 bluelightning : well, i didnot want to repeat the same set of package groups listed for both the archs. So I wish there was a way to combine both in to one. Hope I make sense! Jun 05 15:43:49 milan__: _append_ will do that, just appending the value if the architecture applies Jun 05 15:44:00 milan__: then you can just list the common ones in plain IMAGE_INSTALL Jun 05 15:44:22 you need to ensure you have a leading space in the _append value though since _append won't automatically add that for you Jun 05 15:45:39 bluelightning : Got it ...going to try now. Thank you :) Jun 05 16:10:32 I'm still going through the everything document, but my choice of search words doesn't seem to be very good. Anyways, I have a package that creates a build time script that I need to have available for another package during the cross build stage. Any suggestions what to search for? Jun 05 17:10:06 I should know these things by now but... is there any way to override do_install_append in a bbappend file? I know further do_install_append blocks will just append more rather than replacing the first do_install_append Jun 05 17:11:04 If not I'll just copy the whole recipe from oe-core to my layer and edit Jun 05 17:11:16 But I'd like to avoid that if possible Jun 05 18:38:24 I'm new to yocto, and I cannot figure out how to list the available software that I can add to customise my image. Jun 05 18:39:25 mtetreault: Your best bet is to search for recipes on http://layers.openembedded.org Jun 05 18:40:19 I meant on my computer. Jun 05 18:40:38 I'll explain. I have an I.mx6 base custom board Jun 05 18:41:45 I install yocto from the freescale repository. In that repo I have source/poky source/meta-fsl-* source/meta-openembedded Jun 05 18:42:25 I want to add the qt package (.bb) which is in poky. how do I know the name to include in my local.conf file Jun 05 20:14:54 mtetreault: the way I usually handle this is to do a find -name '*qt*.bb' and see what is returned. Pick from the returned list. Jun 05 20:16:54 where can I find what has changed since daisy and master easily? I have just had the fun of bringing all my custom packages from using a danny based yocto all the way up to using daisy. But I can't get it to work with master. Jun 05 20:58:02 blloyd: try git log daisy..master Jun 05 21:45:39 ok, I haven't found why, but it appears that the build directory now defaults to build instead of ${S} like it used to. Does anyone know if this was an intended chnage or not, or what may have caused it? Jun 05 21:46:32 blloyd: Very intended change Jun 05 21:46:59 It was discussed quite a bit on the mailing list, I'll see if I can find the thread for you Jun 05 21:49:38 blloyd: autotools defaults to separate build dir, if your package can't handle this then 1) fix it or 2) use autotools-brokensep Jun 05 21:49:41 ok, so should I put a bug report in that http://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#var-B needs updated? Or am I misreading it? Jun 05 21:49:59 http://article.gmane.org/gmane.comp.handhelds.openembedded.core/48641 Jun 05 21:50:19 that manual bit needs to be updated Jun 05 21:50:43 unfortunately, that's what I use to figure how to write things. :( Jun 05 21:51:19 I just had the fun of upgrading all my stuff from danny all the way up to the very latest. Didn't have much trouble until this bit me. Jun 05 21:52:28 blloyd: if you're using master the "in the future" comment in http://www.yoctoproject.org/docs/latest/ref-manual/ref-manual.html#ref-classes-autotools is "now" Jun 05 21:54:42 rburton. thanks. I missed that part of manual. Jun 05 21:55:02 I had done my original reading many versions ago. Jun 05 21:56:30 blloyd: presumably you're updating all the way to master? Jun 05 21:56:33 blloyd: be warned that master just got a new compiler and more intrusive stuff is due soon :) Jun 05 22:03:52 rburton: I like to track master so I know what is coming. Company I work for didn't want to spend time to proactively monitor and are now paying for it as the changes from danny up were a bit crazy. At least now they are letting me have some time to track things proactively for the future. Jun 05 22:04:29 Releases will now use daisy, and that thankfully works. Jun 05 22:04:56 (I was able to figure it out between docs and everything without asking questions) Jun 05 22:05:47 however, I did find what looks to be a bug in daisy so was trying to compare to master first so I can write a better bug report. Jun 05 22:07:41 anyways, my immediate headache was a poorly written SYSROOT_PREPROCESS_FUNCS that used ${S} when ${B} was more appropriate, but when they are documented as being the same.... **** ENDING LOGGING AT Fri Jun 06 03:00:00 2014