[OE-core] [PATCH V3 1/1] kmod: fix debuginfo is missing in shared library

2014-10-26 Thread Chong Lu 
INHIBIT_PACKAGE_STRIP variable will make debuginfo lose in shared library.
The test cases of kmod contain kernel modules for many different architectures,
strip and arch gets confused and throws errors. Pack kernel modules in test
cases to avoid strip command failed.

Signed-off-by: Chong Lu 
---
 meta/recipes-kernel/kmod/kmod/run-ptest | 2 ++
 meta/recipes-kernel/kmod/kmod_git.bb| 9 -
 2 files changed, 10 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-kernel/kmod/kmod/run-ptest 
b/meta/recipes-kernel/kmod/kmod/run-ptest
index 37adec3..598dd2c 100755
--- a/meta/recipes-kernel/kmod/kmod/run-ptest
+++ b/meta/recipes-kernel/kmod/kmod/run-ptest
@@ -1,3 +1,5 @@
 #!/bin/sh
 touch testsuite/stamp-rootfs
+tar xf testmodule.tar
 make -k runtest-TESTS 2>/dev/null| grep -e ^PASS -e ^FAIL
+find testsuite -name *.ko -exec rm -f {} \;
diff --git a/meta/recipes-kernel/kmod/kmod_git.bb 
b/meta/recipes-kernel/kmod/kmod_git.bb
index d4c21a4..08dd815 100644
--- a/meta/recipes-kernel/kmod/kmod_git.bb
+++ b/meta/recipes-kernel/kmod/kmod_git.bb
@@ -34,6 +34,10 @@ do_install_append () {
 # install depmod.d file for search/ dir
 install -Dm644 "${WORKDIR}/depmod-search.conf" 
"${D}${base_libdir}/depmod.d/search.conf"
 
+if ${@base_contains('DISTRO_FEATURES', 'ptest', 'true', 'false', d)}; 
then
+find testsuite -name *.ko -exec tar rf testmodule.tar {} \;
+find testsuite -name *.ko -exec rm -f {} \;
+fi
 }
 
 do_compile_prepend() {
@@ -44,7 +48,10 @@ do_compile_ptest () {
 oe_runmake buildtest-TESTS rootfs
 }
 
-INHIBIT_PACKAGE_STRIP = "${@bb.utils.contains("DISTRO_FEATURES", "ptest", "1", 
"0", d)}"
+do_install_ptest () {
+install testmodule.tar ${D}${PTEST_PATH}
+}
+
 INSANE_SKIP_${PN}-ptest = "arch"
 
 inherit update-alternatives
-- 
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/1] kmod: fix debuginfo is missing in shared library

2014-10-26 Thread Chong Lu 
Change since V2:
Delete the modules after test cases have ran.

The following changes since commit ad065f94acb0bfb81e33935890a1db251d6e2979:

  ref-manual: Minor edits to variables. (2014-10-23 15:20:20 +0100)

are available in the git repository at:

  git://git.pokylinux.org/poky-contrib chonglu/kmod
  http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=chonglu/kmod

Chong Lu (1):
  kmod: fix debuginfo is missing in shared library

 meta/recipes-kernel/kmod/kmod/run-ptest | 2 ++
 meta/recipes-kernel/kmod/kmod_git.bb| 9 -
 2 files changed, 10 insertions(+), 1 deletion(-)

-- 
1.9.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH V2 1/1] kmod: fix debuginfo is missing in shared library

2014-10-26 Thread Chong Lu 


On 10/24/2014 07:08 PM, Burton, Ross wrote:


On 24 October 2014 07:25, Chong Lu > wrote:


+++ b/meta/recipes-kernel/kmod/kmod/run-ptest
@@ -1,3 +1,4 @@
 #!/bin/sh
 touch testsuite/stamp-rootfs
+tar xf testmodule.tar
 make -k runtest-TESTS 2>/dev/null| grep -e ^PASS -e ^FAIL


We should to make sure that the ptest scripts clean up after 
themselves, so can you change this to delete the modules after the 
test has ran?


Ross


OK, I will send a V2.

