[PATCH] ptest: fix file ownerships in ${PTEST_PATH}

[PATCH] ptest: fix file ownerships in ${PTEST_PATH}

[Ross Burton]

As most upstreams don't have installable test suites it's fairly common to copy
files directly out of a source tree for ptests, but this results in files in the
recipe being owned by the user running bitbake:

  WARNING: QA Issue: .../sed/4.2.2-r0/packages-split/sed-ptest/usr/lib64/
  sed/ptest/testsuite/bug-regex21 is owned by uid 1000, which is the same
  as the user running bitbake. This may be due to host contamination
  [host-user-contaminated]

Instead of needing to fix this in every recipe that has this problem simply
chown the files to root:root in do_install_ptest_base.

Signed-off-by: Ross Burton <ross.burton@intel.com>
---
 meta/classes/ptest.bbclass | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/classes/ptest.bbclass b/meta/classes/ptest.bbclass
index 2ac9143..b5f470f 100644
--- a/meta/classes/ptest.bbclass
+++ b/meta/classes/ptest.bbclass
@@ -43,6 +43,7 @@ do_install_ptest_base() {
             oe_runmake DESTDIR=${D}${PTEST_PATH} install-ptest
         fi
         do_install_ptest
+        chown -R root:root ${D}${PTEST_PATH}
     fi
 }
 
-- 
2.3.2 (Apple Git-55)

Re: [PATCH] ptest: fix file ownerships in ${PTEST_PATH}

[Mike Looijmans]

Just posting a related idea here:

There are quite a few recipes that just contain a bunch of (data) files, and 
use a simple "cp -r" in the install phase. Instead of peppering these with 
"chown" calls, it might be better to create a small utility that basically 
runs the "install" command recursively, and replace the "cp -r" with 
"install_recursive".

On 09-09-15 14:09, Ross Burton wrote:
> As most upstreams don't have installable test suites it's fairly common to copy
> files directly out of a source tree for ptests, but this results in files in the
> recipe being owned by the user running bitbake:
>
>    WARNING: QA Issue: .../sed/4.2.2-r0/packages-split/sed-ptest/usr/lib64/
>    sed/ptest/testsuite/bug-regex21 is owned by uid 1000, which is the same
>    as the user running bitbake. This may be due to host contamination
>    [host-user-contaminated]
>
> Instead of needing to fix this in every recipe that has this problem simply
> chown the files to root:root in do_install_ptest_base.
>
> Signed-off-by: Ross Burton <ross.burton@intel.com>
> ---
>   meta/classes/ptest.bbclass | 1 +
>   1 file changed, 1 insertion(+)
>
> diff --git a/meta/classes/ptest.bbclass b/meta/classes/ptest.bbclass
> index 2ac9143..b5f470f 100644
> --- a/meta/classes/ptest.bbclass
> +++ b/meta/classes/ptest.bbclass
> @@ -43,6 +43,7 @@ do_install_ptest_base() {
>               oe_runmake DESTDIR=${D}${PTEST_PATH} install-ptest
>           fi
>           do_install_ptest
> +        chown -R root:root ${D}${PTEST_PATH}
>       fi
>   }
>
>



Kind regards,

Mike Looijmans
System Expert

TOPIC Embedded Products
Eindhovenseweg 32-C, NL-5683 KH Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
Telefax: +31 (0) 499 33 69 70
E-mail: mike.looijmans@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail

Re: [PATCH] ptest: fix file ownerships in ${PTEST_PATH}

[Christopher Larson]

[-- Attachment #1: Type: text/plain, Size: 1207 bytes --]

On Wed, Sep 9, 2015 at 5:38 AM, Mike Looijmans <mike.looijmans@topic.nl>
wrote:

> Just posting a related idea here:
>
> There are quite a few recipes that just contain a bunch of (data) files,
> and use a simple "cp -r" in the install phase. Instead of peppering these
> with "chown" calls, it might be better to create a small utility that
> basically runs the "install" command recursively, and replace the "cp -r"
> with "install_recursive".
>

Something like that doesn't seem unreasonable, so the classes/recipes don't
have to worry about the particulars of the recursive copy tool being used.

That said, doesn't cp -r result in correct ownership, since the files are
created without preserving permissions or ownership? I'm pretty sure it's
the cp -a / cp -pPr that we need to be more concerned with.

Note that with gnu cp, it's possible to tell it to preserve permissions,
but not ownership. It's not portable to non-gnu cp, but I don't know what
we care about that anyway.

Ex.: `cp -a --no-preserve=ownership`
-- 
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics

[-- Attachment #2: Type: text/html, Size: 1881 bytes --]