**** BEGIN LOGGING AT Mon Nov 28 02:59:57 2011 Nov 28 09:12:38 morning all Nov 28 10:47:35 Hello ppl Nov 28 10:48:40 while doin' the quickstart on an ubuntu system, not all required system deps were installed by the ubuntu specific apt-get install command. I needed perl's XML::Parser Nov 28 10:49:16 and apt-native_0.7.14.bb is failing with a missing librarty Nov 28 10:49:20 *library Nov 28 10:49:28 anyone knows what's this about? Nov 28 10:49:50 ERROR: oe_libinstall: unable to locate shared library Nov 28 10:49:53 specifically Nov 28 10:50:06 but the log doesn't show that much more :\ Nov 28 11:11:54 sgw: RP__: can you handle the xorg patch to allow the regular xorg-xserver (not lite) to work with dga and then I can use vesa? Nov 28 11:13:31 otavio: I'm trying to figure out if there is an alternative there, I'm not that happy we need have the hard requirement on dga :/ Nov 28 11:17:28 RP__: me neither but I'd prefer this working until we get an alternative Nov 28 11:17:38 RP__: vesa is broken for now Nov 28 11:22:11 RP__: hi, any reply to libsdl patches? I would like to close it before sending new pull request :). Nov 28 11:23:45 JaMa|Off: I don't think I ever reviewed them, saul did... Nov 28 11:27:17 ok, you've commented on PACKAGECONFIG_virtclass-nativesdk case in them, but ok, I'll wait for sgw Nov 28 11:28:05 hmm, I'm building edison on an amd64 machine with no display at all. I'd like to be able to run qemu from a i686 machine, however, the "setup" process did not create a tmp/sysroots/i686-linux it created a tmp/sysroots/x86_64-linux Nov 28 11:28:11 how can I overcome that? Nov 28 11:30:46 SDKMACHINE ?= "i686 Nov 28 11:30:47 ? Nov 28 12:28:26 s0undt3ch: If you build meta-toolchain for SDHMACHINE i686, that will have a qemu binary you can use Nov 28 12:31:52 RP__: so, my distro's qemu binary is not usable? Nov 28 13:49:13 s0undt3ch: There are other things as well as the qemu binary that are needed Nov 28 15:50:33 the qt4 recipe on yocto, is that qt-emmbedded previous qtopia? or qt4-x11? Nov 28 16:12:56 s0undt3ch: we have both Nov 28 16:13:05 bluelightning: great Nov 28 16:13:16 bluelightning: is there an image with qt-embedded? Nov 28 16:13:23 yep Nov 28 16:13:55 qt4e-demo-image Nov 28 16:14:12 bluelightning: Thanks! Nov 28 16:14:19 no worries Nov 28 16:14:19 * s0undt3ch building Nov 28 16:18:15 I've cloned the poky git Nov 28 16:18:21 what's the stable tag? Nov 28 16:18:29 so I can branch off my custom stuff? Nov 28 16:18:46 edison-6.0 tag? Nov 28 16:18:53 that's the release tag Nov 28 16:19:01 there's the release branch, edison Nov 28 16:19:11 bluelightning: that's stable right? Nov 28 16:19:27 yes edison is the latest stable release Nov 28 16:19:33 k, Thanks Nov 28 16:19:46 we are in the process of putting together a new point release so selected patches will be added to the edison branch Nov 28 16:19:52 in the near future Nov 28 16:20:32 btw I'd recommend for most customisations you apply them using bbappends in a separate layer Nov 28 16:20:51 unless they are bugfixes you wish to submit, of course Nov 28 16:20:55 good to know this project is well alive. I got aquainted with it through angstom, which apears to be kind of dead Nov 28 16:21:09 well, I'm not that into the layers stuff Nov 28 16:21:13 yet Nov 28 16:21:27 so, I should instead create my own layer? Nov 28 16:21:30 angstrom is still definitely alive, it's probably got less people working on it though Nov 28 16:21:39 we do share the core metadata though Nov 28 16:21:56 yes I would recommend that if you're planning on doing customisation Nov 28 16:21:59 support seems way more present on yocto Nov 28 16:22:01 it's pretty straightforward Nov 28 16:22:56 just create yourself a new directory for the layer, add a conf/layer.conf file (you can use the file in meta-yocto/conf/ as an example), and then add that dir to your build/conf/bblayers.conf file Nov 28 16:24:09 then, if you want to make some customisations to recipe, just create the appropriate dir structure and use a bbappend for each recipe you wish to customise Nov 28 16:25:36 ok, I'll see if I can get that done without any issues :) Nov 28 16:25:37 e.g. to customise base-files_3.0.14.bb you'd mkdir recipes-core/base-files then add a recipes-core/base-files/base-files_3.0.14.bbappend with your stuff in it Nov 28 16:34:03 bluelightning: do i just add the parent dir or do I have to add /meta Nov 28 16:34:44 there's no need for a meta subdir; it just expects to find a conf/layer.conf in the directory you specify Nov 28 16:34:55 that file tells it where to find everything else Nov 28 16:35:02 ok Nov 28 16:55:52 bluelightning: following http://www.google.pt/url?sa=t&rct=j&q=pyside+yocto&source=web&cd=2&ved=0CCMQFjAB&url=http%3A%2F%2Fwww.mail-archive.com%2Fopenembedded-core%40lists.openembedded.org%2Fmsg04367.html&ei=u7vTTu-HDIPO8QPI-InlAw&usg=AFQjCNGKqp5BKHos7V2TpvvpD2IUBL9Rdw&sig2=nXFpC_U_Usvhfyc_S46ABg I see that OE-core has pyside support, that's not in yocto currently right? Nov 28 16:56:48 s0undt3ch: judging by that it's in OE classic Nov 28 16:57:08 which is not what yocto uses? Nov 28 16:57:08 s0undt3ch: yocto includes oe-core, FYI Nov 28 16:57:22 hmm Nov 28 16:57:24 OE classic was the old structure where everything was in the same repo Nov 28 16:57:35 might that be portable? Nov 28 16:57:50 if you wanted to use pyside unless someone has already brought it over you'd need to do that yourself Nov 28 16:58:19 http://www.openembedded.org/wiki/OpenEmbedded-Core Nov 28 16:58:24 FYI ^ Nov 28 17:02:43 s0undt3ch: not too tricky to bring something across Nov 28 17:02:51 there's some info in the link above Nov 28 17:02:55 bluelightning: but nothing in http://cgit.openembedded.org/openembedded/tree/recipes/pyside is usable? ie the new "workflow" changed in a way that it can't be copied over? Nov 28 17:03:02 ah ok Nov 28 17:03:19 it can be copied over, it's just you may need to make some adjustments to the recipes Nov 28 17:03:39 ok, I'll see what can be done Nov 28 17:03:57 bluelightning: that would go into my new layer right? Nov 28 17:05:27 it can; it would be nice to make it available in a layer for everyone to use though Nov 28 17:06:01 of course you don't have to worry about that now, but it would be nice for the future Nov 28 17:06:53 bluelightning: yeah, if it's usable, I'll try to make it public Nov 28 17:49:46 ka6sox: hi, is it possible for us to remove edit restrictions from the oe wiki? http://lists.linuxtogo.org/pipermail/openembedded-devel/2011-November/036497.html Nov 28 17:49:57 argh wrong channel Nov 28 17:50:14 should have been #oe Nov 28 19:00:59 bluelightning: still around? Nov 28 19:01:09 s0undt3ch: yep Nov 28 19:01:30 bluelightning: I've created a /recipes-pyside with what was in that git repo Nov 28 19:01:42 however the .bb are not being found Nov 28 19:01:55 s0undt3ch: I think you need one subdir under that with the recipes in it Nov 28 19:02:05 i.e. recipes-pyside/pyside/*.bb Nov 28 19:02:23 bluelightning: http://paste.pocoo.org/show/514113/ Nov 28 19:02:26 ah Nov 28 19:02:52 or to update the layer.conf to match a different pattern Nov 28 19:03:33 that extra dir made it Nov 28 19:03:41 now I need to update the recipes Nov 28 19:03:48 ERROR: This recipe does not have the LICENSE field set (python-pyside-embedded) Nov 28 19:03:56 ERROR: Unable to parse /yokto/arms-project/recipes-pyside/pyside/python-pyside-embedded_1.0.2.bb: Exited with "1" Nov 28 19:04:16 s0undt3ch: right, yep, that field is now mandatory Nov 28 19:04:35 s0undt3ch: have a look at the bottom of http://www.openembedded.org/wiki/OpenEmbedded-Core for migration info Nov 28 19:05:02 long time ago I wrote a bit about bblayers that might help here as well Nov 28 19:05:05 http://sakrah.homelinux.org/blog/2010/11/bblayers-bbappend/ Nov 28 19:05:25 bluelightning: will do Nov 28 19:05:32 khem: Will read that too, Thanks Nov 28 19:11:41 khem: just posted a follow-up comment discussing FILESEXTRAPATHS and THISDIR Nov 28 19:12:11 I'm curious, why was THISDIR added, when FILE_DIRNAME existed in oe? just to try to make it more obvious? Nov 28 19:12:52 not sure, RP__ might know Nov 28 19:13:22 * bluelightning heads home Nov 28 19:20:06 hmm, do I need to provide the LICENSE files myself? Nov 28 19:20:19 the qt4 recipes don't seem to have those files and nothing fails Nov 28 19:20:40 I copied the license field and their checksums and it's failing Nov 28 19:21:18 you need to have proper checksums for tats Nov 28 19:21:20 tars Nov 28 19:21:39 remove them from recipe and then clean the recipe and do -cfetch again Nov 28 19:21:50 then bitbake will emit the ones you need Nov 28 19:21:58 copy them into recipe Nov 28 19:23:00 I hate when projects don't make proper use of acinclude.m4 Nov 28 19:23:19 bitbake -ccleanall will remove the downloaded tars if any Nov 28 19:24:00 kergoth: your hate should begin way earlier namely with the use of autonf at all Nov 28 19:24:30 that's a terrible name. we suffix other tasks with 'all' to mean 'run this against the dependencies', but that's not the meaning for cleanall Nov 28 19:24:41 heh Nov 28 19:25:38 right. may be destroy would be more destructive Nov 28 19:30:33 khem: LIC_FILES_CHKSUM = "file://LICENSE.LGPL;md5=fbc093901857fcd118f065f900982c24" Nov 28 19:30:46 where should the LICENSE.LGPL exist? Nov 28 19:31:13 the source code does not include that file Nov 28 19:32:17 you need a path from the root of the extracted source, usually somewhere like build/tmp/work/my-arch/my-package/my-package-source/ Nov 28 19:32:37 s0undt3ch: in top of srcdir Nov 28 19:33:13 s0undt3ch: it could be called something else lice LICENSE or COPYING Nov 28 19:33:22 ah Nov 28 19:33:23 ok Nov 28 19:33:25 looking Nov 28 19:33:25 if nothing is there you can get it from other files too Nov 28 19:33:40 s0undt3ch: it really depends on what licence the package has Nov 28 19:33:40 khem: and in that case include it in my layer? Nov 28 19:33:47 LGPL Nov 28 19:33:53 often you're looking for a COPYING file, or similar Nov 28 19:34:10 ok then there should be COPYING.LIB or something like that in srcdir Nov 28 19:35:03 hmm Nov 28 19:35:06 GPL!? Nov 28 19:35:25 v2 Nov 28 19:35:33 FYI COPYING Nov 28 19:37:25 bleh, bb.fetch2.FetchMethod.unpack has a lot of lame cruft in it :\ Nov 28 19:43:18 s0undt3ch: read that file it should state if its v2 or v3 Nov 28 20:17:53 damnit, this is irritating Nov 28 20:18:11 I have oe-core - meta-oe - my layer - Nov 28 20:18:23 the problem is I need to bbappend the kernel in one of the machine layers Nov 28 20:18:36 but if I do that, it will error out if I don't include that machine's layer in a particular build Nov 28 20:18:54 so now I have to add extra per-machine layers on top of the machine-specific upstream layers, or I need to fork them, neither of which is pleasant Nov 28 20:19:06 all because of the new bitbake "No recipes available for" fatal error Nov 28 20:19:44 * kergoth mutters and forks Nov 28 20:21:36 kergoth: so situation is that it parses recipes which it doesnt need to in a given run ? Nov 28 20:22:07 not sure what you mean by that. the problem is I have a bbappend which appends to a file in a layer that may or may not be in BBLAYERS in a given build Nov 28 20:23:07 oh so dangling bbappend Nov 28 20:23:40 this should be a fat warning imo but not error Nov 28 20:24:18 in this case, its the meta-ti lzo thing. the panda config uses it. so i fixed in a bbappend, and that just won't work unless I split it out into its own layer on top of meta-ti, which will make the user configuration slightly more annoying Nov 28 20:24:22 heh Nov 28 20:24:31 hmmm or may be there could be a variable which could state which layer it bbappends to ? Nov 28 20:24:53 hmmmm Nov 28 20:26:02 and this does not work when meta-ti is not in BBLAYERS right ? Nov 28 20:27:05 if its not there, then the .bb the bbappend corresponds to doesn't exist, so bitbake errors out Nov 28 20:29:40 right hmm I kind of like errors in general having done language work :) but this could mean that you cant have one layer which could be poking at multiple layers unless you use them all the time Nov 28 20:29:50 right, exactly Nov 28 20:29:52 your configuration must be really broad Nov 28 20:30:27 maybe there could be a way to mark your intentions somehow. "yes, I know the file this appends to is gone, and i don't give a crap, stop yelling at me" Nov 28 20:32:20 may be bitbake needs -pedantic option Nov 28 20:32:29 khem: well, like montavista, mentor sells an oe based product that the customer then uses to build *their* products, so it's sort of generic by definition -- a certain set of machines is likely supported vs not, but even so Nov 28 20:32:44 I understand totally Nov 28 20:32:56 * kergoth shrugs Nov 28 20:33:20 for this case it's a minor issue, I'll just go pester koen until this gets upstream and not worry about it Nov 28 20:33:29 but it got me thinking about it in general :) Nov 28 20:33:58 you have one version that targets a broad range of processors and you prefer to have one meta-mentor instead of meta-mentor-ti and so on Nov 28 20:34:06 yeah Nov 28 20:34:30 its a valid thing imo Nov 28 20:42:15 hmm, there's no vim, only vi? Nov 28 20:43:57 s0undt3ch: you must be joking or someone set alias vi=vim for you :) Nov 28 20:44:14 well inside qemu Nov 28 20:44:27 what I have is vi vim-tiny Nov 28 20:44:33 oh yes sure Nov 28 20:44:42 target rfs will have whats minimal Nov 28 20:44:55 unless you ask it to get rest of it Nov 28 20:45:12 hmm, how do I list available targets Nov 28 23:04:07 well, it looks like there is orphan code in image.bbclass Nov 28 23:04:15 make_zimage_symlink_relative () { Nov 28 23:04:47 in fact the symlink is missing... Nov 29 01:41:50 anyone know does bsp sugarbay support/contains LMS (AMT), SOL (AMT), TPM Driver and VT and AES-NI Drivers? how can i find them if they are there Nov 29 01:41:52 pls help **** ENDING LOGGING AT Tue Nov 29 02:59:57 2011