**** BEGIN LOGGING AT Fri Oct 21 02:59:57 2011 Oct 21 03:39:17 zenlinux: I sent the patches I did Oct 21 03:40:52 zenlinux: take a look when you can Oct 21 03:41:14 RP__: don't merge dbus before base-passwd Oct 21 03:41:19 RP__: otherwise it will break Oct 21 03:43:45 thanks otavio, I'll give it an Acked by shortly Oct 21 03:47:42 good night people Oct 21 03:47:46 2am here Oct 21 03:47:49 heh bye Oct 21 05:17:30 JaMa|zzz: I have restored the python commits in the nitin/python branch on the poky contrib Oct 21 06:21:27 nitink: thanks I'll try Oct 21 07:29:55 good morning Oct 21 10:44:56 anyone was able to bitbake meta-toolchain there? Oct 21 14:12:24 whats the proper url for the edison tar ball ? Oct 21 14:15:13 the one from the quick start guide redirects to a nonexistent location Oct 21 14:19:34 found a working link on the download page Oct 21 16:21:06 msm: Good Morning Oct 21 16:23:22 sgw: hello Oct 21 16:24:38 msm: I am looking back in my email at patch/pull requests and wanted to verify that all your various changes are in, there was alot of back and forth on some of them. If they great, if not, could you pull together and another pull request summary. Oct 21 16:28:07 sgw: let me look Oct 21 16:29:04 msm: thanks, alot of those RP picked up, and my tracking was not great thru there because of the 1.1 release stuff Oct 21 16:29:25 sgw: I think there is only one patch, let me find a thread link Oct 21 16:44:34 sgw: this one was it: http://lists.linuxtogo.org/pipermail/openembedded-core/2011-October/010654.html Oct 21 16:45:23 sgw: there was an issue with it though, and and me and RP talked about it but did not decide on a final way to do it Oct 21 16:45:37 aka fix bitbake or tweak the patch Oct 21 16:46:51 Ok, I was just checking, I thought there was a different one, maybe the libnl I see it on one of my lists, but not merged. Oct 21 16:47:14 sgw: there was a whole copy of libnl from oe to yocto Oct 21 16:47:24 but - i could not really test that Oct 21 16:47:43 but my previous parallel build fix to libnl got applied Oct 21 16:47:56 so my immediate issue was resolved Oct 21 16:48:16 Ok, so no plans on finishing up with the libnl patch? Oct 21 16:50:04 sgw: I have no way to test it - other than compiling it Oct 21 16:50:36 i think that was my conclusion - let me find that thread again Oct 21 16:51:18 sgw: yep, you ask me to test with wpa-supplicant… i dont have hardware with wireless.. Oct 21 16:56:35 Ok, just confirming. Thanks. Oct 21 16:59:18 sgw: some of the changes I posted lately are either in mailing list and other half is in pull request have you picked them up if not then I can just refresh the pull request with everything I have scattered Oct 21 17:01:11 khem, I think I have them pulled together right now, I am working my way through the list and will update the stage/master_under_test shortly. Do you want me to ping you when I do that so you can confirm everything is correct? Oct 21 17:05:58 sgw: sure Oct 21 17:06:16 I sent a V2 of a patch on ml I hope you picked that up Oct 21 17:06:41 and there was a comment I addressed in one of the patches from pull request I think that was day before yesterday Oct 21 17:06:59 if you have those two pieces correct then you have all latest I had Oct 21 17:07:34 I should just create a persistent contrib tree Oct 21 17:07:58 and refresh it when ever I have misc patches whcih are not major features Oct 21 17:08:46 sgw: libtool changes would need a build from scratch and also try out the SDK builds Oct 21 17:09:04 so that libtool-cross and libtools-nativesdk get a bit of excercise Oct 21 17:09:11 khem, that would be find. I will be putting this into the AB as well as building using exsiting world build Oct 21 17:10:07 alright Oct 21 17:15:12 so, if I try to build two images simultaniously on this particular machine, cp errors out trying to copy the readme into DEPLOY_DIR_IMAGE. the error message is that the file already exists. odd, no? considering cp normally happily overwrites an existing file, unless there's permissions issues or so. My blind guess is its a race in cp's logic about whether to write or not. If I serialize the image creations, it doesn't occur Oct 21 17:15:20 Anyone run into anything remotely related? Oct 21 17:15:37 "cp: cannot create regular file '....': File exists" Oct 21 17:31:45 Hi, Is this yocto chat room? Oct 21 17:36:52 that would be why its called #yocto, yes :) Oct 21 17:38:02 ok. This is first time I am using this. So wanted to double confirm. Oct 21 17:38:04 Thank You. Oct 21 17:40:49 I get error failed dependencies:libc.so.1 needed by ...... for my package I am building with yocto and build fails for the core-image-sato for task-do-rootfs. Can anyone let me know what went wrong here? Oct 21 17:41:57 khem: just updated contrib/stage/master_under_test, let me know if I got all your bits. Oct 21 17:42:38 NOTE: package core-image-sato-1.0-r0: task do_rootfs: Failed Oct 21 17:43:35 kishore: are you using head or edison, did you make any changes? Oct 21 17:44:48 I am using edison. I did not make any changes, but added IMAGE_INSTALL += "" to core-image-sato.bb file Oct 21 17:45:38 Did you get a clean image before adding that line? Oct 21 17:45:52 yes. Oct 21 17:46:48 Please note, before I was able to build my package with that line added. Oct 21 17:47:15 Now I wanted to update to edison, and suddenly it started giving that error message. Oct 21 17:48:32 So, when you upgraded to edison you build the sato image (with out your change) and it worked, correct? Oct 21 17:48:32 Also your older version build sato (with your change) and it worked, correct? Oct 21 17:49:20 Yes for both questions. Oct 21 17:50:03 and you rebuilt your package for edison? Oct 21 17:50:13 yes. Oct 21 17:51:06 kishore: I would have to start digging into packging, one question is did you use sstate to rebuild edison? Oct 21 17:52:24 I am not sure of that, I just pulled the fresh edison branch of poky and meta-intel and a local clone of linux-yocto-3.0 Oct 21 17:54:55 error: Failed dependencies: | libc.so.1 is needed by icp-qa-al-1.0-r0.x86_64 | ERROR: Function 'do_rootfs' failed. Oct 21 17:54:56 NOTE: package core-image-sato-1.0-r0: task do_rootfs: Failed Oct 21 17:58:05 kishore: check pm please Oct 21 17:59:30 what is pm? Oct 21 17:59:47 private message Oct 21 19:09:57 sgw: are there some world build logs around. I want to look at "installed but not shipped" warnings Oct 21 19:10:13 we need to clean it up and then turn that warning into error Oct 21 19:21:44 Hi Oct 21 19:22:01 I need to put an so in sysroot but it seems it is not done by default Oct 21 19:22:03 a native one Oct 21 19:22:16 how do I do that? Oct 21 19:22:48 install it in do_install. Oct 21 19:22:51 done. Oct 21 19:23:04 kergoth: it is done at it Oct 21 19:23:09 libcap.inc Oct 21 19:23:15 if it was done, it'd be in sysroot Oct 21 19:23:23 unless its installed to a non-standard location Oct 21 19:23:25 kergoth: it seems it is not Oct 21 19:23:39 sysroot is populated by files installed to ${D}, but it only grabs certain dirs from it Oct 21 19:23:46 if its in ${D}${libdir} it'd show up in the sysroot Oct 21 19:24:01 * otavio rebuilds libcap Oct 21 19:24:38 http://paste.debian.net/138623/ Oct 21 19:26:17 kergoth: on target version it is in sysroot Oct 21 19:26:22 kergoth: but the native one is not Oct 21 19:35:13 ahh Oct 21 19:35:24 libcap-native endded up being installed into lib64 Oct 21 19:35:42 The /usr/lib64 is made available in the sysroot ? Oct 21 19:39:09 ahh Oct 21 19:39:14 * kergoth has no clue on that Oct 21 19:39:57 it seems it doesn't Oct 21 19:43:41 transfig-native has a hack for it Oct 21 19:43:53 it uses sed to mangle the makefile Oct 21 20:34:44 khem: ping Oct 21 20:37:19 sgw: yes Oct 21 20:37:56 khem, I think you can get what you want from autobuilder.yoctoproject.org and take a look at the logs from the various builds **** ENDING LOGGING AT Sat Oct 22 02:59:56 2011