**** BEGIN LOGGING AT Sun Oct 18 02:59:58 2015 Oct 18 09:46:54 hi, I want to append my devicetree to my uImage file. In my kernel recipe i 'inherti kernel' andinclude linux-dtb.inc and set KERNEL_IMAGETYPE = "uImage" I also have KERNEL_DEVICETREE set. The uImage and DT is built but the DT is not included in the uImage how can I fix this? Oct 18 09:48:57 outside yocto I achive this by "cat arch/arm/boot/zImage arch/arm/boot/dts/foo.dtb > /tmp/foo; mkimage -A am -a .. -e ... -d /tmp/foo uImage" Oct 18 11:35:16 say i have 40 packages i want to install and say: bitbake fsl-image-x11 breaks on 20 of them. is there a way to tell me about all the 20 problematic packages at once? right now i'm rerunning that command over and over and it takes about 1-3min to compute the dependencies Oct 18 11:35:31 this is a huge amount of wasted time Oct 18 11:40:05 qknight: -k will continue as much as possible after errors Oct 18 11:40:35 bluelightning: ok Oct 18 12:02:44 i'm assuming 'python patch_do_patch()' in meta/classes/patch.bbclass is the default patch implementation. why isn't it just 'python do_patch()' though? Oct 18 12:53:02 frobar: that's because of EXPORT_FUNCTIONS - the idea is you can override it in your own recipe / class and still have a means of calling the original version Oct 18 12:56:21 bluelightning: interesting Oct 18 13:33:15 bluelightning: okay, ty Oct 18 14:29:08 Hey. I have some patches which are stored in a git repo. How can I apply them? Are there some examples? Oct 18 14:41:38 domidimi: this is actually quite easy Oct 18 14:41:47 domidimi: just have a look at the .rr files Oct 18 14:42:25 qknight: what are the .rr files? Oct 18 14:43:13 domidimi: i meant bb, sorry Oct 18 14:43:56 qknight: sorry, I don't get how does that help Oct 18 14:44:15 domidimi: go into meta-openembedded and search for '.patch' Oct 18 14:44:49 domidimi: from there you will find out what has to be done Oct 18 14:44:55 qknight: I don't have the .patch files in the layer, they are in a git repository Oct 18 14:45:11 domidimi: then put your patch there as well ;-) Oct 18 14:45:33 I don't want the patches to be redundant Oct 18 14:45:52 I want to have just one source which contains the patches Oct 18 14:46:24 domidimi: good luck with that ;-) Oct 18 14:46:46 qknight: thanks for the help ;-) Oct 18 14:46:48 domidimi: in general, put the patch where it belongs and create a PR for you change Oct 18 14:47:29 qknight: the patch is already where it belongs -> in a git repo which is different than the layer repo Oct 18 14:48:34 domidimi: and does it patch something in the same git repo, where it is in or a different layer repo? Oct 18 14:49:25 it patches in a different repo, but the patch is maintained by someone else who does not have anything to do with the layer Oct 18 14:55:05 qknight: but really thanks. I wanted to ask if I'm not missing something simple Oct 18 16:01:17 what causes the do_package_write tasks to run when building an image? do_build by default does not seem to depend on do_package_write. Oct 18 16:03:43 do_rootfs[recrdeptask]. it says do_rootfs depends on the listed tasks in all of its dependencies and runtime dependencies Oct 18 16:03:53 then IMAGE_INSTALL/PACKAGE_INSTALL is added to RDEPENDS Oct 18 16:03:59 see image.bbclass and rootfs_*.bbclass Oct 18 16:05:05 hmm, ok Oct 18 16:10:10 is it really true that the default do_patch() looks at SRC_URI like the reference manual says? patch.bbclass makes it look like it's looking for stuff in ${WORKDIR}. Oct 18 16:14:02 stuff like fetch = bb.fetch2.Fetch([], d) is confusing though :/ Oct 18 16:14:23 and then 'for url in fetch.urls:' Oct 18 16:15:57 oh... looks like [] makes it use SRC_URI Oct 18 16:16:49 why doesn't the do_patch step just allow you to specify where the patches are? that'd decouple fetching from patching completely. Oct 18 16:16:53 seems more flexible Oct 18 16:30:52 URLs are fetched and then unpacked into WORKDIR Oct 18 16:31:02 so yes, it makes perfect sense that do_patch would apply patches from workdir Oct 18 16:37:42 yeah, i was thinking it could just apply *.patch from the workdir by default or something like that Oct 18 16:38:28 not all patches are named .patch :) Oct 18 16:39:33 i just meant as the default behavior Oct 18 16:39:52 instead of looking at SRC_URI Oct 18 16:40:39 gets a bit tricky if you want to fetch patches in an odd way at the moment i guess, since the SRC_URI stuff needs to have a particular form Oct 18 16:41:09 if it just applied patches from ${WORKDIR} or whatever, that'd make it simpler Oct 18 16:42:09 having the "fetch stuff" step be completely decoupled from stuff like patching sounds like it'd be nice at least :S Oct 18 16:42:24 could still have helpful defaults Oct 18 17:09:14 what's meant by a relocatable toolchain? Oct 18 17:33:29 nm, just means it can run from multiple paths Oct 18 17:50:49 hello Oct 18 17:54:08 is ther anyway to change home folder location in yocto e.g. xuser home folder? Oct 18 17:56:50 hello Oct 18 18:30:42 qtbase-examples not found in the base feeds (t4240rdb_64b ppc64e6500 powerpc64 noarch any all). <- anyone an idea how to solve this? Oct 18 18:30:55 found lots of 'not found in the base feeds' posts but they are not helpful at all Oct 18 19:24:25 qknight: it means that the package you are specifying whilst may have been stated to be built by the recipe, was not produced - this is usually because the package ended up empty at packaging time Oct 18 19:25:19 maybe building of the examples was disabled in the configuration? Oct 18 19:25:26 the do_configure log may have something to say about that **** ENDING LOGGING AT Mon Oct 19 02:59:59 2015