**** BEGIN LOGGING AT Wed Dec 17 02:59:59 2014 Dec 17 03:16:11 Hi, everyone. I'm about as new as it gets, and I've run into an error right off the bat. Dec 17 03:16:32 /media/psf/Tosh/proj$ git clone http://git.yoctoproject.org/poky Dec 17 03:16:32 Cloning into 'poky'... Dec 17 03:16:32 fatal: http://git.yoctoproject.org/poky/info/refs not found: did you run git update-server-info on the server? Dec 17 03:18:43 I'm working off of the quick start. Dec 17 03:20:28 Well, I'll so some more reading and maybe check on the mailing list. Dec 17 03:21:22 murgaan: You should stick around here and wait for answers. Dec 17 03:21:25 (as well) Dec 17 03:21:50 It could be that nobody who knows the answer is around, but if you stick around they can see your question and respond. Dec 17 03:50:05 okie dokie Dec 17 08:31:14 If I want to build qt5 only with linuxfb (no gl or gles2) can I just override PACKAGECONFIG_pn-qtbase = "release dbus udev evdev widgets tools libs openssl jpeg libpng zlib linuxfb"? Dec 17 08:33:07 In the configure I still see OpenGL .. Desktop and EGLFS .. yes Dec 17 08:35:26 morning all Dec 17 09:09:33 good morning Dec 17 12:38:46 hi Dec 17 12:40:09 I have to change the window properties in enligtenment can anyone please help me out Dec 17 12:40:18 i am using meta-efl layer Dec 17 16:59:45 need help with virtuals - they don't seem to propagate to packages, but rather real pkg names are recorded as dependencies, right? Dec 17 17:02:05 denix: those are separate namespaces; the runtime dependencies are established separately e.g. through shared library dependencies Dec 17 17:04:41 bluelightning_: indeed. so what is the benefit of making package virtual? Dec 17 17:05:18 denix: you can't with a *package*, you can with a recipe Dec 17 17:05:43 in which case it's about selection between multiple alternative recipes that provide the same functionality Dec 17 17:07:18 bluelightning_: that's good and all, but what's special about virtual/* since the same can be done with PROVIDES and PREFERRED_PROVIDER Dec 17 17:08:47 denix: by and large virtual/* is just a naming convention - supported by PROVIDES and PREFERRED_PROVIDER Dec 17 17:10:13 bluelightning_: ok, there's nothing special about virtual/* then? just the naming convention? Dec 17 17:11:15 denix: IIRC there is some special handling for it in some places, but nothing particularly significant Dec 17 17:11:28 denix: git grep virtual/ should find those Dec 17 17:12:34 bluelightning_: yeah, already did that - few places in base.bbclass when handling dependencies... Dec 17 17:13:01 bluelightning_: so, that's build time. is there any way to emulate the same at runtime? in other words, is there something similar as virtual or providers for packages, not recipes? Dec 17 17:14:16 denix: my understanding is no, there are problems at the package manager level supporting that Dec 17 17:15:01 bluelightning_: I see Dec 17 17:19:04 I'm new to how yocto's bitbake system works. I've been reading over the online manuals and I'm still not sure how to go about adding my own kernel patch files to an existing "machine" layer provided by a third party. I've tried using yocto-kernel tool, but it keeps dying with a python stack trace when doing: patch add myPatchFile Dec 17 17:20:04 bluelightning_: so, let's take an example of multiple providers of virtual/libgles2 - mesa vs. e.g. SGX. let's say then I build Qt5 which links to SGX for one platform, but qt packages aren't platform-specific. I can't then build another platform in the same work dir that needs mesa, right? Dec 17 17:22:32 denix: that might be a problem yes Dec 17 17:23:08 TypoNAM: it sounds like you have hit some kind of bug unfortunately Dec 17 17:24:15 perhaps the parameter is wrong, I'm finding it difficult to figure out what exactly that parameter should be considering I didn't create the BSP layer in the first place. Again it's from a third party. Dec 17 17:24:50 bluelightning_: resulting qt packages would embed dependencies to real SGX libs, not virtual/libgles2, so they can't be re-used for platforms that require different provider of that virtual/libgles2, like mesa... Dec 17 17:26:21 bluelightning_: so, basically, I'm back at where I started - I just thought I was missing something important in understanding how virtuals are working. looks like I'm not crazy after all :) Dec 17 17:27:17 bluelightning_: but, but, but... what's the solution? :) mark all qt packages as machine-specific? PACKAGE_ARCH=MACHINE_ARCH? it would kill the build time :( Dec 17 17:27:35 denix: right, there is nothing special about virtual/, there's no flexible runtime component to it Dec 17 17:28:30 denix: unfortunately due to dependencies & signatures they effectively are machine specific already if they depend upon a machine-specific GL* provider - have you noticed whether or not they rebuild when changing MACHINE? Dec 17 17:32:18 bluelightning_: they were probably rebuilding for different MACHINE, but I was getting other issues later reusing some of those packages for sdk side, so I already started on the path of marking them machine-specific, so correct packages would be preserved. but I started suspecting that's not the right thing to do... Dec 17 17:32:57 FWIW, multiple GL library handling isn't really my field of expertise - this is more something that rburton & otavio have dealt with IIRC Dec 17 17:33:19 (and possibly JaMa) Dec 17 17:34:57 bluelightning_: well, it's not limited to GL... it's one of the examples. I have other such machine-specific providers (e.g. gstreamer) that get embedded in other system libraries like Qt, making them machine-specific too Dec 17 17:35:38 bluelightning_: btw, does YP autobuilder build all platforms in one workdir, or separate ones? Dec 17 17:36:08 denix: right, but I think GL may be a special case; there might be some guaranteed ABI there, I just don't know Dec 17 17:36:12 denix: separate ones Dec 17 17:36:59 denix: VIRTUAL-RUNTIME variables are equivalent of virtual/* for runtime deps Dec 17 17:37:15 bluelightning_: ah, so much easier... I'm trying to reuse builds between platforms and that's where it breaks Dec 17 17:37:25 JaMa: denix: *except* those are still set at build time and fixed at runtime Dec 17 17:38:05 but that doesn't help with different "providers" Dec 17 17:38:13 JaMa: will that help with my example above? I don't see mesa using VIRTUAL-RUNTIME for GL providers Dec 17 17:38:53 no, it only helps making both build time and runtime dependencies more deterministic and consistent Dec 17 17:39:35 > mark all qt packages as machine-specific? PACKAGE_ARCH=MACHINE_ARCH? Dec 17 17:39:50 yes, there is even bbclass to do it a bit simpler Dec 17 17:40:31 the build time is already killed if you don't exclude your various GL providers from siggen Dec 17 17:40:53 JaMa: first question - what's the big difference between PREFERRED_PROVIDER and VIRTUAL-RUNTIME? Dec 17 17:41:08 first for build time, second for run-time Dec 17 17:41:52 again, VIRTUAL-RUNTIME is just a naming convention, in this case for variables that can substitute in runtime package names at build time Dec 17 17:41:54 JaMa: second question - if I exclude GL providers from siggen, will qt packages be shareable between platforms that use different GL providers? assuming ABI is stable Dec 17 17:43:18 bluelightning_: and how dependencies get handled with VIRTUAL-RUNTIME? I assume real libs and their pkg names will still be embedded Dec 17 17:43:48 denix: yes, again it's nothing special Dec 17 17:44:17 denix: yes, I'm sharing them between multiple MACHINEs with different GL* providers, but there are some exceptions Dec 17 17:45:04 like RGX/SGX should be ABI compatible, but because of bugs and work arounds we have to apply in qtbase they aren't and even qtbase has to be different Dec 17 17:47:23 JaMa: what's the trick to prevent qt packages from referencing actual GL packages? Dec 17 17:56:03 because of different package name from debian.bbclass or version? Dec 17 18:00:47 JaMa: even w/o debian renaming. say, one platform has GL1 provider, another has GL2 provider. those names will be used for Depends: field in the package, not the library name... Dec 17 19:08:44 JaMa: am I missing something in the config? I'd expect the dependency to be libgl*(library) instead of GL1(package). even if it gets debian-renamed to libgl*(package), in order to have both providers packaged, they need different names, like libgl-prov1 etc. Dec 17 19:11:53 in my case the libgl providers are MACHINE_ARCH, so they can have the same package name (from SONAME header) Dec 17 19:12:45 only the version is annoying, so that I have to set identical PKGV for all providers Dec 17 19:14:29 JaMa: ok, I see how you do it. the trick is to get the package name and version the same, but deploy into machine-specific locations... Dec 17 21:54:37 denix: this is why i proposed virtual providers for libgl etc some time ago but was argued against. you'd need some magic in the automatic dependency generation to turn the real dependency into a virtual one. (basically, do what debian does) Dec 17 21:55:09 denix: its generically useful functionality so you should implement it :) Dec 17 21:56:55 rburton: heh, I'm sure you'll get it done better... :) Dec 17 21:57:06 hah Dec 17 21:57:21 i'd ask paul to do it :) Dec 18 00:54:16 It could be that nobody who knows the answer is around, but if you stick around they can see your question and respond. **** ENDING LOGGING AT Thu Dec 18 02:59:58 2014