**** BEGIN LOGGING AT Thu Dec 04 02:59:59 2014 Dec 04 06:14:43 hi guys Dec 04 06:15:02 where can I get opengl arm port? Dec 04 06:31:42 kanupatar: there is no such thing as an "opengl arm port" as there is no generic opengl implementation Dec 04 06:31:50 kanupatar: you might want to read up on mesa… Dec 04 06:32:25 LetoThe2nd: how can I bring up the same in R-Car h2 ? am.renesas.com/applications/automotive/cis/cis_highend/rcar_h2/index.jsp running with Linux? Dec 04 06:33:16 kanupatar: i do not know, but i do not feel like reading it up for you. Dec 04 06:33:53 LetoThe2nd: ? Dec 04 06:34:01 kanupatar: mesa is not perfectly documented, but ok. there are recipes for it readily available for you, and a lot of examples online. Dec 04 06:35:43 kanupatar: i see no need to read up on some renesas marketing website to find out first what this thing is, what support for it exists, and so on, and so on. Dec 04 06:36:35 kanupatar: if it runs linux, and has a functioning display, it should be possible to get mesa running on it. (no statement about the performance here, please not.) Dec 04 06:36:48 LetoThe2nd: okay Dec 04 06:36:49 s/please not/please note/ Dec 04 06:37:07 LetoThe2nd: so I need to build and put mesa lib in the board? Dec 04 06:37:19 ro9ughly Dec 04 06:37:38 but i really suggest you learn how a linux system is built and used. Dec 04 06:38:45 compile and copy over might work for some really, really trivial library, and i'm almost sure that it won't for something as complicated as a part of the graphics stack Dec 04 06:40:00 LetoThe2nd: is there any oe download package available as opkg Dec 04 06:41:02 kanupatar: if your board is running something (maybe angstrom) that somebody else is providing a fitting repository feed, then there might be. i would not bet on it. Dec 04 06:41:23 kanupatar: plase note: OE is neither a distribution, nor is it a service for you to download binary packages. Dec 04 06:43:10 kanupatar: as also please consult the documentation and/or support of the specific device that you are using. Dec 04 06:43:30 LetoThe2nd: okay Dec 04 07:16:22 LetoThe2nd: how can I see the exact version of OE version running in board? Dec 04 07:17:04 kanupatar: OE is no distribution. i told you. hence, it has no "exact version" Dec 04 07:17:55 LetoThe2nd: what OS distro is running in my board? Dec 04 07:17:58 how to find it? Dec 04 07:18:01 Angstrom? Dec 04 07:27:06 kanupatar: i do not know, and honestly, i will _NOT_ read the documentation for you. Dec 04 07:27:53 kanupatar: /etc/os-release *might* give you a hint. but do not blame me if it doesn't Dec 04 07:33:22 LetoThe2nd: thanks...np Dec 04 08:54:02 morning everyone :) Dec 04 09:00:35 hi :) Dec 04 09:29:59 hi i have a question: what is the purpose of using oe for not-autotooled programs? I mean crossbuilding can be dealt with makefile and specified toolchain Dec 04 09:33:40 is it just me or does that question not make any sense Dec 04 09:34:51 certainly :) im new to oe and i want to understand why use oe? Dec 04 09:34:51 tbr: kind-of Dec 04 09:35:37 tyst: the main points are a) reproductibility for others (that do not know the magic incantations for the specific makefile incarnation) b) integration into the build process Dec 04 09:36:05 ls Dec 04 09:36:09 ok Dec 04 09:36:22 tyst: i, for one, certainly do not want to learn x slightly different crosscompile incantations fo x packages i need in my build Dec 04 09:37:08 tyst: and of course, everything in a build process that has to be done manually significantly increases failure probability when trying to reproduce. Dec 04 09:38:04 my main point is: I start an image build once and I get a result. no need to run 100 things manually Dec 04 09:38:19 ok but in the particular case of building smth for another target, what does oe bring? Dec 04 09:38:58 OE makes most sense if you want to build a whole system, not just one binary Dec 04 09:39:11 tyst: oe is not meant to build something only once for another, existing system. Dec 04 09:39:20 tyst: oe is there to build *the* system Dec 04 09:39:23 it can generate an SDK if you want to have a matching toolchain for one off builds etc Dec 04 09:40:07 ok Dec 04 09:40:19 thx for your answers this is clearer to me now Dec 04 09:54:43 morning all Dec 04 10:26:05 Anyone seen a recipe for pypy in a layer? Dec 04 10:36:30 layers.openembedded.org? Dec 04 10:38:11 Crofton|work: I guess tasslehoff already looked there, I just did and there isn't anything Dec 04 10:41:22 that is my automatic answer to that question now Dec 04 10:46:07 Crofton|work: that was a good answer, cause I have never been there before :) Dec 04 11:23:41 I'm almost there. :) I've added PACKAGECONFIG_pn-qtbase += " gles2 ", I've added " gallium gallium-gbm gallium-llvm gallium-egl " to mesa PACKAGECONFIG and after this i have such libraries in my system : libEGL.so.1.0.0, libGLESv2.so.2.0.0, but when i try to run appliaction i have an error : Dec 04 11:23:50 gbm_create_device: invalid fd: -1 Dec 04 11:23:58 libEGL warning: GLX: failed to load GLX Dec 04 11:24:06 Could not initialize egl display Dec 04 11:24:08 Aborted Dec 04 11:24:43 I have also drm as a module loaded to my kernel (3.2.28 kernel with AM335X(OMAP3) support). Dec 04 11:25:07 Anyone know any solution for this? Dec 04 11:26:48 I've also added "libegl-gallium libgbm-gallium" to my image install. Dec 04 11:32:54 I'm running application with this command "/usr/share/qt5everywheredemo-1.0/QtDemo -platform eglfs". Maybe here's mistake? Maybe i have to configure sth to use gallium llvm. Dec 04 11:34:34 from my understanding, you should use wayland or x11 with gallium-llvmpipe Dec 04 11:51:37 What do you mean? In x files or wayland files i don't see any gallium-llvm configuration. I have egl compiled with gallium libs and xserver on my machine. Dec 04 12:06:00 koen: Is it safe to use master branch for Angstrom-distribution/oe-core ? Dec 04 12:06:37 I'm asking because i see there newer mesa version i wonder that it would resolve my problem . :) Dec 04 12:13:19 spaszkoPL: haven't tried it yet Dec 04 12:13:31 spaszkoPL: try the v2014.12-yocto.17 branch of setup-scripts Dec 04 14:28:14 I've found that in mesa package, function eglGetDisplay is only in libEGL.so not in egl_gallium.so. Is it ok? When i try to run my app i see Dec 04 14:28:20 "/usr/share/qt5everywheredemo-1.0/QtDemo: symbol lookup error: /usr/lib/qt5/plugins/platforms/libqeglfs.so: undefined symbol: eglGetDisplay" Dec 04 14:42:56 * Crofton|work grumbles. Looks like pyqt needs a different configuration for x86 vs arm Dec 04 15:11:56 JaMa, what machines must a recipe build for? Dec 04 15:38:08 Crofton|work: all enabled :) Dec 04 15:38:26 Crofton|work: I don't mind recipes explicitly restricting enabled architectures Dec 04 15:38:43 I think I have a solution Dec 04 15:38:45 but world builds on qemu{x86,x86-64,arm} shouldn't show any new errors Dec 04 15:38:52 ok Dec 04 15:39:02 I'll run those three Dec 04 15:39:14 do you run mips or powerpc? Dec 04 15:42:50 no Dec 04 15:43:11 but it would be great if someone else does Dec 04 15:44:26 I might run mips versus pyqt just to see if I need to handle it Dec 04 15:49:02 https://www.linkedin.com/jobs2/view/27857140?trk=vsrp_jobs_res_name&trkInfo=VSRPsearchId%3A148665901417708079251%2CVSRPtargetId%3A27857140%2CVSRPcmpt%3Aprimary Dec 04 15:49:14 OpenEmbedded and buildroot are not distros! Dec 04 15:57:40 good that they are looking for someone to explain it to them :) Dec 04 17:57:26 Any way to get more info to debug these: ERROR: Worker process (2249) exited unexpectedly (-9), shutting down... Dec 04 17:58:32 nevermind, looks like the oom killer Dec 04 20:24:24 Hi. I'm failing at configuring an autotools project for my native host, this is completely outside of OE-core, but I've run "autoreconf" from the SDK environment, which seems to leave me with a broken libtool detection in the configure script.. anyone got any ideas ? Dec 04 20:38:29 RP, since you seem to be familiar with libtool-cross.. I have an autotools project that I've run "autoreconf" in, from the Yocto SDK environment. When I run configure from outside the OE environment (for a native distro build), configure complains that it can't find "-libtool", since $host_alias is empty. Is this scenario not intended to work ? Dec 04 20:40:02 kroon we have some patches for libtool in so it works better for us Dec 04 20:40:28 I'm trying to be able to have one native VPATH build, and one target VPATH build from a yocto environment, in different subdirectories, building all the time Dec 04 20:41:18 woglinde, yeah.. I think those changes are the ones that are biting me when I do the native distro configuring Dec 04 20:43:03 Using my distros "autoreconf", things seem to work for both the native and the yocto sdk build Dec 04 20:44:14 Although in that case I get a warning about an unknown option, "--with-libtool-sysroot" Dec 04 20:44:59 kroon: you either need to be using the yocto libtool or the host one, I think you see that host_alias issue if you mix them Dec 04 20:47:43 JaMa, do you need all there patches I sent with pyqt, or should I jsut send the pyqt one itself? Dec 04 20:54:17 RP, hmm ok. Can I specify which libtool to use at configure time ? "LIBTOOL=my/libtool ./configure" doesn't seem to bite Dec 04 20:56:19 kroon: its not that simple, the autoconf macros and data from usr/share need to match. Basically you need to have run the right libtoolize Dec 04 21:15:05 RP, should I be able to build using my distros gcc toolchain, from inside the yocto sdk environment ? Dec 04 21:15:47 I've used autoreconf from oe sdk, now running ./configure without $CONFIGURE_FLAGS, and resetting CC, CXX etc Dec 04 21:16:02 kroon: yes, I'd have thought so Dec 04 21:16:08 it is not going so well :-/ Dec 04 21:16:39 kroon: sounds like there may be some bugs to fix there :/ Dec 04 21:17:14 RP, ok. ill try and look into it.. Dec 04 21:20:47 Crofton|work: just changed one is ok Dec 04 21:20:55 but it looks like ${host_alias} related as well. I have "-libtool", "-libtoolT" and "-libtoolT.tmp" lying in the the top native build dir. Last thing "configure" does is "config.status: executing libtool commands", and it complains that it can't remove those files Dec 04 21:20:57 ok Dec 04 21:41:04 RP, passing a proper --host to configure when I'm configuring for the native distro build seems to do the trick.. Dec 04 21:44:25 at least the libtool script that is created gets prefixed properly Dec 04 21:52:55 kroon: ah, so there is probably something wrong with our patch in the native case Dec 04 21:53:06 kroon: at the very least can you write up a bug report about that? Dec 04 21:53:26 RP, yes, will do that **** ENDING LOGGING AT Fri Dec 05 02:59:58 2014