| Message ID | 20190207003537.7135-1-raj.khem@gmail.com |
|---|---|
| State | New |
| Headers | show |
| Series | glibc-locale: Rewrite do_install using install utility instead of cp | expand |
On Wed, 2019-02-06 at 16:35 -0800, Khem Raj wrote: > This has been a constant source of trouble for build failures due to host-user-contaminated QA > errors of sort > > 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] > > So far we have tried to mould cp command into not carrying the build > user permissions into install area but it is never entirely fixed since > the issue keeps popping up in various scenes > > This patch replaces use of cp with install utility and specifies install > mode for files explcitly > > Signed-off-by: Khem Raj <raj.khem@gmail.com> > --- > meta/recipes-core/glibc/glibc-locale.inc | 44 ++++++++++++++---------- > 1 file changed, 25 insertions(+), 19 deletions(-) > > diff --git a/meta/recipes-core/glibc/glibc-locale.inc b/meta/recipes-core/glibc/glibc-locale.inc > index 6384f9cbf1..9b256a5108 100644 > --- a/meta/recipes-core/glibc/glibc-locale.inc > +++ b/meta/recipes-core/glibc/glibc-locale.inc > @@ -72,27 +72,33 @@ FILES_localedef = "${bindir}/localedef" > LOCALETREESRC = "${COMPONENTS_DIR}/${PACKAGE_ARCH}/glibc-stash-locale" > > do_install () { > - mkdir -p ${D}${bindir} ${D}${datadir} > - if [ -n "$(ls ${LOCALETREESRC}/${bindir})" ]; then > - cp -R --no-dereference --preserve=mode,links ${LOCALETREESRC}/${bindir}/* ${D}${bindir} > - fi > - if [ -n "$(ls ${LOCALETREESRC}/${localedir})" ]; then > - mkdir -p ${D}${localedir} > - cp -R --no-dereference --preserve=mode,links ${LOCALETREESRC}/${localedir}/* ${D}${localedir} > - fi > + install -d ${D}${bindir} > + find "${LOCALETREESRC}/${bindir}" -maxdepth 1 -type f \ > + -exec install -m 0755 -t "${D}${bindir}" {} \; > + > + for d in . $(find "${LOCALETREESRC}/${localedir}" -type d -printf '%P ') ; do > + install -d "${D}${localedir}/$d" > + find "${LOCALETREESRC}/${localedir}/$d" -maxdepth 1 -type f \ > + -exec install -m 0644 -t "${D}${localedir}/$d" {} \; > + done > if [ ${@d.getVar('PACKAGE_NO_GCONV')} -eq 0 ]; then > - mkdir -p ${D}${libdir} > - if [ -e ${LOCALETREESRC}/${libdir}/gconv ]; then > - cp -R --no-dereference --preserve=mode,links ${LOCALETREESRC}/${libdir}/gconv ${D}${libdir} > - fi > - if [ -e ${LOCALETREESRC}/${datadir}/i18n ]; then > - cp -R --no-dereference --preserve=mode,links ${LOCALETREESRC}/${datadir}/i18n ${D}${datadir} > - fi > - fi > - if [ -e ${LOCALETREESRC}/${datadir}/locale ]; then > - cp -R --no-dereference --preserve=mode,links ${LOCALETREESRC}/${datadir}/locale ${D}${datadir} > + for d in . $(find "${LOCALETREESRC}/${libdir}/gconv" -type d -printf '%P ') ; do > + install -d "${D}${libdir}/gconv/$d" > + find "${LOCALETREESRC}/${libdir}/gconv/$d" -maxdepth 1 -type f \ > + -exec install -m 0755 -t "${D}${libdir}/gconv/$d" {} \; > + done > + for d in . $(find "${LOCALETREESRC}/${datadir}/i18n" -type d -printf '%P ') ; do > + install -d "${D}${datadir}/i18n/$d" > + find "${LOCALETREESRC}/${datadir}/i18n/$d" -maxdepth 1 -type f \ > + -exec install -m 0644 -t "${D}${datadir}/i18n/$d" {} \; > + done > fi > - cp -R --no-dereference --preserve=mode,links ${LOCALETREESRC}/SUPPORTED ${WORKDIR} > + for d in . $(find "${LOCALETREESRC}/${datadir}/locale" -type d -printf '%P ') ; do > + install -d "${D}${datadir}/locale/$d" > + find "${LOCALETREESRC}/${datadir}/locale/$d" -maxdepth 1 -type f \ > + -exec install -m 0644 -t "${D}${datadir}/locale/$d" {} \; > + done > + install -m 0644 ${LOCALETREESRC}/SUPPORTED ${WORKDIR}/SUPPORTED > } > > inherit libc-package The trouble is this is a workaround. The cp commands should work and there is some underlying issue in pseudo causing this. We really need to figure out what that is since this will likely just mean we see the problem somewhere else :( I still suspect some kind of inode number reuse problem which these cp commands trigger... Cheers, Richard -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
> -----Original Message----- > From: openembedded-core-bounces@lists.openembedded.org <openembedded- > core-bounces@lists.openembedded.org> On Behalf Of Khem Raj > Sent: den 7 februari 2019 01:36 > To: openembedded-core@lists.openembedded.org > Subject: [OE-core] [PATCH] glibc-locale: Rewrite do_install using > install utility instead of cp > > This has been a constant source of trouble for build failures due to > host-user-contaminated QA errors of sort > > 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] > > So far we have tried to mould cp command into not carrying the build > user permissions into install area but it is never entirely fixed since > the issue keeps popping up in various scenes > > This patch replaces use of cp with install utility and specifies > install mode for files explcitly > > Signed-off-by: Khem Raj <raj.khem@gmail.com> > --- > meta/recipes-core/glibc/glibc-locale.inc | 44 ++++++++++++++---------- > 1 file changed, 25 insertions(+), 19 deletions(-) > > diff --git a/meta/recipes-core/glibc/glibc-locale.inc b/meta/recipes-core/glibc/glibc-locale.inc > index 6384f9cbf1..9b256a5108 100644 > --- a/meta/recipes-core/glibc/glibc-locale.inc > +++ b/meta/recipes-core/glibc/glibc-locale.inc > @@ -72,27 +72,33 @@ FILES_localedef = "${bindir}/localedef" > LOCALETREESRC = "${COMPONENTS_DIR}/${PACKAGE_ARCH}/glibc-stash-locale" > > do_install () { > - mkdir -p ${D}${bindir} ${D}${datadir} > - if [ -n "$(ls ${LOCALETREESRC}/${bindir})" ]; then > - cp -R --no-dereference --preserve=mode,links ${LOCALETREESRC}/${bindir}/* ${D}${bindir} > - fi > - if [ -n "$(ls ${LOCALETREESRC}/${localedir})" ]; then > - mkdir -p ${D}${localedir} > - cp -R --no-dereference --preserve=mode,links ${LOCALETREESRC}/${localedir}/* ${D}${localedir} > - fi > + install -d ${D}${bindir} > + find "${LOCALETREESRC}/${bindir}" -maxdepth 1 -type f \ > + -exec install -m 0755 -t "${D}${bindir}" {} \; > + > + for d in . $(find "${LOCALETREESRC}/${localedir}" -type d -printf '%P ') ; do > + install -d "${D}${localedir}/$d" > + find "${LOCALETREESRC}/${localedir}/$d" -maxdepth 1 -type f \ > + -exec install -m 0644 -t "${D}${localedir}/$d" {} \; > + done > if [ ${@d.getVar('PACKAGE_NO_GCONV')} -eq 0 ]; then > - mkdir -p ${D}${libdir} > - if [ -e ${LOCALETREESRC}/${libdir}/gconv ]; then > - cp -R --no-dereference --preserve=mode,links ${LOCALETREESRC}/${libdir}/gconv ${D}${libdir} > - fi > - if [ -e ${LOCALETREESRC}/${datadir}/i18n ]; then > - cp -R --no-dereference --preserve=mode,links ${LOCALETREESRC}/${datadir}/i18n ${D}${datadir} > - fi > - fi > - if [ -e ${LOCALETREESRC}/${datadir}/locale ]; then > - cp -R --no-dereference --preserve=mode,links ${LOCALETREESRC}/${datadir}/locale ${D}${datadir} > + for d in . $(find "${LOCALETREESRC}/${libdir}/gconv" -type d -printf '%P ') ; do > + install -d "${D}${libdir}/gconv/$d" > + find "${LOCALETREESRC}/${libdir}/gconv/$d" -maxdepth 1 -type f \ > + -exec install -m 0755 -t "${D}${libdir}/gconv/$d" {} \; > + done > + for d in . $(find "${LOCALETREESRC}/${datadir}/i18n" -type d -printf '%P ') ; do > + install -d "${D}${datadir}/i18n/$d" > + find "${LOCALETREESRC}/${datadir}/i18n/$d" -maxdepth 1 -type f \ > + -exec install -m 0644 -t "${D}${datadir}/i18n/$d" {} \; > + done > fi > - cp -R --no-dereference --preserve=mode,links ${LOCALETREESRC}/SUPPORTED ${WORKDIR} > + for d in . $(find "${LOCALETREESRC}/${datadir}/locale" -type d -printf '%P ') ; do > + install -d "${D}${datadir}/locale/$d" > + find "${LOCALETREESRC}/${datadir}/locale/$d" -maxdepth 1 -type f \ > + -exec install -m 0644 -t "${D}${datadir}/locale/$d" {} \; > + done > + install -m 0644 ${LOCALETREESRC}/SUPPORTED ${WORKDIR}/SUPPORTED > } > > inherit libc-package > -- > 2.20.1 May I suggest using a help function to simplify the code a lot: copy_locale_files() { local dir=$1 mode=$2 [ -e "${LOCALETREESRC}$dir" ] || return 0 for d in . $(find "${LOCALETREESRC}$dir" -type d -printf '%P '); do install -d ${D}$dir/$d find "${LOCALETREESRC}$dir/$d" -maxdepth 1 -type f \ -exec install -m $mode -t "${D}$dir/$d" {} \; done } do_install() { copy_locale_files ${bindir} 0755 copy_locale_files ${localedir} 0644 if [ ${PACKAGE_NO_GCONV} -eq 0 ]; then copy_locale_files ${libdir}/gconv 0755 copy_locale_files ${datadir}/i18n 0644 fi copy_locale_files ${datadir}/locale 0644 install -m 0644 ${LOCALETREESRC}/SUPPORTED ${WORKDIR}/SUPPORTED } The code above is untested, but I think I got it reasonably correct. Also note that I have restored the indentation to use tabs, and turned the access to the ${PACKAGE_NO_GCONV} variable into a simple variable instead of using d.getVar(). //Peter -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
On Thu, Feb 7, 2019 at 1:00 AM Richard Purdie <richard.purdie@linuxfoundation.org> wrote: > > On Wed, 2019-02-06 at 16:35 -0800, Khem Raj wrote: > > This has been a constant source of trouble for build failures due to host-user-contaminated QA > > errors of sort > > > > 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] > > > > So far we have tried to mould cp command into not carrying the build > > user permissions into install area but it is never entirely fixed since > > the issue keeps popping up in various scenes > > > > This patch replaces use of cp with install utility and specifies install > > mode for files explcitly > > > > Signed-off-by: Khem Raj <raj.khem@gmail.com> > > --- > > meta/recipes-core/glibc/glibc-locale.inc | 44 ++++++++++++++---------- > > 1 file changed, 25 insertions(+), 19 deletions(-) > > > > diff --git a/meta/recipes-core/glibc/glibc-locale.inc b/meta/recipes-core/glibc/glibc-locale.inc > > index 6384f9cbf1..9b256a5108 100644 > > --- a/meta/recipes-core/glibc/glibc-locale.inc > > +++ b/meta/recipes-core/glibc/glibc-locale.inc > > @@ -72,27 +72,33 @@ FILES_localedef = "${bindir}/localedef" > > LOCALETREESRC = "${COMPONENTS_DIR}/${PACKAGE_ARCH}/glibc-stash-locale" > > > > do_install () { > > - mkdir -p ${D}${bindir} ${D}${datadir} > > - if [ -n "$(ls ${LOCALETREESRC}/${bindir})" ]; then > > - cp -R --no-dereference --preserve=mode,links ${LOCALETREESRC}/${bindir}/* ${D}${bindir} > > - fi > > - if [ -n "$(ls ${LOCALETREESRC}/${localedir})" ]; then > > - mkdir -p ${D}${localedir} > > - cp -R --no-dereference --preserve=mode,links ${LOCALETREESRC}/${localedir}/* ${D}${localedir} > > - fi > > + install -d ${D}${bindir} > > + find "${LOCALETREESRC}/${bindir}" -maxdepth 1 -type f \ > > + -exec install -m 0755 -t "${D}${bindir}" {} \; > > + > > + for d in . $(find "${LOCALETREESRC}/${localedir}" -type d -printf '%P ') ; do > > + install -d "${D}${localedir}/$d" > > + find "${LOCALETREESRC}/${localedir}/$d" -maxdepth 1 -type f \ > > + -exec install -m 0644 -t "${D}${localedir}/$d" {} \; > > + done > > if [ ${@d.getVar('PACKAGE_NO_GCONV')} -eq 0 ]; then > > - mkdir -p ${D}${libdir} > > - if [ -e ${LOCALETREESRC}/${libdir}/gconv ]; then > > - cp -R --no-dereference --preserve=mode,links ${LOCALETREESRC}/${libdir}/gconv ${D}${libdir} > > - fi > > - if [ -e ${LOCALETREESRC}/${datadir}/i18n ]; then > > - cp -R --no-dereference --preserve=mode,links ${LOCALETREESRC}/${datadir}/i18n ${D}${datadir} > > - fi > > - fi > > - if [ -e ${LOCALETREESRC}/${datadir}/locale ]; then > > - cp -R --no-dereference --preserve=mode,links ${LOCALETREESRC}/${datadir}/locale ${D}${datadir} > > + for d in . $(find "${LOCALETREESRC}/${libdir}/gconv" -type d -printf '%P ') ; do > > + install -d "${D}${libdir}/gconv/$d" > > + find "${LOCALETREESRC}/${libdir}/gconv/$d" -maxdepth 1 -type f \ > > + -exec install -m 0755 -t "${D}${libdir}/gconv/$d" {} \; > > + done > > + for d in . $(find "${LOCALETREESRC}/${datadir}/i18n" -type d -printf '%P ') ; do > > + install -d "${D}${datadir}/i18n/$d" > > + find "${LOCALETREESRC}/${datadir}/i18n/$d" -maxdepth 1 -type f \ > > + -exec install -m 0644 -t "${D}${datadir}/i18n/$d" {} \; > > + done > > fi > > - cp -R --no-dereference --preserve=mode,links ${LOCALETREESRC}/SUPPORTED ${WORKDIR} > > + for d in . $(find "${LOCALETREESRC}/${datadir}/locale" -type d -printf '%P ') ; do > > + install -d "${D}${datadir}/locale/$d" > > + find "${LOCALETREESRC}/${datadir}/locale/$d" -maxdepth 1 -type f \ > > + -exec install -m 0644 -t "${D}${datadir}/locale/$d" {} \; > > + done > > + install -m 0644 ${LOCALETREESRC}/SUPPORTED ${WORKDIR}/SUPPORTED > > } > > > > inherit libc-package > > The trouble is this is a workaround. The cp commands should work and > there is some underlying issue in pseudo causing this. We really need > to figure out what that is since this will likely just mean we see the > problem somewhere else :( so far this is the only place where it shows in world builds that meta-oe does which includes many layers. > > I still suspect some kind of inode number reuse problem which these cp > commands trigger... cp and install are not same when it comes to how they operate underneath. install is better when it comes to what we are doing here it also gives better control of permissions and mods,as a recipe writer someone would prefer then to let the tool ( cp ) assume it. So there might be a pseudo issue, I dont disagree but not obvious and I believe using cp is subpar anyway. > > Cheers, > > Richard > -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
On Thu, Feb 7, 2019 at 3:44 AM Peter Kjellerstedt <peter.kjellerstedt@axis.com> wrote: > > > -----Original Message----- > > From: openembedded-core-bounces@lists.openembedded.org <openembedded- > > core-bounces@lists.openembedded.org> On Behalf Of Khem Raj > > Sent: den 7 februari 2019 01:36 > > To: openembedded-core@lists.openembedded.org > > Subject: [OE-core] [PATCH] glibc-locale: Rewrite do_install using > > install utility instead of cp > > > > This has been a constant source of trouble for build failures due to > > host-user-contaminated QA errors of sort > > > > 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] > > > > So far we have tried to mould cp command into not carrying the build > > user permissions into install area but it is never entirely fixed since > > the issue keeps popping up in various scenes > > > > This patch replaces use of cp with install utility and specifies > > install mode for files explcitly > > > > Signed-off-by: Khem Raj <raj.khem@gmail.com> > > --- > > meta/recipes-core/glibc/glibc-locale.inc | 44 ++++++++++++++---------- > > 1 file changed, 25 insertions(+), 19 deletions(-) > > > > diff --git a/meta/recipes-core/glibc/glibc-locale.inc b/meta/recipes-core/glibc/glibc-locale.inc > > index 6384f9cbf1..9b256a5108 100644 > > --- a/meta/recipes-core/glibc/glibc-locale.inc > > +++ b/meta/recipes-core/glibc/glibc-locale.inc > > @@ -72,27 +72,33 @@ FILES_localedef = "${bindir}/localedef" > > LOCALETREESRC = "${COMPONENTS_DIR}/${PACKAGE_ARCH}/glibc-stash-locale" > > > > do_install () { > > - mkdir -p ${D}${bindir} ${D}${datadir} > > - if [ -n "$(ls ${LOCALETREESRC}/${bindir})" ]; then > > - cp -R --no-dereference --preserve=mode,links ${LOCALETREESRC}/${bindir}/* ${D}${bindir} > > - fi > > - if [ -n "$(ls ${LOCALETREESRC}/${localedir})" ]; then > > - mkdir -p ${D}${localedir} > > - cp -R --no-dereference --preserve=mode,links ${LOCALETREESRC}/${localedir}/* ${D}${localedir} > > - fi > > + install -d ${D}${bindir} > > + find "${LOCALETREESRC}/${bindir}" -maxdepth 1 -type f \ > > + -exec install -m 0755 -t "${D}${bindir}" {} \; > > + > > + for d in . $(find "${LOCALETREESRC}/${localedir}" -type d -printf '%P ') ; do > > + install -d "${D}${localedir}/$d" > > + find "${LOCALETREESRC}/${localedir}/$d" -maxdepth 1 -type f \ > > + -exec install -m 0644 -t "${D}${localedir}/$d" {} \; > > + done > > if [ ${@d.getVar('PACKAGE_NO_GCONV')} -eq 0 ]; then > > - mkdir -p ${D}${libdir} > > - if [ -e ${LOCALETREESRC}/${libdir}/gconv ]; then > > - cp -R --no-dereference --preserve=mode,links ${LOCALETREESRC}/${libdir}/gconv ${D}${libdir} > > - fi > > - if [ -e ${LOCALETREESRC}/${datadir}/i18n ]; then > > - cp -R --no-dereference --preserve=mode,links ${LOCALETREESRC}/${datadir}/i18n ${D}${datadir} > > - fi > > - fi > > - if [ -e ${LOCALETREESRC}/${datadir}/locale ]; then > > - cp -R --no-dereference --preserve=mode,links ${LOCALETREESRC}/${datadir}/locale ${D}${datadir} > > + for d in . $(find "${LOCALETREESRC}/${libdir}/gconv" -type d -printf '%P ') ; do > > + install -d "${D}${libdir}/gconv/$d" > > + find "${LOCALETREESRC}/${libdir}/gconv/$d" -maxdepth 1 -type f \ > > + -exec install -m 0755 -t "${D}${libdir}/gconv/$d" {} \; > > + done > > + for d in . $(find "${LOCALETREESRC}/${datadir}/i18n" -type d -printf '%P ') ; do > > + install -d "${D}${datadir}/i18n/$d" > > + find "${LOCALETREESRC}/${datadir}/i18n/$d" -maxdepth 1 -type f \ > > + -exec install -m 0644 -t "${D}${datadir}/i18n/$d" {} \; > > + done > > fi > > - cp -R --no-dereference --preserve=mode,links ${LOCALETREESRC}/SUPPORTED ${WORKDIR} > > + for d in . $(find "${LOCALETREESRC}/${datadir}/locale" -type d -printf '%P ') ; do > > + install -d "${D}${datadir}/locale/$d" > > + find "${LOCALETREESRC}/${datadir}/locale/$d" -maxdepth 1 -type f \ > > + -exec install -m 0644 -t "${D}${datadir}/locale/$d" {} \; > > + done > > + install -m 0644 ${LOCALETREESRC}/SUPPORTED ${WORKDIR}/SUPPORTED > > } > > > > inherit libc-package > > -- > > 2.20.1 > > May I suggest using a help function to simplify the code a lot: > > copy_locale_files() { > local dir=$1 mode=$2 > > [ -e "${LOCALETREESRC}$dir" ] || return 0 > > for d in . $(find "${LOCALETREESRC}$dir" -type d -printf '%P '); do > install -d ${D}$dir/$d > find "${LOCALETREESRC}$dir/$d" -maxdepth 1 -type f \ > -exec install -m $mode -t "${D}$dir/$d" {} \; > done > } > > do_install() { > copy_locale_files ${bindir} 0755 > copy_locale_files ${localedir} 0644 > if [ ${PACKAGE_NO_GCONV} -eq 0 ]; then > copy_locale_files ${libdir}/gconv 0755 > copy_locale_files ${datadir}/i18n 0644 > fi > copy_locale_files ${datadir}/locale 0644 > install -m 0644 ${LOCALETREESRC}/SUPPORTED ${WORKDIR}/SUPPORTED > } > > The code above is untested, but I think I got it reasonably correct. > Also note that I have restored the indentation to use tabs, and > turned the access to the ${PACKAGE_NO_GCONV} variable into a > simple variable instead of using d.getVar(). > thats a neat idea. I will send a v2 with this > //Peter > -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
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: https://bugzilla.yoctoproject.org/show_bug.cgi?id=12434 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: https://github.com/webosose/meta-webosose/blob/master/meta-webos/recipes-core/glibc/glibc-locale_%25.bbappend Regards, On Thu, Feb 7, 2019 at 3:50 PM Khem Raj <raj.khem@gmail.com> wrote: > On Thu, Feb 7, 2019 at 1:00 AM Richard Purdie > <richard.purdie@linuxfoundation.org> wrote: > > > > On Wed, 2019-02-06 at 16:35 -0800, Khem Raj wrote: > > > This has been a constant source of trouble for build failures due to > host-user-contaminated QA > > > errors of sort > > > > > > 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] > > > > > > So far we have tried to mould cp command into not carrying the build > > > user permissions into install area but it is never entirely fixed since > > > the issue keeps popping up in various scenes > > > > > > This patch replaces use of cp with install utility and specifies > install > > > mode for files explcitly > > > > > > Signed-off-by: Khem Raj <raj.khem@gmail.com> > > > --- > > > meta/recipes-core/glibc/glibc-locale.inc | 44 ++++++++++++++---------- > > > 1 file changed, 25 insertions(+), 19 deletions(-) > > > > > > diff --git a/meta/recipes-core/glibc/glibc-locale.inc > b/meta/recipes-core/glibc/glibc-locale.inc > > > index 6384f9cbf1..9b256a5108 100644 > > > --- a/meta/recipes-core/glibc/glibc-locale.inc > > > +++ b/meta/recipes-core/glibc/glibc-locale.inc > > > @@ -72,27 +72,33 @@ FILES_localedef = "${bindir}/localedef" > > > LOCALETREESRC = "${COMPONENTS_DIR}/${PACKAGE_ARCH}/glibc-stash-locale" > > > > > > do_install () { > > > - mkdir -p ${D}${bindir} ${D}${datadir} > > > - if [ -n "$(ls ${LOCALETREESRC}/${bindir})" ]; then > > > - cp -R --no-dereference --preserve=mode,links > ${LOCALETREESRC}/${bindir}/* ${D}${bindir} > > > - fi > > > - if [ -n "$(ls ${LOCALETREESRC}/${localedir})" ]; then > > > - mkdir -p ${D}${localedir} > > > - cp -R --no-dereference --preserve=mode,links > ${LOCALETREESRC}/${localedir}/* ${D}${localedir} > > > - fi > > > + install -d ${D}${bindir} > > > + find "${LOCALETREESRC}/${bindir}" -maxdepth 1 -type f \ > > > + -exec install -m 0755 -t "${D}${bindir}" {} \; > > > + > > > + for d in . $(find "${LOCALETREESRC}/${localedir}" -type d > -printf '%P ') ; do > > > + install -d "${D}${localedir}/$d" > > > + find "${LOCALETREESRC}/${localedir}/$d" -maxdepth 1 > -type f \ > > > + -exec install -m 0644 -t "${D}${localedir}/$d" {} \; > > > + done > > > if [ ${@d.getVar('PACKAGE_NO_GCONV')} -eq 0 ]; then > > > - mkdir -p ${D}${libdir} > > > - if [ -e ${LOCALETREESRC}/${libdir}/gconv ]; then > > > - cp -R --no-dereference --preserve=mode,links > ${LOCALETREESRC}/${libdir}/gconv ${D}${libdir} > > > - fi > > > - if [ -e ${LOCALETREESRC}/${datadir}/i18n ]; then > > > - cp -R --no-dereference --preserve=mode,links > ${LOCALETREESRC}/${datadir}/i18n ${D}${datadir} > > > - fi > > > - fi > > > - if [ -e ${LOCALETREESRC}/${datadir}/locale ]; then > > > - cp -R --no-dereference --preserve=mode,links > ${LOCALETREESRC}/${datadir}/locale ${D}${datadir} > > > + for d in . $(find "${LOCALETREESRC}/${libdir}/gconv" > -type d -printf '%P ') ; do > > > + install -d "${D}${libdir}/gconv/$d" > > > + find "${LOCALETREESRC}/${libdir}/gconv/$d" > -maxdepth 1 -type f \ > > > + -exec install -m 0755 -t > "${D}${libdir}/gconv/$d" {} \; > > > + done > > > + for d in . $(find "${LOCALETREESRC}/${datadir}/i18n" > -type d -printf '%P ') ; do > > > + install -d "${D}${datadir}/i18n/$d" > > > + find "${LOCALETREESRC}/${datadir}/i18n/$d" > -maxdepth 1 -type f \ > > > + -exec install -m 0644 -t > "${D}${datadir}/i18n/$d" {} \; > > > + done > > > fi > > > - cp -R --no-dereference --preserve=mode,links > ${LOCALETREESRC}/SUPPORTED ${WORKDIR} > > > + for d in . $(find "${LOCALETREESRC}/${datadir}/locale" -type > d -printf '%P ') ; do > > > + install -d "${D}${datadir}/locale/$d" > > > + find "${LOCALETREESRC}/${datadir}/locale/$d" > -maxdepth 1 -type f \ > > > + -exec install -m 0644 -t "${D}${datadir}/locale/$d" > {} \; > > > + done > > > + install -m 0644 ${LOCALETREESRC}/SUPPORTED ${WORKDIR}/SUPPORTED > > > } > > > > > > inherit libc-package > > > > The trouble is this is a workaround. The cp commands should work and > > there is some underlying issue in pseudo causing this. We really need > > to figure out what that is since this will likely just mean we see the > > problem somewhere else :( > > so far this is the only place where it shows in world builds that > meta-oe does which includes many layers. > > > > > I still suspect some kind of inode number reuse problem which these cp > > commands trigger... > > cp and install are not same when it comes to how they operate > underneath. install is better when it comes to what we are doing here > it also gives better control of permissions and mods,as a recipe writer > someone would prefer then to let the tool ( cp ) assume it. > > So there might be a pseudo issue, I dont disagree but not obvious and > I believe using cp is subpar anyway. > > > > > Cheers, > > > > Richard > > > -- > _______________________________________________ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-core > <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> -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Martin, Do you by any chance build in Docker (or some other transient container)? We recently found an issue with building in docker where when the primary container command would exit, causing the container to terminate. When the container terminates, the kernel unceremoniously sends SIGKILL to all its processes. This plays *very* poorly with pseudo because pseudo keeps it's entire database in a in-memory sqlite database and only flushes it out to disk on a periodic interval, or when it get SIGTERM (maybe SIGQUIT?) or exits normally. By default the pseudo daemon will also hang around for 20(?) seconds waiting for a new connection from a pseudo client, meaning that when our docker container was exiting, there were potentially several pseudo dameons sitting around waiting for a client with unflushed databases in memory that suddenly got a SIGKILL and all their data was lost. This was particularly bad if you aborted a build while it was running, or some build failure occurred. Since the pseudo database was lost, the only way to correct these errors was to clean and rebuild. I think pseudo could handle this better and keep the database on disk instead of in memory, but in the short term you can hack bitbake to pass the -S flag when invoking the pseudo client which will make it tell the dameon to shutdown (and thus flush the database) if it is the last connection. On Thu, 2019-02-07 at 17:17 +0100, Martin Jansa wrote: > 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:https://bugzilla.yoctoproject.org/show_bug.cgi?id=12434 > > 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: > https://github.com/webosose/meta-webosose/blob/master/meta-webos/recipes-core/glibc/glibc-locale_%25.bbappend > > Regards, > > On Thu, Feb 7, 2019 at 3:50 PM Khem Raj <raj.khem@gmail.com> wrote: > > On Thu, Feb 7, 2019 at 1:00 AM Richard Purdie > > > > <richard.purdie@linuxfoundation.org> wrote: > > > > > > > > > > On Wed, 2019-02-06 at 16:35 -0800, Khem Raj wrote: > > > > > > This has been a constant source of trouble for build failures > > due to host-user-contaminated QA > > > > > > errors of sort > > > > > > > > > > > > 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] > > > > > > > > > > > > So far we have tried to mould cp command into not carrying the > > build > > > > > > user permissions into install area but it is never entirely > > fixed since > > > > > > the issue keeps popping up in various scenes > > > > > > > > > > > > This patch replaces use of cp with install utility and > > specifies install > > > > > > mode for files explcitly > > > > > > > > > > > > Signed-off-by: Khem Raj <raj.khem@gmail.com> > > > > > > --- > > > > > > meta/recipes-core/glibc/glibc-locale.inc | 44 ++++++++++++++ > > ---------- > > > > > > 1 file changed, 25 insertions(+), 19 deletions(-) > > > > > > > > > > > > diff --git a/meta/recipes-core/glibc/glibc-locale.inc > > b/meta/recipes-core/glibc/glibc-locale.inc > > > > > > index 6384f9cbf1..9b256a5108 100644 > > > > > > --- a/meta/recipes-core/glibc/glibc-locale.inc > > > > > > +++ b/meta/recipes-core/glibc/glibc-locale.inc > > > > > > @@ -72,27 +72,33 @@ FILES_localedef = "${bindir}/localedef" > > > > > > LOCALETREESRC = "${COMPONENTS_DIR}/${PACKAGE_ARCH}/glibc- > > stash-locale" > > > > > > > > > > > > do_install () { > > > > > > - mkdir -p ${D}${bindir} ${D}${datadir} > > > > > > - if [ -n "$(ls ${LOCALETREESRC}/${bindir})" ]; then > > > > > > - cp -R --no-dereference --preserve=mode,links > > ${LOCALETREESRC}/${bindir}/* ${D}${bindir} > > > > > > - fi > > > > > > - if [ -n "$(ls ${LOCALETREESRC}/${localedir})" ]; then > > > > > > - mkdir -p ${D}${localedir} > > > > > > - cp -R --no-dereference --preserve=mode,links > > ${LOCALETREESRC}/${localedir}/* ${D}${localedir} > > > > > > - fi > > > > > > + install -d ${D}${bindir} > > > > > > + find "${LOCALETREESRC}/${bindir}" -maxdepth 1 -type f > > \ > > > > > > + -exec install -m 0755 -t "${D}${bindir}" {} \; > > > > > > + > > > > > > + for d in . $(find "${LOCALETREESRC}/${localedir}" > > -type d -printf '%P ') ; do > > > > > > + install -d "${D}${localedir}/$d" > > > > > > + find "${LOCALETREESRC}/${localedir}/$d" > > -maxdepth 1 -type f \ > > > > > > + -exec install -m 0644 -t "${D}${localedir}/$d" > > {} \; > > > > > > + done > > > > > > if [ ${@d.getVar('PACKAGE_NO_GCONV')} -eq 0 ]; then > > > > > > - mkdir -p ${D}${libdir} > > > > > > - if [ -e ${LOCALETREESRC}/${libdir}/gconv ]; then > > > > > > - cp -R --no-dereference -- > > preserve=mode,links ${LOCALETREESRC}/${libdir}/gconv ${D}${libdir} > > > > > > - fi > > > > > > - if [ -e ${LOCALETREESRC}/${datadir}/i18n ]; then > > > > > > - cp -R --no-dereference -- > > preserve=mode,links ${LOCALETREESRC}/${datadir}/i18n ${D}${datadir} > > > > > > - fi > > > > > > - fi > > > > > > - if [ -e ${LOCALETREESRC}/${datadir}/locale ]; then > > > > > > - cp -R --no-dereference --preserve=mode,links > > ${LOCALETREESRC}/${datadir}/locale ${D}${datadir} > > > > > > + for d in . $(find > > "${LOCALETREESRC}/${libdir}/gconv" -type d -printf '%P ') ; do > > > > > > + install -d "${D}${libdir}/gconv/$d" > > > > > > + find > > "${LOCALETREESRC}/${libdir}/gconv/$d" -maxdepth 1 -type f \ > > > > > > + -exec install -m 0755 -t > > "${D}${libdir}/gconv/$d" {} \; > > > > > > + done > > > > > > + for d in . $(find > > "${LOCALETREESRC}/${datadir}/i18n" -type d -printf '%P ') ; do > > > > > > + install -d "${D}${datadir}/i18n/$d" > > > > > > + find > > "${LOCALETREESRC}/${datadir}/i18n/$d" -maxdepth 1 -type f \ > > > > > > + -exec install -m 0644 -t > > "${D}${datadir}/i18n/$d" {} \; > > > > > > + done > > > > > > fi > > > > > > - cp -R --no-dereference --preserve=mode,links > > ${LOCALETREESRC}/SUPPORTED ${WORKDIR} > > > > > > + for d in . $(find "${LOCALETREESRC}/${datadir}/locale" > > -type d -printf '%P ') ; do > > > > > > + install -d "${D}${datadir}/locale/$d" > > > > > > + find "${LOCALETREESRC}/${datadir}/locale/$d" > > -maxdepth 1 -type f \ > > > > > > + -exec install -m 0644 -t > > "${D}${datadir}/locale/$d" {} \; > > > > > > + done > > > > > > + install -m 0644 ${LOCALETREESRC}/SUPPORTED > > ${WORKDIR}/SUPPORTED > > > > > > } > > > > > > > > > > > > inherit libc-package > > > > > > > > > > The trouble is this is a workaround. The cp commands should work > > and > > > > > there is some underlying issue in pseudo causing this. We really > > need > > > > > to figure out what that is since this will likely just mean we > > see the > > > > > problem somewhere else :( > > > > > > > > so far this is the only place where it shows in world builds that > > > > meta-oe does which includes many layers. > > > > > > > > > > > > > > I still suspect some kind of inode number reuse problem which > > these cp > > > > > commands trigger... > > > > > > > > cp and install are not same when it comes to how they operate > > > > underneath. install is better when it comes to what we are doing > > here > > > > it also gives better control of permissions and mods,as a recipe > > writer > > > > someone would prefer then to let the tool ( cp ) assume it. > > > > > > > > So there might be a pseudo issue, I dont disagree but not obvious > > and > > > > I believe using cp is subpar anyway. > > > > > > > > > > > > > > Cheers, > > > > > > > > > > Richard > > > > > > > -- Joshua Watt <JPEWhacker@gmail.com> <html dir="ltr"><head></head><body style="text-align:left; direction:ltr;"><div>Martin,</div><div><br></div><div>Do you by any chance build in Docker (or some other transient container)? We recently found an issue with building in docker where when the primary container command would exit, causing the container to terminate. When the container terminates, the kernel unceremoniously sends SIGKILL to all its processes. This plays *very* poorly with pseudo because pseudo keeps it's entire database in a in-memory sqlite database and only flushes it out to disk on a periodic interval, or when it get SIGTERM (maybe SIGQUIT?) or exits normally. By default the pseudo daemon will also hang around for 20(?) seconds waiting for a new connection from a pseudo client, meaning that when our docker container was exiting, there were potentially several pseudo dameons sitting around waiting for a client with unflushed databases in memory that suddenly got a SIGKILL and all their data was lost. This was particularly bad if you aborted a build while it was running, or some build failure occurred. Since the pseudo database was lost, the only way to correct these errors was to clean and rebuild.</div><div><br></div><div>I think pseudo could handle this better and keep the database on disk instead of in memory, but in the short term you can hack bitbake to pass the -S flag when invoking the pseudo client which will make it tell the dameon to shutdown (and thus flush the database) if it is the last connection.</div><div><br></div><div><br></div><div>On Thu, 2019-02-07 at 17:17 +0100, Martin Jansa wrote:</div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><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 type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;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> </blockquote></div></blockquote><div><span><pre>-- <br></pre>Joshua Watt <<a href="mailto:JPEWhacker@gmail.com">JPEWhacker@gmail.com</a>></span></div></body></html> -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
On Thu, Feb 7, 2019 at 10:44 AM Joshua Watt <jpewhacker@gmail.com> wrote: > > Martin, > > Do you by any chance build in Docker (or some other transient container)? We recently found an issue with building in docker where when the primary container command would exit, causing the container to terminate. When the container terminates, the kernel unceremoniously sends SIGKILL to all its processes. This plays *very* poorly with pseudo because pseudo keeps it's entire database in a in-memory sqlite database and only flushes it out to disk on a periodic interval, or when it get SIGTERM (maybe SIGQUIT?) or exits normally. By default the pseudo daemon will also hang around for 20(?) seconds waiting for a new connection from a pseudo client, meaning that when our docker container was exiting, there were potentially several pseudo dameons sitting around waiting for a client with unflushed databases in memory that suddenly got a SIGKILL and all their data was lost. This was particularly bad if you aborted a build while it was running, or some build failure occurred. Since the pseudo database was lost, the only way to correct these errors was to clean and rebuild. > > I think pseudo could handle this better and keep the database on disk instead of in memory, but in the short term you can hack bitbake to pass the -S flag when invoking the pseudo client which will make it tell the dameon to shutdown (and thus flush the database) if it is the last connection. FWIW, this patch makes it much easier to do that http://lists.openembedded.org/pipermail/bitbake-devel/2019-February/019813.html Just add FAKEROOTCMD += "-S" in local.conf > > > On Thu, 2019-02-07 at 17:17 +0100, Martin Jansa wrote: > > 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: > https://bugzilla.yoctoproject.org/show_bug.cgi?id=12434 > > 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: > https://github.com/webosose/meta-webosose/blob/master/meta-webos/recipes-core/glibc/glibc-locale_%25.bbappend > > Regards, > > On Thu, Feb 7, 2019 at 3:50 PM Khem Raj <raj.khem@gmail.com> wrote: > > On Thu, Feb 7, 2019 at 1:00 AM Richard Purdie > <richard.purdie@linuxfoundation.org> wrote: > > > > On Wed, 2019-02-06 at 16:35 -0800, Khem Raj wrote: > > > This has been a constant source of trouble for build failures due to host-user-contaminated QA > > > errors of sort > > > > > > 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] > > > > > > So far we have tried to mould cp command into not carrying the build > > > user permissions into install area but it is never entirely fixed since > > > the issue keeps popping up in various scenes > > > > > > This patch replaces use of cp with install utility and specifies install > > > mode for files explcitly > > > > > > Signed-off-by: Khem Raj <raj.khem@gmail.com> > > > --- > > > meta/recipes-core/glibc/glibc-locale.inc | 44 ++++++++++++++---------- > > > 1 file changed, 25 insertions(+), 19 deletions(-) > > > > > > diff --git a/meta/recipes-core/glibc/glibc-locale.inc b/meta/recipes-core/glibc/glibc-locale.inc > > > index 6384f9cbf1..9b256a5108 100644 > > > --- a/meta/recipes-core/glibc/glibc-locale.inc > > > +++ b/meta/recipes-core/glibc/glibc-locale.inc > > > @@ -72,27 +72,33 @@ FILES_localedef = "${bindir}/localedef" > > > LOCALETREESRC = "${COMPONENTS_DIR}/${PACKAGE_ARCH}/glibc-stash-locale" > > > > > > do_install () { > > > - mkdir -p ${D}${bindir} ${D}${datadir} > > > - if [ -n "$(ls ${LOCALETREESRC}/${bindir})" ]; then > > > - cp -R --no-dereference --preserve=mode,links ${LOCALETREESRC}/${bindir}/* ${D}${bindir} > > > - fi > > > - if [ -n "$(ls ${LOCALETREESRC}/${localedir})" ]; then > > > - mkdir -p ${D}${localedir} > > > - cp -R --no-dereference --preserve=mode,links ${LOCALETREESRC}/${localedir}/* ${D}${localedir} > > > - fi > > > + install -d ${D}${bindir} > > > + find "${LOCALETREESRC}/${bindir}" -maxdepth 1 -type f \ > > > + -exec install -m 0755 -t "${D}${bindir}" {} \; > > > + > > > + for d in . $(find "${LOCALETREESRC}/${localedir}" -type d -printf '%P ') ; do > > > + install -d "${D}${localedir}/$d" > > > + find "${LOCALETREESRC}/${localedir}/$d" -maxdepth 1 -type f \ > > > + -exec install -m 0644 -t "${D}${localedir}/$d" {} \; > > > + done > > > if [ ${@d.getVar('PACKAGE_NO_GCONV')} -eq 0 ]; then > > > - mkdir -p ${D}${libdir} > > > - if [ -e ${LOCALETREESRC}/${libdir}/gconv ]; then > > > - cp -R --no-dereference --preserve=mode,links ${LOCALETREESRC}/${libdir}/gconv ${D}${libdir} > > > - fi > > > - if [ -e ${LOCALETREESRC}/${datadir}/i18n ]; then > > > - cp -R --no-dereference --preserve=mode,links ${LOCALETREESRC}/${datadir}/i18n ${D}${datadir} > > > - fi > > > - fi > > > - if [ -e ${LOCALETREESRC}/${datadir}/locale ]; then > > > - cp -R --no-dereference --preserve=mode,links ${LOCALETREESRC}/${datadir}/locale ${D}${datadir} > > > + for d in . $(find "${LOCALETREESRC}/${libdir}/gconv" -type d -printf '%P ') ; do > > > + install -d "${D}${libdir}/gconv/$d" > > > + find "${LOCALETREESRC}/${libdir}/gconv/$d" -maxdepth 1 -type f \ > > > + -exec install -m 0755 -t "${D}${libdir}/gconv/$d" {} \; > > > + done > > > + for d in . $(find "${LOCALETREESRC}/${datadir}/i18n" -type d -printf '%P ') ; do > > > + install -d "${D}${datadir}/i18n/$d" > > > + find "${LOCALETREESRC}/${datadir}/i18n/$d" -maxdepth 1 -type f \ > > > + -exec install -m 0644 -t "${D}${datadir}/i18n/$d" {} \; > > > + done > > > fi > > > - cp -R --no-dereference --preserve=mode,links ${LOCALETREESRC}/SUPPORTED ${WORKDIR} > > > + for d in . $(find "${LOCALETREESRC}/${datadir}/locale" -type d -printf '%P ') ; do > > > + install -d "${D}${datadir}/locale/$d" > > > + find "${LOCALETREESRC}/${datadir}/locale/$d" -maxdepth 1 -type f \ > > > + -exec install -m 0644 -t "${D}${datadir}/locale/$d" {} \; > > > + done > > > + install -m 0644 ${LOCALETREESRC}/SUPPORTED ${WORKDIR}/SUPPORTED > > > } > > > > > > inherit libc-package > > > > The trouble is this is a workaround. The cp commands should work and > > there is some underlying issue in pseudo causing this. We really need > > to figure out what that is since this will likely just mean we see the > > problem somewhere else :( > > so far this is the only place where it shows in world builds that > meta-oe does which includes many layers. > > > > > I still suspect some kind of inode number reuse problem which these cp > > commands trigger... > > cp and install are not same when it comes to how they operate > underneath. install is better when it comes to what we are doing here > it also gives better control of permissions and mods,as a recipe writer > someone would prefer then to let the tool ( cp ) assume it. > > So there might be a pseudo issue, I dont disagree but not obvious and > I believe using cp is subpar anyway. > > > > > Cheers, > > > > Richard > > > > -- > > Joshua Watt <JPEWhacker@gmail.com> -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
On Thu, Feb 07, 2019 at 10:59:18AM -0600, Joshua Watt wrote: > On Thu, Feb 7, 2019 at 10:44 AM Joshua Watt <jpewhacker@gmail.com> wrote: > > > > Martin, > > > > Do you by any chance build in Docker (or some other transient container)? We recently found an issue with building in docker where when the primary container command would exit, causing the container to terminate. When the container terminates, the kernel unceremoniously sends SIGKILL to all its processes. This plays *very* poorly with pseudo because pseudo keeps it's entire database in a in-memory sqlite database and only flushes it out to disk on a periodic interval, or when it get SIGTERM (maybe SIGQUIT?) or exits normally. By default the pseudo daemon will also hang around for 20(?) seconds waiting for a new connection from a pseudo client, meaning that when our docker container was exiting, there were potentially several pseudo dameons sitting around waiting for a client with unflushed databases in memory that suddenly got a SIGKILL and all their data was lost. This was particularly bad if you aborted a build while it was running, or some build failure occurred. Since the pseudo database was lost, the only way to correct these errors was to clean and rebuild. > > > > I think pseudo could handle this better and keep the database on disk instead of in memory, but in the short term you can hack bitbake to pass the -S flag when invoking the pseudo client which will make it tell the dameon to shutdown (and thus flush the database) if it is the last connection. > > FWIW, this patch makes it much easier to do that > http://lists.openembedded.org/pipermail/bitbake-devel/2019-February/019813.html > Just add > FAKEROOTCMD += "-S" > in local.conf Hi Joshua, most of the build failures caused by this weren't from the builds in Docker (or any other container), just plain Ubuntu (various versions 14.04 - 18.04) with just the prerequisites installed. When I get access to some bigger build farm (probably in few months) I can run that for loop reproducer from the ticket again with FAKEROOTCMD += "-S" to see if it makes any difference. Regards, > > On Thu, 2019-02-07 at 17:17 +0100, Martin Jansa wrote: > > > > 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: > > https://bugzilla.yoctoproject.org/show_bug.cgi?id=12434 > > > > 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: > > https://github.com/webosose/meta-webosose/blob/master/meta-webos/recipes-core/glibc/glibc-locale_%25.bbappend > > > > Regards, > > > > On Thu, Feb 7, 2019 at 3:50 PM Khem Raj <raj.khem@gmail.com> wrote: > > > > On Thu, Feb 7, 2019 at 1:00 AM Richard Purdie > > <richard.purdie@linuxfoundation.org> wrote: > > > > > > On Wed, 2019-02-06 at 16:35 -0800, Khem Raj wrote: > > > > This has been a constant source of trouble for build failures due to host-user-contaminated QA > > > > errors of sort > > > > > > > > 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] > > > > > > > > So far we have tried to mould cp command into not carrying the build > > > > user permissions into install area but it is never entirely fixed since > > > > the issue keeps popping up in various scenes > > > > > > > > This patch replaces use of cp with install utility and specifies install > > > > mode for files explcitly > > > > > > > > Signed-off-by: Khem Raj <raj.khem@gmail.com> > > > > --- > > > > meta/recipes-core/glibc/glibc-locale.inc | 44 ++++++++++++++---------- > > > > 1 file changed, 25 insertions(+), 19 deletions(-) > > > > > > > > diff --git a/meta/recipes-core/glibc/glibc-locale.inc b/meta/recipes-core/glibc/glibc-locale.inc > > > > index 6384f9cbf1..9b256a5108 100644 > > > > --- a/meta/recipes-core/glibc/glibc-locale.inc > > > > +++ b/meta/recipes-core/glibc/glibc-locale.inc > > > > @@ -72,27 +72,33 @@ FILES_localedef = "${bindir}/localedef" > > > > LOCALETREESRC = "${COMPONENTS_DIR}/${PACKAGE_ARCH}/glibc-stash-locale" > > > > > > > > do_install () { > > > > - mkdir -p ${D}${bindir} ${D}${datadir} > > > > - if [ -n "$(ls ${LOCALETREESRC}/${bindir})" ]; then > > > > - cp -R --no-dereference --preserve=mode,links ${LOCALETREESRC}/${bindir}/* ${D}${bindir} > > > > - fi > > > > - if [ -n "$(ls ${LOCALETREESRC}/${localedir})" ]; then > > > > - mkdir -p ${D}${localedir} > > > > - cp -R --no-dereference --preserve=mode,links ${LOCALETREESRC}/${localedir}/* ${D}${localedir} > > > > - fi > > > > + install -d ${D}${bindir} > > > > + find "${LOCALETREESRC}/${bindir}" -maxdepth 1 -type f \ > > > > + -exec install -m 0755 -t "${D}${bindir}" {} \; > > > > + > > > > + for d in . $(find "${LOCALETREESRC}/${localedir}" -type d -printf '%P ') ; do > > > > + install -d "${D}${localedir}/$d" > > > > + find "${LOCALETREESRC}/${localedir}/$d" -maxdepth 1 -type f \ > > > > + -exec install -m 0644 -t "${D}${localedir}/$d" {} \; > > > > + done > > > > if [ ${@d.getVar('PACKAGE_NO_GCONV')} -eq 0 ]; then > > > > - mkdir -p ${D}${libdir} > > > > - if [ -e ${LOCALETREESRC}/${libdir}/gconv ]; then > > > > - cp -R --no-dereference --preserve=mode,links ${LOCALETREESRC}/${libdir}/gconv ${D}${libdir} > > > > - fi > > > > - if [ -e ${LOCALETREESRC}/${datadir}/i18n ]; then > > > > - cp -R --no-dereference --preserve=mode,links ${LOCALETREESRC}/${datadir}/i18n ${D}${datadir} > > > > - fi > > > > - fi > > > > - if [ -e ${LOCALETREESRC}/${datadir}/locale ]; then > > > > - cp -R --no-dereference --preserve=mode,links ${LOCALETREESRC}/${datadir}/locale ${D}${datadir} > > > > + for d in . $(find "${LOCALETREESRC}/${libdir}/gconv" -type d -printf '%P ') ; do > > > > + install -d "${D}${libdir}/gconv/$d" > > > > + find "${LOCALETREESRC}/${libdir}/gconv/$d" -maxdepth 1 -type f \ > > > > + -exec install -m 0755 -t "${D}${libdir}/gconv/$d" {} \; > > > > + done > > > > + for d in . $(find "${LOCALETREESRC}/${datadir}/i18n" -type d -printf '%P ') ; do > > > > + install -d "${D}${datadir}/i18n/$d" > > > > + find "${LOCALETREESRC}/${datadir}/i18n/$d" -maxdepth 1 -type f \ > > > > + -exec install -m 0644 -t "${D}${datadir}/i18n/$d" {} \; > > > > + done > > > > fi > > > > - cp -R --no-dereference --preserve=mode,links ${LOCALETREESRC}/SUPPORTED ${WORKDIR} > > > > + for d in . $(find "${LOCALETREESRC}/${datadir}/locale" -type d -printf '%P ') ; do > > > > + install -d "${D}${datadir}/locale/$d" > > > > + find "${LOCALETREESRC}/${datadir}/locale/$d" -maxdepth 1 -type f \ > > > > + -exec install -m 0644 -t "${D}${datadir}/locale/$d" {} \; > > > > + done > > > > + install -m 0644 ${LOCALETREESRC}/SUPPORTED ${WORKDIR}/SUPPORTED > > > > } > > > > > > > > inherit libc-package > > > > > > The trouble is this is a workaround. The cp commands should work and > > > there is some underlying issue in pseudo causing this. We really need > > > to figure out what that is since this will likely just mean we see the > > > problem somewhere else :( > > > > so far this is the only place where it shows in world builds that > > meta-oe does which includes many layers. > > > > > > > > I still suspect some kind of inode number reuse problem which these cp > > > commands trigger... > > > > cp and install are not same when it comes to how they operate > > underneath. install is better when it comes to what we are doing here > > it also gives better control of permissions and mods,as a recipe writer > > someone would prefer then to let the tool ( cp ) assume it. > > > > So there might be a pseudo issue, I dont disagree but not obvious and > > I believe using cp is subpar anyway. > > > > > > > > Cheers, > > > > > > Richard > > > > > > > -- > > > > Joshua Watt <JPEWhacker@gmail.com> -- Martin 'JaMa' Jansa jabber: Martin.Jansa@gmail.com -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
On Thu, 2019-02-07 at 10:59 -0600, Joshua Watt wrote: > On Thu, Feb 7, 2019 at 10:44 AM Joshua Watt <jpewhacker@gmail.com> > wrote: > > Martin, > > > > Do you by any chance build in Docker (or some other transient > > container)? We recently found an issue with building in docker > > where when the primary container command would exit, causing the > > container to terminate. When the container terminates, the kernel > > unceremoniously sends SIGKILL to all its processes. This plays > > *very* poorly with pseudo because pseudo keeps it's entire database > > in a in-memory sqlite database and only flushes it out to disk on a > > periodic interval, or when it get SIGTERM (maybe SIGQUIT?) or exits > > normally. By default the pseudo daemon will also hang around for > > 20(?) seconds waiting for a new connection from a pseudo client, > > meaning that when our docker container was exiting, there were > > potentially several pseudo dameons sitting around waiting for a > > client with unflushed databases in memory that suddenly got a > > SIGKILL and all their data was lost. This was particularly bad if > > you aborted a build while it was running, or some build failure > > occurred. Since > the pseudo database was lost, the only way to correct these errors > was to clean and rebuild. > > I think pseudo could handle this better and keep the database on > > disk instead of in memory, but in the short term you can hack > > bitbake to pass the -S flag when invoking the pseudo client which > > will make it tell the dameon to shutdown (and thus flush the > > database) if it is the last connection. > > FWIW, this patch makes it much easier to do that > http://lists.openembedded.org/pipermail/bitbake-devel/2019-February/019813.html > Just add > FAKEROOTCMD += "-S" > in local.conf Should we be doing that by default? Is there a downside? Keeping the database flushed to disk would likely be slow but this seems reasonable. Cheers, Richard -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
On Thu, 2019-02-07 at 17:21 +0000, Richard Purdie wrote: > On Thu, 2019-02-07 at 10:59 -0600, Joshua Watt wrote: > > On Thu, Feb 7, 2019 at 10:44 AM Joshua Watt <jpewhacker@gmail.com> > > wrote: > > > Martin, > > > > > > Do you by any chance build in Docker (or some other transient > > > container)? We recently found an issue with building in docker > > > where when the primary container command would exit, causing the > > > container to terminate. When the container terminates, the kernel > > > unceremoniously sends SIGKILL to all its processes. This plays > > > *very* poorly with pseudo because pseudo keeps it's entire > > > database > > > in a in-memory sqlite database and only flushes it out to disk on > > > a > > > periodic interval, or when it get SIGTERM (maybe SIGQUIT?) or > > > exits > > > normally. By default the pseudo daemon will also hang around for > > > 20(?) seconds waiting for a new connection from a pseudo client, > > > meaning that when our docker container was exiting, there were > > > potentially several pseudo dameons sitting around waiting for a > > > client with unflushed databases in memory that suddenly got a > > > SIGKILL and all their data was lost. This was particularly bad if > > > you aborted a build while it was running, or some build failure > > > occurred. Since > > the pseudo database was lost, the only way to correct these errors > > was to clean and rebuild. > > > I think pseudo could handle this better and keep the database on > > > disk instead of in memory, but in the short term you can hack > > > bitbake to pass the -S flag when invoking the pseudo client which > > > will make it tell the dameon to shutdown (and thus flush the > > > database) if it is the last connection. > > > > FWIW, this patch makes it much easier to do that > > http://lists.openembedded.org/pipermail/bitbake-devel/2019-February/019813.html > > Just add > > FAKEROOTCMD += "-S" > > in local.conf > > Should we be doing that by default? Is there a downside? pseudo won't stick around waiting for connections from other clients. I'm not sure if this would impact performance at all, as I'm not sure how often a client is able to connect during the "grace period" to prevent a new server needing to be spun up. I would image this potentially cuts down on the spin up time for back-to-back fakeroot tasks in the same recipe? > > Keeping the database flushed to disk would likely be slow but this > seems reasonable. I think there are 3 options in increasing order of complexity/risk/safety 1. Add -S to FAKEROOTCMD by default 2. Make pseudo flush the in memory cache every time the last client disconnects 3. Remove the in-memory cache from pseudo completely and make it write to disk each time. Even if we removed all disk flushes from the sqlite database to keep sync()'s down, it would no worse that what happens today in any case I can think of (specifically, a power loss will cause lost data), and in many cases it would be better (e.g. SIGKILL and crashes in pseudo wouldn't cause data loss). > > Cheers, > > Richard > > -- Joshua Watt <JPEWhacker@gmail.com> -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
> -----Original Message----- > From: openembedded-core-bounces@lists.openembedded.org <openembedded- > core-bounces@lists.openembedded.org> On Behalf Of Richard Purdie > Sent: den 7 februari 2019 10:01 > To: Khem Raj <raj.khem@gmail.com>; openembedded- > core@lists.openembedded.org > Subject: Re: [OE-core] [PATCH] glibc-locale: Rewrite do_install using > install utility instead of cp > > On Wed, 2019-02-06 at 16:35 -0800, Khem Raj wrote: > > This has been a constant source of trouble for build failures due to > host-user-contaminated QA > > errors of sort > > > > 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] > > > > So far we have tried to mould cp command into not carrying the build > > user permissions into install area but it is never entirely fixed > since > > the issue keeps popping up in various scenes > > > > This patch replaces use of cp with install utility and specifies > install > > mode for files explcitly > > > > Signed-off-by: Khem Raj <raj.khem@gmail.com> > > --- > > meta/recipes-core/glibc/glibc-locale.inc | 44 ++++++++++++++-------- > -- > > 1 file changed, 25 insertions(+), 19 deletions(-) > > > > diff --git a/meta/recipes-core/glibc/glibc-locale.inc b/meta/recipes- > core/glibc/glibc-locale.inc > > index 6384f9cbf1..9b256a5108 100644 > > --- a/meta/recipes-core/glibc/glibc-locale.inc > > +++ b/meta/recipes-core/glibc/glibc-locale.inc > > @@ -72,27 +72,33 @@ FILES_localedef = "${bindir}/localedef" > > LOCALETREESRC = "${COMPONENTS_DIR}/${PACKAGE_ARCH}/glibc-stash- > locale" > > > > do_install () { > > - mkdir -p ${D}${bindir} ${D}${datadir} > > - if [ -n "$(ls ${LOCALETREESRC}/${bindir})" ]; then > > - cp -R --no-dereference --preserve=mode,links > ${LOCALETREESRC}/${bindir}/* ${D}${bindir} > > - fi > > - if [ -n "$(ls ${LOCALETREESRC}/${localedir})" ]; then > > - mkdir -p ${D}${localedir} > > - cp -R --no-dereference --preserve=mode,links > ${LOCALETREESRC}/${localedir}/* ${D}${localedir} > > - fi > > + install -d ${D}${bindir} > > + find "${LOCALETREESRC}/${bindir}" -maxdepth 1 -type f \ > > + -exec install -m 0755 -t "${D}${bindir}" {} \; > > + > > + for d in . $(find "${LOCALETREESRC}/${localedir}" -type d - > printf '%P ') ; do > > + install -d "${D}${localedir}/$d" > > + find "${LOCALETREESRC}/${localedir}/$d" -maxdepth 1 > -type f \ > > + -exec install -m 0644 -t "${D}${localedir}/$d" {} \; > > + done > > if [ ${@d.getVar('PACKAGE_NO_GCONV')} -eq 0 ]; then > > - mkdir -p ${D}${libdir} > > - if [ -e ${LOCALETREESRC}/${libdir}/gconv ]; then > > - cp -R --no-dereference -- > preserve=mode,links ${LOCALETREESRC}/${libdir}/gconv ${D}${libdir} > > - fi > > - if [ -e ${LOCALETREESRC}/${datadir}/i18n ]; then > > - cp -R --no-dereference -- > preserve=mode,links ${LOCALETREESRC}/${datadir}/i18n ${D}${datadir} > > - fi > > - fi > > - if [ -e ${LOCALETREESRC}/${datadir}/locale ]; then > > - cp -R --no-dereference --preserve=mode,links > ${LOCALETREESRC}/${datadir}/locale ${D}${datadir} > > + for d in . $(find "${LOCALETREESRC}/${libdir}/gconv" > -type d -printf '%P ') ; do > > + install -d "${D}${libdir}/gconv/$d" > > + find "${LOCALETREESRC}/${libdir}/gconv/$d" - > maxdepth 1 -type f \ > > + -exec install -m 0755 -t > "${D}${libdir}/gconv/$d" {} \; > > + done > > + for d in . $(find "${LOCALETREESRC}/${datadir}/i18n" > -type d -printf '%P ') ; do > > + install -d "${D}${datadir}/i18n/$d" > > + find "${LOCALETREESRC}/${datadir}/i18n/$d" - > maxdepth 1 -type f \ > > + -exec install -m 0644 -t > "${D}${datadir}/i18n/$d" {} \; > > + done > > fi > > - cp -R --no-dereference --preserve=mode,links > ${LOCALETREESRC}/SUPPORTED ${WORKDIR} > > + for d in . $(find "${LOCALETREESRC}/${datadir}/locale" -type > d -printf '%P ') ; do > > + install -d "${D}${datadir}/locale/$d" > > + find "${LOCALETREESRC}/${datadir}/locale/$d" - > maxdepth 1 -type f \ > > + -exec install -m 0644 -t "${D}${datadir}/locale/$d" > {} \; > > + done > > + install -m 0644 ${LOCALETREESRC}/SUPPORTED > ${WORKDIR}/SUPPORTED > > } > > > > inherit libc-package > > The trouble is this is a workaround. The cp commands should work and > there is some underlying issue in pseudo causing this. We really need > to figure out what that is since this will likely just mean we see the > problem somewhere else :( > > I still suspect some kind of inode number reuse problem which these cp > commands trigger... > > Cheers, > > Richard For the record, even if I think the patch was the right thing to do, it did not help the situation. The first build I did after it was integrated, I was bit by the following: Failed to determine the user name of UID 323 for tmp/work/core2-64-poky-linux/glibc-locale/2.29-r0/package/usr/lib/locale where UID 323 is my UID. If you do not recognize the error message, it is because it comes from a local patch we have for rpm to protect us from any incorrect UIDs/GIDs causing incorrect RPMs to be generated (see below). I checked the build directory and the /usr/lib/locale directory was the only file or directory with an incorrect owner, which is typical of these pseudo related problems with incorrect owners. [rpm will by default silently fall back to use root for any files where it cannot determine the name of the user or group based on its UID/GID. This can be due to missing information in the /etc/passwd or /etc/groups files, typically due to relying on another recipe in DEPENDS to create the user without also having an RDEPENDS on the package that creates the user, or because of pseudo messing up. After this bit us once where a device in /dev ended up in an rpm in the sstate cache with root as group instead of the intended video group, which in turn caused the video application to fail as it was no longer allowed to open its device, I created the patch. It is causing a fair bit of grief as it causes builds to fail randomly, but at least we don't end up with an incorrect sstate anymore, which is worse. I am not sure this patch is suitable for integration to OE-Core, but I have attached it if anyone is interested.] //Peter -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
> -----Original Message----- > From: openembedded-core-bounces@lists.openembedded.org <openembedded- > core-bounces@lists.openembedded.org> On Behalf Of Peter Kjellerstedt > Sent: den 10 februari 2019 02:29 > To: Richard Purdie <richard.purdie@linuxfoundation.org>; Khem Raj > <raj.khem@gmail.com>; openembedded-core@lists.openembedded.org > Subject: Re: [OE-core] [PATCH] glibc-locale: Rewrite do_install using > install utility instead of cp > > > -----Original Message----- > > From: openembedded-core-bounces@lists.openembedded.org <openembedded- > > core-bounces@lists.openembedded.org> On Behalf Of Richard Purdie > > Sent: den 7 februari 2019 10:01 > > To: Khem Raj <raj.khem@gmail.com>; openembedded- > > core@lists.openembedded.org > > Subject: Re: [OE-core] [PATCH] glibc-locale: Rewrite do_install using > > install utility instead of cp > > > > On Wed, 2019-02-06 at 16:35 -0800, Khem Raj wrote: > > > This has been a constant source of trouble for build failures due > to > > host-user-contaminated QA > > > errors of sort > > > > > > 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] > > > > > > So far we have tried to mould cp command into not carrying the > build > > > user permissions into install area but it is never entirely fixed > > since > > > the issue keeps popping up in various scenes > > > > > > This patch replaces use of cp with install utility and specifies > > install > > > mode for files explcitly > > > > > > Signed-off-by: Khem Raj <raj.khem@gmail.com> > > > --- > > > meta/recipes-core/glibc/glibc-locale.inc | 44 ++++++++++++++------ > -- > > -- > > > 1 file changed, 25 insertions(+), 19 deletions(-) > > > > > > diff --git a/meta/recipes-core/glibc/glibc-locale.inc > b/meta/recipes- > > core/glibc/glibc-locale.inc > > > index 6384f9cbf1..9b256a5108 100644 > > > --- a/meta/recipes-core/glibc/glibc-locale.inc > > > +++ b/meta/recipes-core/glibc/glibc-locale.inc > > > @@ -72,27 +72,33 @@ FILES_localedef = "${bindir}/localedef" > > > LOCALETREESRC = "${COMPONENTS_DIR}/${PACKAGE_ARCH}/glibc-stash- > > locale" > > > > > > do_install () { > > > - mkdir -p ${D}${bindir} ${D}${datadir} > > > - if [ -n "$(ls ${LOCALETREESRC}/${bindir})" ]; then > > > - cp -R --no-dereference --preserve=mode,links > > ${LOCALETREESRC}/${bindir}/* ${D}${bindir} > > > - fi > > > - if [ -n "$(ls ${LOCALETREESRC}/${localedir})" ]; then > > > - mkdir -p ${D}${localedir} > > > - cp -R --no-dereference --preserve=mode,links > > ${LOCALETREESRC}/${localedir}/* ${D}${localedir} > > > - fi > > > + install -d ${D}${bindir} > > > + find "${LOCALETREESRC}/${bindir}" -maxdepth 1 -type f \ > > > + -exec install -m 0755 -t "${D}${bindir}" {} \; > > > + > > > + for d in . $(find "${LOCALETREESRC}/${localedir}" -type d > - > > printf '%P ') ; do > > > + install -d "${D}${localedir}/$d" > > > + find "${LOCALETREESRC}/${localedir}/$d" -maxdepth > 1 > > -type f \ > > > + -exec install -m 0644 -t "${D}${localedir}/$d" {} > \; > > > + done > > > if [ ${@d.getVar('PACKAGE_NO_GCONV')} -eq 0 ]; then > > > - mkdir -p ${D}${libdir} > > > - if [ -e ${LOCALETREESRC}/${libdir}/gconv ]; then > > > - cp -R --no-dereference -- > > preserve=mode,links ${LOCALETREESRC}/${libdir}/gconv ${D}${libdir} > > > - fi > > > - if [ -e ${LOCALETREESRC}/${datadir}/i18n ]; then > > > - cp -R --no-dereference -- > > preserve=mode,links ${LOCALETREESRC}/${datadir}/i18n ${D}${datadir} > > > - fi > > > - fi > > > - if [ -e ${LOCALETREESRC}/${datadir}/locale ]; then > > > - cp -R --no-dereference --preserve=mode,links > > ${LOCALETREESRC}/${datadir}/locale ${D}${datadir} > > > + for d in . $(find > "${LOCALETREESRC}/${libdir}/gconv" > > -type d -printf '%P ') ; do > > > + install -d "${D}${libdir}/gconv/$d" > > > + find "${LOCALETREESRC}/${libdir}/gconv/$d" > - > > maxdepth 1 -type f \ > > > + -exec install -m 0755 -t > > "${D}${libdir}/gconv/$d" {} \; > > > + done > > > + for d in . $(find > "${LOCALETREESRC}/${datadir}/i18n" > > -type d -printf '%P ') ; do > > > + install -d "${D}${datadir}/i18n/$d" > > > + find "${LOCALETREESRC}/${datadir}/i18n/$d" > - > > maxdepth 1 -type f \ > > > + -exec install -m 0644 -t > > "${D}${datadir}/i18n/$d" {} \; > > > + done > > > fi > > > - cp -R --no-dereference --preserve=mode,links > > ${LOCALETREESRC}/SUPPORTED ${WORKDIR} > > > + for d in . $(find "${LOCALETREESRC}/${datadir}/locale" - > type > > d -printf '%P ') ; do > > > + install -d "${D}${datadir}/locale/$d" > > > + find "${LOCALETREESRC}/${datadir}/locale/$d" - > > maxdepth 1 -type f \ > > > + -exec install -m 0644 -t > "${D}${datadir}/locale/$d" > > {} \; > > > + done > > > + install -m 0644 ${LOCALETREESRC}/SUPPORTED > > ${WORKDIR}/SUPPORTED > > > } > > > > > > inherit libc-package > > > > The trouble is this is a workaround. The cp commands should work and > > there is some underlying issue in pseudo causing this. We really need > > to figure out what that is since this will likely just mean we see > the > > problem somewhere else :( > > > > I still suspect some kind of inode number reuse problem which these > cp > > commands trigger... > > > > Cheers, > > > > Richard > > For the record, even if I think the patch was the right thing to do, > it did not help the situation. The first build I did after it was > integrated, I was bit by the following: > > Failed to determine the user name of UID 323 for > tmp/work/core2-64-poky-linux/glibc-locale/2.29-r0/package/usr/lib/locale > > where UID 323 is my UID. If you do not recognize the error message, > it is because it comes from a local patch we have for rpm to protect > us from any incorrect UIDs/GIDs causing incorrect RPMs to be generated > (see below). I checked the build directory and the /usr/lib/locale > directory was the only file or directory with an incorrect owner, > which is typical of these pseudo related problems with incorrect > owners. > > [rpm will by default silently fall back to use root for any files > where it cannot determine the name of the user or group based on > its UID/GID. This can be due to missing information in the > /etc/passwd or /etc/groups files, typically due to relying on > another recipe in DEPENDS to create the user without also having > an RDEPENDS on the package that creates the user, or because of > pseudo messing up. After this bit us once where a device in /dev > ended up in an rpm in the sstate cache with root as group instead > of the intended video group, which in turn caused the video > application to fail as it was no longer allowed to open its device, > I created the patch. It is causing a fair bit of grief as it causes > builds to fail randomly, but at least we don't end up with an > incorrect sstate anymore, which is worse. I am not sure this patch > is suitable for integration to OE-Core, but I have attached it if > anyone is interested.] > > //Peter Ok, this just got a lot more weird. At the time I wrote the mail above, I had only tried to rebuild once. Now I have done it a number of more times, and the result is not random any more. Every build fails the same way. I've done `bitbake glibc-locale -c cleansstate` followed by `bitbake glibc-locale` and the result is consistent. What I have noted now, is that it is _not_ do_install that causes the problem. The /usr/lib/locale directory created in ${D} has the correct owner. It is when the data is copied to ${PKGD} that it somehow ends up with the wrong owner. I cannot tell from a quick glance what differs /usr/lib/locale from, e.g., /usr/lib/gconv, where the latter does get the correct owner. Unfortunately, I do not have more time to look at this right now, but I thought I should share this information with you. If anyone has any ideas of what to look at to determine why ${PKGD}/usr/lib/locale ends up with the wrong owner, I'm all ears. It would also be interesting to hear if the result is the same for anyone else with the patch I provided in my previous mail applied. //Peter -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
> -----Original Message----- > From: openembedded-core-bounces@lists.openembedded.org <openembedded- > core-bounces@lists.openembedded.org> On Behalf Of Peter Kjellerstedt > Sent: den 10 februari 2019 07:25 > To: Richard Purdie <richard.purdie@linuxfoundation.org>; Khem Raj > <raj.khem@gmail.com>; openembedded-core@lists.openembedded.org > Subject: Re: [OE-core] [PATCH] glibc-locale: Rewrite do_install using > install utility instead of cp > > > -----Original Message----- > > From: openembedded-core-bounces@lists.openembedded.org <openembedded- > > core-bounces@lists.openembedded.org> On Behalf Of Peter Kjellerstedt > > Sent: den 10 februari 2019 02:29 > > To: Richard Purdie <richard.purdie@linuxfoundation.org>; Khem Raj > > <raj.khem@gmail.com>; openembedded-core@lists.openembedded.org > > Subject: Re: [OE-core] [PATCH] glibc-locale: Rewrite do_install using > > install utility instead of cp > > > > > -----Original Message----- > > > From: openembedded-core-bounces@lists.openembedded.org > <openembedded- > > > core-bounces@lists.openembedded.org> On Behalf Of Richard Purdie > > > Sent: den 7 februari 2019 10:01 > > > To: Khem Raj <raj.khem@gmail.com>; openembedded- > > > core@lists.openembedded.org > > > Subject: Re: [OE-core] [PATCH] glibc-locale: Rewrite do_install > using > > > install utility instead of cp > > > > > > On Wed, 2019-02-06 at 16:35 -0800, Khem Raj wrote: > > > > This has been a constant source of trouble for build failures due > > to > > > host-user-contaminated QA > > > > errors of sort > > > > > > > > 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] > > > > > > > > So far we have tried to mould cp command into not carrying the > > build > > > > user permissions into install area but it is never entirely fixed > > > since > > > > the issue keeps popping up in various scenes > > > > > > > > This patch replaces use of cp with install utility and specifies > > > install > > > > mode for files explcitly > > > > > > > > Signed-off-by: Khem Raj <raj.khem@gmail.com> > > > > --- > > > > meta/recipes-core/glibc/glibc-locale.inc | 44 ++++++++++++++---- > -- > > -- > > > -- > > > > 1 file changed, 25 insertions(+), 19 deletions(-) > > > > > > > > diff --git a/meta/recipes-core/glibc/glibc-locale.inc > > b/meta/recipes- > > > core/glibc/glibc-locale.inc > > > > index 6384f9cbf1..9b256a5108 100644 > > > > --- a/meta/recipes-core/glibc/glibc-locale.inc > > > > +++ b/meta/recipes-core/glibc/glibc-locale.inc > > > > @@ -72,27 +72,33 @@ FILES_localedef = "${bindir}/localedef" > > > > LOCALETREESRC = "${COMPONENTS_DIR}/${PACKAGE_ARCH}/glibc-stash- > > > locale" > > > > > > > > do_install () { > > > > - mkdir -p ${D}${bindir} ${D}${datadir} > > > > - if [ -n "$(ls ${LOCALETREESRC}/${bindir})" ]; then > > > > - cp -R --no-dereference --preserve=mode,links > > > ${LOCALETREESRC}/${bindir}/* ${D}${bindir} > > > > - fi > > > > - if [ -n "$(ls ${LOCALETREESRC}/${localedir})" ]; then > > > > - mkdir -p ${D}${localedir} > > > > - cp -R --no-dereference --preserve=mode,links > > > ${LOCALETREESRC}/${localedir}/* ${D}${localedir} > > > > - fi > > > > + install -d ${D}${bindir} > > > > + find "${LOCALETREESRC}/${bindir}" -maxdepth 1 -type f \ > > > > + -exec install -m 0755 -t "${D}${bindir}" {} \; > > > > + > > > > + for d in . $(find "${LOCALETREESRC}/${localedir}" -type > d > > - > > > printf '%P ') ; do > > > > + install -d "${D}${localedir}/$d" > > > > + find "${LOCALETREESRC}/${localedir}/$d" - > maxdepth > > 1 > > > -type f \ > > > > + -exec install -m 0644 -t "${D}${localedir}/$d" > {} > > \; > > > > + done > > > > if [ ${@d.getVar('PACKAGE_NO_GCONV')} -eq 0 ]; then > > > > - mkdir -p ${D}${libdir} > > > > - if [ -e ${LOCALETREESRC}/${libdir}/gconv ]; then > > > > - cp -R --no-dereference -- > > > preserve=mode,links ${LOCALETREESRC}/${libdir}/gconv ${D}${libdir} > > > > - fi > > > > - if [ -e ${LOCALETREESRC}/${datadir}/i18n ]; then > > > > - cp -R --no-dereference -- > > > preserve=mode,links ${LOCALETREESRC}/${datadir}/i18n ${D}${datadir} > > > > - fi > > > > - fi > > > > - if [ -e ${LOCALETREESRC}/${datadir}/locale ]; then > > > > - cp -R --no-dereference --preserve=mode,links > > > ${LOCALETREESRC}/${datadir}/locale ${D}${datadir} > > > > + for d in . $(find > > "${LOCALETREESRC}/${libdir}/gconv" > > > -type d -printf '%P ') ; do > > > > + install -d "${D}${libdir}/gconv/$d" > > > > + find > "${LOCALETREESRC}/${libdir}/gconv/$d" > > - > > > maxdepth 1 -type f \ > > > > + -exec install -m 0755 -t > > > "${D}${libdir}/gconv/$d" {} \; > > > > + done > > > > + for d in . $(find > > "${LOCALETREESRC}/${datadir}/i18n" > > > -type d -printf '%P ') ; do > > > > + install -d "${D}${datadir}/i18n/$d" > > > > + find > "${LOCALETREESRC}/${datadir}/i18n/$d" > > - > > > maxdepth 1 -type f \ > > > > + -exec install -m 0644 -t > > > "${D}${datadir}/i18n/$d" {} \; > > > > + done > > > > fi > > > > - cp -R --no-dereference --preserve=mode,links > > > ${LOCALETREESRC}/SUPPORTED ${WORKDIR} > > > > + for d in . $(find "${LOCALETREESRC}/${datadir}/locale" - > > type > > > d -printf '%P ') ; do > > > > + install -d "${D}${datadir}/locale/$d" > > > > + find "${LOCALETREESRC}/${datadir}/locale/$d" - > > > maxdepth 1 -type f \ > > > > + -exec install -m 0644 -t > > "${D}${datadir}/locale/$d" > > > {} \; > > > > + done > > > > + install -m 0644 ${LOCALETREESRC}/SUPPORTED > > > ${WORKDIR}/SUPPORTED > > > > } > > > > > > > > inherit libc-package > > > > > > The trouble is this is a workaround. The cp commands should work > and > > > there is some underlying issue in pseudo causing this. We really > need > > > to figure out what that is since this will likely just mean we see > > the > > > problem somewhere else :( > > > > > > I still suspect some kind of inode number reuse problem which these > > cp > > > commands trigger... > > > > > > Cheers, > > > > > > Richard > > > > For the record, even if I think the patch was the right thing to do, > > it did not help the situation. The first build I did after it was > > integrated, I was bit by the following: > > > > Failed to determine the user name of UID 323 for > > tmp/work/core2-64-poky-linux/glibc-locale/2.29- > r0/package/usr/lib/locale > > > > where UID 323 is my UID. If you do not recognize the error message, > > it is because it comes from a local patch we have for rpm to protect > > us from any incorrect UIDs/GIDs causing incorrect RPMs to be > generated > > (see below). I checked the build directory and the /usr/lib/locale > > directory was the only file or directory with an incorrect owner, > > which is typical of these pseudo related problems with incorrect > > owners. > > > > [rpm will by default silently fall back to use root for any files > > where it cannot determine the name of the user or group based on > > its UID/GID. This can be due to missing information in the > > /etc/passwd or /etc/groups files, typically due to relying on > > another recipe in DEPENDS to create the user without also having > > an RDEPENDS on the package that creates the user, or because of > > pseudo messing up. After this bit us once where a device in /dev > > ended up in an rpm in the sstate cache with root as group instead > > of the intended video group, which in turn caused the video > > application to fail as it was no longer allowed to open its device, > > I created the patch. It is causing a fair bit of grief as it causes > > builds to fail randomly, but at least we don't end up with an > > incorrect sstate anymore, which is worse. I am not sure this patch > > is suitable for integration to OE-Core, but I have attached it if > > anyone is interested.] > > > > //Peter > > Ok, this just got a lot more weird. At the time I wrote the mail > above, I had only tried to rebuild once. Now I have done it a number > of more times, and the result is not random any more. Every build > fails the same way. I've done `bitbake glibc-locale -c cleansstate` > followed by `bitbake glibc-locale` and the result is consistent. > What I have noted now, is that it is _not_ do_install that causes > the problem. The /usr/lib/locale directory created in ${D} has > the correct owner. It is when the data is copied to ${PKGD} that > it somehow ends up with the wrong owner. I cannot tell from a quick > glance what differs /usr/lib/locale from, e.g., /usr/lib/gconv, > where the latter does get the correct owner. > > Unfortunately, I do not have more time to look at this right now, > but I thought I should share this information with you. If anyone > has any ideas of what to look at to determine why > ${PKGD}/usr/lib/locale ends up with the wrong owner, I'm all ears. > It would also be interesting to hear if the result is the same for > anyone else with the patch I provided in my previous mail applied. > > //Peter Further investigation indicates that the problem I'm seeing is not related to pseudo, but an actual problem in the code. I have not dug too far into it, but I'm seeing the problem in the directories used in do_prep_locale_tree() and do_collect_bins_from_locale_tree() in libc-package.bbclass where some of them seems to have been created without being run under pseudo. The following patch works around the problem, though it would probably be better to correct the problem at the source by running whatever part of the code under pseudo that is currently missing it: diff --git a/meta/classes/libc-package.bbclass b/meta/classes/libc-package.bbclass index 0b4c666a74..174465a891 100644 --- a/meta/classes/libc-package.bbclass +++ b/meta/classes/libc-package.bbclass @@ -72,6 +72,7 @@ do_prep_locale_tree() { tar -cf - -C ${STAGING_DIR_NATIVE}/${prefix_native}/${base_libdir} -p libgcc_s.* | tar -xf - -C $treedir/${base_libdir} fi install -m 0755 ${LOCALETREESRC}${bindir}/localedef $treedir/${base_bindir} + chown -R root:root $treedir } do_collect_bins_from_locale_tree() { //Peter -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
On Sun, Feb 10, 2019 at 3:32 PM Peter Kjellerstedt <peter.kjellerstedt@axis.com> wrote: > > > -----Original Message----- > > From: openembedded-core-bounces@lists.openembedded.org <openembedded- > > core-bounces@lists.openembedded.org> On Behalf Of Peter Kjellerstedt > > Sent: den 10 februari 2019 07:25 > > To: Richard Purdie <richard.purdie@linuxfoundation.org>; Khem Raj > > <raj.khem@gmail.com>; openembedded-core@lists.openembedded.org > > Subject: Re: [OE-core] [PATCH] glibc-locale: Rewrite do_install using > > install utility instead of cp > > > > > -----Original Message----- > > > From: openembedded-core-bounces@lists.openembedded.org <openembedded- > > > core-bounces@lists.openembedded.org> On Behalf Of Peter Kjellerstedt > > > Sent: den 10 februari 2019 02:29 > > > To: Richard Purdie <richard.purdie@linuxfoundation.org>; Khem Raj > > > <raj.khem@gmail.com>; openembedded-core@lists.openembedded.org > > > Subject: Re: [OE-core] [PATCH] glibc-locale: Rewrite do_install using > > > install utility instead of cp > > > > > > > -----Original Message----- > > > > From: openembedded-core-bounces@lists.openembedded.org > > <openembedded- > > > > core-bounces@lists.openembedded.org> On Behalf Of Richard Purdie > > > > Sent: den 7 februari 2019 10:01 > > > > To: Khem Raj <raj.khem@gmail.com>; openembedded- > > > > core@lists.openembedded.org > > > > Subject: Re: [OE-core] [PATCH] glibc-locale: Rewrite do_install > > using > > > > install utility instead of cp > > > > > > > > On Wed, 2019-02-06 at 16:35 -0800, Khem Raj wrote: > > > > > This has been a constant source of trouble for build failures due > > > to > > > > host-user-contaminated QA > > > > > errors of sort > > > > > > > > > > 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] > > > > > > > > > > So far we have tried to mould cp command into not carrying the > > > build > > > > > user permissions into install area but it is never entirely fixed > > > > since > > > > > the issue keeps popping up in various scenes > > > > > > > > > > This patch replaces use of cp with install utility and specifies > > > > install > > > > > mode for files explcitly > > > > > > > > > > Signed-off-by: Khem Raj <raj.khem@gmail.com> > > > > > --- > > > > > meta/recipes-core/glibc/glibc-locale.inc | 44 ++++++++++++++---- > > -- > > > -- > > > > -- > > > > > 1 file changed, 25 insertions(+), 19 deletions(-) > > > > > > > > > > diff --git a/meta/recipes-core/glibc/glibc-locale.inc > > > b/meta/recipes- > > > > core/glibc/glibc-locale.inc > > > > > index 6384f9cbf1..9b256a5108 100644 > > > > > --- a/meta/recipes-core/glibc/glibc-locale.inc > > > > > +++ b/meta/recipes-core/glibc/glibc-locale.inc > > > > > @@ -72,27 +72,33 @@ FILES_localedef = "${bindir}/localedef" > > > > > LOCALETREESRC = "${COMPONENTS_DIR}/${PACKAGE_ARCH}/glibc-stash- > > > > locale" > > > > > > > > > > do_install () { > > > > > - mkdir -p ${D}${bindir} ${D}${datadir} > > > > > - if [ -n "$(ls ${LOCALETREESRC}/${bindir})" ]; then > > > > > - cp -R --no-dereference --preserve=mode,links > > > > ${LOCALETREESRC}/${bindir}/* ${D}${bindir} > > > > > - fi > > > > > - if [ -n "$(ls ${LOCALETREESRC}/${localedir})" ]; then > > > > > - mkdir -p ${D}${localedir} > > > > > - cp -R --no-dereference --preserve=mode,links > > > > ${LOCALETREESRC}/${localedir}/* ${D}${localedir} > > > > > - fi > > > > > + install -d ${D}${bindir} > > > > > + find "${LOCALETREESRC}/${bindir}" -maxdepth 1 -type f \ > > > > > + -exec install -m 0755 -t "${D}${bindir}" {} \; > > > > > + > > > > > + for d in . $(find "${LOCALETREESRC}/${localedir}" -type > > d > > > - > > > > printf '%P ') ; do > > > > > + install -d "${D}${localedir}/$d" > > > > > + find "${LOCALETREESRC}/${localedir}/$d" - > > maxdepth > > > 1 > > > > -type f \ > > > > > + -exec install -m 0644 -t "${D}${localedir}/$d" > > {} > > > \; > > > > > + done > > > > > if [ ${@d.getVar('PACKAGE_NO_GCONV')} -eq 0 ]; then > > > > > - mkdir -p ${D}${libdir} > > > > > - if [ -e ${LOCALETREESRC}/${libdir}/gconv ]; then > > > > > - cp -R --no-dereference -- > > > > preserve=mode,links ${LOCALETREESRC}/${libdir}/gconv ${D}${libdir} > > > > > - fi > > > > > - if [ -e ${LOCALETREESRC}/${datadir}/i18n ]; then > > > > > - cp -R --no-dereference -- > > > > preserve=mode,links ${LOCALETREESRC}/${datadir}/i18n ${D}${datadir} > > > > > - fi > > > > > - fi > > > > > - if [ -e ${LOCALETREESRC}/${datadir}/locale ]; then > > > > > - cp -R --no-dereference --preserve=mode,links > > > > ${LOCALETREESRC}/${datadir}/locale ${D}${datadir} > > > > > + for d in . $(find > > > "${LOCALETREESRC}/${libdir}/gconv" > > > > -type d -printf '%P ') ; do > > > > > + install -d "${D}${libdir}/gconv/$d" > > > > > + find > > "${LOCALETREESRC}/${libdir}/gconv/$d" > > > - > > > > maxdepth 1 -type f \ > > > > > + -exec install -m 0755 -t > > > > "${D}${libdir}/gconv/$d" {} \; > > > > > + done > > > > > + for d in . $(find > > > "${LOCALETREESRC}/${datadir}/i18n" > > > > -type d -printf '%P ') ; do > > > > > + install -d "${D}${datadir}/i18n/$d" > > > > > + find > > "${LOCALETREESRC}/${datadir}/i18n/$d" > > > - > > > > maxdepth 1 -type f \ > > > > > + -exec install -m 0644 -t > > > > "${D}${datadir}/i18n/$d" {} \; > > > > > + done > > > > > fi > > > > > - cp -R --no-dereference --preserve=mode,links > > > > ${LOCALETREESRC}/SUPPORTED ${WORKDIR} > > > > > + for d in . $(find "${LOCALETREESRC}/${datadir}/locale" - > > > type > > > > d -printf '%P ') ; do > > > > > + install -d "${D}${datadir}/locale/$d" > > > > > + find "${LOCALETREESRC}/${datadir}/locale/$d" - > > > > maxdepth 1 -type f \ > > > > > + -exec install -m 0644 -t > > > "${D}${datadir}/locale/$d" > > > > {} \; > > > > > + done > > > > > + install -m 0644 ${LOCALETREESRC}/SUPPORTED > > > > ${WORKDIR}/SUPPORTED > > > > > } > > > > > > > > > > inherit libc-package > > > > > > > > The trouble is this is a workaround. The cp commands should work > > and > > > > there is some underlying issue in pseudo causing this. We really > > need > > > > to figure out what that is since this will likely just mean we see > > > the > > > > problem somewhere else :( > > > > > > > > I still suspect some kind of inode number reuse problem which these > > > cp > > > > commands trigger... > > > > > > > > Cheers, > > > > > > > > Richard > > > > > > For the record, even if I think the patch was the right thing to do, > > > it did not help the situation. The first build I did after it was > > > integrated, I was bit by the following: > > > > > > Failed to determine the user name of UID 323 for > > > tmp/work/core2-64-poky-linux/glibc-locale/2.29- > > r0/package/usr/lib/locale > > > > > > where UID 323 is my UID. If you do not recognize the error message, > > > it is because it comes from a local patch we have for rpm to protect > > > us from any incorrect UIDs/GIDs causing incorrect RPMs to be > > generated > > > (see below). I checked the build directory and the /usr/lib/locale > > > directory was the only file or directory with an incorrect owner, > > > which is typical of these pseudo related problems with incorrect > > > owners. > > > > > > [rpm will by default silently fall back to use root for any files > > > where it cannot determine the name of the user or group based on > > > its UID/GID. This can be due to missing information in the > > > /etc/passwd or /etc/groups files, typically due to relying on > > > another recipe in DEPENDS to create the user without also having > > > an RDEPENDS on the package that creates the user, or because of > > > pseudo messing up. After this bit us once where a device in /dev > > > ended up in an rpm in the sstate cache with root as group instead > > > of the intended video group, which in turn caused the video > > > application to fail as it was no longer allowed to open its device, > > > I created the patch. It is causing a fair bit of grief as it causes > > > builds to fail randomly, but at least we don't end up with an > > > incorrect sstate anymore, which is worse. I am not sure this patch > > > is suitable for integration to OE-Core, but I have attached it if > > > anyone is interested.] > > > > > > //Peter > > > > Ok, this just got a lot more weird. At the time I wrote the mail > > above, I had only tried to rebuild once. Now I have done it a number > > of more times, and the result is not random any more. Every build > > fails the same way. I've done `bitbake glibc-locale -c cleansstate` > > followed by `bitbake glibc-locale` and the result is consistent. > > What I have noted now, is that it is _not_ do_install that causes > > the problem. The /usr/lib/locale directory created in ${D} has > > the correct owner. It is when the data is copied to ${PKGD} that > > it somehow ends up with the wrong owner. I cannot tell from a quick > > glance what differs /usr/lib/locale from, e.g., /usr/lib/gconv, > > where the latter does get the correct owner. > > > > Unfortunately, I do not have more time to look at this right now, > > but I thought I should share this information with you. If anyone > > has any ideas of what to look at to determine why > > ${PKGD}/usr/lib/locale ends up with the wrong owner, I'm all ears. > > It would also be interesting to hear if the result is the same for > > anyone else with the patch I provided in my previous mail applied. > > > > //Peter > > Further investigation indicates that the problem I'm seeing is not > related to pseudo, but an actual problem in the code. I have not dug > too far into it, but I'm seeing the problem in the directories used > in do_prep_locale_tree() and do_collect_bins_from_locale_tree() in > libc-package.bbclass where some of them seems to have been created > without being run under pseudo. The following patch works around the > problem, though it would probably be better to correct the problem > at the source by running whatever part of the code under pseudo that > is currently missing it: > > diff --git a/meta/classes/libc-package.bbclass b/meta/classes/libc-package.bbclass > index 0b4c666a74..174465a891 100644 > --- a/meta/classes/libc-package.bbclass > +++ b/meta/classes/libc-package.bbclass > @@ -72,6 +72,7 @@ do_prep_locale_tree() { > tar -cf - -C ${STAGING_DIR_NATIVE}/${prefix_native}/${base_libdir} -p libgcc_s.* | tar -xf - -C $treedir/${base_libdir} > fi > install -m 0755 ${LOCALETREESRC}${bindir}/localedef $treedir/${base_bindir} > + chown -R root:root $treedir > } > > do_collect_bins_from_locale_tree() { > Can you try something on the lines diff --git a/meta/classes/libc-package.bbclass b/meta/classes/libc-package.bbclass index 0b4c666a74..34025635ce 100644 --- a/meta/classes/libc-package.bbclass +++ b/meta/classes/libc-package.bbclass @@ -61,7 +61,7 @@ LOCALETREESRC ?= "${PKGD}" do_prep_locale_tree() { treedir=${WORKDIR}/locale-tree rm -rf $treedir - mkdir -p $treedir/${base_bindir} $treedir/${base_libdir} $treedir/${datadir} $treedir/${localedir} + install -d $treedir/${base_bindir} $treedir/${base_libdir} $treedir/${datadir} $treedir/${localedir} tar -cf - -C ${LOCALETREESRC}${datadir} -p i18n | tar -xf - -C $treedir/${datadir} # unzip to avoid parsing errors for i in $treedir/${datadir}/i18n/charmaps/*gz; do > //Peter -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Peter did you have a chance to try https://patchwork.openembedded.org/patch/158661/ On Sun, Feb 10, 2019 at 6:09 PM Khem Raj <raj.khem@gmail.com> wrote: > > On Sun, Feb 10, 2019 at 3:32 PM Peter Kjellerstedt > <peter.kjellerstedt@axis.com> wrote: > > > > > -----Original Message----- > > > From: openembedded-core-bounces@lists.openembedded.org <openembedded- > > > core-bounces@lists.openembedded.org> On Behalf Of Peter Kjellerstedt > > > Sent: den 10 februari 2019 07:25 > > > To: Richard Purdie <richard.purdie@linuxfoundation.org>; Khem Raj > > > <raj.khem@gmail.com>; openembedded-core@lists.openembedded.org > > > Subject: Re: [OE-core] [PATCH] glibc-locale: Rewrite do_install using > > > install utility instead of cp > > > > > > > -----Original Message----- > > > > From: openembedded-core-bounces@lists.openembedded.org <openembedded- > > > > core-bounces@lists.openembedded.org> On Behalf Of Peter Kjellerstedt > > > > Sent: den 10 februari 2019 02:29 > > > > To: Richard Purdie <richard.purdie@linuxfoundation.org>; Khem Raj > > > > <raj.khem@gmail.com>; openembedded-core@lists.openembedded.org > > > > Subject: Re: [OE-core] [PATCH] glibc-locale: Rewrite do_install using > > > > install utility instead of cp > > > > > > > > > -----Original Message----- > > > > > From: openembedded-core-bounces@lists.openembedded.org > > > <openembedded- > > > > > core-bounces@lists.openembedded.org> On Behalf Of Richard Purdie > > > > > Sent: den 7 februari 2019 10:01 > > > > > To: Khem Raj <raj.khem@gmail.com>; openembedded- > > > > > core@lists.openembedded.org > > > > > Subject: Re: [OE-core] [PATCH] glibc-locale: Rewrite do_install > > > using > > > > > install utility instead of cp > > > > > > > > > > On Wed, 2019-02-06 at 16:35 -0800, Khem Raj wrote: > > > > > > This has been a constant source of trouble for build failures due > > > > to > > > > > host-user-contaminated QA > > > > > > errors of sort > > > > > > > > > > > > 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] > > > > > > > > > > > > So far we have tried to mould cp command into not carrying the > > > > build > > > > > > user permissions into install area but it is never entirely fixed > > > > > since > > > > > > the issue keeps popping up in various scenes > > > > > > > > > > > > This patch replaces use of cp with install utility and specifies > > > > > install > > > > > > mode for files explcitly > > > > > > > > > > > > Signed-off-by: Khem Raj <raj.khem@gmail.com> > > > > > > --- > > > > > > meta/recipes-core/glibc/glibc-locale.inc | 44 ++++++++++++++---- > > > -- > > > > -- > > > > > -- > > > > > > 1 file changed, 25 insertions(+), 19 deletions(-) > > > > > > > > > > > > diff --git a/meta/recipes-core/glibc/glibc-locale.inc > > > > b/meta/recipes- > > > > > core/glibc/glibc-locale.inc > > > > > > index 6384f9cbf1..9b256a5108 100644 > > > > > > --- a/meta/recipes-core/glibc/glibc-locale.inc > > > > > > +++ b/meta/recipes-core/glibc/glibc-locale.inc > > > > > > @@ -72,27 +72,33 @@ FILES_localedef = "${bindir}/localedef" > > > > > > LOCALETREESRC = "${COMPONENTS_DIR}/${PACKAGE_ARCH}/glibc-stash- > > > > > locale" > > > > > > > > > > > > do_install () { > > > > > > - mkdir -p ${D}${bindir} ${D}${datadir} > > > > > > - if [ -n "$(ls ${LOCALETREESRC}/${bindir})" ]; then > > > > > > - cp -R --no-dereference --preserve=mode,links > > > > > ${LOCALETREESRC}/${bindir}/* ${D}${bindir} > > > > > > - fi > > > > > > - if [ -n "$(ls ${LOCALETREESRC}/${localedir})" ]; then > > > > > > - mkdir -p ${D}${localedir} > > > > > > - cp -R --no-dereference --preserve=mode,links > > > > > ${LOCALETREESRC}/${localedir}/* ${D}${localedir} > > > > > > - fi > > > > > > + install -d ${D}${bindir} > > > > > > + find "${LOCALETREESRC}/${bindir}" -maxdepth 1 -type f \ > > > > > > + -exec install -m 0755 -t "${D}${bindir}" {} \; > > > > > > + > > > > > > + for d in . $(find "${LOCALETREESRC}/${localedir}" -type > > > d > > > > - > > > > > printf '%P ') ; do > > > > > > + install -d "${D}${localedir}/$d" > > > > > > + find "${LOCALETREESRC}/${localedir}/$d" - > > > maxdepth > > > > 1 > > > > > -type f \ > > > > > > + -exec install -m 0644 -t "${D}${localedir}/$d" > > > {} > > > > \; > > > > > > + done > > > > > > if [ ${@d.getVar('PACKAGE_NO_GCONV')} -eq 0 ]; then > > > > > > - mkdir -p ${D}${libdir} > > > > > > - if [ -e ${LOCALETREESRC}/${libdir}/gconv ]; then > > > > > > - cp -R --no-dereference -- > > > > > preserve=mode,links ${LOCALETREESRC}/${libdir}/gconv ${D}${libdir} > > > > > > - fi > > > > > > - if [ -e ${LOCALETREESRC}/${datadir}/i18n ]; then > > > > > > - cp -R --no-dereference -- > > > > > preserve=mode,links ${LOCALETREESRC}/${datadir}/i18n ${D}${datadir} > > > > > > - fi > > > > > > - fi > > > > > > - if [ -e ${LOCALETREESRC}/${datadir}/locale ]; then > > > > > > - cp -R --no-dereference --preserve=mode,links > > > > > ${LOCALETREESRC}/${datadir}/locale ${D}${datadir} > > > > > > + for d in . $(find > > > > "${LOCALETREESRC}/${libdir}/gconv" > > > > > -type d -printf '%P ') ; do > > > > > > + install -d "${D}${libdir}/gconv/$d" > > > > > > + find > > > "${LOCALETREESRC}/${libdir}/gconv/$d" > > > > - > > > > > maxdepth 1 -type f \ > > > > > > + -exec install -m 0755 -t > > > > > "${D}${libdir}/gconv/$d" {} \; > > > > > > + done > > > > > > + for d in . $(find > > > > "${LOCALETREESRC}/${datadir}/i18n" > > > > > -type d -printf '%P ') ; do > > > > > > + install -d "${D}${datadir}/i18n/$d" > > > > > > + find > > > "${LOCALETREESRC}/${datadir}/i18n/$d" > > > > - > > > > > maxdepth 1 -type f \ > > > > > > + -exec install -m 0644 -t > > > > > "${D}${datadir}/i18n/$d" {} \; > > > > > > + done > > > > > > fi > > > > > > - cp -R --no-dereference --preserve=mode,links > > > > > ${LOCALETREESRC}/SUPPORTED ${WORKDIR} > > > > > > + for d in . $(find "${LOCALETREESRC}/${datadir}/locale" - > > > > type > > > > > d -printf '%P ') ; do > > > > > > + install -d "${D}${datadir}/locale/$d" > > > > > > + find "${LOCALETREESRC}/${datadir}/locale/$d" - > > > > > maxdepth 1 -type f \ > > > > > > + -exec install -m 0644 -t > > > > "${D}${datadir}/locale/$d" > > > > > {} \; > > > > > > + done > > > > > > + install -m 0644 ${LOCALETREESRC}/SUPPORTED > > > > > ${WORKDIR}/SUPPORTED > > > > > > } > > > > > > > > > > > > inherit libc-package > > > > > > > > > > The trouble is this is a workaround. The cp commands should work > > > and > > > > > there is some underlying issue in pseudo causing this. We really > > > need > > > > > to figure out what that is since this will likely just mean we see > > > > the > > > > > problem somewhere else :( > > > > > > > > > > I still suspect some kind of inode number reuse problem which these > > > > cp > > > > > commands trigger... > > > > > > > > > > Cheers, > > > > > > > > > > Richard > > > > > > > > For the record, even if I think the patch was the right thing to do, > > > > it did not help the situation. The first build I did after it was > > > > integrated, I was bit by the following: > > > > > > > > Failed to determine the user name of UID 323 for > > > > tmp/work/core2-64-poky-linux/glibc-locale/2.29- > > > r0/package/usr/lib/locale > > > > > > > > where UID 323 is my UID. If you do not recognize the error message, > > > > it is because it comes from a local patch we have for rpm to protect > > > > us from any incorrect UIDs/GIDs causing incorrect RPMs to be > > > generated > > > > (see below). I checked the build directory and the /usr/lib/locale > > > > directory was the only file or directory with an incorrect owner, > > > > which is typical of these pseudo related problems with incorrect > > > > owners. > > > > > > > > [rpm will by default silently fall back to use root for any files > > > > where it cannot determine the name of the user or group based on > > > > its UID/GID. This can be due to missing information in the > > > > /etc/passwd or /etc/groups files, typically due to relying on > > > > another recipe in DEPENDS to create the user without also having > > > > an RDEPENDS on the package that creates the user, or because of > > > > pseudo messing up. After this bit us once where a device in /dev > > > > ended up in an rpm in the sstate cache with root as group instead > > > > of the intended video group, which in turn caused the video > > > > application to fail as it was no longer allowed to open its device, > > > > I created the patch. It is causing a fair bit of grief as it causes > > > > builds to fail randomly, but at least we don't end up with an > > > > incorrect sstate anymore, which is worse. I am not sure this patch > > > > is suitable for integration to OE-Core, but I have attached it if > > > > anyone is interested.] > > > > > > > > //Peter > > > > > > Ok, this just got a lot more weird. At the time I wrote the mail > > > above, I had only tried to rebuild once. Now I have done it a number > > > of more times, and the result is not random any more. Every build > > > fails the same way. I've done `bitbake glibc-locale -c cleansstate` > > > followed by `bitbake glibc-locale` and the result is consistent. > > > What I have noted now, is that it is _not_ do_install that causes > > > the problem. The /usr/lib/locale directory created in ${D} has > > > the correct owner. It is when the data is copied to ${PKGD} that > > > it somehow ends up with the wrong owner. I cannot tell from a quick > > > glance what differs /usr/lib/locale from, e.g., /usr/lib/gconv, > > > where the latter does get the correct owner. > > > > > > Unfortunately, I do not have more time to look at this right now, > > > but I thought I should share this information with you. If anyone > > > has any ideas of what to look at to determine why > > > ${PKGD}/usr/lib/locale ends up with the wrong owner, I'm all ears. > > > It would also be interesting to hear if the result is the same for > > > anyone else with the patch I provided in my previous mail applied. > > > > > > //Peter > > > > Further investigation indicates that the problem I'm seeing is not > > related to pseudo, but an actual problem in the code. I have not dug > > too far into it, but I'm seeing the problem in the directories used > > in do_prep_locale_tree() and do_collect_bins_from_locale_tree() in > > libc-package.bbclass where some of them seems to have been created > > without being run under pseudo. The following patch works around the > > problem, though it would probably be better to correct the problem > > at the source by running whatever part of the code under pseudo that > > is currently missing it: > > > > diff --git a/meta/classes/libc-package.bbclass b/meta/classes/libc-package.bbclass > > index 0b4c666a74..174465a891 100644 > > --- a/meta/classes/libc-package.bbclass > > +++ b/meta/classes/libc-package.bbclass > > @@ -72,6 +72,7 @@ do_prep_locale_tree() { > > tar -cf - -C ${STAGING_DIR_NATIVE}/${prefix_native}/${base_libdir} -p libgcc_s.* | tar -xf - -C $treedir/${base_libdir} > > fi > > install -m 0755 ${LOCALETREESRC}${bindir}/localedef $treedir/${base_bindir} > > + chown -R root:root $treedir > > } > > > > do_collect_bins_from_locale_tree() { > > > > > Can you try something on the lines > > diff --git a/meta/classes/libc-package.bbclass > b/meta/classes/libc-package.bbclass > index 0b4c666a74..34025635ce 100644 > --- a/meta/classes/libc-package.bbclass > +++ b/meta/classes/libc-package.bbclass > @@ -61,7 +61,7 @@ LOCALETREESRC ?= "${PKGD}" > do_prep_locale_tree() { > treedir=${WORKDIR}/locale-tree > rm -rf $treedir > - mkdir -p $treedir/${base_bindir} $treedir/${base_libdir} > $treedir/${datadir} $treedir/${localedir} > + install -d $treedir/${base_bindir} $treedir/${base_libdir} > $treedir/${datadir} $treedir/${localedir} > tar -cf - -C ${LOCALETREESRC}${datadir} -p i18n | tar -xf - -C > $treedir/${datadir} > # unzip to avoid parsing errors > for i in $treedir/${datadir}/i18n/charmaps/*gz; do > > > > > //Peter -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Just to provide some feedback. Even with this patch, this annoying QA issue is still there. WARNING: glibc-locale-2.29-r0 do_package_qa: QA Issue: glibc-locale: /glibc-binary-localedata-wo-sn/usr/lib/locale/wo_SN/LC_CTYPE is owned by uid 1001, which is the same as the user running bitbake. This may be due to host contamination [host-user-contaminated] Best Regards, Chen Qi On 02/07/2019 08:35 AM, Khem Raj wrote: > This has been a constant source of trouble for build failures due to host-user-contaminated QA > errors of sort > > 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] > > So far we have tried to mould cp command into not carrying the build > user permissions into install area but it is never entirely fixed since > the issue keeps popping up in various scenes > > This patch replaces use of cp with install utility and specifies install > mode for files explcitly > > Signed-off-by: Khem Raj <raj.khem@gmail.com> > --- > meta/recipes-core/glibc/glibc-locale.inc | 44 ++++++++++++++---------- > 1 file changed, 25 insertions(+), 19 deletions(-) > > diff --git a/meta/recipes-core/glibc/glibc-locale.inc b/meta/recipes-core/glibc/glibc-locale.inc > index 6384f9cbf1..9b256a5108 100644 > --- a/meta/recipes-core/glibc/glibc-locale.inc > +++ b/meta/recipes-core/glibc/glibc-locale.inc > @@ -72,27 +72,33 @@ FILES_localedef = "${bindir}/localedef" > LOCALETREESRC = "${COMPONENTS_DIR}/${PACKAGE_ARCH}/glibc-stash-locale" > > do_install () { > - mkdir -p ${D}${bindir} ${D}${datadir} > - if [ -n "$(ls ${LOCALETREESRC}/${bindir})" ]; then > - cp -R --no-dereference --preserve=mode,links ${LOCALETREESRC}/${bindir}/* ${D}${bindir} > - fi > - if [ -n "$(ls ${LOCALETREESRC}/${localedir})" ]; then > - mkdir -p ${D}${localedir} > - cp -R --no-dereference --preserve=mode,links ${LOCALETREESRC}/${localedir}/* ${D}${localedir} > - fi > + install -d ${D}${bindir} > + find "${LOCALETREESRC}/${bindir}" -maxdepth 1 -type f \ > + -exec install -m 0755 -t "${D}${bindir}" {} \; > + > + for d in . $(find "${LOCALETREESRC}/${localedir}" -type d -printf '%P ') ; do > + install -d "${D}${localedir}/$d" > + find "${LOCALETREESRC}/${localedir}/$d" -maxdepth 1 -type f \ > + -exec install -m 0644 -t "${D}${localedir}/$d" {} \; > + done > if [ ${@d.getVar('PACKAGE_NO_GCONV')} -eq 0 ]; then > - mkdir -p ${D}${libdir} > - if [ -e ${LOCALETREESRC}/${libdir}/gconv ]; then > - cp -R --no-dereference --preserve=mode,links ${LOCALETREESRC}/${libdir}/gconv ${D}${libdir} > - fi > - if [ -e ${LOCALETREESRC}/${datadir}/i18n ]; then > - cp -R --no-dereference --preserve=mode,links ${LOCALETREESRC}/${datadir}/i18n ${D}${datadir} > - fi > - fi > - if [ -e ${LOCALETREESRC}/${datadir}/locale ]; then > - cp -R --no-dereference --preserve=mode,links ${LOCALETREESRC}/${datadir}/locale ${D}${datadir} > + for d in . $(find "${LOCALETREESRC}/${libdir}/gconv" -type d -printf '%P ') ; do > + install -d "${D}${libdir}/gconv/$d" > + find "${LOCALETREESRC}/${libdir}/gconv/$d" -maxdepth 1 -type f \ > + -exec install -m 0755 -t "${D}${libdir}/gconv/$d" {} \; > + done > + for d in . $(find "${LOCALETREESRC}/${datadir}/i18n" -type d -printf '%P ') ; do > + install -d "${D}${datadir}/i18n/$d" > + find "${LOCALETREESRC}/${datadir}/i18n/$d" -maxdepth 1 -type f \ > + -exec install -m 0644 -t "${D}${datadir}/i18n/$d" {} \; > + done > fi > - cp -R --no-dereference --preserve=mode,links ${LOCALETREESRC}/SUPPORTED ${WORKDIR} > + for d in . $(find "${LOCALETREESRC}/${datadir}/locale" -type d -printf '%P ') ; do > + install -d "${D}${datadir}/locale/$d" > + find "${LOCALETREESRC}/${datadir}/locale/$d" -maxdepth 1 -type f \ > + -exec install -m 0644 -t "${D}${datadir}/locale/$d" {} \; > + done > + install -m 0644 ${LOCALETREESRC}/SUPPORTED ${WORKDIR}/SUPPORTED > } > > inherit libc-package -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
On Thu, 2019-02-28 at 09:53 +0800, ChenQi wrote: > Just to provide some feedback. > Even with this patch, this annoying QA issue is still there. > WARNING: glibc-locale-2.29-r0 do_package_qa: QA Issue: glibc-locale: > /glibc-binary-localedata-wo-sn/usr/lib/locale/wo_SN/LC_CTYPE is owned > by > uid 1001, which is the same as the user running bitbake. This may be > due > to host contamination [host-user-contaminated] Just seen on our autobuilder too: WARNING: glibc-locale-2.29-r0 do_package_qa: QA Issue: glibc-locale: /glibc-binary-localedata-gez-et+abegede/usr/lib/locale/gez_ET@abegede/LC_MESSAGES/SYS_LC_MESSAGES is owned by uid 6000, which is the same as the user running bitbake. This may be due to host contamination [host-user-contaminated] (https://autobuilder.yoctoproject.org/typhoon/#/builders/70/builds/346) Cheers, Richard -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
diff --git a/meta/recipes-core/glibc/glibc-locale.inc b/meta/recipes-core/glibc/glibc-locale.inc index 6384f9cbf1..9b256a5108 100644 --- a/meta/recipes-core/glibc/glibc-locale.inc +++ b/meta/recipes-core/glibc/glibc-locale.inc @@ -72,27 +72,33 @@ FILES_localedef = "${bindir}/localedef" LOCALETREESRC = "${COMPONENTS_DIR}/${PACKAGE_ARCH}/glibc-stash-locale" do_install () { - mkdir -p ${D}${bindir} ${D}${datadir} - if [ -n "$(ls ${LOCALETREESRC}/${bindir})" ]; then - cp -R --no-dereference --preserve=mode,links ${LOCALETREESRC}/${bindir}/* ${D}${bindir} - fi - if [ -n "$(ls ${LOCALETREESRC}/${localedir})" ]; then - mkdir -p ${D}${localedir} - cp -R --no-dereference --preserve=mode,links ${LOCALETREESRC}/${localedir}/* ${D}${localedir} - fi + install -d ${D}${bindir} + find "${LOCALETREESRC}/${bindir}" -maxdepth 1 -type f \ + -exec install -m 0755 -t "${D}${bindir}" {} \; + + for d in . $(find "${LOCALETREESRC}/${localedir}" -type d -printf '%P ') ; do + install -d "${D}${localedir}/$d" + find "${LOCALETREESRC}/${localedir}/$d" -maxdepth 1 -type f \ + -exec install -m 0644 -t "${D}${localedir}/$d" {} \; + done if [ ${@d.getVar('PACKAGE_NO_GCONV')} -eq 0 ]; then - mkdir -p ${D}${libdir} - if [ -e ${LOCALETREESRC}/${libdir}/gconv ]; then - cp -R --no-dereference --preserve=mode,links ${LOCALETREESRC}/${libdir}/gconv ${D}${libdir} - fi - if [ -e ${LOCALETREESRC}/${datadir}/i18n ]; then - cp -R --no-dereference --preserve=mode,links ${LOCALETREESRC}/${datadir}/i18n ${D}${datadir} - fi - fi - if [ -e ${LOCALETREESRC}/${datadir}/locale ]; then - cp -R --no-dereference --preserve=mode,links ${LOCALETREESRC}/${datadir}/locale ${D}${datadir} + for d in . $(find "${LOCALETREESRC}/${libdir}/gconv" -type d -printf '%P ') ; do + install -d "${D}${libdir}/gconv/$d" + find "${LOCALETREESRC}/${libdir}/gconv/$d" -maxdepth 1 -type f \ + -exec install -m 0755 -t "${D}${libdir}/gconv/$d" {} \; + done + for d in . $(find "${LOCALETREESRC}/${datadir}/i18n" -type d -printf '%P ') ; do + install -d "${D}${datadir}/i18n/$d" + find "${LOCALETREESRC}/${datadir}/i18n/$d" -maxdepth 1 -type f \ + -exec install -m 0644 -t "${D}${datadir}/i18n/$d" {} \; + done fi - cp -R --no-dereference --preserve=mode,links ${LOCALETREESRC}/SUPPORTED ${WORKDIR} + for d in . $(find "${LOCALETREESRC}/${datadir}/locale" -type d -printf '%P ') ; do + install -d "${D}${datadir}/locale/$d" + find "${LOCALETREESRC}/${datadir}/locale/$d" -maxdepth 1 -type f \ + -exec install -m 0644 -t "${D}${datadir}/locale/$d" {} \; + done + install -m 0644 ${LOCALETREESRC}/SUPPORTED ${WORKDIR}/SUPPORTED } inherit libc-package
This has been a constant source of trouble for build failures due to host-user-contaminated QA errors of sort 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] So far we have tried to mould cp command into not carrying the build user permissions into install area but it is never entirely fixed since the issue keeps popping up in various scenes This patch replaces use of cp with install utility and specifies install mode for files explcitly Signed-off-by: Khem Raj <raj.khem@gmail.com> --- meta/recipes-core/glibc/glibc-locale.inc | 44 ++++++++++++++---------- 1 file changed, 25 insertions(+), 19 deletions(-) -- 2.20.1 -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core