**** BEGIN LOGGING AT Wed Jun 08 02:59:56 2011 Jun 08 08:17:39 morning all Jun 08 14:13:50 bluelightning: morning Jun 08 14:13:59 hi jefferai Jun 08 14:14:19 thanks to you and zenlinux I now have beagleboard booting Yocto :-) Jun 08 14:14:36 although, I have two problems Jun 08 14:14:49 bootup log is here http://privatepaste.com/aee493bd50# Jun 08 14:15:13 one is all the warnings about "gconftool-2: /usr/lib/libxml2.so.2: no version information available (required by gconftool-2)" Jun 08 14:15:17 I'm not sure if that's important or not Jun 08 14:15:23 the other is it doesn't find a framebuffer device Jun 08 14:15:31 although I do have a monitor connected Jun 08 14:17:02 I do get output on the monitor when using the stock beagleboard microsd card Jun 08 14:17:26 jefferai: the latter is probably due to the lack of graphics support for beagleboard in our current kernel; IIRC dvhart is working on improved beagleboard hw support for our next release Jun 08 14:17:38 ah, hm Jun 08 14:18:17 OK. Maybe dvhart can let me know if there is some kernel config option I can tweak or some such thing to add support (the kernel on the provided card is 2.6.32, so the driver exists...) Jun 08 14:18:23 I'll follow up with him on that Jun 08 14:19:38 for the former, if we don't have a bug report for that (and a quick search doesn't show anything) then we should have one... can I convince you to file that? Jun 08 14:27:38 bluelightning: yeah -- although I'm not sure if it's actually a problem Jun 08 14:27:42 let me look around Google a bit Jun 08 14:28:21 well IMHO we would want to stop all boot-time errors like that showing up Jun 08 14:29:08 true Jun 08 14:29:25 thing is, normally you'd see this if you had libxml2 in some non-standard path and it couldn't be found Jun 08 14:29:31 but in this case it's in a totally standard path Jun 08 14:38:44 bluelightning: done: http://bugzilla.pokylinux.org/show_bug.cgi?id=1148 Jun 08 14:45:40 jefferai: thanks Jun 08 14:50:11 sure Jun 08 15:10:09 jefferai, reading up Jun 08 15:11:13 jefferai, I have the framebuffer working with an updated kernel, unfortunately the usb hub isn't powering on Jun 08 15:11:19 jefferai, I'm working through that today Jun 08 15:14:30 morning all Jun 08 15:14:36 hey zeddii Jun 08 15:14:37 erm Jun 08 15:14:40 hey zenlinux Jun 08 15:14:48 hi guys Jun 08 15:14:48 hi to you too zeddii ;) Jun 08 15:14:56 * zeddii gophers up. Jun 08 15:15:03 bluelightning, thanks for working with jefferai re bbxm Jun 08 15:15:06 and descends back to building renamed recipes :) Jun 08 15:15:15 zeddii, did you have any trouble with the linux-omap merge? Jun 08 15:15:15 we should all space our IRC nicks out across the alphabet - would make tab-completion easier :) Jun 08 15:15:42 dvhart: no worries, you're the one doing the hard work for it :) Jun 08 15:16:15 one would argue that would be koen and others ;-) but yes, even integrating that work is a bit of a nightmare Jun 08 15:16:45 dvhart: OK. I was just looking through the kernel option differences between the 2.6.32 angstrom kernel and the 2.6.37 yocto one -- I'm happy to work with you on this if you want Jun 08 15:17:00 keeping in mind that although I'm an old hand with linux I'm very new to Yocto and anything embedded :-) Jun 08 15:17:22 jefferai, that's about where I came into this project less than a year back Jun 08 15:17:28 yeah, we all start somewhere Jun 08 15:17:30 jefferai, it isn't as simple as changing the config options though Jun 08 15:17:36 I figured Jun 08 15:17:39 heh Jun 08 15:17:42 we merged the linux-omap tree first Jun 08 15:17:59 then I applied/merged/droppped the ~200 patches from the meta-ti linux-omap recipe Jun 08 15:18:28 then pruned down the beagleboard defconfig from the meta-ti layer to eliminate policy decisions (relegating those to the yocto/base) Jun 08 15:18:59 and now I'm trying to sort out why the usb hub doesn't power on, despite the ehci power assert level patch being applied and confirming it is running that code Jun 08 15:19:15 jefferai, so I can push this kernel branch someplace for you to take a peak at if you like Jun 08 15:19:50 Sure Jun 08 15:19:59 one sec Jun 08 15:20:02 OK. Jun 08 15:20:12 jefferai, are you familiar with how the linux-yocto git repository works? Jun 08 15:20:15 I'll need some help figuring out how to instruct which kernel branch to use :-| Jun 08 15:20:17 bsp branches, meta branch, etc ? Jun 08 15:20:21 Not really, no Jun 08 15:20:25 I have an idea what a BSP is Jun 08 15:20:34 Board Support Package Jun 08 15:20:43 just the bits that are specific to a board Jun 08 15:20:51 special patches, config fragments, etc Jun 08 15:21:05 right Jun 08 15:21:19 what are the meta branches? Jun 08 15:21:35 the bits above the bsp branches that contain the generic yocto stuff? Jun 08 15:21:41 that you merge down? Jun 08 15:21:58 jefferai, you will need to start with this if you want to work with the yocto kernel recipe and repository: Jun 08 15:21:59 http://www.yoctoproject.org/docs/1.1/kernel-manual/kernel-manual.html Jun 08 15:22:21 *click* Jun 08 15:22:32 if you can read through that, I will make the tree available and help you with the tactical parts of getting started Jun 08 15:22:54 this will be a good exercise to highlight where the manual is lacking and where a tutorial makes sense Jun 08 15:23:06 jefferai, did you attend elc in SFO this year? Jun 08 15:24:32 jefferai, if not, you may also get something out of my kernel development tutorial: http://free-electrons.com/blog/elc-2011-videos/ , search for "Kernel Development Tutorial" Jun 08 15:25:41 dvhart: no, I didn't Jun 08 15:25:47 OK Jun 08 15:25:57 dvhart gets 5 bucks everytime someone views his video! ;) Jun 08 15:26:03 bwahaha Jun 08 15:26:12 my check for $10 should be on the way then Jun 08 15:26:16 hehe Jun 08 15:26:29 * dvhart clicks again... and again Jun 08 15:26:36 dvhart needs a new minivan@! Jun 08 15:26:48 I prefer the term swagger-wagon Jun 08 15:28:46 jefferai, if you take notes on anything you come across that needs further explanation in the kernel manual, we'd be grateful. I'd even share half my proceeds from the video viewing with you ;-) Jun 08 15:30:30 heh Jun 08 15:30:36 sure, no problem -- even without the proceeds Jun 08 15:30:49 I'm getting free help -- happy to give free help Jun 08 15:31:32 (in the hypothetical case that you actually got money, of course -- I might not turn down the offer of a few million in shared proceeds...) Jun 08 15:31:33 :-) Jun 08 15:31:50 dvhart: ah, was this at LFCS? Jun 08 15:32:47 yeah, your half would be $0 ;-) Jun 08 15:32:56 uhm lfcs.... hrm Jun 08 15:33:02 it was a linux foundation event Jun 08 15:33:13 called ELC Jun 08 15:33:30 oh, no, not the collaboration summit Jun 08 15:33:34 this was a separate event Jun 08 15:33:58 ah, ok Jun 08 15:34:04 because I was at LFCS, and Camp KDE before that Jun 08 15:34:17 so I was there like a week before, if I see the dates correctly Jun 08 15:34:19 at the same hotel Jun 08 15:34:26 actually, that's where I heard about Yocto Jun 08 15:34:53 right Jun 08 15:37:30 dvhart: reading this manual, I'm curious -- is there any project-tracking that Yocto does for the kernel, outside of bugzilla/mailing lists? Jun 08 15:37:53 there are some feature/tasks on the 1.1 schedule: Jun 08 15:38:09 https://wiki.yoctoproject.org/wiki/Yocto_1.1_Schedule Jun 08 15:38:22 but I'd like to see that rolled up into bugzilla with milestones, etc as well Jun 08 15:38:46 I see Jun 08 15:38:53 (also, I'd suggest that you guys get SSL running on the site -- nobody likes logging into unencrypted sites :-) ) Jun 08 15:39:13 what did you need to log in for/ Jun 08 15:39:14 ? Jun 08 15:39:19 report bugs, for instance Jun 08 15:39:53 heh, right Jun 08 15:40:05 that message for ssl is rather ironic... Jun 08 15:40:12 sgw, is that on the list to get fixed? ^ Jun 08 15:40:55 * jefferai wonders what population of devs on Yocto came from OpenEmbedded/Linaro/Intel and how many are funded to work on it Jun 08 15:42:01 dvhart: ack Jun 08 15:42:06 jefferai, changes daily - with more and more people joining from both the corporate and private space Jun 08 15:42:15 ah, cool Jun 08 15:42:22 sgw, great, thanks! Jun 08 15:42:32 sgw, with proper certificates too I presume ;-) Jun 08 15:42:40 seems to be one of things that gets overlooked a lot Jun 08 15:42:48 There are just obvious signs of a project with some non-trivial amount of funding Jun 08 15:42:51 dvhart: nah, we will just make one up! Jun 08 15:42:58 so it made me curious Jun 08 15:43:02 the only thing worse than logging into an unencrypted site, is logging in to one that gives you security warnings every time! Jun 08 15:43:13 "Get me out of here!" Jun 08 15:43:33 jefferai, no doubt that Intel and WindRiver have put some considerable effort into bootstrapping Jun 08 15:43:39 yeah Jun 08 15:44:08 With the new infrastructure coming on line here soon we should have new certs also. Bugzilla will be one of the later things moved though. Jun 08 15:44:28 sgw, thanks for update. Jun 08 15:44:35 is there a bug for that? Jun 08 15:44:38 ;-) Jun 08 15:45:10 HEADS UP FOR ALL: We will be bringing the Autobuilder down later today to move it, this means the primary source mirror will be off line for an hour or less. Jun 08 15:45:37 sgw, that went to the list as well right? Jun 08 15:47:16 yes I think last week, need to get beth to resend. Jun 08 15:48:11 dvhart: regarding tree construction, I'm unclear on one bit after reading it: when creating a project-specific kernel, does it apply the generated meta-series to the BSP-specific branch, or does it apply the BSP-specific-branch changes *plus* everything else to the baseline kernel? Jun 08 15:48:53 plu everything else Jun 08 15:48:58 it's a hierarchy Jun 08 15:49:09 so the bsp branch is a leaf node of a tree Jun 08 15:49:20 and you get all the changes that go into the "parent" branches as well Jun 08 15:49:21 right Jun 08 15:49:28 I guess what I'm saying is Jun 08 15:49:32 when you make a project-specific kernel Jun 08 15:49:47 does it basically create a new git branch for your project, based off of some existing BSP branch Jun 08 15:50:00 or if not, what does it do? Jun 08 15:50:55 well, you would have to create the branch, so for instance, lets say you want a kernel for a jrb board Jun 08 15:51:00 you would create a branch: Jun 08 15:51:06 yocto/standard/jrb Jun 08 15:51:13 that you based on yocto/standard/base Jun 08 15:51:23 then you add any changes to the source in the jrb branch Jun 08 15:51:33 and write the scc files to include in jrb specific config fragments Jun 08 15:51:35 yeah Jun 08 15:51:41 so if you want a custom kernel based off of beagleboard Jun 08 15:51:42 (in the meta dir) Jun 08 15:51:57 you would create yocto/standard/blech that is based off of yocto/standard/beagleboard yes? Jun 08 15:52:27 maybe my misunderstanding is when the guide talks about custom "projects" does it mean new BSPs or projects based off of existing BSPs Jun 08 15:52:59 that would work Jun 08 15:53:03 OK Jun 08 15:53:18 but better to call it yocto/standard/beagleboard/blech Jun 08 15:53:30 zeddii, yeah... but that means we have to create beagleboard/base Jun 08 15:53:35 although .. that will make git barf :P Jun 08 15:53:42 since the bsps aren't currently intended to be derived from Jun 08 15:53:46 right :) Jun 08 15:53:48 yep. dvhart. I actually have changes for that here. Jun 08 15:53:57 just always create a /base and some extra smarts. Jun 08 15:54:03 zeddii, good plan Jun 08 15:54:09 I just need to get these renames and 3.0-rc2 out first .. Jun 08 15:54:13 * zeddii rushes around Jun 08 15:54:15 :) Jun 08 15:54:18 heh Jun 08 15:54:32 jefferai, http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-2.6.37-contrib/ Jun 08 15:54:48 jefferai, you'll see two branches in the recently created branch, obviously named Jun 08 15:54:55 one for meta and one for the bsp Jun 08 15:55:01 dvhart/meta/beagleboard Jun 08 15:55:06 dvhart/yocto/standard/beagleboard-ti-patched-yocto Jun 08 15:55:22 yep, see them Jun 08 15:55:39 jefferai, before you use these, you'll need to get setup for local kernel development Jun 08 15:55:51 using the meta-kernel-dev layer in poky-extras.git Jun 08 15:56:02 and following the example I gave in the turorial video Jun 08 15:56:03 I'm probably good; I did the entire build of poky-sato Jun 08 15:56:16 jefferai, no that uses a remote linux-yocto source Jun 08 15:56:17 including it building the kernel for the beagleboard Jun 08 15:56:18 ah Jun 08 15:56:20 ok Jun 08 15:56:21 you need one locally Jun 08 15:56:25 then I'll look in the video :-) Jun 08 15:56:44 so you'll need to checkout a bare and a regulare linux-yocto-2.6.37.git repository Jun 08 15:57:03 you'll point the build at the bare one for the SRCURI Jun 08 15:57:23 and then push the branches from contrib to the meta and yocto/base/beagleboard branch names in the bare repo Jun 08 15:57:43 are these the same instructions? (haven't looked at the video yet) http://www.yoctoproject.org/docs/1.1/kernel-manual/kernel-manual.html#bsp-creating Jun 08 15:58:11 that's the idea yes Jun 08 15:58:20 although you won't be needing a bbappend just yet Jun 08 15:58:27 we'll be working in the build tree itself until it works Jun 08 15:58:30 Hm. Alternately I could simply checkout the contrib git repo bare, yes? Jun 08 15:58:36 then I can easily update when you add any patches Jun 08 15:58:36 no Jun 08 15:58:43 ah Jun 08 15:58:55 add contrib as a remote to your non-bare version Jun 08 15:59:00 then you will have to push like this: Jun 08 15:59:18 git push localbare contrib/dvhart/meta/beagleboard:meta Jun 08 15:59:50 git push localbare contrib/dvhart/yocto/standard/beagleboard:yocto/standard/beagleboard Jun 08 16:00:13 ah Jun 08 16:00:22 note you're replacing the dvhart branch naming from the branches in the bare repo so the recipes can use the regular naming Jun 08 16:00:22 I see, so they have to be specifically-named branches Jun 08 16:00:26 yep Jun 08 16:00:27 * dvhart nods Jun 08 16:00:36 is there a specific place to put these clones? Jun 08 16:00:40 yocto/, build/? Jun 08 16:00:45 er, I mean Jun 08 16:00:49 poky/ , build/ Jun 08 16:00:49 no, wherever you like Jun 08 16:00:54 ok Jun 08 16:01:00 and then modify the config file to find it yes? Jun 08 16:01:02 you'll specify in a KSRC= variable Jun 08 16:01:06 right Jun 08 16:01:09 I do it in bblayers.conf Jun 08 16:01:18 described in the video Jun 08 16:01:20 yeah Jun 08 16:01:30 but it's a long one... I understand prefering the text Jun 08 16:01:36 I need to get it out in written form Jun 08 16:01:47 I don't mind watching the video -- but as long as you're giving me good info in here I haven't gotten to it yet Jun 08 16:01:48 :-) Jun 08 16:01:53 heh Jun 08 16:02:18 get cloning, /me caffeinates and tries to get back to a working kernel/config to start bisecting from Jun 08 16:02:44 sure Jun 08 16:03:53 on a side note, I attended MeeGo Conf 2011 recently; it seems to me that with Intel basically in control of MeeGo, MeeGo could certainly benefit from pushing Yocto tech into it Jun 08 16:04:10 it'd be nice to see MeeGo having more broad board support Jun 08 16:04:19 and then the people working on MeeGo could concentrate on its UI bits Jun 08 16:06:15 It's a comment we get fairly often. There is a subtle, but significant, difference in the aims and requirements of the two projects. Jun 08 16:06:37 perhaps some of the kernel tech could be applied though Jun 08 16:09:20 I'm actually pretty aware of the difference in the aims/requirements...my suggestion wasn't meant as "hey, the projects should merge", but simply that getting some of what Yocto is doing into MeeGo's build environment might help MeeGo diversify while lessening duplicate development effort; right now, MeeGo actually runs/works on a pretty small number of devices Jun 08 16:10:12 But I do know that Intel wants to push their low-power chips (Atom and the like) so they're in a tough spot; make MeeGo more open to broad device support and they lose one of the selling points they have Jun 08 16:11:00 re the build, it appears that obs and such are all woven in with the compliance bits Jun 08 16:11:09 but, I'm no expert on MeeGo Jun 08 16:12:02 ya, I've used MeeGo, but thats about it.. but from my understanding MeeGo is more or less a binary based distro, with a static configuration, in order to deal with the compliance Jun 08 16:12:29 Yocto is source derived with variable (source) configurations, so the API isn't necessarily stable.. Jun 08 16:12:36 "for more detail, ask Dirk Hohndel" Jun 08 16:13:01 right, bbxm kernel... /me jumps down the rabbit hole Jun 08 16:53:36 dvhart: hey, so I have all of the repos cloned and remotes added and all Jun 08 16:53:51 when I try to push your meta to my local bare repo I get a complaint about it not being a fast forward Jun 08 16:53:54 did you rewrite history at some point? Jun 08 16:54:27 hrm Jun 08 16:54:37 I wouldn't have thought as far back as that Jun 08 16:54:55 did you get that for each? Jun 08 16:55:11 haven't tried both yet, just meta Jun 08 16:55:12 try rebasing each to the original Jun 08 16:55:24 yeah, my meta was behind when I pushed I think Jun 08 16:55:33 try a "git rebase meta" Jun 08 16:55:34 first Jun 08 16:55:37 then push Jun 08 16:55:53 sorry about that Jun 08 16:56:02 bruce made some changes to meta while I was working on it Jun 08 16:56:32 hm, git rebase meta onto what? Jun 08 16:57:33 sorry Jun 08 16:57:40 git checkout dvhart/meta/beagleboard Jun 08 16:57:47 git rebase origin/meta Jun 08 16:57:55 git push bare dvhart/meta/beagleboard:meta Jun 08 16:58:07 ok, so in the contrib repo Jun 08 16:58:28 uhm depends on how you set it up... Jun 08 16:58:31 ah, true Jun 08 16:58:51 I have a single non-bare repo cloned from the main repo with contrib as a remote Jun 08 17:00:07 yeah, that's how I set it up Jun 08 17:00:27 with a local contrib repo as a remote, or the upstream contrib repo as a remote? Jun 08 17:01:32 * jefferai adds upstream for now Jun 08 17:01:38 I had it local, but that's rather a pain Jun 08 17:04:51 upstream Jun 08 17:04:59 no need for a local contrib Jun 08 17:05:01 yeah Jun 08 17:05:09 * jefferai is rebasing Jun 08 17:05:12 lots of patches :-) Jun 08 17:05:25 btw, thanks for walking me through this, hopefully I'll end up being of use Jun 08 17:12:08 stuffcorpse: btw, what the hell are you doing here :-) Jun 08 17:14:54 dvhart: just to check, when you referenced your yocto/standard/beagleboard branch, you meant the beagleboard-ti-patched-yocto branch yes? Jun 08 17:15:24 correct Jun 08 17:16:58 zeddii, the linux-omap merge appears to have busted usb hub support on the bbxm :( Jun 08 17:16:58 okay, all done Jun 08 17:17:14 tim to build linux-omap and see if even that works Jun 08 17:17:16 dvhart, there's always a catch .. isn't there. Jun 08 17:17:21 sigh Jun 08 17:17:33 nothing like merging 3 trees together Jun 08 17:18:01 zeddii, did you run into any merge issues? Jun 08 17:18:17 dvhart, almost none. I just had to fixup some makefiles to account for lttngs. Jun 08 17:18:21 lttng that is. Jun 08 17:18:25 hrm Jun 08 17:18:36 okay, I'll build linux-omap from meta-ti and see if that works Jun 08 17:18:51 yep. isolate and conquer Jun 08 17:18:54 dvhart: so now I just put KSRC = "/home/jmitchell/yocto/kernelsource/linux-yocto-2.6.37.git" into bblayers.conf and theoretically should just have to rebuild the kernel package yes? Jun 08 17:18:55 I did test the stock kernel (angstrom) that ships with the board, that still works - so not hardware Jun 08 17:19:09 jefferai, that is your bare repo? Jun 08 17:19:12 yep Jun 08 17:19:15 jefferai, and you have meta-kernel-dev enabled? Jun 08 17:19:30 jefferai, actually that is now KSRC_linux_yocto now Jun 08 17:19:49 no, and roger Jun 08 17:20:12 http://pastebin.com/aWyfi5Uy Jun 08 17:20:17 that is my bblayers.conf Jun 08 17:20:20 would that be in EXTRA_IMAGE_FEATURES? Jun 08 17:20:21 ok Jun 08 17:20:38 meta-kernel-dev is a layer Jun 08 17:20:45 in the poky-extras.git repository Jun 08 17:21:09 http://git.pokylinux.org/cgit/cgit.cgi/poky-extras Jun 08 17:21:24 erm Jun 08 17:21:26 http://git.yoctoproject.org/cgit/cgit.cgi/poky-extras Jun 08 17:21:32 (same thing, but...) Jun 08 17:21:39 hm, ok Jun 08 17:21:45 what's meta-yocto Jun 08 17:21:47 vs. meta? Jun 08 17:22:14 meta-yocto is the yocto project meta data in addition to what is in meta (oe-core) Jun 08 17:22:24 hm, ok Jun 08 17:22:29 it includes the yocto support for each of the hw platforms (oe-core is qemu only) Jun 08 17:22:29 hard to know what is in each, at first :-) Jun 08 17:22:33 ah, ok Jun 08 17:22:37 uhm, yeah Jun 08 17:22:42 no argument here Jun 08 17:23:07 * dvhart thinks s/meta/meta-oe-core/ would make it explicit Jun 08 17:23:55 so if I read your conf file right you have a git clone of poky, and inside the git clone you created a directory named layers, and inside there you did a git clone of poky-extras Jun 08 17:24:06 yessir Jun 08 17:24:16 as well as many others Jun 08 17:24:28 can poky-extras live in a separate dir outside the poky git dir? Jun 08 17:24:43 (then I don't have to e.g. create a branch with my changes from upstream just to keep things sane) Jun 08 17:26:37 otherwise I could create a custom branch that differs only in the addition of a .gitignore, or so Jun 08 17:27:12 or perhaps layers/ should be in the official .gitignore :-) Jun 08 17:29:43 all of the above work :) Jun 08 17:30:03 heh, ok Jun 08 17:30:13 I haven't had any trouble - but adding layers to .gitignore sounds like a plan Jun 08 17:30:14 * dvhart adds Jun 08 17:30:16 I wasn't sure if the layers require relative paths Jun 08 17:30:27 nope, mine are all explicit Jun 08 17:32:33 great, so at this point I should be able to rerun bitbake -k poky-image-sato, yes? Jun 08 17:33:01 (I figure that adding meta-yocto might have caused some things to change so better to give all things a chance to rebuild...) Jun 08 17:34:11 hmm Jun 08 17:34:15 Jefro, ping Jun 08 17:34:29 dvhart: btw, regarding your paste above: git convention is for bare directories to have .git at the end, and non-bare directories to have no extension Jun 08 17:35:12 jefferai, huh, news to me. My convention has been to add .git to all my development git dirs (not the layers) Jun 08 17:35:26 jefferai, is this documented somewhere? Jun 08 17:35:26 heh Jun 08 17:35:30 not sure Jun 08 17:35:38 but that's why when you do a bare clone the dir defaults to .git at the end Jun 08 17:35:43 and when you do a normal clone it doesn't Jun 08 17:35:55 that seems like good evidence Jun 08 17:36:03 of course, do what works for you Jun 08 17:36:14 in this case it was clear it wasn't a bare dir since you referenced non-bare-git-dir directories :-) Jun 08 17:36:16 now that I have __git_ps1 in my prompt, I don't really need the .git appendage any longer Jun 08 17:36:31 thanks Jun 08 17:36:44 sure Jun 08 17:36:58 so at this point re-run bitbake to generate the kernel? Jun 08 17:37:18 you have a built tree at the moment? Jun 08 17:37:23 yes Jun 08 17:37:29 bitbake linux-yocto -c fetch -f Jun 08 17:37:39 that will force it to back up and refetch with the new sources Jun 08 17:37:43 although Jun 08 17:37:46 start with: Jun 08 17:37:56 bitbake linux-yocto -c cleanall Jun 08 17:38:04 then just do a bitbake linux-yocto Jun 08 17:38:27 ok Jun 08 17:38:37 won't need to re-build other packages from adding meta-yocto? Jun 08 17:39:07 you didn't have meta-yocto before? Jun 08 17:39:16 nope Jun 08 17:39:18 just meta Jun 08 17:39:22 huh Jun 08 17:39:36 http://pastebin.com/raw.php?i=H1qc5y59 Jun 08 17:39:38 I guess it depends on what you are wanting to do Jun 08 17:40:05 I'm not sure, as I'm not entirely clear on the difference ... you said that meta only builds for qemu, but I was able to boot off the beagleboard with the generated image just fine... Jun 08 17:40:52 (note that I'm on the bernard git branch; perhaps things are different on master?) Jun 08 17:41:16 ah Jun 08 17:41:17 yes Jun 08 17:41:27 there is no division in bernard Jun 08 17:41:59 you got the error because the meta-yocto directory doesn't exist :-) Jun 08 17:42:04 you can whack that from your bblayers Jun 08 17:42:14 or you can build from master Jun 08 17:42:24 I think just for kernel work... you should be fine Jun 08 17:43:51 Crofton pong Jun 08 17:44:13 ab meeting in 20 minuts? Jun 08 17:45:02 in general if there is a reason to stick on master (for instance, easier collaboration/testing of your fixes) then I don't mind doing it Jun 08 17:45:09 or any other branch Jun 08 17:45:37 (the meta-yocto directory does actually exist, but the only thing in it in bernard is recipes-core) Jun 08 17:47:42 Crofton yep - phone bridge in just second Jun 08 17:48:16 I may get pulled away, working in MV this week Jun 08 17:56:50 jefferai, while developing the linux-yocto kernel recipe and such... I _think_ you'll be ok on bernard Jun 08 17:56:58 jefferai, we can switch if we hit issues Jun 08 17:57:40 ok Jun 08 18:01:29 so something I'm not clear on -- how come when running bitbake linux-yocto, it repackages a bunch of other packges? do_package_write/do_package_ipk -- no actual recompilation though Jun 08 18:01:45 last time I ran bitbake poky-image-sato it finished all tasks... Jun 08 18:02:47 my telephone skillz are failing Jun 08 18:06:44 jefferai, hrm Jun 08 18:06:49 jefferai, which packages? Jun 08 18:06:52 although it did refresh cache Jun 08 18:07:22 jefferai, sometimes the dependencies surprise me still Jun 08 18:07:35 let's see, a sampling: module-init-tools, gcc-runtime, db, openssl, bzip2, libtool, git, pseudo, rpm, file, pax-utils, opkg-utils, python, ncurses... Jun 08 18:08:04 it's not really the dependencies that surprise me, but more why it's deciding to repackage all of these -- not recompile, just rewrite the packages Jun 08 18:29:37 dvhart: yikes: http://pastebin.com/raw.php?i=3Yp0n0zt Jun 08 18:29:40 that's during clean Jun 08 18:30:01 build didn't work either, tried to fetch some wonky paths Jun 08 18:30:44 yikes Jun 08 18:30:59 can you paste your log.do_fetch ? Jun 08 18:34:56 retrying fetch Jun 08 18:35:00 it tried downloading from e.g. http://autobuilder.yoctoproject.org/sources/git2_.home.jmitchell.yocto.kernelsource.linux-yocto-2.6.37.git.tar.gz Jun 08 18:35:22 ok, and you have meta-kernel-dev in your bbclass? Jun 08 18:35:23 lots and lots of those "X is not a literal" warnings Jun 08 18:35:26 yes Jun 08 18:35:37 right now it's cloning from my own bare repo Jun 08 18:35:45 but that wasn't the first thing it tried Jun 08 18:36:00 oh Jun 08 18:36:07 ok Jun 08 18:36:15 not sure why it tries the mirror first Jun 08 18:36:25 there are some MIRROR flags that can set to avoid that Jun 08 18:36:35 but if it's cloning properly, I wouldn't worry about it Jun 08 18:37:05 it wasn't earlier Jun 08 18:37:23 unfortunately I had that in a screen session and Ubuntu's screenrc sucks, so I couldn't get all the output Jun 08 18:37:31