**** BEGIN LOGGING AT Fri Oct 23 02:59:58 2015 Oct 23 07:12:52 good morning Oct 23 07:48:15 morning all Oct 23 08:37:09 morning Oct 23 08:55:54 sagt euch ".meta/cfg/scratch/dss11e-standard-meta" etwas im bezug auf den kernel? Oct 23 08:55:56 oops wrong window Oct 23 08:56:08 I don't know why it always happens to me... Oct 23 08:56:10 :) Oct 23 08:56:17 * Jin^eLD kicks his keyboard Oct 23 09:00:13 hmm, but actualy that may have something to do wiht OE.. I recently pulled from poky jethro, I do it about once a week, and since then my kernel build started to fail at do_patch Oct 23 09:00:26 from what I can see this "meta" file is some sort of a patch steps description Oct 23 09:00:42 any hints on who creates it? Oct 23 09:00:47 the error from bitbake that I get is: Oct 23 09:00:48 DEBUG: Executing shell function do_patch Oct 23 09:00:49 cp: cannot stat '.meta/cfg/scratch/dss11e-standard-meta': No such file or directory Oct 23 09:01:05 who is supposed to supply that file? Oct 23 09:04:47 da hats was Oct 23 09:05:02 oops :) again heh Oct 23 11:52:15 how do I control which linux header files end up in the user space api? Oct 23 12:25:17 We've added a new header file to the kernel, and I want it to show up in the sdk. Oct 23 14:09:41 Hi. One question to systemd? How can i enable wpa_suplicant@wlan0 in my image recipe or config? Oct 23 14:09:57 Should i add new recipe or make systemd bbappend? Oct 23 14:10:23 i mean of course wpa_suplicant@wlan0.service Oct 23 14:57:00 hmm, I have a recipe that is supposed to take an image image from the deploy dir and repackage it; the recipe DEPENDS on the image recipe, however the do_install step fails because the image recipe did not deploy its stuff yet Oct 23 14:57:11 any hints on how to get around this? Oct 23 14:57:26 I guess I need to depend more precisely, on some task or something? Oct 23 15:05:16 image-name:do_deploy? Oct 23 15:05:40 let me try that Oct 23 15:09:07 what is the syntax for it? just DEPENDS = "myimage:do_deploy" does not seem to work Oct 23 15:09:51 says no buildable providers Oct 23 15:10:06 I think I need my install task depend on it Oct 23 15:12:09 do_install[depends] += ... seems to do it Oct 23 15:18:01 of course what you probably want is a custom image type Oct 23 15:19:34 how is that related? Oct 23 15:19:50 it seems my image has no do_deploy, so I depend on do_rootfs, that does seem to work though Oct 23 15:19:55 but how would that be related to a custom type? Oct 23 15:23:04 I only have your one line description of "taking an image and repackaging it" but that sounds like something that should probably be a custom image type to produce the right output with the generated rootfs contents rather than unpicking an existing image and rejigging it Oct 23 15:24:17 ah, no, its more perverted than that :) Oct 23 15:24:27 the image goes into an ipk, that's what I meant by repacking Oct 23 15:24:35 its a rescue image that needs to be installed and be upgradable Oct 23 15:24:53 it goes to a separate partition on the target then Oct 23 15:28:05 ah, gotcha - crossed wires on irc, who'd have thought? :-) Oct 23 15:28:43 :) Oct 23 15:43:00 Jin^eLD: Huh. thought about creating an ipk fstype for use in IMAGE_FSTYPES? Otherwise you could probably make do_package depend on do_rootfs, resurrect the packaging tasks that image.bbclass removed, and point D to IMAGE_ROOTFS, and let the usual packaging functions do the work.. Oct 23 15:43:01 hmm Oct 23 15:46:56 hmm Oct 23 15:47:13 you mean get rid of the noexec's that image.bbclass is setting? Oct 23 15:48:08 we also need the image without an ipk for some other scenarious though Oct 23 15:48:12 so, both is needed Oct 23 15:48:31 right now we have two separate packages, one that just does the image, and the other one can take the image from deploy and package it into an ipk Oct 23 15:49:34 right, i'm saying treat do_rootfs as though it was do_install. it populates IMAGE_ROOTFS, so if you were to point D at that, and make do_package depend on do_rootfs instead of do_install, it'd write the image, then package its contents Oct 23 15:49:37 in theory Oct 23 15:50:42 aaha, I think I sort of get the idea Oct 23 15:50:47 I could try that Oct 23 15:54:11 might have to use anonymous python to delete the noexec flags, i think bitbake still treats it being set to the empty string as being set, rather than not being set Oct 23 15:54:14 not sure though Oct 23 15:54:17 * kergoth shrugs Oct 23 15:54:31 that's off the top of my head, and i haven't had my coffee yet, so, keep that in mind :P Oct 23 15:54:38 might not be ideal, but worth a try possibly Oct 23 15:55:16 :) Oct 23 15:55:18 thx Oct 23 16:02:10 otherwise you could possibly treat ipk as your archival method, and add it as an image fstype not unlike the tar one, just with metadata included Oct 23 16:02:16 * kergoth gets caffeine Oct 23 16:03:34 I'll talk to the guys once more regarding requirements / use of the image and then see if I can simplify/improve what we have based on your hints Oct 23 20:48:28 gah, where I set the files matchbox runs at boot Oct 23 20:48:30 again **** ENDING LOGGING AT Sat Oct 24 02:59:59 2015