Re: [OE-core] [PATCH] shadow: 'useradd' copies root's extended attributes

[wenzong fan]

On 01/15/2018 10:33 PM, José Bollo wrote:

On Wed, 10 Jan 2018 17:50:19 +0800
wenzong fan  wrote:


On 01/10/2018 01:01 AM, Patrick Ohly wrote:

On Fri, 2018-01-05 at 01:07 +, Fan, Wenzong wrote:

It works and will override the labels of home dir that SELinux
applied, that's the issue.

For SELinux enabled system, the user's home dir should have lavel
'user_home_dir_t' instead of 'etc_t', it prevents users from
creating files in their home dir.


Sounds like the "copy xattr" function needs to become a bit
smarter: it needs to understand some of the semantic involved and
skip those SELinux xattrs that are always meant to be set
dynamically by the running kernel.

Wenzong, which xattrs are those? Do you agree with the proposed
solution?


The xattr for selinux is "security.selinux":

$ getfattr -n security.selinux /home/t1
security.selinux="user_u:object_r:user_home_dir_t:s0-s15:c0.c1023"

I think the "attr_copy_file()" is doing right thing, but it should be
used in a limited situation, such as only for Smack ...

Thanks
Wenzong


The LSM "SELinux" is complicated enough to change label of template
files to label of instance files correctly. The approach with Smack is
different and the template files embed the expected complex hierarchy
that otherwise could only be created with a program.

A possible approach would be with smack to add a program for creating
homes. Conversely, SELinux could consider to use template approach too
instead of increasing its rules set (with templating splitted in two
parts: files and "creation" rules).


From "man 7 xattr" we know:

  - extended attributes are namespaced
  - the fully qualified name is "namespace.attribute"
  - actual namespaces are security, system, trusted, and user

A possibility would be to filter the copied extended attributes. For
SELinux we can just tell to not copy "security" attributes. See
manual of the command "tar" (recent version) that has options
--xattrs-exclude and --xattr-include.

Is there a need to copy extended attributes except for Smack?


I incline to limit the patch only for Smack with a proper bbappend, and 
maybe we'll want a distro feature as well. Both enable SELinux and Smack 
is not a normal use case, sometimes user choice Smack is because SELinux 
is too weight for their system. (except for you know a case that Smack 
can do but SELinux can't)


About how to get Smack and SELinux work together, I'm not sure if their 
communities also considered about that. Only fix the xattr issue maybe 
not enough ...


Thanks
Wenzong




Jose, can you look into updating your patch accordingly?


Perhaps yes but not now because I don't now what to do.

Best regards
Jose


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

Re: [OE-core] [PATCH] shadow: 'useradd' copies root's extended attributes

[wenzong fan]

On 01/10/2018 01:01 AM, Patrick Ohly wrote:

On Fri, 2018-01-05 at 01:07 +, Fan, Wenzong wrote:

It works and will override the labels of home dir that SELinux
applied, that's the issue.

For SELinux enabled system, the user's home dir should have lavel
'user_home_dir_t' instead of 'etc_t', it prevents users from creating
files in their home dir.


Sounds like the "copy xattr" function needs to become a bit smarter: it
needs to understand some of the semantic involved and skip those
SELinux xattrs that are always meant to be set dynamically by the
running kernel.

Wenzong, which xattrs are those? Do you agree with the proposed
solution?


The xattr for selinux is "security.selinux":

$ getfattr -n security.selinux /home/t1
security.selinux="user_u:object_r:user_home_dir_t:s0-s15:c0.c1023"

I think the "attr_copy_file()" is doing right thing, but it should be 
used in a limited situation, such as only for Smack ...


Thanks
Wenzong



Jose, can you look into updating your patch accordingly?


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

Re: [OE-core] [PATCH] shadow: 'useradd' copies root's extended attributes

[wenzong fan]

On 01/04/2018 06:41 PM, Patrick Ohly wrote:

On Thu, 2018-01-04 at 11:18 +0100, José Bollo wrote:

Do you agree to move the patch to Smack specific layer? Such as
meta-security?


I agree.


Layers like meta-security should not modify recipes from other layers,
at least not by default. That would violate the "Yocto Compatible 2.0"
rules.

Besides, it would be harder to maintain in a separate layer - for the
maintainer of that layer.

I still think this patch belong into OE-core, even though it is then
more work for the OE-core maintainer.



If so, I think we should wrapper the logic with:

+#if defined(WITH_ATTR) && !defined(WITH_SELINUX)
+  attr_copy_file (def_template, user_home, NULL, NULL);
+#endif

Or just add a new condition like WITH_SMACK or something.

Thanks
Wenzong

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

Re: [OE-core] [PATCH] shadow: 'useradd' copies root's extended attributes

[wenzong fan]

On 01/04/2018 05:28 PM, wenzong fan wrote:

Hi José Bollo,

This will override the labels of user's home directories that set by 
SELinux.


For example, if I run below command on SELinux enabled system:

$ useradd test



Sorry for the typo: s/test/t1/g to match with strace logs.

// Wenzong

SELinux will label it as "user_u:object_r:user_home_dir_t:SystemLow" 
first, and then useradd will reset the label as 
"system_u:object_r:etc_t:SystemLow".


I got strace logs below:

723   openat(AT_FDCWD, "/proc/thread-self/attr/fscreate", 
O_RDWR|O_CLOEXEC) = 11

723   write(11, "user_u:object_r:user_home_dir_t:"..., 35) = 35
723   close(11) = 0
723   mkdir("/home/t1", 000)    = 0
723   chown("/home/t1", 1000, 1000) = 0
723   chmod("/home/t1", 0755)   = 0

# SELinux labelled it as "user_home_dir_t" here.

723   llistxattr("/etc/skel", NULL, 0)  = 17
723   llistxattr("/etc/skel", "security.selinux\0", 17) = 17
723   openat(AT_FDCWD, "/etc/xattr.conf", O_RDONLY) = -1 ENOENT (No such 
file or directory)

723   lgetxattr("/etc/skel", "security.selinux", NULL, 0) = 27
723   lgetxattr("/etc/skel", "security.selinux", 
"system_u:object_r:etc_t:s0", 27) = 27
723   lsetxattr("/home/t1", "security.selinux", 
"system_u:object_r:etc_t:s0", 27, 0) = 0


# useradd reset the label as "etc_t" here.

Do you agree to move the patch to Smack specific layer? Such as 
meta-security?


Thanks
Wenzong

On 03/15/2017 04:04 PM, José Bollo wrote:

On Thu, 09 Mar 2017 18:18:05 +0100
Patrick Ohly  wrote:


On Thu, 2017-03-09 at 17:48 +0100, José Bollo wrote:

On Thu, 09 Mar 2017 17:07:54 +0100
Patrick Ohly  wrote:

Can't you reorder and rebase the patches so that this
0001-useradd.c-create-parent-directories-when-necessary.patch
applies on top of the patch which was submitted upstream?


I agree that it would be better to reorder. Better but less
conservative because an existing patch must be upgraded.


If upstream merges the proposed patch, then rebasing will be
inevitable at some point, so we might as well do the cleaner solution
now, even if the diff becomes larger.


"devtool modify shadow-native" might be useful for that. "git
rebase -i" in workspace/sources/shadow-native", then finish with
"devtool update-recipe shadow-native". I haven't tried whether
"update-recipe" handles re-ordering patches. If it doesn't, just
fix it manually.


I'll do and propose the new version soon.


Thanks!



I pushed a new version of the patch this monday. I suppose that it is
waiting for approval.

Best regards
José Bollo




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

Re: [OE-core] [PATCH] shadow: 'useradd' copies root's extended attributes

[wenzong fan]

Hi José Bollo,

This will override the labels of user's home directories that set by 
SELinux.


For example, if I run below command on SELinux enabled system:

$ useradd test

SELinux will label it as "user_u:object_r:user_home_dir_t:SystemLow" 
first, and then useradd will reset the label as 
"system_u:object_r:etc_t:SystemLow".


I got strace logs below:

723   openat(AT_FDCWD, "/proc/thread-self/attr/fscreate", 
O_RDWR|O_CLOEXEC) = 11
723   write(11, "user_u:object_r:user_home_dir_t:"..., 35) = 35 


723   close(11) = 0
723   mkdir("/home/t1", 000)= 0
723   chown("/home/t1", 1000, 1000) = 0
723   chmod("/home/t1", 0755)   = 0

# SELinux labelled it as "user_home_dir_t" here.

723   llistxattr("/etc/skel", NULL, 0)  = 17
723   llistxattr("/etc/skel", "security.selinux\0", 17) = 17
723   openat(AT_FDCWD, "/etc/xattr.conf", O_RDONLY) = -1 ENOENT (No such 
file or directory)

723   lgetxattr("/etc/skel", "security.selinux", NULL, 0) = 27
723   lgetxattr("/etc/skel", "security.selinux", 
"system_u:object_r:etc_t:s0", 27) = 27
723   lsetxattr("/home/t1", "security.selinux", 
"system_u:object_r:etc_t:s0", 27, 0) = 0


# useradd reset the label as "etc_t" here.

Do you agree to move the patch to Smack specific layer? Such as 
meta-security?


Thanks
Wenzong

On 03/15/2017 04:04 PM, José Bollo wrote:

On Thu, 09 Mar 2017 18:18:05 +0100
Patrick Ohly  wrote:


On Thu, 2017-03-09 at 17:48 +0100, José Bollo wrote:

On Thu, 09 Mar 2017 17:07:54 +0100
Patrick Ohly  wrote:

Can't you reorder and rebase the patches so that this
0001-useradd.c-create-parent-directories-when-necessary.patch
applies on top of the patch which was submitted upstream?


I agree that it would be better to reorder. Better but less
conservative because an existing patch must be upgraded.


If upstream merges the proposed patch, then rebasing will be
inevitable at some point, so we might as well do the cleaner solution
now, even if the diff becomes larger.


"devtool modify shadow-native" might be useful for that. "git
rebase -i" in workspace/sources/shadow-native", then finish with
"devtool update-recipe shadow-native". I haven't tried whether
"update-recipe" handles re-ordering patches. If it doesn't, just
fix it manually.


I'll do and propose the new version soon.


Thanks!



I pushed a new version of the patch this monday. I suppose that it is
waiting for approval.

Best regards
José Bollo


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

Re: [OE-core] [PATCH] core-image-tiny-initramfs: initramfs recipes should not generate an actual image file

[wenzong fan]

On 11/28/2017 02:00 PM, Alejandro Hernandez wrote:

Hey Wenzong,

If you are using an Intel NUC, there is a recipe in meta-intel which is 
called core-image-tiny (not initramfs), that one is exactly what you are 
asking for, it builds the core-image-tiny-initramfs and then 
automatically creates a WIC image, which would be something similar to 
manually building core-image-tiny-initramfs and then doing:


$ wic create core-image-tiny -e core-image-tiny-initramfs


Hope that helps!


Great, that's what I want.

Thank you so much!

Wenzong




Alejandro



On 11/27/2017 09:29 PM, wenzong fan wrote:

Hi Alex,

Do you have a case that generating an image with wic + tiny initramfs? 
If so could you please show me that?


I tried to create an image with below commands directly, I'm not sure 
if this is a proper test case:

$ wic create mkefidisk -e core-image-tiny-initramfs

While I booting it with USB + Intel NUC, it hangs at finding rootfs.

Thanks
Wenzong

On 09/16/2017 02:22 AM, Alejandro Hernandez wrote:
core-image-tiny-initramfs was used to generate a wic image, which was 
conceptually wrong
since initrafms recipes should only generate the boot artifacts that 
can later be used

by another recipe to generate an image using the tool of their choice.

Signed-off-by: Alejandro Hernandez 
---
  meta/recipes-core/images/core-image-tiny-initramfs.bb | 7 +++
  1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/meta/recipes-core/images/core-image-tiny-initramfs.bb 
b/meta/recipes-core/images/core-image-tiny-initramfs.bb

index 184727ddf7a..a8893d1e53e 100644
--- a/meta/recipes-core/images/core-image-tiny-initramfs.bb
+++ b/meta/recipes-core/images/core-image-tiny-initramfs.bb
@@ -1,10 +1,9 @@
  # Simple initramfs image artifact generation for tiny images.
  DESCRIPTION = "Tiny image capable of booting a device. The kernel 
includes \
  the Minimal RAM-based Initial Root Filesystem (initramfs), which 
finds the \
-first 'init' program more efficiently. core-image-tiny-initramfs 
doesn't \
+first 'init' program more efficiently. core-image-tiny-initramfs 
doesn't \
  actually generate an image but rather generates boot and rootfs 
artifacts \
-into a common location that can subsequently be picked up by 
external image \

-generation tools such as wic."
+that can subsequently be picked up by external image generation 
tools such as wic."
    PACKAGE_INSTALL = "initramfs-live-boot packagegroup-core-boot 
dropbear ${VIRTUAL-RUNTIME_base-utils} udev base-passwd 
${ROOTFS_BOOTSTRAP_INSTALL}"

  @@ -17,7 +16,7 @@ IMAGE_LINGUAS = ""
  LICENSE = "MIT"
    # don't actually generate an image, just the artifacts needed for 
one

-IMAGE_FSTYPES = "${INITRAMFS_FSTYPES} wic"
+IMAGE_FSTYPES = "${INITRAMFS_FSTYPES}"
    inherit core-image





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

Re: [OE-core] [PATCH] core-image-tiny-initramfs: initramfs recipes should not generate an actual image file

[wenzong fan]

Hi Alex,

Do you have a case that generating an image with wic + tiny initramfs? 
If so could you please show me that?


I tried to create an image with below commands directly, I'm not sure if 
this is a proper test case:

$ wic create mkefidisk -e core-image-tiny-initramfs

While I booting it with USB + Intel NUC, it hangs at finding rootfs.

Thanks
Wenzong

On 09/16/2017 02:22 AM, Alejandro Hernandez wrote:

core-image-tiny-initramfs was used to generate a wic image, which was 
conceptually wrong
since initrafms recipes should only generate the boot artifacts that can later 
be used
by another recipe to generate an image using the tool of their choice.

Signed-off-by: Alejandro Hernandez 
---
  meta/recipes-core/images/core-image-tiny-initramfs.bb | 7 +++
  1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/meta/recipes-core/images/core-image-tiny-initramfs.bb 
b/meta/recipes-core/images/core-image-tiny-initramfs.bb
index 184727ddf7a..a8893d1e53e 100644
--- a/meta/recipes-core/images/core-image-tiny-initramfs.bb
+++ b/meta/recipes-core/images/core-image-tiny-initramfs.bb
@@ -1,10 +1,9 @@
  # Simple initramfs image artifact generation for tiny images.
  DESCRIPTION = "Tiny image capable of booting a device. The kernel includes \
  the Minimal RAM-based Initial Root Filesystem (initramfs), which finds the \
-first 'init' program more efficiently.  core-image-tiny-initramfs doesn't \
+first 'init' program more efficiently. core-image-tiny-initramfs doesn't \
  actually generate an image but rather generates boot and rootfs artifacts \
-into a common location that can subsequently be picked up by external image \
-generation tools such as wic."
+that can subsequently be picked up by external image generation tools such as 
wic."
  
  PACKAGE_INSTALL = "initramfs-live-boot packagegroup-core-boot dropbear ${VIRTUAL-RUNTIME_base-utils} udev base-passwd ${ROOTFS_BOOTSTRAP_INSTALL}"
  
@@ -17,7 +16,7 @@ IMAGE_LINGUAS = ""

  LICENSE = "MIT"
  
  # don't actually generate an image, just the artifacts needed for one

-IMAGE_FSTYPES = "${INITRAMFS_FSTYPES} wic"
+IMAGE_FSTYPES = "${INITRAMFS_FSTYPES}"
  
  inherit core-image
  


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

Re: [OE-core] [PATCH 3/3] initscripts: disable mountall.sh for busybox init

[wenzong fan]

On 11/02/2017 07:41 PM, Otavio Salvador wrote:

On Thu, Nov 2, 2017 at 12:02 AM, wenzong fan  wrote:



On 11/01/2017 08:51 PM, Otavio Salvador wrote:


Hello,

On Wed, Nov 1, 2017 at 4:04 AM,   wrote:


From: Wenzong Fan 

Disable 'mountall.sh' to avoid system halt while the init manager is
set as 'busybox'.

In busybox init, the 'SIGUSR1' was handled as 'halt', calling to the
'mountall.sh' would trigger the signal with:
+ kill -USR1 1



Wouldn't be better to add the signal handler for it?



There's the handler in busybox-1.24.1/init/init.c:

  788 /* The SIGPWR/SIGUSR[12]/SIGTERM handler */
  789 static void halt_reboot_pwoff(int sig) NORETURN;
  790 static void halt_reboot_pwoff(int sig)
  791 {
  ...
  803 run_shutdown_and_kill_processes();
  ...
  817 }

I think it was intended to halt the system.


Ok; but what mountall will offer to OE-Core then?

If we use systemd, it all another way to provide the same. So why not
dropping it?



We can drop it for systemd and busybox. Actually it has been limited to 
be used with sysvinit only from the packagegroup-core-boot.bb:


+ SYSVINIT_SCRIPTS = "${@bb.utils.contains('MACHINE_FEATURES', 'rtc', 
'${VIRTUAL-RUNTIME_base-utils-hwclock}', '', d)} \

+modutils-initscripts \
+init-ifupdown \
+${VIRTUAL-RUNTIME_initscripts} \
   "

+ RDEPENDS_${PN} = "\
+ ${@bb.utils.contains("DISTRO_FEATURES", "sysvinit", 
"${SYSVINIT_SCRIPTS}", "", d)} \

+ ...
+"

Please ignore my patches, they fix the issues for "busybox + 
initscrtipts" which won't be supported again.


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

Re: [OE-core] [PATCH 3/3] initscripts: disable mountall.sh for busybox init

[wenzong fan]

On 11/01/2017 08:51 PM, Otavio Salvador wrote:

Hello,

On Wed, Nov 1, 2017 at 4:04 AM,   wrote:

From: Wenzong Fan 

Disable 'mountall.sh' to avoid system halt while the init manager is
set as 'busybox'.

In busybox init, the 'SIGUSR1' was handled as 'halt', calling to the
'mountall.sh' would trigger the signal with:
   + kill -USR1 1


Wouldn't be better to add the signal handler for it?


There's the handler in busybox-1.24.1/init/init.c:

 788 /* The SIGPWR/SIGUSR[12]/SIGTERM handler */
 789 static void halt_reboot_pwoff(int sig) NORETURN;
 790 static void halt_reboot_pwoff(int sig)
 791 {
 ...
 803 run_shutdown_and_kill_processes();
 ...
 817 }

I think it was intended to halt the system.

Thanks
Wenzong




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

Re: [OE-core] pseudo 1.8.1 doesn't work with docker & dumb-init

[wenzong fan]

On 09/02/2016 10:10 AM, Seebs wrote:

On 1 Sep 2016, at 20:33, wenzong fan wrote:


No, I didn't think it's related to any specific docker version.

I tested it on "Docker version 1.7.1, build 786b29d" & "Docker version
1.11.2, build b9f10c9".

BTW, I also tested the docker build w/o dumb-init, and the build works
...


Yeah, it's definitely specific in some way to docker.

However, it doesn't appear to be 100% reproducible; I just tried a build
with your reproducer and it completed without problems. (Unless the
problems are more subtle, and don't prevent a build.) So this one's
gonna be really fun to track down.


Yes, I believe it's not a 100 reproducible issue. Maybe you could run it 
with other builds in parallel and try it 3 times or more.


It keeps high probability on my work host which a server that shared by 
several persons, I can always get the error from 1 ~ 3 times build.


Thanks
Wenzong



-s

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

Re: [OE-core] pseudo 1.8.1 doesn't work with docker & dumb-init

[wenzong fan]

On 08/31/2016 11:48 PM, Seebs wrote:

On 31 Aug 2016, at 4:21, wenzong fan wrote:


Finally I narrowed it down to pseudo commit:


Yes, that makes sense, we expect that there'd be potential issues, but I
didn't have a reproducer for any. Thanks! I'll see whether it reproduces
for me now. Any specific version of docker I might need?


No, I didn't think it's related to any specific docker version.

I tested it on "Docker version 1.7.1, build 786b29d" & "Docker version 
1.11.2, build b9f10c9".


BTW, I also tested the docker build w/o dumb-init, and the build works ...

Thanks
Wenzong



-s


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

Re: [OE-core] pseudo 1.8.1 doesn't work with docker & dumb-init

[wenzong fan]

On 08/31/2016 11:11 PM, Joshua Lock wrote:

On Wed, 2016-08-31 at 17:21 +0800, wenzong fan wrote:

Hi Experts,

While I trying to build Yocto in Docker Container which using dumb-
init
as init system, I found the build always be stopped at some point
and
the container was terminated as well with below errors:

 Child process timeout after 2 seconds.
 Child process exit status 4: lock_held

Sometimes there's not any obvious error message.

After some `git bisect` testing, I believe the issue was started
since
commit:

--
9df3cdf42d8c1216682f497f0b166a43ef9f4184 is the first bad commit
commit 9df3cdf42d8c1216682f497f0b166a43ef9f4184
Author: Richard Purdie 
Date: Tue Jul 5 13:18:31 2016 +0100

 pseudo: Upgrade to 1.8.1

 * Drop patches where the changes exist upstream
 * Fetch from git as no tarball is available for 1.8.1
 * Move common code to pseudo.inc
 * Update patchset in git recipe

 (From OE-Core rev: 0c36984d4c501d12fa91cf7371511641585cc256)
---

Finally I narrowed it down to pseudo commit:


commit 77ee254a6c974aad9bcab2c58c9ee9e0880c9718
Author: Peter Seebach 
Date: Tue Mar 1 16:21:15 2016 -0600

 Server launch reworking.

 This is the big overhaul to have the server provide meaningful
exit
status
 to clients.

 In the process, I discovered that the server was running with
signals blocked
 if launched by a client, which is not a good thing, and
prevented
this from
 working as intended.

 Still looking to see why more than one server spawn seems to
happen.


I also created a testcase for reproducing the issue at:

 https://github.com/WenzongFan/docker-build-yocto


Thanks for providing a detailed reproducer. I'm trying to configure a
container behind my proxy here.



For dumb-init please refer to:

 https://github.com/Yelp/dumb-init

Could anyone help to fix the signal handling in pseudo?


It may not actually be pseudo at fault here. I've only skimmed the
dumb-init README but it looks like there might be a strange interaction
between the newly fixed signal handling in pseudo and dumb-init's
signal handling.

Should dumb-init be running in single-child/non-setsid mode so that
signals are only forwarded to the direct child rather than all child
processes in the dumb-init session? Is this a scenario you've tested?


Yes, I had try below options, but all of them don't work:

1) Run dumb-init with the -c flag: 
https://github.com/Yelp/dumb-init/issues/51 - single-child/non-setsid mode
2) Update dumb-init to latest version v1.1.3 (the release notes mention 
fixes for race conditions)
3) Switch to tini which an alterative to dumb-init: 
https://github.com/krallin/tini


Thanks
Wenzong



Regards,

Joshua



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

[OE-core] pseudo 1.8.1 doesn't work with docker & dumb-init

[wenzong fan]

Hi Experts,

While I trying to build Yocto in Docker Container which using dumb-init 
as init system, I found the build always be stopped at some point and 
the container was terminated as well with below errors:


Child process timeout after 2 seconds.
Child process exit status 4: lock_held

Sometimes there's not any obvious error message.

After some `git bisect` testing, I believe the issue was started since 
commit:


--
9df3cdf42d8c1216682f497f0b166a43ef9f4184 is the first bad commit
commit 9df3cdf42d8c1216682f497f0b166a43ef9f4184
Author: Richard Purdie 
Date: Tue Jul 5 13:18:31 2016 +0100

pseudo: Upgrade to 1.8.1

* Drop patches where the changes exist upstream
* Fetch from git as no tarball is available for 1.8.1
* Move common code to pseudo.inc
* Update patchset in git recipe

(From OE-Core rev: 0c36984d4c501d12fa91cf7371511641585cc256)
---

Finally I narrowed it down to pseudo commit:


commit 77ee254a6c974aad9bcab2c58c9ee9e0880c9718
Author: Peter Seebach 
Date: Tue Mar 1 16:21:15 2016 -0600

Server launch reworking.

This is the big overhaul to have the server provide meaningful exit 
status

to clients.

In the process, I discovered that the server was running with 
signals blocked
if launched by a client, which is not a good thing, and prevented 
this from

working as intended.

Still looking to see why more than one server spawn seems to happen.


I also created a testcase for reproducing the issue at:

https://github.com/WenzongFan/docker-build-yocto

For dumb-init please refer to:

https://github.com/Yelp/dumb-init

Could anyone help to fix the signal handling in pseudo?


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

Re: [OE-core] [PATCH 0/2] subversion: fix CVE-2015-3184, CVE-2015-3187

[wenzong fan]

On 11/18/2015 09:26 AM, akuster808 wrote:


On 11/16/2015 09:38 PM, wenzong@windriver.com wrote:

From: Wenzong Fan 

The following changes since commit d9aabf9639510fdb3e2ccc21ba5ae4aa9f6e4a57:

   gcc: Drop 4.8 (2015-11-16 14:59:18 +)

are available in the git repository at:

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

Wenzong Fan (2):


Thanks.


   subversion: fix CVE-2015-3184
   subversion: fix CVE-2015-3187


These two fixes only affect Apache.

Apache version < 2.4.16 will need the following fix too.

CVE-2015-3185 httpd: ap_some_auth_required() does not properly indicate
authenticated request in 2.4


apache2 has been updated to 2.4.16, it should be fixed now.

commit fe0833e87e853024c9162fae17cbaf2fbfc6a53f
Author: Roy Li 
Date:   Fri Aug 7 14:07:49 2015 +0800

apache: upgrade to 2.4.16

2.4.16 includes fixes for CVE-2015-3185, CVE-2015-0253 and 
CVE-2015-3183

remove a backport patch 0001-SECURITY-CVE-2015-0228-cve.mitre.org.patch

Signed-off-by: Roy Li 
Signed-off-by: Martin Jansa 

Thanks
Wenzong




This affects fido.

- armin




  .../subversion-CVE-2015-3184.patch | 2094 
  .../subversion-CVE-2015-3187.patch |  346 
  .../subversion/subversion_1.8.13.bb|2 +
  3 files changed, 2442 insertions(+)
  create mode 100644 
meta/recipes-devtools/subversion/subversion-1.8.13/subversion-CVE-2015-3184.patch
  create mode 100644 
meta/recipes-devtools/subversion/subversion-1.8.13/subversion-CVE-2015-3187.patch




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

Re: [OE-core] [PATCH 0/3] qemu: fix CVE-2015-5225, CVE-2015-6855, CVE-2015-7295

[wenzong fan]

On 11/16/2015 09:57 PM, Burton, Ross wrote:


On 16 November 2015 at 07:32, mailto:wenzong@windriver.com>> wrote:

Wenzong Fan (3):
   qemu: fix CVE-2015-5225
   qemu: fix CVE-2015-6855
   qemu: fix CVE-2015-7295


Master has the 2.4.0.1 upgrade now, can you rebase this series?  At
least 5225 is fixed there already.


Ok, I'll rebase them.

Thanks
Wenzong



Ross

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

Re: [OE-core] [PATCH] gstreamer1.0-plugins-bad: disable uvch264 for systemd

[wenzong fan]

On 11/14/2015 05:49 PM, Martin Jansa wrote:

On Sat, Nov 14, 2015 at 05:19:03PM +0800, wenzong fan wrote:

On 11/14/2015 04:23 PM, Martin Jansa wrote:

NAK, see
http://lists.openembedded.org/pipermail/openembedded-core/2015-November/112685.html


Hi Martin

Thanks for your reply.

If we build oe-core + systemd only (without meta-oe), it will fail with:

ERROR: Nothing PROVIDES 'libgudev' (but
/path/to/poky/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_1.4.5.bb
DEPENDS on or otherwise requires it)
ERROR: udev PROVIDES libgudev but was skipped: 'systemd' in DISTRO_FEATURES
ERROR: Required build target 'gstreamer1.0-plugins-bad' has no buildable
providers.
Missing or unbuildable dependency chain was:
['gstreamer1.0-plugins-bad', 'libgudev']

We should not get oe-core depends on meta-oe, I incline to disable
libgudev for systemd by default.


udev should provide libgudev for oe-core, but I see it was skipped:
ERROR: udev PROVIDES libgudev but was skipped: 'systemd' in DISTRO_FEATURES

How is that supposed to work when systemd is enabled as well as udev?

Does the sysvinit image nowadays use udev package from systemd recipe?


No, sysvinit image uses the independent "udev" package. But systemd 
image used the one from itself.


It may conflicts build both systemd and independent udev package:

commit e07e0f80d6c794adf154be74eca503d191c35cc6
Author: Ross Burton 
Date:   Mon Jan 21 12:15:31 2013 +

