Re: [meta-intel] [PATCH 3/3] libva-intel-driver: Update to 1.6.0
Missing Upstream-Status: Backport. Sorry. Ok, I will add in. I'm now a bit confused. Which upstream status I should be using Backport or Accepted? Read in www.openembedded.org/wiki/Commit_Patch_Message_Guidelines Now I felt sound like the accepted should be using. Backport also correct as well, I really backport the fixed from upstream master into this fixed version. I don't think your choice here matters, the important thing is that a future maintainer upgrading this recipe can see that this patch might/should be included in a future release: either choice works for that. FWIW, I think accepted is the next step from submitted: a status update for a yocto/oe patch that was also sent to upstream mailing list or issue tracker. backport on the other hand is a commit already in upstream that was then backported to yocto/oe. Thank you for clarify. Now I think much clear what upstream status I should be using. Is this information status needed like below: Upstream-Status: Accepted - The code fixed already accepted in upstream, and expected to be in next release. - Currently backport this code fixed from upstream into 1.6.0 fixed version. - Bugzilla status for this issue is closed fixed. - Expected version info? Can I put wait for next release or totally skip first? (Because I'm really sure what is next release version in libva-intel-driver. It could be 1.6.1 or 1.7.0. This really depends on next release from libva-intel-driver.) If you know the version number the commit is (or will be) in, please include the version number. If the code is not committed upstream yet and you have a bug URL, please include the URL. Ok. Thanks. ...siewhoon -- ___ meta-intel mailing list meta-intel@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-intel
Re: [meta-intel] Do we still need GST_API_VERSION inside gstreamer-vaapi-xxx.bb recipes?
Gstreamer-vaapi already include those GST_API_VERSION checking in
configuration.ac which gstreamer framework version support.
And --with-gstreamer-api option also didn't exist in gstreamer-vaapi.
Will get this kind of warning message:
WARNING: QA Issue: gstreamer-vaapi-1.0: configure was passed unrecognised
options: --with-gstreamer-api [unknown-configure-option]
Can we do a cleanup for it?
1. Remove out --with-gstreamer-api=${GST_API_VERSION} inside the
gstreamer-vaapi.inc?
2. Remove out the GST_API_VERSION from gstreamer-vaapi recipes?
It was needed in the past when there were both 0.10 and 1.0 recipes for
gstreamer-vaapi, but if gstreamer-vaapi has removed the --with-gstreamer-api
option then it can all be deleted.
Run configuration: ./configure or ./autogen.sh --prefix=/usr
Got warning message: configure: WARNING: unrecognized options:
--with-gstreamer-api
But I just found out in gstreamer-vaapi/debian.upstream/rules file, got this
--with-gstreamer-api=$(GST_API_VERSION).
Will check whether gstreamer-vaapi side missing this out clean up in
gstreamer-vaapi/debian.upstream/rules as well.
OK. Then I will go double check and confirm before create a patch for this one
to do clean up.
Thanks.
...siewhoon
--
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel
Re: [meta-intel] [PATCH 3/3] libva-intel-driver: Update to 1.6.0
On 13 August 2015 at 09:09, Lim, Siew Hoon siew.hoon@intel.com wrote: On 23 July 2015 at 10:46, Lim Siew Hoon siew.hoon@intel.com wrote: +Tested-by: Lim, Siew Hoon siew.hoon@intel.com +Signed-off-by: Zhao Yakui yakui.z...@intel.com Missing Upstream-Status: Backport. Sorry. Ok, I will add in. I'm now a bit confused. Which upstream status I should be using Backport or Accepted? Read in www.openembedded.org/wiki/Commit_Patch_Message_Guidelines Now I felt sound like the accepted should be using. Backport also correct as well, I really backport the fixed from upstream master into this fixed version. I don't think your choice here matters, the important thing is that a future maintainer upgrading this recipe can see that this patch might/should be included in a future release: either choice works for that. FWIW, I think accepted is the next step from submitted: a status update for a yocto/oe patch that was also sent to upstream mailing list or issue tracker. backport on the other hand is a commit already in upstream that was then backported to yocto/oe. Is this information status needed like below: Upstream-Status: Accepted - The code fixed already accepted in upstream, and expected to be in next release. - Currently backport this code fixed from upstream into 1.6.0 fixed version. - Bugzilla status for this issue is closed fixed. - Expected version info? Can I put wait for next release or totally skip first? (Because I'm really sure what is next release version in libva-intel-driver. It could be 1.6.1 or 1.7.0. This really depends on next release from libva-intel-driver.) If you know the version number the commit is (or will be) in, please include the version number. If the code is not committed upstream yet and you have a bug URL, please include the URL. HTH, Jussi Thanks. siewhoon -- ___ meta-intel mailing list meta-intel@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-intel -- ___ meta-intel mailing list meta-intel@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-intel
Re: [meta-intel] [PATCH v3] intel-gpu-tools: upgrade to version 1.11
On 08/12/2015 08:15 PM, Pengyu Ma wrote:
# ~/checkbashisms -f
/usr/lib64/intel-gpu-tools/intel-gpu-tools/check_drm_clients
possible bashism in
/usr/lib64/intel-gpu-tools/intel-gpu-tools/check_drm_clients line 3
(bash arrays, ${name[0|*|@]}):
SOURCE_DIR=$( dirname ${BASH_SOURCE[0]} )
possible bashism in
/usr/lib64/intel-gpu-tools/intel-gpu-tools/check_drm_clients line 3
($BASH_SOMETHING):
SOURCE_DIR=$( dirname ${BASH_SOURCE[0]} )
It seems there are some bash specific script.
Shall bash is rdepended in this package instead of remove bash?
Yes, if there are bashisms that can not be fixed easily then we should
have a RDEPENDS = bash added to the recipe to ensure bash is installed
for these tools.
Sau!
Pengyu
On 08/12/2015 11:33 PM, Burton, Ross wrote:
On 12 August 2015 at 16:17, Saul Wold s...@linux.intel.com
mailto:s...@linux.intel.com wrote:
If you are running on a system with bash the /bin/sh will point to
bash so there is no real change, the real test is to install these
tools on a system without Bash and ensure they work.
Or run checkbashisms, or just read the scripts.
Ross
--
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel
Re: [meta-intel] CrownBay EMGD acceleration for Daisy 1.6.3
On 13 August 2015 at 17:49, Chad Bishop chad.a.bis...@gmail.com wrote: The EMGD documentation for v1.18 of the driver speaks to EMGD support for Wayland / Weston. However the details are specific to Meego. I am writing to inquire as to whether the meta-intel CrownBay BSP provided for daisy can also support this configuration. A very old dated snapshot of Wayland/Weston from before they even make a 1.0 release should work, but you'll need the exact snapshot. Ross -- ___ meta-intel mailing list meta-intel@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-intel
Re: [meta-intel] [PATCH v3] intel-gpu-tools: upgrade to version 1.11
On 08/13/2015 11:10 PM, Saul Wold wrote:
On 08/12/2015 08:15 PM, Pengyu Ma wrote:
# ~/checkbashisms -f
/usr/lib64/intel-gpu-tools/intel-gpu-tools/check_drm_clients
possible bashism in
/usr/lib64/intel-gpu-tools/intel-gpu-tools/check_drm_clients line 3
(bash arrays, ${name[0|*|@]}):
SOURCE_DIR=$( dirname ${BASH_SOURCE[0]} )
possible bashism in
/usr/lib64/intel-gpu-tools/intel-gpu-tools/check_drm_clients line 3
($BASH_SOMETHING):
SOURCE_DIR=$( dirname ${BASH_SOURCE[0]} )
It seems there are some bash specific script.
Shall bash is rdepended in this package instead of remove bash?
Yes, if there are bashisms that can not be fixed easily then we should
have a RDEPENDS = bash added to the recipe to ensure bash is
installed for these tools.
OK, I will send V4 version.
Pengyu
Sau!
Pengyu
On 08/12/2015 11:33 PM, Burton, Ross wrote:
On 12 August 2015 at 16:17, Saul Wold s...@linux.intel.com
mailto:s...@linux.intel.com wrote:
If you are running on a system with bash the /bin/sh will point to
bash so there is no real change, the real test is to install these
tools on a system without Bash and ensure they work.
Or run checkbashisms, or just read the scripts.
Ross
--
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel
[meta-intel] [meta-intel-iot-middleware][PATCH] hiredis: Fix build on arm platform
* upgrade previous patch to avoid wiping CFLAGS. This fixes build on arm platforms which previously caused an issue due to -fPIC being lost Signed-off-by: Andrea Galbusera giz...@gmail.com --- This patch is inteded to fix a build error when building on arm platforms. To reproduce the issue just bitbake hiredis for the Yocto arm reference machine beaglebone. The error comes from the -fPIC compiler option being lost due to the current version of 0001-Makefile-remove-hardcoding-of-CC.patch which does not honor CFLAGS from the environment. The proposed patch is a minimal variation of the current version that fixes the issue both on a cortexa5 target and the beaglebone. The patch was also successfully build tested against qemuarm and qemux86. Also available on GitHub at: https://github.com/gizero/meta-intel-iot-middleware/tree/hiredis-fix-arm-build .../0001-Makefile-remove-hardcoding-of-CC.patch| 34 +++--- 1 file changed, 17 insertions(+), 17 deletions(-) diff --git a/recipes-extended/hiredis/files/0001-Makefile-remove-hardcoding-of-CC.patch b/recipes-extended/hiredis/files/0001-Makefile-remove-hardcoding-of-CC.patch index cfacc8c..fef2bc7 100644 --- a/recipes-extended/hiredis/files/0001-Makefile-remove-hardcoding-of-CC.patch +++ b/recipes-extended/hiredis/files/0001-Makefile-remove-hardcoding-of-CC.patch @@ -1,32 +1,32 @@ -From 193d499c59871ab4ce1785fecf3642699bb593bf Mon Sep 17 00:00:00 2001 -From: Brendan Le Foll brendan.le.f...@intel.com -Date: Wed, 18 Jun 2014 16:26:53 +0100 +From d13b918a3ff8b0ebfd1e7b18b198b4b45841d720 Mon Sep 17 00:00:00 2001 +From: Andrea Galbusera giz...@gmail.com +Date: Fri, 31 Jul 2015 16:42:08 +0200 Subject: [PATCH] Makefile: remove hardcoding of CC -Signed-off-by: Brendan Le Foll brendan.le.f...@intel.com +* upgrade previous patch to avoid wiping CFLAGS. This fixes build on arm +platforms which previously caused and issue due to -fPIC being lost + +Signed-off-by: Andrea Galbusera giz...@gmail.com --- - Makefile |8 - 1 file changed, 8 deletions(-) + Makefile | 5 - + 1 file changed, 5 deletions(-) diff --git a/Makefile b/Makefile -index 16b8767..0a991a3 100644 +index 8b0f0c2..66a4317 100644 --- a/Makefile +++ b/Makefile -@@ -10,14 +10,6 @@ LIBNAME=libhiredis - HIREDIS_MAJOR=0 - HIREDIS_MINOR=10 +@@ -34,11 +34,6 @@ define REDIS_TEST_CONFIG + endef + export REDIS_TEST_CONFIG -# Fallback to gcc when $CC is not in $PATH. -CC:=$(shell sh -c 'type $(CC) /dev/null 2/dev/null echo $(CC) || echo gcc') -OPTIMIZATION?=-O3 -WARNINGS=-Wall -W -Wstrict-prototypes -Wwrite-strings -DEBUG?= -g -ggdb --REAL_CFLAGS=$(OPTIMIZATION) -fPIC $(CFLAGS) $(WARNINGS) $(DEBUG) $(ARCH) --REAL_LDFLAGS=$(LDFLAGS) $(ARCH) -- - DYLIBSUFFIX=so - STLIBSUFFIX=a - DYLIB_MINOR_NAME=$(LIBNAME).$(DYLIBSUFFIX).$(HIREDIS_MAJOR).$(HIREDIS_MINOR) + REAL_CFLAGS=$(OPTIMIZATION) -fPIC $(CFLAGS) $(WARNINGS) $(DEBUG) $(ARCH) + REAL_LDFLAGS=$(LDFLAGS) $(ARCH) + -- -1.7.10.4 +1.9.1 -- 1.9.1 -- ___ meta-intel mailing list meta-intel@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-intel
