On Thursday 05 December 2013 18:18:16 Damian, Alexandru wrote:
> On Thu, Dec 5, 2013 at 3:27 PM, Paul Eggleton <[email protected]
> > 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 ?
I'm not an expert in this area, but I'd assume the most important aspect of
this is about what went into the image, so it might be similar to the rest of
the individual package information.
> > 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.
We handle differing installed versions in the rest of the build system; QA
ensure that things keep on working. I don't see how this is different.
> 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 ?
I think the first question is where we expect this to be usable. I think the
answer almost certainly is "almost every distro we currently support, where
practical". From there, we'll know what we need to support in Toaster.
> > > 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.
OK, understood.
> > > 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 ?
It occurs to me that the trouble with our initial model of a single file / line
is it isn't going to be able to effectively reflect how our task functions came
to be - they're really just a special case of variables and can thus be
prepended/appended in a number of different places to get the final function.
This kind of suggests that the history is what we ought to be using.
Cheers,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
_______________________________________________
toaster mailing list
[email protected]
https://lists.yoctoproject.org/listinfo/toaster
