**** BEGIN LOGGING AT Thu Dec 08 02:59:57 2011 Dec 08 08:06:27 gm Dec 08 08:07:18 Hi eFfeM_work Dec 08 08:10:14 * khem sleeps Dec 08 08:34:31 good morning! Dec 08 08:55:13 mornin Dec 08 09:53:23 gm Dec 08 09:53:31 otavio: ping Dec 08 09:57:38 hi all Dec 08 10:07:35 pb_: gm Dec 08 10:20:52 hey likewise, pb_ Dec 08 10:20:54 likewise: hi Dec 08 10:20:59 gm all Dec 08 10:21:39 otavio: I saw you followed the meta-freescale repo at github, like me. You got iMX h/w? Dec 08 10:23:21 likewise: yes and I am starting working at improving it and adding iMX 28 support on it too Dec 08 10:29:08 otavio: ok, cool, I was planning on using it as a base for iMX53 Dec 08 10:40:57 morning all Dec 08 10:45:28 hi bluelightning Dec 08 12:30:38 wake up guys. Lunch break is over. Dec 08 12:37:30 calm down, it's almost friday... Dec 08 12:44:04 yes, I wanted to make sure everybody is in time for the weekend :) Dec 08 12:51:09 hi mickey_office Dec 08 12:56:37 hi pb_ Dec 08 14:18:02 hi likewise otavio fwiw I have a meta-mx53qsb which start to works on the MX53 QSB Dec 08 14:19:09 ericben: I just got my u-boot and kernel working, now trying to build codecs and everything. What is your status? Dec 08 14:19:24 likewise: 3D running last time I tested Dec 08 14:19:34 Did you test the codecs? Dec 08 14:19:46 likewise: that's the next thing on the todolist Dec 08 14:20:02 ericben: ok, are you aware of meta-freescale on github (well now you are :) Dec 08 14:20:09 likewise: now I'm aware of it Dec 08 14:21:10 can we join forces somehow, I hate all this fragmentation. Dec 08 14:21:15 I have a recipe for the codecs on i.MX27 so it should not be difficult to port to 51/53 (my primary platform is 51, 53 is the second one) Dec 08 14:21:48 ericben: meta-freescale builds the latest codecs (2.03) and GPU binary blob driver/lib, no issues during build here. Dec 08 14:22:29 well meta-freescale seems to have everything in good shape Dec 08 14:22:41 should have published my tree earlier Dec 08 14:22:47 but I wanted to find time to get the codecs running Dec 08 14:22:54 before publishing it Dec 08 14:23:05 ericben: hmm, not all, basically they are aiming for their equivalent OE-core of their LTIB release (2.6.35.3) Dec 08 14:23:26 The real nice stuff is Linaro 3.1, but they need some way to get the GPU binaries recompiled I think. Dec 08 14:23:52 Linaro kernel 3.1 I mean, the Freescale Landing Team of Linaro is now rushing for im53 upstreaming, however they lose codec compatibility... Dec 08 14:23:53 likewise: linaro-3.2 does'nt boot on my 51 (I tried yestyerday), still have to understand why Dec 08 14:24:21 ok, I'm launching a build of meta-freescale to test it Dec 08 14:24:25 my first goal is to get 2.6.35.3 (the freescale) release completely running (1080p codecs). Dec 08 14:24:35 using LTIB ? Dec 08 14:24:36 or OE ? Dec 08 14:24:36 ericben: you need some tweaks, it doesn't work outside of freescale. Dec 08 14:24:45 OE Dec 08 14:25:01 ericben: I can package my meta-freescale, I don't have it GITted yet. Dec 08 14:25:03 ok, if interested I can send you my wip meta-mx53qsb Dec 08 14:25:18 I was not sure we could redistribute the binaries Dec 08 14:25:19 ok, let's exchange, then work on github or somesuch from there. Dec 08 14:25:22 seems its possible Dec 08 14:25:48 well they're open in github, I took it from there... so I can also make a diff :) Dec 08 14:26:05 what is your your prefered email address? Dec 08 14:26:08 +r Dec 08 14:26:32 the one on the mailing list Dec 08 14:27:12 ok I have 3D on i.MX51 not MX53 Dec 08 14:27:20 but the recipe should be direct to port to the 53 Dec 08 14:27:36 sometimes I'm lost between MX25/27/35/51/53 ;-) Dec 08 14:28:02 which QSB do you have : the one with Dialog PMIC or the one with FSL PMIC ? Dec 08 14:28:59 dialog Dec 08 14:29:04 ok same here Dec 08 14:31:26 ericben, hi Dec 08 14:31:34 hi GNUtoo Dec 08 14:32:42 ericben, so there is a meta-freescale arm somewhere else? Dec 08 14:33:14 what should we do then? Dec 08 14:33:33 GNUtoo: https://gitorious.org/yocto Dec 08 14:33:42 this one only supports MX53 Dec 08 14:34:10 but seems a good working base Dec 08 14:34:13 ok Dec 08 14:35:55 likewise: see PM Dec 08 14:37:01 so we port the freescale eukrea stuff on that ? Dec 08 14:38:05 there is also meta-freescale at github.com (the one I am using). Dec 08 14:39:34 http://www.openembedded.org/wiki/LayerIndex has only fsl-ppc Dec 08 14:41:23 GNUtoo: that's because it's not public yet. Dec 08 14:41:51 GNUtoo: remember by deciding to use our friend oe-core, we invited our other friend called "fragmentation" :) Dec 08 14:42:06 indeed Dec 08 14:42:19 if you haven't already it might be worth talking to msm or someone else at freescale, see if they would be able to help maintain an arm layer as well Dec 08 14:42:23 that's why stuff should be documented there Dec 08 14:42:32 on the layer index page Dec 08 14:44:13 yes msm was talking about freescale-arm stuff Dec 08 14:44:24 but I didn't know he worked for freescale Dec 08 14:49:13 bluelightning: msm is in the loop, thanks Dec 08 14:49:20 cool Dec 08 14:49:49 we will decide on where we join forced and then announce it, I'm sure. Dec 08 14:49:54 forced=forces. Dec 08 14:54:27 bluelightning: glad to see you volunteering to stand for the TSC Dec 08 14:55:32 pb_: thanks, I hope to do a good job if given the opportunity Dec 08 15:33:57 (In case someone is interested) I just found the root cause for the CMAKE_AR issue when using an external binary toolchain. The meta/classes/cmake.bbclass generates a toolchain.cmake and sets the CMAKE_FIND_ROOT_PATH. Since this variable doesn't contain the path to the cross toolchain cmake won't be able to find ar and therefore fails when it comes to the creation of static libs. Dec 08 15:35:10 So, adding ${EXTERNAL_TOOLCHAIN} to the cmake.bbclass solves it for me. Even though, I'm not sure if using (polluting) the cmake.bbclass with such a variable would be accepted upstream. Dec 08 17:15:36 kergoth`: what does your bblayer.conf look like w/ meta-oe? Dec 08 17:16:54 msm, hi Dec 08 17:18:28 GNUtoo: hello Dec 08 17:18:47 kergoth`: maybe i should ask what is your meta-oe layer priority... Dec 08 17:18:57 msm, there are too many different layers for freescale stuff Dec 08 17:19:11 2 layers? Dec 08 17:19:12 just before we were talking about unificating them Dec 08 17:19:22 it seem at least 3 Dec 08 17:19:37 meta-freescale on github is ARM Dec 08 17:19:44 meta-fsl-ppc on yocto is PPC Dec 08 17:19:45 there is one on gitorious also Dec 08 17:19:47 those are the two I know of Dec 08 17:19:51 I'm talking about arm only Dec 08 17:19:53 whats the link? Dec 08 17:20:04 GNUtoo: i'm not ARM at all =) Dec 08 17:20:16 GNUtoo: ARM always does things the hard way ;) Dec 08 17:20:17 https://gitorious.org/yocto/meta-freescale Dec 08 17:20:28 and the third one is used by eukrea Dec 08 17:20:30 ah ok Dec 08 17:20:43 GNUtoo: thats the meta-freescale I was talkng about… maybe it's not on github Dec 08 17:20:50 what is this one by eureka? Dec 08 17:20:51 ok Dec 08 17:20:58 I'm not sure if it's published Dec 08 17:22:04 I should ask ericben if he published it Dec 08 17:26:48 does meta-oe not come with a conf/layer.conf file on purpose? Dec 08 17:27:14 msm: the meta-openembedded repo consists of a number of individual layers Dec 08 17:27:19 each one has a conf/layer.conf Dec 08 17:27:22 indeed Dec 08 17:28:25 bluelightning: ahh i see now Dec 08 17:30:09 GNUtoo: not yet published, I expect to have it online by the end of the month/year ;-) Dec 08 17:30:15 ok Dec 08 17:30:26 msm: our overlay supports i.MX25/35/51 (and soon 53) modules Dec 08 17:30:32 how do we handle the freescale tarballs? Dec 08 17:30:38 *how will we handle Dec 08 17:30:52 GNUtoo: well in meta-freescale they put everything in files Dec 08 17:30:59 I don't remember if everything is redistributable or not Dec 08 17:31:00 so redistribution seems possible Dec 08 17:31:02 ok Dec 08 17:31:27 I guess for the codecs the fees for software patents are paid with the hardware Dec 08 17:33:08 has anyone seen this issue when adding meta-oe? Dec 08 17:33:08 ERROR: Could not include required file recipes-graphics/xorg-driver/xorg-driver-input.inc Dec 08 17:34:04 msm, what recipe? Dec 08 17:34:25 GNUtoo: it's just parsing recipes Dec 08 17:34:31 ok Dec 08 17:35:38 that file is here tough: Dec 08 17:35:40 openembedded-core/meta/recipes-graphics/xorg-driver/xorg-driver-input.inc Dec 08 17:38:29 its not on yocto though Dec 08 17:38:37 are the two possible out of sync? Dec 08 17:38:53 or did this file get renamed recently (I'm on the last release) Dec 08 17:39:11 I used shr's branches on contrib Dec 08 17:39:31 the reason of theses branches is for having a sync Dec 08 17:40:10 I just need to find the approriate sync point Dec 08 17:40:14 ok Dec 08 17:40:22 I looked a the edison release, it did not have a meta-oe SHA Dec 08 17:41:10 msm: what is trying to include it? Dec 08 17:41:24 lunch time bbiab Dec 08 17:41:32 bon apetit Dec 08 17:41:34 so oe-core is out of sync with meta in poky? Dec 08 17:41:35 or..? Dec 08 17:42:32 game time bbl Dec 08 18:05:40 Is someone using systemd and dropbear? I've refactored the recipe and want more people to test it before sending for merging Dec 08 18:06:58 surely angstrom uses dropbear? Dec 08 18:07:05 bluelightning: uses Dec 08 18:07:55 bluelightning: I've merged the dropbear-systemd recipe onto a dropbear bbappend and ported it to use systemd bbclass ... cleaner solution but I'd like more people to test it before sending it for merging Dec 08 18:17:46 bluelightning: in case you want to take a look, it is at https://github.com/OSSystems/meta-oe/commit/469e6f929862bd294de7683c083c44f3b401c707 Dec 08 18:18:10 unfortunately I have no experience with systemd in oe so I probably can't help you much Dec 08 18:24:23 otavio, in shr we have some systemd branches but we use openssh rather than dropbear Dec 08 18:32:28 GNUtoo: is it possible for you to test this patch? Dec 08 18:33:15 otavio, which patch? Dec 08 18:33:30 GNUtoo: the dropebar one. Dec 08 18:33:32 that one: https://github.com/OSSystems/meta-oe/commit/469e6f929862bd294de7683c083c44f3b401c707 ? Dec 08 18:33:35 GNUtoo: yep Dec 08 18:33:46 GNUtoo: any specific reason why you use openssh/? Dec 08 18:33:48 I'm very sorry but I don't use dropbear right now Dec 08 18:33:52 yes security Dec 08 18:34:06 basically empty password can be handled better with openssh Dec 08 18:34:12 that's why we switched Dec 08 18:47:08 Tartarus, are you just coming in for the 1 day to present for Jason? Dec 08 18:47:15 whole conf Dec 08 18:47:19 kk Dec 08 18:47:56 should be interesting. nice group of talks this year. Dec 08 18:48:19 quite a few Beagle Talks. Dec 08 18:48:22 even mine is. Dec 08 18:52:51 kergoth`: im not sure what SHA I should use for edison release Dec 08 18:53:04 kergoth`: meta-oe SHA for whatever OE/Yocto was at that time Dec 08 18:55:20 so does anyone know if information exists for which SHA for meta-oe is useful for oe-core around the time of edison? Dec 08 19:18:26 i'd just look at the date, myself Dec 08 19:18:28 heh Dec 08 19:32:27 kergoth`: thats what im done Dec 08 19:32:30 i just feel weird doing that Dec 08 19:32:35 meta-oe needs branches or at least some tags Dec 08 19:35:58 well, it's not part of the yocto release, so it makes sense that it wouldn't have yocto release tags :) Dec 08 19:40:21 well Dec 08 19:40:38 kergoth`: it has nothing at all… no branches or tags Dec 08 19:40:54 kergoth`: i guess im just complaining for fun =) Dec 08 19:40:57 heh :) Dec 08 19:41:09 kergoth`: really, yocto release emails should contain the meta-oe branch they work with Dec 08 19:41:26 well, to be fair, sometimes a simpler branching model is better, less confusion. and I don't think meta-oe has been in any releases of anything yet.. heh Dec 08 19:41:47 kergoth`: i just realized it might not have been in any release =) Dec 08 19:43:00 :) Dec 08 19:43:40 * kergoth` tries building mplayer2 in meta-oe+meta-yocto Dec 08 19:44:01 re priority, I think I intended to put meta-yocto above meta-oe, but I don't think I actually did Dec 08 19:44:15 largely due to not wanting to maintain a separate branch/fork of meta-oe Dec 08 19:47:56 kergoth`: yea, we should be able to override those in bblayer.conf Dec 08 20:05:51 when I add a layer, it's going to take the newest recipe regardless, right? Dec 08 20:06:00 the layer priority only resolves recipes that are the same version? Dec 08 20:06:05 nope, that's not correct Dec 08 20:06:12 at least it hasnt' been in the past, unless its been changed Dec 08 20:06:15 ok Dec 08 20:06:17 im asking Dec 08 20:06:20 it'll use an old version in a high priority layer over a high version in a low priority layer Dec 08 20:06:20 heh PRIORITY and BBPATH Dec 08 20:06:26 ok Dec 08 20:06:31 good, that's actually what I want Dec 08 20:06:52 I must say dropbear sucks Dec 08 20:07:03 tasslehoff: I owe you an answer Dec 08 20:07:26 tasslehoff: the toolchains in OE-core are not relocatable as in for installing Dec 08 20:07:34 they will have to be installed in SDKPATH Dec 08 20:07:49 and you can change SDKPATH during build time Dec 08 20:09:42 khem: ah. thanks for that info. I've had the SDK committed to our repo to make it easier to always get back to the toolchain used at a given time, but maybe I must reconsider. Dec 08 20:10:36 I think the oe-core sdk is lot more standalone though Dec 08 20:10:53 it ships its own supporting libs e.g. glibc etc that gcc will use to run Dec 08 20:11:07 so it can work across the machines pretty much Dec 08 20:11:28 khem: you mean more stand-alone than the oe-classic was? Dec 08 20:11:34 yes Dec 08 20:11:55 barring relocatability Dec 08 20:12:18 there are lot of libs that gcc and friends want when they run Dec 08 20:12:23 khem: yeah. only gripe I have with that is when one must go back in time and reproduce a build. Dec 08 20:12:39 it was convenient to have the sdk in git as well :) Dec 08 20:12:41 and it makes sure that it supplies them all together and not depend on versions on your host Dec 08 20:13:09 tasslehoff: you mean sdk binaries ? Dec 08 20:13:37 tasslehoff: I think various distros e.g. poky release sdk tarballs Dec 08 20:13:53 khem: yes. I extracted the sdk to a toolchains folder in our repo. Dec 08 20:14:24 khem: yes, that's what I will do as well. Dec 08 20:14:43 tasslehoff: ok Dec 08 20:15:27 then I just have to wrestle systemd a bit more, and my transition to oe-core will be somewhat complete :) Dec 08 20:15:59 systemd is not a requirement for oe-core Dec 08 20:16:02 khem: will you throw in an answer to the SDK thread I posted on the ML? Dec 08 20:16:06 unless you are using angstrom Dec 08 20:16:08 khem: nope, but I use angstrom Dec 08 20:16:12 exactly :) Dec 08 20:16:16 ah Dec 08 20:16:37 * khem is usually behind on reading emails always Dec 08 20:17:01 I've always used angstrom, but perhaps I don't need to. I really only need a console image with some extra stuff. Dec 08 20:17:20 hmmm Dec 08 20:17:42 tasslehoff: oe-core has core-image-minimal Dec 08 20:17:51 which is similar Dec 08 20:18:02 so, when I add meta-oe to my build…. my lsb-sdk target is building different packages... Dec 08 20:18:22 msm: possible Dec 08 20:18:38 since meta-oe might have copies of some recipes that are in oe-core Dec 08 20:18:40 khem: i made it the lowest priority too Dec 08 20:18:56 khem: so i would think it would not use anthing from meta-oe if it exsits elsewhere Dec 08 20:18:58 You can generate bitbake -g lsb-image Dec 08 20:19:04 maybe RRECCOMMENDS? Dec 08 20:19:05 and check the bb files its using Dec 08 20:19:54 khem: ah, I'll take a look at basing my image on that one instead. it still uses sysvinit? Dec 08 20:20:52 msm: if its lowest priority then yes but also make sure that it appears last on BBLAYERS Dec 08 20:21:25 tasslehoff: yes Dec 08 20:21:33 khem: its last and lowest priority Dec 08 20:21:39 heh Dec 08 20:21:57 ok Dec 08 20:23:25 tasslehoff: oh but one thing Dec 08 20:23:44 tasslehoff: meta-oe has patches to gcc which makes it much more appealing for arm cores Dec 08 20:24:21 tasslehoff: if you care about armv7-a particularly you may want to use meta-oe on top of oe-core Dec 08 20:24:27 khem: ok. I run on a beagleboard-like system, so that's relevant Dec 08 21:12:45 hey likewise Dec 08 21:30:13 khem: did your post to the ML indicate that it *can* be relocated after all? or did I misunderstand? Dec 08 22:12:21 tasslehoff: I think I am trying to sort the problem Dec 08 22:12:39 tasslehoff: I think the relocatability is there its just not working but I will find out Dec 08 22:15:20 khem: cool. than I will just enjoy my whiskey while you do ;) Dec 08 22:15:49 hmmm you can enjoy mine too since I dont drink :) Dec 08 22:21:38 khem: wise choice :) Dec 08 22:55:10 kergoth`: We add packages to RDEPENDS not recipes by name right ? Dec 08 22:55:40 and add recipes by name to DEPENDS Dec 08 23:00:23 yes, that's what the R means, runtime Dec 08 23:11:01 libxaw depends on xmlto Dec 08 23:11:06 but xmlto is no where to be found Dec 08 23:11:23 kergoth`: but I want to make sure the difference between recipe name and output package name Dec 08 23:11:55 many people confuse DEPENDS = "recipe" RDEPNDS = "recipe" one for build time the other for runtime Dec 08 23:12:14 but actually it should be DEPENDS = "recipe" RDEPENDS "output package name" Dec 08 23:12:30 and recipe name may not be equal to output package name Dec 08 23:13:12 msm: for quick hack add --disable-xmlto Dec 08 23:13:41 hmm, I like this hack Dec 08 23:13:46 seems like im missing stuff on my host Dec 08 23:13:58 …. /usr/share/xmlto/format/fo/ps Dec 08 23:14:01 msm: there should be a native package providing xmlto Dec 08 23:14:04 for libxaw Dec 08 23:14:34 khem: don't see anything Dec 08 23:15:36 kergoth`: it would be nice if bitbake could catch such semantic errors Dec 08 23:15:44 msm: ok disable it then Dec 08 23:16:12 msm: if you are unlucky then it wont let you disable it Dec 08 23:16:36 khem: giving it a try Dec 08 23:18:14 didnt work Dec 08 23:18:22 i think installing host packages will fix issue though Dec 08 23:18:56 libxaw already has a disable docs on it Dec 09 00:40:28 kergoth`: I want to add a task to recipe but defer executing it later Dec 09 00:40:55 kergoth`: so essentially I want the do_* script to be emitted but not executed how to do that Dec 09 00:50:55 hi everyone, I have a question about the full SDK that you can download with the narcissus distribution for beagleboard Dec 09 00:51:40 I was able to run the distribution, now I am trying to build a distribution with the sdk and run it Dec 09 00:52:07 but I can't find a Make program or anyway to compile the sdk Dec 09 00:56:24 ..or documentation, does anyone know how it's supposed to work? thanks, Dec 09 01:21:07 :) **** ENDING LOGGING AT Fri Dec 09 02:59:58 2011