**** BEGIN LOGGING AT Mon Mar 18 02:59:58 2013 Mar 18 07:37:53 hello Mar 18 07:56:11 morning Mar 18 07:56:56 JaMa: I think there are some issues with meta-qt5 on 32-bit systems. Are you on 64-bit? Mar 18 08:01:28 yes I'm on 64-bit Mar 18 08:01:41 Is there something I can put in a recipe/conf to generate sdk for both 32 and 64 bit hosts? Mar 18 08:01:45 but there are many issues, can you pastebin what issues you see? Mar 18 08:02:23 tasslehoff: I don't think so, but you can set SDK_MACHINE from outside (bash env), I was using for cycle to generate both Mar 18 08:02:25 JaMa: hm. unfortunately not. I installed 64-bit last friday, and have started recompiling Mar 18 08:03:21 but, on master I believe the problem was "cc1plus: out of memory" when compiling qtbase, even though I had plenty of memory left. Mar 18 08:17:39 Hi Mar 18 08:17:56 ERROR: gstreamer: Recipe file does not have license file information (LIC_FILES_CHKSUM) Mar 18 08:20:37 bhaskar than add a licesens file checksum Mar 18 08:21:24 ya that i did it s worked fine Mar 18 08:21:38 but its failed at packaging Mar 18 08:21:54 do_qa_configure error came Mar 18 08:24:18 ERROR: QA Issue: pkgconfig rdepends on external-gf-toolchain-dev Mar 18 08:24:28 ERROR: QA run found fatal errors. Please consider fixing them. Mar 18 08:24:35 ERROR: Function failed: do_package_qa Mar 18 08:24:51 i am building gstreamer with my externel tool chain Mar 18 08:25:00 but at the end i got this error Mar 18 08:25:15 Please can any one help me to fix Mar 18 08:27:59 please pastebin more from the log Mar 18 08:28:42 ERROR: Logfile of failure stored in: /home/kotha/REDROSE/build-webos/BUILD-redrose/work/armv7a-vfp-neon-gf115x-linux-gnueabi/pkgconfig-0.25-r5/temp/log.do_package.19422 Mar 18 08:28:53 bhaskar: hi :) Mar 18 08:29:07 bhaskar that is not pastebin Mar 18 08:29:16 moin Mar 18 08:29:22 hi florian Mar 18 08:29:28 florian: hi Mar 18 08:29:40 pastebin means? Mar 18 08:29:52 Hi JaMa Mar 18 08:30:11 bhaskar and why do you need an external toolchain for webos? Mar 18 08:30:51 this is needed for my own architecture Mar 18 08:30:57 bhaskar: services like http://paste.debian.net/ Mar 18 08:31:04 bhaskar ? Mar 18 08:31:10 webos is just i used reference Mar 18 08:31:29 you bought an armsoc design from arm? Mar 18 08:31:59 which is not covered yet by gcc and binutils? Mar 18 08:32:02 nice Mar 18 08:32:27 woglinde: :) Mar 18 08:32:34 we hv added externel arm tool chain Mar 18 08:32:50 able to build some hello worl, glibc2 Mar 18 08:33:03 but gstreamer its giving packaging problem Mar 18 08:33:56 bhaskar: it probably links to something provided by external-gf-toolchain-dev Mar 18 08:34:15 ok Mar 18 08:34:25 bhaskar: and here it builds correctly with the same toolchain you're using :) Mar 18 08:34:28 where to check that? Mar 18 08:34:38 log.do_package.19422 Mar 18 08:35:31 and you're mixing 2 issues, one is missing LIC_FILES_CHKSUM in gstreamer recipe and 2nd is pkgconfig linking to toolchain-dev Mar 18 08:36:21 this LIC_FILES_CHKSUM was fixed by adding empty do_qa_configure() function Mar 18 08:36:34 only pkgconfig Mar 18 08:36:41 is the problem Mar 18 08:37:24 NOTE: DO PACKAGE QA Mar 18 08:37:37 ERROR: QA Issue: pkgconfig rdepends on external-gf-toolchain-dev Mar 18 08:37:45 ERROR: QA run found fatal errors. Please consider fixing them. Mar 18 08:37:57 ERROR: Function failed: do_package_qa Mar 18 08:38:25 in log also i am able to see this error Mar 18 08:38:36 nothing new in log file Mar 18 08:43:34 bhaskar: that's not fix! 09:36:23 < bhaskar> this LIC_FILES_CHKSUM was fixed by adding empty do_qa_configure() function Mar 18 08:44:05 ya its fixed Mar 18 08:44:16 its not giving any error Mar 18 08:44:27 do_qa_configure() { Mar 18 08:44:38 all my modules which are building i did like that Mar 18 08:44:44 so its working fine Mar 18 08:44:55 do i need to have md5check sum?? Mar 18 08:45:46 removing check is not fixing the problem Mar 18 08:46:26 but its not giving error Mar 18 08:46:34 its creating images Mar 18 09:05:07 good morning Mar 18 09:12:43 hi mckoan Mar 18 10:31:51 What is bootloader? Mar 18 10:50:23 vivekm: this is not right chanell for such questions Mar 18 11:07:20 almost a year since last time I tried 64-bit, but I ran into the same compile error now http://lists.linuxtogo.org/pipermail/openembedded-core/2012-April/021438.html Mar 18 11:27:22 tasslehoff: I'm currently (and always) running on 64-bit host (ubuntu) without problems Mar 18 11:36:10 mckoan: yeah. it's our own hostbuilds that has been holding us back, but I will fix that now Mar 18 11:36:52 anyone besides me compiling boost with python support? not sure how to get around that compile error Mar 18 11:37:30 trying to add -m32 to CFLAGS/CXXFLAGS for the boost recipe, but I don't know how this bjam-stuff works Mar 18 12:21:29 tasslehoff bjam suckz Mar 18 12:26:09 woglinde: YES! I'm getting angrier by the minute, trying to figure out how to get my flag into the build :| Mar 18 12:28:11 tasslehoff I think it was really strange Mar 18 13:52:27 heh. now I found a patch in master fixing it. done by tasslehoff a year ago... Mar 18 14:56:11 1;) Mar 18 15:38:41 ah someone is struggling to cross compile python-modules, I have fixed distutils locally to that effect Mar 18 15:39:04 problem is on OE we use python setup.py .... in do_compile for modules Mar 18 15:39:38 which setup.py lameness groks for header search and lib search Mar 18 15:40:10 so basically you end up with compiling a 32bit module against 64bit host headers, that module will never function correctly even if it compiled fine Mar 18 15:44:40 khem: hope oe can have full blown python support one day Mar 18 15:44:58 pip install django Mar 18 15:47:35 khem: https://fedorahosted.org/releases/c/r/cronie/cronie-1.4.9.tar.gz'. Unable to fetch URL from any source. Mar 18 15:47:56 khem: fedora timeouts today, but still applied (timeout is better then failing parse) Mar 18 16:01:40 JaMa: hmmm I did not run into it Mar 18 16:01:51 JaMa: probably, I fetched it sometime last week Mar 18 16:02:16 ausxxh_: yes OE is quite far in cross compiling python Mar 18 18:37:09 ah hi khem Mar 18 18:37:19 right your patches are still pending Mar 18 20:55:00 so someone broke autofs with systemd Mar 18 20:55:05 lets see Mar 18 20:55:53 $ git show 2d6c355a55ab92555128a3c3e876a7752c035329 Mar 18 20:55:53 commit 2d6c355a55ab92555128a3c3e876a7752c035329 Mar 18 20:55:53 Author: Joe MacDonald Mar 18 20:55:53 Date: Mon Mar 18 15:01:17 2013 -0400 Mar 18 20:55:53 autofs: fix QA error when building without systemd Mar 18 20:55:56 Mar 18 20:55:58 Building without systemd enabled results in: Mar 18 20:56:01 Mar 18 20:56:03 WARNING: QA Issue: autofs: Files/directories were installed but not shipped Mar 18 20:56:05 /lib Mar 18 20:56:08 /lib/systemd Mar 18 20:56:11 /lib/systemd/system Mar 18 20:56:13 /lib/systemd/system/autofs.service Mar 18 20:56:16 Mar 18 20:56:18 fix that in the PKGCONFIG way. Mar 18 20:56:21 Mar 18 20:56:23 Signed-off-by: Joe MacDonald Mar 18 20:56:26 systemd is a DISTRO_FEATURE why dont use that ? Mar 18 20:56:41 now one needs yet another knob Mar 18 20:56:52 doesn't pkgconfig inherit the features? Mar 18 20:57:24 and that patch was never posted to ml Mar 18 20:57:34 I cant find any reference to it in patchwork Mar 18 21:00:00 even if one has push access, didnt we decide to have reviews Mar 18 21:00:42 yes.. take it up with joe.. I have no idea why it didn't end up on the list Mar 18 21:04:09 and if the distro falgs don't get inherited into the PACKAGECONFIG settings, then that was probably my mistake telling him they did Mar 18 21:05:00 usually the reciep defines the default PACKAGECONFIG value using base_contains on DISTRO_FEATURES. it's not automatic, its up to the recipe defining PACKAGECONFIG to play nice Mar 18 21:05:04 heh Mar 18 21:05:19 yes Mar 18 21:05:21 then that bit is my fault for telling him the wrong info Mar 18 21:05:37 in this case simply defining it in terms of DISTRO_FEATURE would have beent he right thing Mar 18 21:14:36 do I understand the function of PACKAGES_DYNAMIC correctly? typically, OE "guesses" the group of files that will result (shared objects, documentation, binaries etc.), prepares packages for these groups. if a recipe's do_install result does not fit into this particular scheme (for example, because it is binary-only, and has .so's that are stripped already), one should use PACKAGES_DYNAMIC, to bypass this automatic "guessing" and specify Mar 18 21:14:36 the packages + contents at runtime? Mar 18 21:14:54 it doesn't guess Mar 18 21:15:12 there are explicit lists of what packages will be emitted (PACKAGES) and what files will be included (FILES_*) Mar 18 21:15:18 the defaults cover most cases, but recipes sometimes override this Mar 18 21:15:37 yes, but there are expectations. for example, a non-dev package cannot have .so files Mar 18 21:15:40 PACKAGES_DYNAMIC is for emission of packages whose existence may vary, based on what actually came out of the build Mar 18 21:15:57 in those cases, it can't know at runqueue generation time what packages will be emitted Mar 18 21:16:14 hence the pattern it can match against to find recipes which may emit packages matching that pattern (PCACKAGES_DYNAMIC) Mar 18 21:16:27 okay Mar 18 21:16:34 most often used for locale generation, or recipes which emit a variety of different slightly different shared libraries based on what configure options were enabled Mar 18 21:16:45 and for binary-only packages? Mar 18 21:17:02 those are packaged like any other recipe, and dont' need PACKAGES_DYNAMIC at all Mar 18 21:17:08 just override the appropriate FILES ariables Mar 18 21:17:14 see bitbake.conf for th edefault values Mar 18 21:17:16 I do have stuff here that comes as .so files (not .so.X.Y, just .so) , and without PACKAGES_DYNAMIC, it wont work Mar 18 21:17:20 hmm. Mar 18 21:17:24 no, packages_dyanmic is irreleevent Mar 18 21:17:24 I did that. Mar 18 21:17:28 and it didnt work. Mar 18 21:17:31 define FILES_${PN} and FILES_${PN}-dev correctly Mar 18 21:17:50 bitbake complained about putting .so's in a non-dev package Mar 18 21:17:54 no matter what I put in FILES Mar 18 21:18:01 then you're doing something wrong, or something else is going on. packages are built in PACKAGES order. the first recipe in that list to grab a file gets it, and the others will not Mar 18 21:18:12 so if a package is ahead of the one you're exerting control over, it'll get it instead of you Mar 18 21:18:24 use bitbake -e to examine PACKAGES and the FILES variables Mar 18 21:18:28 hmm perhaps something else was grabbing them, true. Mar 18 21:18:41 bitbake -e is an invaluable tool for checking our assumptions against reality, sometimes vars aren't set the way we think they are, too Mar 18 21:18:43 and by adding PACKAGES_DYNAMIC, can it somehow influence this order? Mar 18 21:18:46 for exmaple, due to a typo, or an override Mar 18 21:18:51 no, do not touch packages_dynamic Mar 18 21:18:54 again, it has nothing to do with this case Mar 18 21:18:54 because that would explain a few things I've seen Mar 18 21:19:02 no I mean I have used it in the past to circumvent this Mar 18 21:19:11 with it, it worked Mar 18 21:19:14 then you're doing it wrong Mar 18 21:19:19 that's not what i'ts used for Mar 18 21:19:29 yeah, I suspected that. its just odd that it worked Mar 18 21:19:35 I guess it was a coincidence Mar 18 21:19:51 fray: is Joe on IRC > Mar 18 21:19:57 I sent him a mail too Mar 18 21:20:32 dv_: could be, it's tough to say without looking at the exact recipe exhibiting the behavior :) Mar 18 21:20:53 I'll try to reproduce. the recipe had many more problems, it was hacked together for quick results. Mar 18 21:20:56 but first make sure your FILES vars are set the way you think they are via bitbake -e, then make sure no earlier packages are stealing the files before your package can dos o Mar 18 21:20:57 he's not right now Mar 18 21:21:08 and go from there Mar 18 21:30:01 sorry, what was my last message? Mar 18 21:35:46 16:20 < dv_> I'll try to reproduce. the recipe had many more problems, it was hacked together for quick results. Mar 18 21:35:55 alright, thanks Mar 18 21:36:06 okay, one more question: for a recipe, the source contents are in one big unified tarball. a tarball containing tarballs (not my choice). Mar 18 21:36:06 how can I specify that in the SRC_URI ? Mar 18 21:36:06 I thought of prepending something to the unpack stage, but the best thing would be to do this only once for several recipes Mar 18 21:39:21 i'd say create a .inc or bbclass which adds a function to run after do_unpack that extracts any files which were unpacked into ${WORKDIR} Mar 18 21:39:27 do_unpack[postfuncs] += "unpack_more" Mar 18 21:39:40 do_unpack[vardeps] += "unacpk_more" Mar 18 21:47:16 so, unpack the big tarball, and in the postfunc, unpack the little ones? Mar 18 21:49:43 well, alright.. I am just worried that the big tarball will then be unpacked once for each recipe. **** ENDING LOGGING AT Tue Mar 19 02:59:58 2013