http://permalink.gmane.org/gmane.comp.handhelds.openembedded hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.comp.handhelds.openembedded/58297 <pre>There are three issues I would like to comment on: 1. systemd migration: From what I see the only major step left over is to bury meta-systemd. The only appends found there are those for oe-core. I asked for this long time ago [1] and support was offered but... 2. indention: Reading between the lines there is some unhappiness on meta-oe using four spaces for shell and python code. I personally agree with Martin here because I have not seen a technical reason for shell requiring tabs so far. To me this looks like a style decision which increases the burden to submit for low-skilled people like me. Could somebody please enlighten me: For what technical reason do we need tabs in shell code? 3. xserver-nodm-init oe-core vs. meta-oe This is a long lasting issue and Martin commented on why there is a different approach in meta-oe [2]. One blocker for progress is xinput calibrator rework. Short story: I have a solution working here which is capable of starting calibrator by udev/systemd and can be invoked by an</pre> Andreas Müller 2013-05-22T08:31:16 http://permalink.gmane.org/gmane.comp.handhelds.openembedded/58296 <pre>This recipe has been failing to build. With this patch it now builds. build tested for beaglebone Signed-off-by: Khem Raj &lt;raj.khem&lt; at &gt;gmail.com&gt; CC: Paul Eggleton &lt;paul.eggleton&lt; at &gt;linux.intel.com&gt; --- recipes-bsp/ezx/ezxd_svn.bb | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/recipes-bsp/ezx/ezxd_svn.bb b/recipes-bsp/ezx/ezxd_svn.bb index 6dbcd0f..7b69454 100644 --- a/recipes-bsp/ezx/ezxd_svn.bb +++ b/recipes-bsp/ezx/ezxd_svn.bb &lt; at &gt;&lt; at &gt; -1,12 +1,12 &lt; at &gt;&lt; at &gt; DESCRIPTION = "Open implementation of motorola's tapisrv, replaces opentapi" -LICENSE = "GPLv2" +LICENSE = "GPLv2+" SECTION = "devel" AUTHOR = "Daniel Ribeiro" SRCREV = "2513" PV = "0.0+svnr${SRCPV}" PR = "r4" - +LIC_FILES_CHKSUM = "file://plugin.c;endline=19;md5=16da36fbb577507b411368f133ce2067" SRC_URI = "svn://svn.openezx.org/trunk/src/userspace/;module=ezxd;protocol=http \ file://ezxd.init \ " &lt; at &gt;&lt; at &gt; -18,9 +18,9 &lt; at &gt;&lt; at &gt; INITSCRIPT_PARAMS = "start 00 S ." S = "${WORKDIR}/${PN}" -CFLAGS_append = " -DDEBUG " </pre> Khem Raj 2013-05-22T02:16:49 http://permalink.gmane.org/gmane.comp.handhelds.openembedded/58294 <pre> My builds were with gcc-4.8 and I see chromium do_compile failing in my last build and the same in khem's log http://lists.linuxtogo.org/pipermail/openembedded-devel/2013-May/045634.html | ../../third_party/webrtc/system_wrappers/interface/scoped_ptr.h: In destructor 'webrtc::scoped_ptr&lt;T&gt;::~scoped_ptr()': | ../../third_party/webrtc/system_wrappers/interface/scoped_ptr.h:55:18: error: typedef 'type_must_be_complete' locally defined but not used [-Werror=unused-local-typedefs] | typedef char type_must_be_complete[sizeof(T)]; | ^ </pre> Martin Jansa 2013-05-21T21:04:23 http://permalink.gmane.org/gmane.comp.handhelds.openembedded/58293 <pre> On May 21, 2013, at 12:47 PM, Andreas Müller &lt;schnitzeltony&lt; at &gt;googlemail.com&gt; wrote: yes gcc 4.8 and no local patches to chromium </pre> Khem Raj 2013-05-21T19:50:21 http://permalink.gmane.org/gmane.comp.handhelds.openembedded/58292 <pre>I was also wondering of the passed chromium in the last logs you sent. Was this build performed with gcc 4.8 - or was there an update fixing builds with gcc 4.8 which I have missed? Andreas _______________________________________________ Openembedded-devel mailing list Openembedded-devel&lt; at &gt;lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel </pre> Andreas Müller 2013-05-21T19:47:21 http://permalink.gmane.org/gmane.comp.handhelds.openembedded/58290 <pre> I plan to push it today anyway, I was just waiting for khem's reply about .inc merge :). current webkit-efl revision was failing near the end while linking, but I wanted to upgrade it anyways (I was using old revision mostly because we didn't have harfbuzz when I was upgrading it for last time), but it's hard to find newer working revision and what's even worse is that only test app for webkit-efl (I know of) is eve which is quite abandoned in upstream and every webkit-efl upgrade in the past required couple of fixes in eve to support new APIs :/. Interestingly last revision I was building today r141868 fails in different places for armv4t, armv5te+armv7a and qemux86-64 :). </pre> Martin Jansa 2013-05-21T19:32:04 http://permalink.gmane.org/gmane.comp.handhelds.openembedded/58289 <pre>Few errors should be fixed by my last series not yet applied (gtkhtml2 / evince - this is not a ping :) For chromium I have fixed some (not yet all) errors which came up with gcc 4.8 update. Looking into webkit-efl error messages I think there are similar issues (webkit). Hope to find the time to fix both next week. Hopefully an angel is blessing us with working arm-kernels then... Andreas </pre> Andreas Müller 2013-05-21T19:20:26 http://permalink.gmane.org/gmane.comp.handhelds.openembedded/58288 <pre>Hi All I have run world build on angstrom and here are results if anyone is interested and provide fixes. http://sakrah.dontexist.org/files/eglibc.beaglebone.world.log There are a lot of parsing errors especially from meta-opie Thanks -Khem </pre> Khem Raj 2013-05-21T18:16:10 http://permalink.gmane.org/gmane.comp.handhelds.openembedded/58287 <pre>Hi Otavio, Le Tue, 21 May 2013 00:02:42 -0300, Otavio Salvador &lt;otavio&lt; at &gt;ossystems.com.br&gt; a écrit : pushed to dylan-next, doesn't apply to danny. Eric _______________________________________________ Openembedded-devel mailing list Openembedded-devel&lt; at &gt;lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel </pre> Eric Bénard 2013-05-21T17:18:07 http://permalink.gmane.org/gmane.comp.handhelds.openembedded/58286 <pre> Good point. It would also discourage people from using compositing managers which render using desktop OpenGL, then wondering why the 3D effects are so awfully slow. Same goes for stuff like Enlightenment Evas, which uses by default the desktop GL backend instead of the GLES one. </pre> Carlos Rafael Giani 2013-05-21T16:57:29 http://permalink.gmane.org/gmane.comp.handhelds.openembedded/58285 <pre> +1 </pre> Otavio Salvador 2013-05-21T16:47:39 http://permalink.gmane.org/gmane.comp.handhelds.openembedded/58283 <pre> You can change mesa's PACKAGECONFIG to not build egl and gles. meta-intel does something like this because the EMGD/CDT drivers are in the same boat. However considering our software GL support in Mesa is currently swrast (very very bad) and not llvmpipe (usable if you have enough CPU, which we generally don't) you generally don't want to actually have any OpenGL present at all. Generally it's mesa-demos that pulls in virtual/libgl, and in master this can be disabled. This may be worth a backport if someone wants to backport and test it. Ross </pre> Burton, Ross 2013-05-21T15:22:40 http://permalink.gmane.org/gmane.comp.handhelds.openembedded/58282 <pre>On Tue, May 21, 2013 at 12:51 AM, Andreas Müller &lt;schnitzeltony&lt; at &gt;googlemail.com&gt; wrote: I think this case looks ok if its lone case. Although keeping .incs do have advantages. _______________________________________________ Openembedded-devel mailing list Openembedded-devel&lt; at &gt;lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel </pre> Khem Raj 2013-05-21T14:30:58 http://permalink.gmane.org/gmane.comp.handhelds.openembedded/58281 <pre>Florian, Thanks for all your effort on behalf of the OpenEmbedded Project! Philip On 05/19/2013 08:22 AM, Florian Boor wrote: &gt; </pre> Philip Balister 2013-05-21T12:39:30 http://permalink.gmane.org/gmane.comp.handhelds.openembedded/58280 <pre>Also updated the git repo address after recent changes in hosting. The recipe failed to build for machines without neon as a tune feature. The cmake config options have been changed so that it configures properly now. Disable documentation to prevent build failures on some machines, Tested on armv7a, x86, and x86-64. Signed-off-by: Philip Balister &lt;philip&lt; at &gt;balister.org&gt; --- meta-oe/recipes-connectivity/gnuradio/gnuradio_git.bb | 11 ++++------- ...hd-firmware_003.005.002.bb =&gt; uhd-firmware_003.005.003.bb} | 0 2 files changed, 4 insertions(+), 7 deletions(-) rename meta-oe/recipes-connectivity/uhd/{uhd-firmware_003.005.002.bb =&gt; uhd-firmware_003.005.003.bb} (100%) diff --git a/meta-oe/recipes-connectivity/gnuradio/gnuradio_git.bb b/meta-oe/recipes-connectivity/gnuradio/gnuradio_git.bb index edd4615..45f4c77 100644 --- a/meta-oe/recipes-connectivity/gnuradio/gnuradio_git.bb +++ b/meta-oe/recipes-connectivity/gnuradio/gnuradio_git.bb &lt; at &gt;&lt; at &gt; -70,7 +70,7 &lt; at &gt;&lt; at &gt; SRCREV = "5f69899e059e9bea58f92af61f70fc3f63</pre> Philip Balister 2013-05-21T12:32:36 http://permalink.gmane.org/gmane.comp.handhelds.openembedded/58279 <pre> This also crops up when building for raspberrypi with the meta-raspberrypi layer. The errors I see in a `bitbake world` are (with paths shortened): ERROR: Multiple .bb files are due to be built which each provide virtual/egl (.../openembedded-core/meta/recipes-graphics/mesa/mesa_9.0.2.bb .../meta-raspberrypi/recipes-graphics/userland/userland_git.bb). This usually means one provides something the other doesn't and should. ERROR: Multiple .bb files are due to be built which each provide virtual/libgles2 (.../openembedded-core/meta/recipes-graphics/mesa/mesa_9.0.2.bb .../meta-raspberrypi/recipes-graphics/userland/userland_git.bb). This usually means one provides something the other doesn't and should. It's not really something I've looked into much (I don't know the full list of things mesa provides) but if there's a solution for other platforms I could have a look at doing a similar thing in meta-raspberrypi. -- Paul Barker Email: paul&lt; at &gt;paulbarker.me.uk http://www.paulbarker.me.uk </pre> Paul Barker 2013-05-21T10:51:22 http://permalink.gmane.org/gmane.comp.handhelds.openembedded/58278 <pre> The collision is indeed between marvell-libgfx and mesa, I just verified. My case is actually quite common with embedded 3D hardware - EGL, OpenGL ES 1.x,2.x and OpenVG are supported, but desktop OpenGL isn't. I have seen this with nVidia Tegra, Vivante, PowerVR, and ARM Mali hardware so far. It would be useful to instruct Mesa to turn off its OpenGLES and EGL support, leaving Mesa only for GLX+Desktop OpenGL (software-rendered), if anybody really needs it. As an alternative, as you suggest, I could simply turn off desktop OpenGL, but I have the feeling that this would be better off as a user decision that can be configured in the local.conf file. What do you think? </pre> Carlos Rafael Giani 2013-05-21T10:08:56 http://permalink.gmane.org/gmane.comp.handhelds.openembedded/58277 <pre> What are the bb files that are being build? I'm guessing mesa and marvell-libgfx, but can you confirm this? If you use depexp you can find out what's pulling in mesa, but it's generally mesa-demos. This depends on virtual/libgl that you're not providing, so it will pull in Mesa. If you don't have any support for "big" GL then the easiest fix is to take the recent patches to mesa-demos in master that let you turn off GL using PACKAGECONFIG options. Ross </pre> Burton, Ross 2013-05-21T09:45:43 http://permalink.gmane.org/gmane.comp.handhelds.openembedded/58276 <pre>Before doing this I have checked: Nothing except glibmm itself includes glibmm.inc in the layers I use. So for me it looked like a remnant from classic oe where we had more than one version for many recipes. So if this code is not really shared I prefer clean recipes without includes. Do you have a use case for this include - then I should send V2. Andreas </pre> Andreas Müller 2013-05-21T07:51:22 http://permalink.gmane.org/gmane.comp.handhelds.openembedded/58275 <pre>Hello Eric, Please cherry-pick the bac6da16a0d57f30c2cde1d805b3957147abdaeb into dylan and danny. Regards, </pre> Otavio Salvador 2013-05-21T03:02:42 http://permalink.gmane.org/gmane.comp.handhelds.openembedded/58274 <pre>Hi Martin, On Friday, May 17, 2013 08:11:59 PM Martin Jansa wrote: Yes, it needs that fix that I mentioned into oe-core. Can you take a look into that? Thank you </pre> Felipe Ferreri Tonello 2013-05-20T21:43:42 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.handhelds.openembedded