**** BEGIN LOGGING AT Fri Dec 05 02:59:58 2014 Dec 05 07:51:04 good morning Dec 05 07:54:03 hi mckoan Dec 05 07:56:27 morning! Dec 05 08:16:36 hi woglinde, mago_ Dec 05 09:25:11 about submitting patches to oe-core, should I attach my patchfile on bugzilla (even though the pages specifically say I shouldn't), or should I post it separately on the oe-core mailinglist? if so, is there a preferred way to reference the bug in yocto bugzilla from my commit message? Dec 05 09:29:43 mago_: patches are submitted via the mailinglist Dec 05 09:38:29 morning all Dec 05 09:41:43 hi bluelightning Dec 05 10:04:34 well, there we have it. I have sent my very first patch to oe-core ;-) Dec 05 10:05:39 mago_: what is the $subject of your patch? Dec 05 10:06:05 [OE-core][PATCH] Add python-codecs runtime dependency for python-json Dec 05 10:06:25 i haven't received it yet.. Dec 05 10:06:44 weird, i sent it to openembedded-core@lists.openembedded.org Dec 05 10:07:17 you are a member of the list? Dec 05 10:08:01 yeah, i became a member earlier this morning. I've received other patches through the list, for example some busybox-mdev patches from Mike Looijmans Dec 05 10:08:08 mago_: be sure to read the patch submission guidelines Dec 05 10:08:27 mago_: the subject should be something like 'recipe: action' Dec 05 10:08:44 e.g. 'python-json: add RDEPENDS for python-codecs' Dec 05 10:09:03 ah, ok. sorry about that Dec 05 10:09:09 ok. maybe there is moderation for first posts.. i don't know. Dec 05 10:09:25 but maybe i can fix it, if the patch didn't make it into the list anways Dec 05 10:22:42 mago_: ok, it made it to the list ;-) Dec 05 10:23:46 ashame i didn't set a proper subject, like koen pointed out. I can't find any mention of that you should do this on http://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded though .. other than that the example sets the subject to "flex: .." Dec 05 10:31:28 mago_: that's more on the side of the commit message, which is documented in http://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines (which is linked from the "How to submit a patch" page) Dec 05 10:31:43 mago_: happy to take suggestions on how to make that more obvious, though Dec 05 10:38:40 i think my problem is that i got a little too eager to get it sent off, since i'm not suppose to be sending patches (according to my project manager) right now :) the docs are good, but i think repeating the subject syntax on the submit-a-patch page could be useful. I'd be happy to add it to the wiki, but it seems the wiki doesn't allow new users? Dec 05 10:44:24 ndec: by the way, about the image-in-image recipe you showed me the other day. Right now, getting the embedded image into the "superimage" is done using IMAGE_PREPROCESS_COMMANDs. Have you tried making a recipe instead, basically deploying the embedded fs using a do_install() task? The super-image when then IMAGE_INSTALL += "rootfs_recipe". The benefit of this would be that we probably can benefit from Dec 05 10:44:26 sstate-cache more efficiently Dec 05 10:45:15 i think it better maps to the image concept, instead of hacking a preprocess-command to install files into the image, they get deployed using a dedicated recipe Dec 05 10:47:08 mago_: well. the embedded image needs to be an image recipe, to do all the image stuff Dec 05 10:47:28 so essentially you are implying to have a do_install() in an image recipe.. Dec 05 10:50:33 no, i mean a separate recipe. image-a.bb generates some_rootfs.tar.gz. package-a.bb with a do_install() that copies ${DEPLOY_DIR_IMAGE}/some_rootfs.tar.gz into it's ${D}. And then we let image-b.bb IMAGE_INSTALL package-a.bb. package-a.bb should also depend on image-a:do_rootfs of course Dec 05 10:52:31 ah. ok. to me it's replacing one hack by another one ;-) Dec 05 10:53:13 i don't know what sstate would do in that case with the dependency on image-a:do_rootfs. Dec 05 10:53:15 well, don't you think it maps better to the whole idea of images? this way, we will actually have a package-a.ipk that contains the rootfs Dec 05 10:54:16 maybe... but then you have an .ipk that contains an entire image, which doesn't map to the definition of a package that much.. maybe you can try and see how it behaves. we can compare after.. Dec 05 10:54:30 i think of POST/PRE-commands of ways to manipulate already deployed contents, not to bring in additional stuff. For this, we use IMAGE_INSTALL Dec 05 10:58:51 ndec: also, you get workaround to https://bugzilla.yoctoproject.org/show_bug.cgi?id=7024 for free :) Dec 05 13:41:15 anyone know of a allarch-recipe that just installs a bunch of static files (like a website). My problem is that I'd prefer to not list all files manually, in SRC_URI, in do_install() and FILES_${PN} Dec 05 13:44:23 mago_: wouldn't it just be the parent directory of all of those files in the latter two cases? Dec 05 13:44:45 mago_: for SRC_URI, where would you be expecting to grab the files from? aren't they under source control? Dec 05 14:03:38 bluelightning: i was kind-of putting the whole webpage as SRC_URI, basically using the meta-repo as my webrepo. I see my mistake now :) Dec 05 14:04:29 right, you might find it easier if the web content was in its own repo Dec 05 14:41:36 Hi guys! What means "ls: cannot access setup-scripts/build/tmp-angstrom_v2013_12-eglibc/sysroots/myimage/pkgdata/runtime-reverse/kernel-module-g-serial:" while runnind myimage do_rootfs? Dec 05 14:45:49 spaszkoPL: it'll be a bug I'm afraid Dec 05 15:05:30 spaszkoPL: I'm still waiting for that meta-qt5 patch :) Dec 05 15:31:27 JaMa: Im' trying but lot of work at work :) Dec 05 15:31:49 same here Dec 05 15:32:06 But i'm trying and it will be near :) Dec 05 15:32:53 thanks Dec 05 15:58:58 bluelightning: So to recreate this bug you have to enable USB Gadget Serial in kernel, compile kernel&image, disable gadget serial and compile kernel&image. Dec 05 15:59:24 spaszkoPL: ok, right... for some reason it expects it to be there still Dec 05 17:07:31 The /etc/init.d/mountall.sh script starts by default on S03 in oe-core, mounting any device mentioned in /etc/fstab. udevd starts by default on S04. This means that when mountall.sh runs, most of /dev is not populated and you cannot mount things like an SD-card. I've been able to work-around the issue by overriding INITSCRIPT_PARAMS for udevd in another layer, forcing it to run before mountall.sh, but is there an Dec 05 17:07:33 argument for not swapping the default init-order in oe-core of these two components? Would you say this counts as a bug? Dec 05 17:09:16 (or is the proper solution here to use udev to do the mounting?) Dec 05 19:26:06 I'm trying to migrate from Angstrom 2013.12 to 2014.12 and i see from www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#migration-1.5-busybox that there isn't any tinylogin recipe. So what happend with variable IMAGE_LOGIN_MANAGER? Dec 05 19:27:24 Is there any new variable to define login manager or any other solution? Dec 05 21:22:06 * Crofton|work grumbles about SRC_URI having an _ and SRCREV not having one. again Dec 05 21:48:10 what is the trick for handing the case where .so files that should ben in the -lib package end up in the -dev one? Dec 05 22:09:49 remove them from FILES_${PN}-dev and set INSANE_SKIP to hide the QA warning (if needed) Dec 05 22:19:16 I did Dec 05 22:19:17 SOLIBS = ".so" Dec 05 22:19:17 SOLIBSDEV = "xxx" Dec 05 22:19:31 and no QA warning, but it seem I've seen better appraoches Dec 05 22:38:34 Crofton|work: QA warning is shown only when it's also a symlink, IIRC Dec 05 22:48:55 ah yes **** ENDING LOGGING AT Sat Dec 06 03:00:00 2014