Hi Martin!

On Mon, 10 May 2021, 12:25, Martin Jansa <martin.jansa@...> wrote:

On Mon, May 10, 2021 at 12:08:22PM +0300, Thomas Hill via lists.yoctoproject.org wrote:

On Fri, 7 May 2021, 15:28, Richard Purdie <richard.purdie@...>

On Fri, 2021-05-07 at 10:10 +0300, Thomas Hill via lists.yoctoproject.org wrote:

On Thu, 6 May 2021, 13:44 Martin Jansa <Martin.Jansa@...> wrote:

On Thu, May 6, 2021 at 10:57 AM Thomas Hill via lists.yoctoproject.org <tom.hill=inbox.lv@...> wrote:

On Mon, Nov 16, 2020 at 02:28 PM, Martin Jansa wrote:
https://github.com/webOS-ports/meta-webos-ports/commit/9fd17a67cdbed92df13a14b002a189b4c6c2d442
is an example where it triggers this error, but doesn't trigger the more common host-user-contaminated QA error (unless you happened to use UID 1001 on host for the user running bitbake).

 > I have here a similar problem with one of my own packages. It happens that my bitbake user uses UID 1001. Do you have more information why this is a problem? Should it be enough to change the UID to 1002 to get everything running?

No, you should chown the files to be owned by the expected user which exists in the image (probably root like in my commit). Changing the UID of the user on host is very bad work around (as it will fail for the next person building the same image with host user 1001.

Ok. Thanks. I can confirm that the change of the bitbake users UID to 1111
did not solve the issue.
I will open a new thread because I don't see why this fails. I use oe_runmake
in my do_install function and got the impression that oe_runmake should take 
care of this via fakeroot.

When you install files during do_install, you need to be clear about who
you want to own the end result.

See my other mail for more details - subject:
"Path ./package/usr/lib/libcryptopp.so.8 is owned by uid 1111, gid 1111, which doesn't match any ..."

If you do something like "touch ${D}/x", the it will be owned by the default
user which in a fakeroot context under pseudo is root.

If however you cp a file to ${D}/x, it would depend what you told cp
to do about ownership. If the original file was owned by user 1001, it
may try and preserve that.

I do not touch any files myself. The do_install function uses only
"oe_runmake install-lib". No "touch", no "cp", nothing.
The GNUmakefile uses "mkdir", "cp", "chmod" but I patched it so it
uses "install" instead of "cp" in my recipe.

We don't know what your code is doing in do_install but its almost certainly
not setting the file ownership correctly.

My other mail has more details. I did not append the GNUmakefile. It is
quite large. I think it ist easier to get it directly from the original git-repository.
<https://github.com/weidai11/cryptopp/blob/9dcc26c58213abb8351fbb1b2a7a1d2c667366e4/GNUmakefile>

0002_libcryptopp_8.2.0_use-install-instead-of-cp.patch from your recipe
might be interesting as well to guess what went wrong in your case.

Nothing fancy is going on. I only replace "cp" with "install" - see appended file.

Thanks for your time!

Tom