* [PATCH V2 0/2] populate_sdk_ext: two fixes
@ 2015-05-04 7:59 Chen Qi
2015-05-04 7:59 ` [PATCH V2 1/2] populate_sdk_ext: install the latest buildtools-tarball Chen Qi
` (2 more replies)
0 siblings, 3 replies; 5+ messages in thread
From: Chen Qi @ 2015-05-04 7:59 UTC (permalink / raw)
To: openembedded-core
The following changes since commit 4dd4b96b6d60246338bb30ede9f3ab1b2e757be9:
libxfont: Security Advisory - libxfont - CVE-2015-1804 (2015-04-28 07:56:01 +0100)
are available in the git repository at:
git://git.openembedded.org/openembedded-core-contrib ChenQi/populate_sdk_ext_2_fixes
http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=ChenQi/populate_sdk_ext_2_fixes
Chen Qi (2):
populate_sdk_ext: install the latest buildtools-tarball
populate_sdk_ext: consider custom configuration in local.conf
meta/classes/populate_sdk_ext.bbclass | 24 +++++++++++++++++++++++-
1 file changed, 23 insertions(+), 1 deletion(-)
--
1.9.1
^ permalink raw reply [flat|nested] 5+ messages in thread* [PATCH V2 1/2] populate_sdk_ext: install the latest buildtools-tarball 2015-05-04 7:59 [PATCH V2 0/2] populate_sdk_ext: two fixes Chen Qi @ 2015-05-04 7:59 ` Chen Qi 2015-05-04 7:59 ` [PATCH V2 2/2] populate_sdk_ext: consider custom configuration in local.conf Chen Qi 2015-05-08 2:26 ` [PATCH V2 0/2] populate_sdk_ext: two fixes ChenQi 2 siblings, 0 replies; 5+ messages in thread From: Chen Qi @ 2015-05-04 7:59 UTC (permalink / raw) To: openembedded-core If we do `bitbake buildtools-tarball' and then after one day do `bitbake core-image-minimal -c populate_sdk_ext', we would meet errors like below. | install: cannot stat '/buildarea2/chenqi/poky/build-systemd/tmp/deploy/sdk/ poky-glibc-x86_64-buildtools-tarball-core2-64-buildtools-nativesdk-standalone -1.8+snapshot-20150429.sh': No such file or directory The problem is that the output name for buildtools-tarball has ${DATE} in it. So if populate_sdk_ext task is executed but buildtools-tarball is not rebuilt, the above error appears. Instead of hardcoding ${DISTRO_VERSION} which consists of ${DATE} in the install_tools() function, we should find the latest buildtools-tarball based on the modification time and install it. [YOCTO #7674] Signed-off-by: Chen Qi <Qi.Chen@windriver.com> --- meta/classes/populate_sdk_ext.bbclass | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/meta/classes/populate_sdk_ext.bbclass b/meta/classes/populate_sdk_ext.bbclass index dc2c58e..2fc4c11 100644 --- a/meta/classes/populate_sdk_ext.bbclass +++ b/meta/classes/populate_sdk_ext.bbclass @@ -168,7 +168,9 @@ install_tools() { ln -sr ${SDK_OUTPUT}/${SDKPATH}/${scriptrelpath}/recipetool ${SDK_OUTPUT}/${SDKPATHNATIVE}${bindir_nativesdk}/recipetool touch ${SDK_OUTPUT}/${SDKPATH}/.devtoolbase - install ${SDK_DEPLOY}/${DISTRO}-${TCLIBC}-${SDK_ARCH}-buildtools-tarball-${TUNE_PKGARCH}-buildtools-nativesdk-standalone-${DISTRO_VERSION}.sh ${SDK_OUTPUT}/${SDKPATH} + # find latest buildtools-tarball and install it + buildtools_path=`ls -t1 ${SDK_DEPLOY}/${DISTRO}-${TCLIBC}-${SDK_ARCH}-buildtools-tarball-${TUNE_PKGARCH}-buildtools-nativesdk-standalone-*.sh | head -n1` + install $buildtools_path ${SDK_OUTPUT}/${SDKPATH} install ${SDK_DEPLOY}/${BUILD_ARCH}-nativesdk-libc.tar.bz2 ${SDK_OUTPUT}/${SDKPATH} } -- 1.9.1 ^ permalink raw reply related [flat|nested] 5+ messages in thread
* [PATCH V2 2/2] populate_sdk_ext: consider custom configuration in local.conf 2015-05-04 7:59 [PATCH V2 0/2] populate_sdk_ext: two fixes Chen Qi 2015-05-04 7:59 ` [PATCH V2 1/2] populate_sdk_ext: install the latest buildtools-tarball Chen Qi @ 2015-05-04 7:59 ` Chen Qi 2015-05-08 9:32 ` Paul Eggleton 2015-05-08 2:26 ` [PATCH V2 0/2] populate_sdk_ext: two fixes ChenQi 2 siblings, 1 reply; 5+ messages in thread From: Chen Qi @ 2015-05-04 7:59 UTC (permalink / raw) To: openembedded-core Copy the contents of local.conf under TOPDIR into the final generated local.conf. In this way, custom settings are also made into the final local.conf like IMAGE_INSTALL, DISTRO_FEATURES, VIRTUAL-RUNTIME_xxx, etc. Before this change, installing extensible SDK would usually report failure when preparing the build system if the user has custom configuration for DISTRO_FEATURES in local.conf. Also, items in IMAGE_INSTALL_append in local.conf also don't get built correctly. This patch solves the above problem. A blacklist mechanism is also introduced so that we can blacklist variables that should not be copied into the final local.conf file. Currently, the blacklist contains 'TMPDIR', 'SSTATE_DIR', 'DL_DIR', 'STAMPS_DIR', 'BASE_WORKDIR' and 'DEPLOY_DIR'. What these variables have in common is that they are set in bitbake.conf using '?=' or '??='. This list of course doesn't cover every possible setting allowed in local.conf. And it's possible that some setting in local.conf would still result in failure when preparing build system at installation time of extensible SDK. The point is that we want to make sure that reasonable settings like PACKAGECONFIG, DISTRO_FEATURES, IMAGE_INSTALL, etc, don't result in failure which would very much depress the users of extensible SDK. [YOCTO #7616] Signed-off-by: Chen Qi <Qi.Chen@windriver.com> --- meta/classes/populate_sdk_ext.bbclass | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) diff --git a/meta/classes/populate_sdk_ext.bbclass b/meta/classes/populate_sdk_ext.bbclass index 2fc4c11..f08ba86 100644 --- a/meta/classes/populate_sdk_ext.bbclass +++ b/meta/classes/populate_sdk_ext.bbclass @@ -16,6 +16,7 @@ SDK_RDEPENDS_append_task-populate-sdk-ext = " ${SDK_TARGETS}" SDK_RELOCATE_AFTER_INSTALL_task-populate-sdk-ext = "0" SDK_META_CONF_WHITELIST ?= "MACHINE DISTRO PACKAGE_CLASSES" +SDK_META_CONF_BLACKLIST ?= "TMPDIR DL_DIR SSTATE_DIR STAMPS_DIR BASE_WORKDIR DEPLOY_DIR" SDK_TARGETS ?= "${PN}" OE_INIT_ENV_SCRIPT ?= "oe-init-build-env" @@ -114,6 +115,25 @@ python copy_buildsystem () { f.write('# this configuration provides, it is strongly suggested that you set\n') f.write('# up a proper instance of the full build system and use that instead.\n\n') + # Copy configurations from the current local.conf + builddir = d.getVar('TOPDIR', True) + with open(builddir + '/conf/local.conf', 'r') as lf: + varblacklist = d.getVar('SDK_META_CONF_BLACKLIST', True).split() + skip = False + for line in lf: + line = line.lstrip() + if line.startswith('#'): + continue + for varname in varblacklist: + if line.startswith(varname): + skip = True + break + if not skip: + f.write(line) + skip = False + f.write('\n') + + # Configurations in local.conf which are specific for extensible SDK f.write('INHERIT += "%s"\n\n' % 'uninative') f.write('CONF_VERSION = "%s"\n\n' % d.getVar('CONF_VERSION')) -- 1.9.1 ^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: [PATCH V2 2/2] populate_sdk_ext: consider custom configuration in local.conf 2015-05-04 7:59 ` [PATCH V2 2/2] populate_sdk_ext: consider custom configuration in local.conf Chen Qi @ 2015-05-08 9:32 ` Paul Eggleton 0 siblings, 0 replies; 5+ messages in thread From: Paul Eggleton @ 2015-05-08 9:32 UTC (permalink / raw) To: Chen Qi; +Cc: openembedded-core Hi Qi, On Monday 04 May 2015 15:59:30 Chen Qi wrote: > Copy the contents of local.conf under TOPDIR into the final generated > local.conf. In this way, custom settings are also made into the final > local.conf like IMAGE_INSTALL, DISTRO_FEATURES, VIRTUAL-RUNTIME_xxx, etc. > > Before this change, installing extensible SDK would usually report failure > when preparing the build system if the user has custom configuration for > DISTRO_FEATURES in local.conf. Also, items in IMAGE_INSTALL_append in > local.conf also don't get built correctly. > > This patch solves the above problem. > > A blacklist mechanism is also introduced so that we can blacklist variables > that should not be copied into the final local.conf file. Currently, the > blacklist contains 'TMPDIR', 'SSTATE_DIR', 'DL_DIR', 'STAMPS_DIR', > 'BASE_WORKDIR' and 'DEPLOY_DIR'. What these variables have in common is > that they are set in bitbake.conf using '?=' or '??='. > > This list of course doesn't cover every possible setting allowed in > local.conf. And it's possible that some setting in local.conf would still > result in failure when preparing build system at installation time of > extensible SDK. The point is that we want to make sure that reasonable > settings like PACKAGECONFIG, DISTRO_FEATURES, IMAGE_INSTALL, etc, don't > result in failure which would very much depress the users of extensible > SDK. > > [YOCTO #7616] > > Signed-off-by: Chen Qi <Qi.Chen@windriver.com> > --- > meta/classes/populate_sdk_ext.bbclass | 20 ++++++++++++++++++++ > 1 file changed, 20 insertions(+) > > diff --git a/meta/classes/populate_sdk_ext.bbclass > b/meta/classes/populate_sdk_ext.bbclass index 2fc4c11..f08ba86 100644 > --- a/meta/classes/populate_sdk_ext.bbclass > +++ b/meta/classes/populate_sdk_ext.bbclass > @@ -16,6 +16,7 @@ SDK_RDEPENDS_append_task-populate-sdk-ext = " > ${SDK_TARGETS}" SDK_RELOCATE_AFTER_INSTALL_task-populate-sdk-ext = "0" > > SDK_META_CONF_WHITELIST ?= "MACHINE DISTRO PACKAGE_CLASSES" > +SDK_META_CONF_BLACKLIST ?= "TMPDIR DL_DIR SSTATE_DIR STAMPS_DIR > BASE_WORKDIR DEPLOY_DIR" > > SDK_TARGETS ?= "${PN}" > OE_INIT_ENV_SCRIPT ?= "oe-init-build-env" > @@ -114,6 +115,25 @@ python copy_buildsystem () { > f.write('# this configuration provides, it is strongly suggested > that you set\n') f.write('# up a proper instance of the full build system > and use that instead.\n\n') > > + # Copy configurations from the current local.conf > + builddir = d.getVar('TOPDIR', True) > + with open(builddir + '/conf/local.conf', 'r') as lf: > + varblacklist = d.getVar('SDK_META_CONF_BLACKLIST', > True).split() + skip = False > + for line in lf: > + line = line.lstrip() > + if line.startswith('#'): > + continue > + for varname in varblacklist: > + if line.startswith(varname): > + skip = True > + break > + if not skip: > + f.write(line) > + skip = False > + f.write('\n') > + > + # Configurations in local.conf which are specific for extensible > SDK f.write('INHERIT += "%s"\n\n' % 'uninative') > f.write('CONF_VERSION = "%s"\n\n' % d.getVar('CONF_VERSION')) All you've done since v1 is extend the blacklist - I was hoping for something generic that stops inappropriate paths bleeding into the SDK configuration. Can you please add some code to handle that? Thanks, Paul -- Paul Eggleton Intel Open Source Technology Centre ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH V2 0/2] populate_sdk_ext: two fixes 2015-05-04 7:59 [PATCH V2 0/2] populate_sdk_ext: two fixes Chen Qi 2015-05-04 7:59 ` [PATCH V2 1/2] populate_sdk_ext: install the latest buildtools-tarball Chen Qi 2015-05-04 7:59 ` [PATCH V2 2/2] populate_sdk_ext: consider custom configuration in local.conf Chen Qi @ 2015-05-08 2:26 ` ChenQi 2 siblings, 0 replies; 5+ messages in thread From: ChenQi @ 2015-05-08 2:26 UTC (permalink / raw) To: openembedded-core ping On 05/04/2015 03:59 PM, Chen Qi wrote: > The following changes since commit 4dd4b96b6d60246338bb30ede9f3ab1b2e757be9: > > libxfont: Security Advisory - libxfont - CVE-2015-1804 (2015-04-28 07:56:01 +0100) > > are available in the git repository at: > > git://git.openembedded.org/openembedded-core-contrib ChenQi/populate_sdk_ext_2_fixes > http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=ChenQi/populate_sdk_ext_2_fixes > > Chen Qi (2): > populate_sdk_ext: install the latest buildtools-tarball > populate_sdk_ext: consider custom configuration in local.conf > > meta/classes/populate_sdk_ext.bbclass | 24 +++++++++++++++++++++++- > 1 file changed, 23 insertions(+), 1 deletion(-) > ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2015-05-08 9:32 UTC | newest] Thread overview: 5+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2015-05-04 7:59 [PATCH V2 0/2] populate_sdk_ext: two fixes Chen Qi 2015-05-04 7:59 ` [PATCH V2 1/2] populate_sdk_ext: install the latest buildtools-tarball Chen Qi 2015-05-04 7:59 ` [PATCH V2 2/2] populate_sdk_ext: consider custom configuration in local.conf Chen Qi 2015-05-08 9:32 ` Paul Eggleton 2015-05-08 2:26 ` [PATCH V2 0/2] populate_sdk_ext: two fixes ChenQi
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.