**** BEGIN LOGGING AT Tue Jun 30 02:59:58 2015 Jun 30 05:24:34 how to check which package provides a header file in sysroot directory? Jun 30 06:27:16 Hello everyone, I'm facing some difficulties adding a driver to the kernel in the yocto dizzy project. Can anyone help me please Jun 30 06:28:50 mimetonbo: what kind of difficulties are you facing? Jun 30 06:29:46 So I have found an off the shelf driver for a digipot over i2c and am unsure how to proceed to add it to my kernel Jun 30 06:30:22 I have read online I need to add it as a module however I can even add it directly to the kernel. Jun 30 06:30:46 https://www.yoctoproject.org/sites/default/files/kernel-lab-1.6.pdf might be able to help you Jun 30 06:31:07 it's a bit long but kernel job is never easy to begin with Jun 30 06:32:01 yes I read that. Thing is it explains how to add a layer to yocto and the required bb files etc are already part of the git project. However All I have is the .c file of the driver Jun 30 06:33:29 so it looks like you will need to write a recipe to compile the codes, then find a way to install the resulting module to kernel modules directory...I'm not entirely sure of the mechanics of it though Jun 30 06:33:52 I'm afraid I cannot be of assistance any further :-( Jun 30 06:35:17 Thank You for trying :)! Jun 30 06:38:14 the good news is there are better ones out here who can probably do better. You just need to bide your time Jun 30 11:34:12 is this now th right channel? Jun 30 11:34:16 hups sorry Jun 30 11:34:21 wrong channel :-) Jun 30 11:39:47 guys Jun 30 11:39:50 http://dpaste.com/1EBDYTE.txt Jun 30 11:39:57 what does it mean? Jun 30 11:40:10 why I don't have such recipes? Jun 30 11:40:36 I've just cloned yocto and meta-sourcery Jun 30 12:14:48 <_4urele_> Ox4, maybe you should check your bblayers.conf (maybe you already did it...) Jun 30 12:14:55 Ox4: the version of the recipe has probably been updated Jun 30 12:15:57 Ox4: e.g. lttng-ust is 2.6.1 in master, not 2.6.0 Jun 30 12:25:43 yes, you're right Jun 30 12:25:44 thanks Jun 30 12:25:52 what about qt5? Jun 30 12:26:08 qtbase_5.4.2.bbappend is not correct Jun 30 12:26:38 I've done checkout to 82b211aa423cd9ae46422823139b24a07e8b0fa9 commit Jun 30 12:27:35 and I see in the diff the following: Jun 30 12:27:38 -PV = "5.4.1+git${SRCPV}" Jun 30 12:27:38 +PV = "5.4.2+git${SRCPV}" Jun 30 12:27:52 but Jun 30 12:28:19 ERROR: No recipes available for: ...../qtbase/qtbase_5.4.2.bbappend Jun 30 12:43:12 Ox4: qtbase is not oe-core. When you add a distro layer, you should add all the layers it depends on. http://layers.openembedded.org/ should help Jun 30 12:43:27 qtbase is not _in_ oe-core Jun 30 12:44:50 jku: I see Jun 30 12:44:52 thanks Jun 30 12:50:22 one more question Jun 30 12:51:45 according to this document http://processors.wiki.ti.com/index.php/Creating_a_Root_File_System_for_Linux_on_OMAP35x#Add_the_Shared_Libraries_Applications_will_Require I have to copy target toolchain libs to rootfs lib/ directory. How can I accomplish this by yocto? Jun 30 12:52:02 just add bbappend file? Jun 30 14:09:06 well, I've appended meta-qt5 meta-oe and append the info to bblayers.conf file ( http://paste.pound-python.org/show/CS57unr8ws31PRgo0Oxv/ ), but still have a problem like: ERROR: No recipes available for: /home/int/dev/leantegra/sandbox/yocto/poky/meta-powerbeacon/recipes-bbappend/qtbase/qtbase_5.4.2.bbappend Jun 30 14:26:48 is there a way to make bitbake update layers before cooking? Jun 30 14:30:52 Ox4: same thing as before: there is no qtbase_5.4.2.bb in any of your layers (although meta-qt5 has qtbase_git.bb). Either meta-powerbeacon actually depends on some other layer for qtbase, or it isn't compatible with current meta-qt5 Jun 30 14:33:14 jku: but I cloned meta-qt5 from the github Jun 30 14:34:42 ah Jun 30 14:34:44 oe-core Jun 30 14:34:45 sorry Jun 30 14:40:37 hm, but I enumerated all layers from which my bsp layer depends on :-( Jun 30 14:45:16 rburton: RP: autobuilder appears idle, may I queue a build? Jun 30 14:48:03 fine by me Jun 30 14:55:10 * joshuagl presses go Jun 30 15:11:34 hello !, I'd like to understand how can I remove the "debug-tweaks" option, my image inherit from core-image which inherit from image which set debug-tweaks Jun 30 15:11:53 meta/classes/image.bbclass: IMAGE_FEATURES[validitems] += "debug-tweaks read-only-rootfs" Jun 30 15:24:54 It looks like the recent update to cmake-native in poky has broken any -native packages that build using cmake as the new cmake enforces path restrictions for finding gcc based on CMAKE_FIND_ROOT_PATH_MODE_PROGRAM Jun 30 15:28:41 is there any way to make bitbake update layers? Jun 30 15:28:52 before builds Jun 30 15:29:04 what do you mean by update layers? Jun 30 15:29:26 bitbake isn't what's responsible for cloning, updating, or configuring your layers Jun 30 15:33:19 kergoth, so whats responsible for that? Jun 30 15:33:31 you are Jun 30 15:33:37 what you use to do so entirely depends Jun 30 15:33:52 some folks do it manually, some use submodules, some use repo, others use different tools, makefiles, etc Jun 30 15:33:55 so, got to do some scripts to do that i see Jun 30 15:33:56 angstrom has theri own scripts for it Jun 30 15:34:14 ok, tnks Jun 30 15:34:47 not ideal, but it's difficult to cover every use case with tools for managing such things, differnet people prefer different tools or methods for their use cases Jun 30 15:38:41 kergoth i see that toaster does just that Jun 30 15:38:59 not sure what you mean by that Jun 30 15:39:12 toaster is a bitbake frontend, handles configuration and build monitoring Jun 30 15:39:13 updating repos just before build Jun 30 15:39:21 it's not going to replace a higher level tool for managing your layers, as far as i'm aware Jun 30 15:40:37 god i'd hate bitbake to update layers when i did a build. Jun 30 15:40:55 introducing something else changing whilst i'm trying to work would be a bad idea Jun 30 15:40:57 agreed. stuff would just break on you Jun 30 15:41:13 multiple variables (excuse the term) changing at once is bad for diagnosis Jun 30 15:42:02 in a production environment it should be someones job to update layers locally, run regressions tests, and then commit the updated layers somewhere. repo, submodules, whatever. Jun 30 15:42:43 yep. that's my job here, i update the upstream layers in our repo manifest on a weekly basis after doing sanity test builds across all supported bsps Jun 30 15:42:54 Here's a SO question on the topic: http://stackoverflow.com/questions/6500524/git-subtree-or-gitslave-if-switch-away-from-git-submodules Jun 30 15:42:57 sometimes it gets postponed until something unrelated is fixed upstream Jun 30 15:43:14 Has anyone used git slave, I've only just heard of it. Jun 30 16:38:24 Hello - I'm getting a strange error from multiple yocto commands, regarding a directory not existing. It seems like some bad string concatenation is happening somewhere. Jun 30 16:38:30 OSError: [Errno 2] No such file or directory: '/home/alex/Client/project_yocto/build/../poky/meta-yocto:/home/alex/Client/project_yocto/build:/home/alex/Client/project_yocto/build/../poky/meta:/home/alex/Client/project_yocto/build/../poky/meta-yocto-bsp:/home/alex/Client/project_yocto/build/../directv/meta-hg1x/../directv/meta-hg1x/recipes-kernel/linux' Jun 30 16:40:02 Okay, I guess I didn't sufficiently anonymize that, but I don't think there's any damaging info there. Jun 30 16:40:18 Anyway, what is putting all those colons together, and why is it trying to CD to the whole string? Jun 30 18:55:30 damnit bitbake. once again it's doing that hting where it says i need to define a preferred provider that's already defined Jun 30 18:55:41 one that multilib_global defined, actually Jun 30 18:55:55 kergoth: master? Jun 30 18:55:59 yeah Jun 30 18:56:04 * kergoth digs Jun 30 19:15:11 RP: got it, it's the case where a preferred provider is set to a recipe which doesn't exist / a provider that isn't valid. we should catch that and warn the user that their preference is on something that doesnt' exist. would catch typos and other misconfigurations and be less misleading than the message saying it needs to be defined Jun 30 19:15:23 * kergoth adds a note to open an enhancement request Jun 30 20:59:20 ah, right, that's my problem Jun 30 20:59:59 multilib_global sets preferred_providers for the multlilibs, but it doesn't force expansion of the value with the multilib override applied.. i can see why, but it means use of variables affected by that override will be expanded in the wrong context Jun 30 21:00:21 e.g. multilib-prefix + gcc-cross-${TARGET_ARCH} is expanded iwthout the multilib applied, so ends up pointing at a non-existent recipe Jun 30 21:00:34 s/multilib applied/multilib override applied/ Jun 30 21:00:55 Hi - so my BBPATH seems to be corrupted with a colon-separated list of all my BBLAYERS. Jun 30 21:00:58 have a related issue with pnblacklist, it handles multilibs, but tehre's the same issue, the PN value is conditional Jun 30 21:01:02 How would I debug what is causing that? Jun 30 21:01:04 Circuitsoft: what makes you think that's bad? Jun 30 21:01:08 its exactly what it's supposed to be doing Jun 30 21:01:25 each layer adds itself to BBPATH in layer.conf so config files and classes in the layer can be found Jun 30 21:01:31 if the layer doesn't have any, it doesn't have to add itself to BBPATH Jun 30 21:01:33 but most do Jun 30 21:01:34 I figured it was what was set in bblayers.conf and didn't change. Jun 30 21:01:38 nope Jun 30 21:02:34 Ah. So my BBLAYERS should be pointing to ${TOPDIR}/.../etc, not ${BBPATH}/.../etc Jun 30 21:13:54 bbpath is a colon separated list, i don't see how you could refernece it to refer to anything Jun 30 21:13:59 but yes Jun 30 21:15:23 kergoth: good point, a variable set to something invalid is something we should warn about Jun 30 21:16:17 bah, configparsed event handlers can't be prepended/appended, since it doesn't get the handler value from the finalized data Jun 30 21:17:02 kergoth: I could just merge the datastore changes which will fix that Jun 30 21:17:30 kergoth: Its sitting on the branch ready, just haven't summoned up the courage yet! :) Jun 30 21:17:32 that's true. sorry i still haven't had time to review the patch series, it sounds like you've been vetting it pretty thoroughly though Jun 30 21:17:34 * kergoth nods Jun 30 21:18:34 Its been through the autobuilder and through several regression tests. Have I caught everything?, unlikely. Its as good as I can reasonably get it though... Jun 30 21:52:45 ahh Jun 30 21:54:46 aha, the bits in multilib_global use the expanded-with-the-multilib-override value when handling the case where the provide name might change due to the multilib override, but the bits which handle the multilib name don't use that expanded value, so e.g. PREFERRED_PROVIDER_virtual/lib32-${TARGET_PREFIX}gcc = "lib32-gcc-external-cross-${TARGET_ARCH}" ends up using the non-multilib TARGET_ARCH Jun 30 21:54:49 * kergoth preps patch Jul 01 01:32:27 HI team Jul 01 01:32:45 I am having this issue with a package ( mpich ): http://pastebin.com/K13gSArj Jul 01 01:33:06 apparently QA Issue: package mpich contains bad RPATH Jul 01 01:33:12 any clue how to fix it ? Jul 01 01:33:16 is more than welcome Jul 01 01:45:57 fixed : https://lists.yoctoproject.org/pipermail/yocto/2015-February/023765.html **** ENDING LOGGING AT Wed Jul 01 02:59:58 2015