**** BEGIN LOGGING AT Thu May 07 02:59:58 2015 May 07 07:23:39 good morning May 07 08:03:23 morning all May 07 08:09:08 bluelightning: gm May 07 08:09:17 morning ant_work May 07 08:09:25 I've noticed we miss LAYERVERSION and LAYERDEPENDS in the couple of layers May 07 08:10:21 I'm parsing old threads and it seems there are discording opinions about the syntax to use May 07 08:11:24 hi bluelightning, ant_work May 07 08:11:34 hello mckoan May 07 08:11:43 bluelightning: this http://lists.openembedded.org/pipermail/openembedded-devel/2014-November/099003.html May 07 08:12:11 ant_work: I introduced a new syntax for LAYERVERSION recently - before that it wasn't much use because it only supported =, not >= May 07 08:12:28 well, for LAYERDEPENDS, that is May 07 08:13:01 ok, I can flush that old msg from my mail queue then :) May 07 08:15:05 ant_work: all I changed was how versions are evaluated in LAYERDEPENDS, it doesn't auto-set everyone's values ;) May 07 08:15:18 so work still needs to be done in almost every layer.conf May 07 08:15:35 (if we want sensible errors when people mismatch branches) May 07 08:15:47 * ant_work is marking the msg again... May 07 11:14:20 bluelightning: i've built a custom kernel based on the linux-yocto-custom.bb template in oe-core. it works and builds fine, but i'm seeing all these warnings about multiple providers. Even though I have set a PREFERRED_PROVIDER of virtual/kernel in my machine config. Does linux-yocto.inc bring any quirks to the kernel preferrence? May 07 11:21:40 mago_: no, but there must be something depending upon something your new kernel recipe doesn't provide May 07 11:25:05 bluelightning: okay, for virtual/kernel bitbake has these providers: linux-yocto, linux-xlnx, linux-my-custom-kernel, linux-dummy. i've set PREFERRED_PROVIDER_virtual/kernel to linux-my-custom-kernel. Are you saying something in my image depends on linux-xlnx, linux-ycot and linux-dummy? May 07 11:30:17 mago_: possibly yes May 07 11:30:35 the output of bitbake -g your-image may help track that down May 07 11:57:01 bluelightning: found it. seems like there was a space inserted in the recipe name on my PREFFERED line. E.g PREFERRED_PROVIDER_virtual/kernel = " my-kernel" silently failed (was suppose to be "my-kernel"). And then bitbake just picked one of the available providers, which ended up being my-kernel (luck?) May 07 15:09:07 otavio: hi, any thoughts about http://patches.openembedded.org/patch/93091/ ? May 07 15:21:11 Hi, I'm trying to produce the meta-qt5 toolchain for Beaglebone Black but I'm getting this error : http://pastebin.com/HVfX8hnn Is somebody can help me ? May 07 15:52:43 I updated the wiki Current Members list to reflect e.V. meeting in Dusseldorf May 07 17:20:09 jbrianceau_away: I am fine with ths May 07 17:20:21 JaMa: any issue? May 07 17:49:58 Anyone using the recipe for chromium-40.0.2214.91? It seems to build fine but it can't find /usr/bin/chrome/icudtl.dat when I run it. May 07 20:55:21 Where did genext2fs disappear to after dora ? May 07 20:56:52 nvm, found. May 07 21:06:44 heh, python-thrift exists in meta-clous-services and meta-openstack May 07 21:06:54 and soon meta-python May 07 21:10:37 Does anyone know what "QA Issue: ELF binary 'path' has relocations in .text [textrel]" mean? May 08 01:05:14 realBigFoot: that means when you run your binary dynamic linker will patch relocaitons into it May 08 01:08:23 and it can be slow depending upon number of such relocations May 08 01:10:09 usually if a shared object is compild with -fPIC this issue should go away May 08 01:15:37 usually code pages of shared objects when loaded into memory are marked r/o if there is no textrel patching needed May 08 01:15:47 1. Its secure May 08 01:16:21 2. when another process needs to use this library these pages will be shared and not copied May 08 01:16:29 textrel will cause COW **** ENDING LOGGING AT Fri May 08 02:59:59 2015