Fix two problems falling back to the "license" field from package.json when no license file is present: 1) The function that was supposed to return the license field value was always explicitly returning None, and this was never noticed (because the test cases never exercised the fallback as they provided license files for each module). 2) Fix the main package not falling back because it had a default of an empty list, which evaluates to '' instead of 'Unknown'. Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The extra directory next to the recipe should only be created if there are files to put into it; currently only the npm plugin does this. I didn't notice the issue earlier because the test was actually able to succeed under these circumstances if the recipe file came first in the directory listing, which was a fault in my original oe-selftest test; apparently on some YP autobuilder machines the order came out reversed. With this change we can put the oe-selftest test that highlighted the issue back to the way it was, with an extra check to reinforce that only a single file should be created. Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Allow plugins to create additional files to go alongside the recipe. The plugins don't know what the output filename is going to be, so they need to put the files in a temporary location and add them to an "extrafiles" dict within extravalues where the destination filename is the key and the temporary path is the value. devtool add was also extended to ensure these files get moved in and preserved upon reset if they've been edited by the user. Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If the user specifies an npm:// URL then the fetcher needs npm to be available to run, so check if it's available early rather than failing later. Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Rather than rolling all of an npm module's dependencies into the same package, split them into one module per package, setting the SUMMARY and PKGV values from the package.json file for each package. Additionally, mark each package with the appropriate license using the license scanning we already do, falling back to the license stated in the package.json file for the module if unknown. All of this is mostly in aid of ensuring all modules and their licenses now show up in the manifests for the image. Additionally we set the main LICENSE value more concretely once we've calculated the per-package licenses, since we have more information at that point. Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Matching license texts directly to md5sums only goes so far. Some licenses make the copyright statement an intrinsic part of the license statement (e.g. MIT) which of course varies between projects. Also, people often seem to take standard license texts such as GPLv2 and reformat them cosmetically - re-wrapping lines at a different width or changing quoting styles are seemingly popular examples. In order to match license files to their actual licenses more effectively, "crunch" out these elements before comparing to an md5sum. (The existing plain md5sum matching has been left in since it's a shortcut, and our list of crunched md5sums isn't a complete replacement for it.) As always, this code isn't providing any guarantees (legal or otherwise) that it will always get the license correct - as indicated by the accompanying comments the LICENSE values it writes out to the recipe are indicative and you should verify them yourself by looking at the documentation supplied from upstream for the software being built if you have any concerns. Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
For example, this picks up a file named MIT-LICENSE.txt. Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Make the following improvements to mapping items specified in AC_CHECK_PROG, AC_PATH_PROG and AX_WITH_PROG to recipes/classes: * Produce a map of native recipe -> binary for all binaries currently in STAGING_BINDIR_NATIVE and use this when mapping items * Add some more entries to the class map * Ignore autotools binaries since they are covered by the inherit of autotools * Ignore coreutils-native since that would almost always be a bogus dependency Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* Package names are actually case sensitive near as I can tell, so we shouldn't be lowercasing them everywhere. * Look for CMake packages in pkgdata and map those back to recipes, so we aren't dependent on the hardcoded mappings (though those are still preserved). * Avoid duplicates in the unmapped package list Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If you specify a local directory which happens to be a git repository with an origin remote (and it is in fact remote), we can use that for SRC_URI as implemented by OE-Core revision b143d414846854dc8b3e0a47358daf5646eded38, however we also need to set S if the recipe is going to be of any use fetching from that SRC_URI later. Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>