Best Regards
Chong
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 1/1] curl: Security Advisory - curl - CVE-2014-3613

2014-10-26 Thread Chong Lu 


On 10/25/2014 06:16 AM, Burton, Ross wrote:


On 24 October 2014 10:20, Chong Lu > wrote:


 meta/recipes-support/curl/curl/CVE-2014-3613.patch | 269
+


ERROR: Command Error: exit status: 1  Output:
Applying patch CVE-2014-3613.patch
patching file lib/cookie.c
patching file tests/data/test1105
patching file tests/data/test31
Hunk #1 FAILED at 49.
1 out of 2 hunks FAILED -- rejects in file tests/data/test31
patching file tests/data/test8
Patch CVE-2014-3613.patch does not apply (enforce with -f)

Please verify that your patch applies to current git master.

Ross


Hi Ross,

This patch includes windows characters.

+diff --git a/tests/data/test31 b/tests/data/test31
+index 38af83b..dfcac04 100644
+--- a/tests/data/test31
 b/tests/data/test31
+@@ -49,11 +49,12 @@ Set-Cookie: nodomainnovalue
+ Set-Cookie:   nodomain=value; expires=Fri Feb 2 11:56:27 GMT 2035^M
+ Set-Cookie: novalue; domain=reallysilly^M
+ Set-Cookie: test=yes; domain=foo.com; expires=Sat Feb 2 11:56:27 GMT 
2030^M

+ Set-Cookie: test2=yes; domain=se; expires=Sat Feb 2 11:56:27 GMT 2030^M
+ Set-Cookie: magic=yessir; path=/silly/; HttpOnly^M
+-Set-Cookie: blexp=yesyes; domain=.0.0.1; domain=.0.0.1; expiry=totally 
bad;^M
++Set-Cookie: blexp=yesyes; domain=127.0.0.1; domain=127.0.0.1; 
expiry=totally bad;^M

++Set-Cookie: partialip=nono; domain=.0.0.1;^M
+ ^M

You can apply this patch as following steps:
$ git fetch git://git.pokylinux.org/poky-contrib chonglu/curl
$ git cherry-pick FETCH_HEAD

Best Regards
Chong
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 4/7] kernel: Pull uImage generation into separate class

2014-10-26 Thread Marek Vasut 
On Sunday, October 26, 2014 at 12:29:18 PM, Koen Kooi wrote:
[...]
>  To keep backward compatibility, could you rework this into something
>  like:
>  
>  kernel.bbclass:
>   inherit kernel-${KERNEL_IMAGETYPE}
>  
>  kernel-${KERNEL_IMAGETYPE}:
>   inherit kernel-base
>   imagetype stuff
>  
>  kernel-base:
>   old kernel.bbclass stuff
>  
>  That would keep existing BSPs working *and* split out the image types.
> >>> 
> >>> Yes, this makes sense. Are there any traps inside kernel.bbclass I
> >>> should be careful about? Like for example ${PN} or other possible
> >>> variables which are set based on the name of the file?
> >> 
> >> You should be safe, PN is supposed to be completely ignored since the
> >> output packages will all be 'kernel-' instead of
> >> 'linux-myfirstbsp-'
> > 
> > The kernel_do_configure() and do_configure stuff in kernel.bbclass now
> > bit me. I'm not even sure I can explain the problem well, so please bear
> > with me.
> > 
> > The build system now cannot find do_configure() when building kernel
> > recipe, since by moving kernel.bbclass contents into
> > kernel-base.bbclass, the expectations of prefix of functions passed to
> > 'addtask ... do_configure' and 'EXPORT_FUNCTIONS ... do_configure' are
> > no longer met. Before, the functions in kernel.bbclass, namely
> > kernel_do_configure() , kernel_do_compile() and kernel_do_install() had
> > prefix matching the name of the bbclass (kernel_) and were used by the
> > addtask...do_configure() and EXPORT_FUNCTIONS...do_configure() without
> > the kernel_ prefix.
> > 
> > Now that I moved the contents of kernel.bbclass into kernel-base.bbclass,
> > the name of the kernel_do_*() functions no longer matches the bbclass
> > name and so I presume the addtask... and EXPORT_FUNCTIONS... things are
> > confused. Furthermore, I presume we want to keep the name of those
> > kernel_do_*() functions in case some recipes wanted to override those
> > functions.
> > 
> > Do you happen to have any suggestion please ?
> 
> Hmmm, it looks like there isn't a way to make this "just work" for 'old'
> BSPs :(

So uh, what exactly would you propose then? Ask the BSPs to cater for the
change ? I don't quite like that option, since it's like breaking an API
(or similar interface, I'm not sure what the local equivalent of that would
be).

Thanks!

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 v2] gstreamer1.0-plugins-bad: Add patch for disable pkg-check of wayland-scanner