udev: skip in systemd distros, to fix world builds

(From OE-Core rev: 1179e43d67c96367480e563a36684d550d83fcbe)

Signed-off-by: Ross Burton 
Signed-off-by: Richard Purdie 

diff --git a/meta/recipes-core/udev/udev.inc 
b/meta/recipes-core/udev/udev.inc

index 9f60b17..facad0c 100644
--- a/meta/recipes-core/udev/udev.inc
+++ b/meta/recipes-core/udev/udev.inc
@@ -99,3 +99,9 @@ do_install_append () {

echo 'udev_run="/var/run/udev"' >> ${D}${sysconfdir}/udev/udev.conf
 }
+
+# As systemd also builds udev, skip this package if we're doing a 
systemd build.

+python () {
+if oe.utils.contains ('DISTRO_FEATURES', 'systemd', True, False, d):
+raise bb.parse.SkipPackage("'systemd' in DISTRO_FEATURES")
+}


Thanks
Wenzong



Regards,


Does it make sense?

Thanks
Wenzong



On Sat, Nov 14, 2015 at 7:21 AM, mailto:wenzong@windriver.com>> wrote:

 From: Wenzong Fan mailto:wenzong@windriver.com>>

 Disable uvch264 to remove the dependency to libgudev which has been
 removed from systemd project.

 Signed-off-by: Wenzong Fan mailto:wenzong@windriver.com>>
 ---
   meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad.inc | 3 ++-
   1 file changed, 2 insertions(+), 1 deletion(-)

 diff --git
 a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad.inc
 b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad.inc
 index cdedb60..863925d 100644
 --- a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad.inc
 +++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad.inc
 @@ -20,7 +20,8 @@ PACKAGECONFIG ??= " \
   ${@bb.utils.contains('DISTRO_FEATURES', 'wayland', 'wayland',
 '', d)} \
   ${@bb.utils.contains('DISTRO_FEATURES', 'bluetooth', 'bluez',
 '', d)} \
   ${@bb.utils.contains('DISTRO_FEATURES', 'directfb',
 'directfb', '', d)} \
 -orc curl uvch264 neon sndfile \
 +${@bb.utils.contains('DISTRO_FEATURES', 'systemd', '',
 'uvch264', d)} \
 +orc curl neon sndfile \
   hls sbc dash bz2 smoothstreaming \
   "

 --
 1.9.1

 --
 ___
 Openembedded-core mailing list
 Openembedded-core@lists.openembedded.org
 <mailto: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] gstreamer1.0-plugins-bad: disable uvch264 for systemd

[wenzong fan]

On 11/14/2015 04:23 PM, Martin Jansa wrote:

NAK, see
http://lists.openembedded.org/pipermail/openembedded-core/2015-November/112685.html


Hi Martin

Thanks for your reply.

If we build oe-core + systemd only (without meta-oe), it will fail with:

ERROR: Nothing PROVIDES 'libgudev' (but 
/path/to/poky/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_1.4.5.bb 
DEPENDS on or otherwise requires it)

ERROR: udev PROVIDES libgudev but was skipped: 'systemd' in DISTRO_FEATURES
ERROR: Required build target 'gstreamer1.0-plugins-bad' has no buildable 
providers.
Missing or unbuildable dependency chain was: 
['gstreamer1.0-plugins-bad', 'libgudev']


We should not get oe-core depends on meta-oe, I incline to disable 
libgudev for systemd by default.


Does it make sense?

Thanks
Wenzong



On Sat, Nov 14, 2015 at 7:21 AM, mailto:wenzong@windriver.com>> wrote:

From: Wenzong Fan mailto:wenzong@windriver.com>>

Disable uvch264 to remove the dependency to libgudev which has been
    removed from systemd project.

Signed-off-by: Wenzong Fan mailto:wenzong@windriver.com>>
---
  meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad.inc | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git
a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad.inc
b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad.inc
index cdedb60..863925d 100644
--- a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad.inc
+++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad.inc
@@ -20,7 +20,8 @@ PACKAGECONFIG ??= " \
  ${@bb.utils.contains('DISTRO_FEATURES', 'wayland', 'wayland',
'', d)} \
  ${@bb.utils.contains('DISTRO_FEATURES', 'bluetooth', 'bluez',
'', d)} \
  ${@bb.utils.contains('DISTRO_FEATURES', 'directfb',
'directfb', '', d)} \
-orc curl uvch264 neon sndfile \
+${@bb.utils.contains('DISTRO_FEATURES', 'systemd', '',
'uvch264', d)} \
+orc curl neon sndfile \
  hls sbc dash bz2 smoothstreaming \
  "

--
1.9.1

--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
<mailto: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 0/1 v2] mdadm: fix CFLAGS and ptest issues

[wenzong fan]

Patch included.

Wenzong

On 11/09/2015 09:26 AM, wenzong@windriver.com wrote:

From: Wenzong Fan 

V2 change:

* also fix another ptest error while building poky-lsb:

   raid6check.c:352:2: error: ignoring return value of posix_memalign, \
   declared with attribute warn_unused_result [-Werror=unused-result]

The following changes since commit fc45deac89ef63ca1c44e763c38ced7dfd72cbe1:

   build-appliance-image: Update to jethro head revision (2015-11-03 14:03:03 
+)

are available in the git repository at:

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

Wenzong Fan (1):
   mdadm: fix CFLAGS and ptest issues

  .../mdadm/files/mdadm-fix-ptest-build-errors.patch | 50 ++
  meta/recipes-extended/mdadm/mdadm_3.3.4.bb |  3 +-
  2 files changed, 52 insertions(+), 1 deletion(-)
  create mode 100644 
meta/recipes-extended/mdadm/files/mdadm-fix-ptest-build-errors.patch


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

Re: [OE-core] [PATCH 0/1 v2] mdadm: fix CFLAGS and ptest issues

[wenzong fan]

The patch for this thread fails to send, anyways I need to re-send them 
again.


Please ignore this cover.

Wenzong

On 11/09/2015 09:16 AM, wenzong@windriver.com wrote:

From: Wenzong Fan 

V2 change:

* also fix another ptest error while building poky-lsb:

   raid6check.c:352:2: error: ignoring return value of posix_memalign, \
   declared with attribute warn_unused_result [-Werror=unused-result]

The following changes since commit fc45deac89ef63ca1c44e763c38ced7dfd72cbe1:

   build-appliance-image: Update to jethro head revision (2015-11-03 14:03:03 
+)

are available in the git repository at:

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

Wenzong Fan (1):
   mdadm: fix CFLAGS and ptest issues

  .../mdadm/files/mdadm-fix-ptest-build-errors.patch | 50 ++
  meta/recipes-extended/mdadm/mdadm_3.3.4.bb |  3 +-
  2 files changed, 52 insertions(+), 1 deletion(-)
  create mode 100644 
meta/recipes-extended/mdadm/files/mdadm-fix-ptest-build-errors.patch


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

Re: [OE-core] [PATCH 1/1 v2] mdadm: fix CFLAGS and ptest issue

[wenzong fan]

On 11/06/2015 06:38 PM, Burton, Ross wrote:


On 16 October 2015 at 06:57, mailto:wenzong@windriver.com>> wrote:

* Also fix ptest build error caused by global CFLAGS:

   raid6check.c: In function 'check_stripes':
   raid6check.c:315:8: error: 'stripe_buf' may be used uninitialized \
   in this function [-Werror=maybe-uninitialized]


We're now seeing this instead when building the ptest part on poky-lsb
(which turns on more security flags):

raid6check.c: In function 'check_stripes':
raid6check.c:352:2: error: ignoring return value of 'posix_memalign',
declared with attribute warn_unused_result [-Werror=unused-result]
   posix_memalign((void**)&stripe_buf, 4096, raid_disks * chunk_size);


I'll fix the patch and send v2 out.

Thanks
Wenzong




(http://errors.yoctoproject.org/Errors/Details/21490/)

Ross

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

Re: [OE-core] [PATCH] openssl: fix mips64 configure support

[wenzong fan]

On 11/07/2015 03:09 PM, Khem Raj wrote:

On Fri, Nov 6, 2015 at 11:07 PM, wenzong fan  wrote:

If target name is linux-mips64, set it as linux-mips to get it build with
mips(32) userspace.


is it really building for mips32 ?




Yes, with this change, the "Configure" will pass '-mips2' to CFLAGS, 
otherwise it will pass '-mips3' which may cause build errors:


| Error: -mips3 conflicts with the other architecture options, which 
imply -mips64r2
| cryptlib.c:1:0: error: '-mips3' conflicts with the other architecture 
options, which specify a mips64r2 processor


I built it with a cav-octeon3 bsp.

Looks openssl doesn't work with mips64 userspace, I got this from git logs:

commit 858646c7bd11d1dad8c14e30f3fe6b4bd58a31b2
Author: Randy MacLeod 
Date:   Fri Dec 21 14:05:46 2012 -0500

openssl: Add mips64 configure support.

Add mips64 configure support but assume mips(32) userspace.

(From OE-Core rev: 7d775b071b902ee0de6391b2c30d36e3003643e1)

Signed-off-by: Randy MacLeod 
Signed-off-by: Mark Hatle 
Signed-off-by: Saul Wold 
Signed-off-by: Richard Purdie 

diff --git a/meta/recipes-connectivity/openssl/openssl.inc 
b/meta/recipes-connectivity/openssl/openssl.inc

index e1e7b65..af1922e 100644
--- a/meta/recipes-connectivity/openssl/openssl.inc
+++ b/meta/recipes-connectivity/openssl/openssl.inc
@@ -95,6 +95,9 @@ do_configure () {
linux-mipsel)
target=debian-mipsel
;;
+linux-*-mips64)
+   target=linux-mips
+;;
linux-powerpc)
target=linux-ppc
;;

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

Re: [OE-core] [PATCH] openssl: fix mips64 configure support

[wenzong fan]

On 11/06/2015 12:18 AM, Khem Raj wrote:



On Nov 4, 2015, at 10:09 PM, wenzong@windriver.com wrote:

From: Wenzong Fan 

Match target name linux-mips64 as well, all mips64 targets will have
mips(32) userspace.


this comment seems to be not relevant to the change



What about:

If target name is linux-mips64, set it as linux-mips to get it build 
with mips(32) userspace.


Thanks
Wenzong



Signed-off-by: Wenzong Fan 
---
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 8af423f..b69cb4c 100644
--- a/meta/recipes-connectivity/openssl/openssl.inc
+++ b/meta/recipes-connectivity/openssl/openssl.inc
@@ -115,7 +115,7 @@ do_configure () {
linux-mipsel)
target=debian-mipsel
;;
-linux-*-mips64)
+linux-*-mips64 | linux-mips64)
target=linux-mips
 ;;
linux-microblaze*|linux-nios2*)
--
1.9.1

--
___
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] gnupg: set development_version as no

[wenzong fan]

On 10/23/2015 06:40 PM, Burton, Ross wrote:


On 22 October 2015 at 10:33, mailto:wenzong@windriver.com>> wrote:

+-development_version=mym4_isbeta
++development_version=no


I'd say that a neater fix would be to change the logic in autogen,sh to
set beta=no in the find-version logic.  There's a chance you can use the
argument that taking an upstream tarball and re-running autoconf
shouldn't be considered a development release to get it upstreamed then.


Ok, I'll update the patch.

Thanks
Wenzong



Ross

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

Re: [OE-core] [PATCH] openssh: Restore TCP wrappers support

[wenzong fan]

On 10/23/2015 04:49 PM, Jussi Kukkonen wrote:

On 23 October 2015 at 10:34, mailto:wenzong@windriver.com>> wrote:

From: Wenzong Fan mailto:wenzong@windriver.com>>

The /etc/hosts.deny doesn't work for sshd without tcp-wrappers support,
apply below patch from Debian to fix it:


I get that hosts.deny not doing anything after updating is a nasty
surprise (mentioning this in the release notes certainly makes sense)
but ... is bringing tcp-wrappers-support back (especially as default)
the correct solution here?


Would it be acceptable that bringing tcp-wrappers-support back but 
disable by default?




The dependencies for this feature have been described as 'poor quality
abandonware' years ago already, and there are certainly other ways to
limit access Is there a use case where ssh+tcpwrappers is so crucial
that it warrants going against upstream opinion on security?


From users' view, it most like a change to distribution, I think this 
why Debian & Fedora get it back again.


I got below comments from Debian's contributor:

https://lwn.net/Articles/615305/

Looks it's an acceptable risk. Of course, I don't object the solution of 
update release notes.


Thanks
Wenzong



  - Jussi

   From 1850a2c93f3dcfa3d682eaa85d1593c01d170429 Mon Sep 17 00:00:00
2001
   From: Colin Watson mailto:cjwat...@debian.org>>
   Date: Tue, 7 Oct 2014 13:22:41 +0100
   Subject: Restore TCP wrappers support

   Support for TCP wrappers was dropped in OpenSSH 6.7.  See this
message
   and thread:

https://lists.mindrot.org/pipermail/openssh-unix-dev/2014-April/032497.html

   It is true that this reduces preauth attack surface in sshd.  On the
   other hand, this support seems to be quite widely used, and abruptly
   dropping it (from the perspective of users who don't read
   openssh-unix-dev) could easily cause more serious problems in
practice.
Link to patch file:
http://anonscm.debian.org/cgit/pkg-ssh/openssh.git/tree/debian/ \
     patches/restore-tcp-wrappers.patch

Signed-off-by: Wenzong Fan mailto:wenzong@windriver.com>>
---
  .../openssh/openssh/restore-tcp-wrappers.patch | 174
+
  meta/recipes-connectivity/openssh/openssh_7.1p1.bb
<http://openssh_7.1p1.bb> |   4 +
  2 files changed, 178 insertions(+)
  create mode 100644
meta/recipes-connectivity/openssh/openssh/restore-tcp-wrappers.patch

diff --git
a/meta/recipes-connectivity/openssh/openssh/restore-tcp-wrappers.patch
b/meta/recipes-connectivity/openssh/openssh/restore-tcp-wrappers.patch
new file mode 100644
index 000..1d819fa
--- /dev/null
+++
b/meta/recipes-connectivity/openssh/openssh/restore-tcp-wrappers.patch
@@ -0,0 +1,174 @@
+From 1850a2c93f3dcfa3d682eaa85d1593c01d170429 Mon Sep 17 00:00:00 2001
+From: Colin Watson mailto:cjwat...@debian.org>>
+Date: Tue, 7 Oct 2014 13:22:41 +0100
+Subject: Restore TCP wrappers support
+
+Support for TCP wrappers was dropped in OpenSSH 6.7.  See this message
+and thread:
+
+
https://lists.mindrot.org/pipermail/openssh-unix-dev/2014-April/032497.html
+
+It is true that this reduces preauth attack surface in sshd.  On the
+other hand, this support seems to be quite widely used, and abruptly
+dropping it (from the perspective of users who don't read
+openssh-unix-dev) could easily cause more serious problems in practice.
+
+It's not entirely clear what the right long-term answer for Debian is,
+but it at least probably doesn't involve dropping this feature shortly
+before a freeze.
+
+Forwarded: not-needed
+Last-Update: 2014-10-07
+
+Upstream-Status: Inappropriate
+
+Patch-Name: restore-tcp-wrappers.patch
+---
+ configure.ac <http://configure.ac> | 57
+
+ sshd.8   |  7 +++
+ sshd.c   | 25 +
+ 3 files changed, 89 insertions(+)
+
+diff --git a/configure.ac <http://configure.ac> b/configure.ac
<http://configure.ac>
+index df21693..4d55c46 100644
+--- a/configure.ac <http://configure.ac>
 b/configure.ac <http://configure.ac>
