On 07/09/2019 02:45 AM, Burton, Ross wrote:
Agreed, making it a non-fatal dependency just means that some eSDKs
break, not all. There needs to be a better fix.
But it's already in buildtools, and eSDK installation process involves
extracting buildtools and sourcing its script.
Under which circumstances will we break some eSDKs?
Anyway, I'm trying to do something about build-sysroots recipe and will
send out a new patch.
Regards,
Chen Qi
Ross
On Mon, 8 Jul 2019 at 17:53, Richard Purdie
<richard.pur...@linuxfoundation.org> wrote:
On Mon, 2019-07-08 at 15:37 +0800, Chen Qi wrote:
For build-sysroots.bb, the xmlcatalog would not be in its
staging directory. Causing the following error for eSDK.
ERROR: build-sysroots-1.0-r0 do_build_native_sysroot: Command
'/PATH/TO/IMAGE/testsdkext/tmp/sysroots/x86_64/usr/bin/postinst-
docbook-xml-dtd4-native-xmlcatalog' returned non-zero exit status
127.
ERROR: build-sysroots-1.0-r0 do_build_native_sysroot: Function
failed: do_build_native_sysroot
The problem could be reproduced by the following steps.
1. Add in local.conf:
IMAGE_INSTALL_append = " btrfs-tools"
DISTRO_FEATURES_append = " api-documentation"
INHERIT += "testsdk"
2. bitbake core-image-minimal -c populate_sdk_ext
3. bitbake core-image-minimal -c testsdkext
So we add nativesdk-libxml2-utils to buildtools-tarball
to ensure the existence of xmlcatalog. Also add it
to HOSTTOOLS_NONFATAL so it could be seen by bitbake.
Signed-off-by: Chen Qi <qi.c...@windriver.com>
---
meta/conf/bitbake.conf | 3 +++
meta/recipes-core/meta/buildtools-tarball.bb | 1 +
2 files changed, 4 insertions(+)
diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
index 5e93f5c..2f64eae 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -517,6 +517,9 @@ HOSTTOOLS_NONFATAL += "scp"
# Link to git-lfs if present
HOSTTOOLS_NONFATAL += "git-lfs"
+# build-sysroot needs xmlcatalog in order for eSDK installation
+HOSTTOOLS_NONFATAL += "xmlcatalog"
I don't mind the buildtools-tarball change but HOSTTOOLS is starting to
grow to contain far too much random stuff which could impact
reproduciblity.
Is there some other way we could fix this? It still feels like a
dependency problem which we chould fix by adding a missing dependency
although I appreciate its far from being that simple.
I wonder if there is a way we could teach build-sysroots to be cleverer
about dependencies?
Cheers,
Richard
--
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
--
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
