Ok, can you please open a bug for the changes to licensing info ? I'm working on the other items under review.
Alex On Fri, Dec 6, 2013 at 1:45 PM, Barros Pena, Belen < [email protected]> wrote: > > > 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 > > -- Alex Damian Yocto Project SSG / OTC
_______________________________________________ toaster mailing list [email protected] https://lists.yoctoproject.org/listinfo/toaster
