Re: [OE-core] [RFC PATCH 0/7] Developer workflow improvements
On Friday 28 November 2014 12:28:00 Trevor Woerner wrote: These tools are really nice! Some thoughts/comments: Maybe the devtool.conf that gets created could be placed in the conf/ subdirectory (along with the other configuration files such as local.conf and bblayers.conf)? Yes, that's a good idea, I'll change that. Perhaps any recipe you're working on could be automatically included via an IMAGE_INSTALL_append in conf/local.conf (or maybe that's too intrusive?)? This is something I'd wanted to do - it's certainly something that should be made easy, but I was concerned about causing a full reparse just because of adding that to local.conf. (There might be a workaround through some sort of packagegroup for containing the packages produced by the recipes in the workspace that is added once when we create the workspace - maybe that's the answer?) Do you envision users creating multiple workspaces? I'm wondering why devtool create-workspace is required. Is there any advantage to requiring users to create the workspace explicitly instead of just having it be created implicitly? I wouldn't expect users to want to create multiple workspaces, but I did want users to be able to (a) choose where their workspace would go and (b) know that it has been created, so that the workspace layer showing up in the configuration isn't a surprise. Some of the commands to devtool include things like - extract - build - deploy - undeploy but when a workspace is created, devtool (very intelligently) adds the workspace to the set of BBLAYERS. So one could then just use bitbake to build the recipe. Are there any advantages to using devtool build recipe instead of bitbake recipe? Not at the moment, although it is a convenient shortcut for bitbake -c install recipename (which is all you need to do for devtool deploy - note that deploy is distinct from our do_deploy, it could perhaps benefit from a better name). The other reason it's there is more for use as part of the SDK where the intention is to do everything through the devtool command, although that is a usage model that isn't enabled yet. 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] gdb: disable Guile
GDB 7.8 added Guile support, and it will auto-detect if Guile is present (which
is non-deterministic, so bad), and if it's present will fail to find the guild
binary as it doesn't consider the sysroot.
For now disable Guile support in GDB, if there is a need to have it enabled in
the future then GDB/Guile can be fixed.
Signed-off-by: Ross Burton ross.bur...@intel.com
---
meta/recipes-devtools/gdb/gdb-common.inc |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-devtools/gdb/gdb-common.inc
b/meta/recipes-devtools/gdb/gdb-common.inc
index 599b405..a902f9a 100644
--- a/meta/recipes-devtools/gdb/gdb-common.inc
+++ b/meta/recipes-devtools/gdb/gdb-common.inc
@@ -38,7 +38,7 @@ EXPAT = --with-expat
--with-libexpat-prefix=${STAGING_DIR_HOST}
EXTRA_OECONF = --disable-gdbtk --disable-tui --disable-x --disable-werror \
--with-curses --disable-multilib --with-system-readline
--disable-sim \
---without-lzma \
+--without-lzma --without-guile \
${GDBPROPREFIX} ${EXPAT} \
${@bb.utils.contains('DISTRO_FEATURES', 'multiarch',
'--enable-64-bit-bfd', '', d)} \
--disable-rpath \
--
1.7.10.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCHv3] toolchain-script: Add support for ccache builds with the SDK
On Sat, Nov 29, 2014 at 8:12 PM, Burton, Ross ross.bur...@intel.com wrote: On 29 November 2014 at 08:46, Laszlo Papp lp...@kde.org wrote: Including both Richard Purdie and Saul Wold as they were the main criticizers last time in the beginning of September when I submitted the first version of this patch. I've merged this into my staging branch now that the point of the patch is clear. Thanks! Ross -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] Yocto: Install full set of python modules in Qt SDK toolchain
On 21 September 2014 at 17:02, Marek Vasut ma...@denx.de wrote:
-TOOLCHAIN_HOST_TASK ?= nativesdk-packagegroup-sdk-host
packagegroup-cross-
canadian-${MACHINE}
+TOOLCHAIN_HOST_TASK ?=\
+ nativesdk-packagegroup-sdk-host \
+ packagegroup-cross-canadian-${MACHINE} \
+ nativesdk-python-modules
Thanks to Laszlo for pinging this. We fixed a similar problem in the
buildtools tarball by pulling in python-modules but the situation was
different there - the buildtools tarball always contained some of Python so
it's logical to make it pull in all of python.
It's nativesdk-packagegroup-sdk-host that's pulling in parts of Python via
it's dependency on smartpm. This makes me think we need two changes here:
1) The toolchain should contain the packaging tools for the selected
packaging format of the images, not just smartpm. So a SDK for a
opkg-based image should be shipping opkg, not smartpm.
2) Toolchains should either ship no Python or all Python, because dropping
a partial Python into $PATH breaks user's expectations (the same argument
that was used for the buildtools). Not sure how to do this though, maybe
the construction should inspect the installed package list and if anything
Python was installed, ensure python-modules is also installed.
Comments?
Ross
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] Yocto: Install full set of python modules in Qt SDK toolchain
On Mon, 2014-12-01 at 15:05 +, Burton, Ross wrote:
On 21 September 2014 at 17:02, Marek Vasut ma...@denx.de wrote:
-TOOLCHAIN_HOST_TASK ?= nativesdk-packagegroup-sdk-host
packagegroup-cross-
canadian-${MACHINE}
+TOOLCHAIN_HOST_TASK ?=\
+ nativesdk-packagegroup-sdk-host \
+ packagegroup-cross-canadian-${MACHINE} \
+ nativesdk-python-modules
Thanks to Laszlo for pinging this. We fixed a similar problem in the
buildtools tarball by pulling in python-modules but the situation was
different there - the buildtools tarball always contained some of
Python so it's logical to make it pull in all of python.
It's nativesdk-packagegroup-sdk-host that's pulling in parts of Python
via it's dependency on smartpm. This makes me think we need two
changes here:
1) The toolchain should contain the packaging tools for the selected
packaging format of the images, not just smartpm. So a SDK for a
opkg-based image should be shipping opkg, not smartpm.
Agreed on smartpm, rpm is a bit of a different story due to where it
gets used in the packaging process. As the SDK and build systems
converge this gets a bit fuzzy :/.
2) Toolchains should either ship no Python or all Python, because
dropping a partial Python into $PATH breaks user's expectations (the
same argument that was used for the buildtools). Not sure how to do
this though, maybe the construction should inspect the installed
package list and if anything Python was installed, ensure
python-modules is also installed.
Comments?
Make nativesdk-python-core RRECOMMEND python-modules?
Cheers,
Richard
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] Yocto: Install full set of python modules in Qt SDK toolchain
On 1 December 2014 at 15:13, Richard Purdie richard.pur...@linuxfoundation.org wrote: Make nativesdk-python-core RRECOMMEND python-modules? Makes sense, and is clean. Patch incoming. Ross -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] Yocto: Install full set of python modules in Qt SDK toolchain
On Monday 01 December 2014 15:13:30 Richard Purdie wrote:
On Mon, 2014-12-01 at 15:05 +, Burton, Ross wrote:
On 21 September 2014 at 17:02, Marek Vasut ma...@denx.de wrote:
-TOOLCHAIN_HOST_TASK ?= nativesdk-packagegroup-sdk-host
packagegroup-cross-
canadian-${MACHINE}
+TOOLCHAIN_HOST_TASK ?=\
+ nativesdk-packagegroup-sdk-host \
+ packagegroup-cross-canadian-${MACHINE} \
+ nativesdk-python-modules
Thanks to Laszlo for pinging this. We fixed a similar problem in the
buildtools tarball by pulling in python-modules but the situation was
different there - the buildtools tarball always contained some of
Python so it's logical to make it pull in all of python.
It's nativesdk-packagegroup-sdk-host that's pulling in parts of Python
via it's dependency on smartpm. This makes me think we need two
changes here:
1) The toolchain should contain the packaging tools for the selected
packaging format of the images, not just smartpm. So a SDK for a
opkg-based image should be shipping opkg, not smartpm.
Agreed on smartpm, rpm is a bit of a different story due to where it
gets used in the packaging process. As the SDK and build systems
converge this gets a bit fuzzy :/.
I'm not entirely sure python-smartpm should have been added by default in the
first place. I'd say having it there ought to be the choice of the person
creating the SDK, just as with a lot of other tools one might want in the SDK.
For most people I suspect it's superfluous.
2) Toolchains should either ship no Python or all Python, because
dropping a partial Python into $PATH breaks user's expectations (the
same argument that was used for the buildtools). Not sure how to do
this though, maybe the construction should inspect the installed
package list and if anything Python was installed, ensure
python-modules is also installed.
Comments?
Make nativesdk-python-core RRECOMMEND python-modules?
This sounds like a reasonable option to me. The split as it is at the moment
exists mainly for trimming the target; the SDK is perhaps less sensitive to
size constraints.
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 1/2] python: ensure all of Python is installed in nativesdk
If any part of Python gets installed in a SDK, we need to ensure that all of
Python gets installed to avoid replacing python in the environment with a
minimal package set.
Signed-off-by: Ross Burton ross.bur...@intel.com
---
meta/recipes-devtools/python/python_2.7.3.bb |1 +
1 file changed, 1 insertion(+)
diff --git a/meta/recipes-devtools/python/python_2.7.3.bb
b/meta/recipes-devtools/python/python_2.7.3.bb
index 50c751e..7f13e22 100644
--- a/meta/recipes-devtools/python/python_2.7.3.bb
+++ b/meta/recipes-devtools/python/python_2.7.3.bb
@@ -161,6 +161,7 @@ require python-${PYTHON_MAJMIN}-manifest.inc
# manual dependency additions
RPROVIDES_${PN}-core = ${PN}
RRECOMMENDS_${PN}-core = ${PN}-readline
+RRECOMMENDS_${PN}-core_append_class-nativesdk = nativesdk-python-modules
RRECOMMENDS_${PN}-crypt = openssl
RRECOMMENDS_${PN}-crypt_class-nativesdk = nativesdk-openssl
--
1.7.10.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/2] python: remove spurious nativesdk dependency
There's no need to add a dependency on python-crypt_class-native to
nativesdk-openssl as the general dependency there is transformed appropriately.
Presumably this is cruft from back when SDK packages were suffixed instead of
prefixed, and there were mapping problems.
Signed-off-by: Ross Burton ross.bur...@intel.com
---
meta/recipes-devtools/python/python_2.7.3.bb |1 -
1 file changed, 1 deletion(-)
diff --git a/meta/recipes-devtools/python/python_2.7.3.bb
b/meta/recipes-devtools/python/python_2.7.3.bb
index 7f13e22..9ded75b 100644
--- a/meta/recipes-devtools/python/python_2.7.3.bb
+++ b/meta/recipes-devtools/python/python_2.7.3.bb
@@ -163,7 +163,6 @@ RPROVIDES_${PN}-core = ${PN}
RRECOMMENDS_${PN}-core = ${PN}-readline
RRECOMMENDS_${PN}-core_append_class-nativesdk = nativesdk-python-modules
RRECOMMENDS_${PN}-crypt = openssl
-RRECOMMENDS_${PN}-crypt_class-nativesdk = nativesdk-openssl
# package libpython2
PACKAGES =+ lib${BPN}2
--
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] Yocto: Install full set of python modules in Qt SDK toolchain
On 1 December 2014 at 15:21, Paul Eggleton paul.eggle...@linux.intel.com wrote: Make nativesdk-python-core RRECOMMEND python-modules? This sounds like a reasonable option to me. The split as it is at the moment exists mainly for trimming the target; the SDK is perhaps less sensitive to size constraints. Patch sent. Ross -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] kernel-yocto.bbclass: fix shell syntax error
Spaces aren't valid around = in an assignment statement (not even with
bash).
Signed-off-by: Paul Eggleton paul.eggle...@linux.intel.com
---
meta/classes/kernel-yocto.bbclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/classes/kernel-yocto.bbclass
b/meta/classes/kernel-yocto.bbclass
index e672a0e..c3e2494 100644
--- a/meta/classes/kernel-yocto.bbclass
+++ b/meta/classes/kernel-yocto.bbclass
@@ -212,7 +212,7 @@ do_kernel_checkout() {
machine_branch=${@ get_machine_branch(d, ${KBRANCH} )}
git show-ref --quiet --verify -- refs/heads/${machine_branch}
if [ $? -eq 0 ]; then
- machine_branch = master
+ machine_branch=master
fi
# checkout and clobber any unimportant files
--
1.9.3
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] kernel-yocto.bbclass: fix shell syntax error
On 14-12-01 12:20 PM, Paul Eggleton wrote:
Spaces aren't valid around = in an assignment statement (not even with
bash).
Signed-off-by: Paul Eggleton paul.eggle...@linux.intel.com
---
meta/classes/kernel-yocto.bbclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/classes/kernel-yocto.bbclass
b/meta/classes/kernel-yocto.bbclass
index e672a0e..c3e2494 100644
--- a/meta/classes/kernel-yocto.bbclass
+++ b/meta/classes/kernel-yocto.bbclass
@@ -212,7 +212,7 @@ do_kernel_checkout() {
machine_branch=${@ get_machine_branch(d, ${KBRANCH} )}
git show-ref --quiet --verify -- refs/heads/${machine_branch}
if [ $? -eq 0 ]; then
- machine_branch = master
+ machine_branch=master
Clearly not running very often :)
Looks good to me.
Bruce
fi
# checkout and clobber any unimportant files
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] Yocto: Install full set of python modules in Qt SDK toolchain
On Mon, Dec 1, 2014 at 4:44 PM, Burton, Ross ross.bur...@intel.com wrote: On 1 December 2014 at 15:21, Paul Eggleton paul.eggle...@linux.intel.com wrote: Make nativesdk-python-core RRECOMMEND python-modules? This sounds like a reasonable option to me. The split as it is at the moment exists mainly for trimming the target; the SDK is perhaps less sensitive to size constraints. Patch sent. Thanks! Ross -- ___ 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 1/2] python: ensure all of Python is installed in nativesdk
On Mon, Dec 1, 2014 at 4:36 PM, Ross Burton ross.bur...@intel.com wrote:
If any part of Python gets installed in a SDK, we need to ensure that all of
Python gets installed to avoid replacing python in the environment with a
minimal package set.
Signed-off-by: Ross Burton ross.bur...@intel.com
---
meta/recipes-devtools/python/python_2.7.3.bb |1 +
1 file changed, 1 insertion(+)
diff --git a/meta/recipes-devtools/python/python_2.7.3.bb
b/meta/recipes-devtools/python/python_2.7.3.bb
index 50c751e..7f13e22 100644
--- a/meta/recipes-devtools/python/python_2.7.3.bb
+++ b/meta/recipes-devtools/python/python_2.7.3.bb
@@ -161,6 +161,7 @@ require python-${PYTHON_MAJMIN}-manifest.inc
# manual dependency additions
RPROVIDES_${PN}-core = ${PN}
RRECOMMENDS_${PN}-core = ${PN}-readline
+RRECOMMENDS_${PN}-core_append_class-nativesdk = nativesdk-python-modules
RRECOMMENDS_${PN}-crypt = openssl
RRECOMMENDS_${PN}-crypt_class-nativesdk = nativesdk-openssl
--
1.7.10.4
--
Is it worth referring to bug number 6735?
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
[OE-core] [recipes-kernel][PATCH v2] powertop: update version number from 2.6.1 to 2.7
The v2.7 release of powertop fixes devfreq support for ARM, along with
other bug fixes.
Signed-off-by: Ezra Savard ezra.sav...@xilinx.com
---
meta/recipes-kernel/powertop/{powertop_2.6.1.bb = powertop_2.7.bb} | 0
1 file changed, 0 insertions(+), 0 deletions(-)
rename meta/recipes-kernel/powertop/{powertop_2.6.1.bb = powertop_2.7.bb}
(100%)
diff --git a/meta/recipes-kernel/powertop/powertop_2.6.1.bb
b/meta/recipes-kernel/powertop/powertop_2.7.bb
similarity index 100%
rename from meta/recipes-kernel/powertop/powertop_2.6.1.bb
rename to meta/recipes-kernel/powertop/powertop_2.7.bb
--
2.1.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/2] python: ensure all of Python is installed in nativesdk
On 1 December 2014 at 18:08, Laszlo Papp lp...@kde.org wrote: Is it worth referring to bug number 6735? Yes, done locally, thanks for reminding me. Ross -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [recipes-kernel][PATCH v2] powertop: update version number from 2.6.1 to 2.7
Hi, On 1 December 2014 at 18:16, Ezra Savard ezra.sav...@xilinx.com wrote: diff --git a/meta/recipes-kernel/powertop/powertop_2.6.1.bb b/meta/recipes-kernel/powertop/powertop_2.7.bb similarity index 100% The SRC_URI checksums haven't changed, so this will fail when fetching. Ross -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/3] Upgrades for comply Intel Graphics Stack Release 2014Q3
Testing was made building and running core-image-sato in qemux86, qemumips,
and qemuarm also core-image-sato/core-image-weston in Intel NUC.
Tests freedesktop piglit was run in Intel NUC with 95% of tests passes
(9251/9694), you can found full results at [1].
[YOCTO #6805]
[1] https://bugzilla.yoctoproject.org/attachment.cgi?id=2267
The following changes since commit b8631416f12b8a904ce3deb036f9d5ce632937b0:
package_regex.inc: Update REGEX'es in order to find upstream versions
correctly (2014-11-28 14:03:02 +)
are available in the git repository at:
git://git.yoctoproject.org/poky-contrib alimon/linux_intel_graphics_2014q3
http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=alimon/linux_intel_graphics_2014q3
Aníbal Limón (3):
libdrm: Upgrade to 2.4.58.
mesa: Upgrade to 10.3.3
xorg-xserver: Upgrade to 1.16.2
.../drm/libdrm/GNU_SOURCE_definition.patch | 30 --
meta/recipes-graphics/drm/libdrm_2.4.54.bb | 8 -
meta/recipes-graphics/drm/libdrm_2.4.58.bb | 7 +
.../mesa/{mesa-gl_10.1.3.bb = mesa-gl_10.3.3.bb} | 0
..._sw-include-xlib_sw_winsys.h-only-when-HA.patch | 52 ---
...ate-NativeDisplayType-depending-on-config.patch | 362 -
.../mesa/mesa/0006-fix-out-of-tree-egl.patch | 48 ---
.../mesa/{mesa_10.1.3.bb = mesa_10.3.3.bb}| 9 +-
meta/recipes-graphics/mesa/mesa_git.bb | 9 +-
.../xorg-xserver/xserver-xorg/crosscompile.patch | 22 --
.../xserver-xorg/mips64-compiler.patch | 29 --
.../xorg-xserver/xserver-xorg/present-module.patch | 66
...erver-xorg_1.15.1.bb = xserver-xorg_1.16.2.bb} | 9 +-
13 files changed, 16 insertions(+), 635 deletions(-)
delete mode 100644 meta/recipes-graphics/drm/libdrm/GNU_SOURCE_definition.patch
delete mode 100644 meta/recipes-graphics/drm/libdrm_2.4.54.bb
create mode 100644 meta/recipes-graphics/drm/libdrm_2.4.58.bb
rename meta/recipes-graphics/mesa/{mesa-gl_10.1.3.bb = mesa-gl_10.3.3.bb}
(100%)
delete mode 100644
meta/recipes-graphics/mesa/mesa/0002-pipe_loader_sw-include-xlib_sw_winsys.h-only-when-HA.patch
delete mode 100644
meta/recipes-graphics/mesa/mesa/0003-EGL-Mutate-NativeDisplayType-depending-on-config.patch
delete mode 100644
meta/recipes-graphics/mesa/mesa/0006-fix-out-of-tree-egl.patch
rename meta/recipes-graphics/mesa/{mesa_10.1.3.bb = mesa_10.3.3.bb} (62%)
delete mode 100644
meta/recipes-graphics/xorg-xserver/xserver-xorg/crosscompile.patch
delete mode 100644
meta/recipes-graphics/xorg-xserver/xserver-xorg/mips64-compiler.patch
delete mode 100644
meta/recipes-graphics/xorg-xserver/xserver-xorg/present-module.patch
rename meta/recipes-graphics/xorg-xserver/{xserver-xorg_1.15.1.bb =
xserver-xorg_1.16.2.bb} (75%)
--
1.9.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/3] libdrm: Upgrade to 2.4.58.
Remove GNU_SOURCE_definition patch because is already integrated in upstream. Signed-off-by: Aníbal Limón anibal.li...@linux.intel.com --- .../drm/libdrm/GNU_SOURCE_definition.patch | 30 -- meta/recipes-graphics/drm/libdrm_2.4.54.bb | 8 -- meta/recipes-graphics/drm/libdrm_2.4.58.bb | 7 + 3 files changed, 7 insertions(+), 38 deletions(-) delete mode 100644 meta/recipes-graphics/drm/libdrm/GNU_SOURCE_definition.patch delete mode 100644 meta/recipes-graphics/drm/libdrm_2.4.54.bb create mode 100644 meta/recipes-graphics/drm/libdrm_2.4.58.bb diff --git a/meta/recipes-graphics/drm/libdrm/GNU_SOURCE_definition.patch b/meta/recipes-graphics/drm/libdrm/GNU_SOURCE_definition.patch deleted file mode 100644 index 8eb1d5e..000 --- a/meta/recipes-graphics/drm/libdrm/GNU_SOURCE_definition.patch +++ /dev/null @@ -1,30 +0,0 @@ -uclibc headers need to know if _GNU_SOURCE is defined or not and its defined -in config.h so include it first to get the definition if its there fixed build -problems on uclibc - -test_decode.c:107:2: error: implicit declaration of function 'open_memstream' [-Werror=implicit-function-declaration] - -Signed-off-by: Khem Raj raj.k...@gmail.com -Upstream-Status: Pending - -Index: libdrm-2.4.30/intel/test_decode.c -=== libdrm-2.4.30.orig/intel/test_decode.c 2012-02-03 14:28:46.409355918 -0800 -+++ libdrm-2.4.30/intel/test_decode.c 2012-02-03 14:29:02.357356689 -0800 -@@ -21,6 +21,8 @@ - * IN THE SOFTWARE. - */ - -+#include config.h -+ - #include string.h - #include stdlib.h - #include stdio.h -@@ -31,7 +33,6 @@ - #include sys/mman.h - #include err.h - --#include config.h - #include intel_bufmgr.h - #include intel_chipset.h - diff --git a/meta/recipes-graphics/drm/libdrm_2.4.54.bb b/meta/recipes-graphics/drm/libdrm_2.4.54.bb deleted file mode 100644 index 12eefc7..000 --- a/meta/recipes-graphics/drm/libdrm_2.4.54.bb +++ /dev/null @@ -1,8 +0,0 @@ -require libdrm.inc - -SRC_URI += file://installtests.patch \ -file://GNU_SOURCE_definition.patch \ - -SRC_URI[md5sum] = 56e98a9c2073c3fab7f95e003b657f46 -SRC_URI[sha256sum] = d94001ebfbe80e1523d1228ee2df57294698d1c734fad9ccf53efde8932fe4e9 - diff --git a/meta/recipes-graphics/drm/libdrm_2.4.58.bb b/meta/recipes-graphics/drm/libdrm_2.4.58.bb new file mode 100644 index 000..e199935 --- /dev/null +++ b/meta/recipes-graphics/drm/libdrm_2.4.58.bb @@ -0,0 +1,7 @@ +require libdrm.inc + +SRC_URI += file://installtests.patch + +SRC_URI[md5sum] = 2421391d72b36c16463ed92e522a +SRC_URI[sha256sum] = b155fae6b9c9a3b02ef8b77f58c7c219194c996a4018dc55ba66c03996a365dd + -- 1.9.1 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/3] mesa: Upgrade to 10.3.3
Remove 0002-pipe_loader_sw-include-xlib_sw_winsys.h-only-when-HA,
0003-EGL-Mutate-NativeDisplayType-depending-on-config.patch and
0006-fix-out-of-tree-egl.patch that are already in upstream.
Signed-off-by: Aníbal Limón anibal.li...@linux.intel.com
---
.../mesa/{mesa-gl_10.1.3.bb = mesa-gl_10.3.3.bb} | 0
..._sw-include-xlib_sw_winsys.h-only-when-HA.patch | 52 ---
...ate-NativeDisplayType-depending-on-config.patch | 362 -
.../mesa/mesa/0006-fix-out-of-tree-egl.patch | 48 ---
.../mesa/{mesa_10.1.3.bb = mesa_10.3.3.bb}| 9 +-
meta/recipes-graphics/mesa/mesa_git.bb | 9 +-
6 files changed, 6 insertions(+), 474 deletions(-)
rename meta/recipes-graphics/mesa/{mesa-gl_10.1.3.bb = mesa-gl_10.3.3.bb}
(100%)
delete mode 100644
meta/recipes-graphics/mesa/mesa/0002-pipe_loader_sw-include-xlib_sw_winsys.h-only-when-HA.patch
delete mode 100644
meta/recipes-graphics/mesa/mesa/0003-EGL-Mutate-NativeDisplayType-depending-on-config.patch
delete mode 100644
meta/recipes-graphics/mesa/mesa/0006-fix-out-of-tree-egl.patch
rename meta/recipes-graphics/mesa/{mesa_10.1.3.bb = mesa_10.3.3.bb} (62%)
diff --git a/meta/recipes-graphics/mesa/mesa-gl_10.1.3.bb
b/meta/recipes-graphics/mesa/mesa-gl_10.3.3.bb
similarity index 100%
rename from meta/recipes-graphics/mesa/mesa-gl_10.1.3.bb
rename to meta/recipes-graphics/mesa/mesa-gl_10.3.3.bb
diff --git
a/meta/recipes-graphics/mesa/mesa/0002-pipe_loader_sw-include-xlib_sw_winsys.h-only-when-HA.patch
b/meta/recipes-graphics/mesa/mesa/0002-pipe_loader_sw-include-xlib_sw_winsys.h-only-when-HA.patch
deleted file mode 100644
index 2df5e61..000
---
a/meta/recipes-graphics/mesa/mesa/0002-pipe_loader_sw-include-xlib_sw_winsys.h-only-when-HA.patch
+++ /dev/null
@@ -1,52 +0,0 @@
-From debac5531f7107d239530ff6e29eeda72b9ec1e9 Mon Sep 17 00:00:00 2001
-From: Martin Jansa martin.ja...@gmail.com
-Date: Sat, 29 Jun 2013 11:20:51 +0200
-Subject: [PATCH 2/4] pipe_loader_sw: include xlib_sw_winsys.h only when
- HAVE_PIPE_LOADER_XLIB
-
-* HAVE_WINSYS_XLIB was removed in
- commit b3f1f665b0fef178ae193e6b111f14c9a5ad3b25
- Author: Matt Turner matts...@gmail.com
- Date: Sun Jan 20 15:32:08 2013 -0800
- build: Get rid of GALLIUM_WINSYS_DIRS
-
-* HAVE_PIPE_LOADER_XLIB is set correctly:
- if test x$NEED_WINSYS_XLIB = xyes; then
- GALLIUM_PIPE_LOADER_DEFINES=$GALLIUM_PIPE_LOADER_DEFINES
-DHAVE_PIPE_LOADER_XLIB
- GALLIUM_PIPE_LOADER_LIBS=$GALLIUM_PIPE_LOADER_LIBS
\$(top_builddir)/src/gallium/winsys/sw/xlib/libws_xlib.la
- fi
-
-* fixes build of pipe_loader_sw without libx11 headers available
-
-Upstream-Status: Submitted https://bugs.freedesktop.org/show_bug.cgi?id=66357
-Signed-off-by: Martin Jansa martin.ja...@gmail.com
- src/gallium/auxiliary/pipe-loader/pipe_loader_sw.c | 4 +++-
- 1 file changed, 3 insertions(+), 1 deletion(-)
-
-diff --git a/src/gallium/auxiliary/pipe-loader/pipe_loader_sw.c
b/src/gallium/auxiliary/pipe-loader/pipe_loader_sw.c
-index c2b78c6..0da3f4d 100644
a/src/gallium/auxiliary/pipe-loader/pipe_loader_sw.c
-+++ b/src/gallium/auxiliary/pipe-loader/pipe_loader_sw.c
-@@ -31,7 +31,9 @@
- #include util/u_dl.h
- #include sw/null/null_sw_winsys.h
- #include target-helpers/inline_sw_helper.h
-+#ifdef HAVE_PIPE_LOADER_XLIB
- #include state_tracker/xlib_sw_winsys.h
-+#endif
-
- struct pipe_loader_sw_device {
-struct pipe_loader_device base;
-@@ -44,7 +46,7 @@ struct pipe_loader_sw_device {
- static struct pipe_loader_ops pipe_loader_sw_ops;
-
- static struct sw_winsys *(*backends[])() = {
--#ifdef HAVE_WINSYS_XLIB
-+#ifdef HAVE_PIPE_LOADER_XLIB
-x11_sw_create,
- #endif
-null_sw_create
---
-1.8.2.1
-
diff --git
a/meta/recipes-graphics/mesa/mesa/0003-EGL-Mutate-NativeDisplayType-depending-on-config.patch
b/meta/recipes-graphics/mesa/mesa/0003-EGL-Mutate-NativeDisplayType-depending-on-config.patch
deleted file mode 100644
index 30a3d98..000
---
a/meta/recipes-graphics/mesa/mesa/0003-EGL-Mutate-NativeDisplayType-depending-on-config.patch
+++ /dev/null
@@ -1,362 +0,0 @@
-From 06c1ba29de8a26fffb73ee99f0fc54c704e9fee4 Mon Sep 17 00:00:00 2001
-From: Daniel Stone dan...@fooishbar.org
-Date: Fri, 24 May 2013 17:20:27 +0100
-Subject: [PATCH 3/5] EGL: Mutate NativeDisplayType depending on config
-
-If we go through ./configure without enabling X11 anywhere, then set the
-fallback types for EGL NativeDisplay and friends, rather than assuming
-X11/Xlib.
-
-Upstream-Status: Backport (slightly different solution was applied in master
-https://bugs.freedesktop.org/show_bug.cgi?id=64959)
-
-Signed-off-by: Daniel Stone dan...@fooishbar.org
-Signed-off-by: Martin Jansa martin.ja...@gmail.com
- configure.ac | 9 +++
- include/EGL/eglplatform.h| 146 ---
- include/EGL/eglplatform.h.in | 146 +++
- 3 files changed, 155 insertions(+), 146 deletions(-)
- delete mode 100644
[OE-core] [PATCH 3/3] xorg-xserver: Upgrade to 1.16.2
Remove crosscompile, mips64-compile and present-module because are already in
upstream.
Signed-off-by: Aníbal Limón anibal.li...@linux.intel.com
---
.../xorg-xserver/xserver-xorg/crosscompile.patch | 22
.../xserver-xorg/mips64-compiler.patch | 29 --
.../xorg-xserver/xserver-xorg/present-module.patch | 66 --
...erver-xorg_1.15.1.bb = xserver-xorg_1.16.2.bb} | 9 +--
4 files changed, 3 insertions(+), 123 deletions(-)
delete mode 100644
meta/recipes-graphics/xorg-xserver/xserver-xorg/crosscompile.patch
delete mode 100644
meta/recipes-graphics/xorg-xserver/xserver-xorg/mips64-compiler.patch
delete mode 100644
meta/recipes-graphics/xorg-xserver/xserver-xorg/present-module.patch
rename meta/recipes-graphics/xorg-xserver/{xserver-xorg_1.15.1.bb =
xserver-xorg_1.16.2.bb} (75%)
diff --git a/meta/recipes-graphics/xorg-xserver/xserver-xorg/crosscompile.patch
b/meta/recipes-graphics/xorg-xserver/xserver-xorg/crosscompile.patch
deleted file mode 100644
index 2f98bb8..000
--- a/meta/recipes-graphics/xorg-xserver/xserver-xorg/crosscompile.patch
+++ /dev/null
@@ -1,22 +0,0 @@
-Upstream-Status: Inappropriate [configuration]
-
-diff --git a/configure.ac b/configure.ac
-index b3b752c..600500b 100644
a/configure.ac
-+++ b/configure.ac
-@@ -523,13 +523,9 @@ dnl Uses --default-font-path if set, otherwise checks for
/etc/X11/fontpath.d,
- dnl otherwise uses standard subdirectories of FONTROOTDIR. When cross
- dnl compiling, assume default font path uses standard FONTROOTDIR directories.
-
DEFAULT_FONT_PATH=${FONTMISCDIR}/,${FONTTTFDIR}/,${FONTOTFDIR}/,${FONTTYPE1DIR}/,${FONT100DPIDIR}/,${FONT75DPIDIR}/
--if test $cross_compiling != yes; then
-- AC_CHECK_FILE([${sysconfdir}/X11/fontpath.d],
-- [DEFAULT_FONT_PATH='catalogue:${sysconfdir}/X11/fontpath.d'],
-- [case $host_os in
-+ case $host_os in
- darwin*)
DEFAULT_FONT_PATH=${DEFAULT_FONT_PATH},/Library/Fonts,/System/Library/Fonts ;;
-- esac])
--fi
-+ esac
- AC_ARG_WITH(default-font-path,
AS_HELP_STRING([--with-default-font-path=PATH], [Comma separated list of font
dirs]),
- [ FONTPATH=$withval ],
- [ FONTPATH=${DEFAULT_FONT_PATH} ])
diff --git
a/meta/recipes-graphics/xorg-xserver/xserver-xorg/mips64-compiler.patch
b/meta/recipes-graphics/xorg-xserver/xserver-xorg/mips64-compiler.patch
deleted file mode 100644
index 168368e..000
--- a/meta/recipes-graphics/xorg-xserver/xserver-xorg/mips64-compiler.patch
+++ /dev/null
@@ -1,29 +0,0 @@
-on mips64/n64 pointers are 64bit therefore the pointer conversions to int dont
work well
-so we end up with incompatible conversion errors
-
-This patch choses the right values for mips64
-
-Signed-off-by: Khem Raj raj.k...@gmail.com
-
-Upstream-Status: Pending
-Index: xorg-server-1.13.0/hw/xfree86/common/compiler.h
-===
xorg-server-1.13.0-orig/hw/xfree86/common/compiler.h 2012-06-14
23:04:29.0 +0300
-+++ xorg-server-1.13.0/hw/xfree86/common/compiler.h2012-11-08
10:06:50.865831783 +0200
-@@ -101,6 +101,7 @@
- #if defined(NO_INLINE) || defined(DO_PROTOTYPES)
- #if !defined(__arm__)
- #if !defined(__sparc__) !defined(__sparc) !defined(__arm32__)
!defined(__nds32__) \
-+ !defined(__mips64) \
-!(defined(__alpha__) defined(linux)) \
-!(defined(__ia64__) defined(linux)) \
-
-@@ -721,7 +722,7 @@
- }
-
- #elif defined(__mips__) || (defined(__arm32__) !defined(__linux__))
--#ifdef __arm32__
-+#if defined (__arm32__) || defined (__mips64)
- #define PORT_SIZE long
- #else
- #define PORT_SIZE short
diff --git
a/meta/recipes-graphics/xorg-xserver/xserver-xorg/present-module.patch
b/meta/recipes-graphics/xorg-xserver/xserver-xorg/present-module.patch
deleted file mode 100644
index 13f3caf..000
--- a/meta/recipes-graphics/xorg-xserver/xserver-xorg/present-module.patch
+++ /dev/null
@@ -1,66 +0,0 @@
-[ YOCTO #6583 ]
-
-Upstream-Status: Backport
-Signed-off-by: Ross Burton ross.bur...@intel.com
-
-From 746be5a03ebbda4ab411ca3efb2ed95f99e9ea46 Mon Sep 17 00:00:00 2001
-From: Chris Wilson ch...@chris-wilson.co.uk
-Date: Wed, 28 May 2014 08:13:59 +0100
-Subject: xfree86: Report DRI3 as a built-in module
-
-This is so that drivers can do a runtime check that DRI3 is available,
-similar to existing runtime checks performed by the drivers for DRI and
-DRI2.
-
-v2: Only add DRI3 to the list if the module was actually built into the
-server (Mark Kettenis).
-
-Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
-Cc: Mark Kettenis mark.kette...@xs4all.nl
-Signed-off-by: Keith Packard kei...@keithp.com
-
-diff --git a/hw/xfree86/loader/loadmod.c b/hw/xfree86/loader/loadmod.c
-index 092bf57..f92ad8d 100644
a/hw/xfree86/loader/loadmod.c
-+++ b/hw/xfree86/loader/loadmod.c
-@@ -838,6 +838,9 @@ static const char
[OE-core] [PATCH 1/4] base.bbclass: don't skip defaultval
This field is now internal and won't be seen.
Signed-off-by: Ross Burton ross.bur...@intel.com
---
meta/classes/base.bbclass |2 --
1 file changed, 2 deletions(-)
diff --git a/meta/classes/base.bbclass b/meta/classes/base.bbclass
index fcb7d89..f3185b4 100644
--- a/meta/classes/base.bbclass
+++ b/meta/classes/base.bbclass
@@ -347,8 +347,6 @@ python () {
extrardeps = []
extraconf = []
for flag, flagval in sorted(pkgconfigflags.items()):
-if flag == defaultval:
-continue
items = flagval.split(,)
num = len(items)
if num 4:
--
1.7.10.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 3/4] scripts: don't skip defaultval
This field is now internal and won't be seen.
Signed-off-by: Ross Burton ross.bur...@intel.com
---
scripts/contrib/list-packageconfig-flags.py |4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/scripts/contrib/list-packageconfig-flags.py
b/scripts/contrib/list-packageconfig-flags.py
index 598b5c3..2f3b8b0 100755
--- a/scripts/contrib/list-packageconfig-flags.py
+++ b/scripts/contrib/list-packageconfig-flags.py
@@ -65,7 +65,6 @@ def get_recipesdata(bbhandler, preferred):
data = bb.cache.Cache.loadDataFull(fn,
bbhandler.cooker.collection.get_file_appends(fn), bbhandler.config_data)
flags = data.getVarFlags(PACKAGECONFIG)
flags.pop('doc', None)
-flags.pop('defaultval', None)
if flags:
data_dict[fn] = data
@@ -78,7 +77,6 @@ def collect_pkgs(data_dict):
for fn in data_dict:
pkgconfigflags = data_dict[fn].getVarFlags(PACKAGECONFIG)
pkgconfigflags.pop('doc', None)
-pkgconfigflags.pop('defaultval', None)
pkgname = data_dict[fn].getVar(P, True)
pkg_dict[pkgname] = sorted(pkgconfigflags.keys())
@@ -135,7 +133,7 @@ def display_all(data_dict):
print('PACKAGECONFIG %s' % packageconfig)
for flag,flag_val in
data_dict[fn].getVarFlags(PACKAGECONFIG).iteritems():
-if flag in [defaultval, doc]:
+if flag == doc:
continue
print('PACKAGECONFIG[%s] %s' % (flag, flag_val))
print ''
--
1.7.10.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/4] Updates for defaultval being internal
Hi, This series cleans up oe-core once the bitbake patch data: rename defaultval to _defaultval is merged. Ross The following changes since commit d7bc23167154c336913739b4cf9f2efda4e61499: data: rename defaultval to _defaultval (2014-12-01 20:40:18 +) are available in the git repository at: git://git.yoctoproject.org/poky-contrib ross/defaultval for you to fetch changes up to d818f59b6da77c778d8af9f91ce1ad97dc847c2d: bitbake.conf: remove internal flags from BB_SIGNATURE_EXCLUDE_FLAGS (2014-12-01 23:42:51 +) Ross Burton (4): base.bbclass: don't skip defaultval uboot-config.bbclass: don't skip defaultval scripts: don't skip defaultval bitbake.conf: remove internal flags from BB_SIGNATURE_EXCLUDE_FLAGS meta/classes/base.bbclass |2 -- meta/classes/uboot-config.bbclass |3 --- meta/conf/bitbake.conf |2 +- scripts/contrib/list-packageconfig-flags.py |4 +--- 4 files changed, 2 insertions(+), 9 deletions(-) Ross Burton (4): base.bbclass: don't skip defaultval uboot-config.bbclass: don't skip defaultval scripts: don't skip defaultval bitbake.conf: remove internal flags from BB_SIGNATURE_EXCLUDE_FLAGS meta/classes/base.bbclass |2 -- meta/classes/uboot-config.bbclass |3 --- meta/conf/bitbake.conf |2 +- scripts/contrib/list-packageconfig-flags.py |4 +--- 4 files changed, 2 insertions(+), 9 deletions(-) -- 1.7.10.4 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 4/4] bitbake.conf: remove internal flags from BB_SIGNATURE_EXCLUDE_FLAGS
As the code that uses BB_SIGNATURE_EXCLUDE_FLAGS uses d.getVarFlags() so doesn't
get to see the internal flags, remove _append and _prepend. Also defaultval is
now _defaultval and thus internal, so remove that too.
Signed-off-by: Ross Burton ross.bur...@intel.com
---
meta/conf/bitbake.conf |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
index 0ccaac0..7902bd7 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -775,7 +775,7 @@ BB_HASHBASE_WHITELIST ?= TMPDIR FILE PATH PWD BB_TASKHASH
BBPATH DL_DIR \
BB_HASHCONFIG_WHITELIST ?= ${BB_HASHBASE_WHITELIST} DATE TIME SSH_AGENT_PID \
SSH_AUTH_SOCK PSEUDO_BUILD BB_ENV_EXTRAWHITE DISABLE_SANITY_CHECKS \
PARALLEL_MAKE BB_NUMBER_THREADS BB_ORIGENV BB_INVALIDCONF BBINCLUDED
-BB_SIGNATURE_EXCLUDE_FLAGS ?= doc defaultval _append _prepend deps depends \
+BB_SIGNATURE_EXCLUDE_FLAGS ?= doc deps depends \
lockfiles type vardepsexclude vardeps vardepvalue vardepvalueexclude \
file-checksums python func task export unexport noexec nostamp dirs
cleandirs \
sstate-lockfile-shared prefuncs postfuncs export_func deptask rdeptask \
--
1.7.10.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/4] uboot-config.bbclass: don't skip defaultval
This field is now internal and won't be seen.
Signed-off-by: Ross Burton ross.bur...@intel.com
---
meta/classes/uboot-config.bbclass |3 ---
1 file changed, 3 deletions(-)
diff --git a/meta/classes/uboot-config.bbclass
b/meta/classes/uboot-config.bbclass
index 8ac1b71..b467659 100644
--- a/meta/classes/uboot-config.bbclass
+++ b/meta/classes/uboot-config.bbclass
@@ -38,9 +38,6 @@ python () {
ubootconfig = ubootconfig[0]
for f, v in ubootconfigflags.items():
-if f == 'defaultval':
-continue
-
items = v.split(',')
if items[0] and len(items) 2:
raise bb.parse.SkipPackage('Only config,images can be specified!')
--
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 0/5] Upgrade dbus and dbus-glib
ping
//Chong
On 11/24/2014 03:49 PM, Chong Lu wrote:
The following changes since commit edaeb8940813b620090a0797ad3b6a076897512d:
bitbake: cooker.py: fix loginfo op being set to an invalid value (2014-11-12
17:04:50 +)
are available in the git repository at:
git://git.pokylinux.org/poky-contrib chonglu/dbus
http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=chonglu/dbus
Chong Lu (5):
dbus: Upgrade to 1.8.10
dbus-test: Upgrade to 1.8.10
dbus-glib: Upgrade to 0.102
connman-gnome: fix dbus interface name
upstream_tracking.inc: update entries for dbus
.../conf/distro/include/upstream_tracking.inc | 2 +-
.../connman-gnome-fix-dbus-interface-name.patch| 187 +
.../connman/connman-gnome_0.7.bb | 7 +-
.../obsolete_automake_macros.patch | 15 --
meta/recipes-core/dbus/dbus-glib.inc | 1 -
.../no-examples.patch | 0
.../test-install-makefile.patch| 57 ---
meta/recipes-core/dbus/dbus-glib_0.100.2.bb| 5 -
meta/recipes-core/dbus/dbus-glib_0.102.bb | 5 +
.../{dbus-test_1.8.2.bb = dbus-test_1.8.10.bb}| 0
meta/recipes-core/dbus/dbus_1.8.10.bb | 4 +
meta/recipes-core/dbus/dbus_1.8.2.bb | 4 -
12 files changed, 234 insertions(+), 53 deletions(-)
create mode 100644
meta/recipes-connectivity/connman/connman-gnome/connman-gnome-fix-dbus-interface-name.patch
delete mode 100644
meta/recipes-core/dbus/dbus-glib-0.100.2/obsolete_automake_macros.patch
rename meta/recipes-core/dbus/{dbus-glib-0.100.2 =
dbus-glib}/no-examples.patch (100%)
rename meta/recipes-core/dbus/{dbus-glib-0.100.2 =
dbus-glib}/test-install-makefile.patch (66%)
delete mode 100644 meta/recipes-core/dbus/dbus-glib_0.100.2.bb
create mode 100644 meta/recipes-core/dbus/dbus-glib_0.102.bb
rename meta/recipes-core/dbus/{dbus-test_1.8.2.bb = dbus-test_1.8.10.bb}
(100%)
create mode 100644 meta/recipes-core/dbus/dbus_1.8.10.bb
delete mode 100644 meta/recipes-core/dbus/dbus_1.8.2.bb
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v2 2/2] u-boot.inc : add compile multiple u-boot feature
Ping .
-Original Message-
From: Chunrong Guo [mailto:b40...@freescale.com]
Sent: Monday, November 24, 2014 1:25 PM
To: openembedded-core@lists.openembedded.org
Cc: Liu Ting-B28495; Luo Zhenhua-B19537; Guo Chunrong-B40290; Guo
Chunrong-B40290
Subject: [OE-core][PATCH v2 2/2] u-boot.inc : add compile multiple u-boot
feature
Signed-off-by: Chunrong Guo b40...@freescale.com
---
meta/recipes-bsp/u-boot/u-boot.inc | 56 +-
1 file changed, 31 insertions(+), 25 deletions(-)
diff --git a/meta/recipes-bsp/u-boot/u-boot.inc
b/meta/recipes-bsp/u-boot/u-boot.inc
index c695b73..bd76241 100644
--- a/meta/recipes-bsp/u-boot/u-boot.inc
+++ b/meta/recipes-bsp/u-boot/u-boot.inc
@@ -63,25 +63,32 @@ do_compile () {
echo ${UBOOT_LOCALVERSION} ${S}/.scmversion
fi
- oe_runmake ${UBOOT_MACHINE}
- oe_runmake ${UBOOT_MAKE_TARGET}
+for type in ${UBOOT_MACHINE}; do
+oe_runmake O=${type} ${type}
+oe_runmake O=${type} ${UBOOT_MAKE_TARGET}
+cp ${S}/${type}/${UBOOT_BINARY} ${S}/${type}/u-boot-${type}.bin
+done
+
}
do_install () {
-install -d ${D}/boot
-install ${S}/${UBOOT_BINARY} ${D}/boot/${UBOOT_IMAGE}
-ln -sf ${UBOOT_IMAGE} ${D}/boot/${UBOOT_BINARY}
+for type in ${UBOOT_MACHINE}; do
+install -d ${D}/boot
+install ${S}/${type}/u-boot-${type}.bin ${D}/boot/u-boot-${type}.bin
+done
if [ -e ${WORKDIR}/fw_env.config ] ; then
install -d ${D}${sysconfdir}
install -m 644 ${WORKDIR}/fw_env.config ${D}${sysconfdir}/fw_env.config
fi
-if [ x${SPL_BINARY} != x ]
-then
-install ${S}/${SPL_BINARY} ${D}/boot/${SPL_IMAGE}
-ln -sf ${SPL_IMAGE} ${D}/boot/${SPL_BINARY}
-fi
+for type in ${UBOOT_MACHINE}; do
+if [ x${SPL_BINARY} != x ] [ -d ${S}/${type}/${SPL_BINARY}]
+then
+install ${S}/${type}/${SPL_BINARY} ${D}/boot/${SPL_IMAGE}
+ln -sf ${SPL_IMAGE} ${D}/boot/${SPL_BINARY}
+fi
+done
if [ x${UBOOT_ENV} != x ]
then
@@ -93,21 +100,20 @@ do_install () {
FILES_${PN} = /boot ${sysconfdir}
do_deploy () {
-install -d ${DEPLOYDIR}
-install ${S}/${UBOOT_BINARY} ${DEPLOYDIR}/${UBOOT_IMAGE}
-
-cd ${DEPLOYDIR}
-rm -f ${UBOOT_BINARY} ${UBOOT_SYMLINK}
-ln -sf ${UBOOT_IMAGE} ${UBOOT_SYMLINK}
-ln -sf ${UBOOT_IMAGE} ${UBOOT_BINARY}
-
-if [ x${SPL_BINARY} != x ]
-then
-install ${S}/${SPL_BINARY} ${DEPLOYDIR}/${SPL_IMAGE}
-rm -f ${DEPLOYDIR}/${SPL_BINARY} ${DEPLOYDIR}/${SPL_SYMLINK}
-ln -sf ${SPL_IMAGE} ${DEPLOYDIR}/${SPL_BINARY}
-ln -sf ${SPL_IMAGE} ${DEPLOYDIR}/${SPL_SYMLINK}
-fi
+for type in ${UBOOT_MACHINE}; do
+install -d ${DEPLOYDIR}
+install ${S}/${type}/u-boot-${type}.bin ${DEPLOYDIR}/u-boot-${type}.bin
+done
+
+for type in ${UBOOT_MACHINE}; do
+if [ x${SPL_BINARY} != x ] [ -d ${S}/${type}/${SPL_BINARY}]
+then
+install ${S}/${type}/${SPL_BINARY} ${DEPLOYDIR}/${SPL_IMAGE}
+rm -f ${DEPLOYDIR}/${SPL_BINARY} ${DEPLOYDIR}/${SPL_SYMLINK}
+ln -sf ${SPL_IMAGE} ${DEPLOYDIR}/${SPL_BINARY}
+ln -sf ${SPL_IMAGE} ${DEPLOYDIR}/${SPL_SYMLINK}
+fi
+done
if [ x${UBOOT_ENV} != x ]
then
--
1.9.2
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v2 1/2] uboot-config.bbclass: Allow multiple U-Boot config for machine
Ping.
-Original Message-
From: Chunrong Guo [mailto:b40...@freescale.com]
Sent: Monday, November 24, 2014 1:24 PM
To: openembedded-core@lists.openembedded.org
Cc: Liu Ting-B28495; Luo Zhenhua-B19537; Guo Chunrong-B40290; Guo
Chunrong-B40290
Subject: [OE-core][PATCH v2 1/2] uboot-config.bbclass: Allow multiple U-Boot
config for machine
This adds support to build multiple U-Boot configs for a machine; this
is useful when we have support for different media boots which require
different U-Boot configuration (e.g: eMMC and NAND).
Signed-off-by: Chunrong Guo b40...@freescale.com
---
meta/classes/uboot-config.bbclass | 42 +++
1 file changed, 16 insertions(+), 26 deletions(-)
diff --git a/meta/classes/uboot-config.bbclass
b/meta/classes/uboot-config.bbclass
index 8ac1b71..f70ca88 100644
--- a/meta/classes/uboot-config.bbclass
+++ b/meta/classes/uboot-config.bbclass
@@ -31,31 +31,21 @@ python () {
return
ubootconfig = (d.getVar('UBOOT_CONFIG', True) or ).split()
-if len(ubootconfig) 1:
-raise bb.parse.SkipPackage('You can only have a single default for
UBOOT_CONFIG.')
+if len(ubootconfig) 0:
+for config in ubootconfig:
+for f, v in ubootconfigflags.items():
+if f == 'defaultval':
+continue
+if config == f:
+items = v.split(',')
+if items[0] and len(items) 2:
+raise bb.parse.SkipPackage('Only config,images can be
specified!')
+d.appendVar('UBOOT_MACHINE', ' ' + items[0])
+# IMAGE_FSTYPES appending
+if len(items) 1 and items[1]:
+bb.debug(1, Appending '%s' to IMAGE_FSTYPES. %
items[1])
+d.appendVar('IMAGE_FSTYPES', ' ' + items[1])
+break
elif len(ubootconfig) == 0:
-raise bb.parse.SkipPackage('You must set a default in UBOOT_CONFIG.')
-ubootconfig = ubootconfig[0]
-
-for f, v in ubootconfigflags.items():
-if f == 'defaultval':
-continue
-
-items = v.split(',')
-if items[0] and len(items) 2:
-raise bb.parse.SkipPackage('Only config,images can be specified!')
-
-if ubootconfig == f:
-bb.debug(1, Setting UBOOT_MACHINE to %s. % items[0])
-d.setVar('UBOOT_MACHINE', items[0])
-
-# IMAGE_FSTYPES appending
-if len(items) 1 and items[1]:
-bb.debug(1, Appending '%s' to IMAGE_FSTYPES. % items[1])
-d.appendVar('IMAGE_FSTYPES', ' ' + items[1])
-
-# Go out as we found a match!
-break
-else:
-raise bb.parse.SkipPackage(UBOOT_CONFIG %s is not supported %
ubootconfig)
+ raise bb.parse.SkipPackage('You must set a default in UBOOT_CONFIG.')
}
--
1.9.2
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC PATCH 0/7] Developer workflow improvements
On 12/01/14 05:11, Paul Eggleton wrote: On Friday 28 November 2014 12:28:00 Trevor Woerner wrote: Perhaps any recipe you're working on could be automatically included via an IMAGE_INSTALL_append in conf/local.conf (or maybe that's too intrusive?)? This is something I'd wanted to do - it's certainly something that should be made easy, but I was concerned about causing a full reparse just because of adding that to local.conf. (There might be a workaround through some sort of packagegroup for containing the packages produced by the recipes in the workspace that is added once when we create the workspace - maybe that's the answer?) Maybe even just printing a bit of text after a successful add to inform the user that the just-added project isn't part of any image and what they might want to do to include it? The packagegroup sounds good too. But if the user doesn't want it included, they might be confused about how it magically appeared, and have some trouble finding how to remove it. Do you envision users creating multiple workspaces? I'm wondering why devtool create-workspace is required. Is there any advantage to requiring users to create the workspace explicitly instead of just having it be created implicitly? I wouldn't expect users to want to create multiple workspaces, but I did want users to be able to (a) choose where their workspace would go and (b) know that it has been created, so that the workspace layer showing up in the configuration isn't a surprise. I can't help think that there's no harm in an unused workspace (is there?). Maybe the empty workspace from create-workspace should just be created by default by the oe-init-build-env tool (or whatever a given project is using). If I were writing the documentation for this workflow, or giving a presentation on it... I'm just trying to figure out how to justify the extra, empty (but necessary) step of creating the environment before using it. Maybe if someone tries to add a project before creating the workspace, instead of erroring out, just run the create-workspace for them with the defaults. If they're a power user who wants to put the workspace somewhere specific then they're free to explicitly call create-workspace on their own, otherwise it'll get called with the defaults for them (or created automatically as part of the oe-init-build-env). To borrow the analogy from git: create-workspace is part of the pluming; it's there if people what to call it explicitly, otherwise it gets called implicitly with defaults? -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC PATCH 0/7] Developer workflow improvements
On 11/25/14 12:28, Paul Eggleton wrote: I've then added a new recipe auto-creation script, recipetool, which can take a source tree or URL and create a skeleton recipe to build it. ... * recipetool create ideally needs to become smarter and fill in more details of the recipe. At some point we'll probably have to make the process interactive and possibly have it automate parts of the build process and examine the output; some things just can't be practically detected from the source tree without building. There is a tool autoscan which might be of some use here. If nothing else, the resulting configure.scan file could be parsed for DEPENDS information and perhaps PACKAGECONFIG items too. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/1] gnutls: disable tpm
Disable tpm to solve following error:
.../usr/lib64/libtspi.la: No such file or directory
trousers isn't an oe-core recipe, disable it for now.
Signed-off-by: Chong Lu chong...@windriver.com
---
meta/recipes-support/gnutls/gnutls.inc | 3 +++
1 file changed, 3 insertions(+)
diff --git a/meta/recipes-support/gnutls/gnutls.inc
b/meta/recipes-support/gnutls/gnutls.inc
index 27aba26..12b26cc 100644
--- a/meta/recipes-support/gnutls/gnutls.inc
+++ b/meta/recipes-support/gnutls/gnutls.inc
@@ -35,6 +35,9 @@ do_configure_prepend() {
done
}
+PACKAGECONFIG ??=
+PACKAGECONFIG[tpm] = --with-tpm, --without-tpm, trousers
+
PACKAGES =+ ${PN}-openssl ${PN}-xx
FILES_${PN}-dev += ${bindir}/gnutls-cli-debug
--
1.9.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/1] gnutls: disable tpm
The following changes since commit b8631416f12b8a904ce3deb036f9d5ce632937b0: package_regex.inc: Update REGEX'es in order to find upstream versions correctly (2014-11-28 14:03:02 +) are available in the git repository at: git://git.pokylinux.org/poky-contrib chonglu/gnutls http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=chonglu/gnutls Chong Lu (1): gnutls: disable tpm meta/recipes-support/gnutls/gnutls.inc | 3 +++ 1 file changed, 3 insertions(+) -- 1.9.1 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/1] bind: fix conf.patch to remove configuration that causes failure
The following changes since commit 68ddb28a68ceb59cd1ed322c16143827ce1ac712: distrodata_class: checkpkg make usage of latest_versionstring methods in bitbake fetcher (2014-11-28 13:59:52 +) are available in the git repository at: git://git.openembedded.org/openembedded-core-contrib ChenQi/bind-configuration http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=ChenQi/bind-configuration Chen Qi (1): bind: fix conf.patch to remove configuration that causes failure meta/recipes-connectivity/bind/bind/conf.patch | 7 +-- 1 file changed, 1 insertion(+), 6 deletions(-) -- 1.9.1 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/1] bind: fix conf.patch to remove configuration that causes failure
conf.patch added db.255 confgiuration entry to named.conf. However,
We don't have db.255 configuration file, so remove this entry to avoid
the following failure.
zone 255.in-addr.arpa/IN: loading from master file /etc/bind/db.255 failed:
file not found
Signed-off-by: Chen Qi qi.c...@windriver.com
---
meta/recipes-connectivity/bind/bind/conf.patch | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/meta/recipes-connectivity/bind/bind/conf.patch
b/meta/recipes-connectivity/bind/bind/conf.patch
index 2785c6a..7bab072 100644
--- a/meta/recipes-connectivity/bind/bind/conf.patch
+++ b/meta/recipes-connectivity/bind/bind/conf.patch
@@ -124,7 +124,7 @@ diff -urN bind-9.3.1.orig/conf/db.root
bind-9.3.1/conf/db.root
diff -urN bind-9.3.1.orig/conf/named.conf bind-9.3.1/conf/named.conf
--- bind-9.3.1.orig/conf/named.conf1970-01-01 01:00:00.0 +0100
+++ bind-9.3.1/conf/named.conf 2005-07-10 22:33:46.0 +0200
-@@ -0,0 +1,49 @@
+@@ -0,0 +1,44 @@
+// This is the primary configuration file for the BIND DNS server named.
+//
+// If you are just adding zones, please do that in /etc/bind/named.conf.local
@@ -155,11 +155,6 @@ diff -urN bind-9.3.1.orig/conf/named.conf
bind-9.3.1/conf/named.conf
+ file /etc/bind/db.0;
+};
+
-+zone 255.in-addr.arpa {
-+ type master;
-+ file /etc/bind/db.255;
-+};
-+
+// zone com { type delegation-only; };
+// zone net { type delegation-only; };
+
--
1.9.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
