**** BEGIN LOGGING AT Tue Aug 09 02:59:56 2011 Aug 09 11:42:20 www.gnome.org/mobile/ what happend to this link ?? Aug 09 13:51:36 zeddii, yocto/standard/preempt_rt/common-pc still exists in origin from what I can tell... Aug 09 13:53:51 I nuked the branch on the tree. is something holding onto it. the fetcher likely couldn't do the delete ? Aug 09 13:54:40 yah. I see it gone on the servers. so something is clinging to it outside of that. Aug 09 14:00:09 dvhart, try git fetch --prune yocto Aug 09 14:00:25 git will not delete tracking branches for deleted branches by default Aug 09 14:08:13 jilles, good call Aug 09 14:26:58 heh, getting bit by the poky-contrib branches changing around? it's bit me a few times now, as someone deletes foo and adds foo/bar Aug 09 14:34:36 dvhart, in theory the fetcher already has that .. but it sounds like you were updating manually. Aug 09 14:48:44 eglibc-nativesdk shouldn't be built during image build, right? Aug 09 14:49:11 eglibc-locale-nativesdk is somehow pulled to image depends :/ Aug 09 14:56:30 JaMa: ouch :/ Aug 09 14:56:46 JaMa: that shouldn't happen Aug 09 14:57:08 bitbake -g isn't giving any hints Aug 09 14:57:34 but commenting all BBCLASSEXTENDS from eglibc(-locale) recipes allows me to build image without it Aug 09 14:57:49 so it looks like wrong provider is choosen Aug 09 15:11:32 fray, what's the bz number for the bb related bug? Aug 09 15:17:11 RP__: weird as it sounds, but it was caused by libcanberra-alsa in RDEPENDS of some task-foo.. and eglibc-nativesdk somehow considered as right libcanberra-alsa provider (instead of libcanberra) Aug 09 15:17:52 RP__: task-depends.dot:"task-shr-minimal.do_package_write_ipk" -> "eglibc-nativesdk.do_package" Aug 09 15:29:40 JaMa: That sounds *ver* odd Aug 09 15:29:43 very Aug 09 15:30:31 RP__: Does https://github.com/kergoth/oe-core/compare/master...devshell address your concerns regarding env exports for devshell? I realize this code isn't ideal, but I think it's important to get this in for the usability improvement Aug 09 15:31:37 RP__: few days ago I had even the warning about multiple providers for libcanberra-alsa (libcanberra,eglibc,eglibc-nativesdk).. Aug 09 15:31:57 kergoth: yes, thats better since it doesn't change the checksums Aug 09 15:32:11 * kergoth nods Aug 09 15:32:15 okay, i'll send that, thanks Aug 09 15:32:27 * kergoth 's trying to get caught up on his old pending branches Aug 09 15:32:29 RP__: after greping for libcanberra in eglibc dir I decided that's broken cache or something.. but today warning was gone but dependency still there.. Aug 09 15:32:37 kergoth: We did start adding code in bitbake to store the original environment, we don't have a method to access that data yet Aug 09 15:33:00 RP__ ahh, I thought the code had been finished... Aug 09 15:33:00 yeah, that will be useful Aug 09 15:34:53 fray: I think its being used by the UI now, we just don't have access through a bb.xxx function yet Aug 09 15:34:59 ahh ok Aug 09 16:16:49 RP__, ping/heads up. I'm seeing an inability to execute anything on qemux86 out of an up to date master Aug 09 16:17:05 same behaviour with the 3.0 kernel (which I was testing) and the 2.6.37 kernel. Aug 09 16:22:54 zeddii: hmm :/ Aug 09 16:24:14 I'm at a loss at the moment Aug 09 16:24:26 I always get "command not found" for anything but a shell builtin. Aug 09 16:24:36 I know I've seen this in the past, and am consulting google :P Aug 09 16:30:05 zeddii: I'm seeing 64 bit executables on 32 bit :/ Aug 09 16:31:12 that would do it. Aug 09 16:31:25 zeddii: looks like its mixing and matching 32 and 64 bit exes Aug 09 16:31:37 I tested on my host and it showed 32 bit .. but I may have picked the one it didn't use on the target fs. Aug 09 16:31:44 zeddii: this could be my multilib tests breaking things though Aug 09 16:32:24 hmm. I wondered that, but had no evidence yet to point in any direction(s). I always suspect myself first :) Aug 09 16:38:28 zeddii, I also always suspect you first. Aug 09 16:38:34 ;) Aug 09 16:51:00 zeddii, ping - to include scc files that reside in the same directory, is there any reason to use the longer path? Aug 09 16:51:01 ie Aug 09 16:51:04 include routerstationpro.scc Aug 09 16:51:13 include bsp/routerstationpro/routerstationpro.scc Aug 09 16:51:29 I'm seeing both forms and am unsure which to follow Aug 09 16:53:42 where do scc files live? Aug 09 16:58:09 msm, in the linux-yocto git repository, meta branch Aug 09 17:00:50 zeddii: summary is I think the interpreter prefix is getting broken Aug 09 17:02:37 dvhart: how do patches go in to this branch? via the normal methods? Aug 09 17:03:36 msm, checkout the repo, change to the branch, write your patches, send them to the yocto list, specifying they are for linux-yocto meta branch Aug 09 17:03:39 so yeah, normal methods Aug 09 17:03:47 k Aug 09 17:03:55 zeddii: Was it an incremental or from scratch build? Aug 09 17:04:11 RP__, mine was an incremental where I saw this Aug 09 17:04:27 RP__, (same issue as zedd) Aug 09 17:06:36 * zeddii was eating Aug 09 17:07:33 incremental. I thought it was from scratch, but I had a .37 kernel around, so it was an update. Aug 09 17:07:55 dvhart, to answer you question. no reason to have the longer path. It only comes in handy if something moves later. Aug 09 17:09:09 zeddii, do you have a preference? Aug 09 17:09:16 nope. Aug 09 17:09:24 shorter i.e. cwd is fine. Aug 09 17:09:24 * dvhart opts for shorter then Aug 09 17:13:09 * RP__ suspects incremental gcc gets borken badly Aug 09 17:15:30 RP__, my mips build appears to have suffered the same fate. Aug 09 17:15:42 * zeddii removes everything and starts again. Aug 09 17:18:10 *sigh* and qrm Aug 09 17:18:11 arm Aug 09 17:18:14 Yocto (Built by Poky 5.0) 1.0+snapshot-20110809 192.168.7.2 ttyAMA0 Aug 09 17:18:14 192.168.7.2 login: root Aug 09 17:18:14 root@192:~# uname -a Aug 09 17:18:14 -sh: /bin/uname: No such file or directory Aug 09 17:25:53 zeddii: Its http://git.yoctoproject.org/cgit.cgi/poky/commit/meta/recipes-devtools/gcc/gcc-configure-common.inc?id=be1f70d68b6b75772ebab8bdff683ddd7c42b0cd Aug 09 17:27:12 aha. yes bad dynamic linking would toss that error. Aug 09 17:27:23 so regardless of clean vs incremental, that's a problem, right ? Aug 09 17:27:32 * zeddii will save his sstate if that's the case. Aug 09 17:28:08 zeddii: I think so but am not 100% sure when the regexp isn't working Aug 09 17:28:43 I'll let me clean build run for a bit anyway, it's doing no harm in the background. Aug 09 17:37:45 zeddii, did you say to not even try to get -rt for qemumips ? Aug 09 17:40:16 It has worked in the past. It's just 'under loved'. Aug 09 17:49:28 zeddii: clean builds are fine Aug 09 17:50:13 ';/.''''''''''"" Aug 09 17:50:17 PPPPPPPPppppp ] Aug 09 17:50:18 = Aug 09 17:50:35 thanks fray. that was deep. Aug 09 17:50:49 RP__, cool. so I can complete my 3.0 on sato testing that way. Aug 09 17:51:48 zeddii, hrm, mti-malta seems special Aug 09 17:51:56 it has -be and -le in the name Aug 09 17:52:02 for the standard.scc files Aug 09 17:52:23 I'm used to MACHINE/MACHINE-standard.scc Aug 09 17:52:25 * RP__ says hi to fray's cat Aug 09 17:52:26 yup. it's a hold over. the BSP supports both, we only use be. I have plans to turn the le back on. Aug 09 17:52:28 the -be and -le are throwing me Aug 09 17:52:55 just endianess designations. using an older technique. Aug 09 17:53:33 zeddii, so do I create two -preempt-rt.scc ? Aug 09 17:53:45 just one. ignore -le for now. Aug 09 17:53:57 and how does that impact the KMACHINE KBRANCH specification in the linux-yocto-rt recipe? Aug 09 17:54:22 it is part of the branch now: yocto/standard/mti-malta32-be Aug 09 17:54:38 that was indeed the kittens.. Aug 09 17:54:49 apparently the keyboard is fascinating Aug 09 17:55:18 * fray was outside due to a lawn mower incident.. (my dads mowing the lawn, and he hit a piece of bailing wire.. had to remove the mower deck and clean out the wire) Aug 09 17:57:26 zeddii, so: kconf hardware mti-malta32-be.cfg Aug 09 17:57:27 zeddii, dvhart: http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/ml4&id=c5b54cfb225b21ba7218293bae2712b12974c3fc is the fix Aug 09 17:57:29 doh Aug 09 17:57:43 zeddii, KMACHINE_qemumips = "mti-malta32-be" Aug 09 17:58:29 RP__, thanks - I'll rebase and rebuild Aug 09 17:58:50 * dvhart is pounding on this RAID0 array Aug 09 17:59:01 have builds suddenly started taking a lot more time writing packages? Aug 09 17:59:08 things seem a lot slower Aug 09 17:59:38 I'd run a bbtimeline, but I have need of the system over the next several days :/ Aug 09 17:59:51 dvhart: I'm suspecting the tune changes have slowed something down Aug 09 17:59:57 RP__, ok Aug 09 18:00:13 dvhart: no proof at this point :( Aug 09 18:00:35 hard to track down given how long they builds take.... erm... Aug 09 18:00:36 :) Aug 09 18:01:07 it mostly seems to be the do_package_write... tasks Aug 09 18:01:32 and maybe do_rootfs - but I don't have numbers yet, just a feeling Aug 09 18:02:16 the array is so saturated that other tasks needing access to the drive to read 20MB are literally waiting 30minutes Aug 09 18:02:26 * fray notes he appears to be missing two kittens.. :| Aug 09 18:02:43 fray, check your mouse! Aug 09 18:02:46 ;) Aug 09 18:03:29 ...and on an unrelated note... I just got an email that my 84 3/4x6-8' Cedar Bevel Siding showed up today at the lumber yard Aug 09 18:03:48 ...now waiting on my 60 - 3/4x6-20' pieces... Aug 09 18:04:14 * fray is a bit worried about how big of a stack 84 boards might be... Aug 09 18:13:35 fray, I know the feeling Aug 09 18:13:51 I've parked on the street a lot this year, having a rather large pile of material in my driveway Aug 09 18:14:11 which is now mostly in my garage (waiting for the cedar to dry to the appropriate moisture content for paint) Aug 09 18:17:41 hrm, atsar is giving me strange results on the disk Aug 09 18:18:23 50-70% busy, but with only 100 w/s at 4 kB/s with fairly few requests on the queue Aug 09 18:18:24 * zeddii is back to his clean build Aug 09 18:18:26 * dvhart scratches head Aug 09 18:19:01 this stuff should all be kiln dried.. western red cedar from Oregon.. Aug 09 18:19:06 zeddii, mind running "atsar -D 10 10" near the end of your build? during root-fs etc Aug 09 18:19:09 plan is to prime and paint it before we install it.. Aug 09 18:19:17 fray, the siding usually is yeah Aug 09 18:19:18 building is 8x20 w/ 9 foot walls Aug 09 18:19:31 fray, the thicker stuff (2x and 4x material comes green typically) Aug 09 18:19:38 ah Aug 09 18:19:58 ya, I'm using pine and PVC for all of the other boards.. anything exposed is PVC.. anything structural is pine Aug 09 18:20:00 I ordered my cedar siding pre-primed Aug 09 18:20:21 nice, I'm using AZEK (pvc) for facia as well Aug 09 18:20:42 I couldn't find structural PVC for the railings or I would have used that Aug 09 18:20:47 not sure what the branch is.. but they are basically 1x6 (3/4 x 5 1/2).. Aug 09 18:20:54 facia and trim.. Aug 09 18:21:13 windows and doors are either steel or vinyl.. Aug 09 18:21:38 If I ever build in Oregon I'll use: cement, pvc, and vinyl Aug 09 18:21:51 dvhart, will do. Aug 09 18:21:54 wood is just not a good plan Aug 09 18:22:42 well, my house is 100+ years old.. and has very little rot.. Aug 09 18:22:53 it's both dimensional and rough cut pine Aug 09 18:23:43 the places where there are rot are roof boards and untreated touching foundation Aug 09 18:23:45 fray, right - but you don't get 9 thousand inches of rain a year :) Aug 09 18:24:19 we get a reasonable amount and it's very cold in the winter and very warm/humid in the summer.. Aug 09 18:24:23 but ya.. wood works well here Aug 09 18:24:28 especially cedar Aug 09 18:24:59 (BTW preprimed western red cedar wasn't an option, or I would have done it..) ;) Aug 09 18:25:08 Cedar doesn't do badly here either really, this year has been hard on it though as it's been raining pretty consistently and the mold/mildew got a good chance to grow Aug 09 18:25:13 and now sun to kill it over the summer Aug 09 18:25:30 ahh Aug 09 18:26:26 I will say that the 100 year old cedar on the barn is amazingly light compared to the modern cedar replacements.. I don't know if thats because it was old-growth.. or if it's decayed.. or if modern is just heavier wood due to growing practices.. Aug 09 18:26:30 fray, one misconception on cedar though is that it is rot resistant. Supposedly only the dead heartwood is naturally resistant, and you don't get any of that anymore - it's all from new growth. Still, it's better than hemlock and spruce. Aug 09 18:26:44 modern is wet Aug 09 18:26:50 and "sap wood" Aug 09 18:27:16 modern lumber is pretty poor quality relatively speaking - especially to that stuff on your barn. Aug 09 18:27:19 most of the pine we get around here is hemlock.. Aug 09 18:27:25 heh Aug 09 18:27:40 I have been ordering douglas fir though when replacing some of the structural members.. Aug 09 18:27:47 amazing wood compared to hemlock Aug 09 18:28:34 (4x6 and 6x6 douglas fir.. all special order) Aug 09 18:29:03 I know if I built a new home.. and had the money... and it was wood construction.. I'd get it all in douglas fir.. Aug 09 18:30:05 I had to use #1 on a couple timbers - ouch Aug 09 18:30:32 typically you can go through a new lot of #2 and better by hand and get better quality than a random #1 and pay a lot less. Aug 09 18:30:45 the douglas fir I had to get for my barn is all select douglas fir.. ;) Aug 09 18:31:09 it's automatically select when you order 6x6 because they assume it will be visible in a building Aug 09 18:31:35 http://www.dvhart.com/piwigo/picture.php?/86/category/3 Aug 09 18:31:36 12' 6x6 select douglas fir.. cost me $100 a timber.. had to buy 6 of them Aug 09 18:31:51 also took a month to get them in to the lumber yard.. ;) Aug 09 18:32:06 the white horizontal beams are hand selected #2 Aug 09 18:32:13 (sssshhhh, don't tell the county) Aug 09 18:32:21 hah Aug 09 18:32:33 only difference between #1 and #2 is the number of knots.. Aug 09 18:32:51 zeddii: if I want to make additions to meta in linux-yocto-3.0 whats the best way to get poky to use my changes? point at my local git repo? Aug 09 18:32:51 yup. hand selected #2 had fewer than the single #1 I ordered ;-) Aug 09 18:32:59 heh Aug 09 18:33:19 that douglas fir? Aug 09 18:33:29 msm, use poky-extras/meta-kernel-dev Aug 09 18:33:41 msm, then specify KSRC_linux_yocto to point to a local bare clone Aug 09 18:33:44 fray, yes Aug 09 18:34:00 I wish I could go to a local lumber yard and even select douglas fir.. :( it's all special order Aug 09 18:34:19 fray, that's a shame Aug 09 18:34:58 msm. yes, that typically is the easiest. Aug 09 18:34:59 fray: does KSRC_linux_yocto work in general for local linux trees? Aug 09 18:35:02 errr Aug 09 18:35:08 msm, have a look at my elc2011 practical kernel development with yocto video Aug 09 18:35:09 dvhart: ^ Aug 09 18:35:21 if you are adding configs, you can just bbappend them in .cfg files. Aug 09 18:35:27 msm, uhm... it's specific to linux-yocto... Aug 09 18:35:38 msm, maybe I'm not understanding the question Aug 09 18:35:49 dvhart: nvm Aug 09 18:35:51 if you want to declare new boards/branches, you need more complex changes. Aug 09 18:35:58 s/complex/different/ Aug 09 18:36:04 complex was accurate Aug 09 18:36:06 ;) Aug 09 18:36:14 so, im bbappend'ing in the poky source or linux-yocto meta brnach? Aug 09 18:36:21 im adding a new board Aug 09 18:36:52 dvhart: 52 minutes! Aug 09 18:37:03 do that right in meta. or I can use you as a guniea pig later today ;) if you want to do it outside the tree. Aug 09 18:37:39 zeddii: feel free… im actively working on adding kernel stuff and dealing with how we are going to handle multiple configs for multiple boards Aug 09 18:37:46 I have to go home and talk to a 'dude' about getting my bathroom renovated, but have some queued changes that would allow you to declare thea board outside the kernel tree. it's a port from 'the other' codebase. Aug 09 18:37:47 within yocto Aug 09 18:37:51 msm, sorry man :) Aug 09 18:38:01 msm, we're working on getting it written up in a manual Aug 09 18:38:11 i hear there is a manual fourthcoming Aug 09 18:38:14 msm. ok, I'll send you a pointer to my branch later then. Aug 09 18:38:21 ETA. end of week, or I'll die trying. Aug 09 18:38:26 hah ok Aug 09 18:38:32 * zeddii hopes it isn't the latter. Aug 09 18:42:35 linux-yocto-rt working on qemux86-64 Aug 09 18:42:51 hehe, 37ms max latency Aug 09 18:42:54 yeow! Aug 09 18:42:57 whee! Aug 09 18:43:08 * zeddii notes there is work to be done Aug 09 18:43:36 zeddii, I don't expect qemu to do particularly well Aug 09 18:45:34 true. I have some historical numbers here somewhere .. Aug 09 18:45:47 as long as jitter is not bad, the max is coo. Aug 09 18:45:52 cool even. Aug 09 18:46:35 it's still deterministic ;-) Aug 09 18:46:43 it's horrible - every time Aug 09 18:48:20 * zeddii is stepping out, be back in a bit. Aug 09 19:15:53 blog search stats are always good for a laugh Aug 09 19:30:39 Looks like another night of riots in the UK :( Aug 09 19:33:25 RP__, :( Aug 09 19:46:07 dvhart: what does the meta-kernel-dev actually add? Aug 09 19:46:24 dvhart: does it let you add cfg fragments in your own meta layer? Aug 09 19:58:00 how is it envisioned to add additional bsp/kernels… would they all go in the linux-yocto branch proper? what if there are a lot of new branches? etc Aug 09 19:58:17 at what point does linux-yocto just track the bsp's included in poky Aug 09 20:33:05 msm, I'm back Aug 09 20:33:13 msm, still looking for answers to the above? Aug 09 20:40:22 sort of Aug 09 20:40:29 just trying to think strategy Aug 09 20:40:47 i want to add support for lets say 20 boards, with 4-5 different kernels Aug 09 20:41:02 not sure what patches we will have on top of 3.0 but it could be considerable Aug 09 20:41:14 is this a place for linux-yocto git repo, or our own meta later? Aug 09 21:25:13 dvhart: whopos somehow i left the channel Aug 09 21:29:47 msm, we encourage people to try to use linux-yocto Aug 09 21:29:55 you will also want your own meta layer Aug 09 21:30:08 but it can just add a linux-yocto_3.0.bbappend Aug 09 21:30:24 rather than a completely new linux kernel recipes with patches Aug 09 21:30:42 meta-msm/recipes-kernel/linux/linux-yocto_3.0.bbappend Aug 09 21:30:43 like that Aug 09 21:31:25 your development should be upstream first. Those patches can then be applied to a yocto/standard/msmX branch in the linux-yocto tree Aug 09 21:31:43 and the config description under meta/cfg/kernel-cache/bsp/msmX Aug 09 21:32:13 I should say the patches should apply to yocto/standard/base Aug 09 21:32:36 if they are not upstreamable (ie they break other hardware) then they go in the bsp specific branch Aug 09 21:34:33 zeddii, have you built qemumips and qemuppc for linux-yocto_3.0 ? Aug 09 21:34:50 zeddii, I have non-rt (looking) build failures - easy fixes - but still... Aug 09 21:35:32 zeddii, also, I get black screens on qemuarm and qemumips when trying to boot the rt images. Is there some trick to using these emulators? Aug 09 21:35:44 (this is my first time using qemuarm and qemumips) Aug 09 21:36:19 dvhart: its just you will start generating a lot more of these branches… but i guess they are all automatically generated Aug 09 21:36:30 has anyone here used qemuarm or qemumips? I presume they are supposed to use the qemu screen and don't have some strange serial interface I'm supposed to be connecting to? Aug 09 21:36:54 msm, yes we will - and that is actually *why* the infrastructure exists Aug 09 21:37:19 if we only had the dozen or so machines, we wouldn't need all the complexity Aug 09 21:37:28 it's there to help with pretty much what you are hoping to do Aug 09 21:37:39 dvhart: what about machines not even in a upstream kernel release? Aug 09 21:37:48 i mean, it's just more patches... Aug 09 21:37:57 msm, those patches should go to lkml first Aug 09 21:38:14 that's what we mean by the "upstream first" policy/practice Aug 09 21:38:17 obviously they would at some point - but we are basing a lot of stuff on the 3.0 release Aug 09 21:38:25 so they can never make it in an old release =) Aug 09 21:38:46 that's fine, we can carry things back to 3.0 that make it into pre 3.1 (for example) Aug 09 21:39:11 the point it that the patches get vetted upstream and we don't end up carrying a bunch of patches that never go anywhere bu yocto Aug 09 21:39:51 this is pretty much the same way Redhat (for example) handles there kernels Aug 09 21:39:58 their even Aug 09 21:40:20 dvhart: well that or not support boards that are not upstreamed yet Aug 09 21:40:40 do something like xilinx seems to do… Aug 09 21:41:17 sure, they have the option, but if a patch is to make it into the yocto kernel, it needs to show due diligence for going upstream Aug 09 21:41:29 typically it should be shown to be "on its way in" Aug 09 21:41:47 but there are some that just break other things but are necessary (very few), and we do carry those Aug 09 21:43:27 just trying to get a feel for the intention of the linux-yocto tree Aug 09 21:46:07 any idea why meta-kernel-dev layer is making me build 2.6.37... Aug 09 21:46:21 if I remove that layer, I build 3.0 as requested Aug 09 21:50:36 msm, hrm... Aug 09 21:50:56 it must have a PREFERRED_VERSION override in it somewhere Aug 09 21:51:06 I'm using it and build linux-yocto-rt_3.0 Aug 09 21:51:29 meta-kernel-dev basically does 2 things: Aug 09 21:51:42 1) allows you to easily specify a local bare linux-yocto source tree Aug 09 21:51:51 2) use AUTOREV Aug 09 21:52:54 I don't see a PREFERRED_VERSION in mine Aug 09 21:53:11 are you pointing the KSRC_linux_yocto to linux-yocto-2.6.37 ? Aug 09 21:53:36 I'm not sure it would detect a source mismatch since it uses AUTOREV Aug 09 21:53:47 no its just going for 2.6.37 Aug 09 21:54:22 is it the same machine you're building with and without meta-kernel-dev ? Aug 09 21:54:35 yes Aug 09 21:54:42 literally add and remove the later from bblayers.conf Aug 09 21:54:51 one of our machines? or one of yours/ Aug 09 21:57:02 my own machine i've added in my own layer Aug 09 22:02:36 can you have multiple bbappends Aug 09 22:02:37 ? Aug 09 22:04:56 msm, you can yes Aug 09 22:05:19 the layer priority will dictate the precedence Aug 09 22:06:10 msm, re using 2.6.37, I suggest running with -e and grepping for "PREFERRED_PROVIDER_virtual/kernel" Aug 09 22:06:20 yes Aug 09 22:06:22 its 3.0 Aug 09 22:06:22 possibly PREFERRED_VERSION_linux-yocto Aug 09 22:06:34 its what im setting them too Aug 09 22:06:39 linux-yocto, 3.0 Aug 09 22:06:40 oh Aug 09 22:06:48 have you set COMPATIBLE_MACHINE? Aug 09 22:06:59 in my bbappends Aug 09 22:07:00 COMPATIBLE_MACHINE_$MACHINE = $MACHINE Aug 09 22:07:14 thats set Aug 09 22:07:18 however, KMACHINE is wrong Aug 09 22:07:24 can you post a the bbappend that is causing this to pastebin or something? Aug 09 22:08:27 my own or the one in meta-kern-dev Aug 09 22:09:08 your own Aug 09 22:09:37 and your machine conf Aug 09 22:10:28 hello, do you guys know if Yocto or OE could work on Asus routers that currently run OpenWRT? Aug 09 22:11:28 nemik, I suspect you would have to do some work to get a kernel recipe for it at least. Aug 09 22:11:38 (there may be one out there for OE, I haven't looked) Aug 09 22:20:03 nemik: there was a wrt54 machine support on oe but it has bitrotted Aug 09 22:21:46 khem and dvhart: ok, thank you. i suppose it's more work then currently Aug 09 22:22:09 nemik: if you dig back and use an older snapshot of oe Aug 09 22:22:14 then you stand better chance Aug 09 22:22:27 IIRC those boxes still use 2.4 kernel Aug 09 22:22:50 khem: nah, have been using 2.6 on my asus wl-520gU for a while Aug 09 22:24:45 nemik: thats same chipset used in wrt54g Aug 09 22:24:58 is it configured big endian ? Aug 09 22:25:28 brcm47xx chipset Aug 09 22:25:41 yes how about endian ness Aug 09 22:26:11 not sure about endian-ness...i think little Aug 09 22:26:21 yea, little for sure Aug 09 22:26:40 oe-core supports mips/be so it should not be that hard to extend that to brcm47xx Aug 09 22:26:55 LE might be a bit of work Aug 09 22:27:55 should just be a compiler flag? Aug 09 22:29:51 heh Aug 09 22:31:07 can we set that as the topic? Aug 09 22:32:19 yea...i probably don't know what i'm talking about **** ENDING LOGGING AT Wed Aug 10 02:59:57 2011