+@@ -1448,6 +1448,62 @@ AC_ARG_WITH([skey],
+   ]
+ )
+
++# Check whether user wants TCP wrappers support
++TCPW_MSG="no"
++AC_ARG_WITH([tcp-wrappers],
++  [  --with-tcp-wrappers[[=PATH]] Enable tcpwrappers support
(optionally in PATH)],
++  [
++  if test "x$withval" != "xno" ; then
++  saved_LIBS="$LIBS"
++  saved_LDFLAGS="$LDFLAGS"
++  saved_CPPFLAGS="$

Re: [OE-core] [PATCH v3] rpcbind: handle rpcbind options

[wenzong fan]

Ping again ...

Thanks
Wenzong

On 07/15/2015 02:19 PM, wenzong@windriver.com wrote:

From: Li Wang 

While runing:

$ systemctl restart rpcbind
$ systemctl status rpcbind

There are errors like below:
   rpcbind[1722]: Cannot open '/tmp/rpcbind.xdr' file for reading, \
 errno 2 (No such file or directory)
   rpcbind[1722]: Cannot open '/tmp/portmap.xdr' file for reading, \
 errno 2 (No such file or directory)

Don't pass -w to rpcbind on boot up, since the files won't be there
to be read, the patch refers to:
   https://bugs.launchpad.net/ubuntu/+source/rpcbind/+bug/835833

Signed-off-by: Li Wang 
Signed-off-by: Wenzong Fan 
---
  meta/recipes-extended/rpcbind/rpcbind/rpcbind.service | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-extended/rpcbind/rpcbind/rpcbind.service 
b/meta/recipes-extended/rpcbind/rpcbind/rpcbind.service
index b3ae254..9cdade4 100644
--- a/meta/recipes-extended/rpcbind/rpcbind/rpcbind.service
+++ b/meta/recipes-extended/rpcbind/rpcbind/rpcbind.service
@@ -5,7 +5,7 @@ Requires=rpcbind.socket
  [Service]
  Type=forking
  EnvironmentFile=-@SYSCONFDIR@/rpcbind.conf
-ExecStart=@SBINDIR@/rpcbind -w $RPCBIND_OPTS
+ExecStart=@SBINDIR@/rpcbind $RPCBIND_OPTS
  SuccessExitStatus=2

  [Install]


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

Re: [OE-core] [PATCH] bzip2: fix bunzip2 -qt returns 0 for corrupt archives

[wenzong fan]

On 10/13/2015 08:48 PM, Burton, Ross wrote:


On 13 October 2015 at 03:04, Robert Yang mailto:liezhi.y...@windriver.com>> wrote:

I wrongly thought that it was right, and we did have several
"Backport [Debian]"
in oe-core/meta, should it be a Pending or Pending [Debian], please ?


If the Debian bug/patch doesn't refer to an upstream bug, I'd suggest
Pending with a link to the debian bug# if there is one.


Ok, I'll send V2 with the updates.

Thanks
Wenzong



Ross


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

Re: [OE-core] [PATCH] mdadm: fix CFLAGS invalid issue

[wenzong fan]

Ping ...

Thanks
Wenzong

On 09/11/2015 01:51 PM, wenzong@windriver.com wrote:

From: Wenzong Fan 

* Pass global CFLAGS to build:

The CFLAGS does not pass to build at all since it was redefined by
mdadm Makefile:

   CFLAGS = $(CWFLAGS) $(CXFLAGS) ...

This could be done by setting 'CXFLAGS="${CFLAGS}"'.

* Also fix ptest build error caused by global CFLAGS:

   raid6check.c: In function 'check_stripes':
   raid6check.c:315:8: error: 'stripe_buf' may be used uninitialized \
   in this function [-Werror=maybe-uninitialized]

Signed-off-by: Wenzong Fan 
---
  .../mdadm/files/mdadm-fix-ptest-build-error.patch  | 34 ++
  meta/recipes-extended/mdadm/mdadm_3.3.4.bb |  3 +-
  2 files changed, 36 insertions(+), 1 deletion(-)
  create mode 100644 
meta/recipes-extended/mdadm/files/mdadm-fix-ptest-build-error.patch

diff --git 
a/meta/recipes-extended/mdadm/files/mdadm-fix-ptest-build-error.patch 
b/meta/recipes-extended/mdadm/files/mdadm-fix-ptest-build-error.patch
new file mode 100644
index 000..b2495c0
--- /dev/null
+++ b/meta/recipes-extended/mdadm/files/mdadm-fix-ptest-build-error.patch
@@ -0,0 +1,34 @@
+From d062030a36faa77193ac66b498a1ec704013dbb1 Mon Sep 17 00:00:00 2001
+From: Wenzong Fan 
+Date: Thu, 10 Sep 2015 03:52:20 -0400
+Subject: [PATCH] mdadm: fix ptest build error
+
+Initialize *stripe_buf as NULL to fix ptest build error:
+
+  raid6check.c: In function 'check_stripes':
+  raid6check.c:315:8: error: 'stripe_buf' may be used uninitialized \
+  in this function [-Werror=maybe-uninitialized]
+
+Upstream-Status: Pending
+
+Signed-off-by: Wenzong Fan 
+---
+ raid6check.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/raid6check.c b/raid6check.c
+index cb8522e..e4a9ff0 100644
+--- a/raid6check.c
 b/raid6check.c
+@@ -312,7 +312,7 @@ int check_stripes(struct mdinfo *info, int *source, 
unsigned long long *offsets,
+   /* read the data and p and q blocks, and check we got them right */
+   int data_disks = raid_disks - 2;
+   int syndrome_disks = data_disks + is_ddf(layout) * 2;
+-  char *stripe_buf;
++  char *stripe_buf = NULL;
+
+   /* stripes[] is indexed by raid_disk and holds chunks from each device 
*/
+   char **stripes = xmalloc(raid_disks * sizeof(char*));
+--
+1.9.1
+
diff --git a/meta/recipes-extended/mdadm/mdadm_3.3.4.bb 
b/meta/recipes-extended/mdadm/mdadm_3.3.4.bb
index 460a430..a8b4ee1 100644
--- a/meta/recipes-extended/mdadm/mdadm_3.3.4.bb
+++ b/meta/recipes-extended/mdadm/mdadm_3.3.4.bb
@@ -12,6 +12,7 @@ SRC_URI = 
"${KERNELORG_MIRROR}/linux/utils/raid/mdadm/${BPN}-${PV}.tar.xz \
 file://mdadm-3.2.2_fix_for_x32.patch \
 file://gcc-4.9.patch \
 file://mdadm-3.3.2_x32_abi_time_t.patch \
+   file://mdadm-fix-ptest-build-error.patch \
 file://run-ptest \
  "
  SRC_URI[md5sum] = "7ca8b114710f98f53f20c5787b674a09"
@@ -21,7 +22,7 @@ CFLAGS += "-fno-strict-aliasing"

  inherit autotools-brokensep

-EXTRA_OEMAKE = "CHECK_RUN_DIR=0"
+EXTRA_OEMAKE = 'CHECK_RUN_DIR=0 CXFLAGS="${CFLAGS}"'
  # PPC64 and MIPS64 uses long long for u64 in the kernel, but powerpc's 
asm/types.h
  # prevents 64-bit userland from seeing this definition, instead defaulting
  # to u64 == long in userspace. Define __SANE_USERSPACE_TYPES__ to get


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

Re: [OE-core] [PATCH] glib-2.0: cleanup buildpaths from pkgconfig files

[wenzong fan]

recall this patch, I'll send out v2 for update commit logs.

Wenzong

On 09/24/2015 07:04 PM, wenzong@windriver.com wrote:

From: Wenzong Fan 

* gio-2.0.pc:
   -L/path/to/tmp/sysroots/qemux86-64/lib64 -> -L/lib64

* gobject-2.0.pc:
   -L/path/to/tmp/sysroots/qemux86-64/usr/lib64/../lib64
 -> -L/usr/lib64/../lib64

Signed-off-by: Wenzong Fan 
---
  meta/recipes-core/glib-2.0/glib.inc | 6 ++
  1 file changed, 6 insertions(+)

diff --git a/meta/recipes-core/glib-2.0/glib.inc 
b/meta/recipes-core/glib-2.0/glib.inc
index 072f790..4ccdb93 100644
--- a/meta/recipes-core/glib-2.0/glib.inc
+++ b/meta/recipes-core/glib-2.0/glib.inc
@@ -75,6 +75,12 @@ do_install_append () {
fi
  }

+do_install_append_class-target() {
+   # cleanup buildpaths from gio-2.0.pc, gobject-2.0.pc
+   sed -i -e 's#${STAGING_DIR_HOST}##g' ${D}${libdir}/pkgconfig/gio-2.0.pc
+   sed -i -e 's#${STAGING_DIR_HOST}##g' 
${D}${libdir}/pkgconfig/gobject-2.0.pc
+}
+
  RDEPENDS_${PN}-ptest += "\
  gnome-desktop-testing \
  tzdata \


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

Re: [OE-core] [PATCH] curl: cleanup buildpaths from curl-config

[wenzong fan]

On 09/27/2015 05:45 AM, Richard Purdie wrote:

On Thu, 2015-09-24 at 07:04 -0400, wenzong@windriver.com wrote:

From: Wenzong Fan 

* curl-config:
   -L/path/to/tmp/sysroots/qemux86-64/usr/lib64 -> -L/usr/lib64
   --sysroot=/path/to/tmp/sysroots/qemux86-64'  -> --sysroot=

Signed-off-by: Wenzong Fan 
---
  meta/recipes-support/curl/curl_7.44.0.bb | 3 +++
  1 file changed, 3 insertions(+)

diff --git a/meta/recipes-support/curl/curl_7.44.0.bb 
b/meta/recipes-support/curl/curl_7.44.0.bb
index b293303..b0cf700 100644
--- a/meta/recipes-support/curl/curl_7.44.0.bb
+++ b/meta/recipes-support/curl/curl_7.44.0.bb
@@ -43,6 +43,9 @@ EXTRA_OECONF += "${@bb.utils.contains('DISTRO_FEATURES', 
'largefile', 'ac_cv_siz

  do_install_append() {
oe_multilib_header curl/curlbuild.h
+
+   # cleanup buildpaths from curl-config
+   sed -i -e 's#${STAGING_DIR_HOST}##g' ${D}${bindir}/curl-config
  }


https://autobuilder.yoctoproject.org/main/builders/nightly-deb-non-deb/builds/162

Seems curl-native doesn't build since STAGING_DIR_HOST == "".


Oh, sorry. It should be limited to do_install_append_class-target().

Please ignore this patch, I'll send out V2 for the fix.

Thanks
Wenzong



Cheers,

Richard








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

Re: [OE-core] [PATCH] gnutls: cleanup buildpaths from gnutls.pc

[wenzong fan]

On 09/24/2015 07:55 PM, Burton, Ross wrote:


On 24 September 2015 at 12:49, Jussi Kukkonen mailto:jussi.kukko...@intel.com>> wrote:

I'm not seeing this problem and gnutls.pc.in 
file looks ok to me. Any idea how I could reproduce this?


Also, just sedding them out of the resulting file seems suboptimal
compared to finding out where the path is coming from and fixing that,
so it would be good to see an analysis as to where the path comes from.
Last timeI fixed a number of those it exposed real problems or bad
assumptions in the makefiles.

Ross


For this case, or such cases that use pkg-config to compute paths for 
LIBS (such as zlib), they have different behaviors:


* multilib enabled build:

$ bitbake gnutls -cdevshell
$ pkg-config --libs zlib

-L/buildarea/raid5/wfan/yocto/builds/poky-build/tmp/sysroots/qemux86-64/usr/lib64 
-lz


* build w/o multilib

$ bitbake gnutls -cdevshell
$ pkg-config --libs zlib

-lz

This is where the buildpaths from for target pkgconfig files. Ideally it 
should be fixed from pkg-config side, but just fix it with sed is 
acceptable I think if the former is impossible.


I'll investigate more about that. Do you know where the difference from?

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

Re: [OE-core] [PATCH] gnutls: cleanup buildpaths from gnutls.pc

[wenzong fan]

On 09/24/2015 07:49 PM, Jussi Kukkonen wrote:

On 24 September 2015 at 14:04, mailto:wenzong@windriver.com>> wrote:

From: Wenzong Fan mailto:wenzong@windriver.com>>

* gnutls.pc:
   -L/path/to/tmp/sysroots/qemux86-64/lib64 -> -L/lib64


I'm not seeing this problem and gnutls.pc.in <http://gnutls.pc.in> file
looks ok to me. Any idea how I could reproduce this?


Sorry for the confusion, I'll update the commit logs.

To reproduce the issue with qemux86-64:

1. update local.conf:

MACHINE ?= "qemux86-64"
require conf/multilib.conf
MULTILIBS ?= "multilib:lib32 multilib:lib64"
DEFAULTTUNE_virtclass-multilib-lib32 ?= "x86"
DEFAULTTUNE_virtclass-multilib-lib64 ?= "x86-64"

2. run bitbake gnutls

3. check gnutls.pc:

Libs.private: 
-L/buildarea/raid5/wfan/yocto/builds/poky-build/tmp/sysroots/qemux86-64/usr/lib64 
-lz-lgmp


Thanks
Wenzong



Jussi

Signed-off-by: Wenzong Fan mailto:wenzong@windriver.com>>
---
  meta/recipes-support/gnutls/gnutls.inc | 5 +
  1 file changed, 5 insertions(+)

diff --git a/meta/recipes-support/gnutls/gnutls.inc
b/meta/recipes-support/gnutls/gnutls.inc
index e9b138a..0a5e663 100644
--- a/meta/recipes-support/gnutls/gnutls.inc
+++ b/meta/recipes-support/gnutls/gnutls.inc
@@ -38,6 +38,11 @@ PACKAGECONFIG ??= "zlib"
  PACKAGECONFIG[tpm] = "--with-tpm, --without-tpm, trousers"
  PACKAGECONFIG[zlib] = "--with-zlib, --without-zlib, zlib"

+do_install_append() {
+   # cleanup buildpaths from gnutls.pc
+   sed -i -e 's#${STAGING_DIR_HOST}##g'
${D}${libdir}/pkgconfig/gnutls.pc
+}
+
  PACKAGES =+ "${PN}-openssl ${PN}-xx"

  FILES_${PN}-dev += "${bindir}/gnutls-cli-debug"
--
1.9.1

--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
<mailto: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] openssl: fix ptest issues

[wenzong fan]

Ping ...

Thanks
Wenzong

On 08/03/2015 04:52 PM, wenzong@windriver.com wrote:

From: Wenzong Fan 

* follow symbolic links while copying sources from test/*
* install required target files to remove Make errors:

   make[2]: *** No rule to make target 'xxx', needed by 'yyy'.

* fix hardcode pathes:
   /usr/lib -> ${libdir}, /usr/bin -> ${bindir}

Signed-off-by: Wenzong Fan 
---
  meta/recipes-connectivity/openssl/openssl.inc | 14 ++
  1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/meta/recipes-connectivity/openssl/openssl.inc 
b/meta/recipes-connectivity/openssl/openssl.inc
index 53dcfd9..8d62915 100644
--- a/meta/recipes-connectivity/openssl/openssl.inc
+++ b/meta/recipes-connectivity/openssl/openssl.inc
@@ -191,12 +191,18 @@ do_install () {
  }

  do_install_ptest () {
-   cp -r Makefile test ${D}${PTEST_PATH}
+   cp -r -L Makefile.org Makefile test ${D}${PTEST_PATH}
+   cp Configure config e_os.h ${D}${PTEST_PATH}
+   cp -r -L include ${D}${PTEST_PATH}
+   ln -sf ${base_libdir}/libcrypto.a ${D}${PTEST_PATH}
+   ln -sf ${libdir}/libssl.a ${D}${PTEST_PATH}
+   mkdir -p ${D}${PTEST_PATH}/crypto
+   cp crypto/constant_time_locl.h ${D}${PTEST_PATH}/crypto
cp -r certs ${D}${PTEST_PATH}
mkdir -p ${D}${PTEST_PATH}/apps
-   ln -sf /usr/lib/ssl/misc/CA.sh  ${D}${PTEST_PATH}/apps
-   ln -sf /usr/lib/ssl/openssl.cnf ${D}${PTEST_PATH}/apps
-   ln -sf /usr/bin/openssl ${D}${PTEST_PATH}/apps
+   ln -sf ${libdir}/ssl/misc/CA.sh  ${D}${PTEST_PATH}/apps
+   ln -sf ${libdir}/ssl/openssl.cnf ${D}${PTEST_PATH}/apps
+   ln -sf ${bindir}/openssl ${D}${PTEST_PATH}/apps
cp apps/server2.pem ${D}${PTEST_PATH}/apps
mkdir -p ${D}${PTEST_PATH}/util
install util/opensslwrap.sh${D}${PTEST_PATH}/util


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

Re: [OE-core] [PATCH v2] bjam-native: build and install bjam.debug

[wenzong fan]

Ping ...

Thanks
Wenzong

On 08/04/2015 10:33 AM, wenzong@windriver.com wrote:

From: Wenzong Fan 

bjam is stripped by default, this causes QA warning while stripping it
from do_populate_sysroot():

   WARNING: File '.../tmp/sysroots/x86_64-linux/usr/bin/bjam' \
 from bjam-native was already stripped, \
 this will prevent future debugging!

The JAM scripts allow to build unstripped version with '--debug'. Just
build and install the bjam.debug to stop bjam from being stripped in
compile step.

Signed-off-by: Wenzong Fan 
---
  meta/recipes-support/boost/bjam-native_1.58.0.bb   |  5 ++-
  .../boost/files/bjam-native-build-bjam.debug.patch | 50 ++
  2 files changed, 54 insertions(+), 1 deletion(-)
  create mode 100644 
meta/recipes-support/boost/files/bjam-native-build-bjam.debug.patch

diff --git a/meta/recipes-support/boost/bjam-native_1.58.0.bb 
b/meta/recipes-support/boost/bjam-native_1.58.0.bb
index d85d1a9..32646d7 100644
--- a/meta/recipes-support/boost/bjam-native_1.58.0.bb
+++ b/meta/recipes-support/boost/bjam-native_1.58.0.bb
@@ -5,11 +5,14 @@ SECTION = "devel"

  inherit native

+SRC_URI += "file://bjam-native-build-bjam.debug.patch"
+
  do_compile() {
  ./bootstrap.sh --with-toolset=gcc
  }

  do_install() {
  install -d ${D}${bindir}/
-install -c -m 755 bjam ${D}${bindir}/
+# install unstripped version for bjam
+install -c -m 755 bjam.debug ${D}${bindir}/bjam
  }
diff --git 
a/meta/recipes-support/boost/files/bjam-native-build-bjam.debug.patch 
b/meta/recipes-support/boost/files/bjam-native-build-bjam.debug.patch
new file mode 100644
index 000..9f8b7ea
--- /dev/null
+++ b/meta/recipes-support/boost/files/bjam-native-build-bjam.debug.patch
@@ -0,0 +1,50 @@
+From 619ada314ab26c0c9cbfe5702cd9c0caa8f6415a Mon Sep 17 00:00:00 2001
+From: Wenzong Fan 
+Date: Mon, 3 Aug 2015 17:12:33 +0800
+Subject: [PATCH] bjam-native: build bjam.debug
+
+bjam is stripped by default, this causes QA warning while stripping it
+from do_populate_sysroot():
+
+  WARNING: File '.../tmp/sysroots/x86_64-linux/usr/bin/bjam' \
+from bjam-native was already stripped, \
+this will prevent future debugging!
+
+The JAM scripts allow to build unstripped version with '--debug'. Just
+build and install the bjam.debug to stop bjam from being stripped in
+compile step.
+
+Upstream-Status: Inappropriate [configuration]
+
+Signed-off-by: Wenzong Fan 
+---
+ bootstrap.sh| 1 +
+ tools/build/src/engine/build.sh | 2 +-
+ 2 files changed, 2 insertions(+), 1 deletion(-)
+
+diff --git a/bootstrap.sh b/bootstrap.sh
+index 98cf88b..54690aa 100755
+--- a/bootstrap.sh
 b/bootstrap.sh
+@@ -228,6 +228,7 @@ if test "x$BJAM" = x; then
+   echo "tools/build/src/engine/$arch/b2"
+   cp "$BJAM" .
+   cp "$my_dir/tools/build/src/engine/$arch/bjam" .
++  cp "$my_dir/tools/build/src/engine/${arch}.debug/bjam" bjam.debug
+
+ fi
+
+diff --git a/tools/build/src/engine/build.sh b/tools/build/src/engine/build.sh
+index 6dbc706..c69fdc7 100755
+--- a/tools/build/src/engine/build.sh
 b/tools/build/src/engine/build.sh
+@@ -312,5 +312,5 @@ if test -x "./bootstrap/jam0" ; then
+ if test "${BJAM_UPDATE}" != "update" ; then
+ echo_run ./bootstrap/jam0 -f build.jam --toolset=$BOOST_JAM_TOOLSET 
"--toolset-root=$BOOST_JAM_TOOLSET_ROOT" "$@" clean
+ fi
+-echo_run ./bootstrap/jam0 -f build.jam --toolset=$BOOST_JAM_TOOLSET 
"--toolset-root=$BOOST_JAM_TOOLSET_ROOT" "$@"
++echo_run ./bootstrap/jam0 -f build.jam --toolset=$BOOST_JAM_TOOLSET 
"--toolset-root=$BOOST_JAM_TOOLSET_ROOT" "$@" --debug
+ fi
+--
+1.9.1
+


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

Re: [OE-core] [PATCH] gnu-efi: Make setjmp.S portable to ARM

[wenzong fan]

On 09/07/2015 10:08 PM, Burton, Ross wrote:


On 7 September 2015 at 03:19, mailto:wenzong@windriver.com>> wrote:

+  > Note on targets where the @ character is the start of a comment
+  > (eg ARM) then another character is used instead. For example the
+  > ARM port uses the % character.


Is the documentation badly written or does this now broke the build on x86?


The lib/arm/setjmp.S is introduced by gnu-efi 3.0.3, there's not such 
assembler file in 3.0.2.


It only fails while building qemuarm target.

Thanks
Wenzong



Ross

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

Re: [OE-core] [PATCH 1/2] swig: add package 3.0.2

[wenzong fan]

On 08/20/2015 08:16 PM, Martin Jansa wrote:

On Thu, Aug 20, 2015 at 09:31:11AM +0800, wenzong fan wrote:

On 08/19/2015 09:12 PM, Martin Jansa wrote:

On Wed, Aug 19, 2015 at 03:29:28AM -0400, wenzong@windriver.com wrote:

From: Wenzong Fan 

Pull package from meta-oe to oe-core:
meta-oe commit: 8b7d90d8e4c3338f94c588fc7e4a88319bd9a9e8


There is patch for meta-oe to upgrade it to 3.0.6 (which isn't
compatible with some recipes, but fixes for that were sent as well
already).


Hi Martin,

Do you mean the fix for python-m2crypto?

commit 74de7be5a464e184fed64661e2a45f2f6fac58a5
Author: Li xin 
Date:   Thu Jul 30 18:31:25 2015 +0800

  python-m2crypto: Error fix for swig >= 3.0.5

  After swig upgrade to 3.0.6, build the recipes which
  depends on python-m2crypto will occur errors like this:
  "SALT_LEN = m2.PKCS5_SALT_LEN
  AttributeError: 'module' object has no attribute 'PKCS5_SALT_LEN'"

  Reference

https://github.com/martinpaljak/M2Crypto/issues/60#issuecomment-75735489

  Signed-off-by: Li Xin 
  Signed-off-by: Martin Jansa 
-

If the fixes are not applied to swig directly, I think this patch is OK.
I'll consider to remove swig from meta-oe next step ...


Yes and this swig upgrade:

commit 9cc54e10efa5ca70d9980f833a8e5a310e5ad21d
Author: Li xin 
Date:   Thu Jul 23 18:03:31 2015 +0800

 swig: upgrade 3.0.2 -> 3.0.6

 Signed-off-by: Li Xin 
 Signed-off-by: Martin Jansa 

both changes are now in meta-oe, so if you add swig-3.0.2 instead of
3.0.5 to oe-core then you will need to upgrade it first before removing
it from meta-oe.


Ah, yes. I'll update my patch and pick the 3.0.6 to oe-core.

Thanks
Wenzong




Thanks
Wenzong




It's required for libcap-ng to build python bindings.

With adding it to oe-core, the copies from following layers could
be removed:

* meta-oe, meta-selinux, meta-intel-iot-middleware ...

Signed-off-by: Wenzong Fan 
---
   meta/recipes-devtools/swig/swig.inc| 63 
   ...lf-exe-for-swig-swiglib-on-non-Win32-plat.patch | 69 
++
   ...nfigure-use-pkg-config-for-pcre-detection.patch | 64 
   meta/recipes-devtools/swig/swig_3.0.2.bb   |  8 +++
   4 files changed, 204 insertions(+)
   create mode 100644 meta/recipes-devtools/swig/swig.inc
   create mode 100644 
meta/recipes-devtools/swig/swig/0001-Use-proc-self-exe-for-swig-swiglib-on-non-Win32-plat.patch
   create mode 100644 
meta/recipes-devtools/swig/swig/0001-configure-use-pkg-config-for-pcre-detection.patch
   create mode 100644 meta/recipes-devtools/swig/swig_3.0.2.bb

diff --git a/meta/recipes-devtools/swig/swig.inc 
b/meta/recipes-devtools/swig/swig.inc
new file mode 100644
index 000..9821fa5
--- /dev/null
+++ b/meta/recipes-devtools/swig/swig.inc
@@ -0,0 +1,63 @@
+DESCRIPTION = "SWIG - Simplified Wrapper and Interface Generator"
+HOMEPAGE = "http://swig.sourceforge.net/";
+LICENSE = "BSD & GPLv3"
+LIC_FILES_CHKSUM = "file://LICENSE;md5=e7807a6282784a7dde4c846626b08fc6 \
+file://LICENSE-GPL;md5=d32239bcb673463ab874e80d47fae504 \
+
file://LICENSE-UNIVERSITIES;md5=8ce9dcc8f7c994de4a408b205c72ba08"
+
+SECTION = "devel"
+
+DEPENDS = "libpcre python"
+
+SRC_URI = "${SOURCEFORGE_MIRROR}/${BPN}/${BPN}-${PV}.tar.gz"
+
+inherit autotools pythonnative
+
+EXTRA_OECONF = " \
+--with-python=${PYTHON} \
+--without-allegrocl \
+--without-android \
+--without-boost \
+--without-chicken \
+--without-clisp \
+--without-csharp \
+--without-d \
+--without-gcj \
+--without-go \
+--without-guile \
+--without-java \
+--without-lua \
+--without-mzscheme \
+--without-ocaml \
+--without-octave \
+--without-perl5 \
+--without-pike \
+--without-php \
+--without-python3 \
+--without-r \
+--without-ruby \
+--without-tcl \
+"
+
+BBCLASSEXTEND = "native nativesdk"
+
+do_configure() {
+install -m 0755 ${STAGING_DATADIR_NATIVE}/gnu-config/config.guess 
${S}/Tools/config
+install -m 0755 ${STAGING_DATADIR_NATIVE}/gnu-config/config.sub 
${S}/Tools/config
+install -m 0755 ${STAGING_DATADIR_NATIVE}/gnu-config/config.guess ${S}
+install -m 0755 ${STAGING_DATADIR_NATIVE}/gnu-config/config.sub ${S}
+oe_runconf
+}
+
+do_install_append_class-nativesdk() {
+cd ${D}${bindir}
+ln -s swig swig2.0
+}
+
+def swiglib_relpath(d):
+swiglib = d.getVar('datadir', True) + "/" + d.getVar('BPN', True) + "/" + 
d.getVar('PV', True)
+return os.path.relpath(swiglib, d.getVar('bindir', True))
+
+do_install_append_class-native() {
+create_wrapper ${D}${bindir}/swig SWIG_LIB='`dirname 
$&

Re: [OE-core] [PATCH 1/2] swig: add package 3.0.2

[wenzong fan]

On 08/19/2015 09:12 PM, Martin Jansa wrote:

On Wed, Aug 19, 2015 at 03:29:28AM -0400, wenzong@windriver.com wrote:

From: Wenzong Fan 

Pull package from meta-oe to oe-core:
meta-oe commit: 8b7d90d8e4c3338f94c588fc7e4a88319bd9a9e8


There is patch for meta-oe to upgrade it to 3.0.6 (which isn't
compatible with some recipes, but fixes for that were sent as well
already).


Hi Martin,

Do you mean the fix for python-m2crypto?

commit 74de7be5a464e184fed64661e2a45f2f6fac58a5
Author: Li xin 
Date:   Thu Jul 30 18:31:25 2015 +0800

python-m2crypto: Error fix for swig >= 3.0.5

After swig upgrade to 3.0.6, build the recipes which
depends on python-m2crypto will occur errors like this:
"SALT_LEN = m2.PKCS5_SALT_LEN
AttributeError: 'module' object has no attribute 'PKCS5_SALT_LEN'"

Reference

https://github.com/martinpaljak/M2Crypto/issues/60#issuecomment-75735489

Signed-off-by: Li Xin 
Signed-off-by: Martin Jansa 
-

If the fixes are not applied to swig directly, I think this patch is OK. 
I'll consider to remove swig from meta-oe next step ...


Thanks
Wenzong




It's required for libcap-ng to build python bindings.

With adding it to oe-core, the copies from following layers could
be removed:

* meta-oe, meta-selinux, meta-intel-iot-middleware ...

Signed-off-by: Wenzong Fan 
---
  meta/recipes-devtools/swig/swig.inc| 63 
  ...lf-exe-for-swig-swiglib-on-non-Win32-plat.patch | 69 ++
  ...nfigure-use-pkg-config-for-pcre-detection.patch | 64 
  meta/recipes-devtools/swig/swig_3.0.2.bb   |  8 +++
  4 files changed, 204 insertions(+)
  create mode 100644 meta/recipes-devtools/swig/swig.inc
  create mode 100644 
meta/recipes-devtools/swig/swig/0001-Use-proc-self-exe-for-swig-swiglib-on-non-Win32-plat.patch
  create mode 100644 
meta/recipes-devtools/swig/swig/0001-configure-use-pkg-config-for-pcre-detection.patch
  create mode 100644 meta/recipes-devtools/swig/swig_3.0.2.bb

diff --git a/meta/recipes-devtools/swig/swig.inc 
b/meta/recipes-devtools/swig/swig.inc
new file mode 100644
index 000..9821fa5
--- /dev/null
+++ b/meta/recipes-devtools/swig/swig.inc
@@ -0,0 +1,63 @@
+DESCRIPTION = "SWIG - Simplified Wrapper and Interface Generator"
+HOMEPAGE = "http://swig.sourceforge.net/";
+LICENSE = "BSD & GPLv3"
+LIC_FILES_CHKSUM = "file://LICENSE;md5=e7807a6282784a7dde4c846626b08fc6 \
+file://LICENSE-GPL;md5=d32239bcb673463ab874e80d47fae504 \
+
file://LICENSE-UNIVERSITIES;md5=8ce9dcc8f7c994de4a408b205c72ba08"
+
+SECTION = "devel"
+
+DEPENDS = "libpcre python"
+
+SRC_URI = "${SOURCEFORGE_MIRROR}/${BPN}/${BPN}-${PV}.tar.gz"
+
+inherit autotools pythonnative
+
+EXTRA_OECONF = " \
+--with-python=${PYTHON} \
+--without-allegrocl \
+--without-android \
+--without-boost \
+--without-chicken \
+--without-clisp \
+--without-csharp \
+--without-d \
+--without-gcj \
+--without-go \
+--without-guile \
+--without-java \
+--without-lua \
+--without-mzscheme \
+--without-ocaml \
+--without-octave \
+--without-perl5 \
+--without-pike \
+--without-php \
+--without-python3 \
+--without-r \
+--without-ruby \
+--without-tcl \
+"
+
+BBCLASSEXTEND = "native nativesdk"
+
+do_configure() {
+install -m 0755 ${STAGING_DATADIR_NATIVE}/gnu-config/config.guess 
${S}/Tools/config
+install -m 0755 ${STAGING_DATADIR_NATIVE}/gnu-config/config.sub 
${S}/Tools/config
+install -m 0755 ${STAGING_DATADIR_NATIVE}/gnu-config/config.guess ${S}
+install -m 0755 ${STAGING_DATADIR_NATIVE}/gnu-config/config.sub ${S}
+oe_runconf
+}
+
+do_install_append_class-nativesdk() {
+cd ${D}${bindir}
+ln -s swig swig2.0
+}
+
+def swiglib_relpath(d):
+swiglib = d.getVar('datadir', True) + "/" + d.getVar('BPN', True) + "/" + 
d.getVar('PV', True)
+return os.path.relpath(swiglib, d.getVar('bindir', True))
+
+do_install_append_class-native() {
+create_wrapper ${D}${bindir}/swig SWIG_LIB='`dirname 
$''realpath`'/${@swiglib_relpath(d)}
+}
diff --git 
a/meta/recipes-devtools/swig/swig/0001-Use-proc-self-exe-for-swig-swiglib-on-non-Win32-plat.patch
 
b/meta/recipes-devtools/swig/swig/0001-Use-proc-self-exe-for-swig-swiglib-on-non-Win32-plat.patch
new file mode 100644
index 000..81df3e2
--- /dev/null
+++ 
b/meta/recipes-devtools/swig/swig/0001-Use-proc-self-exe-for-swig-swiglib-on-non-Win32-plat.patch
@@ -0,0 +1,69 @@
+From a4a0440a644c6c5e5da096efe3cf05ba309a284f Mon Sep 17 00:00:00 2001
+From: "NODA, Kai" 
+Date: Sun, 22 Apr 2012 17:01:02 +0900
+Subject: [PATCH] Use /proc/self

Re: [OE-core] [PATCH] bjam-native: inhibit sysroot strip

[wenzong fan]

On 08/09/2015 07:52 AM, Khem Raj wrote:



On Jul 30, 2015, at 12:40 AM, wenzong fan  wrote:

On 07/29/2015 06:19 PM, Burton, Ross wrote:


On 29 July 2015 at 08:34, mailto:wenzong@windriver.com>> wrote:

+# bjam is already stripped, don't strip it again
+INHIBIT_SYSROOT_STRIP = "1"


In case it's even needed to debug bjam-native, how hard would it be to
stop bjam from being stripped in the first place?


By default, a release version is stripped, we could build & install the debug 
version for bjam.

For specific changes, we only need to append "--debug" to build.sh, then update 
do_install() to select the unstripped version.

Do you think this is the right ways?



export INSTALL=“install” or something like that might do it. usually folks use 
install -s by default during install step which cause such issues.


The bjam is stripped while compiling via gcc options '-s'. There are 
three build types defined in build.jam:


...
[ opt --release : [ opt --symbols : -g : -s ] -O3 ]
[ opt --debug : -g -O0 -fno-inline ]
[ opt --profile : -O3 -g -pg ]
...

Build & install "debug" version would provide unstripped bjam for 
further stripping. I have sent V2 patch:


[OE-core] [PATCH v2] bjam-native: build and install bjam.debug

Thanks
Wenzong




Thanks
Wenzong



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] bjam-native: inhibit sysroot strip

[wenzong fan]

On 07/29/2015 06:19 PM, Burton, Ross wrote:


On 29 July 2015 at 08:34, mailto:wenzong@windriver.com>> wrote:

+# bjam is already stripped, don't strip it again
+INHIBIT_SYSROOT_STRIP = "1"


In case it's even needed to debug bjam-native, how hard would it be to
stop bjam from being stripped in the first place?


By default, a release version is stripped, we could build & install the 
debug version for bjam.


For specific changes, we only need to append "--debug" to build.sh, then 
update do_install() to select the unstripped version.


Do you think this is the right ways?

Thanks
Wenzong



Ross

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

Re: [OE-core] [PATCH 0/1] util-linux: add runuser PAM config files

[wenzong fan]

Ping again ...

On 05/15/2015 01:29 PM, Shan Hai wrote:


Add PAM config files for util-linux to fix a runtime failure of the
runuser command.

meta/recipes-core/util-linux/util-linux.inc| 8 
  meta/recipes-core/util-linux/util-linux/runuser-l.pamd | 4 
  meta/recipes-core/util-linux/util-linux/runuser.pamd   | 5 +
  meta/recipes-core/util-linux/util-linux_2.24.2.bb  | 2 ++
  4 files changed, 19 insertions(+)
  create mode 100644 meta/recipes-core/util-linux/util-linux/runuser-l.pamd
  create mode 100644 meta/recipes-core/util-linux/util-linux/runuser.pamd

Thanks
Shan Hai


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

Re: [OE-core] [PATCH] nfs-utils: debianize start-statd

[wenzong fan]

On 07/24/2015 04:08 PM, wenzong fan wrote:

Ping ...


Please ignore the "ping" request, this one has been merged.

Thanks
Wenzong



On 06/29/2015 02:22 PM, wenzong@windriver.com wrote:

From: Li Wang 

make start-statd command to use nfscommon configure, too.

Signed-off-by: Henrik Riomar 
Signed-off-by: Li Wang 
Signed-off-by: Roy Li 
Signed-off-by: Wenzong Fan 
---
  .../files/nfs-utils-debianize-start-statd.patch| 41
++
  .../nfs-utils/nfs-utils_1.3.1.bb   |  1 +
  2 files changed, 42 insertions(+)
  create mode 100644
meta/recipes-connectivity/nfs-utils/files/nfs-utils-debianize-start-statd.patch


diff --git
a/meta/recipes-connectivity/nfs-utils/files/nfs-utils-debianize-start-statd.patch
b/meta/recipes-connectivity/nfs-utils/files/nfs-utils-debianize-start-statd.patch

new file mode 100644
index 000..5a2d5c8
--- /dev/null
+++
b/meta/recipes-connectivity/nfs-utils/files/nfs-utils-debianize-start-statd.patch

@@ -0,0 +1,41 @@
+[PATCH] nfs-utils: debianize start-statd
+
+Upstream-status: Pending
+
+make start-statd command to use nfscommon configure, too.
+
+Signed-off-by: Henrik Riomar 
+Signed-off-by: Li Wang 
+Signed-off-by: Roy Li 
+Signed-off-by: Wenzong Fan 
+---
+ utils/statd/start-statd | 9 -
+ 1 file changed, 8 insertions(+), 1 deletion(-)
+
+diff --git a/utils/statd/start-statd b/utils/statd/start-statd
+index ec9383b..3969b8c 100755
+--- a/utils/statd/start-statd
 b/utils/statd/start-statd
+@@ -6,6 +6,13 @@
+ # site.
+ PATH="/sbin:/usr/sbin:/bin:/usr/bin"
+
++# Read config
++DEFAULTFILE=/etc/default/nfs-common
++NEED_IDMAPD=
++if [ -f $DEFAULTFILE ]; then
++. $DEFAULTFILE
++fi
++
+ # First try systemd if it's installed.
+ if systemctl --help >/dev/null 2>&1; then
+ # Quit only if the call worked.
+@@ -13,4 +20,4 @@ if systemctl --help >/dev/null 2>&1; then
+ fi
+
+ # Fall back to launching it ourselves.
+-exec rpc.statd --no-notify
++exec rpc.statd --no-notify $STATDOPTS
+--
+1.9.1
+
diff --git a/meta/recipes-connectivity/nfs-utils/nfs-utils_1.3.1.bb
b/meta/recipes-connectivity/nfs-utils/nfs-utils_1.3.1.bb
index 6f64e9d..0bcd65e 100644
--- a/meta/recipes-connectivity/nfs-utils/nfs-utils_1.3.1.bb
+++ b/meta/recipes-connectivity/nfs-utils/nfs-utils_1.3.1.bb
@@ -29,6 +29,7 @@ SRC_URI =
"${KERNELORG_MIRROR}/linux/utils/nfs-utils/${PV}/nfs-utils-${PV}.tar.x
 file://nfs-mountd.service \
 file://nfs-statd.service \

file://nfs-utils-Do-not-pass-CFLAGS-to-gcc-while-building.patch \
+   file://nfs-utils-debianize-start-statd.patch \
  "

  SRC_URI[md5sum] = "8de676b9ff34b8f9addc1d0800fabdf8"





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

Re: [OE-core] [PATCH] grub: Add support for net_default_mac and net_default_ip variables

[wenzong fan]

Ping ...

On 07/07/2015 04:14 PM, wenzong@windriver.com wrote:

From: Lijun Guo 

Using "-c" parameter, grub-mkimage can embed a configuration file into
the grub image. However grub 2.0 doesn't support net_default_mac and
net_default_ip variables in the configuration file.

Backport upstream commit to fix the issue:
* commit id: 2aa072d76a9c7df837a6a81bf80958094a522740

Signed-off-by: Lijun Guo 
---
  ...-to-determine-MAC-IP-of-default-interface.patch | 127 +
  meta/recipes-bsp/grub/grub2.inc|   1 +
  2 files changed, 128 insertions(+)
  create mode 100644 
meta/recipes-bsp/grub/files/New-variables-to-determine-MAC-IP-of-default-interface.patch

diff --git 
a/meta/recipes-bsp/grub/files/New-variables-to-determine-MAC-IP-of-default-interface.patch
 
b/meta/recipes-bsp/grub/files/New-variables-to-determine-MAC-IP-of-default-interface.patch
new file mode 100644
index 000..b1b028e
--- /dev/null
+++ 
b/meta/recipes-bsp/grub/files/New-variables-to-determine-MAC-IP-of-default-interface.patch
@@ -0,0 +1,127 @@
+From 2aa072d76a9c7df837a6a81bf80958094a522740 Mon Sep 17 00:00:00 2001
+From: Vladimir 'phcoder' Serbinenko 
+Date: Tue, 7 May 2013 12:05:36 +0200
+Subject: [PATCH] New variables 'net_default_*' to determine MAC/IP of
+ default interface.
+
+commit 2aa072d76a9c7df837a6a81bf80958094a522740 upstream
+
+Upstream-Status: Backport
+
+Signed-off-by: Lijun Guo 
+
+---
+ grub-core/net/bootp.c |  3 +++
+ grub-core/net/net.c   | 69 ++-
+ 2 files changed, 71 insertions(+), 1 deletion(-)
+
+diff --git a/grub-core/net/bootp.c b/grub-core/net/bootp.c
+index 33f860a..c8ef4d6 100644
+--- a/grub-core/net/bootp.c
 b/grub-core/net/bootp.c
+@@ -211,6 +211,9 @@ grub_net_configure_by_dhcp_ack (const char *name,
+   grub_print_error ();
+ }
+
++  if (is_def)
++grub_env_set ("net_default_interface", name);
++
+   if (device && !*device && bp->server_ip)
+ {
+   *device = grub_xasprintf ("tftp,%d.%d.%d.%d",
+diff --git a/grub-core/net/net.c b/grub-core/net/net.c
+index aebbe4b..8ea6906 100644
+--- a/grub-core/net/net.c
 b/grub-core/net/net.c
+@@ -1,6 +1,6 @@
+ /*
+  *  GRUB  --  GRand Unified Bootloader
+- *  Copyright (C) 2010,2011  Free Software Foundation, Inc.
++ *  Copyright (C) 2010,2011,2012,2013  Free Software Foundation, Inc.
+  *
+  *  GRUB is free software: you can redistribute it and/or modify
+  *  it under the terms of the GNU General Public License as published by
+@@ -813,6 +813,69 @@ defserver_get_env (struct grub_env_var *var __attribute__ 
((unused)),
+   return grub_net_default_server ? : "";
+ }
+
++static const char *
++defip_get_env (struct grub_env_var *var __attribute__ ((unused)),
++ const char *val __attribute__ ((unused)))
++{
++  const char *intf = grub_env_get ("net_default_interface");
++  const char *ret = NULL;
++  if (intf)
++{
++  char *buf = grub_xasprintf ("net_%s_ip", intf);
++  if (buf)
++  ret = grub_env_get (buf);
++  grub_free (buf);
++}
++  return ret;
++}
++
++static char *
++defip_set_env (struct grub_env_var *var __attribute__ ((unused)),
++ const char *val)
++{
++  const char *intf = grub_env_get ("net_default_interface");
++  if (intf)
++{
++  char *buf = grub_xasprintf ("net_%s_ip", intf);
++  if (buf)
++  grub_env_set (buf, val);
++  grub_free (buf);
++}
++  return NULL;
++}
++
++
++static const char *
++defmac_get_env (struct grub_env_var *var __attribute__ ((unused)),
++ const char *val __attribute__ ((unused)))
++{
++  const char *intf = grub_env_get ("net_default_interface");
++  const char *ret = NULL;
++  if (intf)
++{
++  char *buf = grub_xasprintf ("net_%s_mac", intf);
++  if (buf)
++  ret = grub_env_get (buf);
++  grub_free (buf);
++}
++  return ret;
++}
++
++static char *
++defmac_set_env (struct grub_env_var *var __attribute__ ((unused)),
++ const char *val)
++{
++  const char *intf = grub_env_get ("net_default_interface");
++  if (intf)
++{
++  char *buf = grub_xasprintf ("net_%s_mac", intf);
++  if (buf)
++  grub_env_set (buf, val);
++  grub_free (buf);
++}
++  return NULL;
++}
++
+
+ static void
+ grub_net_network_level_interface_register (struct 
grub_net_network_level_interface *inter)
+@@ -1560,6 +1623,10 @@ GRUB_MOD_INIT(net)
+  defserver_set_env);
+   grub_register_variable_hook ("pxe_default_server", defserver_get_env,
+  defserver_set_env);
++  grub_register_variable_hook ("net_default_ip", defip_get_env,
++ defip_set_env);
++  grub_register_variable_hook ("net_default_mac", defmac_get_env,
++ defmac_set_env);
+
+   cmd_addaddr = grub_register_command ("net_add_addr", grub_cmd_addaddr,
+   /* TRANSLATORS: HWADDRESS stands for
+--
+1.8.5.2.233.g932f7e4
+

Re: [OE-core] [PATCH] nfs-utils: debianize start-statd

[wenzong fan]

Ping ...

On 06/29/2015 02:22 PM, wenzong@windriver.com wrote:

From: Li Wang 

make start-statd command to use nfscommon configure, too.

Signed-off-by: Henrik Riomar 
Signed-off-by: Li Wang 
Signed-off-by: Roy Li 
Signed-off-by: Wenzong Fan 
---
  .../files/nfs-utils-debianize-start-statd.patch| 41 ++
  .../nfs-utils/nfs-utils_1.3.1.bb   |  1 +
  2 files changed, 42 insertions(+)
  create mode 100644 
meta/recipes-connectivity/nfs-utils/files/nfs-utils-debianize-start-statd.patch

diff --git 
a/meta/recipes-connectivity/nfs-utils/files/nfs-utils-debianize-start-statd.patch
 
b/meta/recipes-connectivity/nfs-utils/files/nfs-utils-debianize-start-statd.patch
new file mode 100644
index 000..5a2d5c8
--- /dev/null
+++ 
b/meta/recipes-connectivity/nfs-utils/files/nfs-utils-debianize-start-statd.patch
@@ -0,0 +1,41 @@
+[PATCH] nfs-utils: debianize start-statd
+
+Upstream-status: Pending
+
+make start-statd command to use nfscommon configure, too.
+
+Signed-off-by: Henrik Riomar 
+Signed-off-by: Li Wang 
+Signed-off-by: Roy Li 
+Signed-off-by: Wenzong Fan 
+---
+ utils/statd/start-statd | 9 -
+ 1 file changed, 8 insertions(+), 1 deletion(-)
+
+diff --git a/utils/statd/start-statd b/utils/statd/start-statd
+index ec9383b..3969b8c 100755
+--- a/utils/statd/start-statd
 b/utils/statd/start-statd
+@@ -6,6 +6,13 @@
+ # site.
+ PATH="/sbin:/usr/sbin:/bin:/usr/bin"
+
++# Read config
++DEFAULTFILE=/etc/default/nfs-common
++NEED_IDMAPD=
++if [ -f $DEFAULTFILE ]; then
++. $DEFAULTFILE
++fi
++
+ # First try systemd if it's installed.
+ if systemctl --help >/dev/null 2>&1; then
+ # Quit only if the call worked.
+@@ -13,4 +20,4 @@ if systemctl --help >/dev/null 2>&1; then
+ fi
+
+ # Fall back to launching it ourselves.
+-exec rpc.statd --no-notify
++exec rpc.statd --no-notify $STATDOPTS
+--
+1.9.1
+
diff --git a/meta/recipes-connectivity/nfs-utils/nfs-utils_1.3.1.bb 
b/meta/recipes-connectivity/nfs-utils/nfs-utils_1.3.1.bb
index 6f64e9d..0bcd65e 100644
--- a/meta/recipes-connectivity/nfs-utils/nfs-utils_1.3.1.bb
+++ b/meta/recipes-connectivity/nfs-utils/nfs-utils_1.3.1.bb
@@ -29,6 +29,7 @@ SRC_URI = 
"${KERNELORG_MIRROR}/linux/utils/nfs-utils/${PV}/nfs-utils-${PV}.tar.x
 file://nfs-mountd.service \
 file://nfs-statd.service \
 file://nfs-utils-Do-not-pass-CFLAGS-to-gcc-while-building.patch \
+   file://nfs-utils-debianize-start-statd.patch \
  "

  SRC_URI[md5sum] = "8de676b9ff34b8f9addc1d0800fabdf8"


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

Re: [OE-core] [PATCH v3] rpcbind: handle rpcbind options

[wenzong fan]

Ping ...

On 07/15/2015 02:19 PM, wenzong@windriver.com wrote:

From: Li Wang 

While runing:

$ systemctl restart rpcbind
$ systemctl status rpcbind

There are errors like below:
   rpcbind[1722]: Cannot open '/tmp/rpcbind.xdr' file for reading, \
 errno 2 (No such file or directory)
   rpcbind[1722]: Cannot open '/tmp/portmap.xdr' file for reading, \
 errno 2 (No such file or directory)

Don't pass -w to rpcbind on boot up, since the files won't be there
to be read, the patch refers to:
   https://bugs.launchpad.net/ubuntu/+source/rpcbind/+bug/835833

Signed-off-by: Li Wang 
Signed-off-by: Wenzong Fan 
---
  meta/recipes-extended/rpcbind/rpcbind/rpcbind.service | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-extended/rpcbind/rpcbind/rpcbind.service 
b/meta/recipes-extended/rpcbind/rpcbind/rpcbind.service
index b3ae254..9cdade4 100644
--- a/meta/recipes-extended/rpcbind/rpcbind/rpcbind.service
+++ b/meta/recipes-extended/rpcbind/rpcbind/rpcbind.service
@@ -5,7 +5,7 @@ Requires=rpcbind.socket
  [Service]
  Type=forking
  EnvironmentFile=-@SYSCONFDIR@/rpcbind.conf
-ExecStart=@SBINDIR@/rpcbind -w $RPCBIND_OPTS
+ExecStart=@SBINDIR@/rpcbind $RPCBIND_OPTS
  SuccessExitStatus=2

  [Install]


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

Re: [OE-core] [PATCH 1/1 v2] rpcbind: handle rpcbind options

[wenzong fan]

On 07/14/2015 07:14 PM, Burton, Ross wrote:


On 13 July 2015 at 06:25, mailto:wenzong@windriver.com>> wrote:

-EnvironmentFile=-@SYSCONFDIR@/rpcbind.conf
+EnvironmentFile=@SYSCONFDIR@/rpcbind.conf


Did you intend to drop the - from the EnvironmentFile statement?  I'm
guessing not.



No, I didn't.

I have sent V3 for clean this change.

Thanks
Wenzong


Ross

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

Re: [OE-core] [PATCH 1/1] rpcbind: handle rpcbind options

[wenzong fan]

On 07/10/2015 10:16 PM, Richard Purdie wrote:

On Fri, 2015-07-10 at 13:36 +0800, wenzong@windriver.com wrote:

From: Li Wang 

the patch refers to:
https://bugs.launchpad.net/ubuntu/+source/rpcbind/+bug/835833

Run test:
$ systemctl restart rpcbind
$ systemctl status rpcbind



I shouldn't have to follow a link to figure out what the patch is for,
why or how. Please improve the commit message.


Ok, I have updated the commit message and re-sent V2 both for:

[OE-core] [PATCH 1/1 v2] rpcbind: handle rpcbind options
[OE-core] [PATCH 1/1 v2] netbase: add rpcbind as an alias to sunrpc

Thanks
Wenzong



Cheers,

Richard



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

Re: [OE-core] [PATCH][meta-perl] libxml-libxml-perl: update from 2.0116 to 2.0121

[wenzong fan]

On 07/10/2015 05:15 PM, Burton, Ross wrote:

meta-perl patches go to openembedded-devel list.


Sorry for the wrong post, I'll re-send it to oe-devel list.

Wenzong



Ross

On 10 July 2015 at 10:07, mailto:wenzong@windriver.com>> wrote:

From: Wenzong Fan mailto:wenzong@windriver.com>>

    Signed-off-by: Wenzong Fan mailto:wenzong@windriver.com>>
---
  .../libxml/libxml-libxml-perl_2.0116.bb
<http://libxml-libxml-perl_2.0116.bb>| 47
--
  .../libxml/libxml-libxml-perl_2.0121.bb
<http://libxml-libxml-perl_2.0121.bb>| 47
++
  2 files changed, 47 insertions(+), 47 deletions(-)
  delete mode 100644
meta-perl/recipes-perl/libxml/libxml-libxml-perl_2.0116.bb
<http://libxml-libxml-perl_2.0116.bb>
  create mode 100644
meta-perl/recipes-perl/libxml/libxml-libxml-perl_2.0121.bb
<http://libxml-libxml-perl_2.0121.bb>

diff --git
a/meta-perl/recipes-perl/libxml/libxml-libxml-perl_2.0116.bb
<http://libxml-libxml-perl_2.0116.bb>
b/meta-perl/recipes-perl/libxml/libxml-libxml-perl_2.0116.bb
<http://libxml-libxml-perl_2.0116.bb>
deleted file mode 100644
index 2a6dbc2..000
--- a/meta-perl/recipes-perl/libxml/libxml-libxml-perl_2.0116.bb
<http://libxml-libxml-perl_2.0116.bb>
+++ /dev/null
@@ -1,47 +0,0 @@
-SUMMARY = "Perl interface to the libxml2 library"
-DESCRIPTION = "This module is an interface to libxml2, providing
XML and HTML parsers \
-with DOM, SAX and XMLReader interfaces, a large subset of DOM Layer 3 \
-interface and a XML::XPath-like interface to XPath API of libxml2. \
-The module is split into several packages which are not described
in this \
-section; unless stated otherwise, you only need to use XML::LibXML;
in \
-your programs."
-
-HOMEPAGE = "http://search.cpan.org/dist/XML-LibXML-1.99/";
-SECTION = "libs"
-LICENSE = "Artistic-1.0|GPLv1+"
-DEPENDS += "libxml2 \
-libxml-sax-perl-native \
-zlib \
-"
-RDEPENDS_${PN} += "libxml2 \
-libxml-sax-perl \
-libxml-sax-base-perl \
-zlib \
-"
-
-SRC_URI =

"http://search.cpan.org/CPAN/authors/id/S/SH/SHLOMIF/XML-LibXML-${PV}.tar.gz;name=libxml
\
-   file://disable-libxml2-check.patch \
-   file://fix-CATALOG-conditional-compile.patch \
-   file://using-DOCB-conditional.patch \
-"
-LIC_FILES_CHKSUM =
"file://debian/copyright;md5=75e021e35a906347f46c9ff163653e2a \
-
  file://LICENSE;md5=97871bde150daeb5e61ad95137ff2446"
-SRC_URI[libxml.md5sum] = "a53a743bf053a0cb4afb41513fb8a684"
-SRC_URI[libxml.sha256sum] =
"b154f2dad3033b30d22ac81b8985b69ad35450b0c552db394cd03bb36845812a"
-
-S = "${WORKDIR}/XML-LibXML-${PV}"
-
-inherit cpan
-
-EXTRA_CPANFLAGS = "INC=-I${STAGING_INCDIR}/libxml2
LIBS=-L${STAGING_LIBDIR}"
-
-BBCLASSEXTEND = "native"
-
-CFLAGS += " -D_GNU_SOURCE "
-BUILD_CFLAGS += " -D_GNU_SOURCE "
-
-do_configure_prepend() {
-   rm -rf ${S}/.pc/*
-}
-
-FILES_${PN}-dbg =+
"${libdir}/perl/vendor_perl/*/auto/XML/LibXML/.debug/"
diff --git
a/meta-perl/recipes-perl/libxml/libxml-libxml-perl_2.0121.bb
<http://libxml-libxml-perl_2.0121.bb>
b/meta-perl/recipes-perl/libxml/libxml-libxml-perl_2.0121.bb
<http://libxml-libxml-perl_2.0121.bb>
new file mode 100644
index 000..9066000
--- /dev/null
+++ b/meta-perl/recipes-perl/libxml/libxml-libxml-perl_2.0121.bb
<http://libxml-libxml-perl_2.0121.bb>
@@ -0,0 +1,47 @@
+SUMMARY = "Perl interface to the libxml2 library"
+DESCRIPTION = "This module is an interface to libxml2, providing
XML and HTML parsers \
+with DOM, SAX and XMLReader interfaces, a large subset of DOM Layer 3 \
+interface and a XML::XPath-like interface to XPath API of libxml2. \
+The module is split into several packages which are not described
in this \
+section; unless stated otherwise, you only need to use XML::LibXML;
in \
+your programs."
+
+HOMEPAGE = "http://search.cpan.org/dist/XML-LibXML-1.99/";
+SECTION = "libs"
+LICENSE = "Artistic-1.0|GPLv1+"
+DEPENDS += "libxml2 \
+libxml-sax-perl-native \
+zlib \
+"
+RDEPENDS_${PN} += "libxml2 \
+libxml-sax-perl \
+libxml-sax-base-perl \
+zlib \
+"
+
+SRC_URI =

"http://search.cpan.org/CPAN/authors/id/S/SH/SHLOMIF/XML-LibXML-${PV}.tar.gz;name=libxm

Re: [OE-core] [PATCH] Fix packet discards HTTP redirect.

[wenzong fan]

On 07/08/2015 10:12 PM, Burton, Ross wrote:

As per our commit guidelines, the commit message needs to start with the
name of the recipe that was modified.


Fixed it, please refer to: [OE-core] [PATCH v2] apr: Fix packet discards 
HTTP redirect


Thanks
Wenzong



Ross

On 8 July 2015 at 08:32, mailto:wenzong@windriver.com>> wrote:

From: Li Wang mailto:li.w...@windriver.com>>

Disconnect the connection by poll() timeout.
If timeout=0 and apr_wait_for_io_or_timeout()=APR_TIMEUP then
apr_socket_recv() returns EAGAIN.

Signed-off-by: Noriaki Yoshitane mailto:yoshitane@cnt.ncos.nec.co.jp>>
Signed-off-by: Li Wang mailto:li.w...@windriver.com>>
---
  .../apr/Fix-packet-discards-HTTP-redirect.patch| 32
++
  meta/recipes-support/apr/apr_1.5.2.bb 
   |  1 +
  2 files changed, 33 insertions(+)
  create mode 100644
meta/recipes-support/apr/apr/Fix-packet-discards-HTTP-redirect.patch

diff --git
a/meta/recipes-support/apr/apr/Fix-packet-discards-HTTP-redirect.patch
b/meta/recipes-support/apr/apr/Fix-packet-discards-HTTP-redirect.patch
new file mode 100644
index 000..6805b8b
--- /dev/null
+++
b/meta/recipes-support/apr/apr/Fix-packet-discards-HTTP-redirect.patch
@@ -0,0 +1,32 @@
+Fix packet discards HTTP redirect.
+
+Disconnect the connection by poll() timeout.
+If timeout=0 and apr_wait_for_io_or_timeout()=APR_TIMEUP then
+apr_socket_recv() returns EAGAIN.
+
+Upstream-Status: Pending
+
+Signed-off-by: Noriaki Yoshitane mailto:yoshitane@cnt.ncos.nec.co.jp>>
+Signed-off-by: Li Wang mailto:li.w...@windriver.com>>
+---
+ network_io/unix/sendrecv.c |4 
+ 1 file changed, 4 insertions(+)
+
+diff --git a/network_io/unix/sendrecv.c b/network_io/unix/sendrecv.c
+index c133a26..e8faf15 100644
+--- a/network_io/unix/sendrecv.c
 b/network_io/unix/sendrecv.c
+@@ -85,6 +85,10 @@ apr_status_t apr_socket_recv(apr_socket_t *sock,
char *buf, apr_size_t *len)
+   && (sock->timeout > 0)) {
+ do_select:
+ arv = apr_wait_for_io_or_timeout(NULL, sock, 1);
++if ((arv == APR_TIMEUP) && (sock->timeout == 0)) {
++*len = 0;
++return EAGAIN;
++}
+ if (arv != APR_SUCCESS) {
+ *len = 0;
+ return arv;
+--
+1.7.9.5
+
diff --git a/meta/recipes-support/apr/apr_1.5.2.bb
 b/meta/recipes-support/apr/apr_1.5.2.bb

index aac6276..c1f7f38 100644
--- a/meta/recipes-support/apr/apr_1.5.2.bb 
+++ b/meta/recipes-support/apr/apr_1.5.2.bb 
@@ -15,6 +15,7 @@ SRC_URI = "${APACHE_MIRROR}/apr/${BPN}-${PV}.tar.bz2 \
 file://configfix.patch \
 file://run-ptest \
 file://upgrade-and-fix-1.5.1.patch \
+   file://Fix-packet-discards-HTTP-redirect.patch \
  "

  SRC_URI[md5sum] = "4e9769f3349fe11fc0a5e1b224c236aa"
--
1.9.1

--
___
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] man: replace ',' with '#'

[wenzong fan]

On 07/02/2015 04:05 PM, Richard Purdie wrote:

On Thu, 2015-07-02 at 09:25 +0800, wenzong@windriver.com wrote:

From: Yue Tao 

Sometimes, the parameters of CC contains the ',', which
cause the sed command failed, so replace the ',' with '#'


What about BUILD_CC? Not sure if there are any linker parameters in
there?


I didn't find an example, but in theory it's possible.

I have updated the patch and send V2 for reviewing.

Thanks
Wenzong



Cheers,

Richard


Signed-off-by: Yue Tao 
---
  meta/recipes-extended/man/man/configure_sed.patch | 22 ++
  meta/recipes-extended/man/man_1.6g.bb |  1 +
  2 files changed, 23 insertions(+)
  create mode 100644 meta/recipes-extended/man/man/configure_sed.patch

diff --git a/meta/recipes-extended/man/man/configure_sed.patch 
b/meta/recipes-extended/man/man/configure_sed.patch
new file mode 100644
index 000..6c047ac
--- /dev/null
+++ b/meta/recipes-extended/man/man/configure_sed.patch
@@ -0,0 +1,22 @@
+man: replace ',' with '#'
+
+Sometimes, the parameters of CC contains the ',', which
+cause the sed command failed, so replace the ',' with '#'
+
+Upstream-Status: Pending
+
+Signed-off-by: Yue Tao 
+---
+diff --git a/configure.old b/configure
+index 9f62cf9..b439055 100755
+--- a/configure.old
 b/configure
+@@ -1321,7 +1321,7 @@ do
+   echo "Creating $infile from $infile.in"
+   sed -e '
+ s,@version@,$version,
+-s,@CC@,$CC,
++s#@CC@#$CC#
+ s,@EXEEXT@,$EXEEXT,
+ s,@BUILD_CC@,$BUILD_CC,
+ s,@INSTALL@,$INSTALL,
diff --git a/meta/recipes-extended/man/man_1.6g.bb 
b/meta/recipes-extended/man/man_1.6g.bb
index d4a4b26..6a4c734 100644
--- a/meta/recipes-extended/man/man_1.6g.bb
+++ b/meta/recipes-extended/man/man_1.6g.bb
@@ -52,6 +52,7 @@ SRC_URI = 
"http://pkgs.fedoraproject.org/lookaside/pkgs/man2html/${BP}.tar.gz/ba
 file://man.conf \
 file://manpath.5.gz;unpack=false \
 file://man-1.6g-whatis3.patch \
+   file://configure_sed.patch \
  "

  SRC_URI[md5sum] = "ba154d5796928b841c9c69f0ae376660"
--
1.9.1







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

Re: [OE-core] [PATCH 1/1] ldconfig-native: Add 64-bit flag for ELF64 entries

[wenzong fan]

On 07/01/2015 04:58 PM, Huang, Yuanjie wrote:

Hi Wenzong,

This package is created by OE-core from glibc source, so there's no
upstream for it...


It should include "Upstream-status: Inappropriate [...]" if there's no 
upstream, please refer to:


http://openembedded.org/wiki/Commit_Patch_Message_Guidelines#Patch_Header_Recommendations

Thanks
Wenzong



Best,
Yuanjie

On 07/01/2015 11:19 AM, wenzong fan wrote:

Hi Yuanjie,

Could you resend your patch with "Upstream-status:xxx"?

Please send the V2 patch directly w/o attachment.

Thanks
Wenzong

On 04/28/2015 03:46 PM, Yuanjie Huang wrote:

From: Yuanjie Huang 

ldconfig-native was grepped from an old version of glibc, and its output
lacks neccessary 64bit flag in entries.
Due to this defect, ctypes.util.find_library() python function fails to
detect any library due to the old file format that ldconfig-native
creates. This fix sets architecture-dependent 64bit flags for 64-bit
ELF.

Since the host's elf.h may not have definition for new AArch64 machine
type, a work-around is added to correctly flag 64-bit ARM libraries.

Signed-off-by: Yuanjie Huang 
---
  .../add-64-bit-flag-for-ELF64-entries.patch| 103
+
  meta/recipes-core/glibc/ldconfig-native_2.12.1.bb  |   1 +
  2 files changed, 104 insertions(+)
  create mode 100644
meta/recipes-core/glibc/ldconfig-native-2.12.1/add-64-bit-flag-for-ELF64-entries.patch


diff --git
a/meta/recipes-core/glibc/ldconfig-native-2.12.1/add-64-bit-flag-for-ELF64-entries.patch
b/meta/recipes-core/glibc/ldconfig-native-2.12.1/add-64-bit-flag-for-ELF64-entries.patch

new file mode 100644
index 000..d42f7a1
--- /dev/null
+++
b/meta/recipes-core/glibc/ldconfig-native-2.12.1/add-64-bit-flag-for-ELF64-entries.patch

@@ -0,0 +1,103 @@
+From 9d62544090b08849218cd1fc52a36cdd5d90363e Mon Sep 17 00:00:00 2001
+From: Yuanjie Huang 
+Date: Fri, 24 Apr 2015 03:29:31 +
+Subject: [PATCH] Add 64-bit flag for ELF64 entries.
+
+ldconfig-native was grepped from an old version of glibc, and its
output
+lacks neccessary 64bit flag in entries.
+Due to this defect, ctypes.util.find_library() python function fails to
+detect any library due to the old file format that ldconfig-native
+creates. This fix sets architecture-dependent 64bit flags for 64-bit
ELF.
+
+Signed-off-by: Yuanjie Huang 
+---
+ cache.c  |  4 
+ ldconfig.h   |  4 
+ readelflib.c | 34 ++
+ 3 files changed, 42 insertions(+)
+
+diff --git a/cache.c b/cache.c
+index a904d44..c4f5411 100644
+--- a/cache.c
 b/cache.c
+@@ -121,6 +121,10 @@ print_entry (const char *lib, int flag,
unsigned int osversion,
+   break;
+ case FLAG_MIPS64_LIBN64:
+   fputs (",64bit", stdout);
++  break;
++case FLAG_AARCH64_LIB64:
++  fputs (",AArch64", stdout);
++  break;
+ case 0:
+   break;
+ default:
+diff --git a/ldconfig.h b/ldconfig.h
+index fadd5ec..6a8a750 100644
+--- a/ldconfig.h
 b/ldconfig.h
+@@ -34,6 +34,10 @@
+ #define FLAG_POWERPC_LIB640x0500
+ #define FLAG_MIPS64_LIBN320x0600
+ #define FLAG_MIPS64_LIBN640x0700
++#define FLAG_X8664_LIBX320x0800
++#define FLAG_ARM_LIBHF0x0900
++#define FLAG_AARCH64_LIB640x0a00
++#define FLAG_ARM_LIBSF0x0b00
+
+ /* Name of auxiliary cache.  */
+ #define _PATH_LDCONFIG_AUX_CACHE "/var/cache/ldconfig/aux-cache"
+diff --git a/readelflib.c b/readelflib.c
+index 0bf0de3..6e87afc 100644
+--- a/readelflib.c
 b/readelflib.c
+@@ -28,6 +28,11 @@
+
+ #include "endian_extra.h"
+
++/* Work-around for old host that does not have AArch64 defined in
elf.h. */
++#ifndef EM_AARCH64
++#define EM_AARCH64183/* ARM AARCH64 */
++#endif
++
+ #undef check_ptr
+ #define check_ptr(ptr)\
+ do\
+@@ -290,6 +295,35 @@ process_elf_file64 (const char *file_name,
const char *lib, int *flag,
+  libc5/libc6.  */
+   *flag = FLAG_ELF;
+
++  /* Set flags according to information in ELF header to align with
target
++ ldconfig */
++  switch (elf_header->e_machine)
++{
++case EM_IA_64:
++  *flag |= FLAG_IA64_LIB64;
++  break;
++case EM_X86_64:
++  *flag |= FLAG_X8664_LIB64;
++  break;
++case EM_S390:
++  *flag |= FLAG_S390_LIB64;
++  break;
++case EM_PPC64:
++  *flag |= FLAG_POWERPC_LIB64;
++  break;
++case EM_MIPS:
++case EM_MIPS_RS3_LE:
++  *flag |= FLAG_MIPS64_LIBN64;
++  break;
++case EM_AARCH64:
++  *flag |= FLAG_AARCH64_LIB64;
++  break;
++default:
++  error(0, 0, "%s is a 64-bit ELF for unknown machine %lx\n",
++file_name, (long)elf_header->e_machine);
++  break;
++}
++
+   loadaddr = -1;
+   dynamic_addr = 0;
+   dynamic_size = 0;
+--
+1.8.5.2.233.g932f7e4
+
diff --git a/meta/recipes-core/glibc/ldconfig-native_2.12.1.bb
b/meta/recipes-core/

Re: [OE-core] [PATCH 1/1] ldconfig-native: Add 64-bit flag for ELF64 entries

[wenzong fan]

Hi Yuanjie,

Could you resend your patch with "Upstream-status:xxx"?

Please send the V2 patch directly w/o attachment.

Thanks
Wenzong

On 04/28/2015 03:46 PM, Yuanjie Huang wrote:

From: Yuanjie Huang 

ldconfig-native was grepped from an old version of glibc, and its output
lacks neccessary 64bit flag in entries.
Due to this defect, ctypes.util.find_library() python function fails to
detect any library due to the old file format that ldconfig-native
creates. This fix sets architecture-dependent 64bit flags for 64-bit ELF.

Since the host's elf.h may not have definition for new AArch64 machine
type, a work-around is added to correctly flag 64-bit ARM libraries.

Signed-off-by: Yuanjie Huang 
---
  .../add-64-bit-flag-for-ELF64-entries.patch| 103 +
  meta/recipes-core/glibc/ldconfig-native_2.12.1.bb  |   1 +
  2 files changed, 104 insertions(+)
  create mode 100644 
meta/recipes-core/glibc/ldconfig-native-2.12.1/add-64-bit-flag-for-ELF64-entries.patch

diff --git 
a/meta/recipes-core/glibc/ldconfig-native-2.12.1/add-64-bit-flag-for-ELF64-entries.patch
 
b/meta/recipes-core/glibc/ldconfig-native-2.12.1/add-64-bit-flag-for-ELF64-entries.patch
new file mode 100644
index 000..d42f7a1
--- /dev/null
+++ 
b/meta/recipes-core/glibc/ldconfig-native-2.12.1/add-64-bit-flag-for-ELF64-entries.patch
@@ -0,0 +1,103 @@
+From 9d62544090b08849218cd1fc52a36cdd5d90363e Mon Sep 17 00:00:00 2001
+From: Yuanjie Huang 
+Date: Fri, 24 Apr 2015 03:29:31 +
+Subject: [PATCH] Add 64-bit flag for ELF64 entries.
+
+ldconfig-native was grepped from an old version of glibc, and its output
+lacks neccessary 64bit flag in entries.
+Due to this defect, ctypes.util.find_library() python function fails to
+detect any library due to the old file format that ldconfig-native
+creates. This fix sets architecture-dependent 64bit flags for 64-bit ELF.
+
+Signed-off-by: Yuanjie Huang 
+---
+ cache.c  |  4 
+ ldconfig.h   |  4 
+ readelflib.c | 34 ++
+ 3 files changed, 42 insertions(+)
+
+diff --git a/cache.c b/cache.c
+index a904d44..c4f5411 100644
+--- a/cache.c
 b/cache.c
+@@ -121,6 +121,10 @@ print_entry (const char *lib, int flag, unsigned int 
osversion,
+   break;
+ case FLAG_MIPS64_LIBN64:
+   fputs (",64bit", stdout);
++  break;
++case FLAG_AARCH64_LIB64:
++  fputs (",AArch64", stdout);
++  break;
+ case 0:
+   break;
+ default:
+diff --git a/ldconfig.h b/ldconfig.h
+index fadd5ec..6a8a750 100644
+--- a/ldconfig.h
 b/ldconfig.h
+@@ -34,6 +34,10 @@
+ #define FLAG_POWERPC_LIB640x0500
+ #define FLAG_MIPS64_LIBN320x0600
+ #define FLAG_MIPS64_LIBN640x0700
++#define FLAG_X8664_LIBX32 0x0800
++#define FLAG_ARM_LIBHF0x0900
++#define FLAG_AARCH64_LIB640x0a00
++#define FLAG_ARM_LIBSF0x0b00
+
+ /* Name of auxiliary cache.  */
+ #define _PATH_LDCONFIG_AUX_CACHE "/var/cache/ldconfig/aux-cache"
+diff --git a/readelflib.c b/readelflib.c
+index 0bf0de3..6e87afc 100644
+--- a/readelflib.c
 b/readelflib.c
+@@ -28,6 +28,11 @@
+
+ #include "endian_extra.h"
+
++/* Work-around for old host that does not have AArch64 defined in elf.h. */
++#ifndef EM_AARCH64
++#define EM_AARCH64183 /* ARM AARCH64 */
++#endif
++
+ #undef check_ptr
+ #define check_ptr(ptr)\
+ do\
+@@ -290,6 +295,35 @@ process_elf_file64 (const char *file_name, const char 
*lib, int *flag,
+  libc5/libc6.  */
+   *flag = FLAG_ELF;
+
++  /* Set flags according to information in ELF header to align with target
++ ldconfig */
++  switch (elf_header->e_machine)
++{
++case EM_IA_64:
++  *flag |= FLAG_IA64_LIB64;
++  break;
++case EM_X86_64:
++  *flag |= FLAG_X8664_LIB64;
++  break;
++case EM_S390:
++  *flag |= FLAG_S390_LIB64;
++  break;
++case EM_PPC64:
++  *flag |= FLAG_POWERPC_LIB64;
++  break;
++case EM_MIPS:
++case EM_MIPS_RS3_LE:
++  *flag |= FLAG_MIPS64_LIBN64;
++  break;
++case EM_AARCH64:
++  *flag |= FLAG_AARCH64_LIB64;
++  break;
++default:
++  error(0, 0, "%s is a 64-bit ELF for unknown machine %lx\n",
++file_name, (long)elf_header->e_machine);
++  break;
++}
++
+   loadaddr = -1;
+   dynamic_addr = 0;
+   dynamic_size = 0;
+--
+1.8.5.2.233.g932f7e4
+
diff --git a/meta/recipes-core/glibc/ldconfig-native_2.12.1.bb 
b/meta/recipes-core/glibc/ldconfig-native_2.12.1.bb
index 7c34635..8a2ea90 100644
--- a/meta/recipes-core/glibc/ldconfig-native_2.12.1.bb
+++ b/meta/recipes-core/glibc/ldconfig-native_2.12.1.bb
@@ -12,6 +12,7 @@ SRC_URI = "file://ldconfig-native-2.12.1.tar.bz2 \
 file://flag_fix.patch \
 file://endianess-header.patch \
 file://ldconfig-default-to-all-multilib-dirs.patch \
+   file://add-64-bi

Re: [OE-core] [PATCH] boost & libxslt: nativesdk is missed in bb file and break

[wenzong fan]

Ping ...

On 04/30/2015 05:34 PM, Li Zhou wrote:

When run , the make will be broken because
nativesdk-boost and nativesdk-libxslt don't exist.
nativesdk-boost is depended by nativesdk-curlpp.
nativesdk-libxslt is depended by nativesdk-python-lxml.
In condition that meta-openembedded is compiled in.

Add nativesdk building for boost and libxslt.

Signed-off-by: Li Zhou 
---
  meta/recipes-support/boost/boost.inc   |2 +-
  meta/recipes-support/libxslt/libxslt_1.1.28.bb |2 +-
  2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-support/boost/boost.inc 
b/meta/recipes-support/boost/boost.inc
index 6b42133..7628e37 100644
--- a/meta/recipes-support/boost/boost.inc
+++ b/meta/recipes-support/boost/boost.inc
@@ -181,4 +181,4 @@ do_install() {

  }

-BBCLASSEXTEND = "native"
+BBCLASSEXTEND = "native nativesdk"
diff --git a/meta/recipes-support/libxslt/libxslt_1.1.28.bb 
b/meta/recipes-support/libxslt/libxslt_1.1.28.bb
index ded883e..166bcd8 100644
--- a/meta/recipes-support/libxslt/libxslt_1.1.28.bb
+++ b/meta/recipes-support/libxslt/libxslt_1.1.28.bb
@@ -43,4 +43,4 @@ do_install_append_class-native () {
  FILES_${PN} += "${libdir}/libxslt-plugins"
  FILES_${PN}-dev += "${libdir}/xsltConf.sh"

-BBCLASSEXTEND = "native"
+BBCLASSEXTEND = "native nativesdk"


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

Re: [OE-core] [PATCH 0/1] util-linux: add runuser PAM config files

[wenzong fan]

Ping ...

On 05/15/2015 01:29 PM, Shan Hai wrote:


Add PAM config files for util-linux to fix a runtime failure of the
runuser command.

meta/recipes-core/util-linux/util-linux.inc| 8 
  meta/recipes-core/util-linux/util-linux/runuser-l.pamd | 4 
  meta/recipes-core/util-linux/util-linux/runuser.pamd   | 5 +
  meta/recipes-core/util-linux/util-linux_2.24.2.bb  | 2 ++
  4 files changed, 19 insertions(+)
  create mode 100644 meta/recipes-core/util-linux/util-linux/runuser-l.pamd
  create mode 100644 meta/recipes-core/util-linux/util-linux/runuser.pamd

Thanks
Shan Hai


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

Re: [OE-core] ltp: vma03 fix the alginment of page size

[wenzong fan]

Hi guys,

I have updated the patch format and sent V2 for reviewing...

Thanks
Wenzong

On 06/26/2015 02:39 PM, Robert Yang wrote:


Hi Dong,

Please don't send the patch as attachment, you can use git send-email
to send the patch. And please add the "Upstream-Status: Submitted"
inside the patch 0001-ltp-vma03-fix-the-alginment-of-page-size.patch,
right before the Signed-off-by line.

// Robert

On 06/03/2015 04:06 PM, cdong wrote:

Hi,
 This patch fix a vma03 bug,the info below detail it:

 the offset which is parameter of mmap2() function doesn't align the
 page size,but,this parameter is allowed multiple of the page size
 as returned by sysconf(_SC_PAGE_SIZE),meanwhile offset * 4096
must be
 a multiple of the system page size,so modify the input parameter
 pgoff = (ULONG_MAX - 1)&(~((pgsz-1)>>12));

 Regards
 Chuang



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

Re: [OE-core] [PATCH v2] libxml2: Security Advisory - libxml2 - CVE-2015-1819

[wenzong fan]

V2 changes:

* Adding Signed-off-by.

Thanks
Wenzong

On 06/15/2015 09:18 AM, wenzong@windriver.com wrote:

From: Yue Tao 

for CVE-2015-1819 Enforce the reader to run in constant memory

Signed-off-by: Yue Tao 
Signed-off-by: Wenzong Fan 
---
  meta/recipes-core/libxml/libxml2.inc   |   1 +
  ...19-Enforce-the-reader-to-run-in-constant-.patch | 181 +
  2 files changed, 182 insertions(+)
  create mode 100644 
meta/recipes-core/libxml/libxml2/0001-CVE-2015-1819-Enforce-the-reader-to-run-in-constant-.patch

diff --git a/meta/recipes-core/libxml/libxml2.inc 
b/meta/recipes-core/libxml/libxml2.inc
index d337bec..1c3c37d 100644
--- a/meta/recipes-core/libxml/libxml2.inc
+++ b/meta/recipes-core/libxml/libxml2.inc
@@ -20,6 +20,7 @@ SRC_URI = 
"ftp://xmlsoft.org/libxml2/libxml2-${PV}.tar.gz;name=libtar \
 file://python-sitepackages-dir.patch \
 file://libxml-m4-use-pkgconfig.patch \
 file://configure.ac-fix-cross-compiling-warning.patch \
+   
file://0001-CVE-2015-1819-Enforce-the-reader-to-run-in-constant-.patch \
"

  BINCONFIG = "${bindir}/xml2-config"
diff --git 
a/meta/recipes-core/libxml/libxml2/0001-CVE-2015-1819-Enforce-the-reader-to-run-in-constant-.patch
 
b/meta/recipes-core/libxml/libxml2/0001-CVE-2015-1819-Enforce-the-reader-to-run-in-constant-.patch
new file mode 100644
index 000..96d58f9
--- /dev/null
+++ 
b/meta/recipes-core/libxml/libxml2/0001-CVE-2015-1819-Enforce-the-reader-to-run-in-constant-.patch
@@ -0,0 +1,181 @@
+From 213f1fe0d76d30eaed6e5853057defc43e6df2c9 Mon Sep 17 00:00:00 2001
+From: Daniel Veillard 
+Date: Tue, 14 Apr 2015 17:41:48 +0800
+Subject: [PATCH] CVE-2015-1819 Enforce the reader to run in constant memory
+
+One of the operation on the reader could resolve entities
+leading to the classic expansion issue. Make sure the
+buffer used for xmlreader operation is bounded.
+Introduce a new allocation type for the buffers for this effect.
+
+Upstream-Status: Backport
+
+Signed-off-by: Yue Tao 
+Signed-off-by: Wenzong Fan 
+---
+ buf.c |   43 ++-
+ include/libxml/tree.h |3 ++-
+ xmlreader.c   |   20 +++-
+ 3 files changed, 63 insertions(+), 3 deletions(-)
+
+diff --git a/buf.c b/buf.c
+index 6efc7b6..07922ff 100644
+--- a/buf.c
 b/buf.c
+@@ -27,6 +27,7 @@
+ #include 
+ #include 
+ #include 
++#include  /* for XML_MAX_TEXT_LENGTH */
+ #include "buf.h"
+
+ #define WITH_BUFFER_COMPAT
+@@ -299,7 +300,8 @@ xmlBufSetAllocationScheme(xmlBufPtr buf,
+ if ((scheme == XML_BUFFER_ALLOC_DOUBLEIT) ||
+ (scheme == XML_BUFFER_ALLOC_EXACT) ||
+ (scheme == XML_BUFFER_ALLOC_HYBRID) ||
+-(scheme == XML_BUFFER_ALLOC_IMMUTABLE)) {
++(scheme == XML_BUFFER_ALLOC_IMMUTABLE) ||
++  (scheme == XML_BUFFER_ALLOC_BOUNDED)) {
+   buf->alloc = scheme;
+ if (buf->buffer)
+ buf->buffer->alloc = scheme;
+@@ -458,6 +460,18 @@ xmlBufGrowInternal(xmlBufPtr buf, size_t len) {
+ size = buf->use + len + 100;
+ #endif
+
++if (buf->alloc == XML_BUFFER_ALLOC_BOUNDED) {
++/*
++   * Used to provide parsing limits
++   */
++if ((buf->use + len >= XML_MAX_TEXT_LENGTH) ||
++  (buf->size >= XML_MAX_TEXT_LENGTH)) {
++  xmlBufMemoryError(buf, "buffer error: text too long\n");
++  return(0);
++  }
++  if (size >= XML_MAX_TEXT_LENGTH)
++  size = XML_MAX_TEXT_LENGTH;
++}
+ if ((buf->alloc == XML_BUFFER_ALLOC_IO) && (buf->contentIO != NULL)) {
+ size_t start_buf = buf->content - buf->contentIO;
+
+@@ -739,6 +753,15 @@ xmlBufResize(xmlBufPtr buf, size_t size)
+ CHECK_COMPAT(buf)
+
+ if (buf->alloc == XML_BUFFER_ALLOC_IMMUTABLE) return(0);
++if (buf->alloc == XML_BUFFER_ALLOC_BOUNDED) {
++/*
++   * Used to provide parsing limits
++   */
++if (size >= XML_MAX_TEXT_LENGTH) {
++  xmlBufMemoryError(buf, "buffer error: text too long\n");
++  return(0);
++  }
++}
+
+ /* Don't resize if we don't have to */
+ if (size < buf->size)
+@@ -867,6 +890,15 @@ xmlBufAdd(xmlBufPtr buf, const xmlChar *str, int len) {
+
+ needSize = buf->use + len + 2;
+ if (needSize > buf->size){
++  if (buf->alloc == XML_BUFFER_ALLOC_BOUNDED) {
++  /*
++   * Used to provide parsing limits
++   */
++  if (needSize >= XML_MAX_TEXT_LENGTH) {
++  xmlBufMemoryError(buf, "buffer error: text too long\n");
++  return(-1);
++  }
++  }
+ if (!xmlBufResize(buf, needSize)){
+   xmlBufMemoryError(buf, "growing buffer");
+ return XML_ERR_NO_MEMORY;
+@@ -938,6 +970,15 @@ xmlBufAddHead(xmlBufPtr bu

Re: [OE-core] [PATCH 1/1] improve the sanity check for PATH and BBPATH

[wenzong fan]

Hi Ross,

Please refer to attachment for the rebased patch.

Thanks
Wenzong

On 12/05/2014 01:28 AM, Burton, Ross wrote:

This doesn't apply to master, can you rebase?

Ross

On 4 December 2014 at 02:29, Shiqun.Lin mailto:shiqun@windriver.com>> wrote:



--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org

http://lists.openembedded.org/mailman/listinfo/openembedded-core






0001-sanity.bbclass-improve-the-sanity-check-for-PATH-and.patch
Description: application/mbox
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 1/6] subversion: Security Advisory - subversion - CVE-2014-3528

[wenzong fan]

On 11/19/2014 02:07 PM, akuster808 wrote:

Wenzong,

I wanted to just patch 1.8.9 for dizzy since 1.8.10 included more than
just security fixes.   Looks like my subject should have included
[dizzy] even though the cover letter did.  I will have to be more
careful next time.



You have clear cover page 'Dizzy next':)

Since I updated serf on master, so I wonder how the subversion related 
CVEes will be processed on Dizzy.


Thanks for the clarification.

Wenzong



thanks,
Armin

On 11/18/2014 05:29 PM, wenzong fan wrote:

There's subversion 1.8.10 in master branch that has included the CVE
fixes.

Would you like to backport 1.8.10 from master? Or just patch 1.8.9 to
fix this CVE?

Thanks
Wenzong

On 11/19/2014 12:18 AM, Armin Kuster wrote:

From: Yue Tao 

Apache Subversion 1.0.0 through 1.7.x before 1.7.17 and 1.8.x before
1.8.10 uses an MD5 hash of the URL and authentication realm to store
cached credentials, which makes it easier for remote servers to obtain
the credentials via a crafted authentication realm.

http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-3528

(From OE-Core rev: e0dc0432b13f38d16f642bdadf8ebc78b7a74806)

Signed-off-by: Yue Tao 
Signed-off-by: Jackie Huang 
Signed-off-by: Ross Burton 
Signed-off-by: Richard Purdie 
Signed-off-by: Armin Kuster 
---
  .../subversion/subversion-CVE-2014-3528.patch  | 29
++
  .../subversion/subversion_1.6.15.bb|  1 +
  .../subversion/subversion_1.8.9.bb |  1 +
  3 files changed, 31 insertions(+)
  create mode 100644
meta/recipes-devtools/subversion/subversion/subversion-CVE-2014-3528.patch



diff --git
a/meta/recipes-devtools/subversion/subversion/subversion-CVE-2014-3528.patch

b/meta/recipes-devtools/subversion/subversion/subversion-CVE-2014-3528.patch


new file mode 100644
index 000..23e738e
--- /dev/null
+++
b/meta/recipes-devtools/subversion/subversion/subversion-CVE-2014-3528.patch


@@ -0,0 +1,29 @@
+Upstream-Status: Backport
+
+Signed-off-by: Yue Tao 
+
+diff --git a/subversion/libsvn_subr/config_auth.c.old
b/subversion/libsvn_subr/config_auth.c
+index ff50270..c511d04 100644
+--- a/subversion/libsvn_subr/config_auth.c.old
 b/subversion/libsvn_subr/config_auth.c
+@@ -85,6 +85,7 @@ svn_config_read_auth_data(apr_hash_t **hash,
+   if (kind == svn_node_file)
+ {
+   svn_stream_t *stream;
++  svn_string_t *stored_realm;
+
+   SVN_ERR_W(svn_stream_open_readonly(&stream, auth_path, pool,
pool),
+ _("Unable to open auth file for reading"));
+@@ -95,6 +96,12 @@ svn_config_read_auth_data(apr_hash_t **hash,
+ apr_psprintf(pool, _("Error parsing '%s'"),
+  svn_path_local_style(auth_path, pool)));
+
++  stored_realm = apr_hash_get(*hash, SVN_CONFIG_REALMSTRING_KEY,
++  APR_HASH_KEY_STRING);
++
++  if (!stored_realm || strcmp(stored_realm->data, realmstring)
!= 0)
++*hash = NULL; /* Hash collision, or somebody tampering with
storage */
++
+   SVN_ERR(svn_stream_close(stream));
+ }
+
diff --git a/meta/recipes-devtools/subversion/subversion_1.6.15.bb
b/meta/recipes-devtools/subversion/subversion_1.6.15.bb
index 6680ab6..b135bb7 100644
--- a/meta/recipes-devtools/subversion/subversion_1.6.15.bb
+++ b/meta/recipes-devtools/subversion/subversion_1.6.15.bb
@@ -19,6 +19,7 @@ SRC_URI =
"http://subversion.tigris.org/downloads/${BPN}-${PV}.tar.bz2 \
 file://subversion-CVE-2013-1847-CVE-2013-1846.patch \
 file://subversion-CVE-2013-4277.patch \
 file://subversion-CVE-2014-3522.patch \
+   file://subversion-CVE-2014-3528.patch \
  "

  SRC_URI[md5sum] = "113fca1d9e4aa389d7dc2b210010fa69"
diff --git a/meta/recipes-devtools/subversion/subversion_1.8.9.bb
b/meta/recipes-devtools/subversion/subversion_1.8.9.bb
index e1ab945..1ef59a0 100644
--- a/meta/recipes-devtools/subversion/subversion_1.8.9.bb
+++ b/meta/recipes-devtools/subversion/subversion_1.8.9.bb
@@ -13,6 +13,7 @@ SRC_URI =
"${APACHE_MIRROR}/${BPN}/${BPN}-${PV}.tar.bz2 \
 file://libtool2.patch \
 file://disable_macos.patch \
 file://subversion-CVE-2014-3522.patch;striplevel=0 \
+   file://subversion-CVE-2014-3528.patch \
  "
  SRC_URI[md5sum] = "bd495517a760ddd764ce449a891971db"
  SRC_URI[sha256sum] =
"45d708a5c3ffbef4b2a1044c4716a053e680763743d1f7ba99d0369f6da49e33"





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

Re: [OE-core] [PATCH 0/1] uprev serf: 1.3.6 -> 1.3.8

[wenzong fan]

As https://subversion.apache.org/security/CVE-2014-3522-advisory.txt 
mentioned:


  We recommend all users to upgrade to Subversion 1.8.10.  Users of
  Subversion 1.7.x or 1.8.x who are unable to upgrade may apply the
  included patch.  We also recommend that all users upgrade to Serf 1.3.7
  or newer to resolve CVE-2014-3504.

The subversion has been 1.8.10 on master and we only need to uprev serf now.

Akuster,

I wonder how would you like to process this on Dizzy?

Uprev subversion or just apply related CVE fixes, I did think the serf 
should be uprev-ed.


Thanks
Wenzong

On 11/17/2014 11:35 PM, akuster wrote:

Please add to the 1.3.7 the security fix

- CVE-2014-3504: (Closes: #757965)

On 11/17/2014 12:38 AM, wenzong@windriver.com wrote:

From: Wenzong Fan 

Release changes:

Serf 1.3.8 [2014-10-20, from /tags/1.3.8, r]
   Fix issue #152: CRC calculation error for gzipped http reponses > 4GB.
   Fix issue #153: SSPI CredHandle not freed when APR pool is destroyed.
   Fix issue #154: Disable SSLv2 and SSLv3 as both or broken.

Serf 1.3.7 [2014-08-11, from /tags/1.3.7, r2411]
   Handle NUL bytes in fields of an X.509 certificate. (r2393, r2399)

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 wenzong/serf
   http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=wenzong/serf

Wenzong Fan (1):
   serf: 1.3.6 -> 1.3.8

  .../serf/{serf_1.3.6.bb => serf_1.3.8.bb}  |6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)
  rename meta/recipes-support/serf/{serf_1.3.6.bb => serf_1.3.8.bb} (74%)




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

Re: [OE-core] [PATCH 1/6] subversion: Security Advisory - subversion - CVE-2014-3528

[wenzong fan]

There's subversion 1.8.10 in master branch that has included the CVE fixes.

Would you like to backport 1.8.10 from master? Or just patch 1.8.9 to 
fix this CVE?


Thanks
Wenzong

On 11/19/2014 12:18 AM, Armin Kuster wrote:

From: Yue Tao 

Apache Subversion 1.0.0 through 1.7.x before 1.7.17 and 1.8.x before
1.8.10 uses an MD5 hash of the URL and authentication realm to store
cached credentials, which makes it easier for remote servers to obtain
the credentials via a crafted authentication realm.

http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-3528

(From OE-Core rev: e0dc0432b13f38d16f642bdadf8ebc78b7a74806)

Signed-off-by: Yue Tao 
Signed-off-by: Jackie Huang 
Signed-off-by: Ross Burton 
Signed-off-by: Richard Purdie 
Signed-off-by: Armin Kuster 
---
  .../subversion/subversion-CVE-2014-3528.patch  | 29 ++
  .../subversion/subversion_1.6.15.bb|  1 +
  .../subversion/subversion_1.8.9.bb |  1 +
  3 files changed, 31 insertions(+)
  create mode 100644 
meta/recipes-devtools/subversion/subversion/subversion-CVE-2014-3528.patch

diff --git 
a/meta/recipes-devtools/subversion/subversion/subversion-CVE-2014-3528.patch 
b/meta/recipes-devtools/subversion/subversion/subversion-CVE-2014-3528.patch
new file mode 100644
index 000..23e738e
--- /dev/null
+++ b/meta/recipes-devtools/subversion/subversion/subversion-CVE-2014-3528.patch
@@ -0,0 +1,29 @@
+Upstream-Status: Backport
+
+Signed-off-by: Yue Tao 
+
+diff --git a/subversion/libsvn_subr/config_auth.c.old 
b/subversion/libsvn_subr/config_auth.c
+index ff50270..c511d04 100644
+--- a/subversion/libsvn_subr/config_auth.c.old
 b/subversion/libsvn_subr/config_auth.c
+@@ -85,6 +85,7 @@ svn_config_read_auth_data(apr_hash_t **hash,
+   if (kind == svn_node_file)
+ {
+   svn_stream_t *stream;
++  svn_string_t *stored_realm;
+
+   SVN_ERR_W(svn_stream_open_readonly(&stream, auth_path, pool, pool),
+ _("Unable to open auth file for reading"));
+@@ -95,6 +96,12 @@ svn_config_read_auth_data(apr_hash_t **hash,
+ apr_psprintf(pool, _("Error parsing '%s'"),
+  svn_path_local_style(auth_path, pool)));
+
++  stored_realm = apr_hash_get(*hash, SVN_CONFIG_REALMSTRING_KEY,
++  APR_HASH_KEY_STRING);
++
++  if (!stored_realm || strcmp(stored_realm->data, realmstring) != 0)
++*hash = NULL; /* Hash collision, or somebody tampering with storage */
++
+   SVN_ERR(svn_stream_close(stream));
+ }
+
diff --git a/meta/recipes-devtools/subversion/subversion_1.6.15.bb 
b/meta/recipes-devtools/subversion/subversion_1.6.15.bb
index 6680ab6..b135bb7 100644
--- a/meta/recipes-devtools/subversion/subversion_1.6.15.bb
+++ b/meta/recipes-devtools/subversion/subversion_1.6.15.bb
@@ -19,6 +19,7 @@ SRC_URI = 
"http://subversion.tigris.org/downloads/${BPN}-${PV}.tar.bz2 \
 file://subversion-CVE-2013-1847-CVE-2013-1846.patch \
 file://subversion-CVE-2013-4277.patch \
 file://subversion-CVE-2014-3522.patch \
+   file://subversion-CVE-2014-3528.patch \
  "

  SRC_URI[md5sum] = "113fca1d9e4aa389d7dc2b210010fa69"
diff --git a/meta/recipes-devtools/subversion/subversion_1.8.9.bb 
b/meta/recipes-devtools/subversion/subversion_1.8.9.bb
index e1ab945..1ef59a0 100644
--- a/meta/recipes-devtools/subversion/subversion_1.8.9.bb
+++ b/meta/recipes-devtools/subversion/subversion_1.8.9.bb
@@ -13,6 +13,7 @@ SRC_URI = "${APACHE_MIRROR}/${BPN}/${BPN}-${PV}.tar.bz2 \
 file://libtool2.patch \
 file://disable_macos.patch \
 file://subversion-CVE-2014-3522.patch;striplevel=0 \
+   file://subversion-CVE-2014-3528.patch \
  "
  SRC_URI[md5sum] = "bd495517a760ddd764ce449a891971db"
  SRC_URI[sha256sum] = 
"45d708a5c3ffbef4b2a1044c4716a053e680763743d1f7ba99d0369f6da49e33"


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

Re: [OE-core] [PATCH 0/1] uprev serf: 1.3.6 -> 1.3.8

[wenzong fan]

On 11/17/2014 11:35 PM, akuster wrote:

Please add to the 1.3.7 the security fix

- CVE-2014-3504: (Closes: #757965)


Ok, I have added this comment and updated the contrib branch.

Thanks
Wenzong



On 11/17/2014 12:38 AM, wenzong@windriver.com wrote:

From: Wenzong Fan 

Release changes:

Serf 1.3.8 [2014-10-20, from /tags/1.3.8, r]
   Fix issue #152: CRC calculation error for gzipped http reponses > 4GB.
   Fix issue #153: SSPI CredHandle not freed when APR pool is destroyed.
   Fix issue #154: Disable SSLv2 and SSLv3 as both or broken.

Serf 1.3.7 [2014-08-11, from /tags/1.3.7, r2411]
   Handle NUL bytes in fields of an X.509 certificate. (r2393, r2399)

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 wenzong/serf
   http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=wenzong/serf

Wenzong Fan (1):
   serf: 1.3.6 -> 1.3.8

  .../serf/{serf_1.3.6.bb => serf_1.3.8.bb}  |6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)
  rename meta/recipes-support/serf/{serf_1.3.6.bb => serf_1.3.8.bb} (74%)




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

Re: [OE-core] [PATCH v2 4/4] tcl: clean host path in tclConfig.sh

[wenzong fan]

Oops, the tcl patch will cause "expect 5.45" configure failures, please 
ignore it for now.


// Wenzong

On 11/14/2014 05:44 PM, wenzong@windriver.com wrote:

From: Shiqun Lin 

* /usr/bin/crossscripts/tclConfig.sh

Signed-off-by: Shiqun Lin 
Signed-off-by: Wenzong Fan 
---
  meta/recipes-devtools/tcltk/tcl_8.6.2.bb |5 +
  1 file changed, 5 insertions(+)

diff --git a/meta/recipes-devtools/tcltk/tcl_8.6.2.bb 
b/meta/recipes-devtools/tcltk/tcl_8.6.2.bb
index 75fef01..34f3e87 100644
--- a/meta/recipes-devtools/tcltk/tcl_8.6.2.bb
+++ b/meta/recipes-devtools/tcltk/tcl_8.6.2.bb
@@ -58,6 +58,11 @@ do_install() {
sed -i "s+${WORKDIR}+${STAGING_INCDIR}+g" tclConfig.sh
sed -i "s,-L${libdir},-L=${libdir},g" tclConfig.sh
sed -i "s,-I${includedir},-I=${includedir},g" tclConfig.sh
+   sed -i "/TCL_CC/s,\(--sysroot=\).*,--sysroot= '," tclConfig.sh
+   sed -i "/TCL_BUILD_LIB_SPEC/s,-L${STAGING_LIBDIR},-L${libdir}," 
tclConfig.sh
+   sed -i "/TCL_SRC_DIR/s,${STAGING_INCDIR},${includedir}," tclConfig.sh
+   sed -i "/TCL_BUILD_STUB_LIB_SPEC/s,-L${STAGING_LIBDIR},-L${libdir}," 
tclConfig.sh
+   sed -i "/TCL_BUILD_STUB_LIB_PATH/s,${STAGING_INCDIR},${includedir}," 
tclConfig.sh
install -d ${D}${bindir_crossscripts}
install -m 0755 tclConfig.sh ${D}${bindir_crossscripts}
install -m 0755 tclConfig.sh ${D}${libdir}


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

Re: [OE-core] [PATCH 0/4] Clean host path in target scripts

[wenzong fan]

Drop the patches - Mistaken Signatures.

Wenzong

On 10/22/2014 09:46 AM, wenzong@windriver.com wrote:

From: Wenzong Fan 

Clean host path for:

   * /usr/bin/crossscripts/tclConfig.sh
   * /usr/bin/isc-config.sh
   * /usr/bin/bind9-config - hardlink to isc-config.sh
   * /usr/bin/compile_et
   * /usr/bin/mk_cmds
   * /usr/bin/bashbug

The following changes since commit 924da20c6f2f183fa7e930e4c3c6b14c090acbe5:

   build-appliance-image: Update to dizzy head revision (2014-10-18 16:16:38 
+0200)

are available in the git repository at:

   git://git.pokylinux.org/poky-contrib wenzong/clean-hostpath
   http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=wenzong/clean-hostpath

Wenzong Fan (4):
   bash: clean host path in bashbug
   e2fsprogs: clean host path in compile_et, mk_cmds
   bind: clean host path in isc-config.sh
   tcl: clean host path in tclConfig.sh

  meta/recipes-connectivity/bind/bind_9.9.5.bb   |7 +++
  .../recipes-devtools/e2fsprogs/e2fsprogs_1.42.9.bb |6 ++
  meta/recipes-devtools/tcltk/tcl_8.6.1.bb   |1 +
  meta/recipes-extended/bash/bash.inc|4 
  4 files changed, 18 insertions(+)


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

Re: [OE-core] [PATCH 0/1] shadow: fix pam configs for chpasswd, newusers

[wenzong fan]

Drop the patch - Mistaken Signatures.

Wenzong


On 10/22/2014 01:19 PM, wenzong@windriver.com wrote:

From: Wenzong Fan 

Fix below errors while pam is enabled on target:

   root@qemux86:~# newusers
   newusers: PAM: Authentication failure
   root@qemux86:~# chpasswd
   chpasswd: PAM: Authentication failure

The configs copied from "chgpasswd" which command works with pam.

The following changes since commit 924da20c6f2f183fa7e930e4c3c6b14c090acbe5:

   build-appliance-image: Update to dizzy head revision (2014-10-18 16:16:38 
+0200)

are available in the git repository at:

   git://git.pokylinux.org/poky-contrib wenzong/shadow-pam
   http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=wenzong/shadow-pam

Wenzong Fan (1):
   shadow: fix pam configs for chpasswd, newusers

  meta/recipes-extended/shadow/files/pam.d/chpasswd |2 ++
  meta/recipes-extended/shadow/files/pam.d/newusers |2 ++
  2 files changed, 4 insertions(+)


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

Re: [OE-core] [PATCH 1/1] lsof: fix LSOF_CCV in version.h

[wenzong fan]

On 10/23/2014 04:03 AM, Burton, Ross wrote:


On 22 October 2014 04:23, mailto:wenzong@windriver.com>> wrote:

+-  @echo '#define  LSOF_CCV"${CCV}"' >> version.h
++  @LSOF_CCV=`${CC} -v 2>&1 | sed -n 's/.*version \(.*\)/\1/p'` &&\
++  echo "#define   LSOF_CCV\"${LSOF_CCV}\"" >> version.h


It seems that a better (and importantly, upstreamable) fix would be to
pass LSOF_CC correctly to ./Configure instead of overriding in
do_compile(), and change the LSOF_CCV assignment to run LSOF_CC if _CCV
isn't already set.


Ok, I'll redo the patch and send V2.

Thanks
Wenzong



(My general approach here is spend a little more time getting a fix
upstreamed so that we're not fixing our patch every few months)

Ross


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

Re: [OE-core] [PATCH 0/1] pango / ptest: clean CFLAGS for host binary

[wenzong fan]

On 09/09/2014 05:11 PM, wenzong fan wrote:

Oops, I replied wrong mail list, this patch works and have been merged, 
please just ignore my nonsense below:




Recall this patch, it should be fixed from the dependency of swig.

Sorry for the inconvenience.

// Wenzong




Thanks
Wenzong


On 09/02/2014 01:53 PM, wenzong@windriver.com wrote:

From: Wenzong Fan 

The binary gen-all-unicode needs to be compiled for the host
architecture, the CFLAGS passed to target system could cause
build issues for it.

Such as if CFLAGS includes ARM specific flag '-mapcs-frame',
then it will cause build errors:

   cc1: error: unrecognized command line option "-mapcs-frame"

The following changes since commit
bb00d83675a1293ee8d7a3ac22cf01243fa2397b:

   conf: Account for eglibc->glibc move (2014-09-01 18:03:06 +0100)

are available in the git repository at:

   git://git.pokylinux.org/poky-contrib wenzong/fix-pango

http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=wenzong/fix-pango

Wenzong Fan (1):
   pango / ptest: clean CFLAGS for host binary

  meta/recipes-graphics/pango/pango.inc |2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)





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

Re: [OE-core] [PATCH 0/1] pango / ptest: clean CFLAGS for host binary

[wenzong fan]

Recall this patch, it should be fixed from the dependency of swig.

Sorry for the inconvenience.

// Wenzong

On 09/02/2014 01:53 PM, wenzong@windriver.com wrote:

From: Wenzong Fan 

The binary gen-all-unicode needs to be compiled for the host
architecture, the CFLAGS passed to target system could cause
build issues for it.

Such as if CFLAGS includes ARM specific flag '-mapcs-frame',
then it will cause build errors:

   cc1: error: unrecognized command line option "-mapcs-frame"

The following changes since commit bb00d83675a1293ee8d7a3ac22cf01243fa2397b:

   conf: Account for eglibc->glibc move (2014-09-01 18:03:06 +0100)

are available in the git repository at:

   git://git.pokylinux.org/poky-contrib wenzong/fix-pango
   http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=wenzong/fix-pango

Wenzong Fan (1):
   pango / ptest: clean CFLAGS for host binary

  meta/recipes-graphics/pango/pango.inc |2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)


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

Re: [OE-core] [PATCH 0/1] udev: remove libudev-dbg and libgudev-dbg

[wenzong fan]

On 11/12/2013 03:47 PM, Richard Purdie wrote:

On Mon, 2013-11-11 at 10:05 -0600, Mark Hatle wrote:

On 11/11/13, 4:10 AM, wenzong@windriver.com wrote:

From: Wenzong Fan 

We don't support multiple -dbg packages, so just remove the libudev-dbg,
libgudev-dbg and put all debug stuffs to 'udev-dbg'.


I'm a bit confused, we do support package that want to provide multiple -dbg
files to generate them.


No, we do not. We don't support multiple -dev packages either. Yes
packages can generate them but the system does not correctly handle them
and never has.


Ok, a V2 patch was sent for removing extra -dev/-dbg packages for udev.

Thanks
Wenzong



Cheers,

Richard

___
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 0/1] udev: remove libudev-dbg and libgudev-dbg

[wenzong fan]

On 11/12/2013 12:05 AM, Mark Hatle wrote:

On 11/11/13, 4:10 AM, wenzong@windriver.com wrote:

From: Wenzong Fan 

We don't support multiple -dbg packages, so just remove the libudev-dbg,
libgudev-dbg and put all debug stuffs to 'udev-dbg'.


I'm a bit confused, we do support package that want to provide multiple
-dbg files to generate them.

This way large recipes that provide lots of different bits of
functionality can no only segment the packages they create, but keep the
side of the -dbg information reasonable as well.  (It's not all that
commonly used, but it does work with the IMAGE_FEATURES 'dbg-pkgs'.)

What issue was being solved by combining the two items back into one?


Hi Mark,

This is an updated patch for fixing the 'source codes <--> -dbg 
packages' (i.e. which src should be shipped to which -dbg package), 
details please refer to another thread about:


Subject: udev: ship source files to related dbg package

As Richard mentioned:

"We don't support multiple -dbg packages and this looks like an error." 
- (the udev have there -dbg packages: libudev-dbg/libgudev-dbg/udev-dbg)


If I was wrong please correct me.

Thanks
Wenzong



--Mark


The following changes since commit
4fdc3d77d4a875b7236536bf78849a4d1f6a7449:

   kbd: Fix stdarg related errors on uclibc (2013-11-08 17:31:36 +)

are available in the git repository at:

   git://git.pokylinux.org/poky-contrib wenzong/udev-remove-dbg

http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=wenzong/udev-remove-dbg


Wenzong Fan (1):
   udev: remove libudev-dbg and libgudev-dbg

  meta/recipes-core/udev/udev.inc |6 ++
  1 file changed, 2 insertions(+), 4 deletions(-)



___
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 0/1] udev: ship source files to related dbg package

[wenzong fan]

On 11/08/2013 04:18 PM, Richard Purdie wrote:

On Fri, 2013-11-08 at 16:10 +0800, wenzong fan wrote:

On 11/07/2013 07:12 PM, Burton, Ross wrote:

On 7 November 2013 11:03,   wrote:

From: Wenzong Fan 

Just ship these sources to their own dbg packages instead of udev-dbg:

  libudev* -> libudev-dbg
  gudev*   -> libgudev-dbg
  others   -> udev-dbg


Why do this?  Multiple -dbg packages could make sense in a recipe
which builds a multi-gigabyte -dbg package (such as webkit) but what's
the rationale for doing this in udev?


Actually I don't know clear about why it needs three -dbg packages,
looks they have been there since very early commits of udev. I suspect
that udev/libudev/libgudev are independent each other, so they are
shipped into different packages (base/-dev/-dbg). This patch only ships
their source code to -dbg packages accordingly.


We don't support multiple -dbg packages and this looks like an error.


Ok, another patch for removing the extra -dbg packages has been sent 
with subject:


udev: remove libudev-dbg and libgudev-dbg

Thanks
Wenzong



Cheers,

Richard




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

Re: [OE-core] [PATCH 0/1] udev: ship source files to related dbg package

[wenzong fan]

On 11/08/2013 04:18 PM, Richard Purdie wrote:

On Fri, 2013-11-08 at 16:10 +0800, wenzong fan wrote:

On 11/07/2013 07:12 PM, Burton, Ross wrote:

On 7 November 2013 11:03,   wrote:

From: Wenzong Fan 

Just ship these sources to their own dbg packages instead of udev-dbg:

  libudev* -> libudev-dbg
  gudev*   -> libgudev-dbg
  others   -> udev-dbg


Why do this?  Multiple -dbg packages could make sense in a recipe
which builds a multi-gigabyte -dbg package (such as webkit) but what's
the rationale for doing this in udev?


Actually I don't know clear about why it needs three -dbg packages,
looks they have been there since very early commits of udev. I suspect
that udev/libudev/libgudev are independent each other, so they are
shipped into different packages (base/-dev/-dbg). This patch only ships
their source code to -dbg packages accordingly.


We don't support multiple -dbg packages and this looks like an error.


What about the -dev packages?

So the correct fix is removing below configs, at least -dbg configs, right?

+ FILES_libudev = "${base_libdir}/libudev.so.*"
+ FILES_libudev-dbg = "${base_libdir}/.debug/libudev.so.*"
+ FILES_libudev-dev = "${includedir}/libudev.h ${libdir}/libudev.so 
${libdir}/libudev.la \

 ${libdir}/libudev.a ${libdir}/pkgconfig/libudev.pc"

+ FILES_libgudev = "${base_libdir}/libgudev*.so.* ${libdir}/libgudev*.so.*"
+ FILES_libgudev-dbg = "${base_libdir}/.debug/libgudev*.so.* 
${libdir}/.debug/libgudev*.so.*"
+ FILES_libgudev-dev = "${includedir}/gudev* ${libdir}/libgudev*.so 
${libdir}/libgudev*.la \

 ${libdir}/libgudev*.a ${libdir}/pkgconfig/gudev*.pc"


Thanks
Wenzong



Cheers,

Richard




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

Re: [OE-core] [PATCH 0/1] udev: ship source files to related dbg package

[wenzong fan]

On 11/07/2013 07:12 PM, Burton, Ross wrote:

On 7 November 2013 11:03,   wrote:

From: Wenzong Fan 

Just ship these sources to their own dbg packages instead of udev-dbg:

 libudev* -> libudev-dbg
 gudev*   -> libgudev-dbg
 others   -> udev-dbg


Why do this?  Multiple -dbg packages could make sense in a recipe
which builds a multi-gigabyte -dbg package (such as webkit) but what's
the rationale for doing this in udev?


Actually I don't know clear about why it needs three -dbg packages, 
looks they have been there since very early commits of udev. I suspect 
that udev/libudev/libgudev are independent each other, so they are 
shipped into different packages (base/-dev/-dbg). This patch only ships 
their source code to -dbg packages accordingly.


Thanks
Wenzong



Ross



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

Re: [OE-core] About PACKAGECONFIG audit

[wenzong fan]

On 08/20/2013 04:46 AM, Randy MacLeod wrote:

Add Joe Slater who owns US17463: PACKAGECONFIG clean-up.


On 13-08-15 05:29 AM, wenzong fan wrote:

Hi All,

We have seen some problems like this:

$ bitbake libcap

ld: warning: libaudit.so.1, needed by .../lib64/libpam.so, not found
.../lib64/libpam.so: undefined reference to `audit_open'
.../lib64/libpam.so: undefined reference to `audit_close'
..

The libaudit has been available and libpam build with it, after we run
another build with sstate-cache and w/o libaudit, the error occurs. The
solution in these cases is to use PACKAGECONFIG to lay out dependencies
on optional packages and make them explicit. We need to run an audit and
catch all of these issues.

A probable ways maybe:

1) Run world build to generate the sysroots as much as possible;
2) Run 'configure --help' on each package to spot all of the optional
dependencies, and convert them into PACKAGECONFIG specs/or any other
prompts.


We should try to automate or codify this step so that the output is
a list of oe-core package names.


3) Run #1, #2 as an audit script periodically.

Or could we run this check as part of a QA build step?


Do you mean:
   scripts/test-dependencies.sh


No, I mean some check steps that if PACKAGECONFIG should be used, not 
limit to the script.


Thanks
Wenzong



// Randy




Thanks
Wenzong




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

Re: [OE-core] [PATCH 1/1] oe/path.py: call /bin/cp directly

[wenzong fan]

On 08/17/2013 01:11 AM, Saul Wold wrote:

On 08/13/2013 12:09 AM, wenzong@windriver.com wrote:

From: Wenzong Fan 

This avoids running cp with interactive mode if defined:

 alias cp='cp -i'

Signed-off-by: Wenzong Fan 
---
  meta/lib/oe/path.py |2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/lib/oe/path.py b/meta/lib/oe/path.py
index da044ba..6933977 100644
--- a/meta/lib/oe/path.py
+++ b/meta/lib/oe/path.py
@@ -97,7 +97,7 @@ def copyhardlinktree(src, dst):
  check_output(cmd, shell=True, stderr=subprocess.STDOUT)
  if os.path.isdir(src):
  src = src + "/*"
-cmd = 'cp -afl %s %s' % (src, dst)
+cmd = '/bin/cp -afl %s %s' % (src, dst)


As Richard points out in the Consolidated Pull, this is the wrong way to
go about this, there are possibly other places that will have similar
issues and we can't fix then all this way.

A better solution is to add a sanity check and suggest that the user
needs to fix their environment to ensure the build will succeed.


Ok, I will update the patch for this issue.

Thanks
Wenzong



Sau!

  check_output(cmd, shell=True, stderr=subprocess.STDOUT)
  else:
  copytree(src, dst)




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

Re: [OE-core] About PACKAGECONFIG audit

[wenzong fan]

On 08/15/2013 05:44 PM, Paul Eggleton wrote:

Hi Wenzong,

On Thursday 15 August 2013 17:29:46 wenzong fan wrote:

We have seen some problems like this:

$ bitbake libcap

ld: warning: libaudit.so.1, needed by .../lib64/libpam.so, not found
.../lib64/libpam.so: undefined reference to `audit_open'
.../lib64/libpam.so: undefined reference to `audit_close'
..

The libaudit has been available and libpam build with it, after we run
another build with sstate-cache and w/o libaudit, the error occurs. The
solution in these cases is to use PACKAGECONFIG to lay out dependencies
on optional packages and make them explicit. We need to run an audit and
catch all of these issues.

A probable ways maybe:

1) Run world build to generate the sysroots as much as possible;


(See Ross's reply for a pointer to the new test-dependencies script)


That would be a good start point, I have run that script once, but looks 
not any failure occurs.


I'll find a box and run it periodically.

Thanks
Wenzong




2) Run 'configure --help' on each package to spot all of the optional
dependencies, and convert them into PACKAGECONFIG specs/or any other
prompts.


Actually I have started along this line as well, putting the output of
configure --help into buildhistory so you can see the differences. I'm not
totally sure how useful it is at the moment and it will need some smooting out
to avoid known differences (paths etc.).

Cheers,
Paul


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

[OE-core] About PACKAGECONFIG audit

[wenzong fan]

Hi All,

We have seen some problems like this:

$ bitbake libcap

ld: warning: libaudit.so.1, needed by .../lib64/libpam.so, not found
.../lib64/libpam.so: undefined reference to `audit_open'
.../lib64/libpam.so: undefined reference to `audit_close'
..

The libaudit has been available and libpam build with it, after we run 
another build with sstate-cache and w/o libaudit, the error occurs. The 
solution in these cases is to use PACKAGECONFIG to lay out dependencies 
on optional packages and make them explicit. We need to run an audit and 
catch all of these issues.


A probable ways maybe:

1) Run world build to generate the sysroots as much as possible;
2) Run 'configure --help' on each package to spot all of the optional 
dependencies, and convert them into PACKAGECONFIG specs/or any other 
prompts.

3) Run #1, #2 as an audit script periodically.

Or could we run this check as part of a QA build step?


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

[OE-core] sstate_create_package fails since 'tar: xxxx: file changed as we read it'

[wenzong fan]

Hi All,

I met it on some packages like: util-macros-native, glib-2.0-native, 
libogg ...


Build host: CentOS 5.9
Error messages:
---
DEBUG: Preparing tree 
/home/nxadm/nx/yow-blade4.1/builds-2013-08-06-030257/e500-kvm-guest_std/bitbake_build/tmp/work/x86_64-linux/util-macros-native/1_1.17-r0/sysroot-destdir/home/nxadm/nx/yow-blade4.1/builds-2013-08-06-030257/e500-kvm-guest_std/bitbake_build/tmp/sysroots/x86_64-linux 
for packaging at 
/home/nxadm/nx/yow-blade4.1/builds-2013-08-06-030257/e500-kvm-guest_std/bitbake_build/tmp/work/x86_64-linux/util-macros-native/1_1.17-r0/sstate-build-populate-sysroot/x86_64-linux
NOTE: Removing hardcoded paths from sstate package: 'grep -Irl 
/home/nxadm/nx/yow-blade4.1/builds-2013-08-06-030257/e500-kvm-guest_std/bitbake_build/tmp/sysroots 
/home/nxadm/nx/yow-blade4.1/builds-2013-08-06-030257/e500-kvm-guest_std/bitbake_build/tmp/work/x86_64-linux/util-macros-native/1_1.17-r0/sstate-build-populate-sysroot/ 
| xargs grep -l -e 
'/home/nxadm/nx/yow-blade4.1/builds-2013-08-06-030257/e500-kvm-guest_std/bitbake_build/tmp/sysroots' 
| tee /home/nxadm/nx/yow-blade4.1/builds-2013-08-0
6-030257/e500-kvm-guest_std/bitbake_build/tmp/work/x86_64-linux/util-macros-native/1_1.17-r0/sstate-build-populate-sysroot/fixmepath 
| xargs --no-run-if-empty sed -i -e 
's:/home/nxadm/nx/yow-blade4.1/builds-2013-08-06-030257/e500-kvm-guest_std/bitbake_build/tmp/sysroots:FIXMESTAGINGDIR:g''
NOTE: Replacing absolute paths in fixmepath file: 'sed -i -e 
's:^/home/nxadm/nx/yow-blade4.1/builds-2013-08-06-030257/e500-kvm-guest_std/bitbake_build/tmp/work/x86_64-linux/util-macros-native/1_1.17-r0/sstate-build-populate-sysroot/::g' 
/home/nxadm/nx/yow-blade4.1/builds-2013-08-06-030257/e500-kvm-guest_std/bitbake_build/tmp/work/x86_64-linux/util-macros-native/1_1.17-r0/sstate-build-populate-sysroot/fixmepath'

DEBUG: Executing shell function sstate_create_package
tar: x86_64-linux/usr/share/aclocal/xorg-macros.m4: file changed as we 
read it
WARNING: 
/home/nxadm/nx/yow-blade4.1/builds-2013-08-06-030257/e500-kvm-guest_std/bitbake_build/tmp/work/x86_64-linux/util-macros-native/1_1.17-r0/temp/do_populate_sysroot/run.do_populate_sysroot.sstate_create_package.18975:122 
exit 1 from

  tar -czf $TFILE fixmepath x86_64-linux
DEBUG: Python function sstate_task_postfunc finished
---

I searched and found this discussions but did not found any conclusions, 
anyone know about that?

---
JaMaanyone seeing:  11:40
JaMa| DEBUG: Executing shell function sstate_create_package 11:40
JaMa	| tar: x86_64-linux/usr/share/aclocal/lib-prefix.m4: file changed 
as we read it	11:40
JaMa	? I've found 
http://www.mail-archive.com/openembedded-core@lists.openembedded.org/msg36323.html 
but without solution	11:40

JaMait happens in different recipes, so far all were -native

RP  JaMa: relatively old OS?21:26

JaMaRP: no Ubuntu 12.04 22:15
JaMaand it started suddenly few days ago even on different machines
---

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

[OE-core] nss-native fails to build with older binutils on host

[wenzong fan]

Hi folks,

I'm looking for a proper solution to fix this build failure:

Package name: nss-native
Host binutils version: 2.17.50.0.6-20.el5_8.3
Host type: CentOS 5.9

Error message:
--
gcc -o 
Linux3.4_x86_64_glibc_PTH_64_OPT.OBJ/Linux_SINGLE_SHLIB/intel-gcm.o -O2 
-D_POSIX_SOURCE -D_BSD_SOURCE -D_XOPEN_SOURCE -fPIC -DLINUX2_1  -Wall 
-Werror-implicit-function-declaration -Wno-switch -pipe -DLINUX -Dlinux 
-DHAVE_STRERROR -DXP_UNIX -DSHLIB_SUFFIX=\"so\" -DSHLIB_PREFIX=\"lib\" 
-DSHLIB_VERSION=\"3\" -DSOFTOKEN_SHLIB_VERSION=\"3\" 
-DRIJNDAEL_INCLUDE_TABLES -UDEBUG -DNDEBUG -D_REENTRANT -DNSS_ENABLE_ECC 
-DUSE_UTIL_DIRECTLY -DNO_NSPR_10_SUPPORT -DNSS_USE_64 -DFREEBL_NO_DEPEND 
-DNSS_X86_OR_X64 -DNSS_X64 -DNSS_BEVAND_ARCFOUR -DMPI_AMD64 
-DMP_ASSEMBLY_MULTIPLY -DNSS_USE_COMBA -DMP_CHAR_STORE_SLOW 
-DMP_IS_LITTLE_ENDIAN -DUSE_HW_AES -DMP_API_COMPATIBLE 
-I/home/nxadm/nx/yow-blade14.1/builds-2013-08-07-005810/qemumips_world_oe/bitbake_build/tmp/sysroots/x86_64-linux/usr/include 
-I../../../dist/Linux3.4_x86_64_glibc_PTH_64_OPT.OBJ/include 
-I../../../dist/public/nss -I../../../dist/private/nss -Impi -Iecl  -m64 
-fPIC -Wa,--noexecstack -c intel-gcm.s

intel-gcm.s: Assembler messages:
intel-gcm.s:39: Error: no such instruction: `vmovdqu (Tp),T'
intel-gcm.s:40: Error: no such instruction: `vpshufb .Lbswap_mask(%rip),T,T'
intel-gcm.s:41: Error: no such instruction: `vpxor TMP0,TMP0,TMP0'
intel-gcm.s:44: Error: no such instruction: `vpinsrq $0,Mlen,TMP0,TMP0'
intel-gcm.s:45: Error: no such instruction: `vpinsrq $1,Alen,TMP0,TMP0'
..

A similar bug at:

https://bugzilla.mozilla.org/show_bug.cgi?id=838401

That shows it caused by older host binutils (as|objdump).

I think this could be fixed by getting nss-native depends on 
binutils-native, but binutils-native somehow only install some libraries 
and remove all the binaries.


Could I just override the do_install_class-native() for binutils? Or 
provide a second recipe like 'binutils-tools-native' to produce the full 
binutils?


Any advices/suggestions will be welcome.


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

Re: [OE-core] [PATCH 1/1] ghostscript: resolve the gconfig.h conflict

[wenzong fan]

On 06/23/2013 10:02 AM, Saul Wold wrote:

On 06/17/2013 07:02 PM, wenzong@windriver.com wrote:

From: Wenzong Fan 

Both base/lib.mak and psi/int.mak will create file gconfig.h:
 lib.mak: $(CP_) $(gconfig_h) $(GLGEN)gconfig.h
 int.mak: $(CP_) $(gconfig_h) $(PSGEN)gconfig.h

If $(GLGEN) is same with $(PSGEN), the $(GLGEN)gconfig.h will be
overridden by $(PSGEN)gconfig.h in a parallel build, and this
maybe cause build errors.

Upstream has fixed this issue, just portback its fixes from:
 http://downloads.ghostscript.com/public/ghostscript-9.06.tar.gz


If ghostscript upstream has been updated, then why not just upgrade the
package instead of backporting a patch?


Ok, I'll upgrade this package.

Thanks
Wenzong



Sau!


Signed-off-by: Wenzong Fan 
---
  .../resolve-the-gconfig.h-conflict.patch   |   84

  .../ghostscript/ghostscript_9.05.bb|1 +
  2 files changed, 85 insertions(+)
  create mode 100644
meta/recipes-extended/ghostscript/ghostscript/resolve-the-gconfig.h-conflict.patch


diff --git
a/meta/recipes-extended/ghostscript/ghostscript/resolve-the-gconfig.h-conflict.patch
b/meta/recipes-extended/ghostscript/ghostscript/resolve-the-gconfig.h-conflict.patch

new file mode 100644
index 000..9e030e3
--- /dev/null
+++
b/meta/recipes-extended/ghostscript/ghostscript/resolve-the-gconfig.h-conflict.patch

@@ -0,0 +1,84 @@
+Upstream-Status: Backport
+
+Resolve the gconfig.h conflict
+
+Both base/lib.mak and psi/int.mak will create file gconfig.h:
+lib.mak: $(CP_) $(gconfig_h) $(GLGEN)gconfig.h
+int.mak: $(CP_) $(gconfig_h) $(PSGEN)gconfig.h
+
+If $(GLGEN) is same with $(PSGEN), the $(GLGEN)gconfig.h will be
+overridden by $(PSGEN)gconfig.h in a parallel build, and this
+maybe cause build errors.
+
+Upstream has fixed this issue, just portback its fixes from:
+http://downloads.ghostscript.com/public/ghostscript-9.06.tar.gz
+
+Signed-off-by: Wenzong Fan 
+
+---
+ base/gs.mak  |   13 +
+ base/lib.mak |1 -
+ psi/int.mak  |1 -
+ 3 files changed, 9 insertions(+), 6 deletions(-)
+
+diff --git a/base/gs.mak b/base/gs.mak
+index b59e948..e934657 100644
+--- a/base/gs.mak
 b/base/gs.mak
+@@ -261,7 +261,8 @@ MKROMFS_XE=$(AUX)mkromfs$(XEAUX)
+
+ # Define the names of the generated header files.
+ # gconfig*.h and gconfx*.h are generated dynamically.
+-gconfig_h=$(GLGENDIR)$(D)gconfxx.h
++gconfig_h=$(GLGENDIR)$(D)gconfig.h
++gconfxx_h=$(GLGENDIR)$(D)gconfxx.h
+ gconfigf_h=$(GLGENDIR)$(D)gconfxc.h
+ gconfigd_h=$(GLGENDIR)$(D)gconfigd.h
+
+@@ -434,12 +435,16 @@ GCONFIG_EXTRAS=
+ ld_tr=$(GLGENDIR)$(D)ld.tr
+ $(ld_tr) : \
+   $(GS_MAK) $(TOP_MAKEFILES) $(GLSRCDIR)$(D)version.mak
$(GENCONF_XE) $(ECHOGS_XE) $(devs_tr) $(DEVS_ALL)
$(GLGENDIR)$(D)libcore.dev
+-$(EXP)$(GENCONF_XE) $(devs_tr) -h $(gconfig_h) $(CONFILES)
$(CONFLDTR) $(ld_tr)
+-$(EXP)$(ECHOGS_XE) -a $(gconfig_h) $(GCONFIG_EXTRAS)
++$(EXP)$(GENCONF_XE) $(devs_tr) -h $(gconfxx_h) $(CONFILES)
$(CONFLDTR) $(ld_tr)
++$(EXP)$(ECHOGS_XE) -a $(gconfxx_h) $(GCONFIG_EXTRAS)
+
+-$(gconfig_h) : $(ld_tr)
++$(gconfxx_h) : $(ld_tr)
+ $(NO_OP)
+
++$(gconfig_h) : $(gconfxx_h)
++$(RM_) $(gconfig_h)
++$(CP_) $(gconfxx_h) $(gconfig_h)
++
+ # The line above is an empty command; don't delete.
+
+ # save our set of makefile variables that are defined in every build
(paths, etc.)
+diff --git a/base/lib.mak b/base/lib.mak
+index 35328cb..df02e37 100644
+--- a/base/lib.mak
 b/base/lib.mak
+@@ -593,7 +593,6 @@ $(GLOBJ)gconfig.$(OBJ) : $(gconfig_h)
$(GLSRC)gconf.c $(AK) $(gx_h)\
+  $(gscdefs_h) $(gconf_h)\
+  $(gxdevice_h) $(gxiclass_h) $(gxiodev_h) $(gxiparam_h)
$(TOP_MAKEFILES)\
+  $(MAKEDDIRS)
+-$(CP_) $(gconfig_h) $(GLGEN)gconfig.h || true
+ $(CP_) $(GLSRC)gconf.c $(GLGEN)gconfig.c || true
+ $(GLCC) $(GLO_)gconfig.$(OBJ) $(C_) $(GLGEN)gconfig.c
+
+diff --git a/psi/int.mak b/psi/int.mak
+index 1099c29..fab98e6 100644
+--- a/psi/int.mak
 b/psi/int.mak
+@@ -272,7 +272,6 @@ $(PSOBJ)iconfig.$(OBJ) : $(gconfig_h)
$(PSSRC)iconf.c $(stdio__h)\
+  $(gconf_h) $(gconfigd_h) $(gsmemory_h) $(gstypes_h)\
+  $(iminst_h) $(iref_h) $(ivmspace_h) $(opdef_h) $(iplugin_h)
+ $(RM_) $(PSGEN)iconfig.c
+-$(CP_) $(gconfig_h) $(PSGEN)gconfig.h || true
+ $(CP_) $(PSSRC)iconf.c $(PSGEN)iconfig.c || true
+ $(PSCC) $(PSO_)iconfig.$(OBJ) $(C_) $(PSGEN)iconfig.c
+
+--
+1.7.9.5
+
diff --git a/meta/recipes-extended/ghostscript/ghostscript_9.05.bb
b/meta/recipes-extended/ghostscript/ghostscript_9.05.bb
index 9ec5712..c0195c8 100644
--- a/meta/recipes-extended/ghostscript/ghostscript_9.05.bb
+++ b/meta/recipes-extended/ghostscript/ghostscript_9.05.bb
@@ -28,6 +28,7 @@ SRC_URI = "${SRC_URI_BASE} \
 file://objarch.h \
 file://ghostscript-9.02-parallel-make.patch \
 file://ghostscript-9.05-NOT-check-endian.patch \
+   file://resolve-the-gconfig.h-conflict.patch \
 "

  SRC_URI_class-nati

Re: [OE-core] [PATCH 1/1] xcursor-transparent-theme: install index.theme explicitly

[wenzong fan]

On 04/10/2013 05:17 PM, Burton, Ross wrote:

On 10 April 2013 09:00, Martin Jansa  wrote:

On Wed, Apr 10, 2013 at 11:26:35AM +0800, wenzong@windriver.com wrote:

The xcursor-transparent-theme doesn't install index.theme by default,
this might cause below command fails on target:

 $ gtk-update-icon-cache -q /usr/share/icons/xcursor-transparent
 Error: "gtk-update-icon-cache: No theme index file"

Just install index.theme explicitly to remove those error, its content
is from xcursor-transparent-theme's README file.


Wasn't this discussed and fixed before? IIRC the conclusion was that
postinst should check if there is index.theme or ignore it missing, not
adding index.theme.


NACK.

Martin is right, the gtk-icon-cache class uses -t when updating the caches:

--ignore-theme-index, -t
Don't check for the existence of 'index.theme' in the icon theme
directory. Without this option, gtk-update-icon-cache refuses to
create an icon cache in a directory which does not appear to be the
toplevel directory of an icon theme.

If someone is not using gtk-icon-cache.bbclass they either should, or
have a good reason and also use -t.


Oh, I did think I missed something about the discussion of index.theme & 
gtk-update-icon-cache. I recall this patch and sorry for the noise.


I appreciate your clarifications!

Thanks
Wenzong



Ross



___
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] autotools.bbclass: using relative paths for acpaths

[wenzong fan]

On 09/28/2012 12:59 AM, Richard Purdie wrote:

On Thu, 2012-09-27 at 16:23 +0800, wenzong@windriver.com wrote:

From: Wenzong Fan

Fix autotools.bbclass to use relative paths for acpaths instead of
absolute ones. Since absolute paths may cause potential autoreconf
error like:

 Can't exec "/bin/sh": Argument list too long ...

This error occurs while building coreutils with long TMPDIR, because
it has bunch of m4 files need to be expanded.

[YOCTO #2766]

Signed-off-by: Wenzong Fan
---
  meta/classes/autotools.bbclass |3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/meta/classes/autotools.bbclass b/meta/classes/autotools.bbclass
index e4e034b..874e01d 100644
--- a/meta/classes/autotools.bbclass
+++ b/meta/classes/autotools.bbclass
@@ -130,7 +130,8 @@ autotools_do_configure() {
if [ x"${acpaths}" = xdefault ]; then
acpaths=
for i in `find ${S} -maxdepth 2 -name \*.m4|grep -v 
'aclocal.m4'| \
-   grep -v 'acinclude.m4' | sed -e 
's,\(.*/\).*$,\1,'|sort -u`; do
+   grep -v 'acinclude.m4' | sed -e 
's,\(.*/\).*$,\1,'|sort -u| \
+   sed -e 's,${S},\.,'`; do
acpaths="$acpaths -I $i"
done
else


We applied this but it nearly instantly caused build failure reports.
Anything with multiple configure.ac files where sub configures are used
such as bdwgc-native will fail after this.

I've therefore reverted it and we need to find another way.


Sorry, I didn't figure this out while building a sato image. If we can't 
make everything happy, could we get back the original ways which only 
fix it for coreutils?


With the limit to length of TMPDIR, this issue should rarely occurs.

Thanks
Wenzong



Cheers,

Richard




___
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] coreutils: fix do_configure error with long TMPDIR

[wenzong fan]

On 08/24/2012 12:33 PM, wenzong fan wrote:

On 08/24/2012 12:28 AM, Saul Wold wrote:

On 08/19/2012 07:55 PM, wenzong@windriver.com wrote:

From: Wenzong Fan 

By default the 'm4/*' files will be extended with absolute path while
autoreconf running, if the length of TMPDIR is too long such as 410
which is the maximum value allowed by 'sanity.bbclass', autoreconf
will fail with error:

Can't exec "/bin/sh": Argument list too long ...

Fix this issue by specific the 'acpaths' to '-I ./m4'.

[YOCTO #2766]

Signed-off-by: Wenzong Fan 
---
meta/recipes-core/coreutils/coreutils_8.14.bb | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-core/coreutils/coreutils_8.14.bb
b/meta/recipes-core/coreutils/coreutils_8.14.bb
index 9a714a9..c7c8e13 100644
--- a/meta/recipes-core/coreutils/coreutils_8.14.bb
+++ b/meta/recipes-core/coreutils/coreutils_8.14.bb
@@ -7,7 +7,7 @@ BUGTRACKER = "http://debbugs.gnu.org/coreutils";
LICENSE = "GPLv3+"
LIC_FILES_CHKSUM = "file://COPYING;md5=d32239bcb673463ab874e80d47fae504\
file://src/ls.c;startline=5;endline=16;md5=e1a509558876db58fb6667ba140137ad"


-PR = "r5"
+PR = "r6"
DEPENDS = "gmp libcap"
DEPENDS_virtclass-native = ""

@@ -36,6 +36,8 @@ base_bindir_progs = "cat chgrp chmod chown cp date
dd echo false kill ln ls mkdi

sbindir_progs= "chroot"

+acpaths = "-I ./m4"
+

This is a poor work-around to the problem, and does not give any idea as
to what your fixing. Please investigate a proper fix not just a
work-around.


Hi Saul,

Because a too long TMPDIR will caused the failure:

Can't exec "/bin/sh": Argument list too long at
/usr/lib/perl/5.10/IO/File.pm line 66.

So we have a limitation in the sanity.bbclass that the tmpdir can't be
longer than 410. See commit 2dee999ab2731c2a96e82762ae04fe44f27edac6.

This limitation works for mostly packages but except for coreutils.
There are 378 m4 files under '.../coreutils-8.14/m4', so if all of them
extended with absolute path while the TMPDIR is long enough, it will be
a very long argument list and over the ARG_MAX value that kernel defined.


The ARG_MAX from '/usr/include/linux/limits.h' is '131072'. Only the 
m4/* extended will over than 378 * 410 = 154980 bytes, it's indeed a 
very long argument list.


Wenzong



I think the best solution is reducing the length of argument list,
because autoreconf will be run in $S dir, so absolute path is not
necessary here. The acpaths is generated by autotools.bbclass and allow
to overwrite by a pre-defined value. Another option is getting
autotools.bbclass generate acpatchs with relative path directly, this
might work, but will effect all autotool packages instead of coreutils
only.


Thanks
Wenzong



Thanks
Sau!


do_install_append() {
for i in df mktemp base64; do mv ${D}${bindir}/$i
${D}${bindir}/$i.${BPN}; done






___
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] coreutils: fix do_configure error with long TMPDIR

[wenzong fan]

On 08/24/2012 12:28 AM, Saul Wold wrote:

On 08/19/2012 07:55 PM, wenzong@windriver.com wrote:

From: Wenzong Fan 

By default the 'm4/*' files will be extended with absolute path while
autoreconf running, if the length of TMPDIR is too long such as 410
which is the maximum value allowed by 'sanity.bbclass', autoreconf
will fail with error:

Can't exec "/bin/sh": Argument list too long ...

Fix this issue by specific the 'acpaths' to '-I ./m4'.

[YOCTO #2766]

Signed-off-by: Wenzong Fan 
---
meta/recipes-core/coreutils/coreutils_8.14.bb | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-core/coreutils/coreutils_8.14.bb
b/meta/recipes-core/coreutils/coreutils_8.14.bb
index 9a714a9..c7c8e13 100644
--- a/meta/recipes-core/coreutils/coreutils_8.14.bb
+++ b/meta/recipes-core/coreutils/coreutils_8.14.bb
@@ -7,7 +7,7 @@ BUGTRACKER = "http://debbugs.gnu.org/coreutils";
LICENSE = "GPLv3+"
LIC_FILES_CHKSUM = "file://COPYING;md5=d32239bcb673463ab874e80d47fae504\
file://src/ls.c;startline=5;endline=16;md5=e1a509558876db58fb6667ba140137ad"

-PR = "r5"
+PR = "r6"
DEPENDS = "gmp libcap"
DEPENDS_virtclass-native = ""

@@ -36,6 +36,8 @@ base_bindir_progs = "cat chgrp chmod chown cp date
dd echo false kill ln ls mkdi

sbindir_progs= "chroot"

+acpaths = "-I ./m4"
+

This is a poor work-around to the problem, and does not give any idea as
to what your fixing. Please investigate a proper fix not just a
work-around.


Hi Saul,

Because a too long TMPDIR will caused the failure:

Can't exec "/bin/sh": Argument list too long at 
/usr/lib/perl/5.10/IO/File.pm line 66.


So we have a limitation in the sanity.bbclass that the tmpdir can't be 
longer than 410. See commit 2dee999ab2731c2a96e82762ae04fe44f27edac6.


This limitation works for mostly packages but except for coreutils. 
There are 378 m4 files under '.../coreutils-8.14/m4', so if all of them 
extended with absolute path while the TMPDIR is long enough, it will be 
a very long argument list and over the ARG_MAX value that kernel defined.


I think the best solution is reducing the length of argument list, 
because autoreconf will be run in $S dir, so absolute path is not 
necessary here. The acpaths is generated by autotools.bbclass and allow 
to overwrite by a pre-defined value. Another option is getting 
autotools.bbclass generate acpatchs with relative path directly, this 
might work, but will effect all autotool packages instead of coreutils only.



Thanks
Wenzong



Thanks
Sau!


do_install_append() {
for i in df mktemp base64; do mv ${D}${bindir}/$i
${D}${bindir}/$i.${BPN}; done






___
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] sysfsutils: install libs to base_libdir

[wenzong fan]

On 08/09/2012 09:57 PM, Saul Wold wrote:

On 08/09/2012 06:19 AM, wenzong fan wrote:

On 08/08/2012 04:44 PM, Koen Kooi wrote:


Op 8 aug. 2012, om 08:09 heeft wenzong fan
het volgende geschreven:


On 08/07/2012 08:23 PM, Koen Kooi wrote:


Op 7 aug. 2012, om 14:14 heeft wenzong@windriver.com het
volgende geschreven:


From: Wenzong Fan

Fix the warning form pcmciautils building:

"WARNING: QA Issue: pcmciautils: /sbin/pccardctl, installed in the
base_prefix, requires a shared library under exec_prefix (/usr):
libsysfs.so.2 => /usr/lib/libsysfs.so.2"

Just refer to Debian/Ubuntu distributions, install sysfsutils libs
to "/lib*" instead of "/usr/lib*".

[YOCTO #2907]

Signed-off-by: Wenzong Fan
---
meta/recipes-core/sysfsutils/sysfsutils_2.1.0.bb | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-core/sysfsutils/sysfsutils_2.1.0.bb
b/meta/recipes-core/sysfsutils/sysfsutils_2.1.0.bb
index 3e4fdda..f01d19b 100644
--- a/meta/recipes-core/sysfsutils/sysfsutils_2.1.0.bb
+++ b/meta/recipes-core/sysfsutils/sysfsutils_2.1.0.bb
@@ -8,7 +8,7 @@ LICENSE_libsysfs = "LGPLv2.1"
LIC_FILES_CHKSUM =
"file://COPYING;md5=3d06403ea54c7574a9e581c6478cc393 \

file://cmd/GPL;md5=d41d4e2e1e108554e0388ea4aecd8d27 \

file://lib/LGPL;md5=b75d069791103ffe1c0d6435deeff72e"
-PR = "r3"
+PR = "r4"

SRC_URI = "${SOURCEFORGE_MIRROR}/linux-diag/sysfsutils-${PV}.tar.gz \
file://sysfsutils-2.0.0-class-dup.patch \
@@ -24,3 +24,5 @@ PACKAGES =+ "libsysfs libsysfs-dev
libsysfs-staticdev"
FILES_libsysfs = "${libdir}/lib*${SOLIBS}"
FILES_libsysfs-dev = "${libdir}/lib*${SOLIBSDEV} ${includedir}"
FILES_libsysfs-staticdev = "${libdir}/lib*.a"


Ahem! ^^^


Yep, this works but looks confused, do you mean the 'export libdir'
should be put ahead of FILES_lib*?

From the build logs, only change is $libdir: '/usr/lib -> /lib',
details please refer to attached file.


Wenzong,
We are looking for buildhistory info, not a diff of your build log.

buildhistory can be activated as follows in your local.conf:

INHERIT += "buildhistory"
BUILDHISTORY_COMMIT = "1"

Then you can build before and after your change, and use the script
buildhistory_diff to produce the output we are looking for.


Re-send this because oe-core list was broken yesterday.

Saul,

Thanks for let me know this, it's really cool. The buildhistory diff are:

--
commit b6d84f2a1f755e391596e9a6a38167a6c0657b0a
Author: buildhistory 
Date:   Thu Aug 9 20:37:23 2012 +0800

packages: Build 201208092036 of poky 1.2+snapshot-20120809 for 
machine qemux86 on usp-ub1204-64


diff --git a/packages/i586-poky-linux/sysfsutils/libsysfs-dev/latest 
b/packages/i586-poky-linux/sysfsutils/libsysfs-dev/latest

index d9477cd..565cfbf 100644
--- a/packages/i586-poky-linux/sysfsutils/libsysfs-dev/latest
+++ b/packages/i586-poky-linux/sysfsutils/libsysfs-dev/latest
@@ -3,5 +3,5 @@ PR = r3
 RDEPENDS = libsysfs
 RRECOMMENDS = eglibc-dev
 PKGSIZE = 16307
-FILES = /usr/lib/lib*.so /usr/include
-FILELIST = /usr/include/sysfs/dlist.h /usr/include/sysfs/libsysfs.h 
/usr/lib/libsysfs.so

+FILES = /lib/lib*.so /usr/include
+FILELIST = /lib/libsysfs.so /usr/include/sysfs/dlist.h 
/usr/include/sysfs/libsysfs.h
diff --git 
a/packages/i586-poky-linux/sysfsutils/libsysfs-staticdev/latest 
b/packages/i586-poky-linux/sysfsutils/libsysfs-staticdev/latest

index cac1061..6507d26 100644
--- a/packages/i586-poky-linux/sysfsutils/libsysfs-staticdev/latest
+++ b/packages/i586-poky-linux/sysfsutils/libsysfs-staticdev/latest
@@ -3,5 +3,5 @@ PR = r3
 RDEPENDS =
 RRECOMMENDS =
 PKGSIZE = 171740
-FILES = /usr/lib/lib*.a
-FILELIST = /usr/lib/libsysfs.a
+FILES = /lib/lib*.a
+FILELIST = /lib/libsysfs.a
diff --git a/packages/i586-poky-linux/sysfsutils/libsysfs/latest 
b/packages/i586-poky-linux/sysfsutils/libsysfs/latest

index 8fb74a6..575f971 100644
--- a/packages/i586-poky-linux/sysfsutils/libsysfs/latest
+++ b/packages/i586-poky-linux/sysfsutils/libsysfs/latest
@@ -4,5 +4,5 @@ PKG = libsysfs2
 RDEPENDS = eglibc (>= 2.16)
 RRECOMMENDS =
 PKGSIZE = 42781
-FILES = /usr/lib/lib*.so.*
-FILELIST = /usr/lib/libsysfs.so.2 /usr/lib/libsysfs.so.2.0.1
+FILES = /lib/lib*.so.*
+FILELIST = /lib/libsysfs.so.2 /lib/libsysfs.so.2.0.1
diff --git a/packages/i586-poky-linux/sysfsutils/sysfsutils-dbg/latest 
b/packages/i586-poky-linux/sysfsutils/sysfsutils-dbg/latest

index e575683..851e8de 100644
--- a/packages/i586-poky-linux/sysfsutils/sysfsutils-dbg/latest
+++ b/packages/i586-poky-linux/sysfsutils/sysfsutils-dbg/latest
@@ -3,5 +3,5 @@ PR = r3
 RDEPENDS =
 RRECOMMENDS = eglibc-dbg libsysfs-dbg sysfsutils (= 2.1.0-r3)
 PKGSIZE = 333084
-FILES = /usr/bin/.debug /usr/sbin/.debug /usr/libexec/.debug 
/usr/lib/.debug /bin/.debug /sbin/.debug /lib/.debug 
/usr/lib/sysfsutils/.debug /usr/lib/match

Re: [OE-core] [PATCH 1/1] at 3.1.13: get 'at' depends on 'flex-native' explicitly

[wenzong fan]

On 08/09/2012 09:01 PM, Paul Eggleton wrote:

On Thursday 09 August 2012 10:59:15 wenzong@windriver.com wrote:

From: Wenzong Fan

'at' needs flex to generate source file lex.yy.c, but it doesn't
depend on flex-native directly; This maybe cause a do_compile
failure if flex-native is not built or included in project.

Error message is:
 error: lex.yy.c: No such file or directory

Get 'at' depends on flex-native to fix this potential issue.

[YOCTO #2919]

Signed-off-by: Wenzong Fan
---
  meta/recipes-extended/at/at_3.1.13.bb |4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-extended/at/at_3.1.13.bb
b/meta/recipes-extended/at/at_3.1.13.bb index ce9396a..a391d6e 100644
--- a/meta/recipes-extended/at/at_3.1.13.bb
+++ b/meta/recipes-extended/at/at_3.1.13.bb
@@ -4,14 +4,14 @@ the system load levels drop to a particular level."
  SECTION = "base"
  LICENSE="GPLv2+"
  LIC_FILES_CHKSUM = "file://COPYING;md5=4325afd396febcb659c36b49533135d4"
-DEPENDS = "flex initscripts \
+DEPENDS = "flex flex-native initscripts \


Does it need flex for the target as well, or was it a case of "flex" being added
instead of "flex-native" by mistake?


Yes, it is needed.

I removed 'flex' from DEPENDS, the build failed with:
---
i586-poky-linux-gcc  -m32   -march=i586 
--sysroot=/buildarea/wfan/at/tmp/sysroots/qemux86 -I. -O2 -pipe -g 
-feliminate-unused-debug-types -o at at.o panic.o perm.o posixtm.o 
y.tab.o lex.yy.o   -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed

| lex.yy.o: In function `yylex':
| 
/buildarea/wfan/at/tmp/work/i586-poky-linux/at-3.1.13-r2/at-3.1.13/lex.yy.c:1247: 
undefined reference to `yywrap'

| collect2: error: ld returned 1 exit status
---

Thanks
Wenzong



Cheers,
Paul



___
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] sysfsutils: install libs to base_libdir

[wenzong fan]

On 08/08/2012 04:44 PM, Koen Kooi wrote:


Op 8 aug. 2012, om 08:09 heeft wenzong fan  het 
volgende geschreven:


On 08/07/2012 08:23 PM, Koen Kooi wrote:


Op 7 aug. 2012, om 14:14 heeft wenzong@windriver.com het volgende 
geschreven:


From: Wenzong Fan

Fix the warning form pcmciautils building:

"WARNING: QA Issue: pcmciautils: /sbin/pccardctl, installed in the
base_prefix, requires a shared library under exec_prefix (/usr):
libsysfs.so.2 =>   /usr/lib/libsysfs.so.2"

Just refer to Debian/Ubuntu distributions, install sysfsutils libs
to "/lib*" instead of "/usr/lib*".

[YOCTO #2907]

Signed-off-by: Wenzong Fan
---
meta/recipes-core/sysfsutils/sysfsutils_2.1.0.bb |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-core/sysfsutils/sysfsutils_2.1.0.bb 
b/meta/recipes-core/sysfsutils/sysfsutils_2.1.0.bb
index 3e4fdda..f01d19b 100644
--- a/meta/recipes-core/sysfsutils/sysfsutils_2.1.0.bb
+++ b/meta/recipes-core/sysfsutils/sysfsutils_2.1.0.bb
@@ -8,7 +8,7 @@ LICENSE_libsysfs = "LGPLv2.1"
LIC_FILES_CHKSUM = "file://COPYING;md5=3d06403ea54c7574a9e581c6478cc393 \
 file://cmd/GPL;md5=d41d4e2e1e108554e0388ea4aecd8d27 \
 file://lib/LGPL;md5=b75d069791103ffe1c0d6435deeff72e"
-PR = "r3"
+PR = "r4"

SRC_URI = "${SOURCEFORGE_MIRROR}/linux-diag/sysfsutils-${PV}.tar.gz \
  file://sysfsutils-2.0.0-class-dup.patch \
@@ -24,3 +24,5 @@ PACKAGES =+ "libsysfs libsysfs-dev libsysfs-staticdev"
FILES_libsysfs = "${libdir}/lib*${SOLIBS}"
FILES_libsysfs-dev = "${libdir}/lib*${SOLIBSDEV} ${includedir}"
FILES_libsysfs-staticdev = "${libdir}/lib*.a"


Ahem! ^^^


Yep, this works but looks confused, do you mean the 'export libdir' 
should be put ahead of FILES_lib*?


From the build logs, only change is $libdir: '/usr/lib -> /lib', 
details please refer to attached file.


Thanks
Wenzong




+
+export libdir = "${base_libdir}"


And can you post the buildhistory diff to see if anything else moved when it 
shouldn't have e.g. package config files?


I make a diff to the build dir, only the location of 'lib/' was moved:


Please post the buildhistory diff, that is much more informative. And you 
haven't responded to the FILES_lib* oversight.
--- sysfsutils-2.1.0-r4.old/temp/log.do_configure	2012-08-08 13:59:37.769845883 +0800
+++ sysfsutils-2.1.0-r4.new/temp/log.do_configure	2012-08-07 20:04:56.334984465 +0800
@@ -33,7 +33,7 @@
 test/Makefile.am:9: library has 'testlibsysfs' as canonical name (possible typo)
 autoreconf: running: gnu-configize
 autoreconf: Leaving directory `.'
-NOTE: Running /buildarea/wfan/qt4-native-4.8.1/tmp/work/i586-poky-linux/sysfsutils-2.1.0-r4/sysfsutils-2.1.0/configure  --build=x86_64-linux 		  --host=i586-poky-linux 		  --target=i586-poky-linux 		  --prefix=/usr 		  --exec_prefix=/usr 		  --bindir=/usr/bin 		  --sbindir=/usr/sbin 		  --libexecdir=/usr/libexec 		  --datadir=/usr/share 		  --sysconfdir=/etc 		  --sharedstatedir=/com 		  --localstatedir=/var 		  --libdir=/usr/lib 		  --includedir=/usr/include 		  --oldincludedir=/usr/include 		  --infodir=/usr/share/info 		  --mandir=/usr/share/man 		  --disable-silent-rules 		  --disable-dependency-tracking 		  --with-libtool-sysroot=/buildarea/wfan/qt4-native-4.8.1/tmp/sysroots/qemux86  
+NOTE: Running /buildarea/wfan/qt4-native-4.8.1/tmp/work/i586-poky-linux/sysfsutils-2.1.0-r4/sysfsutils-2.1.0/configure  --build=x86_64-linux 		  --host=i586-poky-linux 		  --target=i586-poky-linux 		  --prefix=/usr 		  --exec_prefix=/usr 		  --bindir=/usr/bin 		  --sbindir=/usr/sbin 		  --libexecdir=/usr/libexec 		  --datadir=/usr/share 		  --sysconfdir=/etc 		  --sharedstatedir=/com 		  --localstatedir=/var 		  --libdir=/lib 		  --includedir=/usr/include 		  --oldincludedir=/usr/include 		  --infodir=/usr/share/info 		  --mandir=/usr/share/man 		  --disable-silent-rules 		  --disable-dependency-tracking 		  --with-libtool-sysroot=/buildarea/wfan/qt4-native-4.8.1/tmp/sysroots/qemux86  
 configure: WARNING: unrecognized options: --disable-silent-rules
 configure: loading site script /buildarea/wfan/poky/meta/site/endian-little
 configure: loading site script /buildarea/wfan/poky/meta/site/ix86-common
--- sysfsutils-2.1.0-r4.old/temp/log.do_compile	2012-08-08 13:59:42.017845808 +0800
+++ sysfsutils-2.1.0-r4.new/temp/log.do_compile	2012-08-07 20:05:01.662984371 +0800
@@ -31,7 +31,7 @@
 ../i586-poky-linux-libtool  --tag=CC   --mode=compile i586-poky-linux-gcc  -m32   -march=i586 --sysroot=/buildarea/wfan/qt4-native-4.8.1/tmp/sysroots/qemux86 -DHAVE_CONFIG_H -I. -I.. -I../include   -Wall -W -Wstrict-prototypes  -O2 -pipe -g -feliminate-unused-debug-types -c -o libsysfs_la-sysfs_module.lo `test -f 'sysfs_module.c' || echo './'`sysfs_module.c
 i586-poky-linux-libto

Re: [OE-core] [PATCH 1/1] sysfsutils: install libs to base_libdir

[wenzong fan]

On 08/07/2012 08:23 PM, Koen Kooi wrote:


Op 7 aug. 2012, om 14:14 heeft wenzong@windriver.com het volgende 
geschreven:


From: Wenzong Fan

Fix the warning form pcmciautils building:

"WARNING: QA Issue: pcmciautils: /sbin/pccardctl, installed in the
base_prefix, requires a shared library under exec_prefix (/usr):
libsysfs.so.2 =>  /usr/lib/libsysfs.so.2"

Just refer to Debian/Ubuntu distributions, install sysfsutils libs
to "/lib*" instead of "/usr/lib*".

[YOCTO #2907]

Signed-off-by: Wenzong Fan
---
meta/recipes-core/sysfsutils/sysfsutils_2.1.0.bb |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-core/sysfsutils/sysfsutils_2.1.0.bb 
b/meta/recipes-core/sysfsutils/sysfsutils_2.1.0.bb
index 3e4fdda..f01d19b 100644
--- a/meta/recipes-core/sysfsutils/sysfsutils_2.1.0.bb
+++ b/meta/recipes-core/sysfsutils/sysfsutils_2.1.0.bb
@@ -8,7 +8,7 @@ LICENSE_libsysfs = "LGPLv2.1"
LIC_FILES_CHKSUM = "file://COPYING;md5=3d06403ea54c7574a9e581c6478cc393 \
 file://cmd/GPL;md5=d41d4e2e1e108554e0388ea4aecd8d27 \
 file://lib/LGPL;md5=b75d069791103ffe1c0d6435deeff72e"
-PR = "r3"
+PR = "r4"

SRC_URI = "${SOURCEFORGE_MIRROR}/linux-diag/sysfsutils-${PV}.tar.gz \
  file://sysfsutils-2.0.0-class-dup.patch \
@@ -24,3 +24,5 @@ PACKAGES =+ "libsysfs libsysfs-dev libsysfs-staticdev"
FILES_libsysfs = "${libdir}/lib*${SOLIBS}"
FILES_libsysfs-dev = "${libdir}/lib*${SOLIBSDEV} ${includedir}"
FILES_libsysfs-staticdev = "${libdir}/lib*.a"


Ahem! ^^^


+
+export libdir = "${base_libdir}"


And can you post the buildhistory diff to see if anything else moved when it 
shouldn't have e.g. package config files?


I make a diff to the build dir, only the location of 'lib/' was moved:

Only in sysfsutils-2.1.0-r4.new/image: lib
Only in sysfsutils-2.1.0-r4.old/image/usr: lib
Only in sysfsutils-2.1.0-r4.new/package: lib
Only in sysfsutils-2.1.0-r4.old/package/usr: lib
Only in sysfsutils-2.1.0-r4.new/packages-split/libsysfs: lib
Only in sysfsutils-2.1.0-r4.old/packages-split/libsysfs: usr
Only in sysfsutils-2.1.0-r4.new/packages-split/libsysfs-dev: lib
Only in sysfsutils-2.1.0-r4.old/packages-split/libsysfs-dev/usr: lib
Only in sysfsutils-2.1.0-r4.new/packages-split/libsysfs-staticdev: lib
Only in sysfsutils-2.1.0-r4.old/packages-split/libsysfs-staticdev: usr
Only in sysfsutils-2.1.0-r4.new/packages-split/sysfsutils-dbg: lib
Only in sysfsutils-2.1.0-r4.old/packages-split/sysfsutils-dbg/usr: lib
Only in sysfsutils-2.1.0-r4.new/packages-split/sysfsutils-dev: lib
Only in sysfsutils-2.1.0-r4.old/packages-split/sysfsutils-dev: usr
Only in sysfsutils-2.1.0-r4.new/sysroot-destdir: lib
Only in sysfsutils-2.1.0-r4.old/sysroot-destdir/usr: lib


Thanks
Wenzong


___
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] gdk-pixbuf: fix parallel install issue

[wenzong fan]

On 08/06/2012 06:32 AM, Colin Walters wrote:

On Fri, 2012-08-03 at 11:30 +0800, wenzong@windriver.com wrote:


Make an explicit dependency to the libs install targets would fix this
issue.


I don't think Yocto should be running the 'make install' target with
parallelism enabled; it's just going to be a source of major pain for
small gain.  Historically Automake's install targets have had a lot of
paralleism issues AIUI, even discarding modules which have custom
install hooks.



Hi Richard,

What's your opinions?

Disable/Enable paralleism for 'make install', this more like a policy
issue rather than tech.

Thanks
Wenzong



___
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] qt4: fix qt4-native build failure on SLED-11

[wenzong fan]

On 08/01/2012 08:36 PM, Paul Eggleton wrote:

On Wednesday 01 August 2012 19:50:02 wenzong@windriver.com wrote:

From: Wenzong Fan

This issue is that with C++ compiler process an old version of kernel
header file, coincidently that file has a variable named 'new':

* 'embedded/qkbdtty_qws.cpp' include 'linux/vt.h';
* '/usr/include/linux/vt.h' has below code on SLED-11.x:
 + unsigned int new;

On mostly hosts it has been changed to: new ->  newev.

[YOCTO #2845]

Signed-off-by: Wenzong Fan


Could you please add the description and signed-off-by to the inner patch as
well?


Ok, I have added those infos and sent patch v2.

Thanks
Wenzong



Thanks,
Paul



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

Re: [OE-core] [PATCH v2 0/1] archive.bbclass: archive work directory

[wenzong fan]

On 01/12/2012 04:04 PM, wenzong fan wrote:

On 01/12/2012 03:31 PM, Saul Wold wrote:

On 01/10/2012 11:34 PM, wenzong@windriver.com wrote:

From: Wenzong Fan

v2 updates:

1) Remove the special-casing for gcc, checking for any packages under
'tmp/work-shared';

2) Remove some bash-specific code, replase the '[[regular-expression]]'
with isovalent 'grep' statement.


So how is this work different than that of Xiaofeng's doing the 
tar_archive?  Can these two be merged somehow?  We also have 
something called copyleft complaince, is this similar or somehow 
different?


They are a little similar but mostly are different, #1655 (Xiaofeng's) 
will need to export the source packages (such as *.tar, *.rpm ...) for 
using, Mark also commented the details at:


http://bugzilla.pokylinux.org/show_bug.cgi?id=1655

But the #1590 (mine) only archive the patched sources/build_scripts up 
for later checking.


And I think both the 'archive.bbclass' and 'copyleft_complaince.bbclass' 
were designed for some license related issues, but the 'archive.bbclass' 
will create snapshot for all sources and 'copyleft_complaince.bbclass' 
will do dynamic checking for the licenses.


Thanks
Wenzong


Thanks
Wenzong



We also have src_distribute.bbclass and sourcepkg.bbclass, seems like 
we have a more ways to package up source code than we know what to do 
with.


Mark, we might want to sync up on this and figure out what we really 
have and what's really needed here.


Thanks
Sau!




The following changes since commit 
4a8a3c503fd896593b787c26edbe46a7324e494e:

   Richard Purdie (1):
 Revert "site/common-uclibc: Cache gl_cv_func_wcwidth_works"

are available in the git repository at:

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

Wenzong Fan (1):
   archive.bbclass: archive work directory

  meta/classes/archive.bbclass |   49 
++

  1 files changed, 49 insertions(+), 0 deletions(-)
  create mode 100644 meta/classes/archive.bbclass


___
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




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

Re: [OE-core] [PATCH v2 0/1] archive.bbclass: archive work directory

[wenzong fan]

On 01/12/2012 03:31 PM, Saul Wold wrote:

On 01/10/2012 11:34 PM, wenzong@windriver.com wrote:

From: Wenzong Fan

v2 updates:

1) Remove the special-casing for gcc, checking for any packages under
'tmp/work-shared';

2) Remove some bash-specific code, replase the '[[regular-expression]]'
with isovalent 'grep' statement.


So how is this work different than that of Xiaofeng's doing the 
tar_archive?  Can these two be merged somehow?  We also have something 
called copyleft complaince, is this similar or somehow different?


They are a little similar but mostly are different, #1655 (Xiaofeng's) 
will need to export the source packages (such as *.tar, *.rpm ...) for 
using, Mark also commented the details at:


http://bugzilla.pokylinux.org/show_bug.cgi?id=1655

But the #1590 (mine) only archive the patched sources/build_scripts up 
for later checking.


Thanks
Wenzong



We also have src_distribute.bbclass and sourcepkg.bbclass, seems like 
we have a more ways to package up source code than we know what to do 
with.


Mark, we might want to sync up on this and figure out what we really 
have and what's really needed here.


Thanks
Sau!




The following changes since commit 
4a8a3c503fd896593b787c26edbe46a7324e494e:

   Richard Purdie (1):
 Revert "site/common-uclibc: Cache gl_cv_func_wcwidth_works"

are available in the git repository at:

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

Wenzong Fan (1):
   archive.bbclass: archive work directory

  meta/classes/archive.bbclass |   49 
++

  1 files changed, 49 insertions(+), 0 deletions(-)
  create mode 100644 meta/classes/archive.bbclass


___
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] archive.bbclass: archive work directoryDistribution

[wenzong fan]

On 01/07/2012 01:39 AM, Phil Blundell wrote:

On Fri, 2012-01-06 at 16:20 +0800, wenzong@windriver.com wrote:
   

+if [[ -d ${S}&&  ${S} != ${WORKDIR} ]]; then
+if [[ ${S} =~ "/work-shared/gcc" ]]; then
+# Create temporary sources directory for gcc
+mkdir -p ${PF}/temp
+cp -r ${S} ${PF}
+cp -r ${S}/../temp/* ${PF}/temp
+cp -r ${WORKDIR}/temp/* ${PF}/temp
+tarbase=`pwd`
 

Special-casing gcc like this seems a bit lame.  Is that check really
needed?
   


Oh, we might have other packages under this dir, so I'll remove the 
special-casing 'gcc' here.

Also, will the above code work with all shells?  It looks a bit
bash-specific to me.
   
I assume that the bitbake have to run with 'bash', looks like this is 
not right on all distributions.


I'll update this.

Thanks
Wenzong


p.



___
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] archive.bbclass: archive work directory

[wenzong fan]

On 01/06/2012 04:46 PM, Saul Wold wrote:

On 01/06/2012 12:20 AM, wenzong@windriver.com wrote:

From: Wenzong Fan

Some legal departments believe a complete archive of the work directory
is required for certain license compliance issues. We could therefore
do with a class which archives up the work directories in each build and
provide them so those legal departments can be happy.

Implementations:

Add a new class named 'archive.bbclass' to provide task 'do_archive',
and get it called after 'do_patch' before 'do_configure'.

Following cases should be considered to the sources dirs:
1) The sources dir is under $WORKDIR:
Just archive sources and temp/run.* up.

2) The sources dir is outside of $WORKDIR, the only package is gcc:
Copy its sources and temp/run.* to a temporary dir and then archive
them up.

3) The sources dir is equal to $WORKDIR:
Just archive whole work dir up.

[YOCTO #1590]

Signed-off-by: Wenzong Fan
---
  meta/classes/archive.bbclass |   42 
++

  1 files changed, 42 insertions(+), 0 deletions(-)
  create mode 100644 meta/classes/archive.bbclass

diff --git a/meta/classes/archive.bbclass b/meta/classes/archive.bbclass
new file mode 100644
index 000..75ac090
--- /dev/null
+++ b/meta/classes/archive.bbclass
@@ -0,0 +1,42 @@
+# Archive the patched sources and build scripts to assist in license
+# compliance by the end user or legal departments.
+
+ARCHIVE_DIR = "${TMPDIR}/archives/${MULTIMACH_TARGET_SYS}/"
+do_archive[dirs] = "${ARCHIVE_DIR}"
+
I see you set ARCHIVE_DIR, but I don' see you move or copy any files 
to this directory, am I missing something?


It just gets bitbake creating '${ARCHIVE_DIR}' before the task started, 
and then 'do_archive' will be run in this dir.





+archive_do_archive() {
+# In mostly scenarios the $S is under $WORKDIR and has a separate
+# dir for storing the sources; but gcc is a special case, its 
sources

+# had been moved to the shared location 'tmp/work-shared/'
+if [[ -d ${S}&&  ${S} != ${WORKDIR} ]]; then
+if [[ ${S} =~ "/work-shared/gcc" ]]; then
+# Create temporary sources directory for gcc
+mkdir -p ${PF}/temp
+cp -r ${S} ${PF}
+cp -r ${S}/../temp/* ${PF}/temp
+cp -r ${WORKDIR}/temp/* ${PF}/temp
+tarbase=`pwd`
+else
+tarbase=`dirname ${WORKDIR}`
+fi
+
+sourcedir=`basename ${S}`
+tar -C $tarbase -cjf ${PF}.tar.bz2 ${PF}/$sourcedir \
+${PF}/temp --exclude log.do_*
+
Also, do you want to name the tarball PF or BP, which deals with 
removing any multilib naming issues if the build it multilib.


Note BP = ${BPN}-${PV} so it removes the ${PR} if that is important 
(which it might be).


Sorry I'm not clear your exact meanings here, do you mean the tarball 
name with '${PF}' will have any issues?


Thanks
Wenzong




+# Remove the temporary gcc sources directory
+if [[ ${S} =~ "/work-shared/gcc"&&  -d ${PF} ]]; then
+rm -rf ${PF}
+fi
+fi
+
+# Just archive whole build directory up when $S is equal to 
$WORKDIR

+if [[ -d ${S}&&  ${S} == ${WORKDIR} ]]; then
+tarbase=`dirname ${WORKDIR}`
+tar -C $tarbase -cjf ${PF}.tar.bz2 ${PF} --exclude log.do_*
+fi
+}
+
+addtask do_archive after do_patch before do_configure
+
+EXPORT_FUNCTIONS do_archive





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

Re: [OE-core] [PATCH 2/5] m4: Add m4-nativesdk recipes

[wenzong fan]

On 11/30/2011 02:04 AM, Richard Purdie wrote:

On Tue, 2011-11-29 at 17:48 +, McClintock Matthew-B29882 wrote:
   

On Tue, Nov 29, 2011 at 2:38 AM,  wrote:
 

From: Wenzong Fan

[YOCTO #1603]

m4-nativesdk is required by autoconf-nativesdk.
   

Is there a reason we don't just extend the m4 recipe for native and
nativesdk? (I'm just curious)
 

Its a good question, BBCLASSEXTEND = "nativesdk" should really work and
those recipes look wrong (they shouldn't need to set
INHIBIT_AUTOTOOLS_DEPS = "1" or have the custom do_configure).
   


Ah, this works. I'll extend the m4 recipe to support 'nativesdk'

The m4-native recipe is a little tricker as its one of the early
bootstrap dependencies required by autotools. This is why it does need
the INHIBIT_AUTOTOOLS_DEPS and custom do_configure line although those
should be possible with modern BBCLASSEXTEND...

   


Thanks for let me know the story, this really confused me when I 
deciding copy/extend for the m4-nativesdk.


Wenzong

Cheers,

Richard


___
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 4/5] autoconf: Extend to provide nativesdk recipe

[wenzong fan]

On 11/29/2011 05:14 PM, Koen Kooi wrote:

Op 29 nov. 2011, om 10:00 heeft wenzong fan het volgende geschreven:

   

On 11/29/2011 04:49 PM, Koen Kooi wrote:
 

Op 29 nov. 2011, om 09:39 heeft   
   het volgende geschreven:


   

From: Wenzong Fan

[YOCTO #1603]

 

For every recipe: what is '[yocto #1603]'?
   

http://bugzilla.pokylinux.org/show_bug.cgi?id=1603

The updates to each recipe was related to this requirement for yocto 1.2, so I 
add the id number in all commit messages.
 

If you add such IDs you need to add a lot more info like a summary of the 
bugreport. People reading commit logs aren't going to know and URI to yocto bz 
(especially in OE-core git) and even if they'd know, opening a webbrowser to 
understand a commit message is not good.

   


You are right, I'll update the commit messages and add more info to it, 
thanks for your advises.


Wenzong


   



___
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 4/5] autoconf: Extend to provide nativesdk recipe

[wenzong fan]

On 11/29/2011 04:49 PM, Koen Kooi wrote:

Op 29 nov. 2011, om 09:39 heeft  
  het volgende geschreven:

   

From: Wenzong Fan

[YOCTO #1603]
 

For every recipe: what is '[yocto #1603]'?


http://bugzilla.pokylinux.org/show_bug.cgi?id=1603

The updates to each recipe was related to this requirement for yocto 
1.2, so I add the id number in all commit messages.


Thanks
Wenzong



___
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 0/1] distro_tracking: update tracking fields for gettext and eds-tools

[wenzong fan]

On 11/29/2011 01:56 AM, Saul Wold wrote:

On 11/27/2011 11:57 PM, wenzong@windriver.com wrote:

From: Wenzong Fan

Update distro tracking fields for gettext and eds-tools.

The eds-tools fails to build for now, so left its status as 'red'. A
defect #1786 has been filed for tracking this.

The following changes since commit 
4cd96710785eb05abeff1f281878655118d4a7dd:

   Richard Purdie (1):
 bitbake: Update users of getVar/setVar to use the data store 
functions directly


are available in the git repository at:

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



Wenzong Fan (1):
   distro_tracking: update tracking fields for gettext and eds-tools

  .../conf/distro/include/distro_tracking_fields.inc |   11 ++-
  1 files changed, 6 insertions(+), 5 deletions(-)

This patch did not apply cleanly and seems to provide duplicate 
entries, please rebase and resubmit.


Hi Saul,

I can't find any issue on the patch itself, but I'm not sure if the 
branch name cause any duplicate issues in your side. I have resubmitted 
it to a different branch, please refer to:


-
The following changes since commit 4cd96710785eb05abeff1f281878655118d4a7dd:
  Richard Purdie (1):
bitbake: Update users of getVar/setVar to use the data store 
functions directly


are available in the git repository at:

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


Wenzong Fan (1):
  distro_tracking: update tracking fields for gettext and eds-tools

 .../conf/distro/include/distro_tracking_fields.inc |   11 ++-
 1 files changed, 6 insertions(+), 5 deletions(-)
---

Thanks
Wenzong



Thanks
Sau!



___
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 0/1] distro_tracking_fields: update packages tracking fields

[wenzong fan]

On 11/02/2011 08:36 AM, Saul Wold wrote:

On 10/24/2011 07:49 PM, wenzong@windriver.com wrote:

From: Wenzong Fan

Update distro tracking fields for ccache, chkconfig.

The following changes since commit 
53ee27a1c5b589cba874f674c428e1a36557cc3b:

   Joshua Lock (1):
 doc: update manual for checksum changes

are available in the git repository at:

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



Wenzong Fan (1):
   distro_tracking_fields: update packages tracking fields

  .../conf/distro/include/distro_tracking_fields.inc |   12 
  1 files changed, 12 insertions(+), 0 deletions(-)


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


This got pulled, but I still need a fix for Month format to MMM please


Fixed, please see another PR whcih with subject "distro_tracking_fields: 
Update the Month to 'MMM'".


Thanks
Wenzong


Thanks
Sau!





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

Re: [OE-core] [PATCH 3/3 v2] distro_tracking_fields: update packages tracking fields

[wenzong fan]

On 10/20/2011 03:43 PM, Saul Wold wrote:

On 10/19/2011 10:59 PM, wenzong@windriver.com wrote:

From: Wenzong Fan

Update packages tracking fields including ccache, chkconfig.

Signed-off-by: Wenzong Fan
---
  .../conf/distro/include/distro_tracking_fields.inc |   12 
  1 files changed, 12 insertions(+), 0 deletions(-)

diff --git a/meta/conf/distro/include/distro_tracking_fields.inc 
b/meta/conf/distro/include/distro_tracking_fields.inc

index abc2cbf..a7c2db5 100644
--- a/meta/conf/distro/include/distro_tracking_fields.inc
+++ b/meta/conf/distro/include/distro_tracking_fields.inc
@@ -5914,6 +5914,18 @@ RECIPE_LATEST_RELEASE_DATE_pn-gettext = "Jun 
06, 2010"

  RECIPE_LAST_UPDATE_pn-gettext = "May 24, 2011"
  RECIPE_MANUAL_CHECK_DATE_pn-gettext = "Sep 29, 2011"

+RECIPE_STATUS_pn-ccache = "green"
+RECIPE_MAINTAINER_pn-ccache = "Wenzong Fan"
+RECIPE_LATEST_VERSION_pn-ccache = "3.1.6"
+RECIPE_LAST_UPDATE_pn-ccache = "June 24, 2011"

You just updated this package, so this should be today's date
Do you mean theis to be RECIPE_LATEST_RELEASE_DATE of June?  Is that 
when the 3.1.6 tarball was released?


Oh, sorry I misunderstand the '_LAST_', June is the last update time for 
previous version 3.1.5.


I'll fix that.

Thanks
Wenzong



+RECIPE_MANUAL_CHECK_DATE_pn-ccache = "October 11, 2011"
+
+RECIPE_STATUS_pn-chkconfig = "green"
+RECIPE_MAINTAINER_pn-chkconfig = "Wenzong 
Fan"

+RECIPE_LATEST_VERSION_pn-chkconfig = "1.3.55"
+RECIPE_LAST_UPDATE_pn-chkconfig = "May 24, 2011"

Same as above!

Sau!

+RECIPE_MANUAL_CHECK_DATE_pn-chkconfig = "October 11, 2011"
+
  RECIPE_STATUS_pn-pseudo = "green"
  RECIPE_LATEST_VERSION_pn-pseudo = "1.1.1"
  RECIPE_LAST_UPDATE_pn-pseudo = "Jun 06, 2011"






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

Re: [OE-core] [PATCH 1/3 v2] ccache: update to 3.1.6

[wenzong fan]

Recall this threads, they are duplicated with another one.

Wenzong

On 10/20/2011 01:59 PM, wenzong@windriver.com wrote:

From: Wenzong Fan

Update ccache to 3.1.6 from 3.1.5.

Signed-off-by: Wenzong Fan
---
  .../ccache/{ccache_3.1.5.bb =>  ccache_3.1.6.bb}|4 ++--
  1 files changed, 2 insertions(+), 2 deletions(-)
  rename meta/recipes-devtools/ccache/{ccache_3.1.5.bb =>  ccache_3.1.6.bb} 
(47%)

diff --git a/meta/recipes-devtools/ccache/ccache_3.1.5.bb 
b/meta/recipes-devtools/ccache/ccache_3.1.6.bb
similarity index 47%
rename from meta/recipes-devtools/ccache/ccache_3.1.5.bb
rename to meta/recipes-devtools/ccache/ccache_3.1.6.bb
index 9a967b2..e87468a 100644
--- a/meta/recipes-devtools/ccache/ccache_3.1.5.bb
+++ b/meta/recipes-devtools/ccache/ccache_3.1.6.bb
@@ -4,5 +4,5 @@ PR = "r0"
  LICENSE = "GPLv3+"
  LIC_FILES_CHKSUM = "file://LICENSE.txt;md5=80e92ec45d4fca91f127864fb9e5d932"

-SRC_URI[md5sum] = "b1a9684828eae68382d6afc98ce80d24"
-SRC_URI[sha256sum] = 
"54afc35c672ce451e04a478cfc0eb74c1ba184e27ef24881206602aa0eb94d63"
+SRC_URI[md5sum] = "e6565e7d6c95d1e35b7a0d67e39901e8"
+SRC_URI[sha256sum] = 
"59f58bb73f00db5bbff36b8eb530d3000c86b3110e34cf8dba9e2a5d19eb684f"
   



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

Re: [OE-core] [PATCH 0/3 v2] Update packages

[wenzong fan]

I got some issues on the git-sendmail, please ignore the duplicate emails.

Sorry for the inconvenience.

Thanks
Wenzong

On 10/20/2011 02:04 PM, wenzong@windriver.com wrote:

From: Wenzong Fan

v2 add the patch to distro_tracking_fields.inc file.

The following changes since commit b4757833c3548b5ee3a1cce58e2f059b3f63cb09:
   Martin Jansa (1):
 fontconfig: fix fix-pkgconfig.patch

are available in the git repository at:

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

Wenzong Fan (3):
   ccache: update to 3.1.6
   chkconfig: Update to 1.3.55
   distro_tracking_fields: update packages tracking fields

  .../conf/distro/include/distro_tracking_fields.inc |   12 
  .../ccache/{ccache_3.1.5.bb =>  ccache_3.1.6.bb}|4 ++--
  .../{chkconfig_1.3.52.bb =>  chkconfig_1.3.55.bb}   |6 +++---
  3 files changed, 17 insertions(+), 5 deletions(-)
  rename meta/recipes-devtools/ccache/{ccache_3.1.5.bb =>  ccache_3.1.6.bb} 
(47%)
  rename meta/recipes-extended/chkconfig/{chkconfig_1.3.52.bb =>  
chkconfig_1.3.55.bb} (83%)


___
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] libpam: Setting suid bit for unix_chkpwd

[wenzong fan]

On 08/22/2011 10:30 AM, Scott Garman wrote:

On 08/20/2011 09:05 AM, Khem Raj wrote:

On 8/20/2011 12:58 AM, wenzong@windriver.com wrote:

From: Wenzong Fan

[YOCTO #1252]

While pam_unix.so required by an application on lsb image, it will
need to
call the unix_chkpwd to get userinfo from shadow file. This fix get a
normal
user could read shadow file via unix_chkpwd.

Signed-off-by: Wenzong Fan
---
meta/recipes-extended/pam/libpam_1.1.4.bb | 8 +++-
1 files changed, 7 insertions(+), 1 deletions(-)

diff --git a/meta/recipes-extended/pam/libpam_1.1.4.bb
b/meta/recipes-extended/pam/libpam_1.1.4.bb
index ae20a97..ca54bd8 100644
--- a/meta/recipes-extended/pam/libpam_1.1.4.bb
+++ b/meta/recipes-extended/pam/libpam_1.1.4.bb
@@ -9,7 +9,7 @@ SECTION = "base"
LICENSE = "GPLv2+ | BSD"
LIC_FILES_CHKSUM = 
"file://COPYING;md5=ca0395de9a86191a078b8b79302e3083"


-PR = "r1"
+PR = "r2"

DEPENDS = "bison flex cracklib"
RDEPENDS_${PN}-runtime = "libpam pam-plugin-deny pam-plugin-permit
pam-plugin-warn pam-plugin-unix"
@@ -85,3 +85,9 @@ do_install() {
install -d ${D}${sysconfdir}/pam.d/
install -m 0644 ${WORKDIR}/pam.d/* ${D}${sysconfdir}/pam.d/
}
+
+pkg_postinst_pam-plugin-unix () {
+ # below is necessary to allow unix_chkpwd get user info from shadow
file
+ # on lsb images
+ chmod 4755 /usr/sbin/unix_chkpwd


may be its better to use corresponding metadata variables instead of
hardcoding /usr/sbin here


With Khem's recommended tweak:


Good point, patch v2 will be sent with this updates.

Thanks
Wenzong


Acked-by: Scott Garman 




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