Hi Martin!

On Mon, 10 May 2021, 12:25, Martin Jansa <[email protected]> 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 
> > <[email protected]>
> > > 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 <[email protected]> wrote:
> > > > > On Thu, May 6, 2021 at 10:57 AM Thomas Hill via 
> > > > > lists.yoctoproject.org <[email protected]> 
> > > > > 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

Attachment: 0002_libcryptopp_8.2.0_use-install-instead-of-cp.patch
Description: Binary data

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#53447): https://lists.yoctoproject.org/g/yocto/message/53447
Mute This Topic: https://lists.yoctoproject.org/mt/78301741/21656
Group Owner: [email protected]
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-

Reply via email to