**** BEGIN LOGGING AT Wed Mar 27 02:59:58 2013 Mar 27 05:03:16 Welcome and مرحبا. This is The official Arabic language help channel and Arabic culture. Stay to meet Arabs. To render Arabic letters use the command: /charset unicode .قناة تعلم اللغة العربية و ثقافتها. استعمل الترميز يونكود لوضوح الكتابة العربية . #.hadidah Mar 27 05:03:55 Welcome and مرحبا. This is The official Arabic language help channel and Arabic culture. Stay to meet Arabs. To render Arabic letters use the command: /charset unicode .قناة تعلم اللغة العربية و ثقافتها. استعمل الترميز يونكود لوضوح الكتابة العربية .#HaDiDaH Mar 27 08:19:02 good morning Mar 27 08:46:58 HI Mar 27 08:47:04 Good afternoon Mar 27 08:47:25 bhaskar: hello Mar 27 08:47:49 When i am building some modules its building successfull but its not creating ipk file and even not giving any error message also Mar 27 08:48:07 Hello mckoan Mar 27 08:48:18 What can be the problem Mar 27 08:48:49 bhaskar: when you say 'module' do you mean a recipe? Mar 27 08:49:51 yes Mar 27 08:51:42 and some situations like if i add FILES_${PN} = "/lib/lib* /bin/*" Mar 27 08:52:04 then its creating ipk which is dev, debug ipk not actual module ipk Mar 27 08:54:40 bhaskar: which is the recipe? Mar 27 08:55:46 i have prebuild binaries and libreries Mar 27 08:55:57 for that we have written recippe Mar 27 08:58:10 image.bbclass Mar 27 08:59:34 hi Mar 27 09:00:24 why does do_package_qa occur? Mar 27 09:03:17 i'm using my own toolchain Mar 27 09:04:22 so when i'build any module i get an error (ex: db8 rdepends on external-toolchain-dev) Mar 27 09:04:51 external-toolchain is my bitbake file for toolchain Mar 27 09:07:36 LICENSE = "MIT" do_qa_configure () { : } #DEPENDS = "external-gf-toolchain" S = "${WORKDIR}/prebuilt-toolchain" PR = "r24" do_install() { export sysroot="${EXTERNAL_TOOLCHAIN}/${LG_TARGET_SYS}/sysroot" install -d ${D}/usr install -d ${D}/usr/include install -d ${D}/usr/lib install -d ${D}/var install -d ${D}/etc cp -rfn ${EXTERNAL_TOOLCHAIN}/prebuilt/opengl_lib/include/* ${D}/${includedir} cp -rfn ${EXTERNAL_TOOLCHAIN}/preb Mar 27 09:08:33 mckoan : Please have look which i pasted above Mar 27 09:09:31 its my recopee conent Mar 27 09:10:57 ~pastebin Mar 27 09:10:58 A "pastebin" is a web-based service where you should paste anything over 3 lines so you don't flood the channel. Here are links to a few: http://www.pastebin.com, http://pastebin.ca, http://channels.debian.net/paste, http://paste.lisp.org, http://bin.cakephp.org/; or install pastebinit with yum or aptitude. Mar 27 09:12:36 Hi mckoan i pasted here http://pastebin.com/SiURviHN Mar 27 09:19:46 morning all Mar 27 09:21:36 silvio: hi Mar 27 09:21:50 bhaskar: your recipe should be *.bb Mar 27 09:21:57 hi mckoan Mar 27 09:21:59 bhaskar: where did you put it? Mar 27 09:23:35 recipee conent i pasted Mar 27 09:24:15 http://pastebin.com/SiURviHN Mar 27 09:24:32 morning all Mar 27 09:24:35 click n that link Mar 27 09:24:42 it will hsow my source code Mar 27 09:24:58 hi bluelightning Mar 27 09:26:42 mckoan : are you able to open it? Mar 27 09:37:35 bhaskar: in which directory did you put it? Mar 27 09:39:11 recipe-devtools Mar 27 09:49:03 bhaskar: if your layer.conf specifies recipes-* then it should be called "recipes-devtools" not "recipe-devtools" Mar 27 09:54:14 hello Mar 27 10:04:37 : its recipes-devtools only its my spelling mistake in chat Mar 27 10:04:44 recipee is building Mar 27 10:04:55 problem is its not creating actual ipk Mar 27 10:05:05 its creating dev,debug ipks Mar 27 10:06:54 bhaskar: look under image/ in the workdir for the recipe (tmp/work/*/recipename) Mar 27 10:06:59 are there files there? Mar 27 10:07:54 yes files are there in image folder Mar 27 10:10:18 In deploy-ipks folder also created, but it has only dev,debug ipks not actual rmodule ipk Mar 27 10:15:03 bhaskar: are you getting warnings about unpackaged files? Mar 27 10:24:31 bluelightning : its not giving any warning also Mar 27 10:25:05 bhaskar: oh, of course - it wouldn't since you've stubbed out do_package_qa which you shouldn't be doing Mar 27 10:25:16 bhaskar: I would suggest removing that Mar 27 10:25:33 if you really must disable some QA warnings there is a proper way to do that selectively Mar 27 10:31:18 if i remove do_package_qa() Mar 27 10:31:23 then its giving ERROR: QA run found fatal errors. Please consider fixing them. ERROR: Function failed: do_package_qa Mar 27 10:31:45 ERROR: QA Issue: prebuilt-toolchaiin-libraries rdepends on prebuilt-toolchaiin-libraries-dev Mar 27 10:31:54 ERROR: QA Issue: prebuilt-toolchaiin-libraries rdepends on external-gf-toolchain-dev Mar 27 10:33:52 bluelightning : i am getting above error if i remove do_package_qa Mar 27 10:34:18 bhaskar: in that case I imagine you have files going into *-dev that shouldn't be Mar 27 10:34:40 bhaskar: look under packages-split/ in the workdir to see where files are being placed Mar 27 10:36:41 files are places in packages-split/ Mar 27 10:37:21 Please let me know why do_package_qa will fail? Mar 27 10:37:34 how can i fix them Mar 27 10:37:46 you got the answer on this channel at least 3 times already :) Mar 27 10:38:25 What all suggested i have seen it Mar 27 10:38:32 but it was not resolved Mar 27 10:38:39 I m building "my" sdk, there is a way to include all qt4 dependency easly? Mar 27 10:39:19 JaMa : i am not getting correct reason why its getting failed do_package_qa Mar 27 10:40:12 it's linking with something packaged in -dev package Mar 27 10:40:23 bhaskar: PN files should not link with PN-dev Mar 27 10:40:44 it's because something shouldn't be in prebuilt-toolchaiin-libraries-dev Mar 27 10:41:10 How can we check that and resolve , beacause i am bit struggling on it , please help me on it Mar 27 10:42:10 Please guid/ suggest me so that i can work on it exactly Mar 27 10:45:37 JaMa : log.do_package file i am getting ERROR: ld.so: object 'libpseudo.so' from LD_PRELOAD cannot be preloaded: ignored. ERROR: ld.so: object 'libpseudo.so' from LD_PRELOAD cannot be preloaded: ignored. Mar 27 10:59:39 bhaskar: that is not the actual error Mar 27 10:59:59 u check the log file again for other errors Mar 27 11:00:14 u can also check for fatal error Mar 27 11:00:53 or no such file or directory Mar 27 11:17:49 oe-core : log.do_package_qa i am not able to see other then that error Mar 27 12:05:40 ------ oe-core : Please find my do_package log file which is failing do_package_qa() function in this link pastebin.com/E9ee3Z0D Mar 27 12:06:41 bluelightning, ping Mar 27 12:06:43 please some one look into my log and help me to resolve Mar 27 12:06:52 i am stuck with this error from 1 week Mar 27 12:06:54 bbiab Mar 27 12:07:00 Crofton|work: hi Mar 27 12:07:55 bhaskar: you need to set the FILES_ values so that the things that shouldn't be in -dev don't go there Mar 27 12:08:25 bhaskar: i.e. keep adjusting values until packages-split/ looks correct Mar 27 12:08:44 once you have the layout correct the warning will go away Mar 27 12:09:47 bluelightning : how i knows which all files Mar 27 12:11:14 bhaskar: the ${PN}-dev package is for development headers and files only needed for building on the target Mar 27 12:11:44 bhaskar: all files needed by the software for normal operation need to go into the main package (${PN}) Mar 27 12:12:29 you have some files going into ${PN} that link to files in ${PN}-dev (e.g. .so files that aren't symlinks) Mar 27 12:13:07 when packaging, the system looks through the packages listed in the PACKAGES variable, and checks the value of FILES_ for each one Mar 27 12:13:49 the first package whose FILES_ value matches a file to be packaged gets the file Mar 27 12:21:16 is there is any way to avoid writing FILES_${PN} = Mar 27 12:21:25 without that how we can do Mar 27 12:21:37 bcz lot of modules and libraries are there Mar 27 12:30:27 bluelightning, so I noticed one wierd thing with populate_sdk and dev-pkgs Mar 27 12:30:50 if I tell it to put libudev in the image, it does not bput libudev-dev in the sdk Mar 27 12:31:04 unless I also select libudev-dev for the image Mar 27 12:31:13 bhaskar: you can specify directory names as well and everything underneath Mar 27 12:31:28 bhaskar: you can also set FILES_${PN}-dev = "" temporarily Mar 27 12:32:00 Crofton|work: yes I know... there is some logic to do that mapping and I guess that case isn't handled Mar 27 12:32:24 ok Mar 27 12:32:27 should I make a bug Mar 27 12:32:36 Crofton|work: yes and assign to me Mar 27 12:32:52 Crofton|work: should udev-dev depend upon libudev-dev ? Mar 27 12:33:05 in fact I wonder that it doesn't Mar 27 12:33:13 hand on, let meget the package names Mar 27 12:33:32 the cat is hampering Mar 27 12:33:54 ibudev-dbg_182-r6_armv7a-vfp-neon.ipk Mar 27 12:33:55 libudev-dev_182-r6_armv7a-vfp-neon.ipk Mar 27 12:33:55 libudev0_182-r6_armv7a-vfp-neon.ipk Mar 27 12:34:11 without libudev-dev in the extra install, the package is missing Mar 27 12:34:16 dbg is picked up fine Mar 27 12:34:33 obviously I dropped a leading l fro the dbg package name Mar 27 12:34:56 I am not sure if udev sucks in libudev Mar 27 13:24:18 bluelightning , oe-core , JaMa : Thanks all for your help Mar 27 13:24:34 at the end i understood the what can be the issue Mar 27 13:24:37 and how to solve Mar 27 13:24:54 i am able to solve some modules with above u suggested way Mar 27 13:24:59 thanks a lot all Mar 27 13:35:57 Crofton|work: I'm guessing it doesn't since if it did the dev package would be there via dependencies Mar 27 13:36:06 yeah Mar 27 13:36:35 I wonder if the issue is due to both ending in dev Mar 27 14:47:46 JaMa: where are meta-smartphone BSP layers meant to get linux.inc from? meta-oe? Mar 27 14:49:26 bluelightning: yes, meta-oe Mar 27 14:49:42 JaMa: ok thanks... some of the READMEs don't list that, FWIW Mar 27 14:50:33 true, I'll fix that, thanks Mar 27 14:51:02 JaMa: should you be listed as the meta-geeksphone maintainer or someone else? Mar 27 14:55:51 bluelightning: vquicksilver contributed that completely Mar 27 14:56:05 bluelightning: I don't have the device to maintain it myself Mar 27 14:56:54 JaMa: ok I will put his name in Mar 27 15:02:40 bluelightning: fixed in master and shr branches Mar 27 15:04:07 JaMa: who is/are the meta-gnome maintainer(s) these days? you and koen? Mar 27 15:06:14 I'm applying patches, but don't use 99% of meta-gnome recipes Mar 27 15:06:25 so I depend on other people on ML to review them Mar 27 15:06:45 ah this is for layerindex, right? Mar 27 15:07:01 I was thinking what you want to contribute to geeksphone :) Mar 27 15:08:30 JaMa: it is indeed for the layerindex Mar 27 15:24:19 hi Mar 27 15:24:52 when i'm adding FILES_${PN} = ${libdir}/* Mar 27 15:24:59 its throwing error Mar 27 15:25:25 oe-core: are you quoting that value? Mar 27 15:25:31 non -dev/-dbg/-nativesdk package contains symlink .so: Mar 27 15:25:33 and you don't need /* Mar 27 15:25:49 how do i avoid packaging symling Mar 27 15:25:54 symlink Mar 27 15:26:37 oe-core: see how the default value in bitbake.conf does it Mar 27 15:26:39 i just need the ipk to be created containing .so files Mar 27 15:27:04 so that they will be available in rootfs Mar 27 15:27:06 ${libdir}/lib*${SOLIBS} Mar 27 15:27:51 if there are non-symlink .so files mixed in you'll have to mention them explicitly as well Mar 27 15:28:10 but there are many Mar 27 15:28:58 will this avoid copying symlinks ${libdir}/lib*${SOLIBS} Mar 27 15:29:44 bluelightning Mar 27 15:29:51 :thanks a lot Mar 27 15:30:05 its not copying symlinks nw Mar 27 15:30:10 np Mar 27 15:30:17 and error resolved Mar 27 15:37:17 oe-core: if you still have QA errors you have non-symlink so's making it into the -dev package Mar 27 15:37:54 when i'm packaging ${bindir} ERROR: QA Issue: yajl rdepends on prebuilt-toolchaiin-libraries-dev Mar 27 15:38:18 ^ Mar 27 15:38:44 you'll need to mention those explicitly in FILES_${PN} Mar 27 15:39:02 prebuilt-toolchaiin-librarie is the bb file for which i had symlinks which got resolved Mar 27 15:39:06 either your package, yajl is broken.. (it's requirement development items).. or more likely your "prebuilt-toolchain-libraries-dev" is broken, as it's providing non-development files in a -dev package Mar 27 15:39:39 symlinks are not enough.. the actualy runtime files should be in the base package, while -dev only holds static libraries and symlinks != the soname of the shared libraries Mar 27 15:39:54 any symlinks that contain the soname should be in the base library. Mar 27 15:40:00 base library -package- that is Mar 27 15:44:27 so u mean to say dev package doesnt contain any .so files, but symlinks to them? Mar 27 15:46:57 yes.. Mar 27 15:47:21 you shouild be getting a QA warning in the creation of the prebuild-toolchain-libraries-* packages that they have incorrect components, unless your recipes have disabled them Mar 27 15:51:23 bluelightning, any reason not to file a bug with my libudev, dev-pkg and sdk issue? Mar 27 15:52:04 which mailing list should I send mail to get some suggestions about my OE/Yocto talk? Mar 27 15:52:11 i got the warning saying No GNU_HASH in the elf-binary Mar 27 15:52:13 Crofton|work: there does seem to be a bug, whether it's in the metadata or elsewhere, so please file it Mar 27 15:52:20 k Mar 27 15:52:36 I worked around for now, just want to get some other eyes on it Mar 27 15:52:39 bluelightning JaMa: any ideas? Mar 27 15:52:41 eren: main yocto mailing list I would think Mar 27 15:53:04 I can cross build uhd with it now Mar 27 15:53:41 bluelightning: ok. OE lists are fully technical, I guess CC'ing them would not be appropriate Mar 27 15:54:47 it might be a bit much for this kind of thing yeah Mar 27 15:55:40 excessive cc'ing is annoying :) Mar 27 15:57:54 right :) Mar 27 16:20:23 oe-core -- the warning says that the binaries you produced do not have a 'GNU_HASH' section in them. There are two ways the symbols can be resolved either via the GNU_HASH or via a SYSV style approach.. The GNU_HASH is more efficient in many cases.. Mar 27 16:20:50 we've moved to defaulting to GNU_HASH, if your toolchain doesn't have it on.. it should (or you should ask your vendor to enable it in their binaries).. Mar 27 16:21:07 if it's individual applications that are missing it, then you can usually ignore the warning with no ill effects Mar 27 16:54:14 Hi. Why does gnomebase append ;name=archive to SRC_URI? Is that really necessary? I'm trying to update libgsf. If I wget 'http://ftp.gnome.org/pub/GNOME/sources/libgsf/1.14/libgsf-1.14.26.tar.xz;name=archive' if fails (404). If I remove ;name=archive, it works. Mar 27 16:55:21 mario-goulart: that part should never actually be passed to wget by the fetcher Mar 27 16:55:56 mario-goulart: the name is used e.g. so that you can associate a SRC_URI checksum with the entry when there are multiple entries Mar 27 17:02:00 bluelightning: hmmm. I'm observing something weird here (or a misleading error message). Or I'm missing something, naturally. :-) http://paste.debian.net/245169/ Mar 27 17:02:54 mario-goulart: the file not existing is expected if the checksum mismatches Mar 27 17:03:14 mario-goulart: the full fetch URL including extra parameters being printed there is also expected Mar 27 17:19:27 Ok. Call me stupid, but I don't understand the fetch error: http://paste.debian.net/245171/ Mar 27 17:19:42 This looks ok: http://paste.debian.net/245174/ Mar 27 17:20:02 I do have Mar 27 17:20:05 SRC_URI[archive.md5sum] = "3c5a4fbd16a727c36974078e6d0e9575" Mar 27 17:20:05 SRC_URI[archive.sha256sum] = "8919e725aadd785380350c8dec7427d82cf33164bc9a9a549df9440a0c3da6d5" Mar 27 17:20:10 in the recipe. Mar 27 17:36:43 mario-goulart: I'm confused as well then... Mar 27 17:38:31 bluelightning: this is only work in progres, but what do you think? http://bpaste.net/show/87043/ Mar 27 17:40:00 JaMa: I think I'm still not understanding the situation you're trying to detect Mar 27 17:41:15 JaMa: probably because I'm less familiar with this particular area Mar 27 17:41:19 bluelightning: when remote git repositori moves tag v1.0 to some other revision Mar 27 17:41:42 bluelightning: fetcher will "detect" that because it runs git ls-remote to map tags to revisions Mar 27 17:41:56 so it will build the same metadata, but with newer sources Mar 27 17:42:33 right, got it Mar 27 17:42:44 which is better situation then different builders building same tag but with different revisions Mar 27 17:42:58 but worth showing warning when something like that happens Mar 27 17:43:26 webos is using tags instead of SRCREVs for everything :/ Mar 27 17:43:36 bluelightning: thanks for looking at it. I'm gonna work around that problem for now and try to investigate it further later. Mar 27 17:43:56 JaMa: why do you want the # SRCREV values? surely you only want the actual end value i.e. the uncommented lines? Mar 27 17:44:35 yes but I want to know if it's the same tag as before Mar 27 17:44:43 because different tag and different srcrev is OK Mar 27 17:45:13 warning is when only one of them is different then last time Mar 27 17:45:34 but then surely you would compare the tag you're about to write with the existing tag and the SRCREV with the actual SRCREV you're about to write? Mar 27 17:45:56 yes, that's what pastebin is supposed to do :) Mar 27 17:46:09 then I don't see how the SRCREV value Mar 27 17:46:11 er Mar 27 17:46:17 damned UK keyboards Mar 27 17:46:43 I don't see how the "# SRCREV = " values are needed, those are what SRCREV is set to in the recipe Mar 27 17:47:07 I don't need those, they were there before Mar 27 17:47:30 I need # tag_name_foo = "abc" Mar 27 17:47:31 right, then I would suggest not reading them at all, currently you are Mar 27 17:47:40 although the values are being wiped out Mar 27 17:47:47 you mean to the data variable, right? Mar 27 17:47:51 yes Mar 27 17:48:20 true, it's not even tested yet (probably won't read tag param correctly as it is now) Mar 27 17:49:26 JaMa: ok, other than that the approach seems reasonable Mar 27 17:49:47 ok, I'll get it working and send to ML Mar 27 17:51:27 JaMa: integrated with my earlier patch I presume? Mar 27 17:51:55 Or separate follow up patch Mar 27 17:52:34 I'd prefer to make it one Mar 27 17:52:43 ok Mar 27 17:54:14 saves Richard one patch to review :) Mar 27 17:54:56 true, but I'm not sure if I'll finish it today, but your patch (with s/path.remove/remove/g) is good to go already Mar 27 17:56:43 JaMa: true, and they're reasonably independent Mar 27 17:57:17 JaMa: one issue with your change; what if there's a SRC_URI entry called tag_foo ? Mar 27 17:57:32 unlikely and asking for trouble, but possible Mar 27 17:58:32 I was thinking about some weird prefix or at least separator, I'll try harder before sending it to ML Mar 27 17:58:37 * JaMa off for hour or so Mar 27 17:58:58 ok... some other stylistic issues there too but we can discuss later Mar 27 18:18:41 to get something in the host part of the sdk, it needs a native-sdk option? Mar 27 18:19:31 Crofton|work: think so yes Mar 27 18:19:40 apparently i didn't get enough coffee this morning... Mar 27 18:20:19 must update orc ... Mar 27 18:20:23 when is the release? Mar 27 18:21:07 bluelightning, are you goign to take care to the dev-pkg sdk fix? Mar 27 18:28:45 Crofton|work: I'll look at it tomorrow yes Mar 27 18:28:52 thanks Mar 27 18:29:07 my other stuff (nativesdk addds) are in meta-oe Mar 27 18:29:36 Crofton|work: https://wiki.yoctoproject.org/wiki/Yocto_1.4_Schedule Mar 27 18:30:48 ok, I recall some reference to a march release, and niming if it went to April in meeting minutes :) Mar 27 21:30:42 guys: can someone remind me how to make VAR = "{if ${SOME_VAR} == "val1", "ans1", "ans2"}"? Mar 27 21:33:57 @base_conditional ;) Mar 27 22:15:23 hrw: ${@base_contains('DISTRO_FEATURES', 'ipv6', 'ipv6', '', d)} Mar 27 22:15:54 will return ipv6 if ipv6 is one if DISTRO_FEATURES else returns empty str Mar 27 22:16:04 +CACHED_CONFIGUREVARS = 'ac_cv_c_endian=${@base_conditional("SITEINFO_ENDIANNESS", "le", "little", "big", d)}' Mar 27 22:16:09 in my case Mar 27 22:16:28 yes that works Mar 27 22:16:49 probably better would be to add it to site files Mar 27 22:18:19 khem: http://pastebin.com/7yE7vjfR Mar 27 22:31:25 khem: what do you think? worth submitting? Mar 27 22:58:50 hrw: seems ok Mar 27 23:06:56 hrw: although you should include it in machine confs **** ENDING LOGGING AT Thu Mar 28 02:59:58 2013