Re: [OE-core] WARNING: The license listed CLOSED was not in the licenses collected for foo
On 11-05-15 11:09, Paul Eggleton wrote: If you want to do this you need to add a generic license file for the license in question, which means extending LICENSE_PATH in your custom layer to a directory containing a file named with the license. I did that, but it didn't get rid of the warning message (see previous post). You're right that the error message isn't as helpful as it could be. We should fix that as well. Well if I knew what to do myself, I could provide a patch for that... Kind regards, Mike Looijmans System Expert TOPIC Embedded Products Eindhovenseweg 32-C, NL-5683 KH Best Postbus 440, NL-5680 AK Best Telefoon: +31 (0) 499 33 69 79 Telefax: +31 (0) 499 33 69 70 E-mail: mike.looijm...@topicproducts.com Website: www.topicproducts.com Please consider the environment before printing this e-mail -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Changing external kernel module results in rebuild of whole kernel
On 06-05-15 14:35, Richard Purdie wrote: On Wed, 2015-05-06 at 08:35 +0200, Mike Looijmans wrote: Something in recent OE-core triggered a weird dependency backfire. If I change a recipe for a kernel module (a bb recipe that does inherit module) this will trigger a rebuild of the whole kernel. This turns the 5-second job of just updating a single module into a several minute workout for the build machine, and then causes boards to re-write the kernel into flash needlessly when upgrading. I now see this on all projects using OE-core master. I can't really pin what caused it though. Anyone else seen this? I have a suspicion this may be as a result of the changed kernel build process in 1.8. The idea there is that the modules depend on the kernel source and rather than taring up and then extracting a large (GB) sized sstate object, we just extract the original kernel source. So is the kernel really rebuilding, or, is it just extracting source for the kernel to build against? I noticed rm_work in your other post and this may also be some bad interaction between rm_work and the kernel build process changes. Any things I can try or provide on this? As things are now, I'd much prefer the taring up and then extracting a large (GB) sized sstate object option, since that at least worked correctly. Mike. Kind regards, Mike Looijmans System Expert TOPIC Embedded Products Eindhovenseweg 32-C, NL-5683 KH Best Postbus 440, NL-5680 AK Best Telefoon: +31 (0) 499 33 69 79 Telefax: +31 (0) 499 33 69 70 E-mail: mike.looijm...@topicproducts.com Website: www.topicproducts.com Please consider the environment before printing this e-mail -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH V3 1/2] populate_sdk_ext: install the latest buildtools-tarball
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.c...@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
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH V3 0/2] populate_sdk_ext: two fixes
The following changes since commit 7ffe10df73cc20d10fcd41b121074445273bd60e: license_class: license_create_manifest improvment (2015-05-09 22:26:02 +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 | 27 ++- 1 file changed, 26 insertions(+), 1 deletion(-) -- 1.9.1 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH V3 2/2] populate_sdk_ext: consider custom configuration in local.conf
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 '??='.
In addition, we check to avoid any setting that might lead to host path
bleeding into SDK's configuration.
[YOCTO #7616]
Signed-off-by: Chen Qi qi.c...@windriver.com
---
meta/classes/populate_sdk_ext.bbclass | 23 +++
1 file changed, 23 insertions(+)
diff --git a/meta/classes/populate_sdk_ext.bbclass
b/meta/classes/populate_sdk_ext.bbclass
index 2fc4c11..49ba26b 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,28 @@ 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
+# avoid host path bleeding into SDK configuration
+if line.find('/') != -1:
+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
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] elfutils: Disable the unnecessary check in iconv.m4
From: Roy Li rongqing...@windriver.com Disable the test Test against HP-UX 11.11 bug: No converter from EUC-JP to UTF-8 is provided since we don't support HP-UX and if the euc-jp is not installed on the host, the dependence will be built without iconv support and will cause guild-native building fail. The patch is similar as 0470bd7a9658d3[libunistring: remove the test to convert euc-jp in configure] Signed-off-by: Roy Li rongqing...@windriver.com --- .../0001-remove-the-unneed-checking.patch | 38 ++ meta/recipes-devtools/elfutils/elfutils_0.161.bb | 1 + 2 files changed, 39 insertions(+) create mode 100644 meta/recipes-devtools/elfutils/elfutils-0.161/0001-remove-the-unneed-checking.patch diff --git a/meta/recipes-devtools/elfutils/elfutils-0.161/0001-remove-the-unneed-checking.patch b/meta/recipes-devtools/elfutils/elfutils-0.161/0001-remove-the-unneed-checking.patch new file mode 100644 index 000..5be92d7 --- /dev/null +++ b/meta/recipes-devtools/elfutils/elfutils-0.161/0001-remove-the-unneed-checking.patch @@ -0,0 +1,38 @@ +Disable the test to convert euc-jp + +Remove the test Test against HP-UX 11.11 bug: +No converter from EUC-JP to UTF-8 is provided +since we don't support HP-UX and if the euc-jp is not +installed on the host, the dependence will be built without +iconv support and will cause guild-native building fail. + +Upstream-Status: Inappropriate [OE specific] + +Signed-off-by: Roy Li rongqing...@windriver.com +--- + m4/iconv.m4 | 2 ++ + 1 file changed, 2 insertions(+) + +diff --git a/m4/iconv.m4 b/m4/iconv.m4 +index a503646..299f1eb 100644 +--- a/m4/iconv.m4 b/m4/iconv.m4 +@@ -159,6 +159,7 @@ int main () + } + } + #endif ++#if 0 + /* Test against HP-UX 11.11 bug: No converter from EUC-JP to UTF-8 is + provided. */ + if (/* Try standardized names. */ +@@ -170,6 +171,7 @@ int main () + /* Try HP-UX names. */ +iconv_open (utf8, eucJP) == (iconv_t)(-1)) + result |= 16; ++#endif + return result; + }]])], + [am_cv_func_iconv_works=yes], +-- +2.0.1 + diff --git a/meta/recipes-devtools/elfutils/elfutils_0.161.bb b/meta/recipes-devtools/elfutils/elfutils_0.161.bb index e111b34..70a3c16 100644 --- a/meta/recipes-devtools/elfutils/elfutils_0.161.bb +++ b/meta/recipes-devtools/elfutils/elfutils_0.161.bb @@ -17,6 +17,7 @@ SRC_URI += \ file://fixheadercheck.patch \ file://0001-elf_getarsym-Silence-Werror-maybe-uninitialized-fals.patch \ file://0001-libelf-Fix-dir-traversal-vuln-in-ar-extraction.patch \ +file://0001-remove-the-unneed-checking.patch \ # pick the patch from debian -- 1.9.1 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] meta/lib/oe/utils.py: properly implement both_contain()
Hi Andre, On Monday 11 May 2015 17:34:45 Andre McCurdy wrote: On Wed, Feb 25, 2015 at 7:15 AM, Cristian Iorga cristian.io...@intel.com wrote: oe.utils.both_contain() just does a find() on the value rather than splitting the value and then looking in the list of split items. The result is that if you add a feature to MACHINE_FEATURES that itself has a substring that matches one of the values looked for when building COMBINED_FEATURES, you end up with an incomprehensible error (here with ext2i in MACHINE_FEATURES): ERROR: Nothing RPROVIDES 'packagegroup-base-ext2' (but /home/balister/src/oe-core/oe-core/meta/recipes-core/ /packagegroups/packagegroup-base.bb RDEPENDS on or otherwise requires it) This change seems to break COMBINED_FEATURES. $ bitbake -e packagegroup-base | grep '^COMBINED_FEATURES=' dizzy: COMBINED_FEATURES=alsa fido: COMBINED_FEATURES=set(['alsa']) Yes it did, unfortunately. There was a follow-up fix in master: http://cgit.openembedded.org/openembedded-core/commit/?id=c4ca9dbd4191fcff08e75035e3d276490ed80b05 This is included in Joshua's pending backport changeset for fido. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] gcc5: Add PR65779 patch to fix powerpc compile issues
On Mon, 2015-05-11 at 17:24 -0700, Khem Raj wrote: On Mon, May 11, 2015 at 4:20 PM, akuster808 akuster...@gmail.com wrote: On 05/11/2015 09:54 AM, Richard Purdie wrote: This fixes compile issues on powerpc with gcc 5 which show up with errors like: | make[2]: Entering directory '/media/build1/poky/build/tmp/work/ppc7400-poky-linux/xprop/1_1.2.2-r0/build' | powerpc-poky-linux-gcc -m32 -mhard-float -mcpu=7400 --sysroot=/media/build1/poky/build/tmp/sysroots/qemuppc -Wall -Wpointer-arith -Wmissing-declarations -Wformat=2 -Wstrict-prototypes -Wmissing-prototypes -Wnested-externs -Wbad-function-cast -Wold-style-definition -Wdeclaration-after-statement -Wunused -Wuninitialized -Wshadow -Wmissing-noreturn -Wmissing-format-attribute -Wredundant-decls -Wlogical-op -Werror=implicit -Werror=nonnull -Werror=init-self -Werror=main -Werror=missing-braces -Werror=sequence-point -Werror=return-type -Werror=trigraphs -Werror=array-bounds -Werror=write-strings -Werror=address -Werror=int-to-pointer-cast -Werror=pointer-to-int-cast -fno-strict-aliasing -O2 -pipe -g -feliminate-unused-debug-types -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed -o xprop dsimple.o clientwin.o xprop.o -lX11 | /media/build1/poky/build/tmp/sysroots/qemuppc/usr/lib/../lib/libX11.so: undefined reference to `.LCL2' | collect2: error: ld returned 1 exit status Signed-off-by: Richard Purdie richard.pur...@linuxfoundation.org Acked-by: Armin Kuster akuster...@gmail.com this fixes all but one package(lzop) failure on qemuppc base yocto world build. I am fine witj this patch for now, since we are mostly build testing, we have to keep in mind its a codegen bug and can bite us at runtime. I am just hoping for an update to this patch and that will eliminate that doubt. Agreed, an update upstream would obviously help. FWIW the automated runtime tests did look reasonable on the autobuilder apart from: core-image-sato-sdk has a problem with the C++ toolchain not finding limits (all arches). qemuarm is not booting (minimal, sato or sato-sdk). However these issues were present before the patch so I don't think its related. Since the failures list is better with the patch I'll merge it until something better comes along. Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] gcc: Fix packaging for gcc v5
On May 12, 2015, at 5:03 AM, Richard Purdie
richard.pur...@linuxfoundation.org wrote:
Fixes:
ERROR: QA Issue: gcc: Files/directories were installed but not shipped in any
package:
/usr/bin/i586-poky-linux-gcov-tool
with gcc v5.x
Signed-off-by: Richard Purdie richard.pur...@linuxfoundation.org
diff --git a/meta/recipes-devtools/gcc/gcc-target.inc
b/meta/recipes-devtools/gcc/gcc-target.inc
index e348517..47fe1b6 100644
--- a/meta/recipes-devtools/gcc/gcc-target.inc
+++ b/meta/recipes-devtools/gcc/gcc-target.inc
@@ -83,7 +83,7 @@ FILES_cpp = \
${libexecdir}/gcc/${TARGET_SYS}/${BINV}/cc1
FILES_cpp-symlinks = ${bindir}/cpp
-FILES_gcov = ${bindir}/${TARGET_PREFIX}gcov
+FILES_gcov = ${bindir}/${TARGET_PREFIX}gcov*”
this is ok but I think its better if we were explicit here since I would like
to know
when a new file is added into gcc. this will implicitly add it.
FILES_gcov-symlinks = ${bindir}/gcov
FILES_g++ = \
signature.asc
Description: Message signed with OpenPGP using GPGMail
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] rpm: fix build issue with gcc5
On 05/12/2015 12:06 AM, Richard Purdie wrote:
On Sun, 2015-05-10 at 23:03 +0100, Richard Purdie wrote:
On Sun, 2015-05-10 at 09:15 -0700, Khem Raj wrote:
On Sun, May 10, 2015 at 7:28 AM, Armin Kuster akuster...@gmail.com wrote:
| tset.o:(.debug_loc+0xe8): undefined reference to `.LCL0'
| tset.o:(.debug_loc+0xf7): undefined reference to `.LCL0'
thanks Khem
Signed-off-by: Armin Kuster akuster...@gmail.com
---
meta/recipes-devtools/rpm/rpm_5.4.14.bb | 3 +++
1 file changed, 3 insertions(+)
diff --git a/meta/recipes-devtools/rpm/rpm_5.4.14.bb
b/meta/recipes-devtools/rpm/rpm_5.4.14.bb
index 03a24f0..22b111a 100644
--- a/meta/recipes-devtools/rpm/rpm_5.4.14.bb
+++ b/meta/recipes-devtools/rpm/rpm_5.4.14.bb
@@ -110,6 +110,9 @@ inherit autotools gettext
acpaths = -I ${S}/db/dist/aclocal -I ${S}/db/dist/aclocal_java
+FULL_OPTIMIZATION_powerpc_remove = -O2
+FULL_OPTIMIZATION_append_powerpc = -Os
+
http://git.openembedded.org/openembedded-core-contrib/commit/?h=kraj/masterid=741d3bf91144973d26de647039fa60b87a09edf1
fixes same issue for libx11
I am wondering if we should make this change in some common config
metadata file to list all recipes that need this workaround
untill gcc is fixed for it may be arch-powerpc.inc, since then it will
be easy to remember to unbolt them once gcc is fixed.
I like the idea of a common include to handle this a lot better.
FWIW, I tried gcc 5 on the autobuilder. The results were 141 failures so
far:
http://errors.yoctoproject.org/Errors/Search/?items=10query=1426e31f0bcd19f066931d2ecbdec3752b14e88elimit=150
With the gcc patch I've posted applied:
http://errors.yoctoproject.org/Errors/Search/?items=10query=5fd0b7c163f4f3312bea9bd3246a6bd67a8da594limit=100
so down to 57 errors. There are a few themes:
* linux-yocto 3.14 gcc5 issues
* meta-fsl-ppc and metafsl-arm gcc5 issues, particularly kernel
* poky-lsb issues with the security flags and gcc5
* x32 failed with a race of some kind in glibc, suspect transient
* gcc-target has a packaging issue which fails builds (have patch)
The good news is that the various ppc issues are fixed including the rpm
one from this series.
Have you tried arm64?
kernel did not build ( as of last week) and I have not yet tried the
kernel patches Khem pointed out.
- armin
Ross: The backports we were looking at are for warnings, not errors on
the most part.
Otavio: Could you see what our options are with meta-fsl-ppc and
metafsl-arm?
Cheers,
Richard
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] gcc5: Add PR65779 patch to fix powerpc compile issues
On May 12, 2015, at 12:28 AM, Richard Purdie richard.pur...@linuxfoundation.org wrote: On Mon, 2015-05-11 at 17:24 -0700, Khem Raj wrote: On Mon, May 11, 2015 at 4:20 PM, akuster808 akuster...@gmail.com wrote: On 05/11/2015 09:54 AM, Richard Purdie wrote: This fixes compile issues on powerpc with gcc 5 which show up with errors like: | make[2]: Entering directory '/media/build1/poky/build/tmp/work/ppc7400-poky-linux/xprop/1_1.2.2-r0/build' | powerpc-poky-linux-gcc -m32 -mhard-float -mcpu=7400 --sysroot=/media/build1/poky/build/tmp/sysroots/qemuppc -Wall -Wpointer-arith -Wmissing-declarations -Wformat=2 -Wstrict-prototypes -Wmissing-prototypes -Wnested-externs -Wbad-function-cast -Wold-style-definition -Wdeclaration-after-statement -Wunused -Wuninitialized -Wshadow -Wmissing-noreturn -Wmissing-format-attribute -Wredundant-decls -Wlogical-op -Werror=implicit -Werror=nonnull -Werror=init-self -Werror=main -Werror=missing-braces -Werror=sequence-point -Werror=return-type -Werror=trigraphs -Werror=array-bounds -Werror=write-strings -Werror=address -Werror=int-to-pointer-cast -Werror=pointer-to-int-cast -fno-strict-aliasing -O2 -pipe -g -feliminate-unused-debug-types -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed -o xprop dsimple.o clientwin.o xprop.o -lX11 | /media/build1/poky/build/tmp/sysroots/qemuppc/usr/lib/../lib/libX11.so: undefined reference to `.LCL2' | collect2: error: ld returned 1 exit status Signed-off-by: Richard Purdie richard.pur...@linuxfoundation.org Acked-by: Armin Kuster akuster...@gmail.com this fixes all but one package(lzop) failure on qemuppc base yocto world build. I am fine witj this patch for now, since we are mostly build testing, we have to keep in mind its a codegen bug and can bite us at runtime. I am just hoping for an update to this patch and that will eliminate that doubt. Agreed, an update upstream would obviously help. FWIW the automated runtime tests did look reasonable on the autobuilder apart from: core-image-sato-sdk has a problem with the C++ toolchain not finding limits (all arches). hmm thats interesting. Can you point to an error for more details ? qemuarm is not booting (minimal, sato or sato-sdk). yes I have had problems with linux-yocto on emulator too. However these issues were present before the patch so I don't think its related. right Since the failures list is better with the patch I'll merge it until something better comes along. thats OK signature.asc Description: Message signed with OpenPGP using GPGMail -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] rpm: fix build issue with gcc5
On May 12, 2015, at 7:57 AM, Otavio Salvador ota...@ossystems.com.br wrote: On Tue, May 12, 2015 at 4:06 AM, Richard Purdie richard.pur...@linuxfoundation.org wrote: On Sun, 2015-05-10 at 23:03 +0100, Richard Purdie wrote: ... Otavio: Could you see what our options are with meta-fsl-ppc and metafsl-arm? Yes. I foresee some challenges especially the old kernels. fsl-arm has 2.6.35 for some platforms and fsl-ppc has 3.12. Most of gcc5 issues are already addressed in kernel upstream so it might be that you need few back ports. but going back to 2.6.x might be daunting. There might be a lot to deal with I am adding FSL people to also take a look on these failures. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 signature.asc Description: Message signed with OpenPGP using GPGMail -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/6] devtool: improve handling of local source files
Hi Markus, On Thursday 30 April 2015 12:16:06 Markus Lehtonen wrote: This patchset tries to improve handling of local source files (i.e. file:// in SRC_URI). First, it improves packages for which S=WORKDIR (that possibly only have local sources. Second, it makes local sources available in the srctree for all packages. See yocto bug #7602 I've finally looked at these, apologies for the delay. Some comments: * I don't think we really want the local files to become part of the git repository by default - they shouldn't be committed. Once users have finished with devtool, we want them to be able to push the source tree to their own repo and point to that within the recipe, whilst keeping the local files next to the recipe. * This implies that new files added to the local files dir when we do devtool update-recipe should not be added as a patch, they should be copied next to the recipe and added to SRC_URI. I'm more than happy for us to implement this separately as a follow-up (i.e. we could start by not handling adding files to the local files directory at all.) * The local-files directory needs to be named specific to OE - oe-local-files would be ideal. If we could have one place in the code where this was defined that would be ideal as well (maybe at some point we'd allow it to be configured). Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] meta/lib/oe/utils.py: properly implement both_contain()
On Tue, May 12, 2015 at 1:40 AM, Paul Eggleton paul.eggle...@linux.intel.com wrote: Hi Andre, On Monday 11 May 2015 17:34:45 Andre McCurdy wrote: On Wed, Feb 25, 2015 at 7:15 AM, Cristian Iorga cristian.io...@intel.com wrote: oe.utils.both_contain() just does a find() on the value rather than splitting the value and then looking in the list of split items. The result is that if you add a feature to MACHINE_FEATURES that itself has a substring that matches one of the values looked for when building COMBINED_FEATURES, you end up with an incomprehensible error (here with ext2i in MACHINE_FEATURES): ERROR: Nothing RPROVIDES 'packagegroup-base-ext2' (but /home/balister/src/oe-core/oe-core/meta/recipes-core/ /packagegroups/packagegroup-base.bb RDEPENDS on or otherwise requires it) This change seems to break COMBINED_FEATURES. $ bitbake -e packagegroup-base | grep '^COMBINED_FEATURES=' dizzy: COMBINED_FEATURES=alsa fido: COMBINED_FEATURES=set(['alsa']) Yes it did, unfortunately. There was a follow-up fix in master: http://cgit.openembedded.org/openembedded-core/commit/?id=c4ca9dbd4191fcff08e75035e3d276490ed80b05 This is included in Joshua's pending backport changeset for fido. I see it now. Thanks Paul. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH V3 1/2] populate_sdk_ext: install the latest buildtools-tarball
On May 11, 2015, at 11:19 PM, Chen Qi qi.c...@windriver.com wrote:
- 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}
why not create a symink instead of poking using wild chars
signature.asc
Description: Message signed with OpenPGP using GPGMail
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 4/8] kernel: Pull uImage generation into separate class
On Tuesday 12 May 2015 11:38:14 Bruce Ashfield wrote:
On 2015-05-12 10:15 AM, Paul Eggleton wrote:
On Monday 04 May 2015 23:41:47 Marek Vasut wrote:
On Tuesday, April 28, 2015 at 11:16:17 PM, Marek Vasut wrote:
On Tuesday, April 28, 2015 at 08:44:54 PM, Bruce Ashfield wrote:
On 2015-04-28 12:38 PM, Marek Vasut wrote:
Pull the uImage image format generation from kernel.bbclass into
a separate kernel-uimage.bbclass. The recipes which now need to
generate an uImage will have to inherit kernel-uimage instead of
kernel class.
Signed-off-by: Marek Vasut ma...@denx.de
Cc: Richard Purdie richard.pur...@linuxfoundation.org
Cc: Koen Kooi k...@dominion.thruhere.net
Cc: Paul Eggleton paul.eggle...@linux.intel.com
Cc: Ross Burton ross.bur...@intel.com
Cc: Bruce Ashfield bruce.ashfi...@windriver.com
---
meta/classes/kernel-uimage.bbclass | 48
+ meta/classes/kernel.bbclass
| 55 +++--- 2 files changed, 58
insertions(+), 45 deletions(-)
create mode 100644 meta/classes/kernel-uimage.bbclass
NOTE: The inherit kernel-uimage in kernel.bbclass should be changed
to
something like inherit kernel-${@d.getVar(KERNEL_IMAGETYPE,
True).lower()} but the problem is that I only want to perform
the inheritance for uimage and fitimage, the other image types
don't need to inherit any additional special stuff.
Paul suggested I can do inherit empty here. This would at
least let me implement a python function which returns either
kernel-uimage, kernel-fitimage or and based on that, I
could inherit the particular image type specifics into
kernel.bbclass.
What I don't know how to implement well is this function which
returns those three strings based on the KERNEL_IMAGETYPE.
What
I would like to avoid is encoding those strings explicitly
into
the function, since that would force each new kernel image
format to also edit this function in kernel.bbclass .
Apparently, checking whether class exists and inheriting it
only if it does is also not a simple task.
Agreed that this would be better. It would remove a lot of the checks
in the other tasks for the image type.
Hi!
Yes, that's indeed true. All the image type checks would disappear from
kernel-uimage and kernel-fitimage bbclasses.
I'm not aware of the exact details on how to make this work, but
hopefully others have the foo.
Any ideas please ?
To me this is about how we wish to structure these classes. That's not my
call, but to enumerate the options - unless I'm missing something we have
to choose between:
1) Hardcode uimage/fitimage. Hard to extend.
2) inherit kernel-type and just insist that a class for every image type
exists. Ugly and kernel-*.bbclass already exists.
3) Try to search for a kernel-type class and inherit it if one is found.
AFAIK we don't do this kind of thing anywhere else so this doesn't seem
right to me.
4) Establish some other mechanism for registering kernel image type
classes
(KERNEL_CLASSES ?). Not sure if we want to do this but it is at least a
common mechanism elsewhere in the system.
I wasn't familiar with an option like this, but if we can do something
for the kernel classes that follows the existing patterns .. it makes
a lot of sense. I really don't want to invent something new here either.
So something along the lines of the way that image.bbclass works with
the IMAGE_CLASSES ?
Indeed, that's what I was referring to.
Cheers,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] gcc5: Add back g++ sysroot patch
On May 12, 2015, at 5:02 AM, Richard Purdie
richard.pur...@linuxfoundation.org wrote:
Without this, g++/c++ compilation doesn't work on target due to missing
header files. Automated sanity tests fail. Add back the gcc4 patch to
address this.
ah thanks for this. I was about to start looking at it.
Signed-off-by: Richard Purdie richard.pur...@linuxfoundation.org
diff --git a/meta/recipes-devtools/gcc/gcc-5.1.inc
b/meta/recipes-devtools/gcc/gcc-5.1.inc
index 305736b..1d64f9e 100644
--- a/meta/recipes-devtools/gcc/gcc-5.1.inc
+++ b/meta/recipes-devtools/gcc/gcc-5.1.inc
@@ -69,6 +69,7 @@ SRC_URI = \
file://0035-Dont-link-the-plugins-with-libgomp-explicitly.patch \
file://0036-Use-SYSTEMLIBS_DIR-replacement-instead-of-hardcoding.patch \
file://0037-pr65779.patch \
+ file://0038-fix-g++-sysroot.patch \
#S = ${TMPDIR}/work-shared/gcc-${PV}-${PR}/gcc-${SNAP}
diff --git a/meta/recipes-devtools/gcc/gcc-5.1/0038-fix-g++-sysroot.patch
b/meta/recipes-devtools/gcc/gcc-5.1/0038-fix-g++-sysroot.patch
new file mode 100644
index 000..f024dd5
--- /dev/null
+++ b/meta/recipes-devtools/gcc/gcc-5.1/0038-fix-g++-sysroot.patch
@@ -0,0 +1,44 @@
+Portions of
+
+http://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg26013.html
+
+are not upstreamed yet. So lets keep missing pieces.
+
+Upstream-Status: Pending
+
+Without this, compiling something simple like #include limits on target
+with c++ test.cpp fails unable to find the header. strace shows it looking in
+usr/include/ rather than /usr/include/
+
+Signed-off-by: Khem Raj raj.k...@gmail.com
+
+Index: gcc-4.8.1/gcc/configure.ac
+===
+--- gcc-4.8.1.orig/gcc/configure.ac 2013-07-15 15:55:49.488399132 -0700
gcc-4.8.1/gcc/configure.ac 2013-07-15 16:02:31.772406679 -0700
+@@ -148,7 +148,9 @@
+ if test ${with_sysroot+set} = set; then
+ gcc_gxx_without_sysroot=`expr ${gcc_gxx_include_dir} :
${with_sysroot}'\(.*\)'`
+ if test ${gcc_gxx_without_sysroot}; then
+-gcc_gxx_include_dir=${gcc_gxx_without_sysroot}
++if test x${with_sysroot} != x/; then
++ gcc_gxx_include_dir=${gcc_gxx_without_sysroot}
++fi
+ gcc_gxx_include_dir_add_sysroot=1
+ fi
+ fi
+Index: gcc-4.8.1/gcc/configure
+===
+--- gcc-4.8.1.orig/gcc/configure 2013-07-15 15:55:49.472399132 -0700
gcc-4.8.1/gcc/configure 2013-07-15 16:02:31.780406680 -0700
+@@ -3325,7 +3325,9 @@
+ if test ${with_sysroot+set} = set; then
+ gcc_gxx_without_sysroot=`expr ${gcc_gxx_include_dir} :
${with_sysroot}'\(.*\)'`
+ if test ${gcc_gxx_without_sysroot}; then
+-gcc_gxx_include_dir=${gcc_gxx_without_sysroot}
++if test x${with_sysroot} != x/; then
++ gcc_gxx_include_dir=${gcc_gxx_without_sysroot}
++fi
+ gcc_gxx_include_dir_add_sysroot=1
+ fi
+ fi
signature.asc
Description: Message signed with OpenPGP using GPGMail
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [master/fido][PATCH] lttng-modules: Update to stable version 2.6.1
This fixes a build issue with the 3.19.5 kernel where the regmap prototypes
have changed. The patch is rebased do to changes in the new version of the
Makefile.
[YOCTO #7737]
Signed-off-by: Saul Wold s...@linux.intel.com
---
...modules-replace-KERNELDIR-with-KERNEL_SRC.patch | 31 +-
...tng-modules_2.6.0.bb = lttng-modules_2.6.1.bb} | 2 +-
2 files changed, 19 insertions(+), 14 deletions(-)
rename meta/recipes-kernel/lttng/{lttng-modules_2.6.0.bb =
lttng-modules_2.6.1.bb} (96%)
diff --git
a/meta/recipes-kernel/lttng/lttng-modules/lttng-modules-replace-KERNELDIR-with-KERNEL_SRC.patch
b/meta/recipes-kernel/lttng/lttng-modules/lttng-modules-replace-KERNELDIR-with-KERNEL_SRC.patch
index bbfa38a..ccc6c54 100644
---
a/meta/recipes-kernel/lttng/lttng-modules/lttng-modules-replace-KERNELDIR-with-KERNEL_SRC.patch
+++
b/meta/recipes-kernel/lttng/lttng-modules/lttng-modules-replace-KERNELDIR-with-KERNEL_SRC.patch
@@ -7,41 +7,46 @@ build and install lttng-modules, we do this replacement for
it as-is.
Signed-off-by: Zumeng Chen zumeng.c...@windriver.com
+[sgw - rebased for 2.6.1]
+Signed-off-by: Saul wold s...@linux.intel.com
Index: git/Makefile
===
--- git.orig/Makefile
+++ git/Makefile
-@@ -62,19 +62,19 @@ obj-m += lib/
+@@ -68,19 +68,19 @@ obj-m += lib/
endif # CONFIG_TRACEPOINTS
else # KERNELRELEASE
- KERNELDIR ?= /lib/modules/$(shell uname -r)/build
+- PWD := $(shell pwd)
+- CFLAGS = $(EXTCFLAGS)
+-
+ KERNEL_SRC ?= /lib/modules/$(shell uname -r)/build
- PWD := $(shell pwd)
- CFLAGS = $(EXTCFLAGS)
-
++ PWD := $(shell pwd)
++ CFLAGS = $(EXTCFLAGS)
++
default:
-- $(MAKE) -C $(KERNELDIR) M=$(PWD) modules
-+ $(MAKE) -C $(KERNEL_SRC) M=$(PWD) modules
+- LTTNG_KERNELDIR=$(KERNELDIR) $(MAKE) -C $(KERNELDIR) M=$(PWD) modules
++ LTTNG_KERNELDIR=$(KERNEL_SRC) $(MAKE) -C $(KERNEL_SRC) M=$(PWD) modules
modules_install:
-- $(MAKE) -C $(KERNELDIR) M=$(PWD) modules_install
-+ $(MAKE) -C $(KERNEL_SRC) M=$(PWD) modules_install
+- LTTNG_KERNELDIR=$(KERNELDIR) $(MAKE) -C $(KERNELDIR) M=$(PWD)
modules_install
++ LTTNG_KERNELDIR=$(KERNEL_SRC) $(MAKE) -C $(KERNEL_SRC) M=$(PWD)
modules_install
clean:
-- $(MAKE) -C $(KERNELDIR) M=$(PWD) clean
-+ $(MAKE) -C $(KERNEL_SRC) M=$(PWD) clean
+- LTTNG_KERNELDIR=$(KERNELDIR) $(MAKE) -C $(KERNELDIR) M=$(PWD) clean
++ LTTNG_KERNELDIR=$(KERNEL_SRC) $(MAKE) -C $(KERNEL_SRC) M=$(PWD) clean
%.i: %.c
-- $(MAKE) -C $(KERNELDIR) M=$(PWD) $@
-+ $(MAKE) -C $(KERNEL_SRC) M=$(PWD) $@
+- LTTNG_KERNELDIR=$(KERNELDIR) $(MAKE) -C $(KERNELDIR) M=$(PWD) $@
++ LTTNG_KERNELDIR=$(KERNEL_SRC) $(MAKE) -C $(KERNEL_SRC) M=$(PWD) $@
endif # KERNELRELEASE
Index: git/probes/Makefile
===
--- git.orig/probes/Makefile
+++ git/probes/Makefile
-@@ -231,18 +231,18 @@ endif
+@@ -267,18 +267,18 @@ endif
endif
else
diff --git a/meta/recipes-kernel/lttng/lttng-modules_2.6.0.bb
b/meta/recipes-kernel/lttng/lttng-modules_2.6.1.bb
similarity index 96%
rename from meta/recipes-kernel/lttng/lttng-modules_2.6.0.bb
rename to meta/recipes-kernel/lttng/lttng-modules_2.6.1.bb
index 4cf01ca..9c08e9c 100644
--- a/meta/recipes-kernel/lttng/lttng-modules_2.6.0.bb
+++ b/meta/recipes-kernel/lttng/lttng-modules_2.6.1.bb
@@ -11,7 +11,7 @@ do_configure[depends] += virtual/kernel:do_shared_workdir
inherit module
-SRCREV = 1b2a5429de815c95643df2eadf91253909708728
+SRCREV = 62080b2248fd8ec4111ffc379d0bc5eaf0a5c16d
COMPATIBLE_HOST = '(x86_64|i.86|powerpc|aarch64|mips|arm).*-linux'
--
2.1.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 4/8] kernel: Pull uImage generation into separate class
On Tuesday, May 12, 2015 at 06:18:15 PM, Paul Eggleton wrote:
On Tuesday 12 May 2015 11:38:14 Bruce Ashfield wrote:
On 2015-05-12 10:15 AM, Paul Eggleton wrote:
On Monday 04 May 2015 23:41:47 Marek Vasut wrote:
On Tuesday, April 28, 2015 at 11:16:17 PM, Marek Vasut wrote:
On Tuesday, April 28, 2015 at 08:44:54 PM, Bruce Ashfield wrote:
On 2015-04-28 12:38 PM, Marek Vasut wrote:
Pull the uImage image format generation from kernel.bbclass into
a separate kernel-uimage.bbclass. The recipes which now need to
generate an uImage will have to inherit kernel-uimage instead of
kernel class.
Signed-off-by: Marek Vasut ma...@denx.de
Cc: Richard Purdie richard.pur...@linuxfoundation.org
Cc: Koen Kooi k...@dominion.thruhere.net
Cc: Paul Eggleton paul.eggle...@linux.intel.com
Cc: Ross Burton ross.bur...@intel.com
Cc: Bruce Ashfield bruce.ashfi...@windriver.com
---
meta/classes/kernel-uimage.bbclass | 48
+ meta/classes/kernel.bbclass
| 55 +++--- 2 files changed, 58
insertions(+), 45 deletions(-)
create mode 100644 meta/classes/kernel-uimage.bbclass
NOTE: The inherit kernel-uimage in kernel.bbclass should be
changed to
something like inherit
kernel-${@d.getVar(KERNEL_IMAGETYPE, True).lower()} but
the problem is that I only want to perform the inheritance
for uimage and fitimage, the other image types don't need
to inherit any additional special stuff. Paul suggested I
can do inherit empty here. This would at least let me
implement a python function which returns either
kernel-uimage, kernel-fitimage or and based on
that, I could inherit the particular image type specifics
into kernel.bbclass.
What I don't know how to implement well is this function
which returns those three strings based on the
KERNEL_IMAGETYPE. What
I would like to avoid is encoding those strings explicitly
into
the function, since that would force each new kernel image
format to also edit this function in kernel.bbclass .
Apparently, checking whether class exists and inheriting it
only if it does is also not a simple task.
Agreed that this would be better. It would remove a lot of the
checks in the other tasks for the image type.
Hi!
Yes, that's indeed true. All the image type checks would disappear
from kernel-uimage and kernel-fitimage bbclasses.
I'm not aware of the exact details on how to make this work, but
hopefully others have the foo.
Any ideas please ?
To me this is about how we wish to structure these classes. That's not
my call, but to enumerate the options - unless I'm missing something
we have to choose between:
1) Hardcode uimage/fitimage. Hard to extend.
2) inherit kernel-type and just insist that a class for every image
type exists. Ugly and kernel-*.bbclass already exists.
3) Try to search for a kernel-type class and inherit it if one is
found. AFAIK we don't do this kind of thing anywhere else so this
doesn't seem right to me.
4) Establish some other mechanism for registering kernel image type
classes
(KERNEL_CLASSES ?). Not sure if we want to do this but it is at least a
common mechanism elsewhere in the system.
I wasn't familiar with an option like this, but if we can do something
for the kernel classes that follows the existing patterns .. it makes
a lot of sense. I really don't want to invent something new here either.
So something along the lines of the way that image.bbclass works with
the IMAGE_CLASSES ?
Indeed, that's what I was referring to.
Doesn't that mean it would be possible for kernel.bbclass to inherit multiple
classes -- for example kernel-uimage.bbclass and kernel-fitimage.bbclass -- at
the same time ? Won't that make it impossible to remove the kernel type checks
in kernel-uimage.bbclass ? But maybe having those checks in place is the right
thing to do since there might be a target building both fitImage and uImage at
the same time?
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] OE Changelog since 2015-05-03 until 2015-05-10
Changelog since 2015-05-03 until 2015-05-10. Projects included in this report: bitbake: git://git.openembedded.org/bitbake openembedded-core: git://git.openembedded.org/openembedded-core meta-openembedded: git://git.openembedded.org/meta-openembedded meta-angstrom: git://github.com/Angstrom-distribution/meta-angstrom.git meta-arago: git://arago-project.org/git/meta-arago.git meta-atmel: https://github.com/linux4sam/meta-atmel.git meta-beagleboard: git://github.com/beagleboard/meta-beagleboard.git meta-browser: git://github.com/OSSystems/meta-browser.git meta-bug: git://github.com/buglabs/meta-bug.git meta-chicken: git://github.com/OSSystems/meta-chicken meta-efikamx: git://github.com/kraj/meta-efikamx.git meta-ettus: http://github.com/koenkooi/meta-ettus.git meta-fsl-arm: git://git.yoctoproject.org/meta-fsl-arm meta-fsl-arm-extra: git://github.com/Freescale/meta-fsl-arm-extra.git meta-fsl-ppc: git://git.yoctoproject.org/meta-fsl-ppc meta-guacamayo: git://github.com/Guacamayo/meta-guacamayo.git meta-gumstix: git://github.com/gumstix/meta-gumstix.git meta-gumstix-community: git://gitorious.org/schnitzeltony-oe-meta/meta-gumstix-community.git meta-handheld: git://git.openembedded.org/meta-handheld meta-igep: http://github.com/ebutera/meta-igep.git meta-intel: git://git.yoctoproject.org/meta-intel meta-ivi: git://git.yoctoproject.org/meta-ivi meta-java: git://github.com/woglinde/meta-java meta-kde: git://gitorious.org/openembedded-core-layers/meta-kde.git meta-micro: git://git.openembedded.org/meta-micro meta-mono: git://git.yoctoproject.org/meta-mono.git meta-netbookpro: git://github.com/tworaz/meta-netbookpro meta-nslu2: git://github.com/kraj/meta-nslu2 meta-opie: git://git.openembedded.org/meta-opie meta-qt3: git://git.yoctoproject.org/meta-qt3 meta-qt5: git://github.com/meta-qt5/meta-qt5.git meta-slugos: git://github.com/kraj/meta-slugos meta-systemd: git://git.yoctoproject.org/meta-systemd meta-raspberrypi: git://github.com/djwillis/meta-raspberrypi.git meta-smartphone: http://git.shr-project.org/repo/meta-smartphone.git meta-ti: git://git.yoctoproject.org/meta-ti meta-webos: git://github.com/openwebos/meta-webos.git meta-xilinx: git://git.yoctoproject.org/meta-xilinx meta-yocto: git://git.yoctoproject.org/meta-yocto openembedded: git://git.openembedded.org/openembedded Changelog for bitbake: Maxin B. John (1): prserv: serv.py: remove unused and duplicate imports Ross Burton (1): setup.py: remove Changelog for openembedded-core: Alejandro Hernandez (5): python3: Upgrade from 3.3.3 to 3.4.2 python3: Change python BASEVERSION to 3.4 python3-native: Fix pip install issue due to unclean build directory python3-native: Disable pip on native builds to fix Autobuilder issues python3: Disable pip to fix issues on the Autobuilders Andre McCurdy (1): mirrors.bbclass: drop support for svk sources Aníbal Limón (5): license_class: Reimplemented manifest creation in python license_class: Generalize license_ok function license: Split visit_string in LicenseVisitor license: Add support for handle INCOMPATIBLE_LICENSE in manifest creation license_class: license_create_manifest improvment Bruce Ashfield (4): linux-yocto/3.19: Braswell support and bug fixes linux-yocto: fix race between checkout and meta data generation linux-yocto/3.14: fix qemumips build error kernel-yocto: propagate in tree defconfigs to WORKDIR Cristian Iorga (4): connman: code cleanup connman: upgrade to 1.29 qemu: upgrade to 2.3.0 runqemu-internal: correctly set format for root FS as raw Ed Bartosh (1): kernel.bbclass: Fix race condition Joe Slater (1): distro_features_check: add any of test Jussi Kukkonen (8): shared-mime-info: Upgrade 1.3 - 1.4 xproto: Upgrade 7.0.26 - 7.0.27 randrproto: Upgrade 1.4.0 - 1.4.1 kbproto: Upgrade 1.0.6 - 1.0.7 xev: Upgrade 1.2.1 - 1.2.2 xmodmap: Upgrade 1.0.8 - 1.0.9 xhost: Upgrade 1.0.6 - 1.0.7 x11perf: Upgrade 1.5.4 - 1.6.0 Kevron Rees (1): bluez: update to 5.30 Khem Raj (4): libart-lgpl: Fix cross compiling insane: Support aarch64 on musl gcc: Add 5 recipes gcc-4.9, gcc-5: Use variable SYSTEMLIBS_DIR instead of hardcoding it for aar Maxin B. John (1): serf: update SRC_URI to use debian mirrors instead of googlecode Nathan Rossi (4): kernel-arch: Update mapping for MicroBlaze architectures insane.bbclass: Add MicroBlaze big endian target info siteinfo.bbclass: Add MicroBlaze big endian target info ghostscript: Add MicroBlaze support Patrick Ohly (1): combo-layer: improve merge commit handling Paul Eggleton (6): classes/buildstats: whitespace cleanup classes/buildstats: don't catch all errors from mkdirhier classes/buildstats: misc cleanups oe-selftest: devtool: fix broken URL in test_devtool_add_fetch devtool: fix for rename of gcc-source oe-selftest: devtool: add a proper test to see if tap
Re: [OE-core] [PATCH 4/8] kernel: Pull uImage generation into separate class
On Tuesday 12 May 2015 21:27:30 Marek Vasut wrote:
On Tuesday, May 12, 2015 at 06:18:15 PM, Paul Eggleton wrote:
On Tuesday 12 May 2015 11:38:14 Bruce Ashfield wrote:
On 2015-05-12 10:15 AM, Paul Eggleton wrote:
On Monday 04 May 2015 23:41:47 Marek Vasut wrote:
On Tuesday, April 28, 2015 at 11:16:17 PM, Marek Vasut wrote:
On Tuesday, April 28, 2015 at 08:44:54 PM, Bruce Ashfield wrote:
On 2015-04-28 12:38 PM, Marek Vasut wrote:
Pull the uImage image format generation from kernel.bbclass into
a separate kernel-uimage.bbclass. The recipes which now need to
generate an uImage will have to inherit kernel-uimage instead of
kernel class.
Signed-off-by: Marek Vasut ma...@denx.de
Cc: Richard Purdie richard.pur...@linuxfoundation.org
Cc: Koen Kooi k...@dominion.thruhere.net
Cc: Paul Eggleton paul.eggle...@linux.intel.com
Cc: Ross Burton ross.bur...@intel.com
Cc: Bruce Ashfield bruce.ashfi...@windriver.com
---
meta/classes/kernel-uimage.bbclass | 48
+ meta/classes/kernel.bbclass
| 55 +++--- 2 files changed, 58
insertions(+), 45 deletions(-)
create mode 100644 meta/classes/kernel-uimage.bbclass
NOTE: The inherit kernel-uimage in kernel.bbclass should be
changed to
something like inherit
kernel-${@d.getVar(KERNEL_IMAGETYPE, True).lower()} but
the problem is that I only want to perform the inheritance
for uimage and fitimage, the other image types don't need
to inherit any additional special stuff. Paul suggested I
can do inherit empty here. This would at least let me
implement a python function which returns either
kernel-uimage, kernel-fitimage or and based on
that, I could inherit the particular image type specifics
into kernel.bbclass.
What I don't know how to implement well is this function
which returns those three strings based on the
KERNEL_IMAGETYPE. What
I would like to avoid is encoding those strings explicitly
into
the function, since that would force each new kernel image
format to also edit this function in kernel.bbclass .
Apparently, checking whether class exists and inheriting
it
only if it does is also not a simple task.
Agreed that this would be better. It would remove a lot of the
checks in the other tasks for the image type.
Hi!
Yes, that's indeed true. All the image type checks would disappear
from kernel-uimage and kernel-fitimage bbclasses.
I'm not aware of the exact details on how to make this work, but
hopefully others have the foo.
Any ideas please ?
To me this is about how we wish to structure these classes. That's not
my call, but to enumerate the options - unless I'm missing something
we have to choose between:
1) Hardcode uimage/fitimage. Hard to extend.
2) inherit kernel-type and just insist that a class for every image
type exists. Ugly and kernel-*.bbclass already exists.
3) Try to search for a kernel-type class and inherit it if one is
found. AFAIK we don't do this kind of thing anywhere else so this
doesn't seem right to me.
4) Establish some other mechanism for registering kernel image type
classes
(KERNEL_CLASSES ?). Not sure if we want to do this but it is at least
a
common mechanism elsewhere in the system.
I wasn't familiar with an option like this, but if we can do something
for the kernel classes that follows the existing patterns .. it makes
a lot of sense. I really don't want to invent something new here either.
So something along the lines of the way that image.bbclass works with
the IMAGE_CLASSES ?
Indeed, that's what I was referring to.
Doesn't that mean it would be possible for kernel.bbclass to inherit
multiple classes -- for example kernel-uimage.bbclass and
kernel-fitimage.bbclass -- at the same time ? Won't that make it impossible
to remove the kernel type checks in kernel-uimage.bbclass ? But maybe
having those checks in place is the right thing to do since there might be
a target building both fitImage and uImage at the same time?
You will still need these checks, yes. To be honest I don't consider having
those to be a bad thing though.
Cheers,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH][V3] mmc-utils: fix the building failure when DEBUG_BUILD is 1
From: Roy Li rongqing...@windriver.com
AM_CFLAGS in Makefile includes -D_FORTIFY_SOURCE=2 which will lead
to building failure when DEBUG_BUILD is 1.
So Redefine AM_CFLAGS, input it from the environment to overrides
variable in makefile
Signed-off-by: Roy Li rongqing...@windriver.com
---
meta/recipes-devtools/mmc/mmc-utils_git.bb | 2 ++
1 file changed, 2 insertions(+)
diff --git a/meta/recipes-devtools/mmc/mmc-utils_git.bb
b/meta/recipes-devtools/mmc/mmc-utils_git.bb
index bdb4fed..d6d77d9 100644
--- a/meta/recipes-devtools/mmc/mmc-utils_git.bb
+++ b/meta/recipes-devtools/mmc/mmc-utils_git.bb
@@ -11,6 +11,8 @@ PV = 0.1
SRC_URI =
git://git.kernel.org/pub/scm/linux/kernel/git/cjb/mmc-utils.git;branch=${BRANCH}
\
file://0001-mmc.h-don-t-include-asm-generic-int-ll64.h.patch
+EXTRA_OEMAKE = 'AM_CFLAGS=-D_FILE_OFFSET_BITS=64'
+
S = ${WORKDIR}/git
do_install() {
--
2.1.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/3] xserver-xorg: disable xwayland
On 05/12/2015 10:21 PM, Burton, Ross wrote:
On 12 May 2015 at 03:42, Robert Yang liezhi.y...@windriver.com
mailto:liezhi.y...@windriver.com wrote:
Thanks, updated it in the repo:
Please check with a clean sysroot:
| checking for XWAYLANDMODULES... no
| checking whether to build Xwayland DDX... yes
| configure: error: Xwayland build explicitly requested, but required modules
not found.
Sorry, libepoxy is also required:
configure:32059: checking for XWAYLANDMODULES
configure:32066: $PKG_CONFIG --exists --print-errors wayland-client = 1.3.0
libdrm epoxy
Package epoxy was not found in the pkg-config search path.
Perhaps you should add the directory containing `epoxy.pc'
to the PKG_CONFIG_PATH environment variable
No package 'epoxy' found
I've updated it in the repo:
git://git.openembedded.org/openembedded-core-contrib rbt/3fixes
diff --git a/meta/recipes-graphics/xorg-xserver/xserver-xorg.inc
b/meta/recipes-graphics/xorg-xserver/xserver-xorg.inc
index 30299c2..3d16d3a 100644
--- a/meta/recipes-graphics/xorg-xserver/xserver-xorg.inc
+++ b/meta/recipes-graphics/xorg-xserver/xserver-xorg.inc
@@ -115,7 +115,9 @@ EXTRA_OECONF += --with-fop=no \
ac_cv_file__usr_share_sgml_X11_defs_ent=no \
-PACKAGECONFIG ??= udev ${@bb.utils.contains('DISTRO_FEATURES', 'opengl', 'dri
dri2 glx', '', d)}
+PACKAGECONFIG ??= udev ${@bb.utils.contains('DISTRO_FEATURES', 'opengl', 'dri
dri2 glx', '', d)} \
+ ${@bb.utils.contains(DISTRO_FEATURES, wayland,
xwayland, , d)} \
+
PACKAGECONFIG[udev] = --enable-config-udev,--disable-config-udev,udev
PACKAGECONFIG[dri] = --enable-dri,--disable-dri,glproto virtual/mesa
xf86driproto
@@ -128,6 +130,7 @@ PACKAGECONFIG[xshmfence] =
--enable-xshmfence,--disable-xshmfence,libxshmfence
PACKAGECONFIG[xmlto] = --with-xmlto, --without-xmlto, xmlto-native
docbook-xml-dtd4-native docbook-xsl-stylesheets-native
PACKAGECONFIG[systemd-logind] =
--enable-systemd-logind=yes,--enable-systemd-logind=no,dbus,
PACKAGECONFIG[xinerama] = --enable-xinerama,--disable-xinerama,xineramaproto
+PACKAGECONFIG[xwayland] = --enable-xwayland,--disable-xwayland,wayland
libepoxy
do_install_append () {
# Its assumed base-files creates this for us
// Robert
Ross
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] unzip: Security Advisory -CVE-2014-9636 and CVE-2015-1315
From: Roy Li rongqing...@windriver.com
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-9636
unzip 6.0 allows remote attackers to cause a denial of service
(out-of-bounds read or write and crash) via an extra field with
an uncompressed size smaller than the compressed field size in a
zip archive that advertises STORED method compression.
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2015-1315
Buffer overflow in the charset_to_intern function in unix/unix.c in
Info-Zip UnZip 6.10b allows remote attackers to execute arbitrary code
via a crafted string, as demonstrated by converting a string from CP866
to UTF-8.
Signed-off-by: Roy Li rongqing...@windriver.com
---
.../06-unzip60-alt-iconv-utf8_CVE-2015-1315.patch | 402 +
.../unzip/unzip/unzip-6.0_overflow3.diff | 45 +++
meta/recipes-extended/unzip/unzip_6.0.bb | 5 +-
3 files changed, 451 insertions(+), 1 deletion(-)
create mode 100644
meta/recipes-extended/unzip/unzip/06-unzip60-alt-iconv-utf8_CVE-2015-1315.patch
create mode 100644 meta/recipes-extended/unzip/unzip/unzip-6.0_overflow3.diff
diff --git
a/meta/recipes-extended/unzip/unzip/06-unzip60-alt-iconv-utf8_CVE-2015-1315.patch
b/meta/recipes-extended/unzip/unzip/06-unzip60-alt-iconv-utf8_CVE-2015-1315.patch
new file mode 100644
index 000..9ba3c1d
--- /dev/null
+++
b/meta/recipes-extended/unzip/unzip/06-unzip60-alt-iconv-utf8_CVE-2015-1315.patch
@@ -0,0 +1,402 @@
+From: Giovanni Scafora giovanni.archlinux.org
+Subject: unzip files encoded with non-latin, non-unicode file names
+Last-Update: 2015-02-11
+
+Upstream-Status: Backport
+
+Updated 2015-02-11 by Marc Deslauriers marc.deslauri...@canonical.com
+to fix buffer overflow in charset_to_intern()
+
+Signed-off-by: Marc Deslauriers marc.deslauri...@canonical.com
+
+Index: unzip-6.0/unix/unix.c
+===
+--- unzip-6.0.orig/unix/unix.c 2015-02-11 08:46:43.675324290 -0500
unzip-6.0/unix/unix.c 2015-02-11 09:18:04.902081319 -0500
+@@ -30,6 +30,9 @@
+ #define UNZIP_INTERNAL
+ #include unzip.h
+
++#include iconv.h
++#include langinfo.h
++
+ #ifdef SCO_XENIX
+ # define SYSNDIR
+ #else /* SCO Unix, AIX, DNIX, TI SysV, Coherent 4.x, ... */
+@@ -1874,3 +1877,102 @@
+ }
+ }
+ #endif /* QLZIP */
++
++
++typedef struct {
++char *local_charset;
++char *archive_charset;
++} CHARSET_MAP;
++
++/* A mapping of local - archive charsets used by default to convert
filenames
++ * of DOS/Windows Zip archives. Currently very basic. */
++static CHARSET_MAP dos_charset_map[] = {
++{ ANSI_X3.4-1968, CP850 },
++{ ISO-8859-1, CP850 },
++{ CP1252, CP850 },
++{ UTF-8, CP866 },
++{ KOI8-R, CP866 },
++{ KOI8-U, CP866 },
++{ ISO-8859-5, CP866 }
++};
++
++char OEM_CP[MAX_CP_NAME] = ;
++char ISO_CP[MAX_CP_NAME] = ;
++
++/* Try to guess the default value of OEM_CP based on the current locale.
++ * ISO_CP is left alone for now. */
++void init_conversion_charsets()
++{
++const char *local_charset;
++int i;
++
++/* Make a guess only if OEM_CP not already set. */
++if(*OEM_CP == '\0') {
++ local_charset = nl_langinfo(CODESET);
++ for(i = 0; i sizeof(dos_charset_map)/sizeof(CHARSET_MAP); i++)
++ if(!strcasecmp(local_charset,
dos_charset_map[i].local_charset)) {
++ strncpy(OEM_CP, dos_charset_map[i].archive_charset,
++ sizeof(OEM_CP));
++ break;
++ }
++}
++}
++
++/* Convert a string from one encoding to the current locale using iconv().
++ * Be as non-intrusive as possible. If error is encountered during covertion
++ * just leave the string intact. */
++static void charset_to_intern(char *string, char *from_charset)
++{
++iconv_t cd;
++char *s,*d, *buf;
++size_t slen, dlen, buflen;
++const char *local_charset;
++
++if(*from_charset == '\0')
++ return;
++
++buf = NULL;
++local_charset = nl_langinfo(CODESET);
++
++if((cd = iconv_open(local_charset, from_charset)) == (iconv_t)-1)
++return;
++
++slen = strlen(string);
++s = string;
++
++/* Make sure OUTBUFSIZ + 1 never ends up smaller than FILNAMSIZ
++ * as this function also gets called with G.outbuf in fileio.c
++ */
++buflen = FILNAMSIZ;
++if (OUTBUFSIZ + 1 FILNAMSIZ)
++{
++buflen = OUTBUFSIZ + 1;
++}
++
++d = buf = malloc(buflen);
++if(!d)
++ goto cleanup;
++
++bzero(buf,buflen);
++dlen = buflen - 1;
++
++if(iconv(cd, s, slen, d, dlen) == (size_t)-1)
++ goto cleanup;
++strncpy(string, buf, buflen);
++
++cleanup:
++free(buf);
++iconv_close(cd);
++}
++
++/* Convert a string from OEM_CP to the current locale charset. */
++inline void oem_intern(char *string)
++{
++charset_to_intern(string, OEM_CP);
++}
++
++/* Convert a string from ISO_CP to the current locale charset. */
++inline void
Re: [OE-core] [PATCH V3 1/2] populate_sdk_ext: install the latest buildtools-tarball
On 05/13/2015 12:19 AM, Khem Raj wrote:
On May 11, 2015, at 11:19 PM, Chen Qi qi.c...@windriver.com wrote:
- 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}
why not create a symink instead of poking using wild chars
Because it's simpler.
//Chen Qi
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH V3 1/2] populate_sdk_ext: install the latest buildtools-tarball
On May 12, 2015, at 6:45 PM, ChenQi qi.c...@windriver.com wrote:
On 05/13/2015 12:19 AM, Khem Raj wrote:
On May 11, 2015, at 11:19 PM, Chen Qi qi.c...@windriver.com wrote:
- 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}
why not create a symink instead of poking using wild chars
Because it's simpler.
what happens if I touch an older installer ?
//Chen Qi
signature.asc
Description: Message signed with OpenPGP using GPGMail
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH V3 1/2] populate_sdk_ext: install the latest buildtools-tarball
On 05/13/2015 09:56 AM, Khem Raj wrote:
On May 12, 2015, at 6:45 PM, ChenQi qi.c...@windriver.com wrote:
On 05/13/2015 12:19 AM, Khem Raj wrote:
On May 11, 2015, at 11:19 PM, Chen Qi qi.c...@windriver.com wrote:
- 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}
why not create a symink instead of poking using wild chars
Because it's simpler.
what happens if I touch an older installer ?
Hi Khem,
I make this patch to avoid installing a non-existent buildools-tarball.
If we touch an old buildtools-tarball, the installation would still
succeed. The touched one is installed.
What would lead to a potential problem is the following situation.
The user built buildtools-tarball, after one day, he modified key part
of buildtools-tarball recipe, rebuilt it, and then he deliberately
touched the old one, and then he built an ext SDK.
I don't think that's a situation we need to take care of.
But if you insist that we should, you can suggest a reasonable symlink
name and I would make a new patch.
Best Regards,
Chen Qi
//Chen Qi
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH][Resend] apt: upgrade to 1.0.9.9
From: Roy Li rongqing...@windriver.com
Upgrade to fix the several CVEs: CVE-2014-0488, CVE-2014-0490
Remove apt-0.9.9.4-CVE-2014-0478.patch, which was backport.
Romve no-ko-translation.patch, apt-1.0.9.9 has ko translation
Update use-host.patch no-curl.patch db_linking_hack.patch and
noconfigure.patch
Not build the test cases since it requires gtest
Signed-off-by: Roy Li rongqing...@windriver.com
---
.../apt-0.9.9.4/apt-0.9.9.4-CVE-2014-0478.patch| 193 -
.../apt/apt-0.9.9.4/no-ko-translation.patch| 11 --
.../disable-configure-in-makefile.patch| 0
.../apt/apt-1.0.9.9/disable-test.patch | 58 +++
.../fix-gcc-4.6-null-not-defined.patch | 0
.../{apt-0.9.9.4 = apt-1.0.9.9}/makerace.patch| 0
.../{apt-0.9.9.4 = apt-1.0.9.9}/no-nls-dpkg.patch | 0
.../{apt-0.9.9.4 = apt-1.0.9.9}/noconfigure.patch | 17 +-
.../apt/{apt-0.9.9.4 = apt-1.0.9.9}/nodoc.patch | 0
.../truncate-filename.patch| 0
.../{apt-0.9.9.4 = apt-1.0.9.9}/use-host.patch| 6 +-
...apt-native_0.9.9.4.bb = apt-native_1.0.9.9.bb} | 4 +-
meta/recipes-devtools/apt/apt.inc | 5 +-
.../apt/{apt_0.9.9.4.bb = apt_1.0.9.9.bb} | 4 +-
.../apt/files/db_linking_hack.patch| 6 +-
meta/recipes-devtools/apt/files/no-curl.patch | 8 +-
16 files changed, 83 insertions(+), 229 deletions(-)
delete mode 100644
meta/recipes-devtools/apt/apt-0.9.9.4/apt-0.9.9.4-CVE-2014-0478.patch
delete mode 100644
meta/recipes-devtools/apt/apt-0.9.9.4/no-ko-translation.patch
rename meta/recipes-devtools/apt/{apt-0.9.9.4 =
apt-1.0.9.9}/disable-configure-in-makefile.patch (100%)
create mode 100644 meta/recipes-devtools/apt/apt-1.0.9.9/disable-test.patch
rename meta/recipes-devtools/apt/{apt-0.9.9.4 =
apt-1.0.9.9}/fix-gcc-4.6-null-not-defined.patch (100%)
rename meta/recipes-devtools/apt/{apt-0.9.9.4 = apt-1.0.9.9}/makerace.patch
(100%)
rename meta/recipes-devtools/apt/{apt-0.9.9.4 =
apt-1.0.9.9}/no-nls-dpkg.patch (100%)
rename meta/recipes-devtools/apt/{apt-0.9.9.4 =
apt-1.0.9.9}/noconfigure.patch (54%)
rename meta/recipes-devtools/apt/{apt-0.9.9.4 = apt-1.0.9.9}/nodoc.patch
(100%)
rename meta/recipes-devtools/apt/{apt-0.9.9.4 =
apt-1.0.9.9}/truncate-filename.patch (100%)
rename meta/recipes-devtools/apt/{apt-0.9.9.4 = apt-1.0.9.9}/use-host.patch
(84%)
rename meta/recipes-devtools/apt/{apt-native_0.9.9.4.bb =
apt-native_1.0.9.9.bb} (55%)
rename meta/recipes-devtools/apt/{apt_0.9.9.4.bb = apt_1.0.9.9.bb} (74%)
diff --git
a/meta/recipes-devtools/apt/apt-0.9.9.4/apt-0.9.9.4-CVE-2014-0478.patch
b/meta/recipes-devtools/apt/apt-0.9.9.4/apt-0.9.9.4-CVE-2014-0478.patch
deleted file mode 100644
index 79a6897..000
--- a/meta/recipes-devtools/apt/apt-0.9.9.4/apt-0.9.9.4-CVE-2014-0478.patch
+++ /dev/null
@@ -1,193 +0,0 @@
-This patch comes from:
-https://bugs.debian.org/cgi-bin/bugreport.cgi?msg=73;filename=apt_0.9.7.9%2Bdeb7u2.debdiff;att=1;bug=749795
-
-Upstream-Status: Backport
-
-Signed-off-by: Wenlin Kang wenlin.k...@windriver.com
-Signed-off-by: Chong Lu chong...@windriver.com
-
-diff -uarN apt-0.9.9.4-org/cmdline/apt-get.cc apt-0.9.9.4/cmdline/apt-get.cc
apt-0.9.9.4-org/cmdline/apt-get.cc 2014-08-29 15:37:42.587156134 +0800
-+++ apt-0.9.9.4/cmdline/apt-get.cc 2014-08-29 15:51:16.672334086 +0800
-@@ -1046,25 +1046,8 @@
-return true;
- }
- /*}}}*/
--// CheckAuth - check if each download comes form a trusted source /*{{{*/
--// -
--/* */
--static bool CheckAuth(pkgAcquire Fetcher)
-+static bool AuthPrompt(std::string UntrustedList, bool const PromptUser)
- {
-- string UntrustedList;
-- for (pkgAcquire::ItemIterator I = Fetcher.ItemsBegin(); I
Fetcher.ItemsEnd(); ++I)
-- {
-- if (!(*I)-IsTrusted())
-- {
-- UntrustedList += string((*I)-ShortDesc()) + ;
-- }
-- }
--
-- if (UntrustedList == )
-- {
-- return true;
-- }
--
-ShowList(c2out,_(WARNING: The following packages cannot be
authenticated!),UntrustedList,);
-
-if (_config-FindB(APT::Get::AllowUnauthenticated,false) == true)
-@@ -1073,6 +1056,9 @@
- return true;
-}
-
-+ if (PromptUser == false)
-+ return _error-Error(_(Some packages could not be authenticated));
-+
-if (_config-FindI(quiet,0) 2
- _config-FindB(APT::Get::Assume-Yes,false) == false)
-{
-@@ -1090,6 +1076,28 @@
-return _error-Error(_(There are problems and -y was used without
--force-yes));
- }
- /*}}}*/
-+// CheckAuth - check if each download comes form a trusted source /*{{{*/
-+// -
-+/* */
-+static bool CheckAuth(pkgAcquire Fetcher, bool PromptUser=true)
-+{
-+ string
[OE-core] [PATCH 0/2] meta: 2 fixes
The following changes since commit 7ffe10df73cc20d10fcd41b121074445273bd60e: license_class: license_create_manifest improvment (2015-05-09 22:26:02 +0100) are available in the git repository at: git://git.openembedded.org/openembedded-core-contrib rbt/2fixes http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=rbt/2fixes Robert Yang (2): stat: fix SRC_URI openssl/orc: virtclass-native - class-native meta/recipes-connectivity/openssl/openssl.inc |2 +- meta/recipes-devtools/orc/orc_0.4.23.bb |2 +- meta/recipes-extended/stat/stat_3.3.bb|2 +- 3 files changed, 3 insertions(+), 3 deletions(-) -- 1.7.9.5 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/2] stat: fix SRC_URI
The old SRC_URI is redirected to the new one, fixed:
WARNING: Failed to fetch URL
ftp://metalab.unc.edu/pub/Linux/utils/file/stat-3.3.tar.gz, attempting MIRRORS
if available
Signed-off-by: Robert Yang liezhi.y...@windriver.com
---
meta/recipes-extended/stat/stat_3.3.bb |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-extended/stat/stat_3.3.bb
b/meta/recipes-extended/stat/stat_3.3.bb
index 6754fb8..8a19b3b 100644
--- a/meta/recipes-extended/stat/stat_3.3.bb
+++ b/meta/recipes-extended/stat/stat_3.3.bb
@@ -5,7 +5,7 @@ LICENSE = GPLv2
LIC_FILES_CHKSUM = file://COPYRIGHT;md5=39886b077fd072e876e5c4c16310b631 \
file://GPL;md5=94d55d512a9ba36caa9b7df079bae19f
-SRC_URI = ftp://metalab.unc.edu/pub/Linux/utils/file/stat-${PV}.tar.gz \
+SRC_URI = http://www.ibiblio.org/pub/Linux/utils/file/${BP}.tar.gz \
file://fix-error-return.patch
SRC_URI[md5sum] = 37e247e8e400ad9205f1b0500b728fd3
--
1.7.9.5
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/2] openssl/orc: virtclass-native - class-native
The virtclass-native is out of date.
Signed-off-by: Robert Yang liezhi.y...@windriver.com
---
meta/recipes-connectivity/openssl/openssl.inc |2 +-
meta/recipes-devtools/orc/orc_0.4.23.bb |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-connectivity/openssl/openssl.inc
b/meta/recipes-connectivity/openssl/openssl.inc
index ba9bca6..53dcfd9 100644
--- a/meta/recipes-connectivity/openssl/openssl.inc
+++ b/meta/recipes-connectivity/openssl/openssl.inc
@@ -203,7 +203,7 @@ do_install_ptest () {
install util/shlib_wrap.sh ${D}${PTEST_PATH}/util
}
-do_install_append_virtclass-native() {
+do_install_append_class-native() {
create_wrapper ${D}${bindir}/openssl \
OPENSSL_CONF=${libdir}/ssl/openssl.cnf \
SSL_CERT_DIR=${libdir}/ssl/certs \
diff --git a/meta/recipes-devtools/orc/orc_0.4.23.bb
b/meta/recipes-devtools/orc/orc_0.4.23.bb
index 0e07731..d4257c3 100644
--- a/meta/recipes-devtools/orc/orc_0.4.23.bb
+++ b/meta/recipes-devtools/orc/orc_0.4.23.bb
@@ -20,6 +20,6 @@ python populate_packages_prepend () {
do_split_packages(d, libdir, '^lib(.*)\.so\.*', 'lib%s', 'ORC %s library',
extra_depends='', allow_links=True)
}
-do_compile_prepend_virtclass-native () {
+do_compile_prepend_class-native () {
sed -i -e 's#/tmp#.#g' ${S}/orc/orccodemem.c
}
--
1.7.9.5
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 4/8] kernel: Pull uImage generation into separate class
On Tuesday, May 12, 2015 at 10:57:11 PM, Paul Eggleton wrote: [...] To me this is about how we wish to structure these classes. That's not my call, but to enumerate the options - unless I'm missing something we have to choose between: 1) Hardcode uimage/fitimage. Hard to extend. 2) inherit kernel-type and just insist that a class for every image type exists. Ugly and kernel-*.bbclass already exists. 3) Try to search for a kernel-type class and inherit it if one is found. AFAIK we don't do this kind of thing anywhere else so this doesn't seem right to me. 4) Establish some other mechanism for registering kernel image type classes (KERNEL_CLASSES ?). Not sure if we want to do this but it is at least a common mechanism elsewhere in the system. I wasn't familiar with an option like this, but if we can do something for the kernel classes that follows the existing patterns .. it makes a lot of sense. I really don't want to invent something new here either. So something along the lines of the way that image.bbclass works with the IMAGE_CLASSES ? Indeed, that's what I was referring to. Doesn't that mean it would be possible for kernel.bbclass to inherit multiple classes -- for example kernel-uimage.bbclass and kernel-fitimage.bbclass -- at the same time ? Won't that make it impossible to remove the kernel type checks in kernel-uimage.bbclass ? But maybe having those checks in place is the right thing to do since there might be a target building both fitImage and uImage at the same time? You will still need these checks, yes. To be honest I don't consider having those to be a bad thing though. I am not very fond of such blanket if, it certainly doesn't look very nice and it looks confusingly redundant especially if the image type implementation is in it's own dedicated class. But if you consider this OK, I will thus try and implement the KERNEL_IMAGE_CLASSES (that might be a better name) approach. OK ? Best regards, Marek Vasut -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] python3: Upgrade from 3.4.2 to 3.4.3
On Tue, May 12, 2015 at 03:09:50PM +, Alejandro Hernandez wrote: Modifies: python3-native_3.4.2.bb - python3-native_3.4.3.bb: Updates checksums, LICENSE did not change, dates were updated. python3_3.4.2.bb - python3_3.4.3.bb: Updates checksums, LICENSE did not change, dates were updated. generate-manifest-3.4.py: fixes asyncio and net-tools. python-3.4-manifest.inc: fixes asyncio and net-tools. This upgrade contains a fix for CVE-2014-9365. There is still that textrel issue I've reported earlier: python3-3.4.2: ELF binary '/home/jenkins/oe/world/shr-core/tmp-glibc/work/i586-oe-linux/python3/3.4.2-r1.0/packages-split/python3-audio/usr/lib/python3.4/lib-dynload/ossaudiodev.cpython-34m.so' has relocations in .text [textrel] python3-3.4.2: ELF binary '/home/jenkins/oe/world/shr-core/tmp-glibc/work/i586-oe-linux/python3/3.4.2-r1.0/packages-split/python3-codecs/usr/lib/python3.4/lib-dynload/_codecs_cn.cpython-34m.so' has relocations in .text [textrel] python3-3.4.2: ELF binary '/home/jenkins/oe/world/shr-core/tmp-glibc/work/i586-oe-linux/python3/3.4.2-r1.0/packages-split/python3-core/usr/lib/python3.4/lib-dynload/binascii.cpython-34m.so' has relocations in .text [textrel] python3-3.4.2: ELF binary '/home/jenkins/oe/world/shr-core/tmp-glibc/work/i586-oe-linux/python3/3.4.2-r1.0/packages-split/python3-crypt/usr/lib/python3.4/lib-dynload/_sha256.cpython-34m.so' has relocations in .text [textrel] python3-3.4.2: ELF binary '/home/jenkins/oe/world/shr-core/tmp-glibc/work/i586-oe-linux/python3/3.4.2-r1.0/packages-split/python3-ctypes/usr/lib/python3.4/lib-dynload/_ctypes.cpython-34m.so' has relocations in .text [textrel] python3-3.4.2: ELF binary '/home/jenkins/oe/world/shr-core/tmp-glibc/work/i586-oe-linux/python3/3.4.2-r1.0/packages-split/python3-curses/usr/lib/python3.4/lib-dynload/_curses.cpython-34m.so' has relocations in .text [textrel] python3-3.4.2: ELF binary '/home/jenkins/oe/world/shr-core/tmp-glibc/work/i586-oe-linux/python3/3.4.2-r1.0/packages-split/python3-elementtree/usr/lib/python3.4/lib-dynload/_elementtree.cpython-34m.so' has relocations in .text [textrel] python3-3.4.2: ELF binary '/home/jenkins/oe/world/shr-core/tmp-glibc/work/i586-oe-linux/python3/3.4.2-r1.0/packages-split/python3-fcntl/usr/lib/python3.4/lib-dynload/fcntl.cpython-34m.so' has relocations in .text [textrel] python3-3.4.2: ELF binary '/home/jenkins/oe/world/shr-core/tmp-glibc/work/i586-oe-linux/python3/3.4.2-r1.0/packages-split/python3-gdbm/usr/lib/python3.4/lib-dynload/_gdbm.cpython-34m.so' has relocations in .text [textrel] python3-3.4.2: ELF binary '/home/jenkins/oe/world/shr-core/tmp-glibc/work/i586-oe-linux/python3/3.4.2-r1.0/packages-split/python3-io/usr/lib/python3.4/lib-dynload/_socket.cpython-34m.so' has relocations in .text [textrel] python3-3.4.2: ELF binary '/home/jenkins/oe/world/shr-core/tmp-glibc/work/i586-oe-linux/python3/3.4.2-r1.0/packages-split/python3-json/usr/lib/python3.4/lib-dynload/_json.cpython-34m.so' has relocations in .text [textrel] python3-3.4.2: ELF binary '/home/jenkins/oe/world/shr-core/tmp-glibc/work/i586-oe-linux/python3/3.4.2-r1.0/packages-split/python3-lang/usr/lib/python3.4/lib-dynload/_bisect.cpython-34m.so' has relocations in .text [textrel] python3-3.4.2: ELF binary '/home/jenkins/oe/world/shr-core/tmp-glibc/work/i586-oe-linux/python3/3.4.2-r1.0/packages-split/python3-math/usr/lib/python3.4/lib-dynload/cmath.cpython-34m.so' has relocations in .text [textrel] python3-3.4.2: ELF binary '/home/jenkins/oe/world/shr-core/tmp-glibc/work/i586-oe-linux/python3/3.4.2-r1.0/packages-split/python3-mmap/usr/lib/python3.4/lib-dynload/mmap.cpython-34m.so' has relocations in .text [textrel] python3-3.4.2: ELF binary '/home/jenkins/oe/world/shr-core/tmp-glibc/work/i586-oe-linux/python3/3.4.2-r1.0/packages-split/python3-multiprocessing/usr/lib/python3.4/lib-dynload/_multiprocessing.cpython-34m.so' has relocations in .text [textrel] python3-3.4.2: ELF binary '/home/jenkins/oe/world/shr-core/tmp-glibc/work/i586-oe-linux/python3/3.4.2-r1.0/packages-split/python3-profile/usr/lib/python3.4/lib-dynload/_lsprof.cpython-34m.so' has relocations in .text [textrel] python3-3.4.2: ELF binary '/home/jenkins/oe/world/shr-core/tmp-glibc/work/i586-oe-linux/python3/3.4.2-r1.0/packages-split/python3-readline/usr/lib/python3.4/lib-dynload/readline.cpython-34m.so' has relocations in .text [textrel] python3-3.4.2: ELF binary '/home/jenkins/oe/world/shr-core/tmp-glibc/work/i586-oe-linux/python3/3.4.2-r1.0/packages-split/python3-resource/usr/lib/python3.4/lib-dynload/resource.cpython-34m.so' has relocations in .text [textrel] python3-3.4.2: ELF binary '/home/jenkins/oe/world/shr-core/tmp-glibc/work/i586-oe-linux/python3/3.4.2-r1.0/packages-split/python3-syslog/usr/lib/python3.4/lib-dynload/syslog.cpython-34m.so' has relocations in .text [textrel] python3-3.4.2: ELF binary
[OE-core] [PATCH 1/1] python3: Upgrade from 3.4.2 to 3.4.3
Modifies:
python3-native_3.4.2.bb - python3-native_3.4.3.bb: Updates checksums, LICENSE
did not change,
dates were updated.
python3_3.4.2.bb - python3_3.4.3.bb: Updates checksums, LICENSE did not change,
dates were updated.
generate-manifest-3.4.py: fixes asyncio and net-tools.
python-3.4-manifest.inc: fixes asyncio and net-tools.
This upgrade contains a fix for CVE-2014-9365.
Signed-off-by: Alejandro Hernandez alejandro.hernan...@linux.intel.com
---
meta/recipes-devtools/python/python-3.4-manifest.inc | 12
.../{python3-native_3.4.2.bb = python3-native_3.4.3.bb} | 7 +++
.../python/{python3_3.4.2.bb = python3_3.4.3.bb}| 6 +++---
scripts/contrib/python/generate-manifest-3.4.py | 5 -
4 files changed, 18 insertions(+), 12 deletions(-)
rename meta/recipes-devtools/python/{python3-native_3.4.2.bb =
python3-native_3.4.3.bb} (89%)
rename meta/recipes-devtools/python/{python3_3.4.2.bb = python3_3.4.3.bb}
(97%)
diff --git a/meta/recipes-devtools/python/python-3.4-manifest.inc
b/meta/recipes-devtools/python/python-3.4-manifest.inc
index f051373..28885a9 100644
--- a/meta/recipes-devtools/python/python-3.4-manifest.inc
+++ b/meta/recipes-devtools/python/python-3.4-manifest.inc
@@ -5,14 +5,18 @@
-PROVIDES+=${PN}-2to3 ${PN}-audio ${PN}-codecs ${PN}-compile ${PN}-compression
${PN}-core ${PN}-crypt ${PN}-ctypes ${PN}-curses ${PN}-datetime ${PN}-db
${PN}-debugger ${PN}-dev ${PN}-difflib ${PN}-distutils
${PN}-distutils-staticdev ${PN}-doctest ${PN}-elementtree ${PN}-email
${PN}-fcntl ${PN}-gdbm ${PN}-html ${PN}-idle ${PN}-image ${PN}-importlib
${PN}-io ${PN}-json ${PN}-lang ${PN}-logging ${PN}-mailbox ${PN}-math
${PN}-mime ${PN}-mmap ${PN}-multiprocessing ${PN}-netclient ${PN}-netserver
${PN}-numbers ${PN}-pickle ${PN}-pkgutil ${PN}-pprint ${PN}-profile ${PN}-pydoc
${PN}-re ${PN}-readline ${PN}-reprlib ${PN}-resource ${PN}-robotparser
${PN}-shell ${PN}-smtpd ${PN}-sqlite3 ${PN}-sqlite3-tests ${PN}-stringold
${PN}-subprocess ${PN}-syslog ${PN}-terminal ${PN}-tests ${PN}-textutils
${PN}-threading ${PN}-tkinter ${PN}-unittest ${PN}-unixadmin ${PN}-xml
${PN}-xmlrpc
+PROVIDES+=${PN}-2to3 ${PN}-asyncio ${PN}-audio ${PN}-codecs ${PN}-compile
${PN}-compression ${PN}-core ${PN}-crypt ${PN}-ctypes ${PN}-curses
${PN}-datetime ${PN}-db ${PN}-debugger ${PN}-dev ${PN}-difflib ${PN}-distutils
${PN}-distutils-staticdev ${PN}-doctest ${PN}-elementtree ${PN}-email
${PN}-fcntl ${PN}-gdbm ${PN}-html ${PN}-idle ${PN}-image ${PN}-importlib
${PN}-io ${PN}-json ${PN}-lang ${PN}-logging ${PN}-mailbox ${PN}-math
${PN}-mime ${PN}-mmap ${PN}-multiprocessing ${PN}-netclient ${PN}-netserver
${PN}-numbers ${PN}-pickle ${PN}-pkgutil ${PN}-pprint ${PN}-profile ${PN}-pydoc
${PN}-re ${PN}-readline ${PN}-reprlib ${PN}-resource ${PN}-robotparser
${PN}-shell ${PN}-smtpd ${PN}-sqlite3 ${PN}-sqlite3-tests ${PN}-stringold
${PN}-subprocess ${PN}-syslog ${PN}-terminal ${PN}-tests ${PN}-textutils
${PN}-threading ${PN}-tkinter ${PN}-unittest ${PN}-unixadmin ${PN}-xml
${PN}-xmlrpc
-PACKAGES=${PN}-dbg ${PN}-2to3 ${PN}-audio ${PN}-codecs ${PN}-compile
${PN}-compression ${PN}-core ${PN}-crypt ${PN}-ctypes ${PN}-curses
${PN}-datetime ${PN}-db ${PN}-debugger ${PN}-dev ${PN}-difflib
${PN}-distutils-staticdev ${PN}-distutils ${PN}-doctest ${PN}-elementtree
${PN}-email ${PN}-fcntl ${PN}-gdbm ${PN}-html ${PN}-idle ${PN}-image
${PN}-importlib ${PN}-io ${PN}-json ${PN}-lang ${PN}-logging ${PN}-mailbox
${PN}-math ${PN}-mime ${PN}-mmap ${PN}-multiprocessing ${PN}-netclient
${PN}-netserver ${PN}-numbers ${PN}-pickle ${PN}-pkgutil ${PN}-pprint
${PN}-profile ${PN}-pydoc ${PN}-re ${PN}-readline ${PN}-reprlib ${PN}-resource
${PN}-robotparser ${PN}-shell ${PN}-smtpd ${PN}-sqlite3 ${PN}-sqlite3-tests
${PN}-stringold ${PN}-subprocess ${PN}-syslog ${PN}-terminal ${PN}-tests
${PN}-textutils ${PN}-threading ${PN}-tkinter ${PN}-unittest ${PN}-unixadmin
${PN}-xml ${PN}-xmlrpc ${PN}-modules
+PACKAGES=${PN}-dbg ${PN}-2to3 ${PN}-asyncio ${PN}-audio ${PN}-codecs
${PN}-compile ${PN}-compression ${PN}-core ${PN}-crypt ${PN}-ctypes
${PN}-curses ${PN}-datetime ${PN}-db ${PN}-debugger ${PN}-dev ${PN}-difflib
${PN}-distutils-staticdev ${PN}-distutils ${PN}-doctest ${PN}-elementtree
${PN}-email ${PN}-fcntl ${PN}-gdbm ${PN}-html ${PN}-idle ${PN}-image
${PN}-importlib ${PN}-io ${PN}-json ${PN}-lang ${PN}-logging ${PN}-mailbox
${PN}-math ${PN}-mime ${PN}-mmap ${PN}-multiprocessing ${PN}-netclient
${PN}-netserver ${PN}-numbers ${PN}-pickle ${PN}-pkgutil ${PN}-pprint
${PN}-profile ${PN}-pydoc ${PN}-re ${PN}-readline ${PN}-reprlib ${PN}-resource
${PN}-robotparser ${PN}-shell ${PN}-smtpd ${PN}-sqlite3 ${PN}-sqlite3-tests
${PN}-stringold ${PN}-subprocess ${PN}-syslog ${PN}-terminal ${PN}-tests
${PN}-textutils ${PN}-threading ${PN}-tkinter ${PN}-unittest ${PN}-unixadmin
${PN}-xml ${PN}-xmlrpc ${PN}-modules
SUMMARY_${PN}-2to3=Python automated Python 2 to 3 code translator
Re: [OE-core] [PATCH 4/8] kernel: Pull uImage generation into separate class
On Wednesday 13 May 2015 00:18:07 Marek Vasut wrote: On Tuesday, May 12, 2015 at 10:57:11 PM, Paul Eggleton wrote: [...] To me this is about how we wish to structure these classes. That's not my call, but to enumerate the options - unless I'm missing something we have to choose between: 1) Hardcode uimage/fitimage. Hard to extend. 2) inherit kernel-type and just insist that a class for every image type exists. Ugly and kernel-*.bbclass already exists. 3) Try to search for a kernel-type class and inherit it if one is found. AFAIK we don't do this kind of thing anywhere else so this doesn't seem right to me. 4) Establish some other mechanism for registering kernel image type classes (KERNEL_CLASSES ?). Not sure if we want to do this but it is at least a common mechanism elsewhere in the system. I wasn't familiar with an option like this, but if we can do something for the kernel classes that follows the existing patterns .. it makes a lot of sense. I really don't want to invent something new here either. So something along the lines of the way that image.bbclass works with the IMAGE_CLASSES ? Indeed, that's what I was referring to. Doesn't that mean it would be possible for kernel.bbclass to inherit multiple classes -- for example kernel-uimage.bbclass and kernel-fitimage.bbclass -- at the same time ? Won't that make it impossible to remove the kernel type checks in kernel-uimage.bbclass ? But maybe having those checks in place is the right thing to do since there might be a target building both fitImage and uImage at the same time? You will still need these checks, yes. To be honest I don't consider having those to be a bad thing though. I am not very fond of such blanket if, it certainly doesn't look very nice and it looks confusingly redundant especially if the image type implementation is in it's own dedicated class. But if you consider this OK, I will thus try and implement the KERNEL_IMAGE_CLASSES (that might be a better name) approach. OK ? I think this is the best (or perhaps least worst) approach. KERNEL_CLASSES probably would be a better name - there's nothing inherently image type specific to this, we're just going to inherit its value. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] python3: Upgrade from 3.4.2 to 3.4.3
On 12/05/15 17:30, Martin Jansa wrote: On Tue, May 12, 2015 at 03:09:50PM +, Alejandro Hernandez wrote: Modifies: python3-native_3.4.2.bb - python3-native_3.4.3.bb: Updates checksums, LICENSE did not change, dates were updated. python3_3.4.2.bb - python3_3.4.3.bb: Updates checksums, LICENSE did not change, dates were updated. generate-manifest-3.4.py: fixes asyncio and net-tools. python-3.4-manifest.inc: fixes asyncio and net-tools. This upgrade contains a fix for CVE-2014-9365. There is still that textrel issue I've reported earlier: python3-3.4.2: ELF binary '/home/jenkins/oe/world/shr-core/tmp-glibc/work/i586-oe-linux/python3/3.4.2-r1.0/packages-split/python3-audio/usr/lib/python3.4/lib-dynload/ossaudiodev.cpython-34m.so' has relocations in .text [textrel] python3-3.4.2: ELF binary '/home/jenkins/oe/world/shr-core/tmp-glibc/work/i586-oe-linux/python3/3.4.2-r1.0/packages-split/python3-codecs/usr/lib/python3.4/lib-dynload/_codecs_cn.cpython-34m.so' has relocations in .text [textrel] python3-3.4.2: ELF binary '/home/jenkins/oe/world/shr-core/tmp-glibc/work/i586-oe-linux/python3/3.4.2-r1.0/packages-split/python3-core/usr/lib/python3.4/lib-dynload/binascii.cpython-34m.so' has relocations in .text [textrel] python3-3.4.2: ELF binary '/home/jenkins/oe/world/shr-core/tmp-glibc/work/i586-oe-linux/python3/3.4.2-r1.0/packages-split/python3-crypt/usr/lib/python3.4/lib-dynload/_sha256.cpython-34m.so' has relocations in .text [textrel] python3-3.4.2: ELF binary '/home/jenkins/oe/world/shr-core/tmp-glibc/work/i586-oe-linux/python3/3.4.2-r1.0/packages-split/python3-ctypes/usr/lib/python3.4/lib-dynload/_ctypes.cpython-34m.so' has relocations in .text [textrel] python3-3.4.2: ELF binary '/home/jenkins/oe/world/shr-core/tmp-glibc/work/i586-oe-linux/python3/3.4.2-r1.0/packages-split/python3-curses/usr/lib/python3.4/lib-dynload/_curses.cpython-34m.so' has relocations in .text [textrel] python3-3.4.2: ELF binary '/home/jenkins/oe/world/shr-core/tmp-glibc/work/i586-oe-linux/python3/3.4.2-r1.0/packages-split/python3-elementtree/usr/lib/python3.4/lib-dynload/_elementtree.cpython-34m.so' has relocations in .text [textrel] python3-3.4.2: ELF binary '/home/jenkins/oe/world/shr-core/tmp-glibc/work/i586-oe-linux/python3/3.4.2-r1.0/packages-split/python3-fcntl/usr/lib/python3.4/lib-dynload/fcntl.cpython-34m.so' has relocations in .text [textrel] python3-3.4.2: ELF binary '/home/jenkins/oe/world/shr-core/tmp-glibc/work/i586-oe-linux/python3/3.4.2-r1.0/packages-split/python3-gdbm/usr/lib/python3.4/lib-dynload/_gdbm.cpython-34m.so' has relocations in .text [textrel] python3-3.4.2: ELF binary '/home/jenkins/oe/world/shr-core/tmp-glibc/work/i586-oe-linux/python3/3.4.2-r1.0/packages-split/python3-io/usr/lib/python3.4/lib-dynload/_socket.cpython-34m.so' has relocations in .text [textrel] python3-3.4.2: ELF binary '/home/jenkins/oe/world/shr-core/tmp-glibc/work/i586-oe-linux/python3/3.4.2-r1.0/packages-split/python3-json/usr/lib/python3.4/lib-dynload/_json.cpython-34m.so' has relocations in .text [textrel] python3-3.4.2: ELF binary '/home/jenkins/oe/world/shr-core/tmp-glibc/work/i586-oe-linux/python3/3.4.2-r1.0/packages-split/python3-lang/usr/lib/python3.4/lib-dynload/_bisect.cpython-34m.so' has relocations in .text [textrel] python3-3.4.2: ELF binary '/home/jenkins/oe/world/shr-core/tmp-glibc/work/i586-oe-linux/python3/3.4.2-r1.0/packages-split/python3-math/usr/lib/python3.4/lib-dynload/cmath.cpython-34m.so' has relocations in .text [textrel] python3-3.4.2: ELF binary '/home/jenkins/oe/world/shr-core/tmp-glibc/work/i586-oe-linux/python3/3.4.2-r1.0/packages-split/python3-mmap/usr/lib/python3.4/lib-dynload/mmap.cpython-34m.so' has relocations in .text [textrel] python3-3.4.2: ELF binary '/home/jenkins/oe/world/shr-core/tmp-glibc/work/i586-oe-linux/python3/3.4.2-r1.0/packages-split/python3-multiprocessing/usr/lib/python3.4/lib-dynload/_multiprocessing.cpython-34m.so' has relocations in .text [textrel] python3-3.4.2: ELF binary '/home/jenkins/oe/world/shr-core/tmp-glibc/work/i586-oe-linux/python3/3.4.2-r1.0/packages-split/python3-profile/usr/lib/python3.4/lib-dynload/_lsprof.cpython-34m.so' has relocations in .text [textrel] python3-3.4.2: ELF binary '/home/jenkins/oe/world/shr-core/tmp-glibc/work/i586-oe-linux/python3/3.4.2-r1.0/packages-split/python3-readline/usr/lib/python3.4/lib-dynload/readline.cpython-34m.so' has relocations in .text [textrel] python3-3.4.2: ELF binary '/home/jenkins/oe/world/shr-core/tmp-glibc/work/i586-oe-linux/python3/3.4.2-r1.0/packages-split/python3-resource/usr/lib/python3.4/lib-dynload/resource.cpython-34m.so' has relocations in .text [textrel] python3-3.4.2: ELF binary '/home/jenkins/oe/world/shr-core/tmp-glibc/work/i586-oe-linux/python3/3.4.2-r1.0/packages-split/python3-syslog/usr/lib/python3.4/lib-dynload/syslog.cpython-34m.so' has relocations in .text [textrel] python3-3.4.2: ELF binary
[OE-core] [PATCH] gcc5: Add back g++ sysroot patch
Without this, g++/c++ compilation doesn't work on target due to missing
header files. Automated sanity tests fail. Add back the gcc4 patch to
address this.
Signed-off-by: Richard Purdie richard.pur...@linuxfoundation.org
diff --git a/meta/recipes-devtools/gcc/gcc-5.1.inc
b/meta/recipes-devtools/gcc/gcc-5.1.inc
index 305736b..1d64f9e 100644
--- a/meta/recipes-devtools/gcc/gcc-5.1.inc
+++ b/meta/recipes-devtools/gcc/gcc-5.1.inc
@@ -69,6 +69,7 @@ SRC_URI = \
file://0035-Dont-link-the-plugins-with-libgomp-explicitly.patch \
file://0036-Use-SYSTEMLIBS_DIR-replacement-instead-of-hardcoding.patch \
file://0037-pr65779.patch \
+ file://0038-fix-g++-sysroot.patch \
#S = ${TMPDIR}/work-shared/gcc-${PV}-${PR}/gcc-${SNAP}
diff --git a/meta/recipes-devtools/gcc/gcc-5.1/0038-fix-g++-sysroot.patch
b/meta/recipes-devtools/gcc/gcc-5.1/0038-fix-g++-sysroot.patch
new file mode 100644
index 000..f024dd5
--- /dev/null
+++ b/meta/recipes-devtools/gcc/gcc-5.1/0038-fix-g++-sysroot.patch
@@ -0,0 +1,44 @@
+Portions of
+
+http://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg26013.html
+
+are not upstreamed yet. So lets keep missing pieces.
+
+Upstream-Status: Pending
+
+Without this, compiling something simple like #include limits on target
+with c++ test.cpp fails unable to find the header. strace shows it looking in
+usr/include/ rather than /usr/include/
+
+Signed-off-by: Khem Raj raj.k...@gmail.com
+
+Index: gcc-4.8.1/gcc/configure.ac
+===
+--- gcc-4.8.1.orig/gcc/configure.ac2013-07-15 15:55:49.488399132 -0700
gcc-4.8.1/gcc/configure.ac 2013-07-15 16:02:31.772406679 -0700
+@@ -148,7 +148,9 @@
+ if test ${with_sysroot+set} = set; then
+ gcc_gxx_without_sysroot=`expr ${gcc_gxx_include_dir} :
${with_sysroot}'\(.*\)'`
+ if test ${gcc_gxx_without_sysroot}; then
+-gcc_gxx_include_dir=${gcc_gxx_without_sysroot}
++if test x${with_sysroot} != x/; then
++ gcc_gxx_include_dir=${gcc_gxx_without_sysroot}
++fi
+ gcc_gxx_include_dir_add_sysroot=1
+ fi
+ fi
+Index: gcc-4.8.1/gcc/configure
+===
+--- gcc-4.8.1.orig/gcc/configure 2013-07-15 15:55:49.472399132 -0700
gcc-4.8.1/gcc/configure2013-07-15 16:02:31.780406680 -0700
+@@ -3325,7 +3325,9 @@
+ if test ${with_sysroot+set} = set; then
+ gcc_gxx_without_sysroot=`expr ${gcc_gxx_include_dir} :
${with_sysroot}'\(.*\)'`
+ if test ${gcc_gxx_without_sysroot}; then
+-gcc_gxx_include_dir=${gcc_gxx_without_sysroot}
++if test x${with_sysroot} != x/; then
++ gcc_gxx_include_dir=${gcc_gxx_without_sysroot}
++fi
+ gcc_gxx_include_dir_add_sysroot=1
+ fi
+ fi
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] gcc: Fix packaging for gcc v5
Fixes:
ERROR: QA Issue: gcc: Files/directories were installed but not shipped in any
package:
/usr/bin/i586-poky-linux-gcov-tool
with gcc v5.x
Signed-off-by: Richard Purdie richard.pur...@linuxfoundation.org
diff --git a/meta/recipes-devtools/gcc/gcc-target.inc
b/meta/recipes-devtools/gcc/gcc-target.inc
index e348517..47fe1b6 100644
--- a/meta/recipes-devtools/gcc/gcc-target.inc
+++ b/meta/recipes-devtools/gcc/gcc-target.inc
@@ -83,7 +83,7 @@ FILES_cpp = \
${libexecdir}/gcc/${TARGET_SYS}/${BINV}/cc1
FILES_cpp-symlinks = ${bindir}/cpp
-FILES_gcov = ${bindir}/${TARGET_PREFIX}gcov
+FILES_gcov = ${bindir}/${TARGET_PREFIX}gcov*
FILES_gcov-symlinks = ${bindir}/gcov
FILES_g++ = \
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] systemd.bbclass: drop has_exactly_one_service setting
On 11 May 2015 at 20:51, Dmitry Eremin-Solenikov dmitry_ere...@mentor.com wrote: The has_exactly_one_service variable was used in now deleted code. Drop this part to make code cleaner. Really thought I fixed this a few months ago... obviously not! Ross -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [RESEND][PATCH 1/3] meta: add new qemuarma9 machine definition
On 11 May 2015 at 20:52, Dmitry Eremin-Solenikov dmitry_ere...@mentor.com wrote: Currently qemuarm is limited to 256 Mb of RAM. Sometimes this is too little to run necessary applications. Add a new arm configuration based on Versatile Express board, Cortex-A9 CPU, allowing up to 1Gb of RAM. Not sure I'm keen on oe-core having two almost-identical qemuarm machines. Why not just change the qemuarm machine to use the A9? Ross -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH V4 3/3] systemd: split modules into packages
* Bruno Bottazzini bruno.bottazz...@intel.com [150511 20:03]:
diff --git a/meta/recipes-core/systemd/systemd_219.bb
b/meta/recipes-core/systemd/systemd_219.bb
index 6ed4fe0..e83601f 100644
--- a/meta/recipes-core/systemd/systemd_219.bb
+++ b/meta/recipes-core/systemd/systemd_219.bb
@@ -19,7 +19,18 @@ PROVIDES = udev
PE = 1
-DEPENDS = kmod docbook-sgml-dtd-4.1-native intltool-native gperf-native acl
readline dbus libcap libcgroup glib-2.0 qemu-native util-linux
+DEPENDS = intltool-native \
+ gperf-native \
+ readline \
+ libcgroup \
+ libcap \
+ qemu-native \
+ ${@bb.utils.contains('PACKAGECONFIG', 'dbus', 'dbus', '', d)} \
+ ${@bb.utils.contains('PACKAGECONFIG', 'kmod', 'kmod', '', d)} \
+ ${@bb.utils.contains('PACKAGECONFIG', 'manpages',
'docbook-sgml-dtd-4.1-native', '', d)} \
+ ${@bb.utils.contains('PACKAGECONFIG', 'acl', 'acl', '', d)} \
+ ${@bb.utils.contains('PACKAGECONFIG', 'glib', 'glib-2.0', '', d)}
\
+ ${@bb.utils.contains('PACKAGECONFIG', 'blkid', 'util-linux', '',
d)}
These lines should be removed. The 3rd parameter in the PACKAGECONFIG[]
definitions below, do automatically get added to DEPENDS if the
respective PACKAGECONFIG is enabled. Thus, you don't need to check for
it yourself in DEPENDS.
Cheers,
Anders
--
Anders Darander
ChargeStorm AB / eStorm AB
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 4/8] kernel: Pull uImage generation into separate class
On Monday 04 May 2015 23:41:47 Marek Vasut wrote:
On Tuesday, April 28, 2015 at 11:16:17 PM, Marek Vasut wrote:
On Tuesday, April 28, 2015 at 08:44:54 PM, Bruce Ashfield wrote:
On 2015-04-28 12:38 PM, Marek Vasut wrote:
Pull the uImage image format generation from kernel.bbclass into
a separate kernel-uimage.bbclass. The recipes which now need to
generate an uImage will have to inherit kernel-uimage instead of
kernel class.
Signed-off-by: Marek Vasut ma...@denx.de
Cc: Richard Purdie richard.pur...@linuxfoundation.org
Cc: Koen Kooi k...@dominion.thruhere.net
Cc: Paul Eggleton paul.eggle...@linux.intel.com
Cc: Ross Burton ross.bur...@intel.com
Cc: Bruce Ashfield bruce.ashfi...@windriver.com
---
meta/classes/kernel-uimage.bbclass | 48
+ meta/classes/kernel.bbclass
| 55 +++--- 2 files changed, 58
insertions(+), 45 deletions(-)
create mode 100644 meta/classes/kernel-uimage.bbclass
NOTE: The inherit kernel-uimage in kernel.bbclass should be changed
to
something like inherit kernel-${@d.getVar(KERNEL_IMAGETYPE,
True).lower()} but the problem is that I only want to perform
the inheritance for uimage and fitimage, the other image types
don't need to inherit any additional special stuff.
Paul suggested I can do inherit empty here. This would at
least let me implement a python function which returns either
kernel-uimage, kernel-fitimage or and based on that, I
could inherit the particular image type specifics into
kernel.bbclass.
What I don't know how to implement well is this function which
returns those three strings based on the KERNEL_IMAGETYPE. What
I would like to avoid is encoding those strings explicitly into
the function, since that would force each new kernel image
format to also edit this function in kernel.bbclass .
Apparently, checking whether class exists and inheriting it
only if it does is also not a simple task.
Agreed that this would be better. It would remove a lot of the checks
in the other tasks for the image type.
Hi!
Yes, that's indeed true. All the image type checks would disappear from
kernel-uimage and kernel-fitimage bbclasses.
I'm not aware of the exact details on how to make this work, but
hopefully others have the foo.
Any ideas please ?
To me this is about how we wish to structure these classes. That's not my
call, but to enumerate the options - unless I'm missing something we have to
choose between:
1) Hardcode uimage/fitimage. Hard to extend.
2) inherit kernel-type and just insist that a class for every image type
exists. Ugly and kernel-*.bbclass already exists.
3) Try to search for a kernel-type class and inherit it if one is found.
AFAIK we don't do this kind of thing anywhere else so this doesn't seem right
to me.
4) Establish some other mechanism for registering kernel image type classes
(KERNEL_CLASSES ?). Not sure if we want to do this but it is at least a common
mechanism elsewhere in the system.
Cheers,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/3] xserver-xorg: disable xwayland
On 12 May 2015 at 03:42, Robert Yang liezhi.y...@windriver.com wrote: Thanks, updated it in the repo: Please check with a clean sysroot: | checking for XWAYLANDMODULES... no | checking whether to build Xwayland DDX... yes | configure: error: Xwayland build explicitly requested, but required modules not found. Ross -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] native.bbclass: avoid unintended substring replacement when setting PROVIDES
On Tue, May 12, 2015 at 11:03 AM, Mario Domenech Goulart ma...@ossystems.com.br wrote: The way native_virtclass_handler was implemented leaded to unintended substring replacements when setting PROVIDES for native providers, in case the original PROVIDES value contains providees with common substrings. Here's a practical case where the old behavior was problematic: the oracle-jse-jdk-x86-64 recipe provides both virtual/java and virtual/javac: Before: $ bitbake -e oracle-jse-jdk-x86-64-native | grep ^PROVIDES= PROVIDES=oracle-jse-jdk-x86-64-native virtual/java-native virtual/java-nativec After: $ bitbake -e oracle-jse-jdk-x86-64-native | grep ^PROVIDES= PROVIDES=oracle-jse-jdk-x86-64-native virtual/java-native virtual/javac-native Change-Id: I8186992dae58e37c2a2364586360ff9b7da9198f Signed-off-by: Mario Domenech Goulart ma...@ossystems.com.br Acked-by: Otavio Salvador ota...@ossystems.com.br -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] README: add Contributing section
* Mario Domenech Goulart ma...@ossystems.com.br [150512 16:58]: +Contributing + + +To contribute to this layer you should submit the patches for +review to the mailing list (openembedded-core@lists.openembedded.org). + +Please refer to: +http://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines +for some useful guidelines to be followed when submitting patches. + +Mailing list: + +http://lists.openembedded.org/mailman/listinfo/openembedded-core + +Source code: + +http://git.openembedded.org/openembedded-core/ + +When sending patches, please use something like: + +git send-email --to openembedded-core@lists.openembedded.org patches Maybe we could add something about the helper scripts: scripts/create-pull-request scripts/send-pull-request or do you think that those scripts might be out of scope for the primary intended audience of this section? Cheers, Anders -- Anders Darander ChargeStorm AB / eStorm AB -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/2] lttng-tools: separate B and S
On 12 May 2015 at 03:13, Robert Yang liezhi.y...@windriver.com wrote: It works well with autotools now. I'm not sure about that: packages/corei7-64-poky-linux/lttng-tools/lttng-tools-ptest: FILELIST: removed /usr/lib/lttng-tools/ptest/tests/utils/testapp/gen-ust-nevents/gen-ust-nevents /usr/lib/lttng-tools/ptest/tests/unit/Makefile /usr/lib/lttng-tools/ptest/tests/unit/test_ust_data.o /usr/lib/lttng-tools/ptest/tests/regression/ust/linking/tp3.o /usr/lib/lttng-tools/ptest/tests/regression/tools/live/.libs/.debug/live_test /usr/lib/lttng-tools/ptest/tests/regression/tools/health/.libs/.debug/libhealthtpfail.so /usr/lib/lttng-tools/ptest/tests/regression/ust/linking/tp.lo /usr/lib/lttng-tools/ptest/tests/regression/ust/linking/demo-demo.o /usr/lib/lttng-tools/ptest/tests/utils/testapp/gen-ust-tracef/Makefile /usr/lib/lttng-tools/ptest/tests/regression/tools/mi/validate_xml-validate_xml.o /usr/lib/lttng-tools/ptest/tests/utils/tap/.libs/libtap.la /usr/lib/lttng-tools/ptest/tests/regression/ust/exit-fast/exit-fast.o /usr/lib/lttng-tools/ptest/tests/regression/ust/overlap/demo/tp2.o /usr/lib/lttng-tools/ptest/tests/utils/testapp/Makefile /usr/lib/lttng-tools/ptest/tests/regression/tools/health/.libs/health_exit.o /usr/lib/lttng-tools/ptest/tests/regression/ust/overlap/demo/.libs/tp2.o /usr/lib/lttng-tools/ptest/tests/regression/ust/linking/demo_builtin /usr/lib/lttng-tools/ptest/tests/regression/tools/mi/.debug/extract_xml /usr/lib/lttng-tools/ptest/tests/utils/testapp/gen-ust-events/gen-ust-events.o /usr/lib/lttng-tools/ptest/tests/utils/testapp/gen-ust-nevents/.debug/gen-ust-nevents /usr/lib/lttng-tools/ptest/tests/regression/ust/multi-session/.debug/gen-nevents /usr/lib/lttng-tools/ptest/tests/regression/ust/high-throughput/gen-events /usr/lib/lttng-tools/ptest/tests/regression/tools/health/health_stall.o /usr/lib/lttng-tools/ptest/tests/utils/tap/libtap.la /usr/lib/lttng-tools/ptest/tests/regression/ust/high-throughput/tp.o /usr/lib/lttng-tools/ptest/tests/regression/ust/linking/.libs/ liblttng-ust-provider-ust-tests-demo3.la /usr/lib/lttng-tools/ptest/tests/regression/tools/health/libhealthexit.la /usr/lib/lttng-tools/ptest/tests/utils/tap/.libs/tap.o /usr/lib/lttng-tools/ptest/tests/regression/tools/health/.libs/health_stall.o /usr/lib/lttng-tools/ptest/tests/regression/ust/overlap/demo/.libs/.debug/liblttng-ust-provider-ust-tests-demo.so /usr/lib/lttng-tools/ptest/tests/regression/tools/health/health_exit.lo /usr/lib/lttng-tools/ptest/tests/utils/testapp/gen-ust-tracef/.debug/gen-ust-tracef /usr/lib/lttng-tools/ptest/tests/regression/ust/linking/.libs/tp2.o /usr/lib/lttng-tools/ptest/tests/regression/ust/overlap/demo/ liblttng-ust-provider-ust-tests-demo.la /usr/lib/lttng-tools/ptest/tests/regression/ust/linking/demo_builtin-demo.o /usr/lib/lttng-tools/ptest/tests/regression/tools/mi/extract_xml /usr/lib/lttng-tools/ptest/tests/regression/tools/health/.libs/ libhealthtpfail.la /usr/lib/lttng-tools/ptest/tests/regression/ust/overlap/demo/tp3.lo /usr/lib/lttng-tools/ptest/tests/regression/ust/overlap/demo/.libs/tp.o /usr/lib/lttng-tools/ptest/tests/regression/ust/overlap/demo/demo /usr/lib/lttng-tools/ptest/tests/regression/tools/health/.libs/libhealthtpfail.lai /usr/lib/lttng-tools/ptest/tests/regression/ust/linking/.libs/ liblttng-ust-provider-ust-tests-demo-static.la /usr/lib/lttng-tools/ptest/tests/regression/ust/high-throughput/main.o /usr/lib/lttng-tools/ptest/tests/regression/ust/overlap/demo/Makefile /usr/lib/lttng-tools/ptest/tests/regression/ust/linking/.libs/liblttng-ust-provider-ust-tests-demo3.so /usr/lib/lttng-tools/ptest/tests/regression/ust/java-jul/Makefile /usr/lib/lttng-tools/ptest/tests/utils/testapp/gen-ust-events/tp.o /usr/lib/lttng-tools/ptest/tests/regression/tools/filtering/gen-ust-events /usr/lib/lttng-tools/ptest/tests/regression/ust/daemon/daemon.o /usr/lib/lttng-tools/ptest/tests/regression/tools/health/.libs/.debug/libhealthexit.so /usr/lib/lttng-tools/ptest/tests/regression/tools/mi/extract_xml-extract_xml.o /usr/lib/lttng-tools/ptest/tests/regression/ust/linking/.libs/.debug/liblttng-ust-provider-ust-tests-demo.so /usr/lib/lttng-tools/ptest/tests/regression/ust/low-throughput/Makefile /usr/lib/lttng-tools/ptest/tests/regression/ust/linking/demo.o /usr/lib/lttng-tools/ptest/tests/regression/tools/filtering/Makefile /usr/lib/lttng-tools/ptest/tests/regression/tools/filtering/.debug/gen-ust-events /usr/lib/lttng-tools/ptest/tests/utils/testapp/gen-ust-tracef/gen-ust-tracef.o /usr/lib/lttng-tools/ptest/tests/utils/testapp/gen-ust-tracef/gen-ust-tracef /usr/lib/lttng-tools/ptest/tests/regression/ust/linking/tp2.o /usr/lib/lttng-tools/ptest/tests/regression/tools/health/.libs/ libhealthstall.la /usr/lib/lttng-tools/ptest/tests/regression/ust/overlap/demo/.libs/liblttng-ust-provider-ust-tests-demo3.lai /usr/lib/lttng-tools/ptest/tests/regression/ust/overlap/demo/tp.o /usr/lib/lttng-tools/ptest/tests/regression/tools/health/health_check.o
[OE-core] [PATCH] native.bbclass: avoid unintended substring replacement when setting PROVIDES
The way native_virtclass_handler was implemented leaded to
unintended substring replacements when setting PROVIDES for
native providers, in case the original PROVIDES value contains
providees with common substrings.
Here's a practical case where the old behavior was problematic:
the oracle-jse-jdk-x86-64 recipe provides both virtual/java and
virtual/javac:
Before:
$ bitbake -e oracle-jse-jdk-x86-64-native | grep ^PROVIDES=
PROVIDES=oracle-jse-jdk-x86-64-native virtual/java-native
virtual/java-nativec
After:
$ bitbake -e oracle-jse-jdk-x86-64-native | grep ^PROVIDES=
PROVIDES=oracle-jse-jdk-x86-64-native virtual/java-native virtual/javac-native
Change-Id: I8186992dae58e37c2a2364586360ff9b7da9198f
Signed-off-by: Mario Domenech Goulart ma...@ossystems.com.br
---
meta/classes/native.bbclass |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/meta/classes/native.bbclass b/meta/classes/native.bbclass
index 5ca5c95..1f8139b 100644
--- a/meta/classes/native.bbclass
+++ b/meta/classes/native.bbclass
@@ -151,12 +151,13 @@ python native_virtclass_handler () {
map_dependencies(RREPLACES, e.data, pkg)
provides = e.data.getVar(PROVIDES, True)
+nprovides = []
for prov in provides.split():
if prov.find(pn) != -1:
continue
if not prov.endswith(-native):
-provides = provides.replace(prov, prov + -native)
-e.data.setVar(PROVIDES, provides)
+nprovides.append(prov.replace(prov, prov + -native))
+e.data.setVar(PROVIDES, ' '.join(nprovides))
e.data.setVar(OVERRIDES, e.data.getVar(OVERRIDES, False) +
:virtclass-native)
}
--
1.7.10.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 11/11] devtool: deploy plugin: wrap long lines in code
On Monday 11 May 2015 16:17:11 Markus Lehtonen wrote:
Signed-off-by: Markus Lehtonen markus.lehto...@linux.intel.com
---
scripts/lib/devtool/deploy.py | 99
+++ 1 file changed, 72
insertions(+), 27 deletions(-)
diff --git a/scripts/lib/devtool/deploy.py b/scripts/lib/devtool/deploy.py
index 078c74b..f6ae433 100644
--- a/scripts/lib/devtool/deploy.py
+++ b/scripts/lib/devtool/deploy.py
@@ -45,17 +45,23 @@ def deploy(args, config, basepath, workspace):
deploy_dir = os.path.join(basepath, 'target_deploy', args.target)
deploy_file = os.path.join(deploy_dir, args.recipename + '.list')
-stdout, _ = exec_build_env_command(config.init_path, basepath, 'bitbake
-e %s' % args.recipename, shell=True) +stdout, _ =
exec_build_env_command(config.init_path, basepath, +
'bitbake -e %s' % args.recipename, +
shell=True)
recipe_outdir = re.search(r'^D=(.*)', stdout, re.MULTILINE).group(1)
if not os.path.exists(recipe_outdir) or not os.listdir(recipe_outdir):
-logger.error('No files to deploy - have you built the %s recipe? If
so, the install step has not installed any files.' % args.recipename) +
logger.error('No files to deploy - have you built the %s recipe? If ' +
'so, the install step has not installed any files.' % +
args.recipename)
return -1
if args.dry_run:
-print('Files to be deployed for %s on target %s:' %
(args.recipename, args.target)) +print('Files to be deployed for %s
on target %s:' %
+ (args.recipename, args.target))
for root, _, files in os.walk(recipe_outdir):
for fn in files:
-print(' %s' % os.path.join(destdir, os.path.relpath(root,
recipe_outdir), fn)) +print(' %s' % os.path.join(
+destdir, os.path.relpath(root, recipe_outdir), fn))
return 0
if os.path.exists(deploy_file):
@@ -65,12 +71,16 @@ def deploy(args, config, basepath, workspace):
extraoptions = ''
if args.no_host_check:
-extraoptions += '-o UserKnownHostsFile=/dev/null -o
StrictHostKeyChecking=no' +extraoptions += '-o
UserKnownHostsFile=/dev/null'
+extraoptions += ' -o StrictHostKeyChecking=no'
if not args.show_status:
extraoptions += ' -q'
-ret = subprocess.call('scp -r %s %s/* %s:%s' % (extraoptions,
recipe_outdir, args.target, destdir), shell=True) +ret =
subprocess.call('scp -r %s %s/* %s:%s' %
+ (extraoptions, recipe_outdir, args.target,
destdir), + shell=True)
if ret != 0:
-logger.error('Deploy failed - rerun with -s to get a complete error
message') +logger.error('Deploy failed - rerun with -s to get a
complete error ' + 'message')
return ret
logger.info('Successfully deployed %s' % recipe_outdir)
@@ -81,7 +91,8 @@ def deploy(args, config, basepath, workspace):
files_list = []
for root, _, files in os.walk(recipe_outdir):
for filename in files:
-filename = os.path.relpath(os.path.join(root, filename),
recipe_outdir) +filename = os.path.relpath(os.path.join(root,
filename), + recipe_outdir)
files_list.append(os.path.join(destdir, filename))
with open(deploy_file, 'w') as fobj:
@@ -91,13 +102,15 @@ def deploy(args, config, basepath, workspace):
def undeploy(args, config, basepath, workspace):
Entry point for the devtool 'undeploy' subcommand
-deploy_file = os.path.join(basepath, 'target_deploy', args.target,
args.recipename + '.list') +deploy_file = os.path.join(basepath,
'target_deploy', args.target, +
args.recipename + '.list')
if not os.path.exists(deploy_file):
logger.error('%s has not been deployed' % args.recipename)
return -1
if args.dry_run:
-print('Previously deployed files to be un-deployed for %s on target
%s:' % (args.recipename, args.target)) +print('Previously deployed
files to be un-deployed for %s on target ' + '%s:' %
(args.recipename, args.target))
with open(deploy_file, 'r') as f:
for line in f:
print(' %s' % line.rstrip())
@@ -105,39 +118,71 @@ def undeploy(args, config, basepath, workspace):
extraoptions = ''
if args.no_host_check:
-extraoptions += '-o UserKnownHostsFile=/dev/null -o
StrictHostKeyChecking=no' +extraoptions += '-o
UserKnownHostsFile=/dev/null '
+extraoptions += ' -o StrictHostKeyChecking=no'
if not args.show_status:
extraoptions += ' -q'
-ret = subprocess.call(scp %s %s %s:/tmp % (extraoptions, deploy_file,
args.target),
Re: [OE-core] [PATCH 2nd resend] powertop: Fix build for !uclibc - kindly respond
On 12 May 2015 at 11:48, Jens Rottmann jens.rottm...@adlinktech.com wrote: Is there anything else I should do, any additional information I need to provide, anything I did wrong? Kindly respond. If a patch is for a release branch, it's best to add eg [daisy] to the subject line so that it gets noticed. Ross -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] rpm: fix build issue with gcc5
On Tue, May 12, 2015 at 4:06 AM, Richard Purdie richard.pur...@linuxfoundation.org wrote: On Sun, 2015-05-10 at 23:03 +0100, Richard Purdie wrote: ... Otavio: Could you see what our options are with meta-fsl-ppc and metafsl-arm? Yes. I foresee some challenges especially the old kernels. fsl-arm has 2.6.35 for some platforms and fsl-ppc has 3.12. I am adding FSL people to also take a look on these failures. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2nd resend] powertop: Fix build for !uclibc - kindly respond
I am working on getting a 1.6.3 release finalized, this will be pulled
into that release and it should be going to QA this week.
Sau!
On 05/12/2015 03:48 AM, Jens Rottmann wrote:
From: Martin Jansa martin.ja...@gmail.com
Date: Thu, 18 Dec 2014 15:54:14 +0100
Subject: powertop: Fix build for !uclibc
* EXTRA_LDFLAGS isn't defined for !uclibc and configure fails
when it reads it unexpanded, see config.log snippet:
configure:4177: checking whether the C compiler works
configure:4199: i586-oe-linux-gcc -m32 -march=i586 --sysroot=/OE/sysroots/qemux86
-O2 -pipe -g -feliminate-unused-debug-types -Wl,-O1 -Wl,--hash-style=gnu
-Wl,--as-needed ${EXTRA_LDFLAGS} conftest.c 5
i586-oe-linux-gcc: error: ${EXTRA_LDFLAGS}: No such file or directory
configure:4203: $? = 1
configure:4241: result: no
Signed-off-by: Martin Jansa martin.ja...@gmail.com
Signed-off-by: Ross Burton ross.bur...@intel.com
Backported from OpenEmbedded Dizzy branch, commit
c8f9b5c9a8e5179c2013f25decd6a5483df9c716.
Signed-off-by: Jens Rottmann jens.rottm...@adlinktech.com
---
Hi Saul,
as I said, attached patch was taken/ported from OE-Core Dizzy, commit
c8f9b5c9a8e5179c2013f25decd6a5483df9c716.
Please apply it to OE-Core _Daisy_ branch, which is affected, too.
Is there anything else I should do, any additional information I need to
provide, anything I did wrong? Kindly respond.
Thanks best regards,
Jens
diff --git a/meta/recipes-kernel/powertop/powertop_2.5.bb
b/met/recipes-kernel/powertop/powertop_2.5.bb
index f37d7a7..84cca25 100644
--- a/meta/recipes-kernel/powertop/powertop_2.5.bb
+++ b/meta/recipes-kernel/powertop/powertop_2.5.bb
@@ -14,8 +14,9 @@ SRC_URI[sha256sum] =
8b2c08a555d79e1c428863470c41cb023971d74ba4801d80a05e35adee
inherit autotools gettext
# we need to explicitly link with libintl in uClibc systems
-LDFLAGS += ${EXTRA_LDFLAGS}
+EXTRA_LDFLAGS ?=
EXTRA_LDFLAGS_libc-uclibc = -lintl
+LDFLAGS += ${EXTRA_LDFLAGS}
# we do not want libncursesw if we can
do_configure_prepend() {
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [RESEND][PATCH 1/3] meta: add new qemuarma9 machine definition
On Tue, May 12, 2015 at 03:25:43PM +0100, Burton, Ross wrote: On 11 May 2015 at 20:52, Dmitry Eremin-Solenikov dmitry_ere...@mentor.com wrote: Currently qemuarm is limited to 256 Mb of RAM. Sometimes this is too little to run necessary applications. Add a new arm configuration based on Versatile Express board, Cortex-A9 CPU, allowing up to 1Gb of RAM. Not sure I'm keen on oe-core having two almost-identical qemuarm machines. Why not just change the qemuarm machine to use the A9? Then we should officially drop thumb1 support, because current qemuarm builds are quite broken when thumb is enabled and dropping current qemuarm or replacing it with A9 variant will prevent oe-core to be testable on autobuilder. See https://bugzilla.yoctoproject.org/show_bug.cgi?id=7717 -- Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] README: add Contributing section
Tips on how to submit patches. Signed-off-by: Mario Domenech Goulart ma...@ossystems.com.br --- README | 21 + 1 file changed, 21 insertions(+) diff --git a/README b/README index 665c98f..bbd7234 100644 --- a/README +++ b/README @@ -13,3 +13,24 @@ which can be found at: http://yoctoproject.org/documentation +Contributing + + +To contribute to this layer you should submit the patches for +review to the mailing list (openembedded-core@lists.openembedded.org). + +Please refer to: +http://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines +for some useful guidelines to be followed when submitting patches. + +Mailing list: + +http://lists.openembedded.org/mailman/listinfo/openembedded-core + +Source code: + +http://git.openembedded.org/openembedded-core/ + +When sending patches, please use something like: + +git send-email --to openembedded-core@lists.openembedded.org patches -- 1.7.10.4 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] oeqa/utils: Fixed a problem with get_bb_var not returning right variable.
It searches using regex now and should be more accurate.
Signed-off-by: Lucian Musat george.l.mu...@intel.com
---
meta/lib/oeqa/utils/commands.py | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/meta/lib/oeqa/utils/commands.py b/meta/lib/oeqa/utils/commands.py
index bc1dbb1..663e4e7 100644
--- a/meta/lib/oeqa/utils/commands.py
+++ b/meta/lib/oeqa/utils/commands.py
@@ -16,6 +16,7 @@ import threading
import logging
from oeqa.utils import CommandError
from oeqa.utils import ftools
+import re
class Command(object):
def __init__(self, command, bg=False, timeout=None, data=None, **options):
@@ -139,11 +140,11 @@ def get_bb_var(var, target=None, postconfig=None):
bbenv = get_bb_env(target, postconfig=postconfig)
lastline = None
for line in bbenv.splitlines():
-if line.startswith(var + =) or line.startswith(export + var +
=):
+if re.search(^(export )?%s= % var, line):
val = line.split('=')[1]
val = val.strip('\')
break
-elif line.startswith(unset + var):
+elif re.match(unset %s$ % var, line):
# Handle [unexport] variables
if lastline.startswith('# '):
val = lastline.split('\')[1]
--
2.1.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] README: add Contributing section
On Tue, May 12, 2015 at 11:58 AM, Mario Domenech Goulart ma...@ossystems.com.br wrote: Tips on how to submit patches. Signed-off-by: Mario Domenech Goulart ma...@ossystems.com.br Acked-by: Otavio Salvador ota...@ossystems.com.br -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] rpm: fix build issue with gcc5
On 12 May 2015 at 08:57, Otavio Salvador ota...@ossystems.com.br wrote: On Tue, May 12, 2015 at 4:06 AM, Richard Purdie richard.pur...@linuxfoundation.org wrote: On Sun, 2015-05-10 at 23:03 +0100, Richard Purdie wrote: ... Otavio: Could you see what our options are with meta-fsl-ppc and metafsl-arm? Yes. I foresee some challenges especially the old kernels. fsl-arm has 2.6.35 for some platforms and fsl-ppc has 3.12. I am adding FSL people to also take a look on these failures. I found one simple hack is to set the C standard to gnu89 for kernel builds. I just added KERNEL_CC_append = -std=gnu89 to my local.conf and my wandboard kernel built and booted. Haven't tried the PPC kernels yet, though. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 -- ___ 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
Re: [OE-core] [PATCH 4/8] kernel: Pull uImage generation into separate class
On 2015-05-12 10:15 AM, Paul Eggleton wrote:
On Monday 04 May 2015 23:41:47 Marek Vasut wrote:
On Tuesday, April 28, 2015 at 11:16:17 PM, Marek Vasut wrote:
On Tuesday, April 28, 2015 at 08:44:54 PM, Bruce Ashfield wrote:
On 2015-04-28 12:38 PM, Marek Vasut wrote:
Pull the uImage image format generation from kernel.bbclass into
a separate kernel-uimage.bbclass. The recipes which now need to
generate an uImage will have to inherit kernel-uimage instead of
kernel class.
Signed-off-by: Marek Vasut ma...@denx.de
Cc: Richard Purdie richard.pur...@linuxfoundation.org
Cc: Koen Kooi k...@dominion.thruhere.net
Cc: Paul Eggleton paul.eggle...@linux.intel.com
Cc: Ross Burton ross.bur...@intel.com
Cc: Bruce Ashfield bruce.ashfi...@windriver.com
---
meta/classes/kernel-uimage.bbclass | 48
+ meta/classes/kernel.bbclass
| 55 +++--- 2 files changed, 58
insertions(+), 45 deletions(-)
create mode 100644 meta/classes/kernel-uimage.bbclass
NOTE: The inherit kernel-uimage in kernel.bbclass should be changed
to
something like inherit kernel-${@d.getVar(KERNEL_IMAGETYPE,
True).lower()} but the problem is that I only want to perform
the inheritance for uimage and fitimage, the other image types
don't need to inherit any additional special stuff.
Paul suggested I can do inherit empty here. This would at
least let me implement a python function which returns either
kernel-uimage, kernel-fitimage or and based on that, I
could inherit the particular image type specifics into
kernel.bbclass.
What I don't know how to implement well is this function which
returns those three strings based on the KERNEL_IMAGETYPE. What
I would like to avoid is encoding those strings explicitly into
the function, since that would force each new kernel image
format to also edit this function in kernel.bbclass .
Apparently, checking whether class exists and inheriting it
only if it does is also not a simple task.
Agreed that this would be better. It would remove a lot of the checks
in the other tasks for the image type.
Hi!
Yes, that's indeed true. All the image type checks would disappear from
kernel-uimage and kernel-fitimage bbclasses.
I'm not aware of the exact details on how to make this work, but
hopefully others have the foo.
Any ideas please ?
To me this is about how we wish to structure these classes. That's not my
call, but to enumerate the options - unless I'm missing something we have to
choose between:
1) Hardcode uimage/fitimage. Hard to extend.
2) inherit kernel-type and just insist that a class for every image type
exists. Ugly and kernel-*.bbclass already exists.
3) Try to search for a kernel-type class and inherit it if one is found.
AFAIK we don't do this kind of thing anywhere else so this doesn't seem right
to me.
4) Establish some other mechanism for registering kernel image type classes
(KERNEL_CLASSES ?). Not sure if we want to do this but it is at least a common
mechanism elsewhere in the system.
I wasn't familiar with an option like this, but if we can do something
for the kernel classes that follows the existing patterns .. it makes
a lot of sense. I really don't want to invent something new here either.
So something along the lines of the way that image.bbclass works with
the IMAGE_CLASSES ?
Bruce
Cheers,
Paul
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
