**** BEGIN LOGGING AT Fri Dec 02 02:59:57 2011 Dec 02 07:31:42 If i bypass task-core-tools and add rsync directly to IMAGE_INSTALL, I get an error when building rootfs: Collected errors: Dec 02 07:31:42 | * satisfy_dependencies_for: Cannot satisfy the following dependencies for rsync: Dec 02 07:31:43 | * eglibc (>= 2.13) * Dec 02 07:32:13 Should this be considered a poky bug, or am I doing something wrong here ? Dec 02 07:34:09 I have verified that eglibc 2.13 IS installed. Dec 02 08:31:44 dany: I think you changed eglibc versions between building rsync and rest of root file system Dec 02 08:32:34 Did not do that. If I set rsync to be built under a task-* it works fine. Dec 02 08:33:07 i.e. IMAGE_FEATURES +=, not IMAGE_INSTALL Dec 02 08:35:55 Using poky-edison, I should probably state. Dec 02 08:44:44 good morning Dec 02 16:50:37 RP__: ping Dec 02 16:51:05 JaMa: pong Dec 02 16:52:13 RP__: the problem with PRINC is not in base.bbclass but to evaluate PRINC := "${@int(PRINC) + 1}" without PRINC Dec 02 16:52:54 you're right that with this it's applied for every recipe, but at least here I haven't seen any impact on parsing speed Dec 02 16:53:00 JaMa: I realise that but you don't need := Dec 02 16:53:11 just a = or even a ?= would do Dec 02 16:53:40 in bitbake.conf for default value or in every recipe using it? Dec 02 16:54:52 JaMa: bitbake.conf Dec 02 16:55:01 ah seems to work Dec 02 16:55:11 with ?= Dec 02 16:57:22 ok, will send updated patch when image build is finished Dec 02 16:58:08 next issue I have now is with meta-oe depending on FEED_ARCH (alias TUNE_PKGARCH) OVERRIDE, I guess koen talked with you about it already Dec 02 16:58:53 can we keep unmodified (by PKGARCHCOMPAT_ARMV7A) value of Dec 02 16:59:03 TUNE_PKGARCH and use it as OVERRIDE? Dec 02 17:00:00 so in meta-oe we would replace armv7a overrides with armv7a-vfp-neon and it would work for me (without PKGARCHCOMPAT_ARMV7A as well as koen with PKGARCHCOMPAT_ARMV7A enabled) Dec 02 19:38:02 Hrm, I'm having an issue with the linux-firmware package (with a bbappend). While investigating, I found I have a run.do_install but no log.do_install in the temp directory. Does anyone know why that might be? Dec 02 19:48:45 dvhart: Did it die in do_install ? Dec 02 19:49:08 khem, no, actually it doesn't die at all. It just doesn't create the package I expect Dec 02 19:49:33 ie, I add the following in a bbappend: Dec 02 19:49:35 PACKAGES += "${PN}-iwlwifi-6000g2a-5" Dec 02 19:49:35 FILES_${PN}-iwlwifi-6000g2a-5 = " \ Dec 02 19:49:35 ${FWPATH}/iwlwifi-6000g2a-5.ucode \ Dec 02 19:49:35 ${FWPATH}/LICENCE.iwlwifi_firmware \ Dec 02 19:49:35 " Dec 02 19:50:01 and when it completes, there is no linux-firmware-iwlwifi-6000g2a-5 package Dec 02 19:50:38 (and the name does appear in the PACKAGES variable with bitbake -e) Dec 02 19:54:30 what have you set FWPATH to, is it set correctly? Is the file in the image/ subdirectory of WORKDIR? Dec 02 19:55:02 the FWPATH thing appears new, I assume you've confirmed other firmwares being correctly generated? Dec 02 19:55:42 is your FILES_${PN}-iwlwifi-6000g2a-5 before the FILES_${PN} += entry? Dec 02 19:56:04 /lib/firmware, yes, yes Dec 02 19:56:16 yes Dec 02 19:56:19 no Dec 02 19:56:28 fix that Dec 02 19:56:29 no on the last because this is a bbappend Dec 02 19:56:40 hrmmm Dec 02 19:57:01 I'm not sure we should be packaging everything else in a big package anyways, but expect that's the issue Dec 02 19:57:03 the linux-firmware recipe sets: Dec 02 19:57:06 FILES_${PN} += "/lib/firmware/*" Dec 02 19:57:08 right Dec 02 19:57:10 right Dec 02 19:57:18 but I don't care about that package Dec 02 19:57:19 try commenting that line out and seeing if it works Dec 02 19:57:28 ok... Dec 02 19:57:41 you can probably shadow FILES_${PN} in your bbappend Dec 02 19:57:51 but clearly there must be a *better* way Dec 02 19:58:44 ooh, OMAP4 devices have hardware face-detection! Dec 02 19:58:51 I don't see how it would affect this though honestly Dec 02 19:59:24 but it did Dec 02 19:59:25 huh Dec 02 19:59:31 the file was generated Dec 02 19:59:34 s/file/package/ Dec 02 19:59:38 * dvhart scratches head Dec 02 19:59:45 ok, handling SIGFOOD - thanks incandescant Dec 02 19:59:45 the FILES_PN is greedy, it's claiming anything that hasn't already been claimed - the bbappend appends so is trying to claim a file that's already been gobbled up Dec 02 20:00:37 ah... and it does that because we oddly copy everything to the image dir first, and then install the package specific files *again* in the install bits... Dec 02 20:00:47 biab Dec 02 20:01:24 dvhart: do PACKAGES =+ instead of PACKAGES += Dec 02 20:01:33 and see if that helps Dec 02 20:01:46 I am guessing there is some big fat regexp that consumes all Dec 02 20:02:32 FILES_${PN} += "/lib/firmware/*" there you go Dec 02 20:02:44 so PACKAGES =+ might help you here Dec 02 20:18:33 khem, right, I realized that whilst eating lunch :-) Dec 02 20:18:41 was just about to put it to the test Dec 02 20:23:39 looks good - thanks khem & incandescant Dec 02 20:30:16 that reminds me that I got a SIGFOOD too **** ENDING LOGGING AT Sat Dec 03 02:59:57 2011