**** BEGIN LOGGING AT Wed Aug 28 02:59:58 2013 Aug 28 06:28:45 Anyone know if there are plans to make nativesdk-* recipes in the meta-qt5 layer? Aug 28 07:08:56 tasslehoff: I don't plan it, but couple of people asked for it already Aug 28 07:09:10 tasslehoff: not sure if someone started on it Aug 28 07:14:17 JaMa: I'm probably one of those people, but I've been working on other stuff for a couple of months. Back at making-our-app-work-with-qt5 now. Aug 28 07:15:36 JaMa: not planned because you don't need/want it yourself, or because it is something few people use? Aug 28 07:19:57 because I don't need/use it, so I wouldn't be able to properly test it anyways even if I find time to work on it Aug 28 07:21:05 I also saw quite a few people asking for it on various mailing lists Aug 28 07:21:59 JaMa: ok. I'll share patches if I end up with something usable. Aug 28 07:24:35 tasslehoff: thanks Aug 28 07:55:46 morning all Aug 28 07:59:58 hello guys Aug 28 08:00:46 hi hrw Aug 28 08:02:26 yo hrw Aug 28 08:02:37 hrw: how goes fedora on chromebook? Aug 28 08:02:43 XorA: how goes Linaro work? Aug 28 08:03:02 XorA: it runs. still have to get it to better shape and to run from emmc not sd Aug 28 08:03:08 hrw: tough, hitting lots of bit of kernel I am unfamiliar with Aug 28 08:04:34 hrw: lets hope for fedora 20 you get it nice and solid :-D Aug 28 08:04:48 XorA: doubt it Aug 28 08:04:59 21? Aug 28 08:05:00 XorA: fedora uses mainline kernels Aug 28 08:05:33 hrw: yeah I know, I remain ever hopeful chromebook will make mainline someday, there are an aweful lot of them in kernel devs hands Aug 28 08:05:42 hrw: I have fedora on mine Aug 28 08:06:01 XorA: 3.11-rc boots and works. but no audio, wifi, usb3 Aug 28 08:06:21 XorA: it could take about 10 yrs like for Zaurus. Just 2 patches left Aug 28 08:06:50 ant_work: zaurus was a lot less popular than chromebook, Linaro Connect had thousands of the damn things Aug 28 08:07:02 ant_work: but zaurus is dead nowadays Aug 28 08:07:15 XorA: sadly it's been the same for every piece of hardware since first VGa drivers back in '90 Aug 28 08:12:18 ant_work: chromebook is the most powerful arm portable platform for development nowadays Aug 28 08:12:35 hrw: if we are lucky on sound broonie will get bored for 5 mins and fix that :-) Aug 28 08:12:54 XorA: I heard that -next had patches months ago Aug 28 08:12:57 hrw: for how many months more? Aug 28 08:13:35 ant_work: several I think. nearly no one wants to release such devices Aug 28 08:13:54 ant_work: most of fast arm chips now goes to phones/tablets Aug 28 08:14:44 hrw: I know, I own some A$$le devices and appreciate the BSD kernels running smoothly even on older hw ;) Aug 28 08:14:45 and android means drivers written in crayon :-( Aug 28 08:16:19 :D Aug 28 08:52:54 hmm, we have ca-certificates-cross, but that wasn't brought over Aug 28 08:54:47 ah, it was superseded by Chris's OE-Core patches Aug 28 09:03:52 bluelightning: that's one of the reasons why I prefer that people doing the move are sending removal patches Aug 28 09:05:09 Mihai even sent patch for upgrading python-docutils in meta-oe yesterday, so I guess I can ignore this one Aug 28 09:09:44 Hi, when configuring glib-2.0, ha anyone ever come across the error message "cannot compute alignment of guint32"? I see from logs this question may of been asked but finding a resolution is proving troublesome. Aug 28 09:13:01 OWayne: yes, see changes in "site" files Aug 28 09:13:13 you're probably building for architecture which doesn't have them yet Aug 28 09:14:28 and as a hint when dealing with packages for arches we dont have but debian does, nick the values from debian config.logs :-) Aug 28 09:15:17 or run configure on target device :) Aug 28 09:15:42 looking at debian build server is easier ;-) Aug 28 09:18:56 JaMa: what are the "site" files? Aug 28 09:19:26 sorry ignore that Aug 28 09:21:02 morning all Aug 28 09:24:58 JaMa: so if I wanted to use my own site files would a site folder in my meta layer take priority? Aug 28 09:25:36 assuming my layer priority is set accordingly Aug 28 10:05:50 pb_: have you ever needed perl-native on meta-micro? Aug 28 10:08:09 I mean, what happens with '#!/usr/bin/env perl '? Aug 28 10:16:33 ant_work: well, even I don't use meta-micro on my build machine, so /usr/bin/env does exist in the build environment Aug 28 10:37:38 JaMa: don't worry, I'm not going to remove anything that shouldn't be removed ;) Aug 28 10:38:00 argh we have a couple more duplications in meta-gnome I had forgotten about Aug 28 10:38:11 desktop-file-utils(-native) and gnome-desktop Aug 28 11:07:20 pb_: I was thinking this patch is hardcoding /usr http://tinyurl.com/ng24ts2 Aug 28 11:12:15 hi. is the DISTRO_FEATURES 'opengl' meant to be used for opengl only, or also for opengles? Aug 28 11:12:28 btw, i am on dylan. fwiw. Aug 28 11:14:16 both, I think. Aug 28 11:14:24 in fact, i thought it was opengl only, but this commit confused me: Aug 28 11:14:24 4c24342 xf86-video-omap: skip package if opengl isn't in DISTRO_FEATURES Aug 28 11:14:34 as clearly, on OMAP, this is about gles. Aug 28 11:14:49 ant_work: I think it's fairly harmless. Aug 28 11:14:56 pb_: but then 'weston' use opengles2 in its recipe. Aug 28 11:18:48 JaMa: ^, since you made the commit i mentioned above ;-) Aug 28 11:19:24 pb_: the short perl script is obscure to me but I'm not sure this patch really affects perlpath http://tinyurl.com/p3spv5j Aug 28 11:33:05 ndec: in xf86-video-omap it was because xserver-xorg was built without required header without opengl in DISTRO_FEATURES Aug 28 11:33:27 ndec: so at least from my POV it wasn't about opengles, but about making the selection consistent with xserver-xorg Aug 28 11:33:46 and similar change is needed in xf86-video-intel Aug 28 11:38:55 JaMa: I suspect all that is needed for an SDK is a qt5-version of of nativesdk-qt4-tools.inc. Aug 28 12:11:50 pb_: things are going for the worst.. a bashism now :/ Aug 28 12:34:02 so JaMa, is that 'expect' that whoever provides virtual/libgles, also provides virtual/libgl? my problem is that 'sdl' has this in DEPENDS: ${@base_contains('DISTRO_FEATURES', 'opengl', 'virtual/libgl', '', d)}, and my 'gles' provider does not provide libgl. Aug 28 12:44:23 ant_work: doh, where? Aug 28 12:44:29 tasslehoff: I expect couple of needed BBCLASSEXTENDS and fixes to build with them Aug 28 12:44:48 ndec: it depends what sdl really needs from it Aug 28 12:45:19 pb_: http://git.kernel.org/cgit/libs/klibc/klibc.git/tree/klcc/Kbuild Aug 28 12:46:03 wow Aug 28 12:46:18 well, I guess it isn't totally unreasonable to assume that anybody building klcc will have bash, but still. Aug 28 12:46:54 well try $(shell which $(PERL)) Aug 28 12:46:54 command -v is the POSIX way iirc Aug 28 12:47:08 pb_: ? Aug 28 12:48:15 "which" isn't POSIX (and doesn't exist on macos for example), so I guess the latter. Aug 28 12:48:53 (it does exist on macos) Aug 28 12:49:05 oh, does it? fair enough, I guess I remembered that wrong. Aug 28 12:49:13 I'm pretty sure it's not posix-required though. Aug 28 12:49:31 pb_: debian doesn't list bash as dep http://packages.debian.org/source/sid/klibc Aug 28 12:50:47 but, to be honest, I find it hard to get too excited about requiring bash here. this is a development tool, after all, and it already requires that you have gcc installed (which is way bigger than bash) so requiring the shell as well doesn't seem like it's going to be a massive hardship. Aug 28 12:51:40 well, I suppose you don't strictly need gcc installed to build klcc itself, but you do need it to use the resulting script. Aug 28 12:54:16 right Aug 28 12:54:36 klcc is just a bunch of mangled paths Aug 28 12:55:23 pb_: all that code to identify perl Aug 28 12:55:51 and pass ARGV to http://git.kernel.org/cgit/libs/klibc/klibc.git/tree/klcc/makeklcc.pl Aug 28 12:56:24 whose < print "#!${perlpath}\n"; > seems really doing anything Aug 28 12:56:47 my eyes bleed reading perl code Aug 28 12:56:58 I prolly misunderstand Aug 28 12:58:35 ant_work: I don't think it's just you, I have the same experience ;) Aug 28 12:58:54 x') Aug 28 13:04:24 JaMa: well, looking at sdl configure.in, all it does with -enable-video-opengl relates to gl, not gles. does that mean that 'opengl' in DISTRO_FEATURES means gl, and not gles, in which case i don't need that flag for ARM platforms with gles only? Aug 28 13:08:14 ndec: I'm not expert on sdl, but if that's the case why not let sdl build against mesa (as virtual/gl)? Aug 28 13:09:13 my initial problem is to understand if i need opengl in DISTRO_FEATURES. the only 'impact' in my image of having it, is that sdl pulls in mesa indeed. however that's conflicting with my 'actual' gles provider (mali) Aug 28 13:09:38 but it will cause error message about multiple virtual/libgles* providers being pulled into image build, but that's not fatal (or shouldn;t be) Aug 28 13:09:43 i am tempted to say that I should remove opengl from distro_feature (in my distro). but i wanted to make sure i understand that correctly. Aug 28 13:10:13 sure, but i don't want to pull mesa/gl if i don't need it Aug 28 13:11:17 yes in that case removing opengl from DISTRO_FEATURES is easiest way Aug 28 13:11:26 that's what I do at least Aug 28 13:11:43 ok. weston seems to be using opengles from DISTRO_FEATURES. Aug 28 13:12:03 so should we add opengles in DISTRO_FEATURES instead? weston is the only user? Aug 28 13:12:22 more generally, are DISTRO_FEATURES supposed to be documented? at least should there be a list of all features? Aug 28 13:13:42 Could somebody please explain what "Fetcher failure: SRCREV was used yet no valid SCM was found in SRC_URI" means? Aug 28 13:15:58 SRCREV is supposed to have the 'commit id' (or revision) to be fetch from SCM. you seem to have set SRVREC without setting a proper 'tree' in SRC_URI Aug 28 13:16:48 SRC_URI can fetch tarball (ftp, http, ...) or it can fetch from SCM (git, svn, hg, ..) Aug 28 13:18:21 pb_: see, I'll patch with command -v but if grep reveals more bashisms I'll do as you say Aug 28 13:18:45 righto, good plan Aug 28 13:20:09 Hm, i did not define SRCREV, and SRC_URI is .zip archive from a local folder.. Aug 28 13:22:22 kbart: well, someone has defined it ;-) you can check its value with bitbake -e Aug 28 13:23:33 ndec: re DISTRO_FEATURES, there is http://www.yoctoproject.org/docs/latest/ref-manual/ref-manual.html#ref-features-distro Aug 28 13:23:44 ndec: probably needs extending to fully cover the above though Aug 28 13:23:49 ndec: I think the reference to SRCREV there is a bit spurious actually. Aug 28 13:24:09 I suspect it actually means "SRCPV was used", and "used" in this sense means "referred to" rather than "defined". Aug 28 13:24:23 ah. Aug 28 13:25:05 so, at a first guess, the offending recipe is trying to set PV in terms of SRCPV or some such thing. Aug 28 13:25:30 kbart: ^ Aug 28 13:25:59 i see what you mean,e.g. settings SRCREV without using SRCPV wouldn't lead to any error ;-) Aug 28 13:36:39 Ah, yes.. It seems like SRCPV was used in related .bbappend file. Thank you. Aug 28 13:42:16 JaMa: have you sent updated world build result to the list, or did I miss it? Aug 28 14:17:09 eren: sorry not yet, I had to restart it because I had few more fixes for it and it's still running NOTE: Running task 10923 of 27051 Aug 28 14:19:29 JaMa: okkie, I am waiting for it Aug 28 14:19:39 JaMa: have you had a change to include the patches from me? :) Aug 28 14:20:01 sure Aug 28 15:20:27 pb_: (and ant_work) FYI: There's a tool called checkbashisms: http://sourceforge.net/projects/checkbaskisms/ Aug 28 15:34:29 if I make a change to bitbake.conf do I need to rebuild my world from scratch? Aug 28 15:35:49 OWayne: shouldn't need to Aug 28 15:36:27 OWayne: generally though you shouldn't be changing bitbake.conf unless you're intending to submit the fix to OE-Core - usually you just set the desired different variable value in local.conf or distro config Aug 28 15:37:17 hmm, ok I'll try adding the setting to my distro config and see if that helps Aug 28 15:40:35 OWayne: bitbake.conf does that: include conf/distro/${DISTRO}.conf Aug 28 15:47:24 moin Aug 28 18:25:43 I have a recipy for linux 2.6.39 in my own overlay. I specified 'PREFERRED_VERSION_linux="2.6.39"' in local.conf, but bitbake still chooses linux-yocto_3.8 as kernel. What am I doing wrong? Aug 28 18:26:47 the version isn't the issue, the name is Aug 28 18:27:04 define PREFERRED_PROVIDER_virtual/kernel = "linux" (it's currently linux-yocto, most likely) Aug 28 18:27:25 alternatively, it could be the COMPATIBLE_MACHINE int he recipe, if that doesnt' include the current machine, the recipe won't be seen as buildable Aug 28 18:35:12 ok, thanks. another thing is that I get hundreds of messages like "NOTE: preferred version 2.6.39 of nativesdk-xcb-proto not available", even if I only add PREFERRED_VERSION_linux="2.6.39 to local.conf. Aug 28 18:36:32 TimSmith_: right, that's because "linux" is in OVERRIDES Aug 28 18:36:58 TimSmith_: so when you say PREFERRED_VERSION_linux = that actually translates to PREFERRED_VERSION = and hits every recipe you're building Aug 28 18:37:35 basically it's a really good idea not to have PN match something already in OVERRIDES Aug 28 18:37:55 in the upcoming release it will warn you if it detects that situation Aug 28 18:38:04 (i.e. in master) Aug 28 18:39:35 so what should I do in order to build the image with my own linux recipy? Aug 28 18:40:15 1. name your recipe something other than linux e.g. linux-yourmachine or linux-mainline or something else Aug 28 18:40:31 2. set PREFERRED_PROVIDER_virtual/kernel as kergoth mentioned above Aug 28 18:40:35 that should be enough Aug 28 18:41:04 ok, thanks. Aug 28 18:42:11 np Aug 28 18:42:12 bb Aug 28 18:42:14 bbl Aug 28 20:44:57 god everything qt5 related takes forever to build Aug 28 21:11:53 I get an error about the line "IMAGE_PREPROCESS_COMMAND = "create_etc_timestamp"" in my image recipy. Is this no longer needed? Aug 29 02:30:15 kergoth: more than qt4? more than ACE? :) **** ENDING LOGGING AT Thu Aug 29 02:59:58 2013