On 06/12/2013 11:44, "Paul Eggleton" <[email protected]> wrote:
>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. I spoke to Beth Flanagan about what kind of information is useful when it comes to licensing, and Paul is right. It is useful to know which licenses apply to a certain recipe, but when it comes to license files, you really want to provide information at the package level. Sorry about this: I should have spoken to Beth sooner. So what we should be showing is the full path to the license files in /build/tmp/deploy/licenses/ So, for busybox: .../build/tmp/deploy/licenses/busybox/generic_bzip2.txt .../build/tmp/deploy/licenses/busybox/generic_GPLv2.txt .../build/tmp/deploy/licenses/busybox/LICENSE.txt I can open enhancements to remove licensing_info from the recipes table and add a license_files field to the package information. Let me know if that would be ok. We should probably also provide the path to the license manifest as part of the image 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