2014-10-26 Thread Burton, Ross 
On 8 October 2014 03:57, Nobuhiro Iwamatsu  wrote:

> +-AC_PATH_PROG([wayland_scanner], [wayland-scanner])
>

This check actually works fine and by removing it you're potentially
breaking the build if it ever does need to invoke it, so don't remove this
line.

Ross
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH V3 1/1] gconf: fix multilib conflict - org.gnome.GConf.service

2014-10-26 Thread Burton, Ross 
On 24 October 2014 03:26, Chong Lu  wrote:

> IMAGE_INSTALL = "gconf lib32-gconf"
>
> So multiple copies of gconf to be installed.
>

Yeah, don't do that.  Would you test installing apache and lib32-apache?

Ross
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] package_manager: Fix BAD_RECOMMENDATIONS for opkg

2014-10-26 Thread Paul Barker 
On 26 October 2014 19:36, Paul Barker  wrote:
> In package_manager.py, when using opkg as the packager, the command 'opkg 
> 
> info ' is called to get information about each pkg in BAD_RECOMMENDATIONS
> in a format that can be written to the status file. The 'Status: ...' line is
> modified and all other lines are passed through. Changing the verbosity level
> argument for this command will change what it written into the status file.
> Crucially, with the default verbosity level, no blank lines are being printed 
> by
> the opkg command and so no blank lines are being written to the status file to
> separate each package entry.
>
> The package parsing code in opkg expects package entries in the status file to
> be separated by at least one blank line. If no blank line is seen, the next
> package entry is interpreted as a continuation of the last package entry, but
> the new values overwrite the old values.
>
> So with the default verbosity level, a blank line follows some package entries
> and these are parsed. The others are dropped due to the lack of blank lines. 
> As
> the verbosity increases, more debugging messages add blank lines and more
> packages are parsed.
>
> The solution to ensure that this works correctly regardless of the verbosity
> level is simply add a blank line after the output of 'opkg info' is written to
> the status file, ensuring that the next package is separated from the current
> package.
>
> [YOCTO #6816]
>
> Signed-off-by: Paul Barker 
> Cc: Chris Carr 
> ---
>  meta/lib/oe/package_manager.py | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/meta/lib/oe/package_manager.py b/meta/lib/oe/package_manager.py
> index ffb83b2..85d7fd4 100644
> --- a/meta/lib/oe/package_manager.py
> +++ b/meta/lib/oe/package_manager.py
> @@ -1408,6 +1408,10 @@ class OpkgPM(PackageManager):
>  else:
>  status.write(line + "\n")
>
> +# Append a blank line after each package entry to ensure 
> that it
> +# is separated from the following entry
> +status.write("\n")
> +
>  '''
>  The following function dummy installs pkgs and returns the log of output.
>  '''
> --
> 2.1.2
>

Chris, could you give this a test and let us know if it fixes the issue.

Thanks,

-- 
Paul Barker

Email: p...@paulbarker.me.uk
http://www.paulbarker.me.uk
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] package_manager: Fix BAD_RECOMMENDATIONS for opkg

2014-10-26 Thread Paul Barker 
In package_manager.py, when using opkg as the packager, the command 'opkg 
info ' is called to get information about each pkg in BAD_RECOMMENDATIONS
in a format that can be written to the status file. The 'Status: ...' line is
modified and all other lines are passed through. Changing the verbosity level
argument for this command will change what it written into the status file.
Crucially, with the default verbosity level, no blank lines are being printed by
the opkg command and so no blank lines are being written to the status file to
separate each package entry.

