<div dir="ltr"><div dir="ltr"><div dir="ltr">There are other rare reproducers which don't involve cp/install (e.g. older qmake was triggering it quite often as well), I've mentioned some in:<div><a href="https://bugzilla.yoctoproject.org/show_bug.cgi?id=12434">https://bugzilla.yoctoproject.org/show_bug.cgi?id=12434</a><br></div><div><br></div><div>glibc-locale is the most common one for sure as pretty much everybody is building that one, I don't have objection converting this from cp to install to prevent this random error (very rare random failure doesn't really help with #12434 reproducer and whoever work on it, can either revert this change or try to reproduce with something else) - I've included few hundreds of INSANE_SKIPs to ignore _random_ host-user-contaminated QAs in LG layers to prevent our builds failing randomly and the one for glibc-locale is the longest part:</div><div><a href="https://github.com/webosose/meta-webosose/blob/master/meta-webos/recipes-core/glibc/glibc-locale_%25.bbappend">https://github.com/webosose/meta-webosose/blob/master/meta-webos/recipes-core/glibc/glibc-locale_%25.bbappend</a><br></div><div><br></div><div>Regards,</div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Feb 7, 2019 at 3:50 PM Khem Raj <<a href="mailto:raj.khem@gmail.com">raj.khem@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Thu, Feb 7, 2019 at 1:00 AM Richard Purdie<br>
<<a href="mailto:richard.purdie@linuxfoundation.org" target="_blank">richard.purdie@linuxfoundation.org</a>> wrote:<br>
><br>
> On Wed, 2019-02-06 at 16:35 -0800, Khem Raj wrote:<br>
> > This has been a constant source of trouble for build failures due to host-user-contaminated QA<br>
> > errors of sort<br>
> ><br>
> > ERROR: QA Issue: glibc-locale: /glibc-binary-localedata-ca-es+valencia/usr/lib/locale/ca_ES@valencia/LC_MONETARY is owned by uid 3004, which is the same as the user running bitbake. This may be due to host contamination [host-user-contaminated]<br>
> ><br>
> > So far we have tried to mould cp command into not carrying the build<br>
> > user permissions into install area but it is never entirely fixed since<br>
> > the issue keeps popping up in various scenes<br>
> ><br>
> > This patch replaces use of cp with install utility and specifies install<br>
> > mode for files explcitly<br>
> ><br>
> > Signed-off-by: Khem Raj <<a href="mailto:raj.khem@gmail.com" target="_blank">raj.khem@gmail.com</a>><br>
> > ---<br>
> > meta/recipes-core/glibc/glibc-locale.inc | 44 ++++++++++++++----------<br>
> > 1 file changed, 25 insertions(+), 19 deletions(-)<br>
> ><br>
> > diff --git a/meta/recipes-core/glibc/glibc-locale.inc b/meta/recipes-core/glibc/glibc-locale.inc<br>
> > index 6384f9cbf1..9b256a5108 100644<br>
> > --- a/meta/recipes-core/glibc/glibc-locale.inc<br>
> > +++ b/meta/recipes-core/glibc/glibc-locale.inc<br>
> > @@ -72,27 +72,33 @@ FILES_localedef = "${bindir}/localedef"<br>
> > LOCALETREESRC = "${COMPONENTS_DIR}/${PACKAGE_ARCH}/glibc-stash-locale"<br>
> ><br>
> > do_install () {<br>
> > - mkdir -p ${D}${bindir} ${D}${datadir}<br>
> > - if [ -n "$(ls ${LOCALETREESRC}/${bindir})" ]; then<br>
> > - cp -R --no-dereference --preserve=mode,links ${LOCALETREESRC}/${bindir}/* ${D}${bindir}<br>
> > - fi<br>
> > - if [ -n "$(ls ${LOCALETREESRC}/${localedir})" ]; then<br>
> > - mkdir -p ${D}${localedir}<br>
> > - cp -R --no-dereference --preserve=mode,links ${LOCALETREESRC}/${localedir}/* ${D}${localedir}<br>
> > - fi<br>
> > + install -d ${D}${bindir}<br>
> > + find "${LOCALETREESRC}/${bindir}" -maxdepth 1 -type f \<br>
> > + -exec install -m 0755 -t "${D}${bindir}" {} \;<br>
> > +<br>
> > + for d in . $(find "${LOCALETREESRC}/${localedir}" -type d -printf '%P ') ; do<br>
> > + install -d "${D}${localedir}/$d"<br>
> > + find "${LOCALETREESRC}/${localedir}/$d" -maxdepth 1 -type f \<br>
> > + -exec install -m 0644 -t "${D}${localedir}/$d" {} \;<br>
> > + done<br>
> > if [ ${@d.getVar('PACKAGE_NO_GCONV')} -eq 0 ]; then<br>
> > - mkdir -p ${D}${libdir}<br>
> > - if [ -e ${LOCALETREESRC}/${libdir}/gconv ]; then<br>
> > - cp -R --no-dereference --preserve=mode,links ${LOCALETREESRC}/${libdir}/gconv ${D}${libdir}<br>
> > - fi<br>
> > - if [ -e ${LOCALETREESRC}/${datadir}/i18n ]; then<br>
> > - cp -R --no-dereference --preserve=mode,links ${LOCALETREESRC}/${datadir}/i18n ${D}${datadir}<br>
> > - fi<br>
> > - fi<br>
> > - if [ -e ${LOCALETREESRC}/${datadir}/locale ]; then<br>
> > - cp -R --no-dereference --preserve=mode,links ${LOCALETREESRC}/${datadir}/locale ${D}${datadir}<br>
> > + for d in . $(find "${LOCALETREESRC}/${libdir}/gconv" -type d -printf '%P ') ; do<br>
> > + install -d "${D}${libdir}/gconv/$d"<br>
> > + find "${LOCALETREESRC}/${libdir}/gconv/$d" -maxdepth 1 -type f \<br>
> > + -exec install -m 0755 -t "${D}${libdir}/gconv/$d" {} \;<br>
> > + done<br>
> > + for d in . $(find "${LOCALETREESRC}/${datadir}/i18n" -type d -printf '%P ') ; do<br>
> > + install -d "${D}${datadir}/i18n/$d"<br>
> > + find "${LOCALETREESRC}/${datadir}/i18n/$d" -maxdepth 1 -type f \<br>
> > + -exec install -m 0644 -t "${D}${datadir}/i18n/$d" {} \;<br>
> > + done<br>
> > fi<br>
> > - cp -R --no-dereference --preserve=mode,links ${LOCALETREESRC}/SUPPORTED ${WORKDIR}<br>
> > + for d in . $(find "${LOCALETREESRC}/${datadir}/locale" -type d -printf '%P ') ; do<br>
> > + install -d "${D}${datadir}/locale/$d"<br>
> > + find "${LOCALETREESRC}/${datadir}/locale/$d" -maxdepth 1 -type f \<br>
> > + -exec install -m 0644 -t "${D}${datadir}/locale/$d" {} \;<br>
> > + done<br>
> > + install -m 0644 ${LOCALETREESRC}/SUPPORTED ${WORKDIR}/SUPPORTED<br>
> > }<br>
> ><br>
> > inherit libc-package<br>
><br>
> The trouble is this is a workaround. The cp commands should work and<br>
> there is some underlying issue in pseudo causing this. We really need<br>
> to figure out what that is since this will likely just mean we see the<br>
> problem somewhere else :(<br>
<br>
so far this is the only place where it shows in world builds that<br>
meta-oe does which includes many layers.<br>
<br>
><br>
> I still suspect some kind of inode number reuse problem which these cp<br>
> commands trigger...<br>
<br>
cp and install are not same when it comes to how they operate<br>
underneath. install is better when it comes to what we are doing here<br>
it also gives better control of permissions and mods,as a recipe writer<br>
someone would prefer then to let the tool ( cp ) assume it.<br>
<br>
So there might be a pseudo issue, I dont disagree but not obvious and<br>
I believe using cp is subpar anyway.<br>
<br>
><br>
> Cheers,<br>
><br>
> Richard<br>
><br>
-- <br>
_______________________________________________<br>
Openembedded-core mailing list<br>
<a href="mailto:Openembedded-core@lists.openembedded.org" target="_blank">Openembedded-core@lists.openembedded.org</a><br>
<a href="http://lists.openembedded.org/mailman/listinfo/openembedded-core" rel="noreferrer" target="_blank">http://lists.openembedded.org/mailman/listinfo/openembedded-core</a><br>
</blockquote></div>