**** BEGIN LOGGING AT Tue Nov 26 02:59:58 2013 Nov 26 05:57:11 Hi ,Can anybody let me know how I handle this situation Nov 26 05:57:26 I wanted to modify my /etc/shadow file Nov 26 05:57:48 and need to disable one of the user acount Nov 26 05:58:15 I guess /etc/shadow file is generated from /etc/paswd Nov 26 05:58:17 file Nov 26 05:58:43 But I can't apply patch to /etc/passwd file of my rootfs Nov 26 06:00:25 which user? Nov 26 06:00:54 its for root user Nov 26 06:01:24 for some other users i am able to make changes Nov 26 06:01:47 by patching the passwd.master file Nov 26 06:02:23 i set a generated passwd for root in a custom post-process function in the image recipe Nov 26 06:02:34 but that's oe-classic Nov 26 06:02:53 not sure if there's a better way in meta-oe Nov 26 06:03:25 so if nothing else, you can sed the passwd file in a pinch Nov 26 06:19:03 Raj_: you could add something like this: ROOTFS_POSTPROCESS_COMMAND += " custom_rootfs_postprocess; " Nov 26 06:19:42 fakeroot custom_rootfs_postprocess() { do stuff } Nov 26 06:44:19 but i can't modify the root user line with my patch because its already been modified by nobash.patch in Nov 26 06:45:38 nerdboy for some reasons we can't go for ROOTFS_POSTPROCESS_COMMAND += " custom_rootfs_postprocess; " Nov 26 06:45:43 those mods are done by that time Nov 26 06:45:59 Could you please let me know how I can do it from sed Nov 26 06:45:59 ? Nov 26 06:46:31 the do stuff part Nov 26 06:46:53 neardboy: Only for root user we have to make this modification Nov 26 06:46:58 for me it's pwgen, openssh, and then sed Nov 26 06:49:03 http://paste2.org/3t0wg7UW Nov 26 06:49:56 that sets a scrambled root ala debian Nov 26 06:50:42 different for shadow, but if all you need is disable root login then it's dead simple... Nov 26 06:51:20 Can I add these line in base-passwd_3.5.26.bbappend? Nov 26 06:52:25 don't see why not Nov 26 06:53:08 i have to do a lot of postprocessing in our oe-classic image... Nov 26 06:53:13 nd would it make changes in /etc/shadow file ?? Nov 26 06:53:38 you'd disable the account in /etc/passwd Nov 26 06:54:27 sorry, i don't use shadow in my builds Nov 26 06:54:32 hang on a sec Nov 26 06:54:41 ok Nov 26 06:56:48 passwd should have root:x: and you need to sed shadow so it looks like root:*: Nov 26 06:56:56 YES Nov 26 06:57:00 you are right Nov 26 06:57:06 this is what I want Nov 26 06:57:17 actually * can be anything that's not a valid password crypt Nov 26 06:57:35 but that only disables password logins Nov 26 06:57:47 ok Nov 26 06:57:52 ssh key would still work Nov 26 06:57:58 ok Nov 26 06:58:22 you mean ssh through root user ,right? Nov 26 06:58:43 if allowed in the config, i think that would bypass shadow Nov 26 06:58:59 ok Nov 26 06:59:12 in sshd_config we can permitrootlogin no Nov 26 06:59:19 that will disable root login Nov 26 06:59:36 i have added fakeroot do_root_passwd() { ROOT_PASS=`${STAGING_BINDIR_NATIVE}/pwgen -1` ROOT_PSTRING=`${STAGING_BINDIR_NATIVE}/openssl passwd -crypt -salt salty ${ROOT_PASS}` sed -i -e "s|root::|root:${ROOT_PSTRING}:|" ${IMAGE_ROOTFS}/etc/passwd } Nov 26 06:59:51 to my base-passwd_3.5.26.bbappend file Nov 26 07:00:25 and my build is ready Nov 26 07:00:32 you don't need all that Nov 26 07:00:45 then? Nov 26 07:01:06 that's what the passwd file looks like for debug builds Nov 26 07:01:27 do you have any of that in your local.conf? Nov 26 07:02:04 depending on what your installed shadow file looks like, you just need a sed line Nov 26 07:03:06 we have root:x: is our passwd file and root:: in shadow file Nov 26 07:03:24 sed -i -e 's|root::|root:!:|' ${IMAGE_ROOTFS}/etc/shadow Nov 26 07:03:33 then all you need is that Nov 26 07:03:33 but we want root:*: in our shadow file Nov 26 07:03:41 that works too Nov 26 07:03:58 and where should i add this line Nov 26 07:03:58 i mean in which file Nov 26 07:03:59 ? Nov 26 07:04:25 that's for your bbappend Nov 26 07:04:34 ok Nov 26 07:04:37 let me add this Nov 26 07:04:42 do_install_append seems like a good place Nov 26 07:05:06 just make one or add the sed line to the end Nov 26 07:05:24 although it's not yet ${IMAGE_ROOTFS} yet Nov 26 07:05:40 make that ${D} instead Nov 26 07:06:05 forgot you're doing a bbappend for a sec... Nov 26 07:06:14 do I have to add it in do_root_passwd() ? Nov 26 07:06:32 take out the whole do_root_passwd() thing Nov 26 07:06:35 sorry i m new to yocto, may I am asking stupid questions Nov 26 07:06:46 ok Nov 26 07:07:10 can you paste your bbappend file? Nov 26 07:07:28 its just patch we have appiled Nov 26 07:07:36 in bbappend Nov 26 07:07:43 using SRC_URI Nov 26 07:08:09 we have only two lines in bbappend Nov 26 07:08:11 okay, just add the sed line in a do_install_append Nov 26 07:08:15 ok Nov 26 07:08:21 let me do this Nov 26 07:08:28 sed -i -e 's|root::|root:!:|' ${D}/etc/shadow Nov 26 07:09:41 i have added it and doing bitbake Nov 26 07:11:50 getting this error Nov 26 07:12:03 unparsed line: 'do_install_append()' unparsed line: 'do_install_append()' Nov 26 07:12:16 i guess i have to use base_passwd_sstate_postinst Nov 26 07:12:19 here Nov 26 07:16:16 you have something like this? Nov 26 07:17:22 http://paste2.org/j9U4NpXs Nov 26 07:17:54 yes in base_passwd_3.5.26.bb Nov 26 07:18:06 it is part of poky Nov 26 07:19:18 buy why do_install_append is not working Nov 26 07:19:21 ? Nov 26 07:22:24 using base_passwd_sstate_postinst also give me same error Nov 26 07:29:45 not sure Nov 26 07:30:18 looking at the recipe, seems like it should work... Nov 26 07:30:38 so r u looking at base_passwd_3.5.26.bb Nov 26 07:30:39 ? Nov 26 07:31:00 3.5.28 in master Nov 26 07:31:59 try calling it do_passwd and the put this in: Nov 26 07:32:05 ok Nov 26 07:32:21 addtask do_passwd after do_install Nov 26 07:35:03 but I don;t have do_install in my .bbapend and i can't make changes to poky's .bb file Nov 26 07:35:36 still getting same error after adding do_passwd{} Nov 26 07:38:43 instead of do_install_append, change it to do_passwd. then add the other part at the end: "addtask do_passwd after do_install" Nov 26 07:39:03 no more do_install_append Nov 26 07:40:22 do_passwd{ sed -i -e 's|root::|root:!:|' ${D}/etc/shadow addtask do_passwd after do_install } Nov 26 07:40:26 is it how i have do it? Nov 26 07:40:50 this goes outside the function - addtask do_passwd after do_install Nov 26 07:40:56 on its own line Nov 26 07:41:00 ok Nov 26 07:41:46 i have added this way Nov 26 07:42:08 do_passwd { sed -i -e 's|root::|root:!:|' ${D}/etc/shadow } addtask do_passwd after do_install Nov 26 07:43:36 hopefully with some newlines? Nov 26 07:43:46 yes yes Nov 26 07:43:58 http://git.yoctoproject.org/cgit.cgi/poky/plain/meta/recipes-kernel/linux/linux-yocto.inc Nov 26 07:44:01 like this way Nov 26 08:05:53 Sorry nerdboy do_install_append may also work ,i was doing it wrongly . I was doing it in do_install_append{} but i should be doing do_install_append(){} Nov 26 08:43:32 nardboy: My bitbake is successful but nothing is changed in /etc/shadow file of rootfs Nov 26 08:44:05 do i have to provide this path ${STAGING_DIR_TARGET}${sysconfdir}/shadow Nov 26 08:44:06 ?? Nov 26 08:52:10 that path is for the sysroot install Nov 26 08:52:48 that should work as-is, so maybe there really is a better way Nov 26 08:52:58 So what Should I do Nov 26 08:53:33 can i use {IMAGE_ROOTFS} path? Nov 26 09:11:59 only after do_rootfs has run Nov 26 09:14:05 morning Nov 26 09:21:26 so i can't call it from my .bbappend file right? Nov 26 09:22:18 looks like it, though i have no idea why... Nov 26 09:23:04 i can give it a try tomorrow, but for now it's past my bedtime Nov 26 09:23:24 No pron nerdboy Nov 26 09:23:40 *no problem Nov 26 09:23:59 you already tole me so many things Nov 26 09:24:18 its great learning talking to you Nov 26 09:24:29 thank u Nov 26 09:26:46 no prob Nov 26 09:26:55 better if it actually worked Nov 26 10:11:06 morning all Nov 26 10:24:52 Hi all, a small doubt--> to work with gumstix caspa camera board, do I need to add this to PREFERRED_PROVIDER_virtual/kernel = "linux-omap3-caspapx" to /yocto/poky/meta-gumstix/conf/machine/overo.conf? gumstixIRC is very slow in responding, so posted here. Nov 26 10:50:17 linux-omap3-caspapx is your kernel recipe,right? Nov 26 10:54:46 hi all i have been trying to compile rtl8723au_bt source to arm-poky-linux,i mean i have using poky with meta-atmel, i got this error while compiling http://pastebin.com/rKXGGs2H can you help me Nov 26 11:32:47 Raj_: Sorry missed your msg. My kernel from overo.conf file is PREFERRED_PROVIDER_virtual/kernel = "linux-gumstix" Nov 26 11:58:00 Can anybody let me know how /etc/shadow file is generated in rootfs? Nov 26 12:05:28 hey all... Nov 26 12:05:47 How would I add gdb-cross into my recipe? IMAGE_INSTALL isn't the right place for it... Nov 26 12:10:51 using IMAGE_INSTALL only i am adding different tool Nov 26 12:10:57 in my image Nov 26 12:11:06 pev: if you mean you want gdb that runs on the target, just add gdb, not gdb-cross Nov 26 12:11:10 Hm, I get an error Nov 26 12:11:15 no, i meant cross Nov 26 12:11:22 so I can decodecode oopses... Nov 26 12:11:28 on my dev machien Nov 26 12:11:29 what erro Nov 26 12:11:30 Hi, the yocto doc says that INITRAMFS_IMAGE can be set in image recipes, however it does not work, am I missing something? Nov 26 12:11:32 *machine Nov 26 12:11:35 *error Nov 26 12:11:58 pev: then it wouldn't be appropriate to add it to IMAGE_INSTALL because gdb-cross could never be installed into an image for the target Nov 26 12:12:48 pev: what exactly are you trying to do? Nov 26 12:12:49 Exactly - I just don't know what the analagous var to add it to in the image recipe is to ensure it gets built :-) Nov 26 12:13:36 bluelightning: Just wanting it to get built by default when I build my image so I don't have to rebuild it after the fact as it takes a while and if I can put it in the recipe it will just get built with my normal nightlies Nov 26 12:13:47 pev: How about: EXTRA_IMAGE_FEATURES_append = " dbg-pkgs" Nov 26 12:14:11 pev: that only adds the debug symbols to the image, that won't cause gdb-cross to be built Nov 26 12:14:16 Saur: ^ Nov 26 12:14:30 Hmm, true... Nov 26 12:14:31 pev: you could do EXTRA_IMAGEDEPENDS += "gdb-cross" Nov 26 12:15:15 Can you write seprate .bb which will having IMAGE_INSTALL and it requires your image recipe file Nov 26 12:15:23 bluelightning: That sounds like the ticket! Nov 26 12:15:41 oops Nov 26 12:45:28 Hi, I am trying to compile core-image-sato for Intel Cedartrail. I am using the Danny branch. My build keeps failing at mesa-demos-8.0.1 Nov 26 12:46:04 could someone guide me how to resolve the dependency Nov 26 12:46:09 thanks Nov 26 13:36:43 Hi all, I'm creating a BSP for a i.MX6 based board called Utilite, and I have a few questions on the use of Yocto Nov 26 13:37:31 I based my BSP on the Freescale's one, and only kept the need files to have a successful build for the core-image-minimal Nov 26 13:38:31 I've changed some settings in mu machine conf file, and I'd like to know what I have to do do "clean" and force Yocto to take those changes into account Nov 26 13:41:14 Romain__: assuming you have set MACHINE to the name of your new machine conf file, you shouldn't need to do anything else Nov 26 13:42:37 yes I did, I've changed a kernel configuration in my machine conf file : SERIAL_CONSOLE = "115200 ttymxc3" Nov 26 13:43:10 I was expecting Yocto to rebuild the Kernel to take this change into account, as i don't have serial output during Kernel boot (if it boots) Nov 26 13:57:22 Romain__: the kernel doesn't pay attention to SERIAL_CONSOLE, that's just for userspace (e.g. init starting a getty on that device) Nov 26 13:58:03 I suppose in that case the only information taken into account is the one provided in the bootargs, right ? Nov 26 13:58:49 right Nov 26 13:59:18 but I haven't changed anything in the u-boot settings of the Utilite, so I assume my Kernel is defective Nov 26 14:19:53 is this syntax allowed in .bb file Nov 26 14:20:14 SRC_URI[rp.md5sum] = "xycbz99f2b8f8e5"' Nov 26 14:22:40 Raj_: yes, but that isn't a valid md5sum of course Nov 26 14:26:01 unparsed line: ' SRC_URI[rp.md5sum] = "xycbz99f2b8f8e5" Nov 26 14:26:14 hello, I trying to create a recipe which include a .inc file from another layer, my pb is that when I'm running bitbake myrecipe, bitbake doesn't found files which are in SRC_URI of the .inc file, it just search them in my recipe folder Nov 26 14:26:50 Raj_: check the line preceding; it also looks like there might be spaces before it Nov 26 14:27:02 ok bluelightning but I m getting this error while bitbake this .bb unparsed line: ' SRC_URI[rp.md5sum] = "xycbz99f2b8f8e5" Nov 26 14:27:55 beuh: http://www.openembedded.org/Layers_FAQ#How_do_I_include_an_inc_file_from_another_layer.3F Nov 26 14:30:16 bluelightning would you please let me what need to checked Nov 26 14:30:21 i mean the space thing Nov 26 14:30:29 Raj_: are there any spaces at the start of the line? Nov 26 14:31:22 yes Nov 26 14:31:28 spaces are there Nov 26 14:31:33 bluelightning, yes i did the require .inc file but bitbake doesn't find files in SRC_URI of the .inc file Nov 26 14:36:08 beuh did you try adding this line FILESEXTRAPATHS_prepend := "${THISDIR}/ Nov 26 14:37:47 Raj_: you should not have any spaces at the start of a line (outside of functions, or a continuation of the previous line) Nov 26 14:39:08 Thanks bluelightning u r dead right!!! Nov 26 14:46:44 what is fakeroot do_install() is for?? Nov 26 15:11:24 RP: Question about the mem-res bitbake. Nov 26 15:11:41 I thought things were not suppose to have to reload the cache on each connect. Nov 26 15:12:01 One of the operations I had hoped to be nearly instant for example was the bitbake -c devshell Nov 26 15:12:23 But I noticed it is always printing "Loading cache:...." Nov 26 15:14:27 Hi, I'm trying to add a recipe to add applications/libraries to the generated SDK. I added a recipe and some dependencies. I got an application generated for the host. Not for the target. Why ? Could you help me to set the compilation target ? Nov 26 15:19:57 rbuchmann: you can add to the "host" side by ensuring there is a nativesdk variant of the recipe for what you want to add, and then adding the corresponding nativesdk package name to TOOLCHAIN_HOST_TASK Nov 26 15:20:29 thx. I will try asap :) Nov 26 15:21:58 okay, that work with do_populate_sdk as long as the desired lib is depended on? Nov 26 15:22:21 *shouldn't that work... Nov 26 15:22:41 jwessel: sounds like we need to take a look at what is going on there Nov 26 15:22:44 what's special abut this case? Nov 26 15:23:03 bluelightning ^^ Nov 26 15:23:42 bluelightning: you suggested IMAGE_INSTALL_append = " package-name" for adding our layer's recipes to our distro image, right? Nov 26 15:24:12 RP: I could have sworn this worked before but now I am not so sure :-) Nov 26 15:24:32 My other test was to simply run time bitbake -c patch bash Nov 26 15:24:59 jwessel: I'm slightly surprised to hear its reloading the cache Nov 26 15:25:00 I expected that there would be no cache reload on every pass with the memres server. Nov 26 15:25:22 lpapp: doing that outside the image recipe for anything but temporary testing is not advisable; e.g. it will inject those packages into images you might not want them in e.g. initramfs images Nov 26 15:25:22 bluelightning: why not EXTRA_IMAGEDEPENDS? Nov 26 15:25:25 I tried it with master as of this morning. Nov 26 15:25:41 lpapp: EXTRA_IMAGEDEPENDS is for adding things to be built alongside the image, not to be included in it Nov 26 15:26:00 lpapp: also EXTRA_IMAGEDEPENDS refers to recipes whereas IMAGE_INSTALL is a list of packages Nov 26 15:26:21 bluelightning: ok, so with someone with an own distribution in a distro layer, IMAGE_INSTALL_append = " package1-name package2-name etc " what you recommend? Nov 26 15:26:24 in the distro conf? Nov 26 15:26:59 lpapp: if you're asking for my recommendation, I don't recommend touching IMAGE_INSTALL from outside an image recipe at all Nov 26 15:27:14 it'll work, but it may have undesirable effects, see above Nov 26 15:27:25 bluelightning: so you suggest to put that into the image recipe? Nov 26 15:27:32 yes Nov 26 15:27:36 or use something else in the distro conf? Nov 26 15:27:47 have your own image recipes that add the packages you need Nov 26 15:28:04 so it is not distro conf material? Nov 26 15:28:05 image recipes are (usually) trivial Nov 26 15:28:07 no Nov 26 15:28:35 bluelightning: isn't there a more intelligent way? Nov 26 15:28:53 lpapp: what do you mean by more intelligent? Nov 26 15:29:05 bluelightning: well, I do not wanna enumerate 10+ packages explicitly. Nov 26 15:29:15 cannot I refer to meta-foo/recipes-foo? Nov 26 15:29:22 and pick up everything from there? Nov 26 15:29:27 create a packagegroup recipe to point to the list of packages Nov 26 15:31:21 bluelightning: that does not solve the problem, just relocates. Nov 26 15:31:32 so how to pick up several packages automatically? Nov 26 15:31:38 you do it once in the packagegoup, and it's done Nov 26 15:31:46 what is a package group recipe? Nov 26 15:32:00 lpapp: http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#usingpoky-extend-customimage-customtasks Nov 26 15:32:14 http://www.yoctoproject.org/docs/1.5/dev-manual/dev-manual.html#usingpoky-extend-customimage-customtasks ? Nov 26 15:32:21 oh Nov 26 15:32:22 :) Nov 26 15:34:46 bluelightning: thanks again. Nov 26 15:34:56 you're welcome Nov 26 15:35:33 bluelightning: and it is better to add that packagegroup in my layer, I think? Nov 26 15:35:45 lpapp: yes, that would make sense Nov 26 15:35:49 i.e. : mkdir -p meta-foo/recipes-core/packagegroups/ Nov 26 15:37:41 RP: I might be able to bisect it. Nov 26 15:37:58 I went to the dora branch of oe and all the way back to Sep 3 of bitbake. Nov 26 15:38:07 And it stopped loading the cache every time. Nov 26 15:38:22 It appears to be something which changed in bitbake. Nov 26 15:38:27 jwessel: I suspect some of the changes Alex made to the init process Nov 26 15:38:56 I really had no idea where to look without putting in instrumentation, as I have not yet worked in that area of bitbake. Nov 26 15:40:29 I'll start a bisect and see if it works, because it says only 5 steps :-) Nov 26 15:43:23 RP: 12e9d33bfae5294e3870dfd1202f63383ad05e92 is the first bad commit Nov 26 15:43:23 Author: Richard Purdie Nov 26 15:43:23 Date: Fri Sep 13 17:31:54 2013 +0100 Nov 26 15:47:20 * jwessel thinks the bisect lied Nov 26 15:49:49 * nerdboy needs to make some packagegroups too Nov 26 15:50:05 oh well, off to work... Nov 26 15:55:04 jwessel: is it actually staying in memory at all? Nov 26 15:55:28 Yes. It is always staying in memory. Nov 26 15:55:34 I just re-bisected. and got it now. Nov 26 15:55:38 dd15648fc2654b8d7c3e00ea7ab3dbf04f24f24b is the first bad commit Nov 26 15:55:43 cooker/command: Add finishcommand to reset cooker state Nov 26 15:56:10 This makes more sense. The starting from a "known state" is causing it to reload the cache on every client connect. Nov 26 15:56:23 jwessel: right, that makes more sense Nov 26 15:56:47 The next question is what can be done to trigger only when we actually need to reload. Nov 26 15:57:14 jwessel: its a question of making the "reset" cleverer Nov 26 15:57:23 Indeed. Nov 26 15:57:35 I'll write a BZ, since I don't have time to look at this today. Nov 26 15:57:56 jwessel: sounds good. I think I might be able to resolve this one but I also can't do it now Nov 26 15:58:04 I just wanted to know that I wasn't crazy and at one point it did actually not re-load all the time. :-) Nov 26 15:58:11 jwessel: I'd also like to check if Cristiana has been looking at it Nov 26 15:58:23 She might not have noticed this yet. Nov 26 15:58:46 It is a small enough amount of time on a fast machine it might not be so noticeable. Nov 26 15:58:53 On my laptop it was fairly obvious. Nov 26 16:00:00 YPTM: welcome to the technical team meeting. Please let me know who's on the bridge. Thanks! Nov 26 16:00:15 YPTM: Paul Eggleton is on Nov 26 16:00:20 Song_Liu: Richard is on the call Nov 26 16:00:20 YPTM: MIchael here. Nov 26 16:00:23 YPTM: Tom Z on Nov 26 16:01:21 YPTM: Scott Rifenbark joined the call. Nov 26 16:02:15 YPTM: Matthew Weigel joined the call. Nov 26 16:02:26 YPTM: ross on the call Nov 26 16:02:31 alex d here Nov 26 16:02:33 YPTM: jzhang on the all Nov 26 16:02:57 YPTM: Any opens? Nov 26 16:03:18 cristiana on the call Nov 26 16:03:55 RP: bz filed 5603 Nov 26 16:04:26 YPTM: Bruce will be late Nov 26 16:04:55 YPTM: polk is on Nov 26 16:06:54 RP: I am looking on the commit mentioned on 5603 Nov 26 16:11:13 cristianav: this is related to the server reset issue. Somehow we need to optimise the reset process so we minimise the performance impact Nov 26 16:12:32 pidge: is deletion documented in the AB setup docs? Nov 26 16:14:10 YPTM: Oh right, Darren is on Nov 26 16:16:30 RP: also, there is another issue regarding the post/pre conf files received by the server. Those should be saved somehow. Now the reset() function on cooker is not well implemented, because it does not consider post/pre files Nov 26 16:19:28 cristianav: yes, we need to handle that Nov 26 16:20:34 I also don't know if the changes I made for the auto port configuration affect the toaster or not. Nov 26 16:20:56 I just assumed the toaster used the same mechanism for hooking up to the xmlrpc class. Nov 26 16:22:47 YPTM: thank you all for joining the meeting. have a nice day/evening. Nov 26 16:23:18 bluelightning: can those four lines be removed? http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-core/packagegroups/packagegroup-core-boot.bb#n20 Nov 26 16:23:34 (oopsie, sorry, did not realize the call...) Nov 26 16:23:41 Hi all, may I ask a question about qemu ? Nov 26 16:23:59 Wolfkiller: yes Nov 26 16:24:21 bluelightning: removed in my copied package group file, that is. Nov 26 16:24:53 I've built an image after making a custom BSP, and the Kernel doesn't seem to boot. Can I use qemu to findout what's wrong ? Nov 26 16:25:25 The problem is : I don't have serial frm the kernel on my board once the kernel is loaded, so I don't think I can debug anything on the board Nov 26 16:27:01 lpapp: er, I'd suggest creating your own packagegroup from scratch a la what is shown in the manual, rather than copying this one Nov 26 16:27:14 bluelightning: yes, I was doing that Nov 26 16:27:23 bluelightning: although I am not sure I need PACKAGES = "\ Nov 26 16:27:23 packagegroup-custom-apps \ Nov 26 16:27:23 packagegroup-custom-tools \ Nov 26 16:27:24 Nov 26 16:27:32 bluelightning: that is superflous if I only need one group, right? Nov 26 16:28:04 lpapp: yep, PACKAGES is set to "${PN}" by default in packagegroup.bbclass Nov 26 16:29:06 what to write for proprietary license? Nov 26 16:29:48 LICENSE = "Proprietary" Nov 26 16:29:59 you'll still have to provide the license text though Nov 26 16:30:05 otherwise set to to "CLOSED" Nov 26 16:30:06 bluelightning: http://pastebin.kde.org/peqruw8n2 Nov 26 16:30:10 is that it? Nov 26 16:30:33 CLOSED or Closed? Nov 26 16:30:46 lpapp: CLOSED Nov 26 16:31:23 lpapp: the LICENSE field for a package that's empty such as a packagegroup doesn't really have much meaning though Nov 26 16:31:44 lpapp: yes that recipe should be sufficient Nov 26 16:33:11 bluelightning: IMAGE_INSTALL = "packagegroup-core-boot packagegroup-foo ${ROOTFS_PKGMANAGE_BOOTSTRAP} ${CORE_IMAGE_EXTRA_INSTALL}" ? Nov 26 16:33:23 lpapp: yep Nov 26 16:34:16 bluelightning: parse error Nov 26 16:34:38 lpapp: specifically? Nov 26 16:34:42 to run qemu I've tried several commands, and one I consider correct ends with "Error: No QEMU binary 'qemu-system-arm' could be found" Nov 26 16:34:43 in packagegroup-foo.bb Nov 26 16:35:15 oh, Nov 26 16:35:20 I need the closing double quote Nov 26 16:35:29 in the last line. Nov 26 16:35:57 Wolfkiller: you'd need to build qemu-native to have that binary in the sysroot Nov 26 16:36:01 bluelightning: is there a way to verify the packages are built without flashing the rootfs? Nov 26 16:36:07 i.e. in the yocto build folder somehow. Nov 26 16:36:15 log, existing packages, etc. Nov 26 16:36:50 lpapp: ls tmp/deploy/(ipk|rpm|deb)/*packagename* ? Nov 26 16:36:59 thanks. Where may I find this information myself please? Nov 26 16:37:56 Wolfkiller: when building for a qemu* machine we build that automatically; becuase you are building for a real machine you need to do it manually Nov 26 16:38:07 where's the spot to tell oe that i do not only want a zimage, but also an umiage? :) Nov 26 16:38:08 bluelightning: that does not yet mean those packages are built into the root by default. Nov 26 16:38:58 lpapp: if you've done what you pasted above they will be. If you want to be sure you'll just have to build the image I'm afraid Nov 26 16:39:23 bluelightning: thanks, i can't find qemu-native in the mega-manual Nov 26 16:40:09 Wolfkiller: I don't think it is, no... but I'm not sure this is a common use case Nov 26 16:40:57 do you mean, building for real machines and trying to debug the image in emulator isn't common use case ? Nov 26 16:41:30 bluelightning: http://pastebin.kde.org/ptjgbwond Nov 26 16:41:46 in that case I may be doing things wrong... Nov 26 16:42:36 Wolfkiller: I'm no kind of expert in that area but AIUI typically you would debug on the real hardware - enable serial output for the kernel, early printk, etc. Nov 26 16:42:40 lpapp, if you are building the image (Which it sounds like you are), then I find just looking in tmp/work////rootfs/ is the best way to see the constructed rootfs without flashing it. Nov 26 16:42:44 bluelightning: bitbake bar and bitbake baz work fine Nov 26 16:42:53 but maybe you are already looking there. Nov 26 16:42:58 * zeddii goes back to email Nov 26 16:43:19 bluelightning: why does foo-core-imagen not work fine then? Nov 26 16:43:26 lpapp: if baz does not produce a package called baz then you'll get that failure because RDEPENDS refers to packages, not recipes Nov 26 16:44:09 bluelightning: Emulation didn't work as expected : qemu: fatal: Trying to execute code outside RAM or ROM at 0x20008000 Nov 26 16:45:24 bluelightning: the problem is that there several folders in tmp/work Nov 26 16:45:29 which one should I check? Nov 26 16:45:39 and find in each of them takes a long while. Nov 26 16:46:14 lpapp: the directory under tmp/work/ corresponds to the package architecture for the recipe Nov 26 16:46:28 or use "bb" Nov 26 16:46:36 rburton: don't go there.. Nov 26 16:46:39 heh Nov 26 16:46:54 ? Nov 26 16:46:55 it doesn't have a "what packages did [recipe] produce" option, which is a shame Nov 26 16:47:24 lpapp: bitbake -e | grep ^PACKAGES will tell the list of generated packages for Nov 26 16:47:44 otherwise you can enable buildhistory, and you will get that info too, post build. Nov 26 16:47:48 rburton: serious or joking? Nov 26 16:48:10 bluelightning: ./tmp/work/armv5te-foo-linux-gnueabi/bar/0.1-r0/packages-split/bar Nov 26 16:48:10 I have that Nov 26 16:48:21 lpapp: is there anything in it? Nov 26 16:48:33 nope Nov 26 16:48:36 right, bingo Nov 26 16:48:59 to a certain definition of right. ;) Nov 26 16:49:00 empty packages by default are not actually packaged unless ALLOW_EMPTY_ is set in the recipe Nov 26 16:49:22 bluelightning: well, it does have .bb recipe Nov 26 16:49:26 so why is the package not generated? Nov 26 16:49:55 bluelightning: http://pastebin.kde.org/p4sr59f3l Nov 26 16:49:57 this is the recipe. Nov 26 16:50:16 ...where's the spot to tell oe that i do not only want a zimage, but also an umiage? :) Nov 26 16:50:57 KERNEL_IMAGETYPE = "uImage" Nov 26 16:51:06 in your machine config. Nov 26 16:51:09 i think it's one *or* the other. Nov 26 16:51:10 lpapp: since you've clearly edited this recipe it's not clear, but if this is the whole recipe it's not sufficient to actually package anything Nov 26 16:51:54 lpapp: most importantly, base.bbclass (inherited implicitly by every recipe) doesn't implement do_install, so that won't be installing anything -> no package will be able to have any contents Nov 26 16:51:58