* new meta-oe failures from master-next @ 2019-10-23 13:03 Khem Raj 2019-10-23 13:05 ` Khem Raj ` (2 more replies) 0 siblings, 3 replies; 18+ messages in thread From: Khem Raj @ 2019-10-23 13:03 UTC (permalink / raw) To: Patches and discussions about the oe-core layer, Richard Purdie Hi Richard New master-next I see these fails https://errors.yoctoproject.org/Errors/Build/91645/ First two are important one's we already know why ti-display-sharing-fw fails to fetch ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: new meta-oe failures from master-next 2019-10-23 13:03 new meta-oe failures from master-next Khem Raj @ 2019-10-23 13:05 ` Khem Raj 2019-10-23 15:58 ` akuster808 2019-10-23 15:29 ` Ross Burton 2019-10-23 16:22 ` richard.purdie 2 siblings, 1 reply; 18+ messages in thread From: Khem Raj @ 2019-10-23 13:05 UTC (permalink / raw) To: Patches and discussions about the oe-core layer, Richard Purdie here is AB failure link https://autobuilder.yoctoproject.org/typhoon/#/builders/88/builds/56 On Wed, Oct 23, 2019 at 2:03 PM Khem Raj <raj.khem@gmail.com> wrote: > > Hi Richard > > New master-next I see these fails > > https://errors.yoctoproject.org/Errors/Build/91645/ > > First two are important one's we already know why > ti-display-sharing-fw fails to fetch ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: new meta-oe failures from master-next 2019-10-23 13:05 ` Khem Raj @ 2019-10-23 15:58 ` akuster808 0 siblings, 0 replies; 18+ messages in thread From: akuster808 @ 2019-10-23 15:58 UTC (permalink / raw) To: Khem Raj, Patches and discussions about the oe-core layer, Richard Purdie On 10/23/19 6:05 AM, Khem Raj wrote: > here is AB failure link > > https://autobuilder.yoctoproject.org/typhoon/#/builders/88/builds/56 Your builds are also archived on wiki https://wiki.yoctoproject.org/wiki/BuildLog > > On Wed, Oct 23, 2019 at 2:03 PM Khem Raj <raj.khem@gmail.com> wrote: >> Hi Richard >> >> New master-next I see these fails >> >> https://errors.yoctoproject.org/Errors/Build/91645/ >> >> First two are important one's we already know why >> ti-display-sharing-fw fails to fetch ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: new meta-oe failures from master-next 2019-10-23 13:03 new meta-oe failures from master-next Khem Raj 2019-10-23 13:05 ` Khem Raj @ 2019-10-23 15:29 ` Ross Burton 2019-10-23 19:23 ` Adrian Bunk 2019-10-23 19:31 ` Richard Purdie 2019-10-23 16:22 ` richard.purdie 2 siblings, 2 replies; 18+ messages in thread From: Ross Burton @ 2019-10-23 15:29 UTC (permalink / raw) To: openembedded-core On 23/10/2019 14:03, Khem Raj wrote: > Hi Richard > > New master-next I see these fails > > https://errors.yoctoproject.org/Errors/Build/91645/ > > First two are important one's we already know why > ti-display-sharing-fw fails to fetch ERROR: QA Issue: libiio: Files/directories were installed but not shipped in any package: /usr/lib/python2.7 /usr/lib/python2.7/site-packages /usr/lib/python2.7/site-packages/libiio-0.18-py2.7.egg-info /usr/lib/python2.7/site-packages/iio.pyc /usr/lib/python2.7/site-packages/iio.py That may have been triggered by some change in oe-core but that's definitely an issue with libiio. WARNING: TOPDIR/build/tmp/work/mips32r2-yoe-linux/python3-astor/0.7.1-r0/temp/run.do_configure.7679:1 exit 1 from 'NO_FETCH_BUILD=1 TOPDIR/build/tmp/work/mips32r2-yoe-linux/python3-astor/0.7.1-r0/recipe-sysroot-native/usr/bin/python3-native/python3 setup.py clean' ERROR: Execution of 'TOPDIR/build/tmp/work/mips32r2-yoe-linux/python3-astor/0.7.1-r0/temp/run.do_configure.7679' failed with exit code 1: Traceback (most recent call last): File "setup.py", line 17, in <module> setup(**config['options']) File "TOPDIR/build/tmp/work/mips32r2-yoe-linux/python3-astor/0.7.1-r0/recipe-sysroot-native/usr/lib/python3.7/site-packages/setuptools/__init__.py", line 145, in setup return distutils.core.setup(**attrs) Looks like whatever astor is doing with setuptools doesn't agree with the upgrade to 41.4.0? Ross ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: new meta-oe failures from master-next 2019-10-23 15:29 ` Ross Burton @ 2019-10-23 19:23 ` Adrian Bunk 2019-10-23 21:20 ` Richard Purdie 2019-10-23 19:31 ` Richard Purdie 1 sibling, 1 reply; 18+ messages in thread From: Adrian Bunk @ 2019-10-23 19:23 UTC (permalink / raw) To: Ross Burton; +Cc: openembedded-core On Wed, Oct 23, 2019 at 04:29:13PM +0100, Ross Burton wrote: > On 23/10/2019 14:03, Khem Raj wrote: > > Hi Richard > > > > New master-next I see these fails > > > > https://errors.yoctoproject.org/Errors/Build/91645/ > > > > First two are important one's we already know why > > ti-display-sharing-fw fails to fetch > > ERROR: QA Issue: libiio: Files/directories were installed but not shipped in > any package: > /usr/lib/python2.7 > /usr/lib/python2.7/site-packages > /usr/lib/python2.7/site-packages/libiio-0.18-py2.7.egg-info > /usr/lib/python2.7/site-packages/iio.pyc > /usr/lib/python2.7/site-packages/iio.py > > That may have been triggered by some change in oe-core but that's definitely > an issue with libiio. I'd agree on that: Python bindings were converted from python2 to python3 last week, and it picks up the host python 2.7. -inherit cmake pythonnative systemd +inherit cmake python3native systemd This does not in any way guarantee that there is no python2 interpreter available. > WARNING: TOPDIR/build/tmp/work/mips32r2-yoe-linux/python3-astor/0.7.1-r0/temp/run.do_configure.7679:1 > exit 1 from 'NO_FETCH_BUILD=1 TOPDIR/build/tmp/work/mips32r2-yoe-linux/python3-astor/0.7.1-r0/recipe-sysroot-native/usr/bin/python3-native/python3 > setup.py clean' > ERROR: Execution of 'TOPDIR/build/tmp/work/mips32r2-yoe-linux/python3-astor/0.7.1-r0/temp/run.do_configure.7679' > failed with exit code 1: > Traceback (most recent call last): > File "setup.py", line 17, in <module> > setup(**config['options']) > File "TOPDIR/build/tmp/work/mips32r2-yoe-linux/python3-astor/0.7.1-r0/recipe-sysroot-native/usr/lib/python3.7/site-packages/setuptools/__init__.py", > line 145, in setup > return distutils.core.setup(**attrs) > > Looks like whatever astor is doing with setuptools doesn't agree with the > upgrade to 41.4.0? The recipe is behind upstream, but even the latest version needs fixing: https://github.com/berkerpeksag/astor/issues/162 Temporarily broken leaf package, not really important. > Ross cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: new meta-oe failures from master-next 2019-10-23 19:23 ` Adrian Bunk @ 2019-10-23 21:20 ` Richard Purdie 2019-10-23 22:08 ` Adrian Bunk 0 siblings, 1 reply; 18+ messages in thread From: Richard Purdie @ 2019-10-23 21:20 UTC (permalink / raw) To: Adrian Bunk, Ross Burton; +Cc: openembedded-core On Wed, 2019-10-23 at 22:23 +0300, Adrian Bunk wrote: > On Wed, Oct 23, 2019 at 04:29:13PM +0100, Ross Burton wrote: > > On 23/10/2019 14:03, Khem Raj wrote: > > > Hi Richard > > > > > > New master-next I see these fails > > > > > > https://errors.yoctoproject.org/Errors/Build/91645/ > > > > > > First two are important one's we already know why > > > ti-display-sharing-fw fails to fetch > > > > ERROR: QA Issue: libiio: Files/directories were installed but not > > shipped in > > any package: > > /usr/lib/python2.7 > > /usr/lib/python2.7/site-packages > > /usr/lib/python2.7/site-packages/libiio-0.18-py2.7.egg-info > > /usr/lib/python2.7/site-packages/iio.pyc > > /usr/lib/python2.7/site-packages/iio.py > > > > That may have been triggered by some change in oe-core but that's > > definitely > > an issue with libiio. > > I'd agree on that: > > Python bindings were converted from python2 to python3 last week, > and it picks up the host python 2.7. > > -inherit cmake pythonnative systemd > +inherit cmake python3native systemd > > This does not in any way guarantee that there is no python2 > interpreter > available. > > > WARNING: TOPDIR/build/tmp/work/mips32r2-yoe-linux/python3- > > astor/0.7.1-r0/temp/run.do_configure.7679:1 > > exit 1 from 'NO_FETCH_BUILD=1 TOPDIR/build/tmp/work/mips32r2-yoe- > > linux/python3-astor/0.7.1-r0/recipe-sysroot-native/usr/bin/python3- > > native/python3 > > setup.py clean' > > ERROR: Execution of 'TOPDIR/build/tmp/work/mips32r2-yoe- > > linux/python3-astor/0.7.1-r0/temp/run.do_configure.7679' > > failed with exit code 1: > > Traceback (most recent call last): > > File "setup.py", line 17, in <module> > > setup(**config['options']) > > File "TOPDIR/build/tmp/work/mips32r2-yoe-linux/python3- > > astor/0.7.1-r0/recipe-sysroot-native/usr/lib/python3.7/site- > > packages/setuptools/__init__.py", > > line 145, in setup > > return distutils.core.setup(**attrs) > > > > Looks like whatever astor is doing with setuptools doesn't agree > > with the > > upgrade to 41.4.0? > > The recipe is behind upstream, but even the latest version needs > fixing: > https://github.com/berkerpeksag/astor/issues/162 > > Temporarily broken leaf package, not really important. Well, yes. The proposed policy is now that we should address these kinds of issues if they get reported. Whilst I understand why and that Khem doesn't get as much help as he needs with meta-oe, pushing the oe- core maintainers to fix things likely won't scale. I would like to see meta-oe quality/reliability improve though so I do understand the desire. Since I'd had to look into them, I've posted patches to oe-devel for the above two issues. Cheers, Richard ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: new meta-oe failures from master-next 2019-10-23 21:20 ` Richard Purdie @ 2019-10-23 22:08 ` Adrian Bunk 0 siblings, 0 replies; 18+ messages in thread From: Adrian Bunk @ 2019-10-23 22:08 UTC (permalink / raw) To: Richard Purdie; +Cc: openembedded-core On Wed, Oct 23, 2019 at 10:20:29PM +0100, Richard Purdie wrote: > > Well, yes. The proposed policy is now that we should address these > kinds of issues if they get reported. Whilst I understand why and that > Khem doesn't get as much help as he needs with meta-oe, pushing the oe- > core maintainers to fix things likely won't scale. I would like to see > meta-oe quality/reliability improve though so I do understand the > desire. >... What is the proposed process for oe-core changes that are likely to break reverse dependencies in meta-oe? Python 3.8 would be a good example for that - for astor your upgrade to the latest upstream version already contains Python 3.8 fixes, but other recipes in meta-oe might require fixing by someone. > Cheers, > > Richard cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: new meta-oe failures from master-next 2019-10-23 15:29 ` Ross Burton 2019-10-23 19:23 ` Adrian Bunk @ 2019-10-23 19:31 ` Richard Purdie 2019-10-23 22:52 ` Khem Raj 1 sibling, 1 reply; 18+ messages in thread From: Richard Purdie @ 2019-10-23 19:31 UTC (permalink / raw) To: Ross Burton, openembedded-core On Wed, 2019-10-23 at 16:29 +0100, Ross Burton wrote: > On 23/10/2019 14:03, Khem Raj wrote: > > Hi Richard > > > > New master-next I see these fails > > > > https://errors.yoctoproject.org/Errors/Build/91645/ > > > > First two are important one's we already know why > > ti-display-sharing-fw fails to fetch > > ERROR: QA Issue: libiio: Files/directories were installed but not > shipped in any package: > /usr/lib/python2.7 > /usr/lib/python2.7/site-packages > /usr/lib/python2.7/site-packages/libiio-0.18-py2.7.egg-info > /usr/lib/python2.7/site-packages/iio.pyc > /usr/lib/python2.7/site-packages/iio.py > > That may have been triggered by some change in oe-core but that's > definitely an issue with libiio. Its from this cmake change: http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=dbba06d9153ae588c9496b40e5db18b3602bfad1 > > WARNING: > TOPDIR/build/tmp/work/mips32r2-yoe-linux/python3-astor/0.7.1- > r0/temp/run.do_configure.7679:1 > exit 1 from 'NO_FETCH_BUILD=1 > TOPDIR/build/tmp/work/mips32r2-yoe-linux/python3-astor/0.7.1- > r0/recipe-sysroot-native/usr/bin/python3-native/python3 > setup.py clean' > ERROR: Execution of > 'TOPDIR/build/tmp/work/mips32r2-yoe-linux/python3-astor/0.7.1- > r0/temp/run.do_configure.7679' > failed with exit code 1: > Traceback (most recent call last): > File "setup.py", line 17, in <module> > setup(**config['options']) > File > "TOPDIR/build/tmp/work/mips32r2-yoe-linux/python3-astor/0.7.1- > r0/recipe-sysroot-native/usr/lib/python3.7/site- > packages/setuptools/__init__.py", > line 145, in setup > return distutils.core.setup(**attrs) > > Looks like whatever astor is doing with setuptools doesn't agree > with the upgrade to 41.4.0? Yes, I can confirm that reverting http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=b9703df2853e72b974a63ef1146f09a6c197990d locally does make it build again. Cheers, Richard ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: new meta-oe failures from master-next 2019-10-23 19:31 ` Richard Purdie @ 2019-10-23 22:52 ` Khem Raj 2019-10-24 6:37 ` Khem Raj 2019-10-24 8:15 ` richard.purdie 0 siblings, 2 replies; 18+ messages in thread From: Khem Raj @ 2019-10-23 22:52 UTC (permalink / raw) To: Richard Purdie; +Cc: Patches and discussions about the oe-core layer On Wed, Oct 23, 2019 at 8:31 PM Richard Purdie <richard.purdie@linuxfoundation.org> wrote: > > On Wed, 2019-10-23 at 16:29 +0100, Ross Burton wrote: > > On 23/10/2019 14:03, Khem Raj wrote: > > > Hi Richard > > > > > > New master-next I see these fails > > > > > > https://errors.yoctoproject.org/Errors/Build/91645/ > > > > > > First two are important one's we already know why > > > ti-display-sharing-fw fails to fetch > > > > ERROR: QA Issue: libiio: Files/directories were installed but not > > shipped in any package: > > /usr/lib/python2.7 > > /usr/lib/python2.7/site-packages > > /usr/lib/python2.7/site-packages/libiio-0.18-py2.7.egg-info > > /usr/lib/python2.7/site-packages/iio.pyc > > /usr/lib/python2.7/site-packages/iio.py > > > > That may have been triggered by some change in oe-core but that's > > definitely an issue with libiio. > > Its from this cmake change: > > http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=dbba06d9153ae588c9496b40e5db18b3602bfad1 > I think its causing more failures, where suddenly, the recipes are now resorting to native python, is this patch correct I wonder ? see https://git.openembedded.org/meta-openembedded-contrib/commit/?h=yoe/mut&id=5d02e814bc7d30f925b2eeec85eb053cec516f26 https://git.openembedded.org/meta-openembedded-contrib/commit/?h=yoe/mut&id=3ab0af60e8512cbb718e8a0112d9c9aa98c620a4 > > > > > WARNING: > > TOPDIR/build/tmp/work/mips32r2-yoe-linux/python3-astor/0.7.1- > > r0/temp/run.do_configure.7679:1 > > exit 1 from 'NO_FETCH_BUILD=1 > > TOPDIR/build/tmp/work/mips32r2-yoe-linux/python3-astor/0.7.1- > > r0/recipe-sysroot-native/usr/bin/python3-native/python3 > > setup.py clean' > > ERROR: Execution of > > 'TOPDIR/build/tmp/work/mips32r2-yoe-linux/python3-astor/0.7.1- > > r0/temp/run.do_configure.7679' > > failed with exit code 1: > > Traceback (most recent call last): > > File "setup.py", line 17, in <module> > > setup(**config['options']) > > File > > "TOPDIR/build/tmp/work/mips32r2-yoe-linux/python3-astor/0.7.1- > > r0/recipe-sysroot-native/usr/lib/python3.7/site- > > packages/setuptools/__init__.py", > > line 145, in setup > > return distutils.core.setup(**attrs) > > > > Looks like whatever astor is doing with setuptools doesn't agree > > with the upgrade to 41.4.0? > > Yes, I can confirm that reverting > http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=b9703df2853e72b974a63ef1146f09a6c197990d > locally does make it build again. > > Cheers, > > Richard > > > > > > -- > _______________________________________________ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-core ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: new meta-oe failures from master-next 2019-10-23 22:52 ` Khem Raj @ 2019-10-24 6:37 ` Khem Raj 2019-10-24 8:15 ` richard.purdie 1 sibling, 0 replies; 18+ messages in thread From: Khem Raj @ 2019-10-24 6:37 UTC (permalink / raw) To: Richard Purdie; +Cc: Patches and discussions about the oe-core layer On Wed, Oct 23, 2019 at 11:52 PM Khem Raj <raj.khem@gmail.com> wrote: > > On Wed, Oct 23, 2019 at 8:31 PM Richard Purdie > <richard.purdie@linuxfoundation.org> wrote: > > > > On Wed, 2019-10-23 at 16:29 +0100, Ross Burton wrote: > > > On 23/10/2019 14:03, Khem Raj wrote: > > > > Hi Richard > > > > > > > > New master-next I see these fails > > > > > > > > https://errors.yoctoproject.org/Errors/Build/91645/ > > > > > > > > First two are important one's we already know why > > > > ti-display-sharing-fw fails to fetch > > > > > > ERROR: QA Issue: libiio: Files/directories were installed but not > > > shipped in any package: > > > /usr/lib/python2.7 > > > /usr/lib/python2.7/site-packages > > > /usr/lib/python2.7/site-packages/libiio-0.18-py2.7.egg-info > > > /usr/lib/python2.7/site-packages/iio.pyc > > > /usr/lib/python2.7/site-packages/iio.py > > > > > > That may have been triggered by some change in oe-core but that's > > > definitely an issue with libiio. > > > > Its from this cmake change: > > > > http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=dbba06d9153ae588c9496b40e5db18b3602bfad1 > > > > I think its causing more failures, where suddenly, the recipes are now > resorting to native python, is this patch correct I wonder ? > > see > https://git.openembedded.org/meta-openembedded-contrib/commit/?h=yoe/mut&id=5d02e814bc7d30f925b2eeec85eb053cec516f26 > > https://git.openembedded.org/meta-openembedded-contrib/commit/?h=yoe/mut&id=3ab0af60e8512cbb718e8a0112d9c9aa98c620a4 more fallouts https://errors.yoctoproject.org/Errors/Details/274418/ > > > > > > > > > WARNING: > > > TOPDIR/build/tmp/work/mips32r2-yoe-linux/python3-astor/0.7.1- > > > r0/temp/run.do_configure.7679:1 > > > exit 1 from 'NO_FETCH_BUILD=1 > > > TOPDIR/build/tmp/work/mips32r2-yoe-linux/python3-astor/0.7.1- > > > r0/recipe-sysroot-native/usr/bin/python3-native/python3 > > > setup.py clean' > > > ERROR: Execution of > > > 'TOPDIR/build/tmp/work/mips32r2-yoe-linux/python3-astor/0.7.1- > > > r0/temp/run.do_configure.7679' > > > failed with exit code 1: > > > Traceback (most recent call last): > > > File "setup.py", line 17, in <module> > > > setup(**config['options']) > > > File > > > "TOPDIR/build/tmp/work/mips32r2-yoe-linux/python3-astor/0.7.1- > > > r0/recipe-sysroot-native/usr/lib/python3.7/site- > > > packages/setuptools/__init__.py", > > > line 145, in setup > > > return distutils.core.setup(**attrs) > > > > > > Looks like whatever astor is doing with setuptools doesn't agree > > > with the upgrade to 41.4.0? > > > > Yes, I can confirm that reverting > > http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=b9703df2853e72b974a63ef1146f09a6c197990d > > locally does make it build again. > > > > Cheers, > > > > Richard > > > > > > > > > > > > -- > > _______________________________________________ > > Openembedded-core mailing list > > Openembedded-core@lists.openembedded.org > > http://lists.openembedded.org/mailman/listinfo/openembedded-core ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: new meta-oe failures from master-next 2019-10-23 22:52 ` Khem Raj 2019-10-24 6:37 ` Khem Raj @ 2019-10-24 8:15 ` richard.purdie 2019-10-24 8:20 ` Khem Raj 2019-10-24 9:34 ` Adrian Bunk 1 sibling, 2 replies; 18+ messages in thread From: richard.purdie @ 2019-10-24 8:15 UTC (permalink / raw) To: Khem Raj; +Cc: Patches and discussions about the oe-core layer On Wed, 2019-10-23 at 23:52 +0100, Khem Raj wrote: > On Wed, Oct 23, 2019 at 8:31 PM Richard Purdie > <richard.purdie@linuxfoundation.org> wrote: > > On Wed, 2019-10-23 at 16:29 +0100, Ross Burton wrote: > > > On 23/10/2019 14:03, Khem Raj wrote: > > > > Hi Richard > > > > > > > > New master-next I see these fails > > > > > > > > https://errors.yoctoproject.org/Errors/Build/91645/ > > > > > > > > First two are important one's we already know why > > > > ti-display-sharing-fw fails to fetch > > > > > > ERROR: QA Issue: libiio: Files/directories were installed but not > > > shipped in any package: > > > /usr/lib/python2.7 > > > /usr/lib/python2.7/site-packages > > > /usr/lib/python2.7/site-packages/libiio-0.18-py2.7.egg-info > > > /usr/lib/python2.7/site-packages/iio.pyc > > > /usr/lib/python2.7/site-packages/iio.py > > > > > > That may have been triggered by some change in oe-core but that's > > > definitely an issue with libiio. > > > > Its from this cmake change: > > > > http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=dbba06d9153ae588c9496b40e5db18b3602bfad1 > > > > I think its causing more failures, where suddenly, the recipes are > now > resorting to native python, is this patch correct I wonder ? > > see > https://git.openembedded.org/meta-openembedded-contrib/commit/?h=yoe/mut&id=5d02e814bc7d30f925b2eeec85eb053cec516f26 > > https://git.openembedded.org/meta-openembedded-contrib/commit/?h=yoe/mut&id=3ab0af60e8512cbb718e8a0112d9c9aa98c620a4 The cmake change makes python visible from HOSTTOOLS. That isn't wrong as such, it is a change in behaviour. If recipes don't set python enabled/disabled explicitly, there is some fallout from that. I'd say that is a bug in those recipes which aren't giving explicit configuration to dependencies though. Cheers, RIchard ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: new meta-oe failures from master-next 2019-10-24 8:15 ` richard.purdie @ 2019-10-24 8:20 ` Khem Raj 2019-10-24 8:25 ` richard.purdie 2019-10-24 9:34 ` Adrian Bunk 1 sibling, 1 reply; 18+ messages in thread From: Khem Raj @ 2019-10-24 8:20 UTC (permalink / raw) To: Richard Purdie; +Cc: Patches and discussions about the oe-core layer On Thu, Oct 24, 2019 at 9:15 AM <richard.purdie@linuxfoundation.org> wrote: > > On Wed, 2019-10-23 at 23:52 +0100, Khem Raj wrote: > > On Wed, Oct 23, 2019 at 8:31 PM Richard Purdie > > <richard.purdie@linuxfoundation.org> wrote: > > > On Wed, 2019-10-23 at 16:29 +0100, Ross Burton wrote: > > > > On 23/10/2019 14:03, Khem Raj wrote: > > > > > Hi Richard > > > > > > > > > > New master-next I see these fails > > > > > > > > > > https://errors.yoctoproject.org/Errors/Build/91645/ > > > > > > > > > > First two are important one's we already know why > > > > > ti-display-sharing-fw fails to fetch > > > > > > > > ERROR: QA Issue: libiio: Files/directories were installed but not > > > > shipped in any package: > > > > /usr/lib/python2.7 > > > > /usr/lib/python2.7/site-packages > > > > /usr/lib/python2.7/site-packages/libiio-0.18-py2.7.egg-info > > > > /usr/lib/python2.7/site-packages/iio.pyc > > > > /usr/lib/python2.7/site-packages/iio.py > > > > > > > > That may have been triggered by some change in oe-core but that's > > > > definitely an issue with libiio. > > > > > > Its from this cmake change: > > > > > > http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=dbba06d9153ae588c9496b40e5db18b3602bfad1 > > > > > > > I think its causing more failures, where suddenly, the recipes are > > now > > resorting to native python, is this patch correct I wonder ? > > > > see > > https://git.openembedded.org/meta-openembedded-contrib/commit/?h=yoe/mut&id=5d02e814bc7d30f925b2eeec85eb053cec516f26 > > > > https://git.openembedded.org/meta-openembedded-contrib/commit/?h=yoe/mut&id=3ab0af60e8512cbb718e8a0112d9c9aa98c620a4 > > The cmake change makes python visible from HOSTTOOLS. That isn't wrong > as such, it is a change in behaviour. If recipes don't set python > enabled/disabled explicitly, there is some fallout from that. I'd say > that is a bug in those recipes which aren't giving explicit > configuration to dependencies though. > So now the behavior is interesting. It works fine if I build for a machine where host-arch = target-arch so if someone is building for x86_64 then they dont see the build failures. IMO thats worse. > Cheers, > > RIchard > > > ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: new meta-oe failures from master-next 2019-10-24 8:20 ` Khem Raj @ 2019-10-24 8:25 ` richard.purdie 2019-10-24 8:34 ` Khem Raj 0 siblings, 1 reply; 18+ messages in thread From: richard.purdie @ 2019-10-24 8:25 UTC (permalink / raw) To: Khem Raj; +Cc: Patches and discussions about the oe-core layer On Thu, 2019-10-24 at 09:20 +0100, Khem Raj wrote: > On Thu, Oct 24, 2019 at 9:15 AM <richard.purdie@linuxfoundation.org> > wrote: > > On Wed, 2019-10-23 at 23:52 +0100, Khem Raj wrote: > > > On Wed, Oct 23, 2019 at 8:31 PM Richard Purdie > > > <richard.purdie@linuxfoundation.org> wrote: > > > > On Wed, 2019-10-23 at 16:29 +0100, Ross Burton wrote: > > > > > On 23/10/2019 14:03, Khem Raj wrote: > > > > > > Hi Richard > > > > > > > > > > > > New master-next I see these fails > > > > > > > > > > > > https://errors.yoctoproject.org/Errors/Build/91645/ > > > > > > > > > > > > First two are important one's we already know why > > > > > > ti-display-sharing-fw fails to fetch > > > > > > > > > > ERROR: QA Issue: libiio: Files/directories were installed but > > > > > not > > > > > shipped in any package: > > > > > /usr/lib/python2.7 > > > > > /usr/lib/python2.7/site-packages > > > > > /usr/lib/python2.7/site-packages/libiio-0.18-py2.7.egg- > > > > > info > > > > > /usr/lib/python2.7/site-packages/iio.pyc > > > > > /usr/lib/python2.7/site-packages/iio.py > > > > > > > > > > That may have been triggered by some change in oe-core but > > > > > that's > > > > > definitely an issue with libiio. > > > > > > > > Its from this cmake change: > > > > > > > > http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=dbba06d9153ae588c9496b40e5db18b3602bfad1 > > > > > > > > > > I think its causing more failures, where suddenly, the recipes > > > are > > > now > > > resorting to native python, is this patch correct I wonder ? > > > > > > see > > > https://git.openembedded.org/meta-openembedded-contrib/commit/?h=yoe/mut&id=5d02e814bc7d30f925b2eeec85eb053cec516f26 > > > > > > https://git.openembedded.org/meta-openembedded-contrib/commit/?h=yoe/mut&id=3ab0af60e8512cbb718e8a0112d9c9aa98c620a4 > > > > The cmake change makes python visible from HOSTTOOLS. That isn't > > wrong > > as such, it is a change in behaviour. If recipes don't set python > > enabled/disabled explicitly, there is some fallout from that. I'd > > say > > that is a bug in those recipes which aren't giving explicit > > configuration to dependencies though. > > > > So now the behavior is interesting. It works fine if I build for a > machine where host-arch = target-arch > so if someone is building for x86_64 then they dont see the build > failures. IMO thats worse. That is a general problem with cross compiling and applies to any automatically detected dependency from the host. Python is in an odd place here since we do need it on the host to run bitbake and there are places where we need that exposed to code (e.g. they have python scripts), there are places where we don't want it exposed as host contamination. Have you looked at the buildhistory logs to see what changed in meta-oe as that would likely highlight the changes. Cheers, Richard ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: new meta-oe failures from master-next 2019-10-24 8:25 ` richard.purdie @ 2019-10-24 8:34 ` Khem Raj 2019-10-24 9:34 ` richard.purdie 0 siblings, 1 reply; 18+ messages in thread From: Khem Raj @ 2019-10-24 8:34 UTC (permalink / raw) To: Richard Purdie; +Cc: Patches and discussions about the oe-core layer On Thu, Oct 24, 2019 at 9:25 AM <richard.purdie@linuxfoundation.org> wrote: > > On Thu, 2019-10-24 at 09:20 +0100, Khem Raj wrote: > > On Thu, Oct 24, 2019 at 9:15 AM <richard.purdie@linuxfoundation.org> > > wrote: > > > On Wed, 2019-10-23 at 23:52 +0100, Khem Raj wrote: > > > > On Wed, Oct 23, 2019 at 8:31 PM Richard Purdie > > > > <richard.purdie@linuxfoundation.org> wrote: > > > > > On Wed, 2019-10-23 at 16:29 +0100, Ross Burton wrote: > > > > > > On 23/10/2019 14:03, Khem Raj wrote: > > > > > > > Hi Richard > > > > > > > > > > > > > > New master-next I see these fails > > > > > > > > > > > > > > https://errors.yoctoproject.org/Errors/Build/91645/ > > > > > > > > > > > > > > First two are important one's we already know why > > > > > > > ti-display-sharing-fw fails to fetch > > > > > > > > > > > > ERROR: QA Issue: libiio: Files/directories were installed but > > > > > > not > > > > > > shipped in any package: > > > > > > /usr/lib/python2.7 > > > > > > /usr/lib/python2.7/site-packages > > > > > > /usr/lib/python2.7/site-packages/libiio-0.18-py2.7.egg- > > > > > > info > > > > > > /usr/lib/python2.7/site-packages/iio.pyc > > > > > > /usr/lib/python2.7/site-packages/iio.py > > > > > > > > > > > > That may have been triggered by some change in oe-core but > > > > > > that's > > > > > > definitely an issue with libiio. > > > > > > > > > > Its from this cmake change: > > > > > > > > > > http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=dbba06d9153ae588c9496b40e5db18b3602bfad1 > > > > > > > > > > > > > I think its causing more failures, where suddenly, the recipes > > > > are > > > > now > > > > resorting to native python, is this patch correct I wonder ? > > > > > > > > see > > > > https://git.openembedded.org/meta-openembedded-contrib/commit/?h=yoe/mut&id=5d02e814bc7d30f925b2eeec85eb053cec516f26 > > > > > > > > https://git.openembedded.org/meta-openembedded-contrib/commit/?h=yoe/mut&id=3ab0af60e8512cbb718e8a0112d9c9aa98c620a4 > > > > > > The cmake change makes python visible from HOSTTOOLS. That isn't > > > wrong > > > as such, it is a change in behaviour. If recipes don't set python > > > enabled/disabled explicitly, there is some fallout from that. I'd > > > say > > > that is a bug in those recipes which aren't giving explicit > > > configuration to dependencies though. > > > > > > > So now the behavior is interesting. It works fine if I build for a > > machine where host-arch = target-arch > > so if someone is building for x86_64 then they dont see the build > > failures. IMO thats worse. > > That is a general problem with cross compiling and applies to any > automatically detected dependency from the host. Python is in an odd > place here since we do need it on the host to run bitbake and there are > places where we need that exposed to code (e.g. they have python > scripts), there are places where we don't want it exposed as host > contamination. > > Have you looked at the buildhistory logs to see what changed in meta-oe > as that would likely highlight the changes. well nothing has changed in meta-oe as such to cause this issue. Since now we expand where all cmake can look for development headers and libraries, it happily finds then it native sysroot earlier it was guarded from looking into native sysroot. So its cmake not differentiating if its mixing two sysroots now, which is not new for cmake, it has to be given certain paths. So yes when headers and libraries for python are set to point to target sysroot then you aid it to look into right sysroot but I think it might become a pain point in future where someone will test it on x86_64 and think it builds and works where as it will be implicitly wrong. We can fix what we know but that is not all. > > Cheers, > > Richard > > > > > > ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: new meta-oe failures from master-next 2019-10-24 8:34 ` Khem Raj @ 2019-10-24 9:34 ` richard.purdie 0 siblings, 0 replies; 18+ messages in thread From: richard.purdie @ 2019-10-24 9:34 UTC (permalink / raw) To: Khem Raj; +Cc: Patches and discussions about the oe-core layer On Thu, 2019-10-24 at 09:34 +0100, Khem Raj wrote: > On Thu, Oct 24, 2019 at 9:25 AM <richard.purdie@linuxfoundation.org> > wrote: > > On Thu, 2019-10-24 at 09:20 +0100, Khem Raj wrote: > > > On Thu, Oct 24, 2019 at 9:15 AM < > > > richard.purdie@linuxfoundation.org> > > > wrote: > > > > On Wed, 2019-10-23 at 23:52 +0100, Khem Raj wrote: > > > > > On Wed, Oct 23, 2019 at 8:31 PM Richard Purdie > > > > > <richard.purdie@linuxfoundation.org> wrote: > > > > > > On Wed, 2019-10-23 at 16:29 +0100, Ross Burton wrote: > > > > > > > On 23/10/2019 14:03, Khem Raj wrote: > > > > > > > > Hi Richard > > > > > > > > > > > > > > > > New master-next I see these fails > > > > > > > > > > > > > > > > https://errors.yoctoproject.org/Errors/Build/91645/ > > > > > > > > > > > > > > > > First two are important one's we already know why > > > > > > > > ti-display-sharing-fw fails to fetch > > > > > > > > > > > > > > ERROR: QA Issue: libiio: Files/directories were installed > > > > > > > but > > > > > > > not > > > > > > > shipped in any package: > > > > > > > /usr/lib/python2.7 > > > > > > > /usr/lib/python2.7/site-packages > > > > > > > /usr/lib/python2.7/site-packages/libiio-0.18- > > > > > > > py2.7.egg- > > > > > > > info > > > > > > > /usr/lib/python2.7/site-packages/iio.pyc > > > > > > > /usr/lib/python2.7/site-packages/iio.py > > > > > > > > > > > > > > That may have been triggered by some change in oe-core > > > > > > > but > > > > > > > that's > > > > > > > definitely an issue with libiio. > > > > > > > > > > > > Its from this cmake change: > > > > > > > > > > > > http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=dbba06d9153ae588c9496b40e5db18b3602bfad1 > > > > > > > > > > > > > > > > I think its causing more failures, where suddenly, the > > > > > recipes > > > > > are > > > > > now > > > > > resorting to native python, is this patch correct I wonder ? > > > > > > > > > > see > > > > > https://git.openembedded.org/meta-openembedded-contrib/commit/?h=yoe/mut&id=5d02e814bc7d30f925b2eeec85eb053cec516f26 > > > > > > > > > > https://git.openembedded.org/meta-openembedded-contrib/commit/?h=yoe/mut&id=3ab0af60e8512cbb718e8a0112d9c9aa98c620a4 > > > > > > > > The cmake change makes python visible from HOSTTOOLS. That > > > > isn't > > > > wrong > > > > as such, it is a change in behaviour. If recipes don't set > > > > python > > > > enabled/disabled explicitly, there is some fallout from that. > > > > I'd > > > > say > > > > that is a bug in those recipes which aren't giving explicit > > > > configuration to dependencies though. > > > > > > > > > > So now the behavior is interesting. It works fine if I build for > > > a > > > machine where host-arch = target-arch > > > so if someone is building for x86_64 then they dont see the build > > > failures. IMO thats worse. > > > > That is a general problem with cross compiling and applies to any > > automatically detected dependency from the host. Python is in an > > odd > > place here since we do need it on the host to run bitbake and there > > are > > places where we need that exposed to code (e.g. they have python > > scripts), there are places where we don't want it exposed as host > > contamination. > > > > Have you looked at the buildhistory logs to see what changed in > > meta-oe > > as that would likely highlight the changes. > > well nothing has changed in meta-oe as such to cause this issue. > Since now we expand where all cmake can look for development headers > and libraries, it happily finds then it native sysroot earlier it was > guarded from looking into native sysroot. So its cmake not > differentiating if its mixing two sysroots now, which is not new for > cmake, it has to be given certain paths. No, cmake has always looked in the native sysroot. What the patch changes is whether HOSTTOOLS are seen or not. The exact change is: -set( CMAKE_FIND_ROOT_PATH ${STAGING_DIR_HOST} ${STAGING_DIR_NATIVE} ${CROSS_DIR} ${OECMAKE_PERLNATIVE_DIR} ${OECMAKE_EXTRA_ROOT_PATH} ${EXTERNAL_TOOLCHAIN}) +set( CMAKE_FIND_ROOT_PATH ${STAGING_DIR_HOST} ${STAGING_DIR_NATIVE} ${CROSS_DIR} ${OECMAKE_PERLNATIVE_DIR} ${OECMAKE_EXTRA_ROOT_PATH} ${EXTERNAL_TOOLCHAIN} ${HOSTTOOLS_DIR}) It already looks at native, cross and external tools, just not HOSTTOOLS_DIR. This does look very much like an omission and would break ASSUME_PROVIDED usage for example so it does fix a real world issue I can imagine people running into. > So yes when headers and libraries for python are set to point to > target sysroot then you aid it to look > into right sysroot but I think it might become a pain point in future > where someone will test it on x86_64 > and think it builds and works where as it will be implicitly wrong. > We can fix what we know but that is not all. Agreed, but that is a problem we already have and is why we do ask people test another arch. Its also why we ask people to list dependencies and explicitly enable or disable them. I do understand what you mean but I don't think it changes much as its the same general problem the project has always faced and continues to face. If you want to propose the patch be reverted, you can however I'm not really seeing a case for it myself. Cheers, Richard ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: new meta-oe failures from master-next 2019-10-24 8:15 ` richard.purdie 2019-10-24 8:20 ` Khem Raj @ 2019-10-24 9:34 ` Adrian Bunk 2019-10-24 9:43 ` richard.purdie 1 sibling, 1 reply; 18+ messages in thread From: Adrian Bunk @ 2019-10-24 9:34 UTC (permalink / raw) To: richard.purdie; +Cc: Patches and discussions about the oe-core layer On Thu, Oct 24, 2019 at 09:15:01AM +0100, richard.purdie@linuxfoundation.org wrote: > > The cmake change makes python visible from HOSTTOOLS. That isn't wrong > as such, it is a change in behaviour. If recipes don't set python > enabled/disabled explicitly, there is some fallout from that. I'd say > that is a bug in those recipes which aren't giving explicit > configuration to dependencies though. The problem is not about enable/disable, it is more about not explicitly selecting the python version. For the affected libiio the python2 -> python3 change of the python bindings last week [1] was basically: -inherit cmake pythonnative systemd +inherit cmake python3native systemd This is very fragile, and I would consider it expected that either the old or the new case will break in some way when both python2 and python3 are available during the build. > Cheers, > > RIchard cu Adrian [1] http://git.openembedded.org/meta-openembedded/commit/?id=6af155513506f6a0a3a44b66fb48897f22fb2c2f -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: new meta-oe failures from master-next 2019-10-24 9:34 ` Adrian Bunk @ 2019-10-24 9:43 ` richard.purdie 0 siblings, 0 replies; 18+ messages in thread From: richard.purdie @ 2019-10-24 9:43 UTC (permalink / raw) To: Adrian Bunk; +Cc: Patches and discussions about the oe-core layer On Thu, 2019-10-24 at 12:34 +0300, Adrian Bunk wrote: > On Thu, Oct 24, 2019 at 09:15:01AM +0100, > richard.purdie@linuxfoundation.org wrote: > > The cmake change makes python visible from HOSTTOOLS. That isn't > > wrong > > as such, it is a change in behaviour. If recipes don't set python > > enabled/disabled explicitly, there is some fallout from that. I'd > > say > > that is a bug in those recipes which aren't giving explicit > > configuration to dependencies though. > > The problem is not about enable/disable, it is more about not > explicitly selecting the python version. > > For the affected libiio the python2 -> python3 change of the python > bindings last week [1] was basically: > > -inherit cmake pythonnative systemd > +inherit cmake python3native systemd > > This is very fragile, and I would consider it expected that either > the old or the new case will break in some way when both python2 and > python3 are available during the build. That isn't the complete story. We changed the search path in master: http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=dbba06d9153ae588c9496b40e5db18b3602bfad1 which then meant libiio found the wrong python as "python" in PATH became py2. As you say, it doesn't specifically declare which python it wants so things changed. I admit I'd misread the recipes, both for the upgrade and enable/disable, I should know better. I think this kind of proves my point about trying to push more work onto people who are already overworked though. The key questions: * is that OE-Core change is correct? * should this recipe be more explicit about its configuration? * are there other places this problem has been introduced? * who is responsible for fixing any further issues? While we remember we should document this for the 3.1 migration guide at the very least. Cheers, Richard ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: new meta-oe failures from master-next 2019-10-23 13:03 new meta-oe failures from master-next Khem Raj 2019-10-23 13:05 ` Khem Raj 2019-10-23 15:29 ` Ross Burton @ 2019-10-23 16:22 ` richard.purdie 2 siblings, 0 replies; 18+ messages in thread From: richard.purdie @ 2019-10-23 16:22 UTC (permalink / raw) To: Khem Raj, Patches and discussions about the oe-core layer Hi Khem. On Wed, 2019-10-23 at 14:03 +0100, Khem Raj wrote: > Hi Richard > > New master-next I see these fails > > https://errors.yoctoproject.org/Errors/Build/91645/ > > First two are important one's we already know why > ti-display-sharing-fw fails to fetch Firstly, before you mention it, I started merging master-next earlier today after multiple tries and finally a green build last night. I paused as there was an issue, I dropped more patches and eventually after I thought I'd handled all the remaining issues I knew about, I merged things. I didn't see this report until now (afterwards) :(. I guess I now need to bisect things and figure out where these failures came from. Cheers, Richard ^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2019-10-24 9:43 UTC | newest] Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-10-23 13:03 new meta-oe failures from master-next Khem Raj 2019-10-23 13:05 ` Khem Raj 2019-10-23 15:58 ` akuster808 2019-10-23 15:29 ` Ross Burton 2019-10-23 19:23 ` Adrian Bunk 2019-10-23 21:20 ` Richard Purdie 2019-10-23 22:08 ` Adrian Bunk 2019-10-23 19:31 ` Richard Purdie 2019-10-23 22:52 ` Khem Raj 2019-10-24 6:37 ` Khem Raj 2019-10-24 8:15 ` richard.purdie 2019-10-24 8:20 ` Khem Raj 2019-10-24 8:25 ` richard.purdie 2019-10-24 8:34 ` Khem Raj 2019-10-24 9:34 ` richard.purdie 2019-10-24 9:34 ` Adrian Bunk 2019-10-24 9:43 ` richard.purdie 2019-10-23 16:22 ` richard.purdie
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.