Hi, Thanks for reviewing this. Comments below, also for Belen.
Alex On Thu, Dec 5, 2013 at 3:27 PM, Paul Eggleton <[email protected] > wrote: > Hi Alex, > > On Tuesday 26 November 2013 18:28:21 Damian, Alexandru wrote: > > I have a set of patches for review on: > > > > > http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=toaster/master > > Sorry for the delay (although we've had some changes in the mean time with > the > pkgdata changes). Reviewing the latest branch, most of the changes look OK, > however I did notice the following: > > > bitbake: toasterui: record recipe licensing information > > If do_populate_lic doesn't execute in this build we won't have the license > file > with this method, right? Is that going to be a problem? > Yep, license info in the required form is dependent on executing do_populate_lic. Belen - we need to either return to recipe-based info (relative paths) or live with missing info for Prebuilt tasks. Which way to go ? > bitbake: toaster: update to Django 1.5.4 > > I think if we do do this we need to provide people with instructions on > how to > use virtualenv to install 1.5.4 on their system. I'm also a bit concerned > about us requiring one specific minor release because a number of distros > are > using 1.5 versions other than 1.5.4 - there shouldn't be any incompatible > changes introduced in minor releases, so we ought to be able to work with > any > 1.5 release >= 1.5.4. > Installation instructions are included in the patch. Since we don't have the capability to test on multiple Django versions, I think the requirement to use a specific version is acceptable. Alternatively, we could just print an warning if a supposedly compatible but not identical Django version is used, instead of refusing to start. What do you think ? > > bitbake: toaster: enable debug mode > > You don't say *why* you're enabling this for all users - we don't normally > turn on BBDEBUG by default. Why is this needed? > Debug mode is enabled only if one starts toaster with "source toaster start debug" command line, i.e. not for all runs, just for debug runs. Since bitbake supports this, seems that toaster support is needed. > > bitbake: toaster: save extra data related to executed tasks > > > >+import pprint > > This doesn't seem to be needed. > > > + 'workdir' : d.getVar("WORKDIR", True), > > We can't do this. Apart from a few bits of old code that really shouldn't, > Bitbake knows nothing about WORKDIR, and that's intentional. If you > absolutely > need this, you'll need to collect it another way. I'm not even sure it > makes > sense when we're talking about a remote context, which we are going to be > in > soon; perhaps we should review how we handle this at the design level. > > > + 'filename' : d.getVarFlag(t, "filename"), > > + 'lineno' : d.getVarFlag(t, "lineno"), > > I've run this past Richard, and he thinks that we should try partially > enabling the variable tracking just for functions - sorry for going back > and > forth on this. What we'd need to do is check the performance impact of > doing > so - would you be able to look into that? > Actually, now I think that using variable history is not a good idea - for AST-parsed functions, the variable history points to the ast.py file :(. This patch needs more rework, as I discovered other corner cases, where the function name is inherited at runtime, e.g. autotools_do_configure is called instead of do_configure, but I still think that varflags is the right way to track the function definition. What problems do you see with that ? > > Cheers, > Paul > > -- > > Paul Eggleton > Intel Open Source Technology Centre > -- Alex Damian Yocto Project SSG / OTC
_______________________________________________ toaster mailing list [email protected] https://lists.yoctoproject.org/listinfo/toaster
