**** BEGIN LOGGING AT Mon Nov 28 02:59:57 2011
Nov 28 09:12:38 <RP__> morning all
Nov 28 10:47:35 <s0undt3ch> Hello ppl
Nov 28 10:48:40 <s0undt3ch> 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 <s0undt3ch> and apt-native_0.7.14.bb is failing with a missing librarty
Nov 28 10:49:20 <s0undt3ch> *library
Nov 28 10:49:28 <s0undt3ch> anyone knows what's this about?
Nov 28 10:49:50 <s0undt3ch> ERROR: oe_libinstall: unable to locate shared library
Nov 28 10:49:53 <s0undt3ch> specifically
Nov 28 10:50:06 <s0undt3ch> but the log doesn't show that much more :\
Nov 28 11:11:54 <otavio> 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 <RP__> 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 <otavio> RP__: me neither but I'd prefer this working until we get an alternative
Nov 28 11:17:38 <otavio> RP__: vesa is broken for now
Nov 28 11:22:11 <JaMa|Off> RP__: hi, any reply to libsdl patches? I would like to close it before sending new pull request :).
Nov 28 11:23:45 <RP__> JaMa|Off: I don't think I ever reviewed them, saul did...
Nov 28 11:27:17 <JaMa|Off> ok, you've commented on PACKAGECONFIG_virtclass-nativesdk case in them, but ok, I'll wait for sgw
Nov 28 11:28:05 <s0undt3ch> 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 <s0undt3ch> how can I overcome that?
Nov 28 11:30:46 <s0undt3ch> SDKMACHINE ?= "i686
Nov 28 11:30:47 <s0undt3ch> ?
Nov 28 12:28:26 <RP__> s0undt3ch: If you build meta-toolchain for SDHMACHINE i686, that will have a qemu binary you can use
Nov 28 12:31:52 <s0undt3ch> RP__: so, my distro's qemu binary is not usable?
Nov 28 13:49:13 <RP__> s0undt3ch: There are other things as well as the qemu binary that are needed
Nov 28 15:50:33 <s0undt3ch> the qt4 recipe on yocto, is that qt-emmbedded previous qtopia? or qt4-x11?
Nov 28 16:12:56 <bluelightning> s0undt3ch: we have both
Nov 28 16:13:05 <s0undt3ch> bluelightning: great
Nov 28 16:13:16 <s0undt3ch> bluelightning: is there an image with qt-embedded?
Nov 28 16:13:23 <bluelightning> yep
Nov 28 16:13:55 <bluelightning> qt4e-demo-image
Nov 28 16:14:12 <s0undt3ch> bluelightning: Thanks!
Nov 28 16:14:19 <bluelightning> no worries
Nov 28 16:14:19 * s0undt3ch building
Nov 28 16:18:15 <s0undt3ch> I've cloned the poky git
Nov 28 16:18:21 <s0undt3ch> what's the stable tag?
Nov 28 16:18:29 <s0undt3ch> so I can branch off my custom stuff?
Nov 28 16:18:46 <s0undt3ch> edison-6.0 tag?
Nov 28 16:18:53 <bluelightning> that's the release tag
Nov 28 16:19:01 <bluelightning> there's the release branch, edison
Nov 28 16:19:11 <s0undt3ch> bluelightning: that's stable right?
Nov 28 16:19:27 <bluelightning> yes edison is the latest stable release
Nov 28 16:19:33 <s0undt3ch> k, Thanks
Nov 28 16:19:46 <bluelightning> 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 <bluelightning> in the near future
Nov 28 16:20:32 <bluelightning> btw I'd recommend for most customisations you apply them using bbappends in a separate layer
Nov 28 16:20:51 <bluelightning> unless they are bugfixes you wish to submit, of course
Nov 28 16:20:55 <s0undt3ch> 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 <s0undt3ch> well, I'm not that into the layers stuff
Nov 28 16:21:13 <s0undt3ch> yet
Nov 28 16:21:27 <s0undt3ch> so, I should instead create my own layer?
Nov 28 16:21:30 <bluelightning> angstrom is still definitely alive, it's probably got less people working on it though
Nov 28 16:21:39 <bluelightning> we do share the core metadata though
Nov 28 16:21:56 <bluelightning> yes I would recommend that if you're planning on doing customisation
Nov 28 16:21:59 <s0undt3ch> support seems way more present on yocto
Nov 28 16:22:01 <bluelightning> it's pretty straightforward
Nov 28 16:22:56 <bluelightning> 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 <bluelightning> 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 <s0undt3ch> ok, I'll see if I can get that done without any issues :)
Nov 28 16:25:37 <bluelightning> 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 <s0undt3ch> bluelightning: do i just add the parent dir or do I have to add <my-customizatiosn>/meta
Nov 28 16:34:44 <bluelightning> 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 <bluelightning> that file tells it where to find everything else
Nov 28 16:35:02 <s0undt3ch> ok
Nov 28 16:55:52 <s0undt3ch> 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 <bluelightning> s0undt3ch: judging by that it's in OE classic
Nov 28 16:57:08 <s0undt3ch> which is not what yocto uses?
Nov 28 16:57:08 <bluelightning> s0undt3ch: yocto includes oe-core, FYI
Nov 28 16:57:22 <s0undt3ch> hmm
Nov 28 16:57:24 <bluelightning> OE classic was the old structure where everything was in the same repo
Nov 28 16:57:35 <s0undt3ch> might that be portable?
Nov 28 16:57:50 <bluelightning> 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 <bluelightning> http://www.openembedded.org/wiki/OpenEmbedded-Core
Nov 28 16:58:24 <bluelightning> FYI ^
Nov 28 17:02:43 <bluelightning> s0undt3ch: not too tricky to bring something across
Nov 28 17:02:51 <bluelightning> there's some info in the link above
Nov 28 17:02:55 <s0undt3ch> 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 <s0undt3ch> ah ok
Nov 28 17:03:19 <bluelightning> it can be copied over, it's just you may need to make some adjustments to the recipes
Nov 28 17:03:39 <s0undt3ch> ok, I'll see what can be done
Nov 28 17:03:57 <s0undt3ch> bluelightning: that would go into my new layer right?
Nov 28 17:05:27 <bluelightning> it can; it would be nice to make it available in a layer for everyone to use though
Nov 28 17:06:01 <bluelightning> of course you don't have to worry about that now, but it would be nice for the future
Nov 28 17:06:53 <s0undt3ch> bluelightning: yeah, if it's usable, I'll try to make it public
Nov 28 17:49:46 <bluelightning> 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 <bluelightning> argh wrong channel
Nov 28 17:50:14 <bluelightning> should have been #oe
Nov 28 19:00:59 <s0undt3ch> bluelightning: still around?
Nov 28 19:01:09 <bluelightning> s0undt3ch: yep
Nov 28 19:01:30 <s0undt3ch> bluelightning:  I've created a <my-layer>/recipes-pyside with what was in that git repo
Nov 28 19:01:42 <s0undt3ch> however the .bb are not being found
Nov 28 19:01:55 <bluelightning> s0undt3ch: I think you need one subdir under that with the recipes in it
Nov 28 19:02:05 <bluelightning> i.e. recipes-pyside/pyside/*.bb
Nov 28 19:02:23 <s0undt3ch> bluelightning: http://paste.pocoo.org/show/514113/
Nov 28 19:02:26 <s0undt3ch> ah
Nov 28 19:02:52 <incandescant> or to update the layer.conf to match a different pattern
Nov 28 19:03:33 <s0undt3ch> that extra dir made it
Nov 28 19:03:41 <s0undt3ch> now I need to update the recipes
Nov 28 19:03:48 <s0undt3ch> ERROR: This recipe does not have the LICENSE field set (python-pyside-embedded)
Nov 28 19:03:56 <s0undt3ch> 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 <bluelightning> s0undt3ch: right, yep, that field is now mandatory
Nov 28 19:04:35 <bluelightning> s0undt3ch: have a look at the bottom of  http://www.openembedded.org/wiki/OpenEmbedded-Core for migration info
Nov 28 19:05:02 <khem> long time ago I wrote a bit about bblayers that might help here as well
Nov 28 19:05:05 <khem> http://sakrah.homelinux.org/blog/2010/11/bblayers-bbappend/
Nov 28 19:05:25 <s0undt3ch> bluelightning: will do
Nov 28 19:05:32 <s0undt3ch> khem: Will read that too, Thanks
Nov 28 19:11:41 <bluelightning> khem: just posted a follow-up comment discussing FILESEXTRAPATHS and THISDIR
Nov 28 19:12:11 <kergoth> 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 <bluelightning> not sure, RP__ might know
Nov 28 19:13:22 * bluelightning heads home
Nov 28 19:20:06 <s0undt3ch> hmm, do I need to provide the LICENSE files myself?
Nov 28 19:20:19 <s0undt3ch> the qt4 recipes don't seem to have those files and nothing fails
Nov 28 19:20:40 <s0undt3ch> I copied the license field and their checksums and it's failing
Nov 28 19:21:18 <khem> you need to have proper checksums for tats
Nov 28 19:21:20 <khem> tars
Nov 28 19:21:39 <khem> remove them from recipe and then clean the recipe and do -cfetch again
Nov 28 19:21:50 <khem> then bitbake will emit the ones you need
Nov 28 19:21:58 <khem> copy them into recipe
Nov 28 19:23:00 <kergoth> I hate when projects don't make proper use of acinclude.m4
Nov 28 19:23:19 <khem> bitbake -ccleanall <your-package> will remove the downloaded tars if any
Nov 28 19:24:00 <khem> kergoth: your hate should begin way earlier namely with the use of autonf at all
Nov 28 19:24:30 <kergoth> 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 <kergoth> heh
Nov 28 19:25:38 <khem> right. may be destroy would be more destructive
Nov 28 19:30:33 <s0undt3ch> khem: LIC_FILES_CHKSUM = "file://LICENSE.LGPL;md5=fbc093901857fcd118f065f900982c24"
Nov 28 19:30:46 <s0undt3ch> where should the LICENSE.LGPL exist?
Nov 28 19:31:13 <s0undt3ch> the source code does not include that file
Nov 28 19:32:17 <incandescant> 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 <khem> s0undt3ch: in top of srcdir
Nov 28 19:33:13 <khem> s0undt3ch: it could be called something else lice LICENSE or COPYING
Nov 28 19:33:22 <s0undt3ch> ah
Nov 28 19:33:23 <s0undt3ch> ok
Nov 28 19:33:25 <s0undt3ch> looking
Nov 28 19:33:25 <khem> if nothing is there you can get it from other files too
Nov 28 19:33:40 <khem> s0undt3ch: it really depends on what licence the package has
Nov 28 19:33:40 <s0undt3ch> khem: and in that case include it in my layer?
Nov 28 19:33:47 <s0undt3ch> LGPL
Nov 28 19:33:53 <incandescant> often you're looking for a COPYING file, or similar
Nov 28 19:34:10 <khem> ok then there should be COPYING.LIB or something like that in srcdir
Nov 28 19:35:03 <s0undt3ch> hmm
Nov 28 19:35:06 <s0undt3ch> GPL!?
Nov 28 19:35:25 <s0undt3ch> v2
Nov 28 19:35:33 <s0undt3ch> FYI COPYING
Nov 28 19:37:25 <kergoth> bleh, bb.fetch2.FetchMethod.unpack has a lot of lame cruft in it :\
Nov 28 19:43:18 <khem> s0undt3ch: read that file it should state if its v2 or v3
Nov 28 20:17:53 <kergoth> damnit, this is irritating
Nov 28 20:18:11 <kergoth> I have oe-core - meta-oe - my layer - <any number of machine layers, depending on what i'm targeting>
Nov 28 20:18:23 <kergoth> the problem is I need to bbappend the kernel in one of the machine layers
Nov 28 20:18:36 <kergoth> 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 <kergoth> 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 <kergoth> 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 <khem> kergoth: so situation is that it parses recipes which it doesnt need to in a given run ?
Nov 28 20:22:07 <kergoth> 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 <khem> oh so dangling bbappend
Nov 28 20:23:40 <khem> this should be a fat warning imo but not error
Nov 28 20:24:18 <kergoth> 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 <kergoth> heh
Nov 28 20:24:31 <khem> hmmm or may be there could be a variable which could state which layer it bbappends to ?
Nov 28 20:24:53 <kergoth> hmmmm
Nov 28 20:26:02 <khem> and this does not work when meta-ti is not in BBLAYERS right ?
Nov 28 20:27:05 <kergoth> if its not there, then the .bb the bbappend corresponds to doesn't exist, so bitbake errors out
Nov 28 20:29:40 <khem> 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 <kergoth> right, exactly
Nov 28 20:29:52 <khem> your configuration must be really broad
Nov 28 20:30:27 <kergoth> 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 <khem> may be bitbake needs -pedantic option
Nov 28 20:32:29 <kergoth> 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 <khem> I understand totally
Nov 28 20:32:56 * kergoth shrugs
Nov 28 20:33:20 <kergoth> 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 <kergoth> but it got me thinking about it in general :)
Nov 28 20:33:58 <khem> 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 <kergoth> yeah
Nov 28 20:34:30 <khem> its a valid thing imo
Nov 28 20:42:15 <s0undt3ch> hmm, there's no vim, only vi?
Nov 28 20:43:57 <khem> s0undt3ch: you must be joking or someone set alias vi=vim for you :)
Nov 28 20:44:14 <s0undt3ch> well inside qemu
Nov 28 20:44:27 <s0undt3ch> what I have is vi vim-tiny
Nov 28 20:44:33 <khem> oh yes sure
Nov 28 20:44:42 <khem> target rfs will have whats minimal
Nov 28 20:44:55 <khem> unless you ask it to get rest of it
Nov 28 20:45:12 <s0undt3ch> hmm, how do I list available targets
Nov 28 23:04:07 <ant____> well, it looks like there is orphan code in image.bbclass
Nov 28 23:04:15 <ant____> make_zimage_symlink_relative () {
Nov 28 23:04:47 <ant____> in fact the symlink is missing...
Nov 29 01:41:50 <loo> 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 <loo> pls help
**** ENDING LOGGING AT Tue Nov 29 02:59:57 2011