Re: [OE-core] [PATCH] relocate_sdk.py: fix lib path error
On 06/06/2014 08:22 PM, Khem Raj wrote: On Friday, June 6, 2014, rongqing...@windriver.com mailto:rongqing...@windriver.com wrote: From: yzhu1 yanjun@windriver.com javascript:; In centos 5.9 32bit, ld lib does not contain some flags, so ld lib is not parsed. So correct lib path is not got from ld lib. Can you explain with examples what's going on here ? Hi, Before relocate_sdk.sh is executed, it needs the parameters: path/ld-linux-x86-64.so.2 path/dmesg.util-linux path/kill.util-linux path/reset.util-linux . The file list (path/dmesg.util-linux path/kill.util-linux path/reset.util-linux .) is collected by grep '\(executable\|dynamically linked\)'. So dynamically linked is very import to the file ld-linux-x86-64.so.2. But in redhat 5.9(32 bit) This file is as below: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), stripped In Ubuntu 12.04 (64bit) This file is as below: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, BuildID[sha1]=0xbb8c5184d8d41f31093193a2ec8d3f6f10964cd2, stripped In this case, we can find in Ubuntu 12.04(64 bit), the flag dynamically linked is present, so ld-linux-x86-64.so.2 can be included in the file list. relocate_sdk.py can work according to the information from ld-linux-x86-64.so.2. But in redhat 5.9(32bit), the flag does not exist. relocate_sdk.py can not get the information from ld-linux-x86-64.so.2 since this file is not included in the file list. The same error occurs on redhat6.0(32 bit). So the direct solution to this defect is to force this file ld-linux-x86-64.so.2 exist in file list. If any problem, please feel free to let me know. Best Regards! Zhu Yanjun Signed-off-by: yzhu1 yanjun@windriver.com javascript:; --- scripts/relocate_sdk.py |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/scripts/relocate_sdk.py b/scripts/relocate_sdk.py index 05d9fd6..a05a7fa 100755 --- a/scripts/relocate_sdk.py +++ b/scripts/relocate_sdk.py @@ -201,7 +201,7 @@ else: new_prefix = sys.argv[1].encode() new_dl_path = sys.argv[2].encode() -executables_list = sys.argv[3:] +executables_list = sys.argv[2:] for e in executables_list: perms = os.stat(e)[stat.ST_MODE] -- 1.7.10.4 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org javascript:; 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] boot-directdisk: fix the support of vmdk
Hi, Saul
Sorry. I do not understand. What does the patch fix? After this patch is
applied, what is the difference?
Zhu Yanjun
On 01/23/2014 02:50 PM, Saul Wold wrote:
From: Joao Henrique Ferreira de Freitas joa...@gmail.com
Previous change (086ce22b88f5ef5f75a83119a32c8b3fdcfa296d) broke
the creating of vmdk images. This protects shell expansion variables
and let dd generate the image to be transformed to vmdk by image-vmdk.class.
Signed-off-by: Joao Henrique Ferreira de Freitas joa...@gmail.com
[edit to change the usage of IMAGE_FSTYPE to IS_VMDK]
Signed-off-by: Saul Wold s...@linux.intel.com
---
meta/classes/boot-directdisk.bbclass | 18 --
1 file changed, 8 insertions(+), 10 deletions(-)
diff --git a/meta/classes/boot-directdisk.bbclass
b/meta/classes/boot-directdisk.bbclass
index 3277666..afab843 100644
--- a/meta/classes/boot-directdisk.bbclass
+++ b/meta/classes/boot-directdisk.bbclass
@@ -61,6 +61,8 @@ DISK_SIGNATURE ?= ${DISK_SIGNATURE_GENERATED}
SYSLINUX_ROOT ?= root=/dev/sda2
SYSLINUX_TIMEOUT ?= 10
+IS_VMDK = '${@base_contains(IMAGE_FSTYPES, vmdk, true, false, d)}'
+
boot_direct_populate() {
dest=$1
install -d $dest
@@ -88,10 +90,10 @@ build_boot_dd() {
grubefi_hddimg_populate $HDDDIR
fi
- if [ ${IMAGE_FSTYPE} = vmdk ]; then
- if [ x${AUTO_SYSLINUXMENU} = x1 ] ; then
+ if [ ${IS_VMDK} ]; then
+ if [ x${AUTO_SYSLINUXMENU} = x1 ] ; then
install -m 0644
${STAGING_DIR}/${MACHINE}/usr/share/syslinux/vesamenu.c32
${HDDDIR}${SYSLINUXDIR}/vesamenu.c32
- if [ x${SYSLINUX_SPLASH} != x ] ; then
+ if [ x${SYSLINUX_SPLASH} != x ] ; then
install -m 0644 ${SYSLINUX_SPLASH}
${HDDDIR}${SYSLINUXDIR}/splash.lss
fi
fi
@@ -129,9 +131,7 @@ build_boot_dd() {
parted $IMAGE unit B mkpart primary ext2 ${END2}B ${END3}B
parted $IMAGE set 1 boot on
- if [ ${IMAGE_FSTYPE} != vmdk ]; then
- parted $IMAGE print
- fi
+ parted $IMAGE print
awk BEGIN { printf \$(echo ${DISK_SIGNATURE} | fold -w 2 | tac | paste -sd '' | sed 's/\(..\)/\\x/g')\ } | \
dd of=$IMAGE bs=1 seek=440 conv=notrunc
@@ -141,10 +141,8 @@ build_boot_dd() {
dd if=${STAGING_DATADIR}/syslinux/mbr.bin of=$IMAGE conv=notrunc
fi
- if [ ${IMAGE_FSTYPE} != vmdk ]; then
- dd if=$HDDIMG of=$IMAGE conv=notrunc seek=1 bs=512
- dd if=${ROOTFS} of=$IMAGE conv=notrunc seek=$OFFSET bs=512
- fi
+ dd if=$HDDIMG of=$IMAGE conv=notrunc seek=1 bs=512
+ dd if=${ROOTFS} of=$IMAGE conv=notrunc seek=$OFFSET bs=512
cd ${DEPLOY_DIR_IMAGE}
rm -f ${DEPLOY_DIR_IMAGE}/${IMAGE_LINK_NAME}.hdddirect
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] Modify the path of env in CA.pl to make export-sdk successfully.
---
meta/recipes-connectivity/openssl/openssl.inc |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-connectivity/openssl/openssl.inc
b/meta/recipes-connectivity/openssl/openssl.inc
index 3bfe569..de10d17 100644
--- a/meta/recipes-connectivity/openssl/openssl.inc
+++ b/meta/recipes-connectivity/openssl/openssl.inc
@@ -154,7 +154,7 @@ do_install () {
install -d ${D}${includedir}
cp --dereference -R include/openssl ${D}${includedir}
- sed -i -e '1s,.*,#!${bindir}/env perl,' ${D}${libdir}/ssl/misc/CA.pl
+ sed -i -e '1s,^.*$,#! ${bindir}/perl,' ${D}${libdir}/ssl/misc/CA.pl
oe_multilib_header openssl/opensslconf.h
}
--
1.7.9.5
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] populate_sdk: verify executable or dynamically linked library
When toolchain directory is changed to execute mode, some non-executable
files or empty files are sorted. This will result in some errors. Thus when
sorting executable files or dynamically linked library, additional conditions
are to exclude non-executable files or empty files.
---
meta/classes/populate_sdk_base.bbclass |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/classes/populate_sdk_base.bbclass
b/meta/classes/populate_sdk_base.bbclass
index b7ea851..6b3535d 100644
--- a/meta/classes/populate_sdk_base.bbclass
+++ b/meta/classes/populate_sdk_base.bbclass
@@ -253,7 +253,7 @@ if [ $dl_path = ] ; then
echo SDK could not be set up. Relocate script unable to find
ld-linux.so. Abort!
exit 1
fi
-executable_files=$($SUDO_EXEC find $native_sysroot -type f -perm /111)
+executable_files=$($SUDO_EXEC find $native_sysroot -type f -perm +111 -exec
file '{}' \;| grep \(executable\|dynamically linked\) | cut -f 1 -d ':')
tdir=`mktemp -d`
if [ x$tdir = x ] ; then
--
1.7.9.5
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] populate_sdk: verify executable or dynamically linked library
When toolchain directory is changed to execute mode, some non-executable
files or empty files are sorted. This will result in some errors. Thus when
sorting executable files or dynamically linked library, additional conditions
are to exclude non-executable files or empty files.
---
meta/classes/populate_sdk_base.bbclass |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/classes/populate_sdk_base.bbclass
b/meta/classes/populate_sdk_base.bbclass
index b7ea851..29890e3 100644
--- a/meta/classes/populate_sdk_base.bbclass
+++ b/meta/classes/populate_sdk_base.bbclass
@@ -253,7 +253,7 @@ if [ $dl_path = ] ; then
echo SDK could not be set up. Relocate script unable to find
ld-linux.so. Abort!
exit 1
fi
-executable_files=$($SUDO_EXEC find $native_sysroot -type f -perm /111)
+executable_files=$($SUDO_EXEC find $native_sysroot -type f -perm /111 -exec
file '{}' \;| grep \(executable\|dynamically linked\) | cut -f 1 -d ':')
tdir=`mktemp -d`
if [ x$tdir = x ] ; then
--
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] populate_sdk: verify executable or dynamically linked library
Please ignore this mail since there is something wrong in the patch.
On 11/26/2013 04:24 PM, yzhu1 wrote:
When toolchain directory is changed to execute mode, some non-executable
files or empty files are sorted. This will result in some errors. Thus when
sorting executable files or dynamically linked library, additional conditions
are to exclude non-executable files or empty files.
---
meta/classes/populate_sdk_base.bbclass |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/classes/populate_sdk_base.bbclass
b/meta/classes/populate_sdk_base.bbclass
index b7ea851..6b3535d 100644
--- a/meta/classes/populate_sdk_base.bbclass
+++ b/meta/classes/populate_sdk_base.bbclass
@@ -253,7 +253,7 @@ if [ $dl_path = ] ; then
echo SDK could not be set up. Relocate script unable to find ld-linux.so.
Abort!
exit 1
fi
-executable_files=$($SUDO_EXEC find $native_sysroot -type f -perm /111)
+executable_files=$($SUDO_EXEC find $native_sysroot -type f -perm +111 -exec file '{}'
\;| grep \(executable\|dynamically linked\) | cut -f 1 -d ':')
tdir=`mktemp -d`
if [ x$tdir = x ] ; then
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] This change is based on a similar change made to e1000e support in commit bb9e44d0d0f4 (e1000e: prevent oops when adapter is being closed and reset simultaneously). The same issue
Here, we have increased the RESET_COUNT value to 50 because there are too
many accesses to e1000 nic on stress tests to e1000 nic, it is not enough
to set RESET_COUT 25. Experimentation has shown that it is enough to set
RESET_COUNT 50.
---
drivers/net/ethernet/intel/e1000/e1000.h |5 +
drivers/net/ethernet/intel/e1000/e1000_main.c |7 +++
2 files changed, 12 insertions(+)
diff --git a/drivers/net/ethernet/intel/e1000/e1000.h
b/drivers/net/ethernet/intel/e1000/e1000.h
index 26d9cd5..5c2a1b1 100644
--- a/drivers/net/ethernet/intel/e1000/e1000.h
+++ b/drivers/net/ethernet/intel/e1000/e1000.h
@@ -83,6 +83,11 @@ struct e1000_adapter;
#define E1000_MAX_INTR 10
+/*
+ * Count for polling __E1000_RESET condition every 10-20msec.
+ */
+#define E1000_CHECK_RESET_COUNT 50
+
/* TX/RX descriptor defines */
#define E1000_DEFAULT_TXD 256
#define E1000_MAX_TXD 256
diff --git a/drivers/net/ethernet/intel/e1000/e1000_main.c
b/drivers/net/ethernet/intel/e1000/e1000_main.c
index 59ad007..69c55ed 100644
--- a/drivers/net/ethernet/intel/e1000/e1000_main.c
+++ b/drivers/net/ethernet/intel/e1000/e1000_main.c
@@ -1445,7 +1445,10 @@ static int e1000_close(struct net_device *netdev)
{
struct e1000_adapter *adapter = netdev_priv(netdev);
struct e1000_hw *hw = adapter-hw;
+ int count = E1000_CHECK_RESET_COUNT;
+ while (test_bit(__E1000_RESETTING, adapter-flags) count--)
+ usleep_range(1, 2);
WARN_ON(test_bit(__E1000_RESETTING, adapter-flags));
e1000_down(adapter);
e1000_power_down_phy(adapter);
@@ -4969,6 +4972,10 @@ static int __e1000_shutdown(struct pci_dev *pdev, bool
*enable_wake)
netif_device_detach(netdev);
if (netif_running(netdev)) {
+ int count = E1000_CHECK_RESET_COUNT;
+ while (test_bit(__E1000_RESETTING, adapter-flags) count--)
+ usleep_range(1, 2);
+
WARN_ON(test_bit(__E1000_RESETTING, adapter-flags));
e1000_down(adapter);
}
--
1.7.9.5
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] e1000: prevent oops when adapter is being closed and reset simultaneously
This change is based on a similar change made to e1000e support in
commit bb9e44d0d0f4 (e1000e: prevent oops when adapter is being closed
and reset simultaneously). The same issue has also been observed
on the older e1000 cards.
Here, we have increased the RESET_COUNT value to 50 because there are too
many accesses to e1000 nic on stress tests to e1000 nic, it is not enough
to set RESET_COUT 25. Experimentation has shown that it is enough to set
RESET_COUNT 50.
---
drivers/net/ethernet/intel/e1000/e1000.h |5 +
drivers/net/ethernet/intel/e1000/e1000_main.c |7 +++
2 files changed, 12 insertions(+)
diff --git a/drivers/net/ethernet/intel/e1000/e1000.h
b/drivers/net/ethernet/intel/e1000/e1000.h
index 26d9cd5..5c2a1b1 100644
--- a/drivers/net/ethernet/intel/e1000/e1000.h
+++ b/drivers/net/ethernet/intel/e1000/e1000.h
@@ -83,6 +83,11 @@ struct e1000_adapter;
#define E1000_MAX_INTR 10
+/*
+ * Count for polling __E1000_RESET condition every 10-20msec.
+ */
+#define E1000_CHECK_RESET_COUNT 50
+
/* TX/RX descriptor defines */
#define E1000_DEFAULT_TXD 256
#define E1000_MAX_TXD 256
diff --git a/drivers/net/ethernet/intel/e1000/e1000_main.c
b/drivers/net/ethernet/intel/e1000/e1000_main.c
index 59ad007..69c55ed 100644
--- a/drivers/net/ethernet/intel/e1000/e1000_main.c
+++ b/drivers/net/ethernet/intel/e1000/e1000_main.c
@@ -1445,7 +1445,10 @@ static int e1000_close(struct net_device *netdev)
{
struct e1000_adapter *adapter = netdev_priv(netdev);
struct e1000_hw *hw = adapter-hw;
+ int count = E1000_CHECK_RESET_COUNT;
+ while (test_bit(__E1000_RESETTING, adapter-flags) count--)
+ usleep_range(1, 2);
WARN_ON(test_bit(__E1000_RESETTING, adapter-flags));
e1000_down(adapter);
e1000_power_down_phy(adapter);
@@ -4969,6 +4972,10 @@ static int __e1000_shutdown(struct pci_dev *pdev, bool
*enable_wake)
netif_device_detach(netdev);
if (netif_running(netdev)) {
+ int count = E1000_CHECK_RESET_COUNT;
+ while (test_bit(__E1000_RESETTING, adapter-flags) count--)
+ usleep_range(1, 2);
+
WARN_ON(test_bit(__E1000_RESETTING, adapter-flags));
e1000_down(adapter);
}
--
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] This change is based on a similar change made to e1000e support in commit bb9e44d0d0f4 (e1000e: prevent oops when adapter is being closed and reset simultaneously). The same is
Please ignore this mail since the title is wrong.
Thanks a lot.
Zhu Yanjun
On 11/25/2013 10:43 AM, yzhu1 wrote:
Here, we have increased the RESET_COUNT value to 50 because there are too
many accesses to e1000 nic on stress tests to e1000 nic, it is not enough
to set RESET_COUT 25. Experimentation has shown that it is enough to set
RESET_COUNT 50.
---
drivers/net/ethernet/intel/e1000/e1000.h |5 +
drivers/net/ethernet/intel/e1000/e1000_main.c |7 +++
2 files changed, 12 insertions(+)
diff --git a/drivers/net/ethernet/intel/e1000/e1000.h
b/drivers/net/ethernet/intel/e1000/e1000.h
index 26d9cd5..5c2a1b1 100644
--- a/drivers/net/ethernet/intel/e1000/e1000.h
+++ b/drivers/net/ethernet/intel/e1000/e1000.h
@@ -83,6 +83,11 @@ struct e1000_adapter;
#define E1000_MAX_INTR 10
+/*
+ * Count for polling __E1000_RESET condition every 10-20msec.
+ */
+#define E1000_CHECK_RESET_COUNT 50
+
/* TX/RX descriptor defines */
#define E1000_DEFAULT_TXD 256
#define E1000_MAX_TXD 256
diff --git a/drivers/net/ethernet/intel/e1000/e1000_main.c
b/drivers/net/ethernet/intel/e1000/e1000_main.c
index 59ad007..69c55ed 100644
--- a/drivers/net/ethernet/intel/e1000/e1000_main.c
+++ b/drivers/net/ethernet/intel/e1000/e1000_main.c
@@ -1445,7 +1445,10 @@ static int e1000_close(struct net_device *netdev)
{
struct e1000_adapter *adapter = netdev_priv(netdev);
struct e1000_hw *hw = adapter-hw;
+ int count = E1000_CHECK_RESET_COUNT;
+ while (test_bit(__E1000_RESETTING, adapter-flags) count--)
+ usleep_range(1, 2);
WARN_ON(test_bit(__E1000_RESETTING, adapter-flags));
e1000_down(adapter);
e1000_power_down_phy(adapter);
@@ -4969,6 +4972,10 @@ static int __e1000_shutdown(struct pci_dev *pdev, bool
*enable_wake)
netif_device_detach(netdev);
if (netif_running(netdev)) {
+ int count = E1000_CHECK_RESET_COUNT;
+ while (test_bit(__E1000_RESETTING, adapter-flags) count--)
+ usleep_range(1, 2);
+
WARN_ON(test_bit(__E1000_RESETTING, adapter-flags));
e1000_down(adapter);
}
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] pr-util: insert appropriate parameter to adapt libtool
On 11/18/2013 08:20 PM, Richard Purdie wrote:
On Mon, 2013-11-18 at 18:31 +0800, yanjun.zhu wrote:
When ccache is enabled, a parameter ccache is inserted.
libtool can not handle this parameter correctly. So --tag=CC
is introduced to help libtool handle it.
---
meta/recipes-support/apr/apr-util_1.5.2.bb |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/meta/recipes-support/apr/apr-util_1.5.2.bb
b/meta/recipes-support/apr/apr-util_1.5.2.bb
index ea0f7fb..d6ae394 100644
--- a/meta/recipes-support/apr/apr-util_1.5.2.bb
+++ b/meta/recipes-support/apr/apr-util_1.5.2.bb
@@ -34,6 +34,11 @@ do_configure_append() {
if [ ${CLASSOVERRIDE} = class-target ]; then
cp ${STAGING_DATADIR}/apr/apr_rules.mk ${S}/build/rules.mk
fi
+
+ # When ccache is enabled, libtool needs --tag=CC to choose correct
handle methods.
+ if [ -f ${S}/build/rules.mk ]; then
+ sed -i s,^LTFLAGS,LTFLAGS = --silent
--tag=CC\n#LTFLAGS,g ${S}/build/rules.mk
+ fi
}
do_configure_prepend_class-native() {
cp ${STAGING_DATADIR_NATIVE}/apr/apr_rules.mk ${S}/build/rules.mk
This looks like something better done with a specific patch along with
an explanation in the patch header. Is there any reason upstream
wouldn't do this?
By using a patch we ensure that when things are upgraded, the right
thing still gets done. You may need to update the apr recipe itself to
get the patch right.
Cheers,
Richard
Hi, Richard
rules.mk is copied from apr_rules.mk. apr_rules.mk is generated by
configure task.
The configure task is after patch. So it is difficult to make a patch
for this defect.
Best Regards!
Zhu Yanjun
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [oe-core][PATCH] pulseaudio_2.1: when do_compile, pulseaudio needs fftw3.h header file. In order to provide fftw3.h, the dependence of fftw is added.
On 02/02/2013 03:21 AM, Saul Wold wrote: On 01/31/2013 10:45 PM, yanjun.zhu wrote: From: yanjun.zhu yanjun@windriver.com Signed-off-by: yanjun.zhu yanjun@windriver.com --- meta/recipes-multimedia/pulseaudio/pulseaudio_2.1.bb | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/meta/recipes-multimedia/pulseaudio/pulseaudio_2.1.bb b/meta/recipes-multimedia/pulseaudio/pulseaudio_2.1.bb index a576368..5110cca 100644 --- a/meta/recipes-multimedia/pulseaudio/pulseaudio_2.1.bb +++ b/meta/recipes-multimedia/pulseaudio/pulseaudio_2.1.bb @@ -1,8 +1,8 @@ require pulseaudio.inc -PR = r15 +PR = r16 -DEPENDS += libjson gdbm speex libxml-parser-perl-native +DEPENDS += libjson gdbm speex libxml-parser-perl-native fftw This looks like a possibly host contamination issue, since oe-core itself does not provide fftw, you could instead add --without-fftw. This will ensure that fftw is not picked up from the host. Thanks Sau! OK. I will follow your advice and make a test. Thanks a lot. Zhu Yanjun inherit gettext perlnative ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [oe-core][PATCH] pulseaudio_2.1: when do_compile, pulseaudio needs fftw3.h header file. In order to provide fftw3.h, the dependence of fftw is added.
On 02/04/2013 10:52 AM, yzhu1 wrote: On 02/02/2013 03:21 AM, Saul Wold wrote: On 01/31/2013 10:45 PM, yanjun.zhu wrote: From: yanjun.zhu yanjun@windriver.com Signed-off-by: yanjun.zhu yanjun@windriver.com --- meta/recipes-multimedia/pulseaudio/pulseaudio_2.1.bb | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/meta/recipes-multimedia/pulseaudio/pulseaudio_2.1.bb b/meta/recipes-multimedia/pulseaudio/pulseaudio_2.1.bb index a576368..5110cca 100644 --- a/meta/recipes-multimedia/pulseaudio/pulseaudio_2.1.bb +++ b/meta/recipes-multimedia/pulseaudio/pulseaudio_2.1.bb @@ -1,8 +1,8 @@ require pulseaudio.inc -PR = r15 +PR = r16 -DEPENDS += libjson gdbm speex libxml-parser-perl-native +DEPENDS += libjson gdbm speex libxml-parser-perl-native fftw This looks like a possibly host contamination issue, since oe-core itself does not provide fftw, you could instead add --without-fftw. This will ensure that fftw is not picked up from the host. Thanks Sau! OK. I will follow your advice and make a test. Thanks a lot. Zhu Yanjun Hi, Saul Just now I made a test. Using --without-fftw, the file module-equalizer-sink.c which requires fftw3.h is not compiled. So this can fix this defect. Thanks a lot. Zhu Yanjun inherit gettext perlnative ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] squashfs: fix CVE-2012-4025
On 12/12/2012 12:33 PM, Saul Wold wrote:
On 12/11/2012 06:17 PM, yzhu1 wrote:
On 12/12/2012 03:04 AM, Saul Wold wrote:
On 12/11/2012 02:00 AM, yanjun.zhu wrote:
From: yanjun.zhu yanjun@windriver.com
CQID:WIND00366813
Reference: http://squashfs.git.sourceforge.net/git/gitweb.cgi?
p=squashfs/squashfs;a=patch;h=8515b3d420f502c5c0236b86e2d6d7e3b23c190e
Integer overflow in the queue_init function in unsquashfs.c in
unsquashfs in Squashfs 4.2 and earlier allows remote attackers
to execute arbitrary code via a crafted block_log field in the
superblock of a .sqsh file, leading to a heap-based buffer overflow.
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2012-4025
Signed-off-by: yanjun.zhu yanjun@windriver.com
This was merged on Nov 30th, or is shit intended for danny, possibly
denzil.
Sau!
Hi, Saul
Thanks for your reply. Maybe you are mistaken. Just now I checked the
latest
source code. This patch is not merged. Please check it again.
You are correct, the problem I encountered is that this patch did not
apply correctly or cleanly with git am, and then I checked saw that a
CVE was applied and thought that was why. I see this is 4025 vs the
older one is 4024.
Please rebase this patch and resend a v2
Thanks
Sau!
Hi, Saul
I modified the error in the patch. Now it can work.
Thanks a lot.
Zhu Yanjun
Thanks a lot.
Zhu Yanjun
[YOCTO #3564]
---
.../patches/squashfs-4.2-fix-CVE-2012-4025.patch | 190
++
...dd-a-commment-and-fix-some-other-comments.patch | 38
.../patches/squashfs-fix-open-file-limit.patch | 215
+
.../squashfs-tools/squashfs-tools_4.2.bb | 3 +
4 files changed, 446 insertions(+)
create mode 100644
meta/recipes-devtools/squashfs-tools/patches/squashfs-4.2-fix-CVE-2012-4025.patch
create mode 100644
meta/recipes-devtools/squashfs-tools/patches/squashfs-add-a-commment-and-fix-some-other-comments.patch
create mode 100644
meta/recipes-devtools/squashfs-tools/patches/squashfs-fix-open-file-limit.patch
diff --git
a/meta/recipes-devtools/squashfs-tools/patches/squashfs-4.2-fix-CVE-2012-4025.patch
b/meta/recipes-devtools/squashfs-tools/patches/squashfs-4.2-fix-CVE-2012-4025.patch
new file mode 100644
index 000..0dabfba
--- /dev/null
+++
b/meta/recipes-devtools/squashfs-tools/patches/squashfs-4.2-fix-CVE-2012-4025.patch
@@ -0,0 +1,190 @@
+Upstream-Status: Backport
+
+Reference: http://squashfs.git.sourceforge.net/git/gitweb.cgi?
+p=squashfs/squashfs;a=patch;h=8515b3d420f502c5c0236b86e2d6d7e3b23c190e
+
+Integer overflow in the queue_init function in unsquashfs.c in
+unsquashfs in Squashfs 4.2 and earlier allows remote attackers
+to execute arbitrary code via a crafted block_log field in the
+superblock of a .sqsh file, leading to a heap-based buffer overflow.
+
+http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2012-4025
+
+Signed-off-by: yanjun.zhu yanjun@windriver.com
+
+--- a/unsquashfs.c2012-11-30 17:57:57.0 +0800
b/unsquashfs.c2012-11-30 17:58:09.0 +0800
+@@ -33,6 +33,7 @@
+ #include sys/types.h
+ #include sys/time.h
+ #include sys/resource.h
++#include limits.h
+
+ struct cache *fragment_cache, *data_cache;
+ struct queue *to_reader, *to_deflate, *to_writer, *from_writer;
+@@ -138,6 +139,24 @@ void sigalrm_handler()
+ }
+
+
++int add_overflow(int a, int b)
++{
++return (INT_MAX - a) b;
++}
++
++
++int shift_overflow(int a, int shift)
++{
++return (INT_MAX shift) a;
++}
++
++
++int multiply_overflow(int a, int multiplier)
++{
++return (INT_MAX / multiplier) a;
++}
++
++
+ struct queue *queue_init(int size)
+ {
+ struct queue *queue = malloc(sizeof(struct queue));
+@@ -145,6 +164,10 @@ struct queue *queue_init(int size)
+ if(queue == NULL)
+ EXIT_UNSQUASH(Out of memory in queue_init\n);
+
++if(add_overflow(size, 1) ||
++multiply_overflow(size + 1, sizeof(void *)))
++EXIT_UNSQUASH(Size too large in queue_init\n);
++
+ queue-data = malloc(sizeof(void *) * (size + 1));
+ if(queue-data == NULL)
+ EXIT_UNSQUASH(Out of memory in queue_init\n);
+@@ -1948,13 +1971,30 @@ void initialise_threads(int fragment_buf
+ * allocate to_reader, to_deflate and to_writer queues. Set
based on
+ * open file limit and cache size, unless open file limit is
unlimited,
+ * in which case set purely based on cache limits
++ *
++ * In doing so, check that the user supplied values do not
overflow
++ * a signed int
+ */
+ if (max_files != -1) {
++if(add_overflow(data_buffer_size, max_files) ||
++add_overflow(data_buffer_size, max_files * 2))
++EXIT_UNSQUASH(Data queue size is too large\n);
++
+ to_reader = queue_init(max_files + data_buffer_size);
+ to_deflate = queue_init(max_files + data_buffer_size);
+ to_writer = queue_init(max_files * 2 + data_buffer_size);
+ } else {
+-int
Re: [OE-core] [PATCH 1/1] squashfs: fix CVE-2012-4025
On 12/12/2012 03:04 AM, Saul Wold wrote:
On 12/11/2012 02:00 AM, yanjun.zhu wrote:
From: yanjun.zhu yanjun@windriver.com
CQID:WIND00366813
Reference: http://squashfs.git.sourceforge.net/git/gitweb.cgi?
p=squashfs/squashfs;a=patch;h=8515b3d420f502c5c0236b86e2d6d7e3b23c190e
Integer overflow in the queue_init function in unsquashfs.c in
unsquashfs in Squashfs 4.2 and earlier allows remote attackers
to execute arbitrary code via a crafted block_log field in the
superblock of a .sqsh file, leading to a heap-based buffer overflow.
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2012-4025
Signed-off-by: yanjun.zhu yanjun@windriver.com
This was merged on Nov 30th, or is shit intended for danny, possibly
denzil.
Sau!
Hi, Saul
Thanks for your reply. Maybe you are mistaken. Just now I checked the
latest
source code. This patch is not merged. Please check it again.
Thanks a lot.
Zhu Yanjun
[YOCTO #3564]
---
.../patches/squashfs-4.2-fix-CVE-2012-4025.patch | 190
++
...dd-a-commment-and-fix-some-other-comments.patch | 38
.../patches/squashfs-fix-open-file-limit.patch | 215
+
.../squashfs-tools/squashfs-tools_4.2.bb | 3 +
4 files changed, 446 insertions(+)
create mode 100644
meta/recipes-devtools/squashfs-tools/patches/squashfs-4.2-fix-CVE-2012-4025.patch
create mode 100644
meta/recipes-devtools/squashfs-tools/patches/squashfs-add-a-commment-and-fix-some-other-comments.patch
create mode 100644
meta/recipes-devtools/squashfs-tools/patches/squashfs-fix-open-file-limit.patch
diff --git
a/meta/recipes-devtools/squashfs-tools/patches/squashfs-4.2-fix-CVE-2012-4025.patch
b/meta/recipes-devtools/squashfs-tools/patches/squashfs-4.2-fix-CVE-2012-4025.patch
new file mode 100644
index 000..0dabfba
--- /dev/null
+++
b/meta/recipes-devtools/squashfs-tools/patches/squashfs-4.2-fix-CVE-2012-4025.patch
@@ -0,0 +1,190 @@
+Upstream-Status: Backport
+
+Reference: http://squashfs.git.sourceforge.net/git/gitweb.cgi?
+p=squashfs/squashfs;a=patch;h=8515b3d420f502c5c0236b86e2d6d7e3b23c190e
+
+Integer overflow in the queue_init function in unsquashfs.c in
+unsquashfs in Squashfs 4.2 and earlier allows remote attackers
+to execute arbitrary code via a crafted block_log field in the
+superblock of a .sqsh file, leading to a heap-based buffer overflow.
+
+http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2012-4025
+
+Signed-off-by: yanjun.zhu yanjun@windriver.com
+
+--- a/unsquashfs.c2012-11-30 17:57:57.0 +0800
b/unsquashfs.c2012-11-30 17:58:09.0 +0800
+@@ -33,6 +33,7 @@
+ #include sys/types.h
+ #include sys/time.h
+ #include sys/resource.h
++#include limits.h
+
+ struct cache *fragment_cache, *data_cache;
+ struct queue *to_reader, *to_deflate, *to_writer, *from_writer;
+@@ -138,6 +139,24 @@ void sigalrm_handler()
+ }
+
+
++int add_overflow(int a, int b)
++{
++return (INT_MAX - a) b;
++}
++
++
++int shift_overflow(int a, int shift)
++{
++return (INT_MAX shift) a;
++}
++
++
++int multiply_overflow(int a, int multiplier)
++{
++return (INT_MAX / multiplier) a;
++}
++
++
+ struct queue *queue_init(int size)
+ {
+ struct queue *queue = malloc(sizeof(struct queue));
+@@ -145,6 +164,10 @@ struct queue *queue_init(int size)
+ if(queue == NULL)
+ EXIT_UNSQUASH(Out of memory in queue_init\n);
+
++if(add_overflow(size, 1) ||
++multiply_overflow(size + 1, sizeof(void *)))
++EXIT_UNSQUASH(Size too large in queue_init\n);
++
+ queue-data = malloc(sizeof(void *) * (size + 1));
+ if(queue-data == NULL)
+ EXIT_UNSQUASH(Out of memory in queue_init\n);
+@@ -1948,13 +1971,30 @@ void initialise_threads(int fragment_buf
+ * allocate to_reader, to_deflate and to_writer queues. Set
based on
+ * open file limit and cache size, unless open file limit is
unlimited,
+ * in which case set purely based on cache limits
++ *
++ * In doing so, check that the user supplied values do not
overflow
++ * a signed int
+ */
+ if (max_files != -1) {
++if(add_overflow(data_buffer_size, max_files) ||
++add_overflow(data_buffer_size, max_files * 2))
++EXIT_UNSQUASH(Data queue size is too large\n);
++
+ to_reader = queue_init(max_files + data_buffer_size);
+ to_deflate = queue_init(max_files + data_buffer_size);
+ to_writer = queue_init(max_files * 2 + data_buffer_size);
+ } else {
+-int all_buffers_size = fragment_buffer_size +
data_buffer_size;
++int all_buffers_size;
++
++if(add_overflow(fragment_buffer_size, data_buffer_size))
++EXIT_UNSQUASH(Data and fragment queues combined are
++ too large\n);
++
++all_buffers_size = fragment_buffer_size + data_buffer_size;
++
++if(add_overflow(all_buffers_size, all_buffers_size))
++EXIT_UNSQUASH(Data and fragment
Re: [OE-core] [PATCH 1/1] Python: Fix for CVE-2012-2135
On 12/06/2012 09:01 PM, Burton, Ross wrote: On 30 November 2012 04:30, yanjun.zhu yanjun@windriver.com wrote: The utf-16 decoder in Python 3.1 through 3.3 does not update the aligned_end variable after calling the unicode_decode_call_errorhandler function, which allows remote attackers to obtain sensitive information (process memory) or cause a denial of service (memory corruption and crash) via unspecified vectors. The source for the vulnurability says Python 3.1 to 3.3, but you're patching 2.7. Is the source not considering the Python 2 releases, or is 2.7 safe from the exploit? Ross I exploit it in Python 2.7. This CVE will affect Python2.7. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] libproxy: Fix for CVE-2012-4504
Sorry. Please ignore this mail. Thanks a lot. Zhu Yanjun On 11/30/2012 01:42 PM, yanjun.zhu wrote: From: yanjun.zhu yanjun@windriver.com Reference:https://code.google.com/p/libproxy/source/detail?r=853 Stack-based buffer overflow in the url::get_pac function in url.cpp in libproxy 0.4.x before 0.4.9 allows remote servers to have an unspecified impact via a large proxy.pac file. http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2012-4504 [YOCTO #3487] Signed-off-by: yanjun.zhu yanjun@windriver.com --- .../libproxy/libproxy/libproxy-0.4.7-CVE-2012-4504.patch | 10 ++ 1 file changed, 10 insertions(+) diff --git a/meta/recipes-support/libproxy/libproxy/libproxy-0.4.7-CVE-2012-4504.patch b/meta/recipes-support/libproxy/libproxy/libproxy-0.4.7-CVE-2012-4504.patch index 323a571..cc1d508 100644 --- a/meta/recipes-support/libproxy/libproxy/libproxy-0.4.7-CVE-2012-4504.patch +++ b/meta/recipes-support/libproxy/libproxy/libproxy-0.4.7-CVE-2012-4504.patch @@ -1,3 +1,13 @@ +Reference:https://code.google.com/p/libproxy/source/detail?r=853 + +Stack-based buffer overflow in the url::get_pac function in url.cpp +in libproxy 0.4.x before 0.4.9 allows remote servers to have an +unspecified impact via a large proxy.pac file. + +http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2012-4504 + +Signed-off-by: yanjun.zhu yanjun@windriver.com + diff -urpN a/libproxy/url.cpp b/libproxy/url.cpp --- a/libproxy/url.cpp2012-11-26 10:08:47.0 +0800 +++ b/libproxy/url.cpp2012-11-26 10:05:54.0 +0800 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
