**** BEGIN LOGGING AT Fri Aug 30 02:59:58 2013 Aug 30 03:06:20 I keep waffling between ST and vim Aug 30 03:27:45 me too Aug 30 03:28:15 seen rsub/rmate? that's what made me really give ST another shot, since i work over ssh most of the time - https://github.com/henrikpersson/rsub Aug 30 03:28:20 * kergoth mutters Aug 30 05:55:24 * nerdboy tried sublime, waffled a bit, then went back to vim Aug 30 07:32:04 florian: ping Aug 30 07:34:46 JaMa: good guy :) Aug 30 07:41:29 .. gets cookie? Aug 30 08:05:23 Can I use wildcards with bitbake? I want to run cleansstate on all the qt-recipes Aug 30 08:05:41 tasslehoff: I'm afraid not, no Aug 30 08:05:41 JaMa: I'm trying out the webos-ports recipes to get gles2 working :) Aug 30 08:12:00 morning all btw Aug 30 08:35:58 morning all Aug 30 08:37:25 JaMa: the gles2 images you use, do they have libGL.so? for some reason my testapp wants that. Aug 30 09:02:12 tasslehoff: depends on MACHINE, e.g. maguro has only gles2 (from libhybris) qemu* have libGL from mesa Aug 30 09:08:04 JaMa: my bad. built my testapplication with libGL instead of libGLESv2... Aug 30 09:11:50 hi, where can i find a description of all variables 'operators' e.g. _prepend, _append, +=, ?=, ??=, .=, ... Aug 30 09:12:19 ndec: the bitbake manual Aug 30 09:12:47 last time i checked the bitbake manual was not quite integrated with the yocto manuals, any specific reason for that? Aug 30 09:13:14 it wasn't part of the Yocto Project manual set, no Aug 30 09:13:22 it's in the process of being updated though Aug 30 09:13:41 where is the most up to date (online) version, then/ Aug 30 09:13:43 then? Aug 30 09:13:59 I don't know that there is an up-to-date online version of it Aug 30 09:14:24 this version whilst old is still 95% valid: http://docs.openembedded.org/bitbake/html/ Aug 30 09:14:49 you can always build your own version from the source Aug 30 09:15:40 * JaMa is always reading source files for that in bitbake repository Aug 30 09:15:52 just because git grep works so good :) Aug 30 09:16:43 repo grep is even better ;-) Aug 30 09:17:15 is there any difference between FOO_prepend = 'bar' and FOO .= 'bar' Aug 30 09:17:43 i believe there is a difference, but i am not sure ;-) Aug 30 09:23:17 yep, there is Aug 30 09:23:44 .= takes effect immediately when the line is parsed Aug 30 09:24:15 _prepend is deferred until after parsing Aug 30 09:25:28 ndec: also, .= appends; the equivalent for prepending is =. Aug 30 09:26:16 ok, i got confused by .= and =., but you answered my question! Aug 30 09:26:28 bluelightning: do you know any reason why to use _prepend/_apppend in places where .=/=. work? Aug 30 09:26:56 bluelightning: in other words why not use .=/=., "by default" and save _prepend/_append only for special cases? Aug 30 09:26:56 JaMa: historical reasons in some cases since .= / =. are quite a bit newer Aug 30 09:27:04 so, if i really need to make sure that 'nobody' will override my variable, i should use _prepend Aug 30 09:27:27 in my case i want to ensure some IMAGE_FSTYPES are always set, from distro.conf. Aug 30 09:27:28 JaMa: worth noting as well is that .= / =. can't work in conjunction with overrides whereas _append / _prepend can Aug 30 09:27:50 bluelightning: ah OK, makes sense, thanks, I was thinking about it because e.g. IMAGE_FSTYPES_append is hard to "override" even with IMAGE_FSTYPES_forcevariable Aug 30 09:27:52 ndec: that should ensure that yes Aug 30 09:28:10 thanks! Aug 30 09:28:15 JaMa: nigh-on impossible to override yes Aug 30 09:29:16 i have another question ;-) in a BSP layer, i want to install a GST plugin (for h/w decode), so we use MACHINE_EXTRA_RDEPENDS and it works. however we would need to include that plugin only if gstreamer is there in the image already. e.g. we build images without gstreamer with the same BSP. Aug 30 09:29:27 bluelightning: at least for DEPENDS_append = "foo" in .bbclasses I'm trying to use intermediate variable DEPENDS_FOO = "foo" which can be overriden Aug 30 09:29:38 is that possible to have 'conditional' MACHINE_EXTRA_RDPENDS? Aug 30 09:30:13 bluelightning: but in this case using .= won't help much, because typical case is that I want to disable extra dependency from .bbclass without overriding the rest of DEPENDS Aug 30 09:31:15 ndec: are you sure that 'nobody' won't have valid use-cases when overriding IMAGE_FSTYPES should work? Aug 30 09:31:38 ndec: conditional upon what in particular? Aug 30 09:32:21 e.g. on CI server which does only build tests and nobody is expected to flash resulting images it's nice to be able to build just .tag even when DISTRO/MACHINE maintainer knows that .ext4 IMAGE_FSTYPE is really needed Aug 30 09:32:35 ndec: for some situations you can use overrides; otherwise you can use python expressions in the value e.g. ${@base_conditional(...)} or ${@base_contains(...)} Aug 30 09:33:53 JaMa: everybody can add more FSTYPES if they need. but i want to enforce that all my distro users at least generate tar.gz. Aug 30 09:34:07 JaMa: quite a long time ago I think there was a discussion on how to set IMAGE_FSTYPES and the outcome was we should always set it in machine configs at least using += Aug 30 09:34:30 bluelightning: and I agree with that conclusion Aug 30 09:34:37 yep, so do I Aug 30 09:34:38 well, i think the problem would be with DISTRO config, which is parsed after MACHINE config. Aug 30 09:34:48 ndec: adding is simple, I'm asking about removing Aug 30 09:35:22 well, it's my distro , i can create my rules, no ;-) Aug 30 09:35:33 ndec: if I have local.conf which adds e.g. tar.bz2 then I really don't need .tar.gz even when your distro thinks otherwise Aug 30 09:36:13 well, in fact it's even for a bad reason that i need that... but our CI script rely on tar.gz to be there... i should fix the CI scripts instead ;-) Aug 30 09:36:15 ndec: true, you can do whatever you want there :) I'm just warning about that :) Aug 30 09:37:14 we have IMAGE_FSTYPES_append in one BSP and I'm dragging one extra patch in my local checkout just to get rid of that :) Aug 30 09:38:38 yes, i see the problem.. let's say i will do that, but make sure to fix the CI scripts so that i can remove later! Aug 30 09:41:21 bluelightning: so, i can use ${@base_conditional(..)} in MACHINE_EXTRA_RDEPENDS! nice. how do i query if gstreamer is pulled already? Aug 30 09:41:53 hi all Aug 30 09:42:03 hi pb_ Aug 30 09:42:20 ndec: you can't at that level Aug 30 09:44:19 when MACHINE_EXTRA_RDEPENDS is processed we don't already have access to all the packages that the image will pull? Aug 30 09:44:42 no, way too early for that Aug 30 09:45:38 can i do RDEPENDS_gstreamer = "my gst plugin" Aug 30 09:45:40 it may not be obvious but machine/distro configs get parsed really early; then later each recipe is parsed (or loaded from the cache) and then recipes that are actually going to be built are parsed again when it comes time to execute tasks from them Aug 30 09:46:12 that *might* work Aug 30 09:46:34 it would have to be RDEPENDS_gstreamer_append = " mygstplugin" Aug 30 09:47:12 ok. another option would be to .bbappend gstreamer in our BSP layer, and add the RDEPENDS there. Aug 30 09:47:14 i suppose. Aug 30 09:47:20 but this isn't quite nice. Aug 30 09:47:51 don't you believe it's a 'normal' use case to be able to add machine packages based on the image content? Aug 30 09:49:06 well bbappends for recipes are a pretty standard means of affecting a recipe in a layer Aug 30 09:56:19 bluelightning: hmm,but the gst plugins will like RDEPENDS on gstreamer too. would that work ? e.g. circular RDEPENDS? Aug 30 09:56:58 I guess (hope) opkg can resolve than kind of circdeps Aug 30 09:57:44 (it roughly means that you have to install both, no big stuff) Aug 30 09:57:55 (erm, that one can't be installed without the other) Aug 30 09:58:50 ok, i haven't tried yet, but i will ;-) Aug 30 10:00:05 probably RRECOMMENDS are more appropriate here, but I think the package manager should be able to resolve the situation Aug 30 10:00:45 given that both RDEPENDS and RRECOMMENDS are always installed, is there any difference between the 2? Aug 30 10:01:20 for your case, the packages being added to RRECOMMENDS will probably always exist so there won't be a lot of difference Aug 30 10:01:46 but technically speaking RDEPENDS means "this thing will break without this other thing so it's not possible to install one without the other" Aug 30 10:02:24 whereas RRECOMMENDS is more like "this thing is useful to provide additional functionality, but if it isn't present the package will still work" Aug 30 10:02:56 ok. will try both, if they both work, we will use RRECOMENDS. Aug 30 10:03:00 thank you! Aug 30 10:42:13 JaMa: eglfs works now, and I'm trying to test wayland. does qtwayland in webos-ports compile for you? Aug 30 10:53:59 yes it does Aug 30 11:02:26 JaMa: hm. which toolchain? I get compile errors. Aug 30 11:03:19 http://pastebin.com/PKbWGLuF Aug 30 11:11:11 tasslehoff: internal Aug 30 11:11:35 the paste shows only warning Aug 30 11:19:12 JaMa: ah, wrong paste http://pastebin.com/AnpD3uQ2 Aug 30 11:19:54 tasslehoff: you need also newer wayland (also in meta-webos-ports) Aug 30 11:20:49 JaMa: I brought that along, but perhaps I need set fix the preferences Aug 30 11:22:33 JaMa: "bitbake wayland" uses the wayland 1.1.0 recipe Aug 30 11:42:33 same compile error with wayland 1.2.0, so that is not the issue Aug 30 11:52:39 JaMa: this is something it should get from my virtual/egl provider, it seems. in my case that is libgles-omap3, which doesn't have it. Aug 30 12:00:27 denix: the newer sgx drivers with wayland support still don't work on omap3530, do they? Aug 30 12:03:16 I'm on version 4.05.00.03 of omap3-sgx-modules/libgles-omap3 **** ENDING LOGGING AT Sat Aug 31 02:59:58 2013