**** BEGIN LOGGING AT Thu Jul 17 02:59:59 2014 Jul 17 07:13:10 Good Morning Jul 17 07:32:39 good morning Jul 17 07:34:33 morning mckoan, all Jul 17 07:34:47 khem: just saw your answer (thx btw) , configure indeed looks for /usr/include/bitstream/common.h, so i put bitstream to this path but still cannot find it Jul 17 07:40:03 how can i pass /usr/includes/bitstream to oe as a dependency? Jul 17 07:41:49 Hi yocto.. Jul 17 08:34:03 RP, we created a pull request for bitbake: https://github.com/openembedded/bitbake/pull/6 . Will this get treated or is it absolutely necessary to post to the mailinglist? Jul 17 08:42:56 Denwid: I had no idea it was there. It needs to go to the mailing list really Jul 17 08:44:26 RP, I just posted it this morning. We will sind it to the mailinglist in that case. Thank you! Jul 17 08:49:43 RP: I've just sent reply to test-dependencies report with warnings from insane_qa check Jul 17 08:50:11 but I need to start test-dependencies build again, because it run out of space.. Jul 17 09:20:32 JaMa: sorry, no time yet to test, it's just about adding DEPENDS = "klibc" at the end of the klibc-utils_2.0.3.bb Jul 17 09:20:54 redefining there Jul 17 09:21:34 this should remove that bunch of warnings Jul 17 09:25:53 I'll send 2.0.4 asap Jul 17 09:30:50 I'm trying to compile a Yocto image for Wandboard. I have the image booting but all GTK apps have empty menus Jul 17 09:31:12 does anyone know what package I might be missing (font/theme?) for GTK to give me menus? Jul 17 09:31:43 here are the GTK packages I have installed currently: http://pastebin.com/cYkbd7uS Jul 17 09:32:44 IceWewe: try installing some fonts, like liberation-fonts Jul 17 09:33:03 or running an app in a terminal so you see any warnings Jul 17 09:33:09 liberation-fonts-1.04-r4.cortexa9hf_vfp_neon Jul 17 09:33:53 the terminal just shows "GdkPixbuf-CRITICAL **: gdk_pixbuf_get_n_channels: assertion 'GDK_IS_PIXBUF (pixbuf)' failed Jul 17 09:34:18 I've tried strace but it just shows: Jul 17 09:34:20 write(2, "\n(deadbeef:1137): GdkPixbuf-CRIT"..., 110) = 110 Jul 17 09:34:20 --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x2} --- Jul 17 09:34:21 write(2, "Segmentation Fault\n", 19) = 19 Jul 17 09:34:50 sounds like your gdk-pixbuf loaders are not installed Jul 17 09:35:36 aha Jul 17 09:35:40 yes I only have a couple installed Jul 17 09:36:24 what ones? Jul 17 09:36:38 run gdk-pixbuf-query-loaders Jul 17 09:38:09 gdk-pixbuf-2.30.3-r0.cortexa9hf_vfp_neon Jul 17 09:38:09 gdk-pixbuf-loader-xpm-2.30.3-r0.cortexa9hf_vfp_neon Jul 17 09:38:10 gdk-pixbuf-loader-gif-2.30.3-r0.cortexa9hf_vfp_neon Jul 17 09:38:45 you probably won't need those ones Jul 17 09:38:56 I installed the remaining ones Jul 17 09:38:59 hold on I'll pastebin Jul 17 09:39:15 http://pastebin.com/q0JAqQhk Jul 17 09:39:16 you need the png loader for icons to work Jul 17 09:39:18 still seg faulting Jul 17 09:39:31 I don't have a png loader package built... Jul 17 09:39:41 you should probaby find out why Jul 17 09:40:24 is this daisy/1.6? Jul 17 09:40:39 yes Jul 17 09:40:41 *sigh* Jul 17 09:40:46 I didn't specify it in the packageconfig Jul 17 09:40:47 derp Jul 17 09:41:00 oh you've been overriding the packageconfig Jul 17 09:41:06 yeah in that case, don't forget to enable png ;) Jul 17 09:42:31 yeah. damn it. Jul 17 09:42:34 thanks :) Jul 17 09:43:04 I wonder if that will solve the text missing too Jul 17 09:44:05 its possible the menus were scaling to the height of the icons, which was 0 Jul 17 09:44:39 what about menu items that don't have an icon? is there really nothing there or is it just a transparent icon? Jul 17 09:44:45 I'm trying to compile deadbeef (audio player) Jul 17 09:45:01 although the missing menus affects other apps too (like mirodi) Jul 17 09:45:04 midori* Jul 17 09:45:39 no icon is really no icon Jul 17 09:49:27 woo! installing the png loader was enough to get deadbeef to play music :D Jul 17 09:49:34 except the mystery of the empty menus continues Jul 17 09:51:38 run xrandr and xdpyinfo, get the dpi values they report Jul 17 09:51:42 (and/or screen size) Jul 17 09:57:44 rburton: http://pastebin.com/ifYMSHXe Jul 17 11:35:27 hi yocto i am compiled libnfc 1.5.1 for RFID and i installed well and pn533 driver also enabled even i am getting the following error "root@beaglebone:~# nfc-list Jul 17 11:35:27 nfc-list uses libnfc 1.5.1 (r) Jul 17 11:35:27 [ 185.842462] usb 1-1: usbfs: interface 0 claimed by pn533 while 'nfc-list' sets config #1No NFC device found. " how to solve this error. Jul 17 11:59:07 any one can help me please.. Jul 17 12:01:27 elinuxer: have you blacklisted pn533 and nfs modules ? Jul 17 12:02:11 elinuxer: please have a look at this link.. It seems to be dealing with the same problem: http://www.libnfc.org/community/topic/668/solved-scl3711-interface-0-claimed-by-pn533-nfclist-sets-conf/ Jul 17 12:19:11 what is the option to install recursively everything in a dir : install -? Jul 17 14:07:46 can someone confirm that yocto-bsp creates meta-bsp-name in /build/meta-bsp-name ? documentatin says different Jul 17 14:09:54 microd: afaik it puts it under the current directory by default; if that happens to be "build" when you run it, then that's where it'll be placed Jul 17 14:11:55 bluelightning: if i run it in toplevel dir (where it should be placed) it says couldn't find BBLAYERS in bitbake -e, did i miss sth? Jul 17 14:13:07 microd: you can do two things - 1) move the dir afterwards or 2) use the -o option to "yocto-bsp create" to specify the output dir Jul 17 14:14:30 bluelightning: ok, move it afterwards is good enough for me Jul 17 14:49:30 Hey all Jul 17 14:50:52 if Ive got a recipe to build an out of tree kernel mod (eg hello-mod) and I also support to kernel flavours via PREFERRED_PROVIDER, can I have two source directories that get picked up on base on kernel version much in the same way you can with machine name? Jul 17 15:32:47 I am debugging a recipe that determines the native python version by running /usr/bin/python. How should a recipe pickup the native version instead? Jul 17 15:33:06 ^ i.e. the Yocto-built native pyton recipe Jul 17 15:34:03 inherit pythonnative at a minimum Jul 17 15:44:11 kergoth: that's what I did already. How is the python in native sysroot supposed to be picked up? Through fakeroot or PATH setting? Jul 17 15:44:31 read pythonnative.bbclass. Jul 17 15:47:35 kergoth: thanks. I currently have a single recipe for cross and native, I'm building OmniORB. Would this change require to create a specific -native recipe/ Jul 17 15:47:42 / = ? Jul 17 15:48:21 hi, I am having a problem with KERNEL_MODULE_AUTOLOAD when it is used together with overrides: Jul 17 15:48:33 In short, I have to .bbappends to the kernel, each adding new modules to the list. Jul 17 15:48:53 One of them, though, using an override with the architecture. This one seems to override completely the previous contents of the variable Jul 17 15:49:26 joseppc: you probably want KERNEL_MODULE_AUTOLOAD_append_machinename = ... rather than KERNEL_MODULE_AUTOLOAD_machinename = Jul 17 15:49:54 bluelightning: tried that too += _append before and after machinename, same thing Jul 17 15:50:10 I tried to track how the variable changes Jul 17 15:50:11 joseppc: += will definitely not work in conjunction with overrides Jul 17 15:50:19 not the way you expect anyway Jul 17 15:51:10 bluelightning: aha, += is used in the layer I am using (meta-intel) Jul 17 15:51:43 joseppc: that in itself is not a problem, it's when an override is used in conjunction with += Jul 17 15:52:07 bluelightning: where can I read more about this? Jul 17 15:52:09 the result will basically be the same as = except a leading space will be added to the value Jul 17 15:52:13 the bitbake manual Jul 17 15:52:28 www.yoctoproject.org/docs/current/bitbake-user-manual/bitbake-user-manual.html Jul 17 15:52:53 bluelightning: only when used in conjuntion with overrides? ok Jul 17 15:53:05 yes Jul 17 15:53:06 likewise: no Jul 17 15:53:28 bluelightning: I'll try with _append (again), and report back to make sure I didn't make a mistake before Jul 17 15:53:32 bluelightning: thanks Jul 17 15:53:51 bluelightning: the symptoms I see are very much how you describe it Jul 17 15:54:26 I tracked how the variable changes and got this: http://fpaste.org/118783/ Jul 17 15:54:30 joseppc: when using _append don't forget to add a leading space to the value you're appending, or you may get items right next to eachother e.g. "a bc" instead of "a b c" Jul 17 15:54:46 bluelightning: yes, good reminder Jul 17 15:59:19 bluelightning: about that last thing, the manual seems to forget the leading space :) Jul 17 16:01:01 kergoth: thanks Jul 17 16:01:33 kergoth: If a package builds it's own cross-build-tools, the native class must be inherited? Jul 17 16:02:52 likewise: no Jul 17 16:03:26 likewise: eg mesa, which builds some tools using CC_FOR_BUILD and then runs them to generate code, and then uses CC to build that code Jul 17 16:04:28 bluelightning: same thing with _append_arch apparently Jul 17 16:07:34 rburton: but is that logic in the original package build files, or in Yocto/OE recipe meta-data? Jul 17 16:08:12 likewise: believe it or not, upstream Jul 17 16:08:23 the _FOR_BUILD forms are sort-of standardised Jul 17 16:08:37 rburton: that's the exception then for most packages in OE/Yocto still. Jul 17 16:09:11 rburton: I am already happy when the upstream package does not assume to be built to run on its built-host Jul 17 16:09:14 likewise: sure. but you can do it yourself from a do_compile_prepend. Jul 17 16:09:38 (you only need native if you actually need to build the entire recipe native, not just a single tool) Jul 17 16:09:48 rburton: yes, but I think the neatest way is when we support cross-compiling both for the native built host as the cross target host, using the same recipe Jul 17 16:10:17 then you have to patch the sources to find the tools you've installed Jul 17 16:11:00 see eg pango which builds a tool in a do_compile_prepend Jul 17 16:11:14 rburton: thanks, will look at pango Jul 17 16:11:46 its not pretty thanks to the flags it needs, but the basic gist is to just make it using the right compiler, and then the build won't re-make it using the cross compiler Jul 17 16:13:34 bluelightning: ah sorry, scratch that, it did work as you said Jul 17 16:17:44 rburton, someone just sent a list I am on a link to something on facebook Jul 17 16:19:29 Crofton|work: chemical fire isn't good enough Jul 17 16:19:39 heh Jul 17 16:20:03 in all fairness, it wa a link to something funny, but even funnier after your retweet about crap on fb :) Jul 17 16:22:27 the good thing about facebook is that you don't get 20 page word documents anymore for a bad joke Jul 17 16:23:12 ... but I'm sure if you wanted to you could print out 'facebook' as a PDF for later.. ;) Jul 17 16:23:29 fray: paperlater.com Jul 17 16:56:56 there *are* devs on faceplant... they're just showing off baby pics like everyone else... Jul 17 16:57:15 eg, the gentoo lady with blue hair Jul 17 18:29:50 RP: maybe there is something wrong with our subversion-native (like http:// disabled?) Jul 17 18:29:53 ERROR: Fetcher failure: Fetch command failed with exit code 1, output: Jul 17 18:29:56 svn: E170000: Unrecognized URL scheme for 'https://svn.enlightenment.org/svn/e/OLD/edb' Jul 17 18:30:00 OE qemux86@ ~/build/oe-core $ svn co https://svn.enlightenment.org/svn/e/OLD/edb Jul 17 18:30:00 A edb/COPYING-PLAIN Jul 17 18:30:00 A edb/Makefile.am Jul 17 18:30:02 ... Jul 17 18:30:55 OE qemux86@ ~/build/oe-core $ tmp-eglibc/sysroots/x86_64-linux/usr/bin/svn co https://svn.enlightenment.org/svn/e/OLD/edb Jul 17 18:30:58 svn: E170000: Unrecognized URL scheme for 'https://svn.enlightenment.org/svn/e/OLD/edb' Jul 17 18:32:33 last commit is from you and says that neon support was dropped Jul 17 18:36:07 there is no serf recipe and neon is still in DEPENDS :/ Jul 17 19:11:02 JaMa: I was thinking in target context when I thought that wasn't much of an issue. I'll get that sorted, sorry Jul 17 19:33:03 So, I'm messing with tunings, and I want to do a thing where I have two tunings which are self-contained and can be used, or can use both with one being a multilib. Rather than having a single tuning file which always defines both. Jul 17 19:33:36 This does not quite work; most noticably, even apart from warnings about double-including x86/arch-x86.inc, TUNE_ARCH ends up set wrong. Jul 17 19:33:43 What I sort of want here is an idempotent include. Jul 17 19:37:34 I think the default assumption has been that you would have a single base tuning file for a chip which would define all of its available tunings, and thus that file is the only one that includes the arch file. Jul 17 19:38:08 For the prebuilt binary toolchain case, it sort of makes sense to have a tuning file per prebuilt library set, but then you could end up with, say, one for i586, one for i686, and one for x86-64. Jul 17 19:38:14 the original assumption was there was an 'arch' file that setup the basic architecture parameters.. but there could be multiple tune files that setup specific core properties.. Jul 17 19:38:28 But then if those are to work individually, you end up wanting to include more than one tune file, each of which includes the arch file, and then you have double-includes. Jul 17 19:38:54 I think there is a bug in the ia32 arch that the TUNE_ARCH is added over and over for each include.. but I'm not sure how to fix it Jul 17 19:39:12 That wouldn't be too bad, you could just add TUNE_ARCH = "" to the top... Jul 17 19:39:18 But you'd still get the warnings about duplicate inclusion. Jul 17 19:39:31 ya, I think that is a different issue.. but perhaps not.. Jul 17 19:39:40 I don't know if RP or anyone else familiar with that part of bitbake can comment Jul 17 19:40:12 Well, the duplicate inclusion is what causes the .= assignments to result in two copies of the arch being prepended to something. Jul 17 19:40:14 if there was a way to say "include this, if it hasn't already previously been included" that would work for me Jul 17 19:40:41 RP: I think that even on target people need https?:// support Jul 17 20:05:36 I just met a sales guy for a company that sells custom tablets based on bay-trail. He hadn't heard of yocto but said he'd pass the tip on to their engineers. Jul 17 20:05:47 What's a good link for getting started with yocto as an OEM? Jul 17 20:06:46 ecdhe: this is a hard question Jul 17 20:07:03 I mean, the homepage... Jul 17 20:07:09 but any other advice? Jul 17 20:07:11 ecdhe: the YP is very nice for them but the documentation would be the same for them and all other people Jul 17 20:07:49 ecdhe: depends if they want a fast overview or in depth doc Jul 17 20:07:56 It took me a couple of weeks to figure out the difference between yocto, poky, openembedded, bsps, etc... Jul 17 20:08:01 ecdhe depends on what they want to do and what processors it's based on.. Jul 17 20:08:05 ecdhe: for in depth, the Documentation is the right place Jul 17 20:08:23 in the case of bay-trail, it's Intel.. if they want "Linux" (not android) then this YP is certainly a possibility.. Jul 17 20:08:33 ecdhe: for fast, check http://bit.ly/1neUtSO Jul 17 20:08:37 I know Intel has a sales and marketing channel for Android, Yocto Project and other things Jul 17 20:08:46 but the place to likely start is just yoctoproject.org Jul 17 20:09:09 As a potential purchaser of hardware, we want this OEM to furnish a basic booting distro that we can then modify. Jul 17 20:09:19 That probably means a bsp layer. Jul 17 20:09:37 yup.. there is (was?) an Intel baytrail BSP at one point Jul 17 20:10:23 I'm not seeing it in meta-intel right now.. (I don't remember how new/old the baytrail is) Jul 17 20:10:47 meta-intel layer: öhttp://git.yoctoproject.org/cgit/cgit.cgi/meta-intel/tree/ Jul 17 20:31:51 JaMa: completely agreed on the http business, don't know what I was thinking :/ Jul 17 20:32:22 JaMa: I just about have serf building Jul 17 20:38:14 JaMa: http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/t222&id=478e74b059008b5bc0f5edb43b797e08bee3cc14 and preceding patch should fix Jul 17 20:38:44 * RP notes missing patch headers before sgw_ reminds me Jul 17 20:45:14 JaMa: my fetch errors seem resolve now btw, thanks if that was something you tweaked :) Jul 17 20:57:06 RP: the fetch errors were caused by svn-native :) Jul 17 20:57:18 RP: the old svn repo seems still running Jul 17 21:00:19 Sanity check: Does anyone think it would likely break anything if "require pathname.inc" were idempotent? Jul 17 21:00:59 Quick testing hasn't revealed any obvious disasters from it, anyway. Jul 17 21:04:02 JaMa: proves serf is working I guess :) Jul 17 21:04:56 seebs: classes already are with inherit iirc Jul 17 21:05:03 Classes are, yes. Requires aren't. Jul 17 21:05:12 seebs: didn't we make multiple requires a fatal error? Jul 17 21:05:20 e.g., "require conf/machine/include/ia32/arch-x86.inc" Jul 17 21:05:27 They are currently a non-fatal error. Jul 17 21:05:55 What this comes out of in my case is having a set of self-contained tuning files which correspond to specific prebuilt binary multilibs. Jul 17 21:06:04 seebs: personally, I think multiple includes/requires should be just an error Jul 17 21:06:07 i.e. don't do that Jul 17 21:06:29 Well, that's the other option, but I've spent a while trying to find a way around it and come up with nothing viable. Jul 17 21:06:46 RP, the issue is multilib tune files.. Jul 17 21:06:50 What I ideally want is: (1) the ability to have several tuning files which you can use individually for something (2) a way to have a thing use two of those tunes. Jul 17 21:07:02 Each tuning file has to include arch-x86.inc or it can't be used on its own. Jul 17 21:07:03 each tune file includes the general arch tuning.. I'm not sure how to structure it differently Jul 17 21:07:22 If you have two tunes, you then include arch-x86.inc twice. Which breaks things, although in a fixable way, but produces a warning. Jul 17 21:08:02 if it silently "works", it means the user isn't getting what they expected wrt ordering in one case Jul 17 21:08:15 include order is sadly important Jul 17 21:08:26 In this particular case, the ordering doesn't matter. Jul 17 21:08:53 At least, I'm pretty sure it doesn't; I think you can include it before any of the tunes or after any of them or between them, and nothing changes. As long as it's only picked up once. Jul 17 21:08:57 seebs: "particular case" Jul 17 21:09:01 Yeah. Jul 17 21:09:31 Hmm. Alternatively, maybe have a thing other than include/require for "require-if-not-yet-required". Jul 17 21:09:48 Because without it, I can't see any way to have things which can be used *either* separately or together. Jul 17 21:10:12 ya, somehow this arch tune needs to be included (once).. no matter how many 'tunes' for an arch are needed.. Jul 17 21:11:22 I think right now it may turn out that the only option is to have a single tune-foo.inc that covers all of the related tunes that could conceptually be in use at once on a given chip. Jul 17 21:11:58 that is effectively how the tune pieces were structured Jul 17 21:12:07 problem is that could require larger config files and break some existign BSPs Jul 17 21:12:31 I don't have a good answer but changing the way that operator works is not a good idea from my perspective, we put that warning in after real world bugs Jul 17 21:13:04 I'm also less than keen on another new operator Jul 17 21:13:08 I think a reasonable example of the problem would be wanring 'i586' 32-bit binaries, but wanting core2 64-bit Jul 17 21:13:11 Yeah. Jul 17 21:13:16 or core2 32-bit, and corei7 64-bit Jul 17 21:13:23 ... That is in fact exactly the one that bit me. Jul 17 21:13:24 a bit unusual, but it should work.. Jul 17 21:13:45 second you include both it breaks Jul 17 21:14:09 the only alternative I see is to put in a key to the 'arch' include, if the key is already set we avoid the require Jul 17 21:14:22 but I'm not sure if that is a good idea, and if it is exactly how to do that Jul 17 21:14:48 Well, hmm. The way the oe-core core2 tuning works is that it pulls in tune-i586.inc. Jul 17 21:15:13 We can't quite do that in ours, because we have (yay historical reasons) both tune-i586.inc and tune-i686.inc. Jul 17 21:15:18 And they each have to work okay when taken on their own... Jul 17 21:15:30 seebs: but can't i686 include i586? Jul 17 21:15:42 the idea was all tunes on a given chip are available Jul 17 21:16:00 *pondering* So the idea would be, core2 includes i686 which includes i586. Jul 17 21:16:17 seebs: that is the way oe-core does things like this (see the arm mess) Jul 17 21:16:21 Yeah. Jul 17 21:16:37 This is complicated significantly by a binary multilib compiler which drastically narrows the field of meaningfully-available tunings. Jul 17 21:17:09 seebs: you can unset variables? :) Jul 17 21:17:35 So what we need is a complete ordering of the available tunes, such that you can always pick the most-inclusive tune file, which includes one of the others, which includes one of the otehrs, and so on. Jul 17 21:18:11 Well, we don't care that much about extra things in the available tunes list, because we have whitelisting to eat those. Jul 17 21:19:27 *pondering* I'm not entirely sure it's reliably possible to develop a proper ordering for tunes that always lets you have the meaningful tunes available, but I'm also not sure it's *not* possible. Jul 17 21:20:16 RP I thought there was a way previously to optional require/include something using variable syntax.. Jul 17 21:20:39 is there an example of the format? The sutff I've tried so far usually results in an error of missing (blank) or missing '' or "" Jul 17 21:20:45 so I'm obviously doing something wrong Jul 17 21:26:05 ahh it's 'inherit' that permits blanks.. Jul 17 21:26:23 would it be reasonable to extend that to require/include to permit blanks? Jul 17 21:26:45 fray: possibly I guess Jul 17 21:27:10 then we could do a dynamic include, if it's already been run then avoid it Jul 17 22:49:02 RP: sgw will remind you about few missing SOB lines e.g. in serf norpath.path Jul 17 22:58:10 goodness **** ENDING LOGGING AT Fri Jul 18 03:00:00 2014