The package parsing code in opkg expects package entries in the status file to
be separated by at least one blank line. If no blank line is seen, the next
package entry is interpreted as a continuation of the last package entry, but
the new values overwrite the old values.

So with the default verbosity level, a blank line follows some package entries
and these are parsed. The others are dropped due to the lack of blank lines. As
the verbosity increases, more debugging messages add blank lines and more
packages are parsed.

The solution to ensure that this works correctly regardless of the verbosity
level is simply add a blank line after the output of 'opkg info' is written to
the status file, ensuring that the next package is separated from the current
package.

[YOCTO #6816]

Signed-off-by: Paul Barker 
Cc: Chris Carr 
---
 meta/lib/oe/package_manager.py | 4 
 1 file changed, 4 insertions(+)

diff --git a/meta/lib/oe/package_manager.py b/meta/lib/oe/package_manager.py
index ffb83b2..85d7fd4 100644
--- a/meta/lib/oe/package_manager.py
+++ b/meta/lib/oe/package_manager.py
@@ -1408,6 +1408,10 @@ class OpkgPM(PackageManager):
 else:
 status.write(line + "\n")
 
+# Append a blank line after each package entry to ensure that 
it
+# is separated from the following entry
+status.write("\n")
+
 '''
 The following function dummy installs pkgs and returns the log of output.
 '''
-- 
2.1.2

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] base bbclass: add support for tar.lz

2014-10-26 Thread Koen Kooi 
Some GNU packages (e.g. ddrescue) switched to lzip only, so add support for it.

Needs matching bitbake patch to work properly:
http://lists.openembedded.org/pipermail/bitbake-devel/2014-October/005093.html

Signed-off-by: Koen Kooi 
---
 meta/classes/base.bbclass | 5 +
 1 file changed, 5 insertions(+)

diff --git a/meta/classes/base.bbclass b/meta/classes/base.bbclass
index ff8c633..128297a 100644
--- a/meta/classes/base.bbclass
+++ b/meta/classes/base.bbclass
@@ -478,6 +478,11 @@ python () {
 elif "osc://" in srcuri:
 d.appendVarFlag('do_fetch', 'depends', ' 
osc-native:do_populate_sysroot')
 
+# *.lz should depends on lzip-native for unpacking
+# Not endswith because of "*.patch.lz;patch=1". Need bb.fetch.decodeurl in 
future
+if '.lz' in srcuri:
+d.appendVarFlag('do_unpack', 'depends', ' 
lzip-native:do_populate_sysroot')
+
 # *.lz4 should depends on lz4-native for unpacking
 # Not endswith because of "*.patch.lz4;patch=1". Need bb.fetch.decodeurl 
in future
 if '.lz4' in srcuri:
-- 
1.9.0

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 0/1] bind: fix to use correct environment file in service file

2014-10-26 Thread Chen Qi 
The following changes since commit 4143f3b0ce0d0c52f5b0babc1bb16ac0ac9610eb:

  nativesdk-cmake: Adjust toolchain paths dynamically (2014-10-24 21:59:34 
+0100)

are available in the git repository at:

  git://git.openembedded.org/openembedded-core-contrib ChenQi/systemd-bind9
  
http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=ChenQi/systemd-bind9

Chen Qi (1):
  bind: fix to use correct environment file in service file

 meta/recipes-connectivity/bind/bind/named.service | 2 +-
 1 file changed, 1 insertion(+), 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 1/1] bind: fix to use correct environment file in service file

2014-10-26 Thread Chen Qi 
Use /etc/default/bind9 as the environment file in named.service.

Signed-off-by: Chen Qi 
---
 meta/recipes-connectivity/bind/bind/named.service | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-connectivity/bind/bind/named.service 
b/meta/recipes-connectivity/bind/bind/named.service
index 1792e41..cda56ef 100644
--- a/meta/recipes-connectivity/bind/bind/named.service
+++ b/meta/recipes-connectivity/bind/bind/named.service
@@ -6,7 +6,7 @@ After=network.target
 
 [Service]
 Type=forking
-EnvironmentFile=-/etc/sysconfig/named
+EnvironmentFile=-/etc/default/bind9
 PIDFile=/run/named/named.pid
 
 ExecStartPre=@SBINDIR@/generate-rndc-key.sh
-- 
1.9.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] gcc: poison default sysroot path

2014-10-26 Thread Koen Kooi 

> Op 24 okt. 2014, om 16:10 heeft Richard Purdie 
>  het volgende geschreven:
> 
> Various pieces of the code assume that the --sysroot option gets passed
> into the compiler tools. By having a "sane" default, we don't always
> spot when this occurs and this can later show up as breakage in sstate,
> or in usage of the external toolchain.
> 
> We've long since talked about poisoning the default such that it will
> break unless the correct option is specified. This patch does just that.
> 
> If this patch causes something to fail to build, it most likely means
> the various compiler flags and commands are not correctly being passed
> through to the underlying piece of software and that there is a real
> problem that needs fixing, its not the fault of this patch. 

So hopefully this won't be needed anymore in my autobuilders:

export GCCARCH=$(MACHINE=${machine} bitbake -e | grep TARGET_ARCH\= | awk -F'"' 
'{print $2}') 
MACHINE=$machine bitbake gcc-cross-${GCCARCH} -c cleansstate || true

Current offenders are: u-boot, linux and on x86 only, opencv.

regards,

Koen
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 4/7] kernel: Pull uImage generation into separate class

2014-10-26 Thread Koen Kooi 

> Op 22 okt. 2014, om 23:45 heeft Marek Vasut  het volgende 
> geschreven:
> 
> On Wednesday, October 22, 2014 at 10:42:09 AM, Koen Kooi wrote:
>>> Op 22 okt. 2014, om 01:28 heeft Marek Vasut  het volgende
>>> geschreven:
>>> 
>>> On Monday, October 20, 2014 at 12:26:04 PM, Koen Kooi wrote:
> Op 19 okt. 2014, om 21:15 heeft Marek Vasut  het
> volgende geschreven:
> 
> 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.
 
 To keep backward compatibility, could you rework this into something
 like:
 
 kernel.bbclass:
inherit kernel-${KERNEL_IMAGETYPE}
 
 kernel-${KERNEL_IMAGETYPE}:
inherit kernel-base
imagetype stuff
 
 kernel-base:
old kernel.bbclass stuff
 
 That would keep existing BSPs working *and* split out the image types.
>>> 
>>> Yes, this makes sense. Are there any traps inside kernel.bbclass I should
>>> be careful about? Like for example ${PN} or other possible variables
>>> which are set based on the name of the file?
>> 
>> You should be safe, PN is supposed to be completely ignored since the
>> output packages will all be 'kernel-' instead of
>> 'linux-myfirstbsp-'
> 
> The kernel_do_configure() and do_configure stuff in kernel.bbclass now bit me.
> I'm not even sure I can explain the problem well, so please bear with me.
> 
> The build system now cannot find do_configure() when building kernel recipe, 
> since by moving kernel.bbclass contents into kernel-base.bbclass, the 
> expectations of prefix of functions passed to 'addtask ... do_configure' and 
> 'EXPORT_FUNCTIONS ... do_configure' are no longer met. Before, the functions
> in kernel.bbclass, namely kernel_do_configure() , kernel_do_compile() and 
> kernel_do_install() had prefix matching the name of the bbclass (kernel_) and 
> were used by the addtask...do_configure() and 
> EXPORT_FUNCTIONS...do_configure() 
> without the kernel_ prefix.
> 
> Now that I moved the contents of kernel.bbclass into kernel-base.bbclass, the 
> name of the kernel_do_*() functions no longer matches the bbclass name and so
> I presume the addtask... and EXPORT_FUNCTIONS... things are confused. 
> Furthermore, I presume we want to keep the name of those kernel_do_*() 
> functions
> in case some recipes wanted to override those functions.
> 
> Do you happen to have any suggestion please ?

Hmmm, it looks like there isn't a way to make this "just work" for 'old' BSPs :(
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core