8887 2016-01-06 12:09:42 +0000 Extensible SDK: pkgdata not populated after devtool build 2016-02-26 13:06:16 +0000 1 1 7 Build System, Metadata & Runtime OE-Core devtools / tool chain 2.0 x86 Multiple RESOLVED FIXED Medium+ normal 2.1 M2 1 bluelightning bluelightning alexandru.c.georgescu meta.mr.watcher meta.watcher anibal.limon --- --- Yes (doc changes required) oldest_to_newest 57575 0 bluelightning 2016-01-06 12:09:42 +0000 Within the extensible SDK, the only way to build a recipe within the workspace is "devtool build". This runs do_populate_sysroot for the recipe, but this won't populate the pkgdata with the result that "devtool add" after this may have trouble mapping dependencies that ought to be easily mapped. Here's an example (assuming you *don't* have libsoup as part of the SDK already): 1) devtool add http://ftp.gnome.org/pub/GNOME/sources/libsoup/2.52/libsoup-2.52.2.tar.xz 2) devtool edit-recipe libsoup and change EXTRA_OECONF to "--disable-vala" 3) devtool build libsoup 4) devtool add https://download.gnome.org/sources/gssdp/0.14/gssdp-0.14.12.tar.xz 5) devtool edit-recipe gssdp At step 5 you should see libsoup in DEPENDS instead of an unmapped libsoup-2.4 dependency, but you won't because the pkgdata is missing. I already went ahead and patched "devtool build" so do_packagedata gets run as well as do_populate_sysroot and the above then works; however the problem you then run into is do_packagedata depends on do_package, where there are one or two QA checks including the one for installed-vs-shipped, which is a fatal error in poky. We could hack it and force WARN_TO_ERROR to "" in the ext SDK configuration, but then a few of our devtool QA tests will still fail because the examples they use have unshipped files and they can't use that hack. 58159 1 bluelightning 2016-01-24 20:03:15 +0000 Fix merged to master: http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=d193531d5ead804380884e97e14ce00cbdccf494 In the end I've bitten the bullet and just enabled this; the installed-vs-shipped issue might present a bit of pain for users, but we can reduce that somewhat through documentation (as well as documenting how people building the SDK can configure the system so that the errors are turned into warnings).