Yeah i don't want to disable stripping the Target files. Well actually, I'll take a look at patching the tree with a custom CMakeLists.txt file. It may not be that bad. Thanks Ross

Putting files in the target sysroot that are in fact native binaries. Don't do that. Can you not work with upstream to integrate the changes? Alternatively, if the native parts are relatively simple,

What are some nasty hack options? The major surgery would be less maintainable.

A target recipe can't drop files into the native sysroot, so it's either nasty hacks or major surgery. Ross

Hi Ross, Yes I've done what you mention before. In this case I already have a Target and Native recipe. The Project generates a Native artifact when building the Target. Not resolvable without

Either use BBCLASSEXTEND or write a -native recipe, build just the native parts in a foo-native recipe and depend on that to build foo and other recipes. For example, glib-2.0 DEPENDS on

On Wed, May 13, 2020 at 09:53:12AM -0400, Robert P. J. Day wrote: [...] > > it gets weirder ... the project i'm working with is based on morty > so that variable *would* still be relevant, but even

it gets weirder ... the project i'm working with is based on morty so that variable *would* still be relevant, but even adding "Unlicense" to that variable didn't stop the offending recipe from

That'll teach me to check in master instead of my release of Yocto :) Quentin

that variable is gone: commit 64daaf29e2c12c8b587bafdebf9409433187ddf7 Author: Peter Kjellerstedt <peter.kjellerstedt@...> Date: Wed Dec 11 17:48:14 2019 +0100 licenses.conf:

Hi Robert, I'm not sure, but there might be a need to add it to SRC_DISTRIBUTE_LICENSES in openembedded-core/meta/conf/licenses.conf. Quentin

as long as this requires only adding an Unlicense file to that directory, i can do that shortly. rday

On Wed, 13 May 2020, Quentin Schulz wrote: ... snip ... > If it's really widely used, maybe something to add to > openembedded-core/files/common-licenses/ ? So that you don't need > any of the

... +1 for adding Unlicense to openembedded-core's common-licenses regards;rl

Hi Robert, You can add a license to your layer by doing the following in conf/layer.conf: LICENSE_PATH += "${LAYERDIR}/licenses" and in there you put the Unlicense file named exactly the same with

colleague added a new recipe to a build, got a warning "The license listed Unlicense was not in the licenses collected for recipe python-filelock" and, sure enough, that source was released under

OK I found. Yes "opkg configure" will call /var/lib/opkg/info/*.postinst for packages marked as "unpacked" in /var/lib/opkg/status ex: Package: test-deployment-lic Version: 1.0-r0 Status: install ok

Reading recipes-devtools/run-postinsts/run-postinsts/run-postinsts and_save_postinsts_common (in rootfs.py) once more, it seems /etc/ipk-postinsts is only used if there is no package manager on the

Hi, This is a common problem. It is likely that I know which SoC supplier you are talking about and have had the exact same issues. We have managed to fix or workaround all of them. In most cases by

Hi, I am using a build environment based on the yocto project from one of the big HW suppliers in the mobile industries. They are continuously breaking the principles behind the yocto project and at