**** BEGIN LOGGING AT Thu Jun 23 02:59:56 2011 Jun 23 04:50:14 dvhart ping Jun 23 04:51:48 pong Jun 23 04:51:59 what's up jefferai Jun 23 04:52:02 erm... Jefro Jun 23 04:54:08 sorry, was typing in wrong window :) Jun 23 04:54:10 I restarted with sato instead of minimal and it appears to be going just fine Jun 23 04:54:31 load was very high (5) but fans were quiet, which is odd for this machine Jun 23 04:55:10 race condition between the cores? I did specify 4 threads Jun 23 07:21:46 dongxiao: ping? Jun 23 08:35:44 morning all Jun 23 13:57:22 fray: around? Jun 23 19:35:02 fray: ping Jun 23 19:35:07 here Jun 23 19:35:59 fray: the AB is dying on python_2.6.6 issues. :KeyError: PKGV Jun 23 19:36:18 update.. RP put in a patch for that soon after it was applied (at least he did in oe-core) Jun 23 19:36:56 commits (oe-core) ad098e40e8c57727892819e131bf18308bf244d2 & c2ce3573fb2816cd2023a56b364fae4c0f4455ae fix the issue Jun 23 19:37:37 fray: ok, ty! Jun 23 23:51:07 bluelightning: Ping. Jun 23 23:52:48 hi ReaperOfSouls Jun 23 23:53:03 sorry for not replying to your email yet Jun 23 23:54:34 No worries, I have been fairly snowed under the last couple weeks, so I totally understand. :) Jun 23 23:54:43 to be honest I have been waiting for Richard to weigh in in more detail; he's been otherwise engaged until just the last day or so Jun 23 23:55:55 just a thought, re remote layer fetching, is this something you definitely feel has to be integrated into bitbake itself or would an external python utility that could utilise the fetcher functionality in a similar way be sufficient? Jun 23 23:56:51 So personally we have been doing collection fetching for the better part of a year an a half, and it really does work fairly well as a method. Jun 23 23:57:30 Realistically in the cooker there is only a single line of code. We could set the remote fetching path completely in a BB_ option. Jun 23 23:57:33 ok Jun 23 23:59:06 FYI the "deadline" for inclusion of this patch (if it was necessarily a deadline) has been extended to M2 sprint D; the schedule wiki page may not yet be updated with that change Jun 23 23:59:57 We started out more or less doing what your suggestting when we first started a product on top of OE, and quickly moved to using it internally. Both can work. The primary reason for doing in process for us, was ealier version of bitbake it wasn't really easy to write external python apps hooking in the bb code. We really didn't want to rewrite the fetchers. Jun 24 00:00:34 Okay, I missed this week's meeting due to some family issues. Ill recheck it. Jun 24 00:00:54 s/using it/using remote fetching/ Jun 24 00:03:25 no worries, I don't think we covered it in that meeting in particular Jun 24 00:06:03 the configuration parsing and variable setting order still somewhat troubles me Jun 24 00:06:58 if we want to do the fetching within bitbake, I wonder if we can insert it after parsing local.conf and then clear the data dictionary, make it jump back to the start and read everything again Jun 24 00:07:54 Well most of the variables are set in the copy. I think TMP is set in the actual data dictionary, which we could move back. Jun 24 00:08:35 right, that would make it less of a concern Jun 24 00:08:41 The two wrt to path to check out and unpack are really the only ones that exist in the main data Jun 24 00:09:13 And those are new, though I would need to double check if I make sure they are evaluated rather then just the variable expression. Jun 24 00:09:18 obviously having them as setIfUnset avoids any issue of overriding except when someone is assuming that an ?= assignment is the first one Jun 24 00:09:41 Well the setunset is there now. Jun 24 00:09:55 But yeah. Jun 24 00:11:45 Well that and they are in copy of data as well. So someone down the line(except for the tmp we already touched on) now would never be effected cause as soon as the remove fetch is complete, those variables vanish. Jun 24 00:12:16 right Jun 24 00:12:30 I had missed that in the patch I have to admit Jun 24 00:13:17 It is okay. I alreayd fully admit I don't like that part of the patch. :) Jun 24 00:16:06 over the next few days I will try to take a look at the patch more closely and see how we can work in the functionality Jun 24 00:16:20 (it was on Ke's task list but he's now working on multilib) Jun 24 00:17:16 again, sorry for how long this has taken :/ Jun 24 00:18:51 It is fine, these days have been crazy for me too. Jun 24 00:19:35 ReaperOfSouls: are there other areas where you'd like to see work? (on bitbake/core classes or elsewhere within the yocto project) Jun 24 00:20:17 You want me to take the fetch*/layer.py and move it in to __init__.py so it is consistant with the rest of the stuff in that directory, or do we want to extract it and do a if on fetch2 vs fetch script. Jun 24 00:20:48 * bluelightning looks Jun 24 00:22:09 So the layering tooling is the other place I am primarily interested. I posted the content-tools repository on the list a couple weeks ago. I am not sure what you guys want to do with that, but if there are things that you can use from that or small changes that would be helpful, I can do that. Jun 24 00:27:15 yes, I think moving the fetch*/layer.py bits out would be a good idea; I would hope we could be at a point where no specific pieces need to be set up for any fetcher in order to have it work with remote layer fetching Jun 24 00:28:55 re the content tools, I had a look; as someone who has probably used bitbake mostly in much less organised environments than you have I think I would benefit from a more detailed example usage scenario Jun 24 00:38:30 Okay. Now that the meta-intel bits or more or less fixed wrt to the BBFILE_COLLECTIONS vars, ill build up a small example content server. But more or less The collection xml file describe a layer. Internally we also provide all the sources that go with that collection, so customers can more or less get all the content locally in one go. The solution xml files basically list all the collections/layers that are used to build what ev Jun 24 00:38:31 xml that describes meta-intel, openembedded-core, and any additional layers you need. Then you create a solution that would have paths to those collection xml files. Jun 24 00:40:26 For the end user you create a content server with the solutions and collections. They run oe-list and it tells then what is there, then they can pass that uri to oe-mirror to create a local mirror or to oe-project and it would create basically what the oe- setup script does, but uses the content tools to generate the bblayer based on the added solutions/colleciton xml files. Jun 24 00:42:02 The solution xml also provied a mechinsm for providing prebuilt binaries. Originially it was set up for prebuilt staging binaries, but I took a pass at making it work with the sstate code. Jun 24 00:42:19 IIRC it partially worked. Jun 24 00:43:18 cool Jun 24 00:49:25 bluelightning: In anycase they may be a good starting point. The start up script needs work with the addition of psuedo to the mix. And there is definately some room for improvement on the new features. Jun 24 00:50:35 ReaperOfSouls: so are "projects" geared to providing a "scratch" layer on top of a solution? or is there more to them than that? Jun 24 00:53:52 So in our current projects we drop an additional empty collection in there for the customer to use. However the project tools have "pass-through" collecitons/layers that you can add in. We have used ordering to determine priority, so there is a little more hand wringing here. Jun 24 00:54:52 * ReaperOfSouls actually likes the ordering is your priority, but it is what it is, and it provide a bit more control if it is specified in each layer. Jun 24 00:57:14 We also use a bit of code that finds bb files, and just pulls them in, rather then building a big bbfiles list. However this has created some headaches from time to time. It would be simple enough to add a empty layer with some reasonable values in the layer.conf such that an user could just drop recipes and a like. Jun 24 01:25:50 ReaperOfSouls: ok, thanks for the explanations Jun 24 01:26:15 time to get some sleep, past 2am here **** ENDING LOGGING AT Fri Jun 24 02:59:57 2011