**** BEGIN LOGGING AT Sat Mar 30 02:59:59 2013 Mar 30 10:11:49 suppose I build an image of a MACHINE xyz . DEFAULTTUNE is set to "armv7ahf" . then, after the image is finished, I change DEFAULTTUNE to "armv7a" , and build the image again. what happens? will the packages that have PACKAGES_ARCH set to MACHINE_ARGS get automatically cleaned (for example, the kernel)? or will it break? Mar 30 14:52:24 hello, isnt this doing the wrong thing? https://github.com/openembedded/oe-core/blob/master/meta/recipes-multimedia/gstreamer/gst-ffmpeg-0.10.13/configure-fix.patch Mar 30 14:52:48 if test "x$disable_yasm" != "xyes"; then embffmpeg_configure_args="$embffmpeg_configure_args --disable-yasm"; fi Mar 30 14:52:59 so, if disable_yasm is not yes, then add --disable-yasm ? Mar 30 14:53:25 shouldnt it be if test "x$disable_yasm" = "xyes" ? Mar 30 14:57:39 I wonder why we use the embedded ffmpeg Mar 30 14:58:05 and I would use gst-libav or so Mar 30 14:59:20 ah okay looks like its libav already Mar 30 14:59:57 but yes the test is wrong Mar 30 15:00:09 should be = Mar 30 15:00:21 thats why you should not use the inverted stuff Mar 30 15:00:42 ah wrote it in the mailing list already :) Mar 30 15:00:44 well Mar 30 15:00:44 if test "x$disable_yasm" = "xyes"; then Mar 30 15:01:23 another thing is this: why arent yasm and liborc present in oe-core yet? the absence of both seriously degrade gstreamer and ffmpeg performance Mar 30 15:01:59 the question is why is gstreamer in oe-core Mar 30 15:02:15 hmm I would not want it in meta-oe Mar 30 15:02:23 meta-oe is unstable and breaks things often Mar 30 15:02:26 but yes recipes-multimedia should contain yasm than Mar 30 15:02:38 I have no problems with meta-oe Mar 30 15:02:43 and when you want stable Mar 30 15:02:45 use danny Mar 30 15:02:54 or upcoming release Mar 30 15:03:00 I have been burned by meta-oe several times (even danny) Mar 30 15:03:45 xorg server failed to build, libvpx got broken ... Mar 30 15:04:17 hm which machine Mar 30 15:04:27 xorg did not break for me Mar 30 15:04:30 using the meta-fsl-arm layer, for the freescale i.mx6 Mar 30 15:04:38 without meta-oe, everything was fine Mar 30 15:04:59 used the danny branches of meta-fsl-arm and meta-oe Mar 30 15:05:12 hm than yo are really unlucky Mar 30 15:05:59 perhaps oe should adopt a model similar to gstreamer Mar 30 15:07:00 gstreamer core, gst-plugins-base (basic plugins), gst-plugins-good (additional good-quality plugins with no licensing issues), gst-plugins-bad (new/untested/broken plugins), gst-plugins-ugly (same as good but with licensing and royalty issues) Mar 30 15:07:18 how about oe-core, oe-extra, oe-extra-unstable? Mar 30 15:07:32 no Mar 30 15:08:38 right now meta-oe is like russian roulette to me. there are unmaintained and untested recipes along with good ones. the libvpx one was clearly broken a few weeks ago, and this was on the danny branch! Mar 30 15:09:01 dv sure this can happen Mar 30 15:09:16 but when discoverd it will be fixed soon enough Mar 30 15:16:21 dv_: JaMa is doing world build tests on a regular basis, FWIW Mar 30 15:17:02 world build = build every single package? Mar 30 15:17:03 bluelightning but not for danny Mar 30 15:17:18 I have seen the jenkins jobs now Mar 30 15:17:48 now dont get me wrong, I dont think meta-oe is crap. I am just concerned with the lack of separation between unstable/experimental/known-to-be-broken recipes and good-quality,maintained ones Mar 30 15:18:21 dv_: any issue with fsl-arm? Mar 30 15:18:46 otavio: try building the X server with meta-fsl-arm and meta-oe added Mar 30 15:18:52 it failed to compile for me Mar 30 15:18:56 dv_: which branches? Mar 30 15:19:01 danny Mar 30 15:19:13 dv_: it works fine. I did it yestarday Mar 30 15:19:19 it was related to EGL I think Mar 30 15:19:20 dv_: which machine? Mar 30 15:19:26 imx6qsabresd Mar 30 15:19:46 ah right, the vivante drivers were also used Mar 30 15:19:54 dv_: the problem with danny is it has some race conditions (in fsl-arm case) Mar 30 15:20:00 I suspect a collision between the vivante EGL headers and the meta-oe/oe-core ones Mar 30 15:20:06 dv_: we fixed it in master Mar 30 15:20:09 but these went away once meta-oe was removed Mar 30 15:20:22 dv_: are you sure? Mar 30 15:20:24 dv yes egl is special Mar 30 15:20:31 dv_: I think it was just lucky Mar 30 15:20:34 yes, I did many builds afterwards Mar 30 15:20:46 with BB parallelization set to 4 Mar 30 15:20:54 dv_: because the problem is mesa-dri and gpu-viv headers Mar 30 15:20:58 dv_: they clash Mar 30 15:21:06 yes, these are multiple providers Mar 30 15:21:15 dv_: this has been fixed in master Mar 30 15:21:26 I had to add virtual/egl, virtual/libgles1, virtual/libgles2 to the multiple provider whitelist in my own layer Mar 30 15:21:34 (unrelated to fsl-arm) Mar 30 15:21:46 dv_: yes, not related Mar 30 15:21:51 dv_: yes lot of issues were fixed after danny Mar 30 15:22:03 JaMa: can't wait for the next release :) Mar 30 15:22:04 dv_: you'll be using X? Mar 30 15:22:16 hi jama Mar 30 15:22:20 I hear there are facilities for addressing the EGL problem now? Mar 30 15:22:22 JaMa: :) Mar 30 15:22:23 hi Mar 30 15:22:30 dv_: not facilities Mar 30 15:22:41 dv_: but it is "less bad" heheh Mar 30 15:22:46 otavio: was directed to JaMa , about the next release Mar 30 15:23:10 dv_: Are you going to use X11? Mar 30 15:23:11 otavio: and yes, I have to use X. I preferred directly using the framebuffer, but thats not an option anymore Mar 30 15:23:13 dv_: or FB? Mar 30 15:23:26 Ok Mar 30 15:23:34 dv why you have to use X? Mar 30 15:23:38 there is wayland now Mar 30 15:23:45 and qt should work on fb too Mar 30 15:23:50 dv_: In master the Xorg is not working with DRI Mar 30 15:23:55 first, the vivante drivers do not support wayland. second, the customer wants X. Mar 30 15:23:57 dv_: if it is Qt, use fb only Mar 30 15:24:07 (but is open to suggestions about wayland if it works with the closed source drivers) Mar 30 15:24:29 dv_: I did one BSP for a customer using Qt (with ePDC) and FB only Mar 30 15:24:36 dv_: works great Mar 30 15:24:47 wait, so GLES wont work with X? Mar 30 15:25:01 dv what is your goal? Mar 30 15:25:05 dv_: In master it will (next week) Mar 30 15:25:10 alright Mar 30 15:25:17 woglinde: just asking Mar 30 15:25:34 dv_: I have the patches in my local tree but I am waiting to see if they can provide a better fix Mar 30 15:25:45 dv_: they = FSL Mar 30 15:25:50 otavio: what happens if I try to create an EGL context and start using GLES functions in X? Mar 30 15:26:22 dv should work Mar 30 15:26:23 also, to pick up on what woglinde said, any word on wayland support? Mar 30 15:26:24 dv_: you'll call vivante methods directly? Mar 30 15:26:27 mesa has it long time Mar 30 15:26:51 hm okay I know nothing about vivante Mar 30 15:26:55 dv_: yes, wayland should happen soon Mar 30 15:27:05 are they just egl/gles lins for imx6? Mar 30 15:27:09 dv_: but for Qt, fb is nicer now Mar 30 15:27:11 like tegra or mali Mar 30 15:27:14 or rpi Mar 30 15:27:20 otavio: "vivante methods"? You mean the EGL stuff from vivante? Mar 30 15:27:20 woglinde: yes Mar 30 15:27:25 dv_: yes Mar 30 15:27:31 yeah thats what I meant Mar 30 15:27:36 dv_: or expect DRI to do it? Mar 30 15:27:43 dv_: DRI is broken Mar 30 15:27:44 also, for GLES support, I'd use qt5 anyway Mar 30 15:27:45 ;) Mar 30 15:28:01 since it uses EGL&GLES directly Mar 30 15:28:03 dv_: yes; nicer Mar 30 15:28:44 otavio: do you always get the drivers through FSL, or do you have contact with vivante directly? Mar 30 15:28:52 otavio/dv than it should work under qt-x and qt-fb Mar 30 15:29:06 dv_: well Mar 30 15:29:10 woglinde: then should what work? Mar 30 15:29:22 dv_: you know, NDA :) Mar 30 15:29:30 oh. right. Mar 30 15:29:53 dv_: but I have the contact I need ;-) Mar 30 15:30:02 dv_: or the ones who has them Mar 30 15:30:29 I wonder why vivante doesnt support EGL on FB for other chips, like the GC600 Mar 30 15:30:32 dv_: If you really don't *need* X11 I'd say you to avoid X Mar 30 15:31:01 my thoughts exactly. which is why I am not happy about the GC600 being X only Mar 30 15:31:27 ( I know the imx6 uses the GC2000, which is an entirely different design) Mar 30 15:31:27 dv_: but viv gpu has fb support Mar 30 15:31:44 dv_: yes Mar 30 15:32:07 I wanted you to ask about the GC600 thing, but with an NDA, this would be a bit difficult :) Mar 30 15:32:40 dv_: I am restricted to FSL related things Mar 30 15:33:25 but overall I like your layer. things worked out of the box (well, except for the xserver issue) Mar 30 15:33:31 I only had to tweak the u-boot config for my needs Mar 30 15:33:58 dv_: if you could drop X11 from distro features and it will give you a workable gpu-viv without x1 Mar 30 15:34:04 dv_: I am glad Mar 30 15:34:18 dv_: things are getting better Mar 30 15:34:42 dv_: FSL guys are contributing more and it is now easier to fix issues Mar 30 15:35:19 there is still one open gstreamer-related issue with the appsink. Mar 30 15:39:14 dv_: yes Mar 30 15:39:21 dv_: this is still not fixed Mar 30 15:39:30 I think I reported it :) Mar 30 16:22:58 dv_: did you find a workaround? Mar 30 16:23:10 for the appsink issue? no. Mar 30 16:23:26 it also happened with master, not just with danny. Mar 30 16:23:45 interestingly, it only seems to happen with the appsink. even fakesink is ok. Mar 30 16:28:55 dv_: Can you ping the issue? and provide the more information you can? Mar 30 20:17:51 is there documentation about the oe-core recipe inclusion process? Mar 30 20:18:29 some list of requirements for getting added to oe-core? Mar 30 20:23:28 sent git patches to the oe-core mailinglist Mar 30 20:24:08 so, if I wrote a tool, and want to add recipes to it to oe-core, thats all I need to do? nice. Mar 30 20:24:20 (to get it looked at I mean) Mar 30 20:24:27 yes Mar 30 20:27:42 remember that it is supposed to be 'core', so getting a new recipe in is nontrivial, but that's the process, yep Mar 30 20:29:15 traded my finicky g5 imac for a g4 mini Mar 30 20:32:19 kergoth: its a tool for printing out information about EGL, OpenGL ES, OpenVG Mar 30 20:32:33 ah, cool Mar 30 20:32:48 on one hand, its pretty specific, on the other hand, EGL/GLES/VG are central components these days Mar 30 20:33:01 well, I'll whip up some recipes for it tomorrow Mar 30 20:38:01 :-D Mar 30 20:38:03 dv_: \n/ Mar 30 20:38:06 \m/ Mar 30 20:41:22 Anyone noticed tasks are rerunning more in today's master? Mar 30 20:41:42 my rm_work tasks now re-run even when no changes were made Mar 30 21:29:30 march madness Mar 30 21:40:03 otavio: not even buildhistory change? Mar 30 21:40:19 JaMa: no Mar 30 21:40:25 JaMa: weird Mar 30 21:44:03 openembedded-core/scripts/sstate-diff-machines.sh is your friend :) Mar 30 21:44:18 just compare it with previous rev Mar 30 21:44:48 0: linux-imx-2.6.35.3-r43.22 do_package_setscene (pid 7046) Mar 30 21:44:53 for example Mar 30 21:45:11 this happens when I build same machine, same image, no change Mar 30 21:45:38 you don't see this behaviour? Mar 30 21:49:01 not really, because in all my todays builds a lot of rebuilds were expected Mar 30 21:55:13 JaMa: right Mar 30 21:55:27 JaMa: I am finishing this build and will check the sign filees Mar 30 22:58:14 Is the server providing xterm sources down ? Mar 31 00:18:15 I can set the SRC_URI in python code with d.setVar('SRC_URI', ..) but how do I set SRC_URI[headers.md5sum] ? Mar 31 00:19:01 there are serval recipes with diffrent sources Mar 31 00:21:35 no I mean how do I set SRC_URI[headers.md5sum] with python code? Mar 31 00:21:42 I cannot find any examples for this Mar 31 00:21:55 just like this? d.setVar('SRC_URI[headers.md5sum]', ..) **** ENDING LOGGING AT Sun Mar 31 02:59:59